An Extension to the Web Browser Single-Sign-On Profile for Dynamic Automated Metadata Exchange with SAML
draft-poehn-dame-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Daniela Pöhn , Stefan Metzger , Wolfgang Hommel | ||
| Last updated | 2014-06-18 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-poehn-dame-00
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]