Assertions and Protocols for the OASIS Security Assertion ...

1 Assertions and Protocols for the OASISS ecurity Assertion Markup Language(SAML) Standard, 15 March 2005 Document : :Scott Cantor, Internet2 John Kemp, NokiaRob Philpott, RSA SecurityEve Maler, Sun MicrosystemsSAML Contributors:Conor P. Cahill, AOLJohn Hughes, Atos OriginHal Lockhart, BEA SystemsMichael Beach, Boeing Rebekah Metz, Booz Allen HamiltonRick Randall, Booz Allen HamiltonThomas Wisniewski, EntrustIrving Reid, Hewlett-PackardPaula Austel, IBMM aryann Hondo, IBMM ichael McIntosh, IBMTony Nadalin, IBMNick Ragouzis, Individual Scott Cantor, Internet2 RL 'Bob' Morgan, Internet2 Peter C Davis, NeustarJeff Hodges, NeustarFrederick Hirsch, Nokia John Kemp, NokiaPaul Madsen, NTTS teve Anderson, OpenNetworkPrateek Mishra, Principal IdentityJohn Linn, RSA SecurityRob Philpott, RSA SecurityJahan Moreh, SigabaAnne Anderson, Sun March 2005 Copyright OASIS Open 2005. All Rights 1 of 8623456789101112131415161718192021222324 252627282930313233343536373839404112 Eve Maler, Sun MicrosystemsRon Monzillo, Sun MicrosystemsGreg Whitehead, TrustgenixAbstract:This specification defines the syntax and semantics for XML-encoded Assertions aboutauthentication, attributes, and authorization, and for the Protocols that convey this :This is an OASIS Standard document produced by the Security Services Technical Committee.

2 Itwas approved by the OASIS membership on 1 March members should submit comments and potential errata to the list. Others should submit them by filling out the web form locatedat Thecommittee will publish on its web page ( ) a catalogof any changes made to this document as a result of information on whether any patents have been disclosed that may be essential toimplementing this specification, and any offers of patent licensing terms, please refer to theIntellectual Property Rights web page for the Security Services TC ( ). March 2005 Copyright OASIS Open 2005. All Rights 2 of 8642434445464748495051525354555657585934 Table of Contents1 Schema Organization and Common Data String URI Time ID and ID Reference SAML Schema Header and Namespace Name Element <BaseID>.. Complex Type Element <NameID>.. Element <EncryptedID>.. Element <Issuer>.. Element <AssertionIDRef>.. Element <AssertionURIRef>.. Element < Assertion >.. Element <EncryptedAssertion>.

3 Element <Subject> .. Element <SubjectConfirmation>.. Element <SubjectConfirmationData>.. Complex Type Example of a Key-Confirmed <Subject>.. Element <Conditions>.. General Processing Attributes NotBefore and NotOnOrAfter .. Element <Condition>.. Elements <AudienceRestriction> and <Audience>.. Element <OneTimeUse>.. Element <ProxyRestriction>.. Element <Advice>.. Element <Statement>.. Element <AuthnStatement>.. Element <SubjectLocality>.. Element <AuthnContext>.. Element <AttributeStatement>.. Element <Attribute>.. Element <AttributeValue>.. Element <EncryptedAttribute>.. Element <AuthzDecisionStatement>.. Simple Type Element <Action>.. March 2005 Copyright OASIS Open 2005. All Rights 3 of Element <Evidence>..343 SAML Schema Header and Namespace Requests and Complex Type Complex Type Element <Status>.. Element <StatusCode>.. Element <StatusMessage>.. Element <StatusDetail>.. Assertion Query and Request Element <AssertionIDRequest>.

4 Element <SubjectQuery>.. Element <AuthnQuery>.. Element <RequestedAuthnContext>.. Element <AttributeQuery>.. Element <AuthzDecisionQuery>.. Element <Response>.. Processing Authentication Request Element <AuthnRequest>.. Element <NameIDPolicy>.. Element <Scoping>.. Element <IDPList>.. Element <IDPE ntry>.. Processing Proxying Processing Artifact Resolution Element <ArtifactResolve>.. Element <ArtifactResponse>.. Processing Name Identifier Management Element <ManageNameIDRequest>.. Element <ManageNameIDResponse>.. Processing Single Logout Element <LogoutRequest>.. Element <LogoutResponse>.. Processing Session Participant Session Authority Name Identifier Mapping Element <NameIDMappingRequest>.. Element <NameIDMappingResponse>.. Processing SAML SAML Specification Set Schema SAML Assertion SAML Protocol Request March 2005 Copyright OASIS Open 2005. All Rights 4 of Response Permissible Version SAML Namespace Schema SAML and XML Signature Syntax and Signing Request/Response Signature XML Signature Signing Formats and Canonicalization SAML and XML Encryption Syntax and General Combining Signatures and SAML Schema Assertion Schema Protocol Schema Schema Wildcard Extension Assertion Extension Protocol Extension Identifier SAML-Defined Action Namespace Read/Write/Execute/ Read/Write/Execute/Delete/Control with Get/Head/ UNIX File Attribute Name Format URI Name Identifier Format Email Subject Windows Domain Qualified Kerberos Principal Entity Persistent Transient Consent March 2005 Copyright OASIS Open 2005.

5 All Rights 5 of Normative Non-Normative A. B. March 2005 Copyright OASIS Open 2005. All Rights 6 of 8621421521621721821922022111121 IntroductionThe Security Assertion Markup Language (SAML) defines the syntax and processing semantics ofassertions made about a subject by a system entity. In the course of making, or relying upon suchassertions, SAML system entities may use other Protocols to communicate either regarding an assertionitself, or the subject of an Assertion . This specification defines both the structure of SAML Assertions , andan associated set of Protocols , in addition to the processing rules involved in managing a SAML Assertions and protocol messages are encoded in XML [XML] and use XML namespaces[XMLNS]. They are typically embedded in other structures for transport, such as HTTP POST requests orXML-encoded SOAP messages. The SAML bindings specification [SAMLBind] provides frameworks forthe embedding and transport of SAML protocol messages.

6 The SAML profiles specification [SAMLProf]provides a baseline set of profiles for the use of SAML Assertions and Protocols to accomplish specificuse cases or achieve interoperability when using SAML features. For additional explanation of SAML terms and concepts, refer to the SAML technical overview[SAMLTechOvw] and the SAML glossary [SAMLG loss] . Files containing just the SAML Assertion schema[SAML-XSD] and protocol schema [SAMLP-XSD] are also available. The SAML conformance document[SAMLC onform] lists all of the specifications that comprise SAML following sections describe how to understand the rest of this NotationThe keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULDNOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted asdescribed in IETF RFC 2119 [RFC 2119].Listings of SAML schemas appear like code listings appear like : Notes like this are sometimes used to highlight non-normative specification uses schema documents conforming to W3C XML Schema [Schema1] and normativetext to describe the syntax and semantics of XML-encoded SAML Assertions and protocol messages.

7 Incases of disagreement between the SAML schema documents and schema listings in this specification,the schema documents take precedence. Note that in some cases the normative text of this specificationimposes constraints beyond those indicated by the schema XML namespace prefixes are used throughout the listings in this specification to stand fortheir respective namespaces (see Section ) as follows, whether or not a namespace declaration ispresent in the example:PrefixXML NamespaceCommentssaml:urn: OASIS :names:tc : :assertionThis is the SAML Assertion namespace, defined in aschema [SAML-XSD]. The prefix is generally elided inmentions of SAML Assertion -related elements in :urn: OASIS :names:tc: :protocolThis is the SAML protocol namespace, defined in aschema [SAMLP-XSD]. The prefix is generally elided inmentions of XML protocol-related elements in : #This namespace is defined in the XML Signature Syntax andProcessing specification [XMLSig] and its governing schema[XMLSig-XSD].

8 March 2005 Copyright OASIS Open 2005. All Rights 7 of 8622222322422522622722822923023123223323 4235236237238239240241242243244245246247 2482492502512522532541314 PrefixXML NamespaceCommentsxenc: #This namespace is defined in the XML Encryption Syntaxand Processing specification [XMLEnc] and its governingschema [XMLEnc-XSD].xs: namespace is defined in the W3C XML Schemaspecification [Schema1]. In schema listings, this is thedefault namespace and no prefix is shown. For clarity, theprefix is generally shown in specification text when XMLS chema-related constructs are : namespace is defined in the W3C XML Schemaspecification [Schema1] for schema-related markup thatappears in XML specification uses the following typographical conventions in text: <SAMLE lement>,<ns:ForeignElement>, XMLA ttribute, Datatype, Schema Organization and NamespacesThe SAML Assertion structures are defined in a schema [SAML-XSD] associated with the following XMLnamespace:urn: OASIS :names:tc: :assertionThe SAML request-response protocol structures are defined in a schema [SAMLP-XSD] associated withthe following XML namespace:urn: OASIS :names:tc: :protocolThe Assertion schema is imported into the protocol schema.

9 See Section for information on SAML namespace imported into both schemas is the schema for XML Signature [XMLSig], which is associated with thefollowing XML namespace: #Finally, the schema for XML Encryption [XMLEnc] is imported into the Assertion schema and is associatedwith the following XML namespace: # Common Data TypesThe following sections define how to use and interpret common data types that appear throughout theSAML String ValuesAll SAML string values have the type xs:string, which is built in to the W3C XML Schema Datatypesspecification [Schema2]. Unless otherwise noted in this specification or particular profiles, all strings inSAML messages MUST consist of at least one non-whitespace character (whitespace is defined in theXML Recommendation [XML] Section ).Unless otherwise noted in this specification or particular profiles, all elements in SAML documents thathave the XML Schema xs:string type, or a type derived from that, MUST be compared using an exactbinary comparison.

10 In particular, SAML implementations and deployments MUST NOT depend on case-insensitive string comparisons, normalization or trimming of whitespace, or conversion of March 2005 Copyright OASIS Open 2005. All Rights 8 of 8625525625725825926026126226326426526626 7268269270271272273274275276277278279280 2812822831516formats such as numbers or currency. This requirement is intended to conform to the W3C working-draftRequirements for String Identity, Matching, and String Indexing [W3C-CHAR].If an implementation is comparing values that are represented using different character encodings, theimplementation MUST use a comparison method that returns the same result as converting both values tothe Unicode character encoding, Normalization Form C [UNICODE-C], and then performing an exactbinary comparison. This requirement is intended to conform to the W3C Character Model for the WorldWide Web [W3C-CharMod], and in particular the rules for Unicode-normalized that compare data received in SAML documents to data from external sources MUST takeinto account the normalization rules specified for XML.