Integration of Dynamic Automated Metadata Exchange into the SAML 2.0 Web Browser SSO Profile
draft-poehn-dame-02
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-12-16 | ||
| RFC stream | Independent Submission | ||
| Formats | |||
| Stream | ISE state | Submission Received | |
| Consensus boilerplate | Unknown | ||
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-poehn-dame-02
Network Working Group D. Poehn
Internet-Draft S. Metzger
Intended status: Standards Track W. Hommel
Expires: June 19, 2015 Leibniz Supercomputing Centre
December 16, 2014
Integration of Dynamic Automated Metadata Exchange into the SAML 2.0 Web
Browser SSO Profile
draft-poehn-dame-02
Abstract
This document specifies the integration of Dynamic Automated Metadata
Exchange (DAME) through an intermediate trusted third party into the
Security Assertion Markup Language (SAML) 2.0 Web Browser SSO
Profile. The user-triggered, on-demand, and fully automated metadata
exchange between identity provider (IDP) and service provider (SP) is
intended for scenarios in which the a-priori, e.g., federation-based
exchange of SAML metadata is neither practical, scalable nor
mandatory for non-technical aspects, such as contract-based trust
building between IDP and SP. The main benefit of DAME is the removal
of waiting times for users and manual setup tasks for IDP and SP
administrators before users can access the service. Implementations
of DAME can leverage existing metadata repositories, such as REEP,
and metadata transfer procotols, such as MD Query.
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 June 19, 2015.
Poehn, et al. Expires June 19, 2015 [Page 1]
Internet-Draft Metadata Exchange in SAML Web SSO Profile December 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
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 . . . . . . . . . . . . . . . . . . . . . . . 4
2. SAML Profiles and Bindings . . . . . . . . . . . . . . . . . 4
3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Identifier . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. IDP Discovery . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Authentication Request Protocol using a TTP . . . . . . . 7
4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. IDP Discovery . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Authentication Request Protocol using TTP . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5.1. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 14
5.3. Use of SHA-1 . . . . . . . . . . . . . . . . . . . . . . 14
5.4. Inappropriate Usage . . . . . . . . . . . . . . . . . . . 15
5.5. Trust . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
In a federated identity management scenario, enabling communication
between an identity provider and a service provider is possible
within trust boundaries, which typically entails joining one or
several federations before the exchange of metadata takes place. The
exchange of SAML metadata is out of scope of the SAML specifications,
Poehn, et al. Expires June 19, 2015 [Page 2]
Internet-Draft Metadata Exchange in SAML Web SSO Profile December 2014
but normally done by sharing metadata files of all entities within
the trust boundaries.
This document specifies the HTTP-based [RFC7230] integration of SAML
metadata exchange into the SAML2 Web Browser SSO
[OASIS.saml-profiles-2.0-os] profile. Focusing on the automation and
the on-demand initiation of the metadata exchange between an identity
provider and a service provider to build a form of opportunistic
trust, even if these do not share membership in a common federation
a-priori or if regular federation scenarios are not suitable. This
could be the case in projects containing partners outside regular
federations. The initiation of the metadata exchange starts at the
identity provider discovery in order to keep the user experience
consistent with traditional federation-based service access.
This document specifies the initiation of the metadata exchange but
does not anticipate the use of either a public metadata registry or
the metadata query itself. The metadata exchange is triggered by a
trusted third party, which does not interfere in further
communication once identity provider and service provider have
successfully exchanged their metadata. In contrast to identity
provider proxies, the trusted third party does not cache assertions
nor is it involved in subsequent communication. 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 flexible solution,
either pull-based metadata exchange, such as MD Query
[I-D.young-md-query], or any kind of push mechanism can be used.
The degree of integration chosen for DAME explicitly does not imply
that disclosing personally identifiable information is required from
an identity provider by sending it to any particular service
provider. This is left to appropriate means, e.g., explicitly
acquiring user consent, in compliance with regulations and policies.
The described integration addresses the protocol, content and
processing of SAML messages for interoperability, referring to
[SAML2Int], but also specifies some deployment details and phases for
cross-boundary trust. Fitting in seamlessly with implemented SAML-
based SSO workflows and being scalable for a large number of users
and entities without exceeding administrative procedures, it enables
to participate in dynamically set up 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].
Poehn, et al. Expires June 19, 2015 [Page 3]
Internet-Draft Metadata Exchange in SAML Web SSO Profile December 2014
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 (IDP) and a receiving party (SP).
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.
SAML metadata information MUST be extended to support this protocol.
For each entity a TTPMetadataSyncLocation MUST be defined, e.g., for
an IDP idp.example.net. To ensure conformity and uniqueness of the
attribute the URN namespace urn:geant:lrz.de will be used:
<md:Extensions>
<ttp:TTPMetadataSyncLocation xmlns:ttp="urn:geant:lrz.de">
https://idp.example.net/idp/profile/SAML2/DAME
</ttp:TTPMetadataSyncLocation>
</md:Extensions>
Poehn, et al. Expires June 19, 2015 [Page 4]
Internet-Draft Metadata Exchange in SAML Web SSO Profile December 2014
3. Protocol
The protocol defined in this document MUST be divided into two
phases:
o Discovery of the appropriate IDP
o User authentication on behalf of the SP through a TTP
A. User authentication to TTP
B. On-demand metadata exchange
C. User authentication to SP
The protocol defined in this document primarily adds the on-demand
metadata exchange between IDP and SP, which is triggered by the user.
The exchange of the metadata itself is explicitly out of scope. The
authentication to the TTP step in the latter phase is required due to
the security considerations discussed below.
3.1. Identifier
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].
3.2. IDP Discovery
A web user attempts to access a secured resource provided by a SP via
an HTTP user agent. Missing an established technical trust
relationship, a certain IDP MUST be discovered by the discovery
functionality that is integrated into or accessible via the TTP.
Poehn, et al. Expires June 19, 2015 [Page 5]
Internet-Draft Metadata Exchange in SAML Web SSO Profile December 2014
User agent SP TTP
| | |
|----HTTP Request--->| |
| | |
|---HTTP Redirect----| |
| | |
|--------------------------HTTP Request----->|
| | |
|<------Selection of identity provider ----->|
| | |
|--------------------------HTTP Redirect-----|
| | |
|---HTTP Request---->| |
| | |
Figure 1: Identity provider discovery.
3.2.1. Redirect to trusted third party
Analogous to the SAML identity provider discovery profile
[OASIS.saml-idp-discovery], the SP redirects the user agent to the
TTP 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 be known to the TTP
through the metadata. The URLs depend on the implementation and MAY
include the literal string "DAME" as path element [RFC3986],
indicating the usage of this profile for dynamic automated metadata
exchange.
3.2.2. Response to service provider
The TTP MUST respond by redirecting the user agent back to the
requesting SP with an HTTP GET request message to the location
specified in the return parameter of the original request. The
unique identifier of the selected IDP MUST be included as value of
the query string parameter specified as returnIDParam or the entityID
if no parameter was supplied.
Poehn, et al. Expires June 19, 2015 [Page 6]
Internet-Draft Metadata Exchange in SAML Web SSO Profile December 2014
3.2.3. Failure processing
If the IDP 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 SP.
3.2.4. Further actions
After receiving the information about the selected IDP it is
RECOMMENDED that the SP verifies acceptance. If the IDP has not been
accepted, the SP halts processing and displays 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 SP. For this step, the authentication request of the SP is
cached and a new authentication request is sent to the IDP as both
entities do not have previously exchanged their metadata. These
authentication requests are REQUIRED to ensure that a metadata
exchange will be initiated only if the user has successfully been
authenticated by the selected IDP.
Poehn, et al. Expires June 19, 2015 [Page 7]
Internet-Draft Metadata Exchange in SAML Web SSO Profile December 2014
User agent SP TTP IDP
| | | |
|--HTTP Redirect-| | |
| | | |
|-----------AuthRequest1------------>| |
| | | |
| | | |
|--------------------HTTP Redirect---| |
| | | |
|----------------------------------------AuthRequest2--->|
| | | |
|<-----------------User authentication------------------>|
| | | |
| | |<---AuthResponse2--|
| | | |
| | |----MDI Request--->|
| | | |
| | |<---MDI Response---|
| | | |
| |<----MDI Request---| |
| | | |
| |---MDI Response--->| |
| | | |
| | | |
|--------------------HTTP Redirect---| |
| | | |
|----------------------------------------AuthRequest1--->|
| | | |
| |<-----------AuthResponse1--------------|
| | | |
|<-HTTP Response-| | |
| | | |
Figure 2: User authentication Request Protocol using a TTP.
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 IDP, the SP creates and sends a SAML
Authentication Request message (AuthnRequest) to the TTP using an
HTTP Redirect to transfer the message through the user agent. It is
RECOMMENDED that this request message is signed or otherwise
authenticated and integrity-protected by the requesting SP.
Poehn, et al. Expires June 19, 2015 [Page 8]
Internet-Draft Metadata Exchange in SAML Web SSO Profile December 2014
3.3.1.2. Store AuthnRequest at TTP
The TTP 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 IDP using a HTTP redirect message
to authenticate the user. The OPTIONAL "ForceAuthn"
[OASIS.saml-core-2.0-os] parameter MAY be included in the request.
The AuthnRequest message SHOULD be signed or otherwise authenticated
and integrity protected by the TTP or by the protocol binding used to
deliver the message.
3.3.1.4. User authentication
The user MUST be identified and authenticated by the IDP by some
means out of scope of this profile. A new authentication SHOULD be
performed unless the IDP can rely on a previously authenticated
session. A previous session MUST NOT be reused if the request
contains a "ForceAuthn" parameter.
3.3.1.5. Authentication Response to TTP
The IDP MUST issue a SAML AuthnResponse message to the TTP 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 IDP
or otherwise authenticated or integrity-protected.
3.3.2. Metadata Exchange orchestrated by TTP
In the second subphase, the metadata of SP and IDP are exchanged in a
way that is orchestrated and synchronized by the TTP.
3.3.2.1. MDI Request
After the user has been authenticated, the TTP MUST initiate the
metadata integration (MDI) between IDP and SP by a metadata
integration request. The MDI request SHOULD contain the query
elements "action=fetchmetadata" and the key element "entityID" with
the value element entityID of the requested entity.
The means used for the metadata exchange are implementation-
dependent. The TTP MAY trigger a metadata query as described by the
work in progress about the Metadata Query Protocol
[I-D.young-md-query].
Poehn, et al. Expires June 19, 2015 [Page 9]
Internet-Draft Metadata Exchange in SAML Web SSO Profile December 2014
IDP and SP MUST integrate each other's metadata in their
configuration. It is RECOMMENDED that the IDP is triggered regarding
metadata integration before the SP 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 TTP containing the
status of the integration.
If an entity was not able to integrate the metadata before sending
the response, the status MUST indicate this state and a new request
MUST be sent by the entity containing the status after the
integration.
If an error occurs integrating the metadata, the message MUST contain
a status describing the error and the TTP 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 SP MUST be presented by
the TTP to the IDP if no error occured beforehand. Because of the
successful user authentication already initiated by the trusted third
party, the IDP 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.
The IDP MUST issue a SAML AuthnResponse message to the services
provider's AssertionConsumerServiceURL. After receiving the
response, the SP MUST decide if the user gets access to the requested
resource based on the information contained within the SAML
assertion.
4. Example
Considering two organizations, SP S (sp.example.com) and identity
provider I (idp.example.net). User U initiates the SAML metadata
exchange between these entities using an user agent through the TTP T
(ttp.example.org).
Poehn, et al. Expires June 19, 2015 [Page 10]
Internet-Draft Metadata Exchange in SAML Web SSO Profile December 2014
4.1. IDP Discovery
After requesting access to a secured resource via HTTPS, S redirects
U to the discovery service of T:
GET /discovery/WAYF?entityID=https%3A%2F%2Fsp.example.com%2FSSO
&return=https%3A%2F%2Fsp.example.com%2FSSO%2FTTP%3FSAMLDS%3D1
%26target%3Dtarget HTTP/1.x
Host: ttp.example.org
U selects an appropriate IDP I:
GET /discovery/WAYF?entityID=https%3A%2F%2Fsp.example.com%2FSSO
&return=https%3A%2F%2Fsp.example.com%2FSSO%2FTTP%3FSAMLDS%3D1
%26target%3Dtarget%
&returnIDParam=entityID
&action=selection
&origin=https%3A%2F%2Fidp.example.net%2Fidp%2FSAMLidp
HTTP/1.x
Host: ttp.example.org
T redirects U back to S using the following message:
HTTP/1.x 302 Moved Temporarily
...
Location: https://sp.example.com/SSO/TTP?SAMLDS=1&target=target
&entityID=https%3A%2F%2Fidp.example.net%2Fidp%2FSAMLidp
GET /SSO/TTP?SAMLDS=1&target=target
&entityID=https%3A%2F%2Fidp.example.net%2Fidp%2FSAMLidp
Host: sp.example.com
4.2. Authentication Request Protocol using TTP
Receiving U's selection, S redirects the user to T containing a SAML
authentication request (AuthnRequest1):
HTTP/1.x 302 Found
...
Location:
https://ttp.example.org/discovery/TTP?action=authenticate
&idpEntityID=https%3A%2F%2Fidp.example.net%2Fidp%2FSAMLidp
&SAMLRequest=fZHNTsMwEIRfJf.....
...
Poehn, et al. Expires June 19, 2015 [Page 11]
Internet-Draft Metadata Exchange in SAML Web SSO Profile December 2014
GET /discovery/TTP?action=authenticate
&idpEntityID=https%3A%2F%2Fidp.example.net%2Fidp%2FSAMLidp
&SAMLRequest=fZHNTsMwEIRfJf.....
&RelayState=target
Host: ttp.example.org
T temporarily stores the authentication request and redirects U to I
sending a second authentication request (AuthnRequest2):
HTTP/1.x 302 Moved Temporarily
...
Location:
https://idp.example.net/idp/profile/SAML2/Redirect/SSO
?SAMLRequest=lZLBbhshEIZfBXHfh.....
...
GET /idp/profile/SAML2/Redirect/SSO
?SAMLRequest=lZLBbhshEIZfBXHfh..... HTTP/1.x
Host: idp.example.net
After successful authentication, I issues a SAML authentication
response message to T:
POST /discovery/TTP?action=SSO-Post HTTP/1.x
Host: ttp.example.org
Content-Type;: application/x-www-form-urlencoded
SAMLReponse=PD94bWwgdmVyc2lvb.....
As U is successfully authenticated I and S are triggered to fetch
each others metadata by T using the appropriate
TTPMetadataSyncLocation defined in the entitie's SAML metadata, e.g.,
/idp/profile/SAML2/DAME:
GET /idp/profile/SAML2/DAME?action=fetchmeta
?entityID=https%3A%2F%2Fsp.example.com%2FSSO HTTP/1.x
Host: idp.example.net
GET SSO/DAME?action=fetchmeta
?entityID=https%3A%2F%2Fidp.example.net%2Fidp%2FSAMLidp
Host: sp.example.com
The entities download the metadata from T using, e.g., Metadata Query
Protocol [I-D.young-md-query]. Only I's messages to download S's
metadata are presented here, S's messages are equivalent:
Poehn, et al. Expires June 19, 2015 [Page 12]
Internet-Draft Metadata Exchange in SAML Web SSO Profile December 2014
GET /metadataservice/entities/https%3A%2F%2Fsp.example.com%2F
SSO HTTP/1.x
Host: ttp.example.org
Accept: application/samlmetadata+xml
HTTP/1.x 200 OK
Content-Type: application/samlmetadata+xml
<?xml version="1.0" encoding="UTF-8"?>
<EntityDescriptor entityID="https://sp.example.com/SSO"
xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
...
After successful completion T forwards S's authentication request to
I:
HTTP/1.x 302 Moved Temporarily
...
Location:
https://idp.example.net/idp/profile/SAML2/Redirect/SSO
?SAMLRequest=fZHNTsMwEIRfJf.....
...
GET /idp/profile/SAML2/Redirect/SSO
?SAMLRequest=fZHNTsMwEIRfJf.....
&RelayState=target HTTP/1.x
Host: idp.example.net
I answers to S's AssertionConsumerServiceURL with a SAML Response:
POST /SSO/SAML2/POST HTTP/1.x
Host: sp.example.com
Content-Type: application/x-www-form-urlencoded
SAMLResponse=PD94bWwgdmVyc2lvb.....
Receiving the SAMLResponse, S redirects U to the requested resource:
HTTP/1.x 302 Found
...
Location: sp.example.com/secure
...
GET /secure HTTP/1.x
Host: sp.example.com
Poehn, et al. Expires June 19, 2015 [Page 13]
Internet-Draft Metadata Exchange in SAML Web SSO Profile December 2014
HTTP/1.x 200 OK
5. Security Considerations
5.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.
- 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.
5.2. Confidentiality
In many cases service metadata is public information and therefore
confidentiality SHOULD 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.
5.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
Poehn, et al. Expires June 19, 2015 [Page 14]
Internet-Draft Metadata Exchange in SAML Web SSO Profile December 2014
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.
5.4. Inappropriate Usage
This protocol mandates the authentication of users before any trust
between SP and IDP 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.
5.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 make use of one ore more additional mechanisms, e.g.,
the usage of flags in metadata, implementation depending mechanisms
in order to secure sensitive information, or to take organizational
measures, such as requiring written contracts between SPs and IDPs.
6. IANA Considerations
This document has no actions for IANA.
7. Acknowledgements
The research leading to these results has received funding from the
European Community's Seventh Framework Programme under grant
agreement no 605243 (GN3plus).
8. References
8.1. Normative References
[OASIS.saml-bindings-2.0-os]
Cantor, S., "Bindings for the OASIS Security Assertion
Markup Language (SAML) V2.0", March 2005.
Poehn, et al. Expires June 19, 2015 [Page 15]
Internet-Draft Metadata Exchange in SAML Web SSO Profile December 2014
[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-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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", January 2005.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", June 2014.
8.2. Informative References
[I-D.young-md-query]
Young, I., "Metadata Query Protocol, draft-young-md-
query-04 [work in progress]", October 2014.
[OASIS.saml-glossary-2.0-os]
Hodges, J., "Glossary for the OASIS Security Assertion
Markup Language (SAML) V2.0", March 2005.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", July 2013.
[SAML2Int]
Solberg, A., "Interoperable SAML2.0 Web Browser SSO
Deployment Profile", .
Poehn, et al. Expires June 19, 2015 [Page 16]
Internet-Draft Metadata Exchange in SAML Web SSO Profile December 2014
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
Wolfgang Hommel
Leibniz Supercomputing Centre
Boltzmannstrasse 1
Garching n. Munich, Bavaria 85748
Germany
Phone: +49 (0) 89 35831 7821
Email: hommel@lrz.de
Poehn, et al. Expires June 19, 2015 [Page 17]