What is SAML?

SAML (Security Assertion Markup Language) is an open source XML framework that enables the exchange of au­then­ti­ca­tion and au­tho­riza­tion in­for­ma­tion. The in­di­vid­ual SAML com­po­nents, which include a central user database and six different protocols, provide all relevant functions for de­scrib­ing and trans­fer­ring security features - which is why SAML is con­sid­ered an excellent complete solution for federated identity man­age­ment (FIM).

Security assertion markup language, or SAML for short, is an open-source XML-based framework for ex­chang­ing au­then­ti­ca­tion and au­tho­riza­tion in­for­ma­tion. It was developed in 2001 by the security services technical committee of the OASIS con­sor­tium (orga­ni­za­tion for the advance­ment of structured infor­ma­tion standards) and published in a first version (SAML v1.0) in November 2002. The project team has made various adap­ta­tions, which can be found in the revisions called SAML 2.0 and 2.1 (also 1.1). SAML contains several com­po­nents that provide functions for de­scrib­ing and trans­mit­ting safety-related in­for­ma­tion. SAML is the optimal basis for federated identity man­age­ment (FIM).

SAML can be used to make state­ments about the prop­er­ties and au­tho­riza­tions of a user for other users or partner companies, but es­pe­cial­ly for ap­pli­ca­tions (ap­pli­ca­tions are also referred to as “service providers” in SAML). For this purpose, the so-called identity provider (central user database), which stores cor­re­spond­ing user in­for­ma­tion, uses as­ser­tions in an XML format. Other com­po­nents of SAML-based ver­i­fi­ca­tion are six different protocols, as well as bindings and profiles.

A SAML assertion can contain one or more state­ments about the char­ac­ter­is­tics (identity, at­trib­ut­es) of a user, as well as their au­tho­riza­tions. This assertion is created by the re­spec­tive identity provider, i.e. the re­spon­si­ble user database, using XML as the markup language. Every assertion also receives a digital signature, which must be verified by the accessing a service provider. This guar­an­tees the integrity and au­then­tic­i­ty of the assertion, which is also called a SAML token in its signed form. After suc­cess­ful ver­i­fi­ca­tion, the service provider analyzes the actual content, and then makes a decision on what kind of access is granted to the user.

The following three types of state­ments in SAML as­ser­tions are specified in SAML 2.0:

• Au­then­ti­ca­tion state­ments: The identity provider informs the ap­pli­ca­tion that the user has been au­then­ti­cat­ed using au­then­ti­ca­tion state­ments. This type of statement also provides in­for­ma­tion in an assertion about when the au­then­ti­ca­tion took place and which method was used.
• Attribute state­ments: Attribute state­ments are at­trib­ut­es that are linked to the re­spec­tive user, and can be com­mu­ni­cat­ed to the ap­pli­ca­tion using the cor­re­spond­ing SAML token.
• Au­tho­riza­tion decision state­ments: When au­tho­riza­tion decision state­ments are included in a SAML assertion, the user has either been granted access to specific resources or denied access to specific resources.

The SAML 2.0 spec­i­fi­ca­tion defines a set of query/response protocols that allow the ap­pli­ca­tion to request or query an assertion, or request a user to au­then­ti­cate. These are the following protocols:

• Au­then­ti­ca­tion request protocol: The au­then­ti­ca­tion request protocol defines messages of type <Au­th­n­Re­quest> that are required to query as­ser­tions with au­then­ti­ca­tion state­ments for a selected user. Based on this protocol, the in­for­ma­tion is trans­ferred from the database to the service provider, usually using a “SAML 2.0 Web Browser SSO Profile” (more on this in the “profiles” section).
   
• Assertion query and request protocol: For queries that can be used to retrieve existing SAML as­ser­tions in general, the framework contains the assertion query and request protocol. The as­ser­tions can be queried on the basis of various pa­ra­me­ters such as the statement types contained.
   
• Single logout protocol: The single logout protocol defines queries that initiate an almost si­mul­ta­ne­ous logout from all active sessions of a user. These kinds of messages can be sent by the user, identity provider, or service provider. The latter is par­tic­u­lar­ly con­ceiv­able when a user session has expired.
   
• Artifact res­o­lu­tion protocol: If SAML messages are to be trans­port­ed sep­a­rate­ly over a secure channel or in a resource-saving size, the artifact res­o­lu­tion protocol is used. It allows you to send ref­er­ences to as­ser­tions, also called artifacts, which are much smaller than the actual message. The log also allows you to resolve these ref­er­ences to receive the original message.
   
• Name iden­ti­fi­er man­age­ment protocol: This protocol provides means to change the name value or format of a user identity. The request can be written by either the service provider or the identity provider. You can also use the name iden­ti­fi­er man­age­ment protocol to remove links between service and identity providers that were created to au­then­ti­cate the original user identity.
   
