Federated identity Management
‘Federated identity management’ has its origins in the concepts of ‘Single sign on’ and ‘Identity management’. In order to completely understand ‘Federated identity management’ we have to skim through these concepts first.
‘Identity management’ is authenticating and authorizing different individuals at different levels in an organization so that they are able to access only the correct amount of resources on different systems and applications.
Single sign on:
‘Single sign on’ on the other hand aims to ease password fatigue which occurs with repetitive entry of ‘username’ and ‘password’ combination. Like it or not, the most commonly used way to authenticate an individual even today, is still the traditional ‘username’ and ‘password’ combination. It is quite a common occurrence for one to have lost his password at least once during his online forays or felt confused about the different combinations of characters that are possible for his password!
It is here, that the concept of ‘Single sign on’ seeks to help us. There is a single username and password combination that is used for different applications and third party apps of a single organization. The most popularly used example to illustrate this concept is always ‘Google’. If you have a ‘Google’ account, and you sign into it with your username and password – you will automatically be logged into ‘YouTube’, ‘Gmail’, ‘Google Drive’, ‘Google photos’, ‘Google Maps’ and more.
Federated identity management:
‘Federated identity management’, is an extension to ‘SSO concept’ or the concept of ‘Single sign on’. Here, again the main idea is to ease the user having to enter and re-enter the ‘username’ and ‘password’ combination multiple times across various sites. In ‘federated identity management’, the user’s login credentials are authenticated first. This authenticated information is shared across multiple domains in order for the user to be able to access the different applications and resources smoothly and efficiently. This way, the user only has to be authenticated once and he/she will automatically be signed onto other participating sites.
Two sites are said to be ‘federated’ when the users get authenticated on one site and they are able to effectively and easily access the resources on another site without re-authenticating.
Advantages of using ‘federated identity management’:
- As already stated, the primary aim of ‘federated identity management’ is ease of use for end-users.
- It also reduces administrative overhead so that the administrator does not have to create multiple accounts and work with managing different ‘username’ and ‘password’ combinations
- It also brings about huge cost savings for participating organizations
SAML, OpenID and OAuth:
There are a number of federated identity standards such as SAML (Security Assertion Markup Language), OpenID and OAuth. It is beyond doubt that we would have encountered these standards online without knowing that they are constantly working in the background. Here are few details of SAML, OpenID and OAuth.
SAML:
SAML(pronounced “sam-el”) is a a XML based standard for both authentication and authorization. SAML 1.0 was first introduced in 2001and the latest version is 2.0 which was released in 2005. SAML is more suited for applications which only involve a single sign on by enterprises.
The three components in SAML usage are – assertions, protocol and binding. The three roles in SAML are principal, identity provider and service provider.
‘Principal’ is the end user(as an example “Bob”) requesting the services from a ‘service provider’(as an example, “facebook.com”) The ‘Identity provider’ validates a user and acts as the trusting medium between the organizations. We can equate ‘identity provider’ to the ‘Aadhar’ identification in India.The ‘Aadhar’ card in India is accepted as trusted identification by many organizations. Once we present the ‘Aadhar’ card, we are not required to re-identify again. In the same way, once we authenticate ourself with the ‘identity provider’ we do not have to do it again.
In SAML and other identity standards, ’trust’ between the different organizations and identity provider is the most crucial factor that keeps the federated identity ball rolling.
Working of SAML:
- The user uses a browser and requests a service(say google.com) to the service provider
- The service provider generates a SAML request and returns it to the browser
- The browser sends the SAML request to the identity provider
- The identity provider authenticates the user(if not already authenticated) and creates a SAML response
- The SAML response is sent to the browser
- The browser sends the SAML response to the service provider and the user is logged in
Security risks:
SAML is prone to XML signature wrapping vulnerability which can be used to impersonate any other user.
OAuth:
OAuth(Open Authentication) was launched in 2006 and is an open standard for token based authentication and authorization. The latest version is OAuth 2.0 It is mostly suited for API authorization and is used by many organizations like Google, LinkedIn, Facebook.
It is quite a probability that we would have encountered the concept of OAuth in our online lives too. By using OAuth, we can login to one website and access the resources of another site by using the credentials of the first site. Most of us would have encountered a similar screen on many occasions.
In order to login to ‘Quora’ we can either create a separate login and password or login with ‘Facebook’ or ‘Google’. Logging in with ‘Facebook’ or ‘Google’ is a perfect example of the working of OAuth. By using OAuth a user’s password fatigue is simplified. OAuth also ensures that only the login details of ‘Facebook’ are shared with ‘Quora’ and the password is not shared at all.
Working of OAuth:
- ‘Client application’(like ‘Quora’) would like to use the data from a resource server(say ‘Facebook’)
- The user data from the ‘resource server’ can only be accessed by an API and not directly.
- Further, to prevent any malicious apps from accessing the same user data, ‘access tokens’ are used. These ‘access tokens’ are generated by ‘authorization server’ and given to the ‘client application’.
- The client application receives the ‘access token’
- The client application requests the user data from the ‘resource server’ along with the ‘access token’.
- The ‘resource server’ verifies if the client application credentials are indeed genuine to access its data. If it is genuine, data is returned to the client application.
Security vulnerabilities of OAuth:
OAuth is prone to phishing attacks and it does not support encryption, channel binding or client verification.
OpenID:
OpenID is an open standard for authentication and the latest version is ‘OpenID connect’. OpenID was first introduced in 2005 and it is a single layer that is present on top of OAuth 2.0 protocol. OpenID extends the capabilities of ‘federated authentication’(the ability to login to app an using ‘Facebook’(here, ‘Facebook’ is an example)) As much as OpenID Connect is similar to SAML, it is more suited for single sign on for consumers.
Similar to SAML, there are three roles in OpenID Connect. They are end user, relying party, OpenID provider. Users can authenticate themselves with the OpenID provider and then easily sign on to other applications. Some examples of OpenID providers are Google, Facebook, Symantec and Yahoo. OpenID Connect again reduces ‘password fatigue’ .
Contact Us
1800-843-7890 (India) 
