The word Security is an important in the IT arena. Enterprises spend millions of dollars for implementing security measures for their wide range of IT assets varying from physical security to application security. Authentication is a basic requirement for access control. It can be a sophisticated biometric strategies or a simple application level user id/password combination. What exactly is authentication? I consider it as the process of recognizing the user.
Historically software applications, whether it is custom developed or enterprise application, incorporated an authentication module in itself. The user id and password (Probably digested password) is challenged against the store. The store could be an LDAP server or a simple database. Modern applications uses declarative authentication using any of the Pluggable Authentication Module (PAM). Even though it is relatively easy, all the application in an enterprise needs to implement authentication module. If each of this application needs to converse between themselves or the user need to navigate from one application to another, he has to login to the respective application and it created inconvenience and reduced the user experience of the participating applications. Then suddenly a new philosophy appeared into the horizon named ‘Single Sign On’. This concealed the individual authentication process from the user and gave him an experience of smooth and seamless navigation from one application to another in an enterprise.
Now a new thought came into picture. Why do we need to authenticate the user in each and every application in an enterprise? Can’t we believe our fellow applications? If a user is authenticated against one of the application in a trustworthy environment like an enterprise why does another application need to validate the user again? These questions guided the architect community to the very though of federated trust. In this the all or some of the applications in an enterprise forms a trusted group. That means each application in this group considers its fellow application as a trusted application. They keep the digital certificate or any other means of proof of the trusted applications.
If a user is authenticated against the application A and if he wants to talk to application B from A then application A sends a detailed covering letter about the user to B in its letter pad. Seeing the covering letter, B verifies whether it is really from A and if so it assumes that the user is a valid user without a second time authentication. In the digital world, most preferred covering letter is in the form of a SAML message. Security Assertion Markup Language (SAML) is an XML based protocol for exchanging authentication and authorization information. This is standardized by OASIS and the latest version of this standard in 2.0. A SAML message is having three important sections named Authentication statement, Authorization decision statement and Attribute statement.
- Authentication statements assert to the service provider that the principal did indeed authenticate with the identity provider at a particular time using a particular method of authentication.
Authorization decision statement asserts that a subject is permitted to perform action.
Attribute statement asserts that a subject is associated with certain attributes. An attribute is simply a name-value pair. Relying parties use attributes to make access control decisions
The SAML message is signed and sends across to the destination. By validating the signature of the message the target application decides whether the message is from a trusted source or not.
Posts
