|
FAQ
[Up to date as of 29-Jan-2006.]
This document helps to answer frequently asked questions about the Security Assertion Markup Language (SAML) OASIS Standard. If you have a question that is not answered here, or if you have questions or comments on any of the answers provided, feel free to contact the editor.
Many of the answers provided here are excerpted from the SAML V2.0 Executive Overview http://www.oasis-open.org/committees/download.php/11785/sstc-saml-exec-overview-2.0-draft-06.pdf.
For more information, be sure to see that document, as well as the SAML V2.0 Technical Overview http://www.oasis-open.org/committees/download.php/11511/sstc-saml-tech-overview-2.0-draft-03.pdf.
Note that these documents are not yet finalized as of this writing.
What is SAML?
Federation is the dominant movement in identity management today.
Federation refers to the establishment of some or all of business agreements, cryptographic trust, and user identifiers or attributes across security and policy domains to enable more seamless cross-domain business interactions. As Web services promise to enable integration between business partners through loose coupling at the application and messaging layer, federation does so at the identity management layer - insulating each domain from the details of the others' authentication and authorization infrastructure.
Key to this loose coupling at the identity management layer are standardized mechanisms and formats for the communication of identity information between the domains - the standard provides the insulating buffer. SAML defines just such a standard.
SAML is an XML-based framework for communicating user authentication, entitlement, and attribute information. As its name suggests, SAML allows 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.
The OASIS Security Services Technical Committee is in charge of defining, enhancing, and maintaining the specifications that define SAML. You can visit the TC's public home page here http://www.oasis-open.org/committees/security/, and see its charter here http://www.oasis-open.org/committees/security/charter.php
Prior to SAML, there was no XML-based standard that enabled exchange of security information between a security system (such as an authentication authority) and an application that trusts the security system. SAML provides a standard XML representation for specifying this information and interoperable ways to exchange and obtain it.
SAML is a flexible and extensible standard 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) Technical Committee have all adopted SAML as a technological underpinning for various purposes.
In practical terms, SAML consists of a set of specifications and XML schemas, which together define how to construct, exchange, consume, interpret, and extend security assertions for a variety of purposes. The defining documents for the latest SAML V2.0 OASIS Standard, can be found in a zip file here http://www.oasis-open.org/committees/download.php/11902/saml-2.0-os.zip.
In addition to this FAQ, non-normative executive and technical overviews (both in draft form as of this writing) are also available.
Additional resources for developers and others may be made available over time, and the OASIS Security Services TC invites input to the editor as to what information would be most helpful.
What is federated identity?
Federated identity allows a set of service providers to agree on a way to refer to a single user, even if that user is known to the providers in different guises. Most commonly, federated identity is achieved through the linking together of the user's several accounts with the providers. This allows the user to get more personalized service without centrally storing personal information. Also, it gives the user fine control over when and how their accounts and attributes are linked and shared, allowing for greater control over their personal data. In practice, this means that users can be authenticated by one company or web site and be recognized and delivered personalized content and services in other locations without having to re-authenticate or sign on with a separate username and password.
See the SAML V2.0 glossary for formal definitions of terms used in the SAML specifications.
What is SAML's history and background? What is in SAML's future?
The original SAML work used two earlier efforts, S2ML and AuthXML, as input. (The V1.0 effort's requirements and use cases document may be of historical interest.) The OASIS Security Services TC was launched in January 2001, and SAML V1.0 was approved as an OASIS Standard in November 2002. The major goals of this version were to enable single sign-on for web users and to allow for the exchange of authentication and authorization information in a variety of kinds of distributed transaction. The design reflected a balance of three goals: providing capabilities that make adoption attractive, maximizing interoperability by identifying clear mechanisms for extension, and moving quickly to produce a standard solution.
Approval of SAML V1.1 followed in September 2003. This version focused on improving interoperability and specification clarity through experience with Version 1.0, and in particular on tightening up the relationship of SAML with XML Signature. The nature of these changes resulted in certain backward compatibility issues for SAML V1.0 and V1.1, so in general, these two versions are considered to be incompatible when different versions of SAML are configured between partners. Products have been introduced to the market that support both SAML V1.0 and V1.1, although they typically require any specific configuration of any two cooperating partners to use the same version of SAML. As in any situation, if you are making a decision about which version to deploy, you should check on product compatibility among your identity federation partners and ensure that any deployment/configuration agreements specify the correct version.
SAML V1.x has seen significant success, gaining momentum in financial services, higher education, government, and other industry segments. SAML support has been broadly implemented by all major Web access management vendors. It is also supported in major application server products and SAML support is also common among Web services management and security vendors.
SAML V2.0, approved as an OASIS Standard in March 2005, builds on this success by unifying the building blocks of federated identity in SAML V1.1 with input from both the Shibboleth initiative (one of whose major architects also served as a SAML designer) and the Liberty Alliance's Identity Federation Framework (which was contributed to the OASIS Security Services TC for consideration). As such, SAML V2.0 is a critical step towards full convergence for federated identity standards. This version also took the opportunity to address issues that arose from experience with previous versions, and it added support for features that had been deferred for schedule reasons.
With V2.0 finished, the OASIS Security Services TC is currently turning its attention to profiles that have been developed by others and submitted for consideration and future parts of the SAML standard.
What are the advantages of SAML?
SAML benefits a diverse group. It allows security systems and application software to be developed and evolve independently. This is because SAML provides a set of interoperable standard interfaces. Standardizing the interfaces between systems allows for faster, cheaper, and more reliable integration. As more profiles of SAML usage are developed, these benefits will be opened up to more and different kinds of access management.
Producers of security software benefit by having standard schemas and protocols for expressing security information. Application developers benefit by decoupling their software from the underlying security infrastructure. Finally, end users benefit because SAML promotes single sign-on (the ability to use a variety of Internet resources without having to log in repeatedly) and a more personalized user experience that can nonetheless be made privacy-friendly.
Following are some more concrete benefits of SAML:
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 than that of a service provider.
How is SAML being used?
As befits a general framework for communicating security and identity information, SAML is being applied in a number of different ways, some of which are presented here.
Web SSO: 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 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.
Attribute-based authorization: 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 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 (ID-WSF) also uses SAML assertions as the base security token for enabling secure and privacy-respecting access to web services.
What are the components of SAML?
SAML is defined in terms of assertions, protocols, bindings, and profiles.
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, attribute, and authorization decision.
SAML defines a number of request/response protocols that allow service providers to, for example, request or query for an assertion; ask for a subject to be authenticated, create and manage name identifier mappings (for federating identities through account linking); and request a near-simultaneous logout of a collection of related sessions ("single logout").
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.
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 assertions.
What's new in SAML V2.0?
SAML V2.0 introduces a number of new features, including:
- Pseudonyms (a key privacy-enabling technology)
- Identifier management (for managing pseudonyms)
- Metadata (for expressing configuration and trust-related data to make deployment of SAML systems easier)
- Encryption (so that attribute statements, name identifiers, or entire assertions can be encrypted in place)
- Attribute profiles
- Session management (for single logout)
- Mobile device support (to better address their challenges and opportunities)
- Identity provider discovery (for deployments having more than one identity provider)
See the Executive Overview or Technical Overview for more explanation of these features.
How does SAML relate to the Liberty Alliance?
The Liberty Alliance is an industry consortium defining standards for federated identity - including enabling simplified sign-on through federated network identification using current and emerging network access devices, as well as supporting and promoteing permission-based attribute sharing to enable a user's choice and control over the use and disclosure of his/her personal identification.
Liberty had defined its Identity Federation Framework (ID-FF) on the base provided by SAML V1.x, layering additional functionality on top. Recognizing the value of a single standard for federated SSO, the Alliance submitted ID-FF V1.2 back into the OASIS Security Services Technical Committee as input for SAML V2.0 and is already working to base its work on the new technical base formed by the SAML V2.0 OASIS Standard.
Liberty's Identity Web Services Framework (ID-WSF), a platform for securing identity-based Web services, continues to evolve within the Liberty Alliance. Liberty ID-WSF uses SAML assertions as the security token format by which the authentication and authorization information associated with the various web service actors are communicated amongst them.
How does SAML relate to Internet2 and Shibboleth?
Shibboleth is a project within the Internet2 higher-education consortium to develop technical and policy frameworks and an open software system for the sharing of online resources among researchers, professors, and students. Like Liberty, Shibboleth profiled SAML for its particular requirements and, also like Liberty, built privacy management into its architecture. Shibboleth's input has been fed back into SAML V2.0, and new work at Shibboleth is anticipated to be built on the SAML V2.0 OASIS Standard.
How does SAML relate to other standards and initiatives?
SAML is used by several other standards groups to provide a security and identity underpinning for their work.
XACML (eXtensible Access Control Markup Language) is an OASIS Standard, an XML-based language for access control that has been standardized in OASIS. XACML describes both an access control policy language and a request/response language. The policy language is used to express access control policies ('who can do what when'). The request/response language expresses queries about whether a particular access should be allowed (requests) and describes answers to those queries (responses). The newest versions of XACML and SAML have been designed to complement each other; for example, an XACML policy can specify what a provider should do when it receives a SAML assertion, and XACML-based attributes can be expressed in SAML.
WS-Security is an OASIS Standard that specifies how SOAP messages can have their integrity and confidentiality ensured. WS-Security defines a framework for securing SOAP messages, with the specifics being defined in profiles determined by the nature of the security token used to carry identity information. So, for instance, there are different profiles of WS-Security for various different security token formats such as X.509 certificates and Kerberos tickets. As already noted in the Securing Web Services section above, there is also a SAML token profile of WS-Security that specifies how SAML assertions can be used to provide message security.
Additionally, SAML itself points to WS-Security as an approved mechanism for securing SOAP messages carrying SAML protocol messages and assertions.
|
