Check other parts:
In this part, i will be talking about the Claims Clients and how they connect to the claims issuer and then to the claims based application.
If you think of the way claims clients should work, you will definitely know that the whole objective is to communicate the token from the client to the application in a secure way.
There are two types of claims clients:
- Browser clients (passive nature) :
- Based on WS-Federation Passive Requestor Profile.
- Uses browser redirects, HTTP GET/POST.
- Non browser smart client (active nature)
- Based on WS-Trust and WS-Federation Active Requestor Profile.
- Smart clients can be Windows-based applications or services such as WCF services.
- WS-Trust: describes how to get security token from issuer
- WS-Security: describes how to pass that security token to a claims-based web service.
- WS-Federation: a protocol that is built on other standard protocols like WS-Trust and WS-Security, and it helps requesting security tokens in browser-based applications, among other things.
- Windows Identity Foundation WIF: .NET classes used to build claims-aware apps.
Step 1: Redirect to issuer
Browser access the application and get redirected to the issuer logon page (HTTP 302) with many query string arguments that act as an instruction to the issuer. Those query strings are:
- Wa: stands for action and indicates weather you are signing in (wsignin1.0) or signing out (wsignout1.0)
- Wtrealm: target realm and contains the URI that identifies the application.
- Wct: time stamp
- Wctx: context data such as return URL
Step 2: Issuer
- The issuer then will try to authenticate the user. This can be a form to type your credentials in, or empty page that is configured in IIS to require Integrated Authentication or smart card authentication.
- The issuer will use the information in the wtrealm query string to identify claims for that application.
- The issuer will generate security token (SAML token)
- The SAML token will be signed with the issuer private key.
- If the application wants its tokens encrypted, the issuer encrypts the token with the public key in the application’s certificate.
- A standard HTTP redirect cannot be used because the token may be 4 KB long, which is larger than most browser’s size limit for a URL. Instead a <form> that includes a POST method is used.
- The issuer may issue its own cookie so that users remain logged on at the issuer and can access many applications. Think about how this works—when a user visits a second application and that application redirects back to the same issuer, the issuer sees its cookie and knows the user has recently been authenticated, so it can immediately issue a token without having to authenticate again. This is how to use claims to achieve Internet-friendly single sign-on with a browser based application.
SAML response (a.k.a Security Token) received from the issuer contains:
- Creation date
- Expiration Date
- Token Audience (URL for the application)
- SAML restrictions and conditions
Step 3: Redirect to application
- POST arrives at the application and WIF takes over.
- The Application has a WIF HTTP module named WSFederationAuthenticationModule (FAM) to intercept the POST
- FAM listens for AuthenticateRequest events and do the following:
- Verifies the token signature
- Extracts the claims in the token and uses the User.Identity property to present IClaimsPrincipal object to the application.
- Issues a cookies (Session tokens) called FedAuth[n] that contains the ClaimsPrincipal object with any other attributes in a compressed and encrypted form.
- On subsequent requests to the application, the SessionApplicationModule intercepts the cookies and uses them to reconstruct the ClaimsPrincipal
Non Browser-Based (Smart Clients)
In smart clients, the client will try to get a token from the issuer before contacting the application, while in browser based clients, the browser will visit the application first and then get redirected to the issuer for token requests.
- The application’s web service is configured with wsFederationHttpBinding that specifies a policy requiring the client to add a SML token to the SOAP security header in order to invoke the service.
- Client sends RequestSecurityToken RST to the issuer.
- Then the issuer sends back the response (RSTR), which includes a signed security token that is encrypted with the public key of the web service. The token includes a proof key. This is a symmetric key randomly generated by the issuer and included as part of the RSTR so that the client also gets a copy.
- Mainly everything later is the same as the browser client.
Blog Reference: A guide to claims-based identity and access control – second edition / Microsoft Corporation