13 Registry SAML Profile

OASIS/ebXML Registry Services Specification December 2004

6764 13 Registry SAML Profile 6765 This chapter defines the Registry SAML Profile that a registry MAY implement in order to 6766 support SAML 2.0 protocols defined by [SAMLCore]. A specific focus of the Registry SAML 6767 Profile is the Web Single Sign On (SSO) profile defined by [SAMLProf].

6768 13.1 Terminology 6769 The reader should refer to the SAML Glossary [SAMLGloss] for various terms used in the 6770 Registry SAML profile. A few terms are described here for convenience: 6771 Term Definition Authentication An Authentication Authority is a system entity (typically a service) that Authority enables other system entities (typically a user or service) to establish an authenticated session by proving their identity by providing necessary credentials (e.g. username / password, certificate alias / password). An Authentication Authority produces authentication assertions as a result of successful authentication. Enhanced Client Describes a client that operates under certain constraints such as not being Proxy (ECP) able to support HTTP Redirect protocol. Typically these are clients that do not have a Web Browser environment. In this document the main example of an ECP is a Registry Client that users SOAP to communicate with the registry (SOAP Requestor). Identity Provider A kind of service provider that creates, maintains, and manages identity (IdP) information for principals (e.g. users). An Identity Provider is usually also an Authentication Authority.

Principal A system entity whose identity can be authenticated. This maps to User in [ebRIM]. SAML A system entity that utilizes the SAML protocol to request Requestor services from another system entity (a SAML authority, a responder). The term “client” for this notion is not used because many system entities simultaneously or serially act as both clients and servers.

Service Provider A role donned by a system entity where the system entity provides services (SP) to principals or other system entities. The Registry Service is a SP Single Sign On The ability to share a single authenticated session across multiple SSO (SSO) enabled services and application. The client may establish the authenticated session by authenticating with any Authentication Authority within the system. The client may then perform secure operations with any SSO enabled service within the system using the authenticated session. Single Logout The ability to logout nearly simultaneously from multiple Service Providers within a federated system. 6772

6773 13.2 Use Cases for SAML Profile 6774 The Registry SAML Profile is intended to address following use cases using the protcols defined 6775 by [SAMLCore].

6776 13.2.1 Registry as SSO Participant: 6777 A large enterprise is deploying an ebXML Registry. The enterprise already has an existing 6778 Identity Provider (e.g. an Access Manager service) where it maintains user information and 6779 credentials. The enterprise also has an existing Authentication Authority (which may be the same 6780 service as the Identity Provider) that is used to authenticate users and enable Single Sign On 6781 (SSO) across all their enterprise services applications. 6782 The enterprise wishes to use its existing Identity Provider to manage registry users and to avoid 6783 duplicating the user database contained in the Identity Provider within the registry. The 6784 enterprise also wishes to use its existing Authentication Authority to authenticate registry users 6785 and expects the registry to participate in SSO capability provided by their Authentication 6786 Authority service. 6787 Source Web Site (Company.com)

Asserting Party ate tic en uth A 1.

Destination Web Site (Travel.com) 2 . Web User Ac ce ss R es our ce Relying Party

6788 6789 Figure 50: SAML SSO Typical Scenario

6790 13.3 SAML Roles Played By Registry 6791 In order to conform to the registry SAML Profile an ebXML Registry plays the Service Provider 6792 (SP) role based upon conformance with SAML 2.0 protocols.

6793 13.3.1 Service Provider Role 6794 The Service Provider role enables the registry to participate in SAML protocols. Specifically it 6795 allows the registry to utilize an Identity Provider to perform client authentication on its behalf.

6796 13.3.1.1 Service Provider Requirements 6797 The following are a list of requirements for the Service Provider role of the registry: 6798 • MUST support the protocols, messages and bindings that are the responsibility of the 6799 Service Provider as defined by Web SSO Profile in [SAMLProf]. Specifically it MUST 6800 be able to intiate and participate in the Authentication Request Protocol with an Identity 6801 Provider. 6802 • MUST be able to use a SAML Identity Provider to authenticate client requests. 6803 • MUST support the ability to maintain a security context for registry clients across 6804 multiple client requests. 6805

