1 

InCommon Federation SAML2.0 Profiles 

2 

Working Draft 03 

3 

February18, 2010 

4 Document identifier: 

5 draft-incommon-saml2-profiles-03 

6 Location: 

7 TBD 

8 Editors: 

9 Scott Cantor, Internet2 / The Ohio State University 

10 Contributors: 
11 Andreas Åkre Solberg, UNINETT 

12 InCommon Federation Technical Advisory Committee 

13 Abstract: 
14 This document contains implementation and deployment profiles for SAML V2.0 recommended 
15 for use within the InCommon Federation. It includes a set of requirements for implementers of 
16 SAML products intended for use within the federation, and a narrower set of guidelines for 
17 deployers intended to foster interoperability. 

draft-incommon-saml2-profiles-03 Page 1 of 9 


Table of Contents 

1 Introduction...............................................................................................................................................3 
1.1 Notation.............................................................................................................................................3 
1.2 Normative References.......................................................................................................................4 
2 SAML V2.0 Browser SSO Implementation Profile.....................................................................................5 
2.1 Required Information.........................................................................................................................5 

2.2 Metadata and Trust Management......................................................................................................5 
2.3 IdentityProvider Discovery................................................................................................................6 
2.4 Name Identifiers................................................................................................................................6 
2.5 Attributes...........................................................................................................................................6 
2.6 Authentication Requests....................................................................................................................6 
2.6.1 Binding and SecurityRequirements............................................................................................6 
2.6.2 Message Content.......................................................................................................................7 
2.7 Responses........................................................................................................................................7 

2.7.1 Binding and SecurityRequirements............................................................................................7 
2.7.2 Message Content.......................................................................................................................7 
3 SAML V2.0 Browser SSO Deployment Profile..........................................................................................8 
3.1 Required Information.........................................................................................................................8 

3.2 Metadata and Trust Management......................................................................................................8 
3.3 Attributes...........................................................................................................................................8 
Appendix A. Open Issues.............................................................................................................................9 

draft-incommon-saml2-profiles-03 Page 2 of 9 


1 Introduction 

41 SAML V2.0 is a rich and extensible standard that must be profiled to be used interoperably, and the 
42 profiles that typically emerge from the broader standardization process usually remain fairly broad and 
43 include a number of options and features that increase the burden for implementers and make 
44 deployment-time decisions more difficult. The InCommon Federation, in consultation with its peer 

federations around the world, has developed a set of requirements and recommendations for both 
46 implementers and deployers that are intended to promote a baseline set of features and options required 
47 tointeroperatesecurelyandeffectively. 

48 It is the intent of the InCommon Federation to participate in the development and support of profiles more 
49 broadly,andthis documentis areflection of manysuchdiscussions (see [SAML2Int]in particular). The 
profiles defined here may evolve or be superseded in response to future developments where warranted. 

51 1.1 Notation 

52 This specification uses normative text to describe the use of SAML capabilities. 

53 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
54 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as 
described in [RFC 2119]: 

56 …they MUST only be used where it is actually required for interoperation or to limit behavior 
57 which has potential for causing harm (e.g., limiting retransmissions)… 

58 These keywords are thus capitalized when used to unambiguously specify requirements over protocol and 
59 application features and behavior that affect the interoperability and security of implementations. When 
these words are not capitalized, theyare meant in their natural-language sense. 

61 Listings of XML schemas appear like this. 
62 

63 Example code listings appear like this. 
64 Conventional XML namespace prefixes are used throughout the listings in this specification to stand for 
their respective namespaces as follows, whether or not a namespace declaration is present in the 
66 example: 

67 · The prefix saml2:stands for the SAML 2.0 assertion namespace, 
68 urn:oasis:names:tc:SAML:2.0:assertion 

69 · The prefix saml2p:stands for the SAML 2.0 protocol namespace, 
urn:oasis:names:tc:SAML:2.0:protocol 

71 · The prefix md:stands for the SAML 2.0 metadata namespace, 
72 urn:oasis:names:tc:SAML:2.0:metadata 

73 · The prefix idpdisc:stands for the IdentityProvider DiscoveryService Protocol and Profile 
74 [IdPDisco] namespace, urn:oasis:names:tc:SAML:profiles:SSO:idp-discoveryprotocol 


76 · The prefix mdattr:stands for the Metadata Extension for EntityAttributes Version 1.0 [MetaAttr] 
77 namespace, urn:oasis:names:tc:SAML:metadata:attribute 

