How Single Sign on works in claims authentication

These days users are very much demanding, they want to access lot of interactive applications on the web but do not want to re-enter their credentials from one application

to another application. it is because of this reason claim based authentication has to support single sign on so that it can be used for various scenarios.

Single sign on is very common in window authentication scenarios where users enters their credentials in morning and access lot of resource in their company throught the

day.

With use of kerberos it cannot include all claims like users email address as kerberos is not competent to provide all claims. Also Active directory is key server for company so it is

behind firewall so you cannot access it untill you configure some thing like VPN from outside company network.

Because of above limitation there is need for better flexibility which can override above limitations. Here comes the claims which comes with all possibilities and features

designed to work cross boundaries such as realms, Firewalls and different platforms for secure communications. With claims your application do not need to authenticate

users , it completely decouples from authentication all it needs is security token from the issuer which it trusts. Application will not break if there is change in security

authentication.

The end goal for any claim based architecture is to communicate claims from issuer to application in secure way. Some of the application has goals to enable federation.

There are two type of federation one is with smart client and other is through browser.

When we are using window based application(smart client) then communication is to request token and pass to services(like WCF). When we are using browser based web

application which relies on HTTP get and Post to get and pass security Tokens. For browser based claim aware application it works like Form based authentication. If users

needs to sign in users are redirected to issuer's Login page here the user is authenticated and then redirect to Application. Issues Login Page doesnt neccesarry be  

Login.aspx like in Form Authentication it can be empty html page which is configured in IIS to accept Window authentication, client certificate or smart card etc.

 

 

When user is redirected to Issuer Page for Authentication two Important values are passed

as part of query string

1) wa :- Signin or signout to tell issuer if user is logging in or logging off.
2) realm :- The url for the application which is used by Issuer to identify the application.

After authentication, issuer grant the claims configured for that application , package claims into security token and sign it with private key. If application requires claims to

be encrypted it encrypt with public key of application certificate too. After this issuer send the html page to browser with Form tag and security token wrapped inside that.

The action is configured to submit with URL of application it also emit some javascript so that user dont see the page and page is automatically posted to

application url so that application can use security token inside the form tag. Application recieves it and validate the token

and store it in a cookie for subsquent requests.

Now assume if issuer is using Integrated Authentication then user go to application which redirects user to issuer login which post the security token and back to application.

As we know WIF(Windows Identity framework) is used to make any application claim aware. After issuer Post the Authentication token WIF of application takes over. It

listens for "AuthenticateRequest" event and validates the incoming token by using issuer public key to make sure it is trusted with Issuer. It also validate AudienceURI

element to make sure token is issued for correct application. Then it parses the claims in the application create IclaimPrinciple object and assign it to User.Identity in page

life cycle. It also create session token to store these values so that authentication process is not repeated for same session until user sign off or expiration of cookie is done.

 

On subsequent request session cookie is checked and if values are present then recreate the claim principle using values in cookie

to reassign current user property.