IBM Tivoli Federated Identity Manager (TFIM) simplifies application integration by providing single sign on between disparate web applications, so the users do not have to share their passwords or re-enter them. TFIM uses various protocols to achieve federation, which include SAML, WS-Federation, and OpenID. Our Security LoB has been invited by IBM to participate in a beta program to implement the popular authorization protocol, OAuth. OAuth, which stands for Open Authorization, is a protocol that allows users to approve applications to act on their behalf. OAuth makes it possible to exchange critical information across distinct organizations based upon a service level agreement that states one application as an OAuth client and the other as an OAuth provider. One major benefit of the OAuth protocol is its emphasis on authorization, when compared to its alternatives. This is giving rise to a hybrid model in which our customers can combine protocols like SAML or OpenID for authentication and OAuth for authorization. OAuth, besides making the token exchange mechanism transparent to the user, provides mechanisms to define the scope which the Client could access regarding the user’s data on the Provider.
Here is a fictitious example. Imagine PFAP as a financial application dashboard developed by Prolifics that provides a user with a consolidated view of his account balances across multiple banks. First, PFAP would have to be in an agreement as an OAuth client across all of the banks, from which account information would be obtained on behalf of the user. Once an agreement is set up with each Provider, PFAP would be registered as an OAuth client to those particular banks (Providers) and so would be provided with a client ID and a shared secret for each one. This information (Client ID, Shared Secret) would help the Provider determine, if the application (Client) requesting data on behalf of user, is one of its trusted OAuth clients. Assuming an agreement between Prolifics and a leading financial firm, PFAP is one of the OAuth clients that has access to the Firm's customer data, upon approval. The first time a user logs into the PFAP application, he will be asked to add his account number to PFAP. Once the user selects “Add Account” button, the user would be redirected to the Firm's website, where he would be asked to put in his credentials. At this step a token would be requested by PFAP from the Firm in the background, which gets authorized upon user logging into the Firm's website. This action grants access to PFAP to act on the user’s behalf.
From the user’s perspective, once logged in the Firm would display a “Consent to Authorize” page where the user would needs to permit access to PFAP to act on his behalf and retrieve information within a certain scope, which in this case would be user’s account balance. Once the user agrees to permit PFAP to act on his behalf and retrieve balance information, a verifier code is sent to PFAP in the background. PFAP would then request an access token from the Firm's application sending the verifier code, Client ID, Shared Secret and few other parameters to request an Access token. The Firm would verify the Client ID and Shared Secret to determine if PFAP is one of its OAuth clients and then would verify the Verifier Code to generate an Access token. Once PFAP receives the Access token, it enables PFAP to get the user’s data on his behalf though within a permitted scope, which in this case would be the account balance. So next time the user logs in, since PFAP would already have an Access token, the user would be able to see his balance information without having to login to the Firm's website. Now, implementation of hybrid models is being thought upon, where a combination of OAuth with protocols like SAML or OpenID would help us achieve SSO at the same time. For instance, once logged into PFAP, an implementation of hybrid model would enable the user to perform other operations in the Firm's website like balance transfers, by launching a new link to the Firm without the need to login again (SSO).
