System for Cross-domain Identity Management D. Poehn Internet-Draft S. Metzger Intended status: Standards Track W. Hommel Expires: December 20, 2014 Leibniz Supercomputing Centre June 18, 2014 An Extension to the Web Browser Single-Sign-On Profile for Dynamic Automated Metadata Exchange with SAML draft-poehn-dame-00 Abstract This document defines an extension for Dynamic Automated Metadata Exchange (DAME) of the Web Browser Single-Sign-On (SSO) Profile of the Security Assertion Markup Language (SAML) through an intermediate trusted third party. Besides integrated identity provider discovery, this enables the on-demand, user-initiated, and automated SAML metadata exchange for bi-directional pairing of provider entities, which allows technical trust establishment between Service Providers and Identity Providers without manual setup. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 20, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Poehn, et al. Expires December 20, 2014 [Page 1] Internet-DraftDynamic Automated Metadata Exchange with SAML June 2014 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Notation and Conventions . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. SAML Profiles and Bindings . . . . . . . . . . . . . . . . . 3 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. IDP Discovery . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Authentication Request Protocol using a TTP . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4.1. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 10 4.3. Use of SHA-1 . . . . . . . . . . . . . . . . . . . . . . 10 4.4. Inappropriate Usage . . . . . . . . . . . . . . . . . . . 10 4.5. Trust . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction In a federated identity management scenario, enabling communication between an identity provider and a service provider requires manual configuration on either side and, up to now, typically involves joining one or several federations before the exchange of metadata takes place. This document specifies an HTTP-based [RFC2616] enhanced SAML Web Browser SSO profile [OASIS.saml-profiles-2.0-os] and Authentication Request protocol. Integrated Identity Provider discovery, the mutual exchange of required SAML metadata, and user authentication take place in a fully automated, user-initiated, and on-demand manner. To provide a highly flexible solution, either pull-based metadata exchange, such as MD Query [I-D.young-md-query], or any kind of push mechanism are supported. This extension is focusing on the automation and the on- demand initiation of the SAML metadata exchange between an Identity Poehn, et al. Expires December 20, 2014 [Page 2] Internet-DraftDynamic Automated Metadata Exchange with SAML June 2014 Provder and an Service Provider, which do not share membership in a common federation a priori. The specified extension of the SAML Web Browser SSO profile is scalable for a large number of users and entities without exceeding administrative procedures. It becomes easy for entities and users to participate in dynamic federations. 1.1. Notation and Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.2. Terminology This document uses identity management terminology from [RFC6973] and [OASIS.saml-glossary-2.0-os]. In particular, this document uses the terms Identity Provider, Service Provider and Identity Management. Furthermore, it uses following terminology: Entity - A single logical construct for which metadata is provided. This is usually either a service provider (SP) or an identity provider (IDP). Metadata - The SAML metadata specification is a machine-readable description of certain entity characteristics and contains information about identifiers, endpoints, certificates and keys, etc. Trusted Third Party - An intermediate entity facilitating interaction between different entities, which trust the third party (TTP). 2. SAML Profiles and Bindings Based on [OASIS.saml-profiles-2.0-os], SAML profiles define rules how to embed SAML assertions in or combine them with other objects as files or protocol data units of communication protocols. The profile defined in this document is based on the existing SAML Web Browser SSO profile, which implements the SAML Authentication Request protocol [OASIS.saml-core-2.0-os] enhanced by a trusted entity between an originating party (identity provider) and a receiving party (service provider). A SAML binding [OASIS.saml-bindings-2.0-os] maps request-response messages of the SAML protocol onto standard communication protocols. For compliance reasons with the underlying Web Browser SSO profile, the SAML HTTP Redirect and HTTP POST Bindings MUST be used. Poehn, et al. Expires December 20, 2014 [Page 3] Internet-DraftDynamic Automated Metadata Exchange with SAML June 2014 3. Protocol The protocol defined in this document MUST be divided into two phases: o Discovery of the appropriate identity provider o User authentication on behalf of the service provider through a trusted third party A. User authentication to trusted third party B. On-demand metadata exchange C. User authentication to service provider The protocol defined in this document primarily adds the on-demand metadata exchange between IDP and SP, which is triggered by the user. The authentication to the TTP step in the latter phase is required due to the security considerations discussed below. 3.1. Identifiers entityID - Specifies the unique identity of an entity, whose metadata is exchanged, as specified in [OASIS.saml-metadata-2.0-os] and [OASIS.saml-idp-discovery]. sessionID - Unique declaration of the communication path between a certain service provider, identity provider, and the trusted third party. The value is of type string and the trusted third party MUST set it to contain a unique identifier. The service provider respectively the trusted third party MAY use this value as an index to the stored session information. 3.2. IDP Discovery A web user attempts to access a secured resource provided by a service provider via an HTTP user agent. Missing an established technical trust relationship, a certain identity provider MUST be discovered by the discovery functionality that is integrated into or accessible via the trusted third party. Poehn, et al. Expires December 20, 2014 [Page 4] Internet-DraftDynamic Automated Metadata Exchange with SAML June 2014 User agent SP TTP | | | |----HTTP Request--->| | | | | |---HTTP Redirect----| | | | | |--------------------HTTP Request----------->| | | | |<------Selection of identity provider ----->| | | | |--------------------------------------------| | | | |---HTTP Request---->| | | | | Figure 1: Identity provider discovery. Figure 1 3.2.1. Redirect to trusted third party Analogous to the SAML identity provider discovery profile [OASIS.saml-idp-discovery], the service provider redirects the user agent to the trusted third party with an HTTP GET request including the REQUIRED or OPTIONAL parameters specified in [OASIS.saml-idp-discovery]. In distinction to the existing discovery profile, the OPTIONAL "isPassive" parameter, which controls the visibly interaction with the user agent, MUST NOT be set to "true" in this profile. The URLs of the participating entities MUST include "DAME" as last path element before the query element [RFC3986], indicating the usage of this profile for dynamic metadata exchange. 3.2.2. Response to service provider The trusted third party MUST respond by redirecting the user agent back to the requesting service provider with an HTTP GET request message to the location specified in the return parameter of the original request. The unique identifier of the selected identity provider MUST be included as value of the query string parameter specified as returnIDParam or the entityID if no parameter was supplied. In a second query string parameter sessionID, the sessionID value determined by the trusted third party MUST be included. The internal Poehn, et al. Expires December 20, 2014 [Page 5] Internet-DraftDynamic Automated Metadata Exchange with SAML June 2014 storage of sessionIDs at the trusted third party is out of scope of this document. The omission of these two parameters indicates a failure. 3.2.3. Failure processing If the identity provider was not determined or the discovery service cannot answer or an unspecified communication error occurs, the discovery service MAY halt further processing, either displaying an error message to the user agent or redirecting the user agent back to the service provider. 3.2.4. Further actions After receiving the information about the selected identity provider it is RECOMMENDED that the service provider verifies acceptance. If the identity provider has not been accepted, e.g., because it is blacklisted by the service provider, the service provider halts processing by displaying an error message to the user agent. 3.3. Authentication Request Protocol using a TTP In the second phase of the protocol user authentication MUST be performed. The trusted third party authenticates the user on behalf of the service provider. This is REQUIRED to ensure that a metadata exchange will be initiated only if the user has successfully been authenticated by the selected identity provider. Poehn, et al. Expires December 20, 2014 [Page 6] Internet-DraftDynamic Automated Metadata Exchange with SAML June 2014 User agent SP TTP IDP | | | | |--HTTP Redirect-| | | | | | | |-----------AuthRequest1------------>| | | | | | | | |---AuthRequest2--->| | | | | |<-----------------User authentication------------------>| | | | | | | |<---AuthResponse2--| | | | | | | |----MDI Request--->| | | | | | | |<---MDI Response---| | | | | | |<----MDI Request---| | | | | | | |---MDI Response--->| | | | | | | | |---AuthRequest1--->| | | | | | |<-----------AuthResponse1--------------| Figure 2: User authentication Request Protocol using a TTP. Figure 2 3.3.1. User authentication to trusted third party In the first subphase the user MUST be authenticated by the selected identity provider, but in distinction to [OASIS.saml-idp-discovery], the trusted third party initiates the authentication. 3.3.1.1. Authentication Request of SP to TTP After accepting the selected identity provider, the service provider creates and sends a SAML Authentication Request message (AuthnRequest) to the trusted third party using a HTTP Redirect to transfer the message through the user agent. The sessionID parameter MUST be included as an additional query string parameter to link the authentication request with the previous identity provider selection. It is RECOMMENDED that this request message is signed or otherwise authenticated and integrity-protected by the requesting service provider. Poehn, et al. Expires December 20, 2014 [Page 7] Internet-DraftDynamic Automated Metadata Exchange with SAML June 2014 3.3.1.2. Store AuthnRequest at TTP The trusted third party MUST temporarily store the SAML AuthnRequest message by means out of scope of this specification. 3.3.1.3. Authentication Request of TTP to IDP After that, a second SAML AuthnRequest message MUST be sent by the trusted third party to the selected identity provider using a HTTP redirect message to authenticate the user. The OPTIONAL "ForceAuthn" parameter MAY be included in the request. The sessionID parameter MUST be included as an additional query string parameter. The AuthnRequest message SHOULD be signed or otherwise authenticated and integrity protected by the trusted third party or by the protocol binding used to deliver the message. 3.3.1.4. User authentication The user MUST be identified by the identity provider by some means out of scope of this profile. Either a new act of authentication MUST be performed or an existing authenticated session MAY be reused. A previous session MUST NOT be reused if the request contains a "ForceAuthn" parameter. 3.3.1.5. Authentication Response to TTP The identity provider MUST issue a SAML AuthnResponse message to the trusted third party containing one or more assertions or an error message with a status describing the error occurred. The HTTP POST binding MUST be used to transfer the message. It is RECOMMENDED that the message is signed by the identity provider or otherwise authenticated or integrity-protected. 3.3.2. Metadata Exchange orchestrated by TTP In the second subphase, the metadata of service provider and identity provider are exchanged in a way that is orchestrated and synchronized by the trusted third party. 3.3.2.1. MDI Request After the user has been authenticated, the trusted third party MUST initiate the metadata integration (MDI) between identity provider and service provider by a metadata integration request. The MDI request MUST contain "DAME" as last path element. It MUST contain the query elements "action=fetchmeta" and the key element "entityID" with the value element entityID of the requested entity. Poehn, et al. Expires December 20, 2014 [Page 8] Internet-DraftDynamic Automated Metadata Exchange with SAML June 2014 The means used for the metadata exchange are implementation- dependent. The trusted third party MAY trigger a metadata query as described by the work in progress about the Metadata Query Protocol [I-D.young-md-query]. Identity provider and service provider MUST integrate each other's metadata in their configuration. It is RECOMMENDED that the identity provider is triggered regarding metadata integration before the service provider because it MAY object to accepting certain service providers. But any kind of concurrent operation MAY be supported. 3.3.2.2. MDI Response After each other's metadata is integrated, each entity MUST send a metadata integration response message to the trusted third party containing the status of the integration. If an error occurs integrating the metadata, the message MUST contain a status describing the error and the trusted third party MUST halt further processing by displaying an error message to the user agent. It is RECOMMENDED to roll back any configuration changes by some means out of scope of this specification. 3.3.3. User authentication to service provider In last step the stored AuthnRequest of the service provider MUST be forwarded from the trusted third party to the identity provider. Because of the successful user authentication already initiated by the trusted third party, the identity provider SHOULD respond with an assertion transferred to the service provider without further act of authentication, except for the case where the request contains a "ForceAuthn" parameter. 4. Security Considerations 4.1. Integrity As SAML metadata contains information necessary for the secure operation of interacting services, it is strongly RECOMMENDED that a mechanism for integrity checking is provided to clients. This MAY include the use of SSL/TLS at the transport layer, digital signatures present within the metadata document, or any other such mechanism. It is RECOMMENDED that the integrity checking mechanism provided by a responder is a digital signature embedded in the returned metadata document, as defined by [OASIS.saml-metadata-2.0-os] section 3: - SHOULD use an RSA keypair whose modulus is no less than 2048 bits in length. Poehn, et al. Expires December 20, 2014 [Page 9] Internet-DraftDynamic Automated Metadata Exchange with SAML June 2014 - SHOULD NOT use the SHA-1 cryptographic hash algorithm as a digest algorithm. - MUST NOT use the MD5 cryptographic hash algorithm as a digest algorithm. - SHOULD otherwise follow current cryptographic best practices in algorithm selection. 4.2. Confidentiality In many cases service metadata is public information and therefore confidentiality MAY NOT be required. In those cases, where such functionality is required, it is RECOMMENDED that both the requester and responder support SSL/TLS. Other mechanisms, such as XML encryption, MAY also be supported for privacy concerns. 4.3. Use of SHA-1 This protocol mandates the availability of a identifier synonym mechanism based on the SHA-1 cryptographic hash algorithm. Although SHA-1 is now regarded as weak enough to exclude it from use in new cryptographic systems, its use in this profile is necessary for full support of the SAML 2.0 standard. Because the SHA-1 cryptographic hash is not being used within this protocol in the context of a digital signature, it is not believed to introduce a security concern over and above that which already exists in SAML due to the possibility of a post-hash collision between entities whose "entityID" attributes hash to the same value. Implementations may guard against this possibility by treating two entities whose "entityID" values have the same SHA-1 equivalent as an indicator of malicious intent on the part of the owner of one of the entities. 4.4. Inappropriate Usage This protocol mandates the authentication of users before any trust between service provider and identity provider is technically established. Although this requires a further step for users, it protects against inappropriate usage of the user-initiated trust establishment process. Therefore, the user MUST be authenticated before the metadata is exchanged. Poehn, et al. Expires December 20, 2014 [Page 10] Internet-DraftDynamic Automated Metadata Exchange with SAML June 2014 4.5. Trust This protocol enables the user to trigger the SAML metadata exchange between two entities and establish the bi-directional technical trust relationship. This is a prerequisite of the subsequent exchange of user information. For entities, which require a higher level of trust, it is RECOMMENDED to either make use of implementation depending mechanisms, e.g., blacklists and whitelists, in order to secure sensitive information, or to take organizational measures, such as requiring written contracts between service providers and identity providers. 5. IANA Considerations This document has no actions for IANA. 6. Acknowledgements The research leading to these results has received funding from the European Community's Seventh Framework Programme under grant agreement no 605243 (GN3plus). 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", June 1999. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", January 2005. [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", July 2013. 7.2. Informative References [I-D.young-md-query] Young, I., "Metadata Query Protocol, draft-young-md- query-02 [work in progress]", April 2014. Poehn, et al. Expires December 20, 2014 [Page 11] Internet-DraftDynamic Automated Metadata Exchange with SAML June 2014 [OASIS.saml-bindings-2.0-os] Cantor, S., "Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0", March 2005. [OASIS.saml-core-2.0-os] Cantor, S., "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0", March 2005. [OASIS.saml-glossary-2.0-os] Hodges, J., "Glossary for the OASIS Security Assertion Markup Language (SAML) V2.0", March 2005. [OASIS.saml-idp-discovery] Cantor, S., "Identity Provider Discovery Service Protocol and Profile", March 2008. [OASIS.saml-metadata-2.0-os] Cantor, S., "Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0", March 2005. [OASIS.saml-profiles-2.0-os] Cantor, S., "Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0", March 2005. Authors' Addresses Daniela Poehn Leibniz Supercomputing Centre Boltzmannstrasse 1 Garching n. Munich, Bavaria 85748 Germany Phone: +49 (0) 89 35831 8763 Email: poehn@lrz.de Stefan Metzger Leibniz Supercomputing Centre Boltzmannstrasse 1 Garching n. Munich, Bavaria 85748 Germany Phone: +49 (0) 89 35831 8846 Email: metzger@lrz.de Poehn, et al. Expires December 20, 2014 [Page 12] Internet-DraftDynamic Automated Metadata Exchange with SAML June 2014 Wolfgang Hommel Leibniz Supercomputing Centre Boltzmanstrasse 1 Garching n. Munich, Bavaria 85748 Germany Phone: +49 (0) 89 35831 7821 Email: hommel@lrz.de Poehn, et al. Expires December 20, 2014 [Page 13]