1 Shibboleth Architecture 2 Conformance Requirements 3 Working Draft 05, 24 February 2005 4 5 Document identifier: draft-mace-shibboleth-arch-conformance-05 6 7 Location: http://shibboleth.internet2.edu/shibboleth-documents.html 8 9 Editors: Scott Cantor (cantor.2@osu.edu), The Ohio State University 10 11 Contributors: RL "Bob" Morgan, University of Washington 12 13 14 15 Abstract: This specification provides the technical requirements for Shibboleth conformance. Shibboleth is itself built on the OASIS SAML 1.1 specification (http://www.oasis-open.org/committees/security). Readers should be familiar with that specification before reading this document. 16 17 18 Status: 1 2 This is a working draft and the text may change before completion. Please submit comments to the shibboleth-dev mailing list (see http://shibboleth.internet2.edu/ for subscription details). draft-mace-shibboleth-arch-conformance-05 24 February 2005 Page 1 of 6 19 Table of Contents 20 1 Introduction..................................................................................................................................................3 21 1.1 Notation................................................................................................................................................3 22 2 Profiles and Conformance Requirements...................................................................................................4 23 2.1 Shibboleth Profiles...............................................................................................................................4 24 29 2.2 Conformance.......................................................................................................................................4 2.2.1 Operational Modes.......................................................................................................................4 2.2.2 Feature Matrix...............................................................................................................................4 2.2.3 SAML Binding and Profile Requirements.....................................................................................5 2.2.4 Metadata Profile Requirements....................................................................................................5 3 References..................................................................................................................................................6 30 3.1 Normative References.........................................................................................................................6 31 3.2 Non-Normative References.................................................................................................................6 25 26 27 28 32 3 4 draft-mace-shibboleth-arch-conformance-05 24 February 2005 Page 2 of 6 33 1 Introduction 34 35 This normative specification describes features that are mandatory and optional for implementations claiming conformance to the Shibboleth Architecture specification ([ShibProt]). 36 1.1 Notation 37 This specification uses normative text to describe the use of SAML 1.1 and additional Shibboleth profiles. 38 39 40 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in [RFC 2119]: 41 42 …they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions)… 43 44 45 5 6 These keywords are thus capitalized when used to unambiguously specify requirements over protocol and application features and behavior that affect the interoperability and security of implementations. When these words are not capitalized, they are meant in their natural-language sense. draft-mace-shibboleth-arch-conformance-05 24 February 2005 Page 3 of 6 46 2 Profiles and Conformance Requirements 47 2.1 Shibboleth Profiles 48 The following set of profiles are recognized within [ShibProt] as making up the Shibboleth architecture: 49 Browser Authentication Request 50 Browser/POST Authentication Response 51 Browser/Artifact Authentication Response 52 Attribute Exchange 53 Transient NameIdentifier Format 54 Metadata Profile 55 2.2 Conformance 56 57 58 59 This section describes the technical conformance requirements for Shibboleth implementations. General conformance requirements for Shibboleth are derived from SAML 1.1 conformance requirements ([SAMLConf]). Where Shibboleth makes use of a SAML protocol or profile, the conformance requirements established by [SAMLConf] are assumed unless otherwise noted. 60 2.2.1 Operational Modes 61 62 This document uses the phrase “operational mode” to describe a role that a software component can play in conforming to Shibboleth. The operational modes are as follows: 63 IdP – Identity Provider 64 SP – Service Provider 65 2.2.2 Feature Matrix 66 67 The following matrix identifies basic conformance requirements in terms of which profiles must (or need not) be supported by particular components. Profile/Protocol IdP SP Browser Authentication Request MUST MUST Browser/POST Authentication Response MUST MUST Browser/Artifact Authentication Response MUST MUST Attribute Exchange MUST OPTIONAL Transient NameIdentifier Format MUST MUST Metadata Profile MUST MUST 68 7 8 draft-mace-shibboleth-arch-conformance-05 24 February 2005 Page 4 of 6 69 2.2.3 SAML Binding and Profile Requirements 70 71 72 73 Implementations of the Attribute Request/Response and the Browser/Artifact profiles MUST support the SOAP 1.1 SAML binding defined by [SAMLBind] and MUST adhere to its conformance requirements. In particular, implementations MUST support the mandatory authentication, confidentiality, and integrity mechanisms required by [SAMLBind]. 74 75 Implementations of the Browser/Artifact profile MUST support the "01" artifact type/format defined by [SAMLBind]. 76 2.2.4 Metadata Profile Requirements 77 78 79 80 81 82 83 It is somewhat difficult to create testable conformance requirements for the support of metadata. In the interest of interoperability, the intent of this requirement is to ensure that a consistent approach to the public exchange of configuration and trust information is possible. Support for this profile does not require that implementations provide native support for or configure themselves via this format. They must only provide a reasonable mechanism to consume it in some fashion in order to establish the necessary configuration that enables partnering deployments to successfully make use of the other profiles. The focus is therefore on consumption rather than production of the information. 84 85 It is specifically OPTIONAL to support the dynamic acquisition and use of metadata in real time using the resolution mechanism defined by the profile. 9 10 draft-mace-shibboleth-arch-conformance-05 24 February 2005 Page 5 of 6 86 3 References 87 The following works are cited in the body of this specification. 88 3.1 Normative References 89 90 [RFC 2119] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. IETF RFC 2119, March 1997. http://www.ietf.org/rfc/rfc2119.txt. 91 92 [ShibProt] S. Cantor et al. Shibboleth Architecture: Protocols and Profiles. Internet2-MACE, February 2005. http://shibboleth.internet2.edu/shibboleth-documents.html. 93 94 95 [SAMLBind] E. Maler et al. Bindings and Profiles for the OASIS Security Assertion Markup Language (SAML). OASIS, September 2003. Document ID oasis-sstc-samlbindings-profiles-1.1. http://www.oasis-open.org/committees/security/. 96 97 98 [SAMLConf] E. Maler et al. Conformance Program Specification for the OASIS Security Assertion Markup Language (SAML). OASIS, September 2003. Document ID oasis-sstc-saml-conform-1.1. http://www.oasis-open.org/committees/security/. 99 100 101 102 11 12 3.2 Non-Normative References [SAML2Conf] P. Mishra et al. Conformance Program Specification for the OASIS Security Assertion Markup Language (SAML) V2.0. OASIS SSTC, March 2005. Document ID oasis-sstc-saml-conform-2.0. http://www.oasis-open.org/committees/security/. draft-mace-shibboleth-arch-conformance-05 24 February 2005 Page 6 of 6