78 This specification uses the following typographical conventions in text: <ns:Element>, Attribute, 
79 Datatype, OtherCode. 

draft-incommon-saml2-profiles-03 Page 3 of 9 


80 1.2 Normative References 
81 [RFC 2119] IETF RFC 2119, Key words for use in RFCs to Indicate Requirement Levels, 
March 1997. http://www.ietf.org/rfc/rfc2119.txt 
[RFC2616] IETF RFC 2616, Hypertext Transfer Protocol – HTTP/1.1, June 1999. 
http://www.ietf.org/rfc/rfc2616.txt 
[RFC2818] IETF RFC 2818, HTTP Over TLS, May 2000. http://www.ietf.org/rfc/rfc2818.txt 
[IdPDisco] OASIS Committee Specification, Identity Provider Discovery Service Protocol 
and Profile, March 2008. http://docs.oasis-open.org/security/saml/Post2.0/sstcsaml-
idp-discovery.pdf 
[MACEAttr] MACE-Dir Working Group Publication, MACE-Dir SAML Attribute Profiles, April 
2008. http://middleware.internet2.edu/dir/docs/internet2-mace-dir-saml-attributes200804.
pdf 
[MetaAttr] OASIS Committee Specification, SAML V2.0 Metadata Extension for Entity 
Attributes Version 1.0, August 2009. http://docs.oasisopen.
org/security/saml/Post2.0/sstc-metadata-attr.pdf 
[MetaIOP] OASIS Committee Specification, SAML V2.0 Metadata Interoperability Profile 
Version 1.0, August 2009. http://docs.oasis-open.org/security/saml/Post2.0/sstcmetadata-
iop.pdf 
[SAML2Core] OASIS Standard, Assertions and Protocols for the OASIS Security Assertion 
Markup Language (SAML) V2.0, March 2005. http://docs.oasisopen.
org/security/saml/v2.0/saml-core-2.0-os.pdf 
[SAML2Meta] OASIS Standard, Metadata for the OASIS Security Assertion Markup Language 
(SAML) V2.0, March 2005. http://docs.oasis-open.org/security/saml/v2.0/samlmetadata-
2.0-os.pdf 
[SAML2Bind] OASIS Standard, Bindings for the OASIS Security Assertion Markup Language 
(SAML) V2.0, March 2005. http://docs.oasis-open.org/security/saml/v2.0/samlbindings-
2.0-os.pdf 
[SAML2Prof] OASIS Standard, Profiles for the OASIS Security Assertion Markup Language 
(SAML) V2.0, March 2005. http://docs.oasis-open.org/security/saml/v2.0/samlprofiles-
2.0-os.pdf 
[SAML2Err] OASIS Approved Errata, SAML V2.0 Errata. http://docs.oasisopen.
org/security/saml/v2.0/sstc-saml-approved-errata-2.0.pdf 
[SAML2Int] A. Solberg et. al., Interoperable SAML 2.0 Web Browser SSO Deployment Profile, 
Draft. http://saml2int.org/profile/draftic 

draft-incommon-saml2-profiles-03 Page 4 of 9 


114 

2 SAMLV2.0 Browser SSOImplementation Profile 

115 This profile specifies behavior and options that implementations of the SAML V2.0 Web Browser SSO 
116 Profile [SAML2Prof] are required to support. The requirements specified are in addition to all normative 
117 requirements ofthe originalprofile, as modifiedbythe ApprovedErrata [SAML2Err], andreaders should 
118 be familiar with all relevantreference documents.Anysuch requirements are not repeatedhere except 
119 where deemednecessaryto highlight apoint ofdiscussion or drawattentionto an issueaddressedin 
120 errata, but remain implied. 

121 SAML leaves substantial latitude to implementations with regard to how software is architected and 
122 combined with authentication andapplication infrastructure. Where theterms "IdentityProvider" and 
123 "Service Provider" are used, they should be understood to include the total software footprint intended to 
124 providedthedesiredfunctionality; no specific assumptions are made as to howthe requiredfeatures are 
125 exposed to deployers, only that there is some method for doing so. 

126 2.1 Required Information 

127 Identification: urn:mace:incommon:profiles:saml2:browser-sso:implementation 

128 Contact information: admin@incommonfederation.org 

129 Description: Given below 

130 Updates: Nothing 

131 2.2 Metadata and Trust Management 