6806 13.4 Registry SAML Interface 6807 In order to conform to the registry SAML Profile an ebXML Registry MUST implement a new 6808 SAML interface in addition to its service interfaces such as QueryManager and 6809 LifeCycleManager. 6810 Details of the registry’s SAML interface are not described by this specification. Instead they are 6811 described by the SAML 2.0 specifications and MUST support SAML HTTP and SOAP requests. 6812 A registry uses its SAML interface to participate in SAML protocols with SAML Clients and 6813 SAML Identity Providers. Specifically, an IdentityProvider uses the registry’s SAML Service 6814 Provider interface to deliver the Response to an Authentication Request.

6815 13.5 Requirements for Registry SAML Profile 6816 In order to conform to the Registry SAML Profile a registry MUST implement specific SAML 6817 protocol that support specific SAML protocol message exchanges using specific protocol 6818 bindings. 6819 Table 13 lists the matrix of SAML Profiles, Protocols Messages and their Bindings that a registry 6820 MUST support in order to conform to the registry SAML Profile. 6821 The reader should refer to: 6822 • [SAMLProf] for description of profiles listed 6823 • [SAMLCore] for description of Message Flows listed 6824 • [SAMLBind] for description of Bindings listed 6825 Profile Message Flows Binding Implementation

Requirement

Web SSO from Registry to HTTP redirect MUST IdentityProvider

Profile Message Flows Binding Implementation

Requirement

IdentityProvider to HTTP POST MUST Registry HTTP artifact MUST

Single Logout HTTP redirect MUST

SOAP MAY

HTTP redirect MUST

SOAP MAY

, SOAP MUST Artifact Resolution SOAP MUST

Enhanced Client/Proxy ECP to Registry, Registry to ECP PAOS MUST SSO to IdentityProvider

IdentityProvider to ECP to Registry, PAOS MUST Registry to ECP 6826 6827 Table 13: Required SAML Profiles, Protocols and Bindings

6828 13.6 SSO Operation 6829 This section describes the interaction sequnce for various types of SSO operations.

6830 13.6.1 Scenario Actors 6831 The following are the actors that will be participating the the various SSO Operation scenarios 6832 described in subsequent section: 6833 • HTTP Requestor: This represents a Registry Client that accesses the registry using the 6834 HTTP binding of the registry protocols typically through a User Agent such as a Web 6835 Browser. 6836 • SOAP Requestor: This represents a Registry Client that accesses the registry using the 6837 SOAP binding of the registry protocols. 6838 • Registry: This represents a Registry and includes all Registry interfaces such as 6839 QueryManager, LifeCycleManager and the registry’s SAML Service Provider. The 6840 Registry is participates in ebXML Registry protocols as well as SAML protocols. 6841 • IdentityProvider: This represents the IdentityProvider used by the registry to perform 6842 Authentication on its behalf.

6843 13.6.2 SSO Operation – Unauthenticated HTTP Requestor 6844 Figure 51 shows a high level view of the Single Sign On (SSO) operation when the SOAP 6845 Requestor is unauthenticated and accesses the registry over HTTP via a User Agent such as a 6846 Web Browser.

6847 6848 Figure 51: SSO Operation – Unauthenticated HTTP Requestor

6849 13.6.2.1 Scenario Sequence 6850 Figure 51 shows the following sequence of steps for the operation: 6851 1 The HTTP Requestor sends a HTTP GET or POST request to a Registry interface such as 6852 the QueryManager or LifeCycleManager. 6853 1.1 The Registry checks to see if it already has a security context established for the Subject 6854 associated with the request. It determines that there is no pre-existing security context. 6855 1.2 In order to establish a security context, the Registry therefor initiates the 6856 protocol with the IdentityProvider. The is sent 6857 using HTTP Redirect via the User Agent (e.g. Web Browser) used by the HTTP Requestor.

6858 1.2.1 The IdentityProvider uses implementation specific means to identify the Subject. 6859 Typically this requires communicating with the User Agent being used by the HTTP 6860 Requestor to get the credentials associated with the Subject and then using the credentials 6861 to authenticate that the IdentityProvider knows the Subject. In case of SSL/TLS based 6862 communication the credetials are acquired without any user intervention directly from the 6863 User Agent. The figure assumes that the IdentityProvider is able to authenticate the 6864 Subject. 6865 1.2.2 The IdentityProvider sends a message containing a 6866 to the Registry using either HTTP POST or HTTP 6867 Artifact SAML Binding via the User Agent. 6868 1.2.2.1 The Registry uses implementation specific means to establish a security context for the 6869 Subject authenticated by the IdentityProvider based upon the information contained 6870 about the Subject in the message. This may include creating an 6871 HTTP Session for the HTTP Requestor. 6872 1.2.2.2 The Registry maps the information about the Subject in the message 6873 into a instance. This establishes the context for the security 6874 context. 6875 1.2.2.3 The Registry then performs authorization decision based upon the original HTTP 6876 request and the . The figure assumes that authorization decision was to 6877 allow the request to be processed. The Registry processes the request and subsequently 6878 return the requested resource to the HTTP Requestor via the HTTP response. 6879

6880 13.6.3 SSO Operation – Authenticated HTTP Requestor 6881 This is the case where the HTTP Requestor first authenticates with an IdentityProvider and then 6882 accesses the registry over HTTP via a User Agent such as a Web Browser. 6883 Currently there are no standard means defined for carrying SAML Assertions resulting from the 6884 Registry Requestor authenticating with an IdentityProvider over HTTP protocol to a Service 6885 Provider such as the registry. A registry MAY support this scenario in an implementation 6886 specific manner. Typically, the Identity Provider will define any such implementation specific 6887 manner.

6888 13.6.4 SSO Operation – Unuthenticated SOAP Requestor 6889 This is the case where an unauthenticated Registry Requestor accesses the registry over SOAP. 6890 Figure 52 shows the steps involved.

6891 6892 Figure 52: SSO Operation - Unauthenticated SOAP Requestor

6893 13.6.4.1 Scenario Sequence 6894 Figure 52 shows the following sequence of steps for the operation: 6895 1 The SOAP Requestor sends a SOAP message such as a 6896 to a Registry interface such as the 6897 LifeCycleManagerManager. In the request header the SOAP Requestor declares that it is an 6898 ECP requestor as defined by the ECP Profile in [SAMLProf]. 6899 1.1 The Registry checks to see if it already has a security context established for the Subject 6900 associated with the request. It determines that there is no pre-existing security context. 6901 1.2 Because the request is from an ECP client, the registry uses the ECP Profile defined by 6902 [SAMLProf] and sends a SOAP message as response to the 6903 SOAP message to the SOAP Requestor using the PAOS Binding as 6904 defined by [SAMLBind]. The response has an HTTP Response status of OK. 6905 1.2.1 The SOAP Requestor then initiates the protocol with the 6906 IdentityProvider. The is sent using HTTP POST or Artifact 6907 Binding directly to the IdentityProvider. 6908 1.2.1.1 The IdentityProvider uses implementation specific means to identify the Subject. 6909 Typically this requires communicating with the SOAP Requestor to get the credentials 6910 associated with the Subject and then using the credentials to authenticate that the 6911 IdentityProvider knows the Subject. In case of SSL/TLS based communication the 6912 credetials are acquired without any user intervention directly from the SOAP Requestor. 6913 The figure assumes that the IdentityProvider is able to authenticate the Subject.

