Home > Articles > Software Development & Management

This chapter is from the book Introduction to SAML

Introduction to SAML

Security Assertion Markup Language (SAML) is derived from two previous security initiatives: Security Services Markup Language (S2ML) and Authorization Markup Language (AuthXML). SAML is an XML–based framework for exchanging security assertion information about subjects. Subjects are entities that have identity related information specific to a security domain. SAML plays a vital role in delivering standards-based infrastructure for enabling single sign-on without requiring the use of a single vendor’s security architecture. However, SAML does not provide the underlying user authentication mechanism.

The Motivation of SAML

SAML provides a standards-based approach to the enabling of SSO among heterogeneous applications and to the supporting of identity management. Before we had the SAML standard, developers had to enforce a centralized security infrastructure using proprietary security mechanisms for heterogeneous application systems. That solution was not cost-effective and created many interoperability issues among different vendor products. In the worst case, developers used client-side screen-scraping or a keystroke-recorder solution that could enable the user to sign on to different applications. These solutions store user credentials locally in either cleartext or a proprietary data format. This created interoperability issues and also opened up many security loopholes and risks for hackers on the client side. In addition, these solutions made it difficult to manage deployment and troubleshooting in multiple application integration scenarios.

Another proprietary approach is to encapsulate encrypted user credentials (also referred to as a security token) in the HTTP-POST header and pass the security token to different applications via a secure transport protocol such as SSL. Once a user authenticates with an SSO-enabled application, the client application uses the SSO security token in the HTTP-POST headers, which helps to redirect the user to the target resource or application to which it has privileged access. Each resource or application needs to build a proprietary agent to intercept the HTTP header for SSO security token. To many business corporations and their trading partners, the use of proprietary agents is intrusive to the infrastructure. Although this approach looks similar to many vendor-defined mechanisms, it provides the basis of the SAML specification for representing authentication and authorization credentials in a standard security-token format.

The Role of SAML in SSO

SAML provides an XML standards-based representation of security information that allows security information to be shared among application security domains over the network. Using HTTP-POST or SOAP message headers, SAML allows applications to participate in SSO scenarios. To support SSO, SAML introduces the notion of SAML Assertions, a part of XML messages that can be transferred between security providers and service providers. SAML Assertions contain statements that applications and service providers use to make authentication and authorization decisions.

In addition, SAML provides many benefits. These include the absence of duplication of security mechanisms and their associated directory information. SAML messages and their underlying XML-based interactions also ensure interoperability and the use of scalable remote authorization services to support multiple applications. SAML requires the user to enroll with at least one SAML-enabled security provider that will provide authentication services to the user. However, SAML does not define how authentication and authorization services should be implemented.

SAML is also designed to be used with other standards; the Liberty Alliance Project, the Shibboleth project, and the OASIS WS-Security standards have all adopted SAML as a technological underpinning to support identity management. A number of security vendors currently provide SAML-compliant security products. These vendors include Sun Microsystems, CA-Netegrity, RSA Security, Oracle-Oblix, Entrust, and so forth. OpenSAML [OpenSAML] and SourceID [SourceID] are open-source implementations. This is not an exhaustive list of SAML-compliant products. More examples of SAML-compliant products can be found at http://www.oasis-open.org/committees/download.php/11915/RSA2005-saml-interop-final.pdf.

SAML 1.0

SAML 1.0 was accepted as an OASIS standard in November 2002. It is endorsed by leading industry vendors for the support of single sign-on and interoperability among security infrastructures. SAML 1.0 addressed one key aspect of identity management: how identity information can be communicated from one domain to another.

SAML 1.1

OASIS released the SAML version 1.1 specification on September 2, 2003.

SAML 1.1 is similar to SAML 1.0 but adds support for “network identity,” defined by Liberty Alliance specifications [Liberty]. SAML 1.1 support for Liberty Alliance specifications allows exchanging user authentication and authorization information securely between Web sites within an organization or between organizations over the Internet by Web account linking and role-based federation. SAML 1.1 also introduced guidelines for the use of digital certificates that allow signing of SAML assertions.