132 IdentityProvider, Service Provider, andDiscoveryService implementations MUST supportthe useof 
133 SAML V2.0 Metadata [SAML2Meta] in conjunction with their support of the SAML V2.0 Web Browser SSO 
134 Profile [SAML2Prof]. Additional expectations around the use of particular metadata elements related to 
135 profile behavior may be encountered in subsequent sections. 

136 Implementations MUST support the SAML V2.0 Metadata Interoperability Profile Version 1.0 [MetaIOP]. It 
137 is OPTIONAL for implementations to support the generation, publication, or exportation of metadata, but 
138 implementations MUST support the following mechanisms for the importation of metadata: 

139 • 
local file 

140 • 
remote resource at fixed location accessible via HTTP 1.1 [RFC2616] or HTTP 1.1 over TLS/SSL 
141 [RFC2818] 

142 In the case of HTTP resolution, implementations MUST support use of the "ETag" header for cache 
143 management; other cache control support is OPTIONAL. Implementations SHOULD support the use of 
144 more than one fixed location for the importation of metadata, but MAY leave their behavior unspecified if a 
145 single entity's metadata is present in more than one source. 

146 In accordance with [MetaIOP], importation of multiple entities' metadata contained within an 
147 <md:EntitiesDescriptor>element MUST be supported. 

148 Verification of metadata, if supported, MUST include XML signature verification at least at the root 
149 element level, and SHOULD support the following mechanisms for signature key trust establishment: 

150 • 
direct comparison against known keys 

151 • 
some form of path-based certificate validation against one or more trusted root certificates and 
152 certificate revocation lists 

draft-incommon-saml2-profiles-03 Page 5 of 9 


153 The latter mechanism does not impose a particular profile for certificate validation, as no such profile has 
154 wide enough adoption across tools and libraries to warrant such a requirement, but should be understood 
155 as being consistent with the "usual" practices encountered in the implementation of certificate validation. 
156 Where possible, implementations SHOULD document known limitations of the mechanisms they employ. 

157 Implementations SHOULD support the SAML V2.0 Metadata Extension for Entity Attributes Version 1.0 
158 [MetaAttr] and provide policy controls on the basis of SAML attributes supplied via this extension 
159 mechanism. 

160 Finally, implementations SHOULD allow for the automated updating/reimportation of metadata without 
161 substantial disruption of services. 

162 2.3 IdentityProvider Discovery 

163 Service Provider andDiscoveryService implementations MUST supportthe IdentityProviderDiscovery 
164 Service Protocol Profile in conformance with section 2.4.1 of [IdPDisco]. 

165 2.4 Name Identifiers 

166 IdentityProviderandService Provider implementations MUST supportthe followingSAMLV2.0name 
167 identifier formats, in accordance with the normative obligations associated with them by [SAML2Core]: 

168 • 
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent 

169 • 
urn:oasis:names:tc:SAML:2.0:nameid-format:transient 

170 Support for other formats is OPTIONAL. 

171 2.5 Attributes 

172 IdentityProviderandService Provider implementations MUST supportthe generation andconsumption of 
173 <saml2:Attribute>elements that conform to the MACE-Dir Attribute Profile for SAML 2.0 [MACEAttr], 
174 with the exception that the ability to support <saml2:AttributeValue> elements whose values are not 
175 simple strings (e.g., <saml2:NameID>, or other XML values) is OPTIONAL. 

176 As a non-normative summary, this requirement primarily implies the capability to ensure the use of 
177 particular Nameand NameFormat values when generating and consuming <saml2:Attribute> 
178 elements, rather than relying on hard-wired assumptions or proprietary sets of attribute identifiers. 

179 2.6 Authentication Requests 

180 2.6.1 Binding and Security Requirements 

181 IdentityProviderandService Provider implementations MUST supportthe useoftheHTTP-Redirect 
182 binding [SAML2Bind] for the transmission of <saml2p:AuthnRequest> messages, including the 
183 generation or verification of signatures in conjunction with this binding. 

184 Because verification ofsignatures byIdentityProviders cannotbe guaranteedin deployments,Service 
185 Provider implementations MUST NOT rely on the integrity of a signed request for the enforcement of 
186 requirements derived from options such as the ForceAuthn attribute or the 
187 <saml2p:RequestedAuthnContext>element. Rather, Service Providers MUST enforce such 
188 requirements based on the content of the <saml2p:Response> messages theyreceive. 

189 Support for other bindings is OPTIONAL. 

draft-incommon-saml2-profiles-03 Page 6 of 9 


