idnits 2.17.1
draft-poehn-dame-06.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (June 28, 2016) is 2859 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112)
== Outdated reference: A later version (-20) exists of
draft-young-md-query-05
== Outdated reference: A later version (-20) exists of
draft-young-md-query-saml-05
Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group D. Poehn
3 Internet-Draft S. Metzger
4 Intended status: Informational Leibniz Supercomputing Centre
5 Expires: December 30, 2016 W. Hommel
6 M. Grabatin
7 Universitaet der Bundeswehr Muenchen
8 June 28, 2016
10 Integration of Dynamic Automated Metadata Exchange into the SAML 2.0 Web
11 Browser SSO Profile
12 draft-poehn-dame-06
14 Abstract
16 This document specifies the integration of Dynamic Automated Metadata
17 Exchange (DAME) through an intermediate trusted third party into the
18 Security Assertion Markup Language (SAML) 2.0 Web Browser SSO
19 Profile. The user-triggered, on-demand, and fully automated metadata
20 exchange between identity provider (IDP) and service provider (SP) is
21 intended for scenarios in which the a-priori, e.g., federation-based
22 exchange of SAML metadata is neither practical, scalable nor
23 mandatory for non-technical aspects, such as contract-based trust
24 building between IDP and SP. The main benefit of DAME is the removal
25 of waiting times for users and manual setup tasks for IDP and SP
26 administrators before users can access the service. Implementations
27 of DAME can leverage existing metadata repositories, such as REEP,
28 and metadata transfer protocols, such as MD Query.
30 Status of This Memo
32 This Internet-Draft is submitted in full conformance with the
33 provisions of BCP 78 and BCP 79.
35 Internet-Drafts are working documents of the Internet Engineering
36 Task Force (IETF). Note that other groups may also distribute
37 working documents as Internet-Drafts. The list of current Internet-
38 Drafts is at http://datatracker.ietf.org/drafts/current/.
40 Internet-Drafts are draft documents valid for a maximum of six months
41 and may be updated, replaced, or obsoleted by other documents at any
42 time. It is inappropriate to use Internet-Drafts as reference
43 material or to cite them other than as "work in progress."
45 This Internet-Draft will expire on December 30, 2016.
47 Copyright Notice
49 Copyright (c) 2016 IETF Trust and the persons identified as the
50 document authors. All rights reserved.
52 This document is subject to BCP 78 and the IETF Trust's Legal
53 Provisions Relating to IETF Documents
54 (http://trustee.ietf.org/license-info) in effect on the date of
55 publication of this document. Please review these documents
56 carefully, as they describe your rights and restrictions with respect
57 to this document. Code Components extracted from this document must
58 include Simplified BSD License text as described in Section 4.e of
59 the Trust Legal Provisions and are provided without warranty as
60 described in the Simplified BSD License.
62 Table of Contents
64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
65 1.1. Notation and Conventions . . . . . . . . . . . . . . . . 4
66 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
67 2. SAML Profiles and Bindings . . . . . . . . . . . . . . . . . 4
68 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 5
69 3.1. Identifier . . . . . . . . . . . . . . . . . . . . . . . 5
70 3.2. IDP Discovery . . . . . . . . . . . . . . . . . . . . . . 5
71 3.3. Authentication Request Protocol using a TTP . . . . . . . 7
72 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
73 4.1. IDP Discovery . . . . . . . . . . . . . . . . . . . . . . 11
74 4.2. Authentication Request Protocol using a TTP . . . . . . . 11
75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
76 5.1. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 13
77 5.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 14
78 5.3. Inappropriate Usage . . . . . . . . . . . . . . . . . . . 14
79 5.4. Trust . . . . . . . . . . . . . . . . . . . . . . . . . . 14
80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
83 8.1. Normative References . . . . . . . . . . . . . . . . . . 15
84 8.2. Informative References . . . . . . . . . . . . . . . . . 15
85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
87 1. Introduction
89 In a federated identity management scenario, enabling communication
90 between an identity provider and a service provider is possible
91 within trust boundaries, which typically entails joining one or
92 several federations before the exchange of metadata takes place. The
93 exchange of SAML metadata is out of scope of the SAML specifications,
94 but normally done by pre-sharing metadata files of all entities
95 within the trust boundaries.
97 This document specifies the HTTP-based [RFC7230] integration of SAML
98 metadata exchange into the SAML2 Web Browser SSO
99 [OASIS.saml-profiles-2.0-os] profile. Focusing on the automation and
100 the on-demand initiation of the metadata exchange between an identity
101 provider and a service provider to build a form of opportunistic
102 trust, even if these do not share membership in a common federation
103 a-priori or if regular federation scenarios are not suitable. This
104 could be the case in projects containing partners outside regular
105 federations. The initiation of the metadata exchange starts after
106 the identity provider discovery in order to keep the user experience
107 consistent with traditional federation-based service access.
109 This document specifies the initiation of the metadata exchange but
110 does not anticipate the use of either a public metadata registry or
111 the metadata query itself. The metadata exchange is triggered by a
112 trusted third party, which does not interfere in further
113 communication once identity provider and service provider have
114 successfully exchanged their metadata. In contrast to identity
115 provider proxies, the trusted third party does not cache assertions
116 nor is it involved in subsequent communication. Integrated identity
117 provider discovery, the mutual exchange of required SAML metadata,
118 and user authentication take place in a fully automated, user-
119 initiated, and on-demand manner. To provide a flexible solution,
120 either pull-based metadata exchange, such as the SAML Profile for MD
121 Query [I-D.young-md-query-saml], or any kind of push mechanism can be
122 used.
124 The degree of integration chosen for DAME explicitly does not imply
125 that disclosing personally identifiable information is required from
126 an identity provider by sending it to any particular service
127 provider. This is left to appropriate means, e.g., explicitly
128 acquiring user consent, in compliance with regulations and policies.
130 The described integration addresses the protocol, content and
131 processing of SAML messages for interoperability, referring to
132 [SAML2Int], but also specifies some deployment details and phases for
133 cross-boundary trust. Fitting in seamlessly with implemented SAML-
134 based SSO workflows and being scalable for a large number of users
135 and entities without exceeding administrative procedures, it enables
136 to participate in dynamically set up federations.
138 1.1. Notation and Conventions
140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
142 document are to be interpreted as described in [RFC2119].
144 1.2. Terminology
146 This document uses identity management terminology from [RFC6973] and
147 [OASIS.saml-glossary-2.0-os]. In particular, this document uses the
148 terms identity provider, service provider and identity management.
149 Furthermore, it uses following terminology:
151 Entity - A single logical construct for which metadata is provided.
152 This is usually either a service provider (SP) or an identity
153 provider (IDP).
155 Metadata - The SAML metadata specification is a machine-readable
156 description of certain entity characteristics and contains
157 information about, e.g., identifiers, endpoints, certificates and
158 keys.
160 Trusted Third Party - An intermediate entity facilitating interaction
161 between different entities, which trust the third party (TTP).
163 2. SAML Profiles and Bindings
165 Based on [OASIS.saml-profiles-2.0-os], SAML profiles define rules how
166 to embed SAML assertions in or combine them with other objects as
167 files or protocol data units of communication protocols. The profile
168 defined in this document is based on the existing SAML Web Browser
169 SSO profile, which implements the SAML Authentication Request
170 protocol [OASIS.saml-core-2.0-os] enhanced by a trusted entity
171 between an originating party (IDP) and a receiving party (SP).
173 A SAML binding [OASIS.saml-bindings-2.0-os] maps request-response
174 messages of the SAML protocol onto standard communication protocols.
175 For compliance reasons with the underlying Web Browser SSO profile,
176 the SAML HTTP Redirect and HTTP POST Bindings MUST be used.
178 SAML metadata information MUST be extended to support this protocol.
179 For each entity a MetadataSyncLocation MUST be defined, e.g., for an
180 IDP idp.example.net. To ensure conformity and uniqueness of the
181 attribute the URN namespace for GEANT [RFC4926] MUST be used:
183
184
185
186 https://idp.example.net/idp/profile/SAML2/DAME
187
188
189
191 3. Protocol
193 The protocol defined in this document MUST be divided into two
194 phases:
196 o Discovery of the appropriate IDP
198 o User authentication on behalf of the SP through a TTP
200 A. User authentication to TTP
202 B. On-demand metadata exchange
204 C. User authentication to SP
206 The protocol defined in this document primarily adds the on-demand
207 metadata exchange between IDP and SP, which is triggered by the user.
208 The exchange of the metadata itself is explicitly out of scope. The
209 authentication to the TTP step in the latter phase is required due to
210 the security considerations discussed below.
212 3.1. Identifier
214 entityID - Specifies the unique identity of an entity, whose metadata
215 is exchanged, as specified in [OASIS.saml-metadata-2.0-os] and
216 [OASIS.saml-idp-discovery].
218 3.2. IDP Discovery
220 A web user attempts to access a secured resource provided by a SP via
221 an HTTP user agent. Missing an established technical trust
222 relationship, a certain IDP MUST be discovered by the discovery
223 functionality that is integrated into or accessible via the TTP.
225 User agent SP TTP
226 | | |
227 |----HTTP Request--->| |
228 | | |
229 |---HTTP Redirect----| |
230 | | |
231 |--------------------------HTTP Request----->|
232 | | |
233 |<------Selection of identity provider ----->|
234 | | |
235 |--------------------------HTTP Redirect-----|
236 | | |
237 |---HTTP Request---->| |
238 | | |
240 Figure 1: Identity provider discovery.
242 3.2.1. Redirect to trusted third party
244 Analogous to the SAML identity provider discovery profile
245 [OASIS.saml-idp-discovery], the SP redirects the user agent to the
246 TTP with an HTTP GET request including the REQUIRED or OPTIONAL
247 parameters specified in [OASIS.saml-idp-discovery].
249 In distinction to the existing discovery profile, the OPTIONAL
250 "isPassive" parameter, which controls the visible interaction with
251 the user agent, SHOULD NOT be set to "true" in this profile. If the
252 parameter "isPassive" is used, the request sent to the TTP MUST
253 contain the entityID of the IDP as a URL query. The URL query is
254 indicated by the '?' operator, followed by variable name entityID,
255 '=', and the variable's value [RFC3986]. This template provides both
256 a structural description and machine-readable instructions.
258 The URLs of the participating entities MUST be known to the TTP
259 through the metadata. The URLs depend on the implementation and MAY
260 include the literal string "DAME" as query [RFC3986], indicating the
261 usage of this profile for dynamic automated metadata exchange.
263 3.2.2. Response to service provider
265 The TTP MUST respond by redirecting the user agent back to the
266 requesting SP with an HTTP GET request message to the location
267 specified in the return parameter of the original request. The
268 unique identifier of the selected IDP MUST be included as value of
269 the query string parameter specified as returnIDParam or the entityID
270 if no parameter was supplied.
272 3.2.3. Failure processing
274 If the IDP was not determined or the discovery service cannot answer
275 or an unspecified communication error occurs, the discovery service
276 MAY halt further processing, either displaying an error message to
277 the user agent or redirecting the user agent back to the SP.
279 3.2.4. Further actions
281 After receiving the information about the selected IDP it is
282 RECOMMENDED that the SP verifies acceptance. If the IDP has not been
283 accepted, the SP halts processing and displays an error message to
284 the user agent.
286 3.3. Authentication Request Protocol using a TTP
288 In the second phase of the protocol user authentication MUST be
289 performed. The trusted third party relays the SP's authentication
290 request to the IDP. For this step, the authentication request of the
291 SP is cached and a new authentication request is sent to the IDP as
292 both entities do not have previously exchanged their metadata. These
293 authentication requests are REQUIRED to ensure that a metadata
294 exchange will be initiated only if the user has successfully been
295 authenticated by the selected IDP.
297 User agent SP TTP IDP
298 | | | |
299 |--HTTP Redirect-| | |
300 | | | |
301 |-----------AuthRequest1------------>| |
302 | | | |
303 |--------------------HTTP Redirect---| |
304 | | | |
305 |----------------------------------------AuthRequest2--->|
306 | | | |
307 |<-----------------User authentication------------------>|
308 | | | |
309 | | |<---AuthResponse2--|
310 | | | |
311 | | |----MDI Request--->|
312 | | | |
313 | | |<---MDI Response---|
314 | | | |
315 | |<----MDI Request---| |
316 | | | |
317 | |---MDI Response--->| |
318 | | | |
319 |--------------------HTTP Redirect---| |
320 | | | |
321 |----------------------------------------AuthRequest1--->|
322 | | | |
323 | |<-----------AuthResponse1--------------|
324 | | | |
325 |<-HTTP Response-| | |
326 | | | |
328 Figure 2: User authentication Request Protocol using a TTP.
330 3.3.1. User authentication to trusted third party
332 In the first sub-phase the user MUST be authenticated by the selected
333 identity provider, but in distinction to [OASIS.saml-idp-discovery],
334 the trusted third party initiates the authentication.
336 3.3.1.1. Authentication Request of SP to TTP
338 After accepting the selected IDP, the SP creates and sends a SAML
339 Authentication Request message (AuthnRequest) to the TTP using an
340 HTTP Redirect to transfer the message through the user agent. It is
341 RECOMMENDED that this request message is signed or otherwise
342 authenticated and integrity-protected by the requesting SP.
344 3.3.1.2. Store AuthnRequest at TTP
346 The TTP MUST temporarily store the SAML AuthnRequest message by means
347 out of scope of this specification.
349 3.3.1.3. Authentication Request of TTP to IDP
351 After that, a second SAML AuthnRequest message MUST be sent by the
352 trusted third party to the selected IDP using a HTTP redirect message
353 to authenticate the user. The OPTIONAL "ForceAuthn"
354 [OASIS.saml-core-2.0-os] parameter MAY be included in the request.
355 The AuthnRequest message SHOULD be signed or otherwise authenticated
356 and integrity protected by the TTP or by the protocol binding used to
357 deliver the message.
359 3.3.1.4. User authentication
361 The user MUST be identified and authenticated by the IDP by some
362 means out of scope of this profile. A new authentication SHOULD be
363 performed unless the IDP can rely on a previously authenticated
364 session. A previous session MUST NOT be reused if the request
365 contains a "ForceAuthn" parameter.
367 3.3.1.5. Authentication Response to TTP
369 The IDP MUST issue a SAML AuthnResponse message to the TTP containing
370 one or more assertions or an error message with a status describing
371 the error occurred. The HTTP POST binding MUST be used to transfer
372 the message. It is RECOMMENDED that the message is signed by the IDP
373 or otherwise authenticated or integrity-protected.
375 3.3.2. Metadata Exchange orchestrated by TTP
377 In the second sub-phase, the metadata of SP and IDP are exchanged in
378 a way that is orchestrated and synchronized by the TTP.
380 3.3.2.1. MDI Request
382 After the user has been authenticated, the TTP MUST initiate the
383 metadata integration (MDI) between IDP and SP by a metadata
384 integration request. The URL [RFC3986] sent to the entities for the
385 MDI request SHOULD contain the query elements {?action,entityID}. The
386 variable name 'action' MUST be followed by '=' and the variable's
387 value 'fetchmetadata'. The variable name 'entityID' is followed by
388 '=' and the variable's value.
390 The means used for the metadata exchange are implementation-
391 dependent. The TTP MAY trigger a metadata query as described by the
392 work in progress about the Metadata Query Protocol
393 [I-D.young-md-query] and the SAML Profile for the Metadata Query
394 Protocol [I-D.young-md-query-saml].
396 IDP and SP MUST integrate each other's metadata in their
397 configuration. It is RECOMMENDED that the IDP is triggered regarding
398 metadata integration before the SP because it MAY object to accepting
399 certain service providers. But any kind of concurrent operation MAY
400 be supported.
402 It is RECOMMENDED that the TTP queries the IDP before the metadata
403 exchange because it MAY be the case that the IDP has already
404 integrated the SP's metadata. The IDP SHOULD then indicate the found
405 metadata by the appropriate HTTP status code according to
406 [I-D.young-md-query].
408 3.3.2.2. MDI Response
410 After each other's metadata is integrated, each entity MUST send a
411 metadata integration response message to the TTP containing the
412 status of the integration by the HTTP status code.
414 If an entity was not able to integrate the metadata before sending
415 the response, the status MUST indicate this state and a new request
416 MUST be sent by the entity containing the status after the
417 integration.
419 If an error occurs integrating the metadata, the message MUST contain
420 a HTTP status code describing the error and the TTP MUST halt further
421 processing by displaying an error message to the user agent. It is
422 RECOMMENDED to roll back any configuration changes by some means out
423 of scope of this specification.
425 3.3.3. User authentication to service provider
427 In last step the stored AuthnRequest of the SP MUST be presented by
428 the TTP to the IDP if no error occurred beforehand. Because of the
429 successful user authentication already initiated by the trusted third
430 party, the IDP SHOULD respond with an assertion transferred to the
431 service provider without further act of authentication, except for
432 the case where the request contains a "ForceAuthn" parameter.
434 The IDP MUST issue a SAML AuthnResponse message to the services
435 provider's AssertionConsumerServiceURL. After receiving the
436 response, the SP MUST decide if the user gets access to the requested
437 resource based on the information contained within the SAML
438 assertion.
440 4. Example
442 Considering two organizations, SP S (sp.example.com) and identity
443 provider I (idp.example.net). User U initiates the SAML metadata
444 exchange between these entities using an user agent through the TTP T
445 (ttp.example.org).
447 4.1. IDP Discovery
449 After requesting access to a secured resource via HTTPS, S redirects
450 U to the discovery service of T:
452 GET /discovery/DAME?entityID=https%3A%2F%2Fsp.example.com%2FSSO
453 &return=https%3A%2F%2Fsp.example.com%2FSSO%2FTTP%3FSAMLDS%3D1
454 %26target%3Dtarget HTTP/1.x
455 Host: ttp.example.org
457 U selects an appropriate IDP I. T redirects U back to S using the
458 following message:
460 HTTP/1.x 302 Found
461 ...
462 Location: https://sp.example.com/SSO/DAME?SAMLDS=1&target=target
463 &entityID=https%3A%2F%2Fidp.example.net%2Fidp%2FSAMLidp
465 GET /SSO/DAME?SAMLDS=1&target=target
466 &entityID=https%3A%2F%2Fidp.example.net%2Fidp%2FSAMLidp
467 Host: sp.example.com
469 4.2. Authentication Request Protocol using a TTP
471 Receiving U's selection, S redirects the user to T containing a SAML
472 authentication request (AuthnRequest1):
474 HTTP/1.x 302 Found
475 ...
476 Location:
477 https://ttp.example.org/discovery/DAME?action=authenticate
478 &idpEntityID=https%3A%2F%2Fidp.example.net%2Fidp%2FSAMLidp
479 &SAMLRequest=fZHNTsMwEIRfJf.....
480 ...
482 GET /DAME?action=authenticate
483 &SAMLRequest=fZHNTsMwEIRfJf.....
484 &RelayState=target
485 Host: ttp.example.org
487 T temporarily stores the authentication request and redirects U to I
488 sending a second authentication request (AuthnRequest2) containing
489 the SAML request:
491 GET /idp/profile/SAML2/Redirect/SSO
492 ?SAMLRequest=lZLBbhshEIZfBXHfh..... HTTP/1.x
493 Host: idp.example.net
495 After successful authentication, I issues a SAML authentication
496 response message to T:
498 POST /SSO/SAML2/POST HTTP/1.x
499 POSTDATA
500 Referer:...
501 Set-Cookie:...
503 As U is successfully authenticated, I and S are triggered to fetch
504 each others metadata by T using the appropriate
505 TTPMetadataSyncLocation defined in the entity's SAML metadata, e.g.,
506 /idp/profile/SAML2/DAME:
508 GET /idp/profile/SAML2/DAME?action=fetchmetadata
509 ?entityID=https%3A%2F%2Fsp.example.com%2FSSO HTTP/1.x
510 Host: idp.example.net
512 GET SSO/DAME?action=fetchmetadata
513 ?entityID=https%3A%2F%2Fidp.example.net%2Fidp%2FSAMLidp
514 Host: sp.example.com
516 The entities download the metadata from T using, e.g., SAML Profile
517 for Metadata Query Protocol [I-D.young-md-query-saml]. Only I's
518 messages to download S's metadata are presented here, S's messages
519 are equivalent:
521 GET /metadataservice/entities/https%3A%2F%2Fsp.example.com%2F
522 SSO HTTP/1.x
523 Host: ttp.example.org
524 Accept: application/samlmetadata+xml
526 HTTP/1.x 200 OK
527 Content-Type: application/samlmetadata+xml
528
529
531 ...
533 T sends a request to I and S in order to receive the status of the
534 integration:
536 GET /metadataservice/DAME?action=add&status=status HTTP/1.x
538 I answeres with:
540 HTTP/1.x 200 OK
542 After successful completion T forwards S's authentication request to
543 I:
545 GET /idp/profile/SAML2/Redirect/SSO
546 ?SAMLRequest=fZHNTsMwEIRfJf.....
547 &RelayState=target HTTP/1.x
548 Host: idp.example.net
550 I answers to S's AssertionConsumerServiceURL with a SAML Response:
552 POST /SSO/SAML2/POST HTTP/1.x
553 POSTDATA
554 ...
556 Receiving the SAMLResponse, S redirects U to the requested resource:
558 HTTP/1.x 302 Found
559 ...
560 Location: sp.example.com/secure
561 ...
563 GET /secure HTTP/1.x
564 Cookie...
566 HTTP/1.x 200 OK
568 5. Security Considerations
570 5.1. Integrity
572 As SAML metadata contains information necessary for the secure
573 operation of interacting services, it is strongly RECOMMENDED that a
574 mechanism for integrity checking is provided to clients. This MAY
575 include the use of SSL/TLS at the transport layer, digital signatures
576 present within the metadata document, or any other such mechanism.
578 It is RECOMMENDED that the integrity checking mechanism provided by a
579 responder is a digital signature embedded in the returned metadata
580 document, as defined by [OASIS.saml-metadata-2.0-os] section 3:
582 - SHOULD use an RSA key pair whose modulus is no less than 2048 bits
583 in length.
585 - SHOULD NOT use the SHA-1 cryptographic hash algorithm as a digest
586 algorithm.
588 - MUST NOT use the MD5 cryptographic hash algorithm as a digest
589 algorithm.
591 - SHOULD otherwise follow current cryptographic best practices in
592 algorithm selection.
594 5.2. Confidentiality
596 In many cases service metadata is public information and therefore
597 confidentiality SHOULD NOT be required. In those cases, where such
598 functionality is required, it is RECOMMENDED that both the requester
599 and responder support SSL/TLS. Other mechanisms, such as XML
600 encryption, MAY also be supported for privacy concerns.
602 5.3. Inappropriate Usage
604 This protocol mandates the authentication of users before any trust
605 between SP and IDP is technically established. Although this
606 requires a further step for users, it protects against inappropriate
607 usage of the user-initiated trust establishment process. An example
608 of inappropriate usage is triggering the metadata exchange for an
609 IDP, where the user has no account. Therefore, the user MUST be
610 authenticated before the metadata is exchanged.
612 5.4. Trust
614 This protocol enables the user to trigger the SAML metadata exchange
615 between two entities and establish the bi-directional technical trust
616 relationship. This is a prerequisite of the subsequent exchange of
617 user information.
619 For entities, which require a higher level of trust, it is
620 RECOMMENDED to make use of one ore more additional mechanisms, e.g.,
621 the usage of flags in metadata, implementation depending mechanisms
622 in order to secure sensitive information, or to take organizational
623 measures, such as requiring written contracts between SPs and IDPs.
625 6. IANA Considerations
627 This document has no actions for IANA.
629 7. Acknowledgements
631 The research leading to these results has received funding from the
632 European Community's Seventh Framework Programme under grant
633 agreement no 605243 (GN3plus).
635 8. References
637 8.1. Normative References
639 [OASIS.saml-bindings-2.0-os]
640 Cantor, S., "Bindings for the OASIS Security Assertion
641 Markup Language (SAML) V2.0", March 2005.
643 [OASIS.saml-core-2.0-os]
644 Cantor, S., "Assertions and Protocols for the OASIS
645 Security Assertion Markup Language (SAML) V2.0", March
646 2005.
648 [OASIS.saml-idp-discovery]
649 Cantor, S., "Identity Provider Discovery Service Protocol
650 and Profile", March 2008.
652 [OASIS.saml-metadata-2.0-os]
653 Cantor, S., "Metadata for the OASIS Security Assertion
654 Markup Language (SAML) V2.0", March 2005.
656 [OASIS.saml-profiles-2.0-os]
657 Cantor, S., "Profiles for the OASIS Security Assertion
658 Markup Language (SAML) V2.0", March 2005.
660 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
661 Requirement Levels", March 1997.
663 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
664 Resource Identifier (URI): Generic Syntax", January 2005.
666 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
667 (HTTP/1.1): Message Syntax and Routing", June 2014.
669 8.2. Informative References
671 [I-D.young-md-query]
672 Young, I., "Metadata Query Protocol, draft-young-md-
673 query-05 [work in progress]", April 2015.
675 [I-D.young-md-query-saml]
676 Young, I., "SAML Profile for Metadata Query Protocol,
677 draft-young-md-query-saml-05 [work in progress]", April
678 2015.
680 [OASIS.saml-glossary-2.0-os]
681 Hodges, J., "Glossary for the OASIS Security Assertion
682 Markup Language (SAML) V2.0", March 2005.
684 [RFC4926] Kalin, T. and M. Molina, "A URN Namespace for GEANT", July
685 2007.
687 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
688 Morris, J., Hansen, M., and R. Smith, "Privacy
689 Considerations for Internet Protocols", July 2013.
691 [SAML2Int]
692 Solberg, A., "Interoperable SAML2.0 Web Browser SSO
693 Deployment Profile".
695 Authors' Addresses
697 Daniela Poehn
698 Leibniz Supercomputing Centre
699 Boltzmannstrasse 1
700 Garching n. Munich, Bavaria 85748
701 Germany
703 Phone: +49 (0) 89 35831 8763
704 Email: poehn@lrz.de
706 Stefan Metzger
707 Leibniz Supercomputing Centre
708 Boltzmannstrasse 1
709 Garching n. Munich, Bavaria 85748
710 Germany
712 Phone: +49 (0) 89 35831 8846
713 Email: metzger@lrz.de
714 Wolfgang Hommel
715 Universitaet der Bundeswehr Muenchen, Computer Science Department
716 Werner-Heisenberg-Weg 39
717 Neubiberg, Bavaria 85577
718 Germany
720 Phone: +49 (0) 89 6004 2495
721 Email: wolfgang.hommel@unibw.de
723 Michael Grabatin
724 Universitaet der Bundeswehr Muenchen, Computer Science Department
725 Werner-Heisenberg-Weg 39
726 Neubiberg, Bavaria 85577
727 Germany
729 Phone: +49 (0) 89 6004 3992
730 Email: michael.grabatin@unibw.de