Identity building in an application for developers is a difficult task, as the application needs to support the authentication from different zones like the internet, intranet, and so on.
Why is it difficult?
For a normal Application used over the internet, the users can easily access the Application by providing a username and password, which are stored in the Application's database in the back-end or in an Application specifically used by the users within the organization; the Application can rely on the organization's user directory to authenticate the user.
Now, imagine the same Application needs to be accessed by both the internet and extranet users. Subsequently, this Application should support both the username and password mechanism for internet and should rely on the organization's directory to support the intranet users. What if a business partner wants to access the same Application? Should he log in as an Internet user or an Intranet user? What if the
Application is hosted on the Cloud?
Imagine how complex it becomes for a developer to build an Application, which should handle all such authentication.
What would resolve?
Here comes the idea of claims, which provides a unified technique to handle all these authentications in a single go.
In the digital world, each of the application on a computer contains its own identity. It is the same with the users who are accessing a specific resource; each will have a unique identity. When a user submits a request to access an Application he is prompted with the username and password; a token is generated by an authentication Service, which contains the user’s identity within.
This token contains the information about the user, which he claims.
![]()
In the scenario mentioned above, the authentication Service that issues a token verifies its directory as per the username and password provided by the user and generates a token and digitally signs it.
The claims can be different for the different applications, which depends upon the type of the application and the information it expects from the user. In our environment, the Service that does all this is called STS (Security token Service).
Let's consider a scenario where a user tries to access an Application with the help of a Web Browser or REST Service. Now, the user is redirected to STS. The Browser or the other client helps the user to access the Application, which raises a ticket by providing the username and password when prompted by STS. This ticket contains the password, which is supplied by the user and the URL of the Application, which the user tries to access. Now, STS generates a security token after verifying the details of the user and the Application; which he is trying to access in its database.
Role of Identity Provider
Here, STS is only a service that serves the Browser by generating a token, which is governed by an identity provider. An identity provider is the one, which is trusted by the Application. In fact, the claims that the user makes should be trusted by the identity provider without which the user cannot access the Application. Now, it is up to the architects of the Application, who will configure the Application whether to trust that specific identity provider or not.
In simple words, if your Application is using an STS token within in your company’s domain, then your organization is your identity provider, else you are using a STS token, which serves Facebook then Facebook is your identity provider.
Claims from the application point of view
In the absence of claims, when a user provides his username and password; the Application verifies it, once the verification is done and if further information is required, the Application has to depend on the organization’s directory or can contain its own database but in presence of claims, the Application specifically mentions what data; it needs to submit in the token provided by the STS generated by the identity provider.
In a claims based approach, the Application is not worried about how the user is authenticated. It is now no more a concern for the developers to build an Application to support different types of authentication. All the Application needs to take care about it i.e. it is getting a token from the trusted identity provider.
The main aim of the claims based authentication is to simplify the user’s submission of his identity and let the Application decide about what role is assigned to the particular user. The most important step is the administrator should configure the identity provider and STS to generate the kind of claims, which are to be involved in the token, which is generated for the user, which are useful for the Application in deciding whether the particular user is authenticated or not, if authenticated what kind of role has to be assigned to him.
Although there is an assumption that there would be only one digital identity for a user who tries to access different Applications, the digital world depends upon different identity providers which has STS to produce appropriate claims in the token generated. The claims in these tokens are different from each other. Basically, we would require multiple identity selectors to access an Application.
In this scenario of multiple Identities, when a user tries to access an Application, using Web Browser or REST Service or any other client, the Application provides what claims that it requires, using Http protocol. Once the Browser has this information, there would be multiple identity selectors, which would be shown on the client’s screen. The user selects the identity selector, provides a username and password. Now, the identity selector contacts the appropriate identity provider, which generates the token with the required claims and provides it to the Browser. The Browser submits this token to the relying party, once the Application has this token, it verifies whether there are required claims in the token, which is provided by the Browser. Once the verification is successful, the user is allowed to access the Application. It is not required to have the identity selector in this scenario but it would be useful, if used. Identity selector is the facility which would be provided to the users to select there way of getting authenticated.
The claims based approach doesn’t mandate that there should be a specific pattern for the tokens, which are generated. Nowadays, the tokens are defined, using XML SAML format but it is not the only required format that should be followed.
Active Directory Federation Services
Microsoft provides Active Directory Federation services to support claims based authentication and Windows Identity Foundation. ADFS 2.0 implements a windows based STS. As the name explains it is an extension of Active Directory Domain Services. ADFS 2.0 implements an STS that generates SAML tokens. ADFS 2.0 also supports WCF and other clients unlike its predecessor which used to support only the browsers. It is to be kept in mind that ADFS is not the only service that provides this functionality but custom built STS can also be used. Products from other Vendors such as IBM Tivoli Federated Identity Manager also provides similar kind of functionality the way ADFS provides.
User accessing an Intranet Application
Let’s consider a scenario where the user is trying to access an Intranet application. User logs in into his organization’s active directory and gets a SAML token. Now, the user tries to access the application, now the application provides the kind of claims that it requires, now the user is redirected to organization’s ADFS. The ADFS verifies the token that the clients provides and checks active directory for the claims that has to be produced in the token that it generates. The type of claims that are to be produced will depended on the application that user is trying to access. Now, the ADFS STS generates the token (does a claims transformation) and provide it to the client, now the client is redirected to the application.The application verifies the SAML token that is generated and allows the user to access the application.
Why this redirection from AD to ADFS and ADFS to an application is happening?
In this scenario ADFS being an Identity provider is configured to produce the type of claims that the application requires which would not be present in the token that is generated by active directory and provided to the user. In the absence of ADFS the architect of the application has to configure the application to make a trip to active directory and get the required claims that it needs from the token submitted by the client which is generated by active directory.
User accessing the same application over the Internet
If the same application has to be extended to the internet environment, in this case, CBA would be reliable.
Here, when a remote user is trying to access the application using the internet environment, the user is asked to select one of the identity selectors provided. Once the user selects the Identity Selector, the user's system is redirected to ADFS STS to generate a token, now the user has redirected the application he wish to access.
How the user is getting authenticated to the Identity provider?
In the previous scenario, the client was using the token that is generated by active directory to authenticate himself. But the remote user is trying to access the application where he will be asked his username and password by the ADFS STS. As the user is already using the same username and password that the firm has provided him there would already be a profile created in Active Directory. Now, ADFS STS makes a trip to the Active Directory and authenticates the user by generating a token.
What if the users are not employees of the organization?
If the users are not employees of the organization, they would be asked to log in using Facebook, Gmail, or Google +, or any other Identity providers and their profile would be created in Active Directory as the external users; which would be a rare case where the business decides to create a profile for the external users along with employees of the organization.
But anyway, the users are providing their username and password, what is the claim here?
The thing to be remembered here is the users need not to provide their user names and password for all the different applications that the organization has launched over the internet. Logging in once would be enough to access the other Applications that are launched by the same organization. Here, in this scenario, the organization is acting as Identity provider for the application.