There are also changes in the digital signature guidelines, such as the recommended use of exclusive canonical transformation. For details about the differences, see the SAML 1.1 [SAML11Diff ]. The specification did not address all of the problems in the single sign-on or identity management domain. For example, it did not provide a standard authentication protocol that supports a variety of authentication devices and methods. Although SAML provides a flexible structure for encapsulating user credentials, there is still a problem in integrating with a Kerberos-based security infrastructure such as Microsoft Windows Kerberos. SAML 2.0 currently includes a work item “Kerberos SAML Profiles” that addresses the integration requirement. This subject is discussed in the next section.

SAML 2.0

SAML 2.0 specifications were approved by OASIS as a standard in March 2005. SAML 1.1 defined the protocols for single sign-on, delegated administration, and simple policy management. Liberty’s Identity Federation Framework (ID-FF) 1.2 was provided to the SAML committee, and SAML 2.0 was the result of converging previous SAML versions with Liberty ID-FF and with Shibboleth. SAML 2.0 fills in the gaps left in SAML 1.1 by including global sign-out, session management, and extension of identity federation framework for opt-in account linking across Web sites (used by Liberty).

Among the additions in SAML 2.0, there are several interesting items:

  • Enhancement of SAML assertions and protocols in support of federated identity and global sign-out.
  • Creation of new SAML attribute profiles, including the X.500/LDAP attribute and XACML. These attribute profiles simply the configuration and deployment of systems that exchange attribute data.
  • Pseudonyms to provide a privacy-enabling “alias” for a global identifier to avoid collusion between service providers. SAML 2.0 uses an opaque pseudo-random identifier (with no discernible correspondence with meaning identifiers such as e-mail addresses) between service providers to represent principals.
  • With the use of pseudonyms, SAML 2.0 defines how two service providers can establish and manage these pseudonyms for the principals they are working with.
  • SAML meta-data specify how configuration and trust-related data can be more easily deployed in SAML systems. Identity providers and service providers often need to agree on data such as roles, identifiers, and supported profiles. SAML meta-data provides a structure for identifying the actors involved in the various profiles, such as single sign-on identity provider, attribute authority, and requester.
  • Better support of mobile and active devices by adding more authentication contexts that accommodate new authentication requirements, such as including smart card-based PKI and Kerberos.
  • Support of encryption for attribute statements, name identifiers, or entire assertion statements.
  • Support for privacy using privacy policy and settings that service providers can obtain and use to express a principal’s consent to particular operations.
  • Discovery of multiple identity providers, using a provider discovery profile that uses a cookie written in a common domain between the identity provider and service providers.
  • Use of an Authentication Request protocol (<AuthnRequest>), which enables an interoperable “destination-site-first” scenario. In other words, the <_AuthnRequest> protocol allows a user to approach a service provider first and then be directed to log in at the identity provider if the service provider deems it to be necessary.
  • Conformance requirements and interoperability details.

SAML 2.0 has some changes in the core specification as well. It has significant changes in scope, particularly with regard to extending the functionality and aligning itself with other related initiatives. Here are some examples of the functionalities:

  • Support for global logout and time-out (session support)
  • Discovery of SAML Web service through a WSDL file (meta-data exchange and protocol)
  • Exchange of name identifier and pseudonyms between sites (identity federation, or federated name registration protocol)
  • Multi-hop delegation and intermediaries (multi-participant transactional workflows)
  • Liberty authentication context exchange and control (authentication context)
  • Additional protocol binding for direct HTTP use (HTTP-based assertion referencing)
  • Coordinating with IETF Simple Authentication and Security Layer effort (SASL support)
  • Integrating and reconciling SAML 2.0 and XACML 2.0, including attribute usage, authorization decision requests and responses, and policy queries and responses.

