!!! Overview
[Security Assertion Markup Language] or (SAML) was developed by the Security Services Technical Committee of the [Organization for the Advancement of Structured Information Standards] ([OASIS]), is an [XML]-based framework for communicating [user|digital Identity] [authentication], [entitlement|privilege], and [attribute] information.

[{$pagename}]s most common implementations allow business entities to make [assertions|Claim] regarding the [identity|digital Identity], [attributes], and [entitlements|privilege] of a [subject|digital Identity] (an [entity] that is often a human user) to other entities, such as a partner company or another enterprise application.[1]

[{$pagename}] is a flexible and extensible protocol designed to be used – and customized if necessary – by other by other standards. The [Liberty Alliance], the Internet2 Shibboleth project, and the [OASIS][ Web Services Security] ([WS-Security]) committee have all adopted [{$pagename}] as a technological underpinning for various purposes.

When you need the real technical details of the how [{$pagename}] works you should refer to the [OASIS] documentation. However, if you need to learn and understand [{$pagename}], do not even go there. The [{$pagename}] core, is an conceptual abstract framework without a context and most people will only become confused.

!! What Are the Components of SAML?
There are three [Entities] involved in a  transaction:
* an [Identity Provider (IDP)] - the asserting party
* a [service provider|SP] - the [Relying Party] relying on the assertion
* a [subject|Digital Identity] of the assertion.

SAML operations defined in terms of:
* [SAML Assertions]
* [SAML Protocols]
* [SAML Bindings]
* [SAML Profiles]

!! Why would you implement [{$pagename}]?
The benefits of SAML include:
* Platform neutrality – [{$pagename}] 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 – [{$pagename}] does not require user information to be maintained and synchronized between directories.
* Improved online experience for end users – [{$pagename}] enables [WEB Single Sign-On] by allowing users to authenticate at an [identity Provider (IDP)] and then access [service providers|SP] without additional authentication. In addition, identity federation (linking of multiple identities) with [{$pagename}] allows for a better-customized user experience at each service while promoting [privacy].
* Reduced administrative costs for [service providers|SP] - Using [{$pagename}] 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 (IDP)].
* Risk transference – [{$pagename}] can act to push responsibility for proper management of identities to the [Identity Provider (IDP)], which is more often compatible with its business model than that of a [service provider|SP].

!!! Common Implementations of SAML
As befits a general framework for communicating security and identity information, SAML is being applied in a number of different ways, the major ones of which are presented here.

!! [WEB Single Sign-On]
In [WEB Single Sign-On], 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 Single Sign-On] 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.

[{$pagename}] supports both [IDP-Initiated SSO-POST] and [SP-Initiated SSO-POST-POST] 

!! Attribute-Based Authorization
Similar to the [WEB Single Sign-On] scenario, the attribute based authorization model has one web site communicating 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, or should not be shared (for privacy reasons), or is insufficient on its own.

!! Securing Web Services
[SAML Assertions] can be and are used within [SOAP] messages in order to carry security and identity information between actors in web service transactions. The [{$pagename}] Token Profile of the [OASIS] [WS-Security] TC specifies how [SAML Assertions] should be used for this purpose. The [Liberty Alliance]'s Identity Web Service Framework (IDWSF) also uses [SAML Assertions] as the base security token for enabling secure and privacy respecting access to web services.

!!! SAML Summary
A [Federated Identity] is one that is both portable and potable, that is, it can be transported and consumed across autonomous domains or business boundaries. Effective identity federation benefits both users and enterprises - providing principals with a smooth, cross-domain browsing experience through SSO and allowing enterprises to make available its resources to a class of users without the associated administrative costs.

SAML has emerged as the gold standard for federated identity. By defining standardized mechanisms for the communication of security and identity information between business partners, SAML makes federated identity, and the cross-domain transactions that it enables, a reality.

Importantly, with [SAML V2.0], the industry has taken a key step towards convergence in the [Federated Identity Management] standards space.

!! Abstract Framework
It is important to realize that the SAML Assertions & Protocols specification, called the SAML Core, is conceptually "abstract". It defines the bits and pieces that make up SAML Assertions, and their nominal semantics, but does not define how to actually put them to use in any particular context. That, as we've said, is left to [SAML Profiles], of which there can be many.

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] [SAML Executive Overview|http://www.google.com/url?sa=t&source=web&ct=res&cd=1&ved=0CAsQFjAA&url=http%3A%2F%2Fwww.oasis-open.org%2Fcommittees%2Fdownload.php%2F11785%2Fsstc-saml-exec-overview-2.0-draft-06.pdf&ei=irpeS8vjKYa0tgfR8fypAg&usg=AFQjCNHjwWYMZ2jmNBEb9CLkt2dkBxOljw&sig2=R15P3yjTvb6LmY6F6C_hDw|target='_blank']