6914 1.2.1.2 The IdentityProvider sends a message containing a 6915 to the SOAP Requestor using SAML SOAP Binding. 6916 The HTTP header specifies the Registry as the ultimate target of the response. 6917 1.2.1.2.1 The SOAP Requestor forwards the message containing a 6918 to the Registry using PAOS Binding via HTTP 6919 POST. 6920 1.2.1.2.1.1 The Registry uses implementation specific means to establish a security context for 6921 the Subject authenticated by the IdentityProvider based upon the information 6922 contained about the Subject in the message. This may include 6923 creating an HTTP Session for the HTTP Requestor. 6924 1.2.1.2.1.2 The Registry maps the information about the Subject in the 6925 message into a instance. This establishes the context for the 6926 security context. 6927 1.2.1.2.1.3 The Registry then performs authorization decision based upon the original SOAP 6928 request and the . The figure assumes that authorization decision was to 6929 allow the request to be processed. The Registry processes the request and 6930 subsequently return a SOAP message as response to the 6931 original SOAP request. 6932

6933 13.6.5 SSO Operation – Authenticated SOAP Requestor 6934 This is the case where the Registry Requestor first authenticates with an IdentityProvider directly 6935 and then makes a request to the registry using SOAP.

6936 6937 Figure 53: SSO Operation - Authenticated SOAP Requestor

6938 13.6.5.1 Scenario Sequence 6939 The figure shows the following sequence of steps for the operation: 6940 1 The SOAP Requestor then initiates the protocol directly with the 6941 IdentityProvider. The is sent using HTTP POST or Artifact Binding. 6942 1.1 The IdentityProvider uses implementation specific means to identify the Subject. Typically 6943 this requires communicating with the SOAP Requestor to get the credentials associated 6944 with the Subject and then using the credentials to authenticate that the IdentityProvider 6945 knows the Subject. In case of SSL/TLS based communication the credetials are acquired 6946 without any user intervention directly from the SOAP Requestor. The figure assumes that 6947 the IdentityProvider is able to authenticate the Subject. 6948 1.2 The IdentityProvider sends a message containing a 6949 to the SOAP Requestor using SAML HTTP POST or 6950 HTTP Artifact Binding.

6951 2 The SOAP Requestor sends a SOAP message such as a 6952 to a Registry interface such as the 6953 LifeCycleManagerManager. The SOAP message includes SAML 6954 Tokens in the of the SOAP message as defined by [WSS-SAML]. The 6955 SAML Tokens are based upon the during authentication. 6956 2.1 The registry maps the SAML Tokens from the of the 6957 to a instance. This establishes the context for the request. 6958 2.2 The Registry then performs authorization decision based upon the original SOAP request 6959 and the . The figure assumes that authorization decision was to allow the 6960 request to be processed. The Registry processes the request and subsequently return a 6961 SOAP message as response to the original 6962 SOAP request. 6963

6964 13.6.6 Generation Rules 6965 The following rules MUST be observed when the registry or Registry Client issues a 6966 : 6967 6968 • A registry MUST specify a NameIDPolicy within the 6969 • The Format of the NameIDPolicy MUST be urn:oasis:names:tc:SAML:2.0:nameid- 6970 format:persistent as defined by section in [SAMLCore]. Note that it is the Persistent 6971 Identifier that maps to the id attribute of . 6972

6973 13.6.7 Processing Rules 6974 This section describes how the registry processes the to a 6975 : 6976 Processing 6977 • Response Processing: The registry MUST verify the for the 6978 if present. 6979 • The registry MUST check the associated with for 6980 errors. If the the has a top level whose value is NOT 6981 urn:oasis:names:tc:SAML:2.0:status:Success then the registry MUST throw an 6982 AuthenticationException as defined by section 13.6.8. 6983 Processing 6984 • The registry SHOULD check the for Conditions and honour any 6985 standard Conditions defined by [SAMLCore] if any are specified. 6986 Processing 6987 • The registry MUST check the SessionNotOnOrAfter attribute of the 6988 for validity of the authenticated session. 6989 Processing 6990 • A registry MUST map the to a instance as described in 6991 13.6.8.

6992 13.6.8 Mapping Subject to User 6993 As required by [SAMLCore] a to a MUST contain a 6994 that identifies the Subject that was authenticated by the IdentityProvider. In 6995 addition it MUST contain a which asserts that the IdentityProvider 6996 indeed authenticated the Subject. 6997 The following table defines the mapping between a and a : 6998 Subject Attribute User Attribute Description NameID content id attribute NameID Format MUST be “urn:oasis:names:tc:SAML:1.1:nameid- format:persistent” 6999 Table 14: Mapping Subject to User 7000 Note that any attribute of Subject not specified above SHOULD be ignored when mapping 7001 Subject to User. Note that any attribute of User not specified above MUST be left unspecified 7002 when mapping Subject to User.