• Name iden­ti­fi­er mapping protocol: The name iden­ti­fi­er mapping protocol defines query and response messages for com­mu­ni­ca­tion between two service providers. Based on this message type, an ap­pli­ca­tion can query an identity provider iden­ti­fi­er for a user to access another ap­pli­ca­tion.

Mappings of SAML messages into standard messaging or com­mu­ni­ca­tion protocols are called “SAML protocol bindings,” or simply “bindings.” For example, SOAP binding defines how SAML messages can be exchanged within SOAP en­vi­ron­ments, while HTTP redirect binding defines how SAML protocol messages can be trans­port­ed using HTTP for­ward­ing. Other bindings which are already pre­de­fined in SAML 2.0:

• Reverse SOAP binding
• HTTP POST binding
• HTTP artifact binding
• SAML URI binding

Generally speaking, SAML is char­ac­ter­ized by its flex­i­bil­i­ty, which means that the framework can be used for many different purposes. However, for certain ap­pli­ca­tions to support SAML, this flex­i­bil­i­ty must be partially re­strict­ed. For this to work, so-called profiles are used, which bundle selected SAML as­ser­tions, protocols, and bindings for specific ap­pli­ca­tions. One of the most commonly used profiles is the “SAML 2.0 web browser” SSO profile, which specifies the framework for using SAML SSO au­then­ti­ca­tion. It contains all the essential com­po­nents for defining the com­mu­ni­ca­tion of SAML au­then­ti­ca­tion re­quire­ments between identity and service providers. The framework also provides the following ad­di­tion­al profiles:

• Enhanced client and proxy (ECP) profiles
• Identity provider discovery profile
• Single logout profiles
• Name iden­ti­fi­er man­age­ment profile
• Artifact res­o­lu­tion profile
• Assertion query/request profile
• Name iden­ti­fi­er mapping profile

More than 24 companies and or­ga­ni­za­tions were involved in the de­vel­op­ment of SAML 2.0 before it was released in March 2005 as the official successor of SAML 1.0 and 1.1. In addition to numerous im­prove­ments of existing features, the framework also had com­plete­ly new features, which are derived from the liberty alliance identity fed­er­a­tion framework (ID-FF) 1.2 and from the shib­bo­leth ar­chi­tec­ture.

Here’s a list of the most important changes made to the framework in the second major release:

• Removal of some obsolete elements such as <Au­thor­i­ty­Bind­ing> or <Re­spond­With>
• Im­ple­men­ta­tion of XML signature and XML en­cryp­tion (according to W3C)
• Re­place­ment of the As­ser­tion­ID attribute with a general XML ID attribute
• In­tro­duc­tion of session man­age­ment to support automatic log-offs from all ap­pli­ca­tions (e.g. during long absences)
• Adap­ta­tion of the metadata to simplify the use of SAML (e.g. the identity provider and the service provider are now also marked in the metadata)
• The use of mech­a­nisms that allow providers to com­mu­ni­cate privacy policies and settings
• Improved support for mobile devices
• Im­ple­men­ta­tion of the logs already listed (only the assertion query and request protocol existed in SAML 1.0 and 1.1)
• Profile op­ti­miza­tion (e.g. merging the “browser/artifact” and “browser/post” profiles in the “SAML 2.0 web browser SSO profile”)

A detailed list of the dif­fer­ences between SAML 2.0 and SAML 1.1 can be found on the SAML community page saml.xml.org.

The field of ap­pli­ca­tion of the SAML framework is quickly defined: With the ap­pro­pri­ate know-how, a central au­then­ti­ca­tion instance can be im­ple­ment­ed on the basis of the markup language, which is char­ac­ter­ized by ef­fi­cien­cy and a high security standard. In par­tic­u­lar, the latter is due to the fact that the in­di­vid­ual ap­pli­ca­tions do not have to store or syn­chro­nize any user data, which sig­nif­i­cant­ly minimizes the number of possible security leaks. The main focus of the framework is to combine this high level of security with the best possible level of user-friend­li­ness, which is why it also supports the single sign-on already mentioned several times thanks to ap­pro­pri­ate protocols and message formats.

The SAML SSO procedure, which enables the use of different ap­pli­ca­tions on the basis of a single log-on, is not only used for internal company ap­pli­ca­tion processes. It is also used for various web services – es­pe­cial­ly in online banking and mobile apps. As a customer, you’ll notice that you’re dealing with several different ap­pli­ca­tions when using these kinds of services. For example, if you log on to your bank’s website once, you’ll most likely access more than one back end system. Thanks to SAML tech­nol­o­gy, however, it’ll seem as if you’re just on one program.