Before jumping into practical implementation of SSO, lets know the basics of SAML.
Security Assertion Markup Language (SAML) is an XML based framework developed by the Organization for the Advancement of Structured Information Standards (OASIS), used for the exchange of security information between different parties. This is an open standard that can be used to exchange security information between different products.
# SAML V1.0 became an OASIS standard in November 2002. SAML V1.1
# In September 2003 and has seen significant success, gaining momentum in financial services, higher
education, government, and other industry segments.
# In 2005, SAML V2.0 unifies the building blocks of federated identity in SAML V1.1 with input from higher
The benefits of SAML include:
• Platform neutrality
SAML abstracts the security framework away from platform architectures and particular vendor implementations. Making security more independent of application logic is an important tenet of Service-Oriented Architecture.
• Loose coupling of directories
SAML does not require user information to be maintained and synchronized between directories.
• Improved online experience for end users
SAML enables single sign-on by allowing users to authenticate at an identity provider and then access service providers without additional authentication. In addition, identity federation (linking of multiple identities) with SAML allows for a better-customized user experience at
each service while promoting privacy.
• Reduced administrative costs for service providers
Using SAML to "reuse" a single act of authentication (such as logging in with a username and password) multiple times across multiple services can reduce the cost of maintaining account information. This burden is
transferred to the identity provider.
• Risk transference
SAML can act to push responsibility for proper management of identities to the identity provider, which is more often compatible with its business model thanthat of a service provider.
Where SAML will be used?
Web single sign on
In web SSO, a user authenticates to one web site and then, without additional authentication, is able to access some personalized or customized resources at another site. SAML enables web SSO through the communication of an authentication assertion from the first site to the second which, if confident of the origin of the assertion, can choose to log in the user as if they had authenticated directly.
Similar to the Web SSO scenario, the attribute based authorization model has one web site communicating identity information about a subject to another web site in support of some transaction. However, the identity information may be some characteristic of the subject (such as a person's role in a B2B scenario) rather than, or in addition to, information about when and how the person was authenticated. The attribute-based authorization model is important when the individual's particular identity is either not important, should not be shared for privacy reasons, or is insufficient on its own.
Securing Web Services
SAML assertions can be used within SOAP messages in order to convey security and identity information between actors in web service interactions. The SAML Token Profile produced by the OASIS Web Services Security (WSS) TC specifies how SAML assertions should be used for this purpose with the WS-Security framework. The Liberty Alliance's Identity Web Service Framework (ID-WSF) builds on these specifications to use SAML assertions for enabling secure and privacy respecting access to web services.
An assertion is a package of information that supplies one or more statements made by a SAML authority. SAML defines three different kinds of assertion statement that can be created by a SAML authority.
• Authentication: The specified subject was authenticated by a particular means at a particular time. This kind of statement is typically generated by a SAML authority called an identity provider, which is in charge of authenticating users and keeping track of other information about them.
• Attribute: The specified subject is associated with the supplied attributes.
• Authorization Decision / Entitlement Info: A request to allow the specified subject to access the specified resource has been granted or denied.
SAML defines a number of request/response protocols that allow service providers to:
• Request from a SAML authority one or more assertions (includes a direct request of the desired assertions, as well as querying for assertions that meet particular criteria)
• Request that an identity provider authenticate a principal and return the corresponding assertion
• Request that a name identifier be registered
• Request that the use of an identifier be terminated
• Retrieve a protocol message that has been requested by means of an artifact
• Request a near-simultaneous logout of a collection of related sessions (“single logout”)
• Request a name identifier mapping
Mappings from SAML request-response message exchanges into standard messaging or communication protocols are called SAML protocol bindings. For instance, the SAML SOAP Binding defines how SAML protocol messages can be communicated within SOAP messages, whilst the HTTP Redirect binding defines how to pass protocol messages through HTTP redirection.
Generally, a profile of SAML defines constraints and/or extensions in support of the usage of SAML for a particular application, the goal being to enhance interoperability by removing some of the flexibility inevitable in a general-use standard. For instance, the Web Browser SSO Profile specifies how SAML authentication assertions are communicated between an identity provider and service provider to enable single sign-on for a browser user.
The Web SSO Profile details how to use the SAML Authentication Request/Response protocol in conjunction with different combinations of the HTTP Redirect, HTTP POST, HTTP Artifact, and SOAP bindings.
Another type of SAML profile is an attribute profile. SAML defines a series of attribute profiles to provide specific rules for interpretation of attributes in SAML attribute assertions. An example is the X.500/LDAP profile, describing how to carry X.500/LDAP attributes within SAML attribute.
In next posts, lets see the practical implementation of SSO and how to use SAML 2.0.
Is it helpful for you? Kindly let me know your comments / Questions.