7003 13.6.9 AuthenticationException Mapping 7004 This section defines how a registry MUST map a from a failed 7005 : 7006 //TODO: Need to define how details of the SAML error are encoded in the 7007 AuthenticationException here.

7008 13.7 External Users 7009 The SAML Profile allows registry Users to be registered in an Identity Provider external to the 7010 registry. These are referred to as “External Users”. A registry dynamically creates such External 7011 Users by mapping a SAML Subject to a User instance dynamically. 7012 The following are some restrictions on External User instances: 7013 • External User instances are transient from the registry’s perspective and MUST not be 7014 stored within the registry as User instances 7015 • A RegistryObject MUST not have a reference to an External User unless it is composed 7016 within that RegistryObject. Composed RegistryObjects such as Classification instances 7017 are allowed to reference their parent External User instance. 7018 • Since External User instances are transient they MUST not match a registry Query. 7019 7020 7021

7331 15 References

7332 15.1 Normative 7333 [Bra97] Keywords for use in RFCs to Indicate Requirement Levels. 7334 [ebRIM] ebXML Registry Information Model version 3.0 7335 http://www.oasis-open.org/committees/regrep/documents/3.0/specs/ebRIM.pdf 7336 [ebRIM Schema] ebXML Registry Information Model Schema 7337 http://www.oasis-open.org/committees/regrep/documents/3.0/schema/rim.xsd 7338 [SAMLBind] S. Cantor et al., Bindings for the OASIS Security Assertion Markup Language 7339 (SAML) V2.0. OASIS SSTC, September 2004. Document ID sstc-saml-bindings-2.0-cd- 7340 02. See http://www.oasis-open.org/committees/security/. 7341 [SAMLConform] P. Mishra et al. Conformance Requirements for the OASIS Security Assertion 7342 Markup Language (SAML) V2.0. OASIS SSTC, September 2004. Document ID sstc- 7343 saml-conformance-2.0-cd-02. http://www.oasis-open.org/committees/security/. 7344 [SAMLCore1.0] E. Maler et al. Assertions and Protocol for the OASIS Security Assertion 7345 Markup Language (SAML). OASIS, November 2002. http://www.oasis- 7346 open.org/committees/download.php/1371/oasis-sstc-saml-core-1.0.pdf. 7347 [SAMLP-XSD] S. Cantor et al., SAML protocols schema. OASIS SSTC, September 2004. 7348 Document ID sstc-saml-schema-protocol-2.0. See http://www.oasis- 7349 open.org/committees/security/. 7350 [SAML-XSD] S. Cantor et al., SAML assertions schema. OASIS SSTC, September 2004. 7351 Document ID sstc-saml-schema-assertion-2.0. See http://www.oasis- 7352 open.org/committees/security/. 7353 [SQL] Structured Query Language (FIPS PUB 127-2) 7354 http://www.itl.nist.gov/fipspubs/fip127-2.htm 7355 [SQL/PSM] Database Language SQL — Part 4: Persistent Stored Modules 7356 (SQL/PSM) [ISO/IEC 9075-4:1996] 7357 ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets 7358 [RFC 1766] IETF (Internet Engineering Task Force). RFC 1766: 7359 Tags for the Identification of Languages, ed. H. Alvestrand. 1995. 7360 http://www.cis.ohio-state.edu/htbin/rfc/rfc1766.html 7361 [RFC 2119] IETF (Internet Engineering Task Force). RFC 2119 7362 [RFC 2130] IETF (Internet Engineering Task Force). RFC 2130 7363 [RFC 2277] IETF (Internet Engineering Task Force). RFC 2277: 7364 IETF policy on character sets and languages, ed. H. Alvestrand. 1998. 7365 http://www.cis.ohio-state.edu/htbin/rfc/rfc2277.html 7366 [RFC 2278] IETF (Internet Engineering Task Force). RFC 2278: 7367 IANA Charset Registration Procedures, ed. N. Freed and J. Postel. 1998. 7368 http://www.cis.ohio-state.edu/htbin/rfc/rfc2278.html 7369 [RFC2616] RFC 2616: 7370 Fielding et al. Hypertext Transfer Protocol -- HTTP/1.1 . 1999. 7371 http://www.w3.org/Protocols/rfc2616/rfc2616.html 7372 [REC-XML] W3C Recommendation. Extensible Markup language(XML)1.0(Second Edition) 7373 http://www.w3.org/TR/REC-xml

7374 [UUID] DCE 128 bit Universal Unique Identifier 7375 http://www.opengroup.org/onlinepubs/009629399/apdxa.htm#tagcjh_20 7376 http://www.opengroup.org/publications/catalog/c706.htmttp://www.w3.org/TR/REC-xml 7377 [WSDL] W3C Note. Web Services Description Language (WSDL) 1.1 7378 http://www.w3.org/TR/wsdl 7379 [SOAP11] W3C Note. Simple Object Access Protocol, May 2000, 7380 http://www.w3.org/TR/SOAP 7381 [SOAPAt] W3C Note: SOAP with Attachments, Dec 2000, 7382 http://www.w3.org/TR/SOAP-attachments 7383 [XMLDSIG] XML-Signature Syntax and Processing, 7384 http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/

7385 15.2 Informative 7386 [ebBPSS] ebXML Business Process Specification Schema 7387 http://www.ebxml.org/specs 7388 [ebCPP] ebXML Collaboration-Protocol Profile and Agreement Specification 7389 http://www.ebxml.org/specs/ 7390 [ebMS] ebXML Messaging Service Specification, Version 1.0 7391 http://www.ebxml.org/specs/ 7392 [DeltaV] Versioning Extension to WebDAV, IETF RFC 3253 7393 http://www.webdav.org/deltav/protocol/rfc3253.html 7394 [XPT] XML Path Language (XPath) Version 1.0 7395 http://www.w3.org/TR/xpath 7396 [IANA] IANA (Internet Assigned Numbers Authority). 7397 Official Names for Character Sets, ed. Keld Simonsen et al. 7398 [RFC 2828] IETF (Internet Engineering Task Force). RFC 2828: 7399 Internet Security Glossary, ed. R. Shirey. May 2000. 7400 http://www.cis.ohio-state.edu/htbin/rfc/rfc2828.html 7401 [RFC 3023] IETF (Internet Engineering Task Force). RFC 3023: 7402 XML Media Types, ed. M. Murata. 2001. 7403 ftp://ftp.isi.edu/in-notes/rfc3023.txt 7404 [SAMLMeta] S. Cantor et al., Metadata for the OASIS Security Assertion Markup Language 7405 (SAML) V2.0. OASIS SSTC, September 2004. Document ID sstc-saml- 7406 metadata-2.0-cd-02. See http://www.oasis-open.org/committees/security/. 7407 [SAMLProf] S. Cantor et al., Profiles for the OASIS Security Assertion Markup Language 7408 (SAML) V2.0. OASIS SSTC, September 2004. Document ID sstc-saml- 7409 profiles-2.0-cd-02. See http://www.oasis-open.org/committees/security/. 7410 [SAMLGloss] J. Hodges et al., Glossary for the OASIS Security Assertion Markup Language 7411 (SAML) V2.0. OASIS SSTC, September 2004. Document ID sstc-saml- 7412 glossary-2.0-cd-02. See http://www.oasis-open.org/committees/security/. 7413 [SAMLSecure] F. Hirsch et al., Security and Privacy Considerations for the OASIS Security 7414 Assertion Markup Language (SAML) V2.0. OASIS SSTC, September 2004. 7415 Document ID sstc-saml-sec-consider-2.0-cd-02. See http://www.oasis- 7416 open.org/committees/security/.