In addition to the SAML assertion, SAML 2.0 introduces the following new message protocols: artifact protocol, federated name registration protocol, federation termination protocol, single logout protocol, and name identifier mapping protocol. [SAML2Core] has a full description of these new messaging protocols, which are not discussed here.

One new message protocol of interest is the logout request (specified by the <LogoutRequest> tag), which supports global logout. This new support means that if a principal (a user or a system entity) logs out as a session participant, then the session authority will issue a logout request to all session participants. The reason for the global logout can be “urn:oasis:names:tc:SAML:2.0:logout:user” (user decides to terminate the session), or “urn:oasis:names:tc:SAML:2.0:logout:admin” (administrator wishes to terminate the session, for example, due to timeout). These and other attributes will be discussed in later sections.

SAML Profiles

The SAML specification defines a standard mechanism for representation of security information. This mechanism allows security information to be shared by multiple applications so that they are able to address single sign-on requirements. The notion of a SAML profile addresses these core interoperability requirements. The SAML profile allows the protocols and assertions to facilitate the use of SAML for a specific application purpose. A SAML profile defines a set of rules and guidelines for how to embed SAML assertions into, and extract them from, a protocol or other context of use. Using a SAML profile, business applications would be able to exchange security information in SAML messages seamlessly and to easily interoperate between SAML-enabled systems.

SAML 2.0 defines the following SAML profiles:

  • Web browser SSO Profile: Single sign-on using standard browsers to multiple service providers. The Web browser SSO profile uses the SAML Authentication Request protocol, in conjunction with the HTTP Redirect, HTTP POST, and HTTP Artifact bindings. SAML 2.0 combines the previous two Web browser profiles from SAML 1.1 into one single profile.
  • Enhanced Client and Proxy Profile: This profile defines the rules for a system entity to contact the appropriate identity provider, possibly in a context-dependent fashion. It uses the Reverse SOAP (PAOS) binding.
  • Identity Provider Discovery Profile: This profile defines how a service provider discovers the identity provider used by the Principal.
  • Single Logout Profile: This profile defines how to terminate the sessions managed by the session authority (or identity provider).
  • Name Identifier Management Profile: This profile defines how to exchange a persistent identifier for a principal with the service providers and how to later modify changes in the format or value.
  • Artifact Resolution Profile: SAML 2.0 defines an Artifact Resolution protocol to dereference a SAML artifact into a corresponding protocol message. The HTTP Artifact binding can then leverage this Artifact Resolution protocol in order to pass SAML protocol messages by reference.
  • Assertion Query/Request Profile: This profile defines a protocol for requesting existing assertions by reference or by querying on the basis of a subject and additional statement-specific criteria.

In addition, the SAML profile also defines rules for mapping attributes expressed in SAML to another attribute representation system. This type of SAML profile is known as Attribute Profile. SAML 2.0 defines five different Attribute Profiles [SAML2Profiles].

  • Basic Profile: This profile defines simple string-based SAML attribute names.
  • X.500/LDAP Profile: This profile defines a common standardized convention for SAML attribute-naming using OIDs (Object Identifiers) expressed as URNs (Uniform Resource Names) and accompanied by using the type xsi:type.
  • UUID Profile: This profile defines SAML attribute names as UUIDs (Universal Unique Identifiers) expressed as URNs.
  • DCE PAC Profile: This profile defines how to represent DCE realm, principal, and primary group, local group, and foreign group membership information in SAML attributes.
  • XACML Profile: This profile defines how to map SAML attributes cleanly to XACML attribute representations.

To support Web services and usage of SAML tokens in Web services communication, the OASIS WS-Security TC developed a SAML Token profile. The SAML Token profile defines the rules and guidelines for using SAML assertions in Web services communication. OASIS also ratified SAML Token profile 1.0 as an approved standard. Refer to Chapter 6, “Web Services Security–Standards and Technologies,” for information about the role of SAML token profiles and how to use them in WS-Security.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020