190 2.6.2 Message Content 
191 In addition to standard core-and profile-driven requirements, Service Provider implementations MUST 
192 support the inclusion of at least the following <saml2p:AuthnRequest>child elements and attributes 
193 (when appropriate): 
194 • 
AssertionConsumerServiceURL 
195 • 
ProtocolBinding 
196 • 
ForceAuthn 
197 • 
IsPassive 
198 • 
AttributeConsumingServiceIndex 
199 • 
<saml2p:RequestedAuthnContext> 
200 • 
<saml2p:NameIDPolicy> 
201 IdentityProviderimplementations MUST support all <saml2p:AuthnRequest>child elements and 
202 attributes defined by [SAML2Core], but MAY provide that support in the form of returning appropriate 
203 errors when confronted by particular request options. However, implementations SHOULD fully support 
204 the options enumerated above. Implementations MAY limit their support of the 
205 <saml2p:RequestedAuthnContext>element to the value "exact" for the Comparisonattribute. 

206 2.7 Responses 

207 2.7.1 Binding and Security Requirements 

208 IdentityProviderandService Provider implementations MUST supportthe useoftheHTTP-POSTbinding 
209 [SAML2Bind] for the transmission of <saml2p:Response> messages. 

210 Support for other bindings is OPTIONAL. 

211 IdentityProviderandService Provider implementations MUST supportthe signing of 
212 <saml2:Assertion>elements in responses; support for signing of the <saml2p:Response> element 
213 is OPTIONAL. 

214 IdentityProviderandService Provider implementations MUST supportthe useofXMLEncryptionvia the 
215 <saml2:EncryptedAssertion>element; support for the <saml2:EncryptedID>and 
216 <saml2:EncryptedAttribute>elements is OPTIONAL. 

217 2.7.2 Message Content 

218 TheWebBrowser SSOProfile allows responses to contain anynumber of assertions andstatements. 
219 IdentityProviderimplementations MUST allowthe number of <saml2:Assertion>, 
220 <saml2:AuthnStatement>, and <saml2:AttributeStatement> elements in the 
221 <saml2p:Response>message to be limited to one. 

222 In turn, Service Provider implementations MAY limit support to a single instance of those elements when 
223 processing <saml2p:Response>messages. 

224 It is OPTIONAL for Identity Provider implementations to support the inclusion of a Consentattribute in 
225 <saml2p:Response>messages. 

226 Service Provider implementations that provide some form of session semantics MUST support the 
227 <saml2:AuthnStatement>element's SessionNotOnOrAfterattribute. 

draft-incommon-saml2-profiles-03 Page 7 of 9 


228 

3 SAMLV2.0 Browser SSODeployment Profile 

229 This profile is layered on, and supplements, the Interoperable SAML 2.0 Web Browser SSO Deployment 
230 Profile [SAML2Int] and identifies InCommon-specific requirements and recommendations that go beyond 
231 that specification. 

232 Note: The current reference to [SAML2Int] is to a draft version. This profile will 
233 remain in draft formuntil such time asastable version of that profile is available 
234 for reference. 

235 3.1 Required Information 

236 Identification: urn:mace:incommon:profiles:saml2:browser-sso:deployment 

237 Contact information: admin@incommonfederation.org 

238 Description: Given below, in conjunction with [SAML2Int]. 

239 Updates: Nothing 

240 3.2 Metadata and Trust Management 

241 Itis the responsibilityof eachdeploymenttoincorporate themetadatasuppliedbyInCommon into its trust 
242 management infrastructure. It is RECOMMENDED that use of the metadata conform to the SAML V2.0 
243 Metadata Interoperability Profile Version 1.0 [MetaIOP] and that metadata be updated at least daily. 

244 3.3 Attributes 

245 It is RECOMMENDED that any <saml2:Attribute> elements exchanged via anySAML 2.0 messages, 
246 assertions, or metadata conform to the MACE-Dir Attribute Profile for SAML 2.0 [MACEAttr]. 

draft-incommon-saml2-profiles-03 Page 8 of 9 


247 

Appendix A. Open Issues 

248 • 
Do we care enough about SessionNotOnOrAfter to require support for it? 

249 • 
Is making IOP "RECOMMENDED" a sufficient statement for deployers? What would it mean to 
250 consume the metadata in a different fashion? Seems like we should make it REQUIRED. 

251 • 
Should we make IdP-initiated SSO explicitlyOPTIONAL, or just allow that Shibboleth is non252 
conformant for the time being? 

draft-incommon-saml2-profiles-03 Page 9 of 9