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 authentication, entitlement, and attribute information.
SAMLs most common implementations allow business entities to make assertions regarding the identity, attributes, and entitlements of a subject (an entity that is often a human user) to other entities, such as a partner company or another enterprise application.
SAML 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 SAML as a technological underpinning for various purposes.
When you need the real technical details of the how SAML works you should refer to the OASIS documentation. However, if you need to learn and understand SAML, do not even go there. The SAML 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 - the Relying Party relying on the assertion
- a subject of the assertion.
SAML operations defined in terms of:
Why would you implement SAML?#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 WEB Single Sign-On by allowing users to authenticate at an identity Provider (IDP) 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 (IDP).
- Risk transference – SAML 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.
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, 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.
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 SAML 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.
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:
- API Service Delivery
- AWS Cognito
- Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants
- Authentication Context Class
- Authentication Protocol
- Bob Blakley
- Common Domain for Identity Provider Discovery
- Digital Identity
- FAL 1
- FAL 2
- Federated Identity
- Federation Assurance Level
- Glossary Of LDAP And Directory Terminology
- Gluu Server
- IDP Metadata
- Identity Federation Framework
- Identity Web Services Framework
- JSON Identity Suite
- Liberty Alliance
- Logging Out
- Neo-Security Stack
- OAuth 2.0 Token Exchange Request
- Open Trust Taxonomy for OAuth2
- OpenID Connect Federation
- Privilege Management Infrastructure
- Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)
- Relying Party
- SAML Assertions
- SAML Attribute Statement
- SAML Bindings
- SAML Protocols
- SAML Web Browser Profiles
- SCIM Use Cases
- SP Metadata
- Security Assertion Markup Language
- Security Token Service
- Service Provider
- Single Logout
- Single Logout Profile
- Single Sign-On Scenarios
- Standards Based SSO
- Token Binding over HTTP
- Token Type Identifiers
- Web Blog_blogentry_030117_1
- Web Blog_blogentry_170617_1
- Web Blog_blogentry_231215_1
- Web Blog_blogentry_250816_1
- Web Blog_blogentry_260715_1
- Web Service Security Specifications
- Web Services Federation
- Why OAuth 2.0
- Why OpenID Connect