Infosys Microsoft Alliance and Solutions blog

« Performance Point Server - Reports Migration | Main | Role of Claims based Authentication in Federated Security -- 5 (Zermatt) »

Role of Claims based Authentication in Federated Security -- 4

I guess with part 3, I hope I have covered all the basics required for understanding Zermatt. Just to recap, Claims represent an identity as a set of attributes which can be anything like Email Id, name, Age, certificate, etc and can come from any source like AD/LDAP, WCS, custom DB, etc. These attributes are very similar to the attributes that exists in AD for any user/machine entry that exists in AD.

In a normal Application based Authentication, Application goes to these repositories like AD/DB to get additional attributes information for Authorization needs. In Claims based Authentication, the user does the Authentication and goes to the Application with Claims (attributes) to the Application (Application never goes to repositories for getting the attributes).

The next logical question that comes to ones mind is that when a user goes with Claims to access the Application, how will the Application trust all the claims and that they are issued by a valid Authority? Digital Signatures help in the same. All the claims details which in the serialized form is called a token alias Security Token, is signed by the issuing authority and the Application post verification of the signature, will trust that the claims made has come from the right, trusted source. The Authority which issues tokens is often referred to as STS (Security Token Service). Just like the way certificate chaining can be built to validate the certificates issued by intermediate authorities, Chaining can be built here as well through the same concept of Digital Signatures and ensure that trust relationship between STS's of partner organizations can be built. This ensures that an organization can trust the partner organization STS to do the authentication and the based on the token it received, the local STS can further issue additional claims (token) which will be valid in the local domain. The same logic holds true across departments/ applications on different platforms having their own STSs.

With this background, we will see what Zermatt offers for achieving this Single Signon /Federated Security in the next blog probably the last in this series to cover the basics of Zermatt.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter