Technical Overview
TC members should send commentson this specification to the TC’s email list. Others shouldsend comments to the TC by using the “Send A Comment”button on the TC’s web page at.
For information on whether anypatents have been disclosed that may be essential to implementingthis specification, and any offers of patent licensing terms, pleaserefer to the Intellectual Property Rights section of the SecurityServices TC web page(http://www.oasis-open.org/committees/security/ipr.php).
sstc-saml-metadata-ext-query-cd-01.
Shibboleth Overview and Requirements.Shibboleth project of Internet2. See
[XMLEnc]D.Eastlake et al.XMLEncryption Syntax and Processing.World Wide Web Consortium. See
The OASIS Security Assertion Markup Language(SAML) standard defines an XML-based framework for describing andexchanging security information between on-line business partners.This security information is expressed in the form of portable SAMLassertions that applications working across security domainboundaries can trust. The OASIS SAML standard defines precise syntaxand rules for requesting, creating, communicating, and using theseSAML assertions.
The OASIS Security Services Technical Committee(SSTC) develops and maintains the SAML standard. The SSTC hasproduced this technical overview to assist those wanting to know moreabout SAML by explaining the business use cases it addresses, thehigh-level technical components that make up a SAML deployment,details of message exchanges for common use cases, and where to gofor additional information.
Why is SAML needed for exchanging securityinformation? There are several drivers behind the adoption of theSAML standard, including:
Single Sign-On:Over the years, various products have been marketed with the claimof providing support for web-based SSO. These products havetypically relied on browser cookies to maintain user authenticationstate information so that re-authentication is not required eachtime the web user accesses the system. However, since browsercookies are never transmitted between DNS domains, theauthentication state information in the cookies from one domain isnever available to another domain. Therefore, these products havetypically supported multi-domain SSO (MDSSO) through the use ofproprietary mechanisms to pass the authentication state informationbetween the domains. While the use of a single vendor's product maysometimes be viable within a single enterprise, business partnersusually have heterogeneous environments that make the use ofproprietary protocols impractical for MDSSO. SAML solves the MDSSOproblem by providing a standard vendor-independent grammar andprotocol for transferring information about a user from one webserver to another independent of the server DNS domains.
Federated identity: Whenonline services wish to establish a collaborative applicationenvironment for their mutual users, not only must the systems beable to understand the protocol syntax and semantics involved in theexchange of information; they must also have a common understandingof who the user is that is referred to in the exchange. Users oftenhave individual local user identities within the security domains ofeach partner with which they interact. Identity federation providesa means for these partner services to agree on and establish acommon, shared name identifier to refer to the user in order toshare information about the user across the organizationalboundaries. The user is said to have afederated identitywhen partners have established such an agreement on how to refer tothe user. From an administrative perspective, this type of sharingcan help reduce identity management costs as multiple services donot need to independently collect and maintain identity-related data(e.g. passwords, identity attributes). In addition, administratorsof these services usually do not have to manually establish andmaintain the shared identifiers; rather control for this can residewith the user.
Web services and other industrystandards: SAML allows for its security assertion format tobe used outside of a “native” SAML-based protocolcontext. This modularity has proved useful to other industryefforts addressing authorization services (IETF, OASIS), identityframeworks, web services (OASIS, Liberty Alliance), etc. The OASISWS-Security Technical Committee has defined aprofilefor how to use SAML's rich assertion constructs within aWS-Securitysecurity token that can be used, forexample, to secure web service SOAP message exchanges. Inparticular, the advantage offered by the use of a SAML assertion isthat it provides a standards-based approach to the exchange ofinformation, including attributes, that are not easily conveyedusing other WS-Security token formats.
The OASIS SSTC has produced numerous documentsrelated to SAML V2.0. This includes documents that make up theofficial OASIS standard itself, outreach material intended to helpthe public better understand SAML, and several extensions to SAML tofacilitate its use in specific environments or to integrate it withother technologies.
The documents thatdefine and support the SAML OASIS Standard are shown in Figure 1.The lighter-colored boxes represent non-normative information.
Conformance Requirementsdocuments the technical requirements for SAML conformance, a statusthat software vendors typically care about because it is one measureof cross-product compatibility. If you need to make a formalreference to SAML V2.0 from another document, you simply need topoint to this one.
Assertions and Protocoldefines the syntax and semantics for creating XML-encoded assertionsto describe authentication, attribute, and authorizationinformation, and for the protocol messages to carry this informationbetween systems. It has associated schemas, one for assertions andone for protocols.
Bindings defines howSAML assertions and request-response protocol messages can beexchanged between systems using common underlying communicationprotocols and frameworks.
Profiles definesspecific sets of rules for using and restricting SAML's rich andflexible syntax for conveying security information to solve specificbusiness problems (for example, to perform a web SSO exchange). Ithas several associated small schemas covering syntax aspects ofattribute profiles.
Metadata defines how aSAML entity can describe its configuration data (e.g. serviceendpoint URLs, key material for verifying signatures) in a standardway for consumption by partner entities. It has an associatedschema.
Authentication Contextdefines a syntax for describing authentication context declarationswhich describe various authentication mechanisms. It has anassociated set of schemas.
Executive Overviewprovides a brief executive-level overview of SAML and its primarybenefits. This is a non-normative document.
Technical Overview is thedocument you are reading.
Glossary normativelydefines terms used throughout the SAML specifications. Wherepossible, terms are aligned with those defined in other securityglossaries.
Errata clarifies interpretation of the SAML V2.0 standard whereinformation in the final published version was conflicting orunclear. Although the advice offered in this document isnon-normative, it is useful as a guide to the likely interpretationsused by implementors of SAML-conforming software, and is likely tobe incorporated in any future revision to the standard. Thisdocument is updated on an ongoing basis.
Security and Privacy Considerations describes and analyzes the security and privacyproperties of SAML.
Following the release of the SAML OASIS Standard, the OASISSSTC has continued work on several enhancements. As of this writing,the documents for the following enhancements have been approved asOASIS Committee Draft specifications and are available from the OASISSSTC web site:
Prior to examining details of the SAML standard,it's useful to describe some of the high-level use cases itaddresses. More detailed use cases are described later in thisdocument along with specific SAML profiles.
Who are the participantsinvolved in a SAML interaction? At a minimum, SAML exchanges takeplace between system entities referred to as a SAMLassertingpartyand a SAMLrelyingparty.In many SAML use cases, a user, perhaps running a web browser orexecuting a SAML-enabled application, is also a participant, and mayeven be the asserting party.
An asserting party is a systementitythat makes SAML assertions. It is also sometimes called aSAMLauthority. A relying party is a system entity that uses assertions it hasreceived. When a SAML asserting or relying party makes a directrequest to another SAML entity, the party making the request iscalled aSAMLrequester, and the other partyis referred to as aSAMLresponder.A replying party's willingness to rely on information from anasserting party depends on the existence of a trust relationship withthe asserting party.
SAML system entities canoperate in a variety of SAMLroleswhichdefine the SAML services and protocol messages they will use and thetypes of assertions they will generate or consume.For example, to support Multi-Domain Single Sign-On (MDSSO, or oftenjust SSO), SAML defines the roles calledidentityprovider (IdP)andserviceprovider (SP).Another example is theattributeauthorityrole where a SAML entity produces assertions in response to identityattribute queries from an entity acting as anattributerequester.
At the heart of most SAMLassertions is asubject(a principal – an entity that can be authenticated –within the context of a particular security domain) about whichsomething is being asserted. Thesubject could be a human but could also be some other kind of entity,such as a company or a computer. The termssubjectand principal tend to be used interchangeably in this document.
A typical assertion from anidentity provider might convey information such as “This useris John Doe, he has an email address ofjohn.doe@.com,and he was authenticated into this system using a passwordmechanism.” A service provider could choose to use thisinformation, depending on its access policies, to grant John Doe webSSO access to local resources.
Multi-domain web single sign-on is arguably themost important use case for which SAML is applied. In this use case,a user has a login session (that is, asecuritycontext)on a()and is accessing resources on that site. At some point, eitherexplicitly or transparently, he is directed over to a partner's(). In this case, we assume that a federated identity for the user hasbeen previously established betweenandbased on a business agreement between them. The identity providersite ()asserts to thesite ()that the user is known (by referring to the user by their federatedidentity), has authenticated to it, and has certain identityattributes (e.g. has a “Gold membership”).Sincetrusts,it trusts that the user is valid and properly authenticated and thuscreates a local session for the user. This use case is shown inFigure 2,which illustrates the fact that the user is not required tore-authenticate when directed over to thesite.
SAML supports numerous variations on these twoprimary flows that deal with requirements for using various types andstrengths of user authentication methods, alternative formats forexpressing federated identities, use of different bindings fortransporting the protocol messages, inclusion of identity attributes,etc. Many of these options are looked at in more detail in latersections of this document.
There are many questions that must be consideredwhen business partners decide to use federated identities to sharesecurity and identity information about users. For example:
Do the users have existinglocal identities at the sites that must be linked together throughthe federated identifiers?
Will the establishment and terminationof federated identifiers for the users be done dynamically or willthe sites use pre-established federated identifiers?
Do users need to explicitly consent toestablishment of the federated identity?
Do identity attributes about the usersneed to be exchanged?
Should the identity federation rely ontransient identifiers that are destroyed at the end of the usersession?
Is the privacy of information to beexchanged of high concern such that the information should beencrypted?
Previous versions of the SAML standard relied onout-of-band agreement on the types of identifiers that would be usedto represent a federated identity between partners (e.g. the use ofX.509 subject names). While it supported the use of federatedidentities, it provided no means to directly establish theidentifiers for those identities using SAML message exchanges. SAML introduced two features toenhance its federated identity capabilities. First, new constructsand messages were added to support the dynamic establishment andmanagement of federated name identifiers. Second, two new types ofname identifiers were introduced with privacy-preservingcharacteristics.
message exchanges. For example, providersmay choose to share information about registered users via batch oroff-line “identity feeds” that are driven by data sources(for example, human resources databases) atthe identity provider and then propagated to service providers.Subsequently, the user's federated identity may be used in a SAMLassertion and propagated between providers to implement singlesign-on or to exchange identity attributes about the user.Alternatively, identity federation may be achieved purely by abusiness agreement that states that an identity provider will referto a user based on certain attribute names and values, with noadditional flows required for maintaining and updating userinformation between providers.
Mostidentity management systems maintainlocal identitiesforusers. These local identities might be represented by the user'slocal login account or some other locally identifiable user profile.These local identities must be linked to the federated identity thatwill be used to represent the user when the provider interacts with aparter. The process of associating a federated identifier with thelocal identity at a partner (or partners) where the federatedidentity will be used is often calledaccount linking.
This use case, shown in Figure 3, demonstrateshow, during web SSO, the sites can dynamically establish thefederated name identifiers used in the account linking process. Oneidentity provider, ,and twos exist in this example:for car rentals andfor hotel bookings. The example assumes a user is registered on allthree provider sites (i.e. they have pre-existing local loginaccounts), but the local accounts all have different accountidentifiers.At ,userJohn is registered asjohndoe, onhis account isjdoe, and onit isjohnd. The sites have established an agreement to usepersistentJohn has notpreviously federated his identities between these sites.
The processing sequence is as follows:
John books a flight at using hisjohndoe useraccount.
John thenuses a browser bookmark or clicks on a linkto visitto reserve a car. This site sees thatthebrowser user is not logged in locally but that he haspreviously visited their IdP partner site(optionally using the new IdP discoveryfeature of SAML). SoasksJohn if he would liketo consent to federate his localidentity with .
Johnconsents to the federation and his browser is redirected back to where thesite creates a new pseudonym,azqu3H7 for John's use when hevisitsThe pseudonym is linked to hisjohndoeaccount. Both providers agree to use this identifier to refer toJohn in subsequent transactions.
John isthen redirected back towith a SAML assertion indicating that the user represented by thefederated persistent identifierazqu3H7is logged in at the IdP. Since this is the first time thathas seen this identifier, it does not know which local user accountto which it applies.
Thus, Johnmust log in atusing hisjdoeaccount. Thenattaches the identityazqu3H7to the localjdoeaccount for future use with the IdP. The user accounts at the IdP and this SP are nowlinkedusing the federated name identifierazqu3H7.
After reserving acar, John selects a browser bookmark or clicks on a link to visitin order to book a hotel room.
The federationprocess is repeated with the IdP ,creating a new pseudonym,f78q9C0, for IdP userjohndoethat will be used when visiting.
John isredirected back to theSP with a new SAML assertion. The SP requires John to log into hislocaljohnd user account and adds the pseudonym as thefederated name identifier for future use with the IdP. The useraccounts at the IdP and this SP are nowlinkedusing the federated name identifierf78q9C0.
In the future, wheneverJohnneeds to books a flight, car, and hotel, he will only need to log inonce to before visitingand.The IdP willidentifyJohn asazqu3H7toand asf78q9C0 to.Each SP will locateJohn'slocal user account through the linked persistent pseudonyms and allowJohn to conduct businessafter the SSO exchange.
This section provides a brief description of thekey SAML concepts and the components defined in the standard.
SAML consists of building-block components that,when put together, allow a number of use cases to be supported. Thecomponents primarily permit transfer of identity, authentication,attribute, and authorization information between autonomousorganizations that have an established trust relationship. ThecoreSAML specification defines the structure and content of bothassertionsandprotocolmessages used to transfer this information.
SAMLassertions carry statements about a principal that anasserting party claims to be true. The valid structure and contentsof an assertion are defined by the SAML assertion XML.Assertions are usually created by an asserting party based on arequest of some sort from a relying party, although under certaincircumstances, the assertions can be delivered to a relying party inan unsolicited manner. SAML protocol messages are used to make theSAML-defined requests and return appropriate responses. The structureand contents of these messages are defined by theSAML-definedprotocol XML.
The means by which lower-level communication ormessaging protocols (such as HTTP or SOAP) are used to transport SAMLprotocol messages between participants is defined by the SAMLbindings.
Next,SAMLprofilesare defined to satisfy a particular business use case, for examplethe Web Browser SSO profile. Profiles typically define constraintson the contents of SAML assertions, protocols, and bindings in orderto solve the business use case in an interoperable fashion. There arealso Attribute Profiles, which do not refer to any protocol messagesand bindings, that define how to exchange attribute information usingassertions in ways that align with a number of commonusage environments (e.g.X.500/LDAPdirectories, DCE).
Figure 4illustratesthe relationship between these basic SAML concepts.
Two other SAML concepts are useful for buildingand deploying a SAML environment:
Metadatadefines a way to express and share configuration information betweenSAML parties. For instance, an entity's supported SAML bindings,operational roles (IDP, SP, etc), identifier information, supportingidentity attributes, and key information for encryption and signingcan be expressed using SAML metadata XML documents. SAML Metadatais defined by its own XML.
In a number of situations, a may need to havedetailed information regarding the type and strength ofauthentication that a user employed when they authenticated at anidentity provider. A SAMLauthenticationcontextis used in (or referred to from) anassertion's authentication statement to carry this information. AnSP can also include an authentication context in a request to an IdPto request that the user be authenticated using a specific set ofauthentication requirements, such as a multi-factor authentication.There is a general XML schema that defines the mechanisms forcreating authentication context declarations and a set ofSAML-defined Authentication Context Classes, each with their own XMLschema, that describe commonly used methods of authentication.
This document does not go into further detailabout Metadata and Authentication Context; for more information, seethe specifications that focus on them ([SAMLMeta]and[SAMLAuthnCxt],respectively).
It should be noted that the story of SAMLneed not end with its published set of assertions, protocols,bindings, and profiles. It is designed to be highly flexible, andthus it comes with extensibility points in its XML schemas, as wellas guidelines for custom-designing new bindings and profiles in sucha way as to ensure maximum interoperability.
A SAML Assertion may contain an element called. In practical terms, whatSubjectConfirmation says is "these are theconditions under which an attesting entity (somebody trying to usethe assertion) is permitted to do so". The entity trying to usethe assertion, or the "wielder", is attesting to its rightto do so, usually by implying a relationship with the subject. Anassertion can have any number ofSubjectConfirmationelements, but an attesting entity only has to satisfy one of them.
elementprovides the means for a relying party to verify the
SAML 2.0 accounts for three different securityscenarios by defining three values for the attribute of the element, these are
urn:oasis:names:tc:SAML:2.0:cm:holder-of-key urn:oasis:names:tc:SAML:2.0:cm:sender-vouches urn:oasis:names:tc:SAML:2.0:cm:bearer
In the ,relying party will allow any party capable of demonstrating knowledgeof specific key information contained with the element's element to use the assertion (and thereby lay claim to somerelationship with the subject within).
In the model, the relying party will allow any party that bears
In model,relying party will use other criteria in determining which partiesshould be allowed to use the assertion (and thereby lay claim to somerelationship with the subject within).
This section takes a more detailed look at each ofthe components that represent the assertion, protocol, binding, andprofile concepts in a SAML environment.
Assertions: SAML allows for one party toassert security information in the form ofstatementsabout asubject. For instance, a SAML assertioncould state that the subject is named “John Doe”, has anemail address of john.doe@example.com, and is a member of the“engineering” group.
An assertion contains some basic required andoptional information that applies to all its statements, and usuallycontains asubjectof theassertion (if not present, the identity determined through othermeans, e.g. the certificate used for subject confirmation),conditionsused tovalidate the assertion, and assertion statements.
SAMLdefines three kinds of statements that can be carried within anassertion:
Authentication statements: These are created by the party that successfully authenticated auser. At a minimum, they describe the particular means used toauthenticate the user and the specific time at which theauthentication took place.
Attribute statements:Thesecontain specific identifying attributes about the subject (forexample, that user “John Doe” has “Gold”card status).
Authorization decision statements: These define something that the subject is entitled to do (forexample, whether “John Doe” is permitted to buy aspecified item).
Authentication RequestProtocol: Defines ameans by which a(or an agent acting on behalf of the principal) can requestassertions containing authentication statements and, optionally,attribute statements. The Web Browser SSO Profile uses this protocolwhen redirecting a user from an SP to an IdP when it needs to obtainan assertion in order to establish a security context for the userat the SP.
Single Logout Protocol: Defines a mechanism to allow near-simultaneous logout of activesessions associated with a. The logout can be directly initiated by the user, or initiated byan IdP or SP because of a session timeout, administrator command,etc.
Assertion Query and RequestProtocol: Defines a set of queries by which SAML assertionsmay be obtained. TheRequestformof this protocol can ask an asserting party for an existingassertion by referring to its assertion ID. TheQueryformof thisprotocol defines how arelying partycan ask for assertions (new or existing) on thebasis of a specific subject and the desired statement type.
Artifact Resolution Protocol:Provides a mechanism by which SAML protocolmessages may be passed by reference using a small, fixed-lengthvalue called anartifact.The artifact receiver uses the Artifact Resolution Protocol to askthe message creator to dereference the artifact and return theactual protocol message. The artifact is typically passed to amessage recipient using one SAML binding (e.g. HTTP Redirect) whilethe resolution request and response take place over a synchronousbinding, such as SOAP.
Name Identifier ManagementProtocol: Provides mechanisms to change the value or format ofthe name. Theissuer of the request can be either the or the identity provider. Theprotocol also provides a mechanism to terminate an association of aname identifier between an identity provider and.
Name Identifier Mapping Protocol: Provides a mechanism to programmatically map oneSAML name identifier into another, subject to appropriate policycontrols. It permits, for example, one SP to request from an IdP anidentifier for a user that the SP can use at another SP in anapplication integration scenario.
Bindings: SAML bindings detail exactly howthe various SAML protocol messages can be carried over underlyingtransport protocols. The bindings defined by SAML are:
HTTP Redirect Binding: Defines how SAML protocol messages can be transported using HTTPredirect messages (302 status code responses).
HTTP POST Binding: Defines howSAML protocol messages can be transported within the base64-encodedcontent of an HTML form control.
HTTP Artifact Binding: Defineshow an artifact (described above in the Artifact ResolutionProtocol) is transported from a message sender to a message receiverusing HTTP. Two mechanisms are provided: either an HTML form controlor a query string in the URL.
SAML SOAP Binding: Defines howSAML protocol messages are transported within SOAP 1.1 messages,with details about using SOAP over HTTP.
Reverse SOAP (PAOS) Binding:Defines a multi-stage SOAP/HTTP message exchange that permits anHTTP client to be a SOAP responder. Used in the Enhanced Client andProxy Profile to enable clients and proxies capable of assisting inIDP discovery.
SAML URI Binding: Definesa means for retrieving an existing SAML assertion by resolving a URI(uniform resource identifier).
Profiles: SAML profiles define how the SAMLassertions, protocols, and bindings are combined and constrained toprovide greater interoperability in particular usage scenarios. Someof these profiles are examined in detail later in this document. Theprofiles defined by SAML are:
Web Browser SSO Profile: Defines how SAML entities use theAuthenticationRequest Protocol and SAML Response messages and assertions toachieve single sign-on with standard web browsers.usedin combination with the HTTP Redirect,, and HTTPArtifact bindings.
Enhanced Client and Proxy (ECP)Profile: Defines a specialized SSO profilewhere specialized clients or gateway proxies can use theReverse-SOAP (PAOS) and SOAP bindings.
Identity Provider DiscoveryProfile: Defines one possible mechanism for service.
Single Logout Profile: Defineshow the SAML Single Logout Protocol can be used with SOAP, HTTPRedirect, HTTP POST, and HTTP Artifact bindings.
Assertion Query/Request Profile: Defines how SAML entities can use the SAML Query and RequestProtocol to obtain SAML assertions over a synchronous binding, suchas SOAP.
Artifact Resolution Profile: Defines how SAML entities can use the Artifact Resolution Protocolover a synchronous binding, such as SOAP, to obtain the protocolmessage referred to by an artifact.
Name Identifier Management Profile: Defines how the Name Identifier Management Protocol may be usedwith SOAP, HTTP Redirect, HTTP POST, and HTTP Artifact bindings.
Name Identifier Mapping Profile: Defines how the Name Identifier Mapping Protocol uses a synchronousbinding such as SOAP.
This section provides descriptions and examples ofsome of the key SAML XML constructs.
An assertion contains one or more statements andsome common information that applies to all contained statements orto the assertion as a whole. A SAML assertion istypically carried between parties in a SAML protocol responsemessage, which itself must be transmitted using some sort oftransport or messaging protocol.
Figure 5 shows a typical example of containment: aSAML assertion containing a series of statements, the whole beingcontained within a SAML response, which itself is carried by somekind of protocol.
Figure 6shows an XML fragment containing anexample assertion with a single authentication statement. Note thatthe XML text in the figure (and elsewhere in this document) has beenformatted for presentation purposes. Specifically, while line breaksand extra spaces are ignored between XML attributes within an XMLelement tag, when they appear between XML element start/end tags,they technically become part of the element value. They are insertedin the example only for readability.
Line 1 begins the assertionand contains the declaration of the SAMLassertion namespace, which is conventionally represented in thespecifications with thesaml:prefix.
Lines 2 through 6provide information about the nature of the assertion: which versionof SAML is being used, when the assertion was created, and whoissued it.
Lines 7 through 12provide information about the subject of the assertion, to which allof the contained statements apply. The subject has a name identifier(line 10) whose value is “j.doe@.com”,provided in the format described on line 9 (email address). SAMLdefines various name identifier formats, and you can also defineyour own.
The assertion as a whole has avalidity period indicated by lines 14 and 15. Additional conditionson the use of the assertion can be provided inside this element;SAML predefines some and you can define your own. Timestamps in SAMLuse the XML Schemadata type.
The authentication statement appearingon lines 17 through 24 shows that this subject was originallyauthenticated using a password-protected transportmechanismSAMLpredefines numerous authentication contextmechanisms (called classes), and you can also define your ownmechanisms.
numberof different formats. SAML's predefined formats include:
Email address
X.509 subject name
Windows domain qualified name
Kerberos principal name
Entity identifier
Persistent identifier
Transient identifier
Of these, persistent and transient nameidentifiers utilize privacy-preserving pseudonyms to represent theprincipal.Persistent identifiers provide a permanentprivacy-preserving federation since they remain associated with thelocal identities until they are explicitly removed.Transientidentifiers support “anonymity” at an SP sincethey correspond to a “one-time use” identifier created atthe IdP. They are not associated with a specific local user identityat the SP and are destroyed once the user session terminates.
When persistent identifiers are created by an IdP,they are usually established for use only with a single SP. That is,an SP will only know about the persistent identifier that the IdPcreated for a principal for use when visiting that SP. The SP doesnot know about identifiers for the same principal that the IdP mayhave created for the user at other service providers. SAML does,however, also provide support for the concept of anaffiliationof service providers which can share a single persistent identifierto identify a principal.
Attribute information about a principal is oftenprovided as an adjunct to authentication information in singlesign-on or can be returned in response to attribute queries from arelying party. SAML's attribute structure does not presume that anyparticular type of data store or data types are being used for theattributes; it has an attribute type-agnostic structure.
Figure 7shows an XML fragmentcontaining an example attribute statement.
Note the following:
A single statement can containmultiple attributes. In this example, there are three attributes(starting on lines 2, 10, and 16) within the statement.
Attribute names arequalified with a name format (lines 4, 11, and 17) which indicateshow the attribute name is to be interpreted. This example takesadvantage of two of the SAML-definedattributeprofilesand defines a third custom attribute as well. Thefirst attribute uses the SAMLX.500/LDAPAttribute Profile to define avalue for the LDAP attribute identified by the OID “2.5.4.42”.This attribute in an LDAP directory has a friendly name of“givenName” and the attribute's value is “John”.The second attribute utilizes the SAMLBasicAttribute Profile, refers to anattribute named “LastName” which has the value “Doe”.The name format of the third attribute indicates the name is not ofa format defined by SAML, but is rather defined by a third party,SmithCo. Note that the use of private formats and attribute profilescan create significant interoperability issues.
The value of an attribute can bedefined by simple data types, as on lines 7 and 14, or can bestructured XML, as on lines 20 through 22.
In environments where communicating SAML partiesare SOAP-enabled, the SOAP-over-HTTP binding can be used to exchangeSAML request/response protocol messages. Figure 8 shows the structureof a SAML response message being carried within the SOAP body of aSOAP envelope, which itself has an HTTP response wrapper. Note thatSAML itself does not make use of the SOAP header of a SOAP envelopebut it does not prevent SAML-based application environments fromdoing so if needed.
Figure 9 shows an XML document containing anexample SAML attribute querymessagebeingtransported within a SOAP envelope.
Note the following:
TheSOAP envelope starts at line 2.
The SAML attributequery starting on line 5 is embedded in a SOAP body element startingon line 4.
The attribute query contains, fromlines 610, various required and optional XML attributes includingdeclarations of the SAML assertion and protocolnamespaces, and the message ID, .
The requestspecifies a number of optional elements, from lines 11 through 22,that govern the type of attributes the requester expects back. Thisincludes, for example, the requested attribute (givenName) and thesubject for which the attribute is sought.
An example XML fragment containing a SAML protocolResponse message being transported in a SOAP message is shown in Figure 10.
Note the following:
On line 10, the Response XMLattribute references the request to which the asserting party isresponding, and specifies additional information (lines 7 through14) needed to process the response, including status information.SAMLdefines a number of status codes and, inmany cases, dictates the circumstances under which they must beused.
Within the response (line 15; detailelided) is a SAML assertion, that would contain the requested givenname attribute in an attribute statement.
In an information technology context, privacygenerally refers to both a user's ability to control how theiridentity data is shared and used, and to mechanisms that inhibittheir actions at multiple service providers from beinginappropriately correlated.
SAML is often deployed in scenarios where suchprivacy requirements must be accounted for (as it is also oftendeployed in scenarios where such privacy need not be explicitlyaddressed, the assumption being that appropriate protections areenabled through other means and/or layers).
SAML has a number of mechanisms that supportdeployment in privacy .
SAML supports the establishment of pseudonymsestablished between an identity provider and a service provider.Such pseudonyms do not themselves enable inappropriate correlationbetween service providers (as would be possible if the identityprovider asserted the same identifier for a user to every serviceprovider, a so-calledglobal identifier).
SAML supportsone-time or transientidentifiers – such identifiers ensure that every time acertain user accesses a given service provider through a singlesign-on operation from an identity provider, that service providerwill be unable to recognize them as the same individual as mighthave previously visited (based solely on the identifier, correlationmay be possible through non-SAML handles).
SAML's Authentication Context mechanismsallow a user to be authenticated at a sufficient (but not more thannecessary) assurance level, appropriate to the resource they may beattempting to access at some service provider.
SAML allows the claimed fact of a userconsenting to certain operations (e.g. the act of federation) to beexpressed between providers. How, when or where such consent isobtained is out of scope for SAML.
Justproviding assertions from an asserting party to a relying party maynot be adequate to ensure a secure
Where message integrity andmessage confidentiality are required, then HTTP over SSL 3.0 or TLS1.0 is recommended.
When a relying party requests anassertion from an asserting party, bi-lateral authentication isrequired and the use of SSL 3.0 or TLS 1.0 using mutualauthentication or authentication via digital signatures isrecommended.
When a response message containing anassertion is delivered to a relying party via a user's web browser(for example using the HTTP POST binding), then to ensure messageintegrity, it is mandated that the response message be digitallysigned using XML Signature
As mentioned earlier, SAML defines a number ofprofiles to describe and constrain the use of SAML protocol messagesand assertions to solve specific business use cases. This sectionprovides greater detail on some of the most important SAML profilesand identity federation use cases.
This section describes the typical flows likely tobe used with the web browser SSO profile of SAML V2.0.
The Web Browser SSO Profile defines how to useSAML messages and bindings to support the web SSO use case describedin section 3.2. This profile provides a wide variety of options,primarily having to do with two dimensions of choice: first whetherthe message flows are IdP-initiated or SP-initiated, and second,which bindings are used to deliver messages between the IdP and theSP.
The first choice has to do with where the userstarts the process of a web SSO exchange. SAML supports two generalmessage flows to support the processes. The most common scenario forstarting a web SSO exchange is the SP-initiated web SSO model whichbegins with the user choosing a browser bookmark or clicking a linkthat takes them directly to an SP application resource they need toaccess. However, since the user is not logged in at the SP, before itallows access to the resource, the SP sends the user to an IdP toauthenticate. The IdP builds an assertion representing the user'sauthentication at the IdP and then sends the user back to the SP withthe assertion.
is used to coordinate messages and actions of IdPs and SPs, forexample, to allow an IdP (with which SSO was initiated) to indicatethe URL of a desired resource when communicating with an SP.
Figure 11compares the IdP-initiated andSP-initiated models.
The following subsectionsdescribe the detailed message flows involved in web SSO exchanges forthe following use case scenarios:
SP-initiated SSO using a RedirectBinding for the SP-to-IdP message and a POST Binding for the IdP-to-SP message
SP-initiated SSO using a POST Bindingfor the message and an Artifact Binding for the message
IDP-initiated SSO using a POST Bindingfor the IdP-to-SP message; no SP-to-IdP message is involved.
This firstexample describes an SP-initiated SSO exchange. In such an exchange,the user attempts toaccessa resource on the SP, sp.example.com.However they do nothave a current logon session on thissiteand their federated identity is managed by their IdP,idp.example.org. They are sent to the IdP to log on and the IdPprovides a SAML web SSO assertion for the user's federated identityback to the SP.
For thisspecific use case, the HTTP Redirect Binding is used to deliver theSAMLmessage to theand the HTTP POST Binding is used to return the SAMLmessage containing the assertion to the SP.Figure 12illustrates the message flow.
The processing is as follows:
The user attempts to access a resource onsp.example.com. The user does not have a valid logon session (i.e.security context) on this site. The SP saves the requested resourceURL in local state information that can be saved across the web SSOexchange.
The SP sends an HTTP redirect response to thebrowser (HTTP status 302 or 303). The Location HTTP header containsthe destination URI of the Sign-On Service at the together with anmessage encoded as a URL query variable named.
Thequery string is encoded using the DEFLATE encoding.
The Single Sign-On Service determines whetherthe user has an existing logon security context at the. If not, the IdP interacts with the browser to challenge the user toprovide valid credentials.
The user provides valid credentials and alocal logon security context is created for the user at the IdP.
The IdP Single Sign-On Service builds a SAMLassertion representing the user's logon security context. Since aPOST binding is going to be used, the assertion is digitally signedand then placed within a SAML message. The message is then placed within anFORM as a hidden form control named . If the IdP received avalue from the SP, it must return it unmodified to theSP in a hidden form control named.The Single Sign-On Service sends the HTML form back to the browserin the HTTP response.For ease ofuse purposes, the HTML FORM typically will be accompanied by scriptcode that will automatically post the form to the destination site.
Assertion Consumer Service.
where the values of theSAMLResponse and RelayState parameters are taken from the HTML formof Step 5.
The's obtains the messagefrom the HTML FORM for processing. The digital signature on the SAMLassertion must first be validated and then the assertion contents areprocessed in order to create a local logon security context for theuser at the SP. Once this completes, the SP retrieves the localstate information indicated by thesends redirect response to thebrowser directing it to access the originally requested resource (notshown).
An access check is made to establish whetherthe user has the correct authorization to access the resource. Ifthe access check passes, the resource is then returned to thebrowser.
This usecase again describes an SP-initiated SSO exchange.
heHTTP POST binding is used to deliver the SAMLto theand the SAMLmessage is returned using the Artifact binding. The HTTP POST bindingmay be necessary for an <AuthnRequest> message in cases whereits length precludes the use of the HTTP Redirect binding (which istypical). The message may be long enough to require a POST bindingwhen, for example, it includes many of its optional elements andattributes, or when it must be digitally signed.
When usingthe HTTP Artifact binding for the SAML message, SAML permits the artifact to be delivered via the browserusing either an HTTP POST or HTTP Redirect response (not to beconfused with the SAML HTTP POST and Redirect Bindings). In thisexample, the artifact is delivered using.
Once theis in possession of the artifact, it contacts the IdP's ArtifactResolution Service using the synchronous SOAP binding to obtain theSAML message that corresponds to the artifact. Figure 13 illustratesthe message flow.
Theprocessing is as follows:
The user attempts to access a resource onsp.example.com. The user does not have a valid logon session (i.e.security context) on this site. The SP saves the requested resourceURL in local state information that can be saved across the web SSOexchange.
The SP sends an HTML form back to the browserin the HTTP response (HTTP status 200). TheFORM contains a SAML message encoded as the value of a hidden form control named.
element:
For ease-of-use purposes, the HTML FORMtypically will be accompanied by script code that will automaticallypost the form to the destination site (which is the IdP in thiscase).Single Sign-On Service.
The user provides valid credentials and alocal logon security context is created for the user at the IdP.
The SP's now sends a SAMLmessage containing the artifact to the.This exchange is performed using a synchronous SOAP messageexchange.
The IdP's Artifact Resolution Serviceextracts the MessageHandle from the artifact and locates theoriginal SAMLis then placed insidea SAML message, which is returned to the SP over the SOAP channel.
The SP extracts and processes thethen processes the embedded assertion in order tocreate a local logon security context for the user at the SP. Oncethis is completed, the SP retrieves the local state informationindicated by thesends redirect response to thebrowser directing it to access the originally requested resource(not shown).
An access check is made to establish whetherthe user has the correct authorization to access the resource. Ifthe access check passes, the resource is then returned to thebrowser.
In addition to supporting the new SP-Initiated webSSO use cases, SAML v2 continues to support the IdP-initiated web SSOuse cases originally supported by SAML v1. In an IdP-initiated usecase, the identity provider is configured with specialized links thatrefer to the desired service providers. These links actually refer tothe local IdP's Single Sign-On Service and pass parameters to theservice identifying the remote SP. So instead of visiting the SPdirectly, the user accesses the IdP site and clicks on one of thelinks to gain access to the remote SP. This triggers the creation ofa SAML assertion that, in this example, will be transported to the using the binding.
Figure 14 shows the process flow for anIdP-initiated web SSO exchange.
The processing is as follows:
If the user does not have a valid localsecurity context at the IdP, at some point the user will bechallenged to supply their credentials to the IdP site,idp.example.org.
The user provides valid credentials and alocal logon security context is created for the user at the IdP.
The user selects a menu option or link on theIdP to request access to an SP web site, sp.example.com. Thiscauses the IdP's Single Sign-On Service to be called.
The Single Sign-On Service builds a SAMLassertion representing the user's logon security context. Since aPOST binding is going to be used, the assertion is digitally signedbefore it is placed within a SAML message. The message is then placed within anFORM as a hidden form control named. (If the convention for identifying a specific application resourceat the SP is supported at the IdP and SP, the resource URL at the SPis also encoded into the form using a hidden form control named.)The Single Sign-On Service sends theHTML form back to the browser in the HTTP response. For ease-of-usepurposes, the HTML FORM typically will contain script code that willautomatically post the form to the destination site.
Assertion Consumer Service. The's obtains the messagefrom the HTML FORM for processing. The digital signature on the SAMLassertion must first be validated and then the assertion contentsare processed in order to create a local logon security context forthe user at the SP. Once this completes, the SP retrieves thesends redirect response to thebrowser directing it to access the requested resource (not shown).
Anaccess check is made to establish whether the user has the correctauthorization to access the resource. If the access check passes,the resource is then returned to the browser.
The browser SSO profile discussed above works withcommercial browsers that have no special capabilities. This sectiondescribes a SAML V2.0 profile that takes into account enhanced clientdevices and proxy servers.
The Enhanced Client and Proxy (ECP) Profilesupports several SSO use cases, in particular:
Clients with capabilities beyondthose of a browser, allowing them to more actively participate inIDP discovery and message flow.
Using a proxy server, for example a WAPgateway in front of a mobile device which has limited functionality.
When other bindings are precluded (e.g. wherethe client does not support redirects, or when auto form post is notpossible without Javascript, or when the artifact binding is ruledout because the identity provider and service provider cannotdirectly communicate.
Figure 15 illustrates two such use cases for usingthe ECP Profile.
The ECP profile defines a single binding –PAOS (Reverse SOAP). Theuses SOAP headers and SOAP bodies to transport SAML and SAML messages between the and the.
Figure 16
Theprocessing is as follows:
The ECP wishes to gain access to a resourceon the. TheECP will issue request for the resource. The HTTP request contains a PAOS HTTP header defining that the ECPservice is to be used.
Accessing the resource requires that theprincipal has a valid security context, and hence a SAML assertionneeds to be supplied to the. In the HTTP response tothe ECP an is carried within a SOAP body. Additional information, using thePAOS binding, is provided back to the ECP
After some processing in the ECP the issent to the appropriate using the SAML SOAPbinding.
The validates the andsends back to the ECP a SAML ,again using the SAML SOAP binding.
The ECP extracts the and forwards it to the as a PAOS response.
The sends to the ECP response containing theresource originally requested.
Once single sign-on has been achieved, severalindividual sessions with service providers share a singleauthentication context. This section discusses SAML's profile forsingle logout, which allows for reversing the sign-on process withall of these providers at once.
One representative flow option is discussed indetail: single logout that is initiated at one SP and results inlogout from multiple SPs.
Single logout permits near real-time sessionlogout of a user from all participants in a session. A request canbe issued by any session participant to request that the session isto be ended. As specified in the SAML Conformance specification ,the SAML l
A user was previously authenticated by the idp.example.org
TheSP sp1.example.com destroys the local authentication session statefor the user and thenorgThe identity providerverifies that the<LogoutRequest>originated from a known and trusted service provider. The identityprovider processes the request and destroys any local sessioninformation for the user.
Having determined that other serviceproviders are also participants in the web SSO session, the identityprovider similar sends a<LogoutRequest>message to those providers. In this example, there is one otherservice provider, sp2.The<LogoutRequest>message is sent using the SOAP over HTTP Binding.
The service provider sp2returns a<LogoutResponse>message containing a suitable status code response to the identityprovider. The response is digitally signed and returned (in thiscase) using the SOAP over HTTP binding.
The identity provider returns a<LogoutResponse> messagecontaining a suitable status code response to the originalrequesting service provider, sp1. The response is digitally signed and returned (in this case) usingthe HTTP Redirect binding.
Finally, the service provider sp1informs the user that they are logged out of all the providers.
Thus far, the use case examples that have beenpresented have focused on the SAML message exchanges required tofacilitate the implementation of web single sign-on solutions. Thissection examines issues surrounding how these message exchanges aretied to individual local and federated user identities shared betweenparticipants in the solution.
Federation viaOut-of-Band Account Linking:Theestablishment of federated identities for users and the associationof those identities to local user identities can be performedwithout the use of SAML protocols and assertions. This was the onlystyle of federation supported by SAML V1 and is still supported inSAML v2.0.
Federation via PersistentPseudonym Identifiers: An federates the user'slocal identitywith the'sidentity at the.
Federation via TransientPseudonym Identifiers: A temporary identifier is used tofederate between the IdP and the SP for the life of the user's webSSO session.
Federation via IdentityAttributes:Attributesof the principal, as defined by the,are used to link to the account used at the serviceprovider.
: termination of an existing federation.
To simplify the examples, not all possible SAMLbindings are illustrated.
Allthe examples are based on the use case scenarios originally definedin Section 3.2, with airline.example.com being the identity provider.
Inthis example, shown inFigure 18,the user John has accounts on bothandeach using the same local user ID (john). The identity data stores at both sites are synchronized by someout-of-band means, for example using database synchronization oroff-line batchupdates.
The processing is as follows:
The user is challenged to supply theircredentials to the site.
The user successfully provides theircredentials and has a security context with the.
The user selects a menu option (or function)on theapplication that means the user wants to access a resource orapplication on.Thesends a HTML form back to the browser. TheFORM contains a SAML response, within which is a SAML assertionabout user john.
.
Theservice provider's Assertion Consumer Service validates the digitalsignature ontheSAML Response. If this, and thevalidate correctly it creates a local session for user john,basedon the local john account. It then sends an HTTP redirect to thebrowser causing it to access theTARGET resource, witha cookie that identifies the local session. An access check is thenmade to establish whether the user john has the correct authorizationto access the cars.example.co.uk web site and the TARGET resource. The TARGET resource is then returned to the browser.
In this use case scenario, the partner sites take advantage of SAML's ability to dynamicallyestablish a federated identity for a user as part of the web SSOmessage exchange. SAML V2.0 provides the NameIDPolicy element on theAuthnRequest to allow the SP to constrain such dynamic behaviour. Theuser
The processing is as follows:
The user attempts to access a resource on. The user does not have any current logon session (i.e. securitycontext) on this site, and is unknown to it. The resource that theuser attempted to access is saved as information.
The uses the HTTP RedirectBinding to send the user to the Single Sign-On Service at theidentity provider ().The HTTP redirect includes a SAML message requesting that the identity provider provide an assertionusing a persistent name identifier for the user. As the serviceprovider desires the IdP have the flexibility to generate a newidentifiier for the user should one not already exist, the SP setsthe AllowCreate attribute on the NameIDPolicy element to 'true”.
The user will be challenged to provide validcredentials.
The user provides valid credentialsidentifying himself asjohnand a local securitycontext is created for the user at the IdP.
The Single Sign-On Service looks up userjohnin its identity store and, seeing that the AllowCreate attributeallows it to, creates a persistent name identifier ()to be used for the session at the service provider. It then builds asigned SAML web SSO assertion where the subject uses a transientname identifier format. The namejohn is not containedanywhere in the assertion. Note that depending on the partneragreements, the assertion might also contain an attribute statementdescribing identity attributes about the user (e.g. their membershiplevel).
Assertion Consumer Service.
serviceprovider'sAssertionConsumer service validates the digital signature on the SAMLResponse and validates the SAML assertion. The supplied nameidentifier is then used to determine whether a previous federationhas been established. If a previous federation has been established(because the name identifier maps to a local account) then go tostep 9. If no federation exists for the persistent identifier inthe assertion, then the SP needs to determine the local identity towhich it should be assigned. The user will be challenged to providelocal credentials at the SP. Optionally the user might first beasked whether he would like to federate the two accounts.
web site (the resource URL was retrieved from state informationidentified by the information.
The processing is as follows:
The user attempts to access a resource on. The user does not have any current logon session (i.e. securitycontext) on this site, and is unknown to it. The resource that theuser attempted to access is saved as information.
The uses the HTTP RedirectBinding to send the user to the Single Sign-On Service at theidentity provider ().The HTTP redirect includes a SAML message requesting that the identity provider provide an assertionusing a transient name identifier for the user.
The user will be challenged to provide validcredentials at the identity provider.
The user provides valid credentialsidentifying himself asjohnand a local securitycontext is created for the user at the IdP.
The Single Sign-On Service looks up userjohnin its identity store and creates a transient name identifier() to be used forthe session at the service provider. It then builds a signed SAMLweb SSO assertion where the subject uses a transient name identifierformat. The namejohn is not contained anywhere in theassertion. The assertion also contains an attribute statement with amembership level attribute (“Gold” level). The assertionis placed in a SAML response message and the IdP uses the HTTP POSTBinding to send the Response message to the service provider.
Assertion Consumer Service.
This example builds upon the previous federationexample using persistent pseudonym identifiers and shows how afederation can be terminated. In this case thejdoeaccount on has been deleted, henceit wishes to terminate the federation withfor this user.
The Terminate request is sent to the using the Name IdentifierManagement Protocol, specifically using the . The example shown in Figure 21 uses the SOAP over HTTP binding whichdemonstrates a use of the back channel. Bindings are also definedthat permit the request (and response) to be sent via the browserusing
The,,
The verifies the digital signatureensuring that theoriginated from a known and trusted. The identity Provider processesthe request and returns acontaining a suitable status code response. The response is carriedwithin a SOAP over HTTP message and is digitally signed.
As explained in Section 3.2, in describing the websingle sign-on use case, the SAML assertion transferred from anidentity provider to a service provider may include attributesdescribing the user. The ability to transfer attributes within anassertion is a powerful SAML feature and it may also be combined withthe forms of identity federation described above.
The following are some typical use patterns:
Transfer of profileinformation
Attributes may be used to convey userprofile information from the identity provider to the serviceprovider.This information may be used to provide personalizedservices at the service provider, or to augment or even create a newaccount for the user at the service provider. The user should beinformed about the transfer of information, and, if required, userconsent explicitly obtained.
Authorization based onattributes
In this model, the attributesprovided in the SAML assertion by the identity provider are used toauthorize specific services at the service provider. The serviceprovider and identity provider need prior agreement (out of band) onthe attribute names and values included in the SAML assertion. Aninteresting use of this pattern which preserves user anonymity butallows for differential classes of service is found in Shibboleth :federation using transient pseudonyms combined with authorizationbased on attributes.
SAML's components are modularand extensible. The SAML Assertions and Protocols specificationhas a section describing the basic extension features provided. TheSAML Profiles specificationprovides guidelines on how to define new profiles and attributeprofiles. The SAML Bindings specificationlikewiseoffers guidelines for defining new bindings.
As a result of this flexibility, SAML has beenadopted for use with several other standard frameworks. Following aresome examples.
SAML assertions can be conveyed by means otherthan the SAML Request/Response protocols orsdefined by the SAML specification set. One example of this is theiruse with Web Services Security (),which is a set of specifications that define means for providingsecurity protection of SOAP messages. The services provided byare authentication, data integrity, and confidentiality.
defines aelement that may be included in a SOAP message header. This elementspecifies how the message is protected.makes use of mechanisms defined in the W3C XML Signature and XMLEncryption specifications to sign and encrypt message data in boththe SOAP header and body. The information in theelement specifies what operations were performed and in what order,what keys were used for these operations, and what attributes andidentity information are associated with that information.also contains other features, such as the ability to timestamp thesecurity information and to address it to a specified Role.
In is specified usingsecuritys.Tokens can either be binary or structured XML. Binary tokens, such asX.509 certificates and Kerberos tickets, are carried in an XMLwrapper. XMLs,such as SAML assertions, are inserted directly as sub-elements of the element.A Security Token Reference may also be used to refer to a token inone of a number of ways.
consists of a core specification , which describes the mechanismsindependent of the type of token being used, and a number of tokenprofiles which describe the use of particular types of tokens. Tokenprofiles cover considerations relating to that particular token typeand methods of referencing the token using a Security TokenReference. The use of SAML assertions withis described in the SAML Token Profile .
Because the SAML protocols havea binding to SOAP, it is easy to get confused between thatSAML-defined binding and the use of SAMLsby.They can be distinguished by their purpose, the message format, andthe parties involved in processing the messages.
The characteristics of the SAML Request/Responseprotocol binding over SOAP are as follows:
It is used to obtain SAML assertionsfor use external to the SOAP message exchange; they play no role inprotecting the SOAP message.
The SAML assertions are containedwithin a SAML Response, which is carried in the body of the SOAPenvelope.
The SAML assertions are provided by atrusted authority and may or may not pertain to the party requestingthem.
The characteristics of the use of SAMLsas defined byare as follows:
The SAMLsare carried in a element within the header of the SOAP envelope as shown in Figure 22.
The SAMLsusually play a role in the protection of the message they arecarried in; typically they contain a key used for digitally signingdata within the body of the SOAP message.
The SAMLswill have been obtained previously and typically pertain to theidentity of the sender of the SOAP message.
Notethat in principle, SAMLscould be used in both ways in a single SOAP message. In this case thesin the header would refer to the identity of the Responder (andRequester) of the message. However, at this time, SAML has notprofiled the use of WS-Security to secure the SOAP message exchangesthat are made within a SAML deployment.
The following sequence of steps typifies the useof SAMLswith.
A SOAP message sender obtains a SAMLby means of the SAML Request/Response protocol or other means. Inthis example, the assertion contains an attribute statement and asubject with a confirmation method calledHolder of Key.
To protect the SOAP message:
The sender constructs the SOAP message, including a SOAP header witha WS-Security header. A SAMLis placed within a WS-Security token and included in the securityheader. The key referred to by the SAML assertion is used toconstruct a digital signature over data in the SOAP message body.Signature information is also included in the security header.
The message receiver verifies the digital signature.
The information in the SAML assertion is used for purposes such asAccess Control and Audit logging.
Figure 23 illustrates this usage scenario.
SAMLsprovide a means to distribute security-related information that maybe used for a number of purposes. One of the most important of thesepurposes is as input to Access Control decisions. For example, it iscommon to consider when and how a user authenticated or what theirattributes are in deciding if a request should be allowed. SAML doesnot specify how this information should be used or how access controlpolicies should be addressed. This makes SAML suitable for use in avariety of environments, including ones that existed prior to SAML.
The eXtensible Access Control Markup Language(XACML) is an OASIS Standard that defines the syntax and semantics ofa language for expressing and evaluating access control policies.Compatibility with SAML has been a key goal of the XACML TC.
As a result, SAML and XACML can each be usedindependently of the other, or both can be used together. Figure 24illustrates the typical use of SAML with XACML.
Using SAML and XACML in combination wouldtypically involve the following steps.
An XACML Policy Enforcement Point(PEP) receives a request to access some resource.
The PEP obtains SAMLscontaining information about the parties to the request, such as therequester, the receiver (if different) or intermediaries. Thesesmight accompany the request or be obtained directly from a SAMLAuthority, depending on the SAML profile used.
The PEP obtains other informationrelevant to the request, such as time, date, location, andproperties of the resource.
The PEP presents all theinformation to a Policy Decision Point (PDP) to decide if the accessshould be allowed.
The PDP obtains all the policiesrelevant to the request and evaluates them, combining conflictingresults if necessary.
The PDP informs the PEP of thedecision result.
The PEP enforces the decision, byeither allowing the requested access or indicating that access isnot allowed.
The SAML and XACML specification sets contain somefeatures specifically designed to facilitate their combined use.
The XACML Attribute Profile in the SAML Profilesspecification defines how attributes can be described using SAMLsyntax so that they may be automatically mapped to XACML Attributes.A schema is provided by SAML to facilitate this.
A document that was produced bythe XACML Technical Committee,SAML profile of XACML v2.0,provides additional information on mapping SAML Attributes to XACMLAttributes. Thprofile also defines a new type of Authorization decision queryspecifically designed for use in an XACML environment. It extends theSAML protocol schema and provides a requestandresponse that contains exactly the inputs and outputs defined byXACML.
That samedocument also contains two additional features that extend the SAMLschemas.Whilethey are not, strictly speaking, intended primarily to facilitatecombining SAML and XACML, they are worth noting. The first is theXACML Policy Query. This extension to the SAML protocol schema allowsthe SAMLprotocol to be used to retrieve XACML policy whichmay be applicable to a given access decision.
The second feature extends theSAML schema by allowing the SAMLenvelope to be used to wrap an XACML policy. This makes available toXACML features such as Issuer, Validity interval and signature,without requiring the definition of a redundant or inconsistentscheme. This promotes code and knowledge reuse between SAML andXACML.
Of particular note are thecontributions from: