Abstract

This document contains an implementation profile for eGovernment use of SAML V2.0, suitable for the purposes of testing conformance of implementations of SAML V2.0. It is not a deployment profile, and does not provide for or reflect specific behavior expected of implementations when used within a particular deployment context.

Status

This document is a transformation of the document from 11 June 2011 into the Asciidoc format. While keeping the requirements as-is, the goal was to change the format to establish a more formally structured baseline for a comparison with the successor of this profile.

The original document is referenced as [eGov] can be downloaded at: http://kantarainitiative.org/confluence/download/attachments/38929505/kantara-report-egov-saml2-profile-2.0.pdf

For license and authors refer to the original document.

Editor of this document format: Rainer Hörbe

1. Introduction

SAML V2.0 is a rich and extensible standard that must be profiled to be used interoperably, and the profiles that typically emerge from the broader standardization process usually remain fairly broad and include a number of options and features that increase the burden for implementers and make deployment-time decisions more difficult. The Kantara Initiative eGovernment Implementation Profile provides a SAML V2.0 conformance specification for Identity Provider and Service Provider implementations operating in eGovernment federations and deployments. The profile is based on the SAML V2.0 specifications created by the Security Services Technical Committee (SSTC) of OASIS, and related specifications approved by that body. It constrains and supplements the base SAML V2.0 features, elements, and attributes required for eGovernment federations and deployments. Implementation profiles define the features that software implementations must support such that deployers can be assured of the ability to meet their own (possibly varied) deployment requirements. Deployment profiles define specific options and constraints to which deployments are required to conform; they guide product configuration and federation operations, and provide criteria against which actual deployments may be tested. This document does not include a deployment profile, but reflects the features deemed necessary or desirable from software implementations in support of a variety of deployment profiles planned and in use. This includes requirements deemed useful to further the eventual goal of interfederation between deployments. === Notation This specification uses normative text to describe the use of SAML capabilities. 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 [RFC2119]

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 example:

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

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

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

  • The prefix idpdisc: stands for the Identity Provider Discovery Service Protocol and Profile [IdPDisco] namespace, urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol

  • The prefix mdattr: stands for the Metadata Extension for Entity Attributes Version 1.0 [MetaAttr] namespace, urn:oasis:names:tc:SAML:metadata:attribute

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

Requirements are written in a terse table format with identifiers for better reference. Traceability to the previous format is provided by the "source" attribute with the format "document/line number(s)", with document being "eGov" for [eGov], and "InC Draft" for InCommon DRAFT SAML Implementation Profile. === Changes since [eGov] from 11 June 2010

Requirements are enumerated and have been changed to be context free, i.e. references like "as above" have been replaced by the referenced text.

2. SAML V2.0 Implementation Profile

2.1. Required Information

Identification of the original document: http://kantarainitiative.org/eGov/profiles/SAML2.0/v2.0

Contact information: http://kantarainitiative.org/confluence/display/eGov/Home

Updates: Liberty Alliance eGov Profile for SAML 2.0 [eGov15]

2.2. Metadata and Trust Management

2.2.1. Metadata Profiles

Table 1. Supported SAML metadata profiles and capabilites ([eGov])
RequID IDP SP Line Requirement

eGov-001

MUST

MUST

161

Support the SAML V2.0 Metadata Interoperability Profile Version 1.0 [SAML2MDIOP].

eGov-002

MUST

MUST

165

Support the <ds:X509Certificate> element as key representation int the <md:KeyDescriptor> element

eGov-003

MAY

MAY

166

Support for other key representations than <ds:X509Certificate>, and for other mechanisms for credential distribution

eGov-004

MUST

MUST

168

Support some form of path validation of signing, TLS, and encryption credentials used to secure SAML exchanges against one or more trusted certificate authorities.

eGov-005

SHOULD

SHOULD

170

Support for PKIX [RFC5280]. Implementations SHOULD document the behavior of the validation mechanisms they employ, particular with respect to limitations or divergence from PKIX [RFC5280]

eGov-006

MUST

MUST

175

Support the use of OCSP [RFC2560] and Certificate Revocation Lists (CRLs) obtained via the 'CRL Distribution Point' X.509 extension [RFC5280] for revocation checking of those credentials.

eGov-007

MAY

MAY

177

Support additional constraints on the contents of certificates used by particular entities, such as 'subjectAltName' or 'DN', key usage constraints, or policy extensions. Implementations SHOULD document such features and make them optional to enable where possible.

eGov-008

SHOULD

SHOULD

184

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

2.2.2. Metadata Exchange

Table 2. Requirements for SAML metadata exchange
RequID IDP SP Line Requirement

eGov-010

MAY

MAY

188

Support the generation or exportation of metadata.

eGov-011

MUST

MUST

189

Support the publication of metadata using the Well-Known-Location method defined in section 4.1 of [SAML2Meta] (under the assumption that entityID values used are suitable for such support).

eGov-012

MUST

MUST

194

Support the importation of metadata from a local file.

eGov-013

MUST

MUST

195

Support the importation of metadata from a remote resource at fixed location accessible via HTTP 1.1 or HTTP 1.1 over TLS/SSL. Implementations MUST support use of the 'ETag' and 'Last-Modified' headers for cache management.

eGov-014

SHOULD

SHOULD

198

Support the use of more than one fixed location for the importation of metadata, but MAY leave their behavior unspecified if a single entity’s metadata is present in more than one source.

eGov-015

MUST

MUST

201

Support importation of multiple entities' metadata contained within an <md:EntitiesDescriptor> element.

eGov-016

SHOULD

SHOULD

203

Allow for the automated updating/reimportation of metadata without service degradation or interruption.

eGov-017

MUST

MUST

206

Verification of metadata, if supported, MUST include XML signature verification at least at the root element level

eGov-018

SHOULD

SHOULD

209

Verification of metadata SHOULD support direct comparison against known keys as mechanism for signature key trust establishment.

eGov-019

SHOULD

SHOULD

210

Verification of metadata SHOULD support some form of path-based certificate validation against one or more trusted certificate authorities, along with certificate revocation lists and/or OCSP [RFC2560]. Support for PKIX [RFC5280] is RECOMMENDED. Implementations SHOULD document the behavior of the validation mechanisms they employ, particular with respect to limitations or divergence from PKIX [RFC5280].

2.3. Name Identifier Formats

In conjunction with their support of the SAML V2.0 profiles referenced by subsequent sections, Identity Provider and Service Provider implementations MUST support the following SAML V2.0 name identifier formats, in accordance with the normative obligations associated with them by [SAML2Core]:

Table 3. Supported SAML Name Identifier formats and semantics (from eGov)
RequID IDP SP Line Format Identifier

eGov-021

MUST

MUST

221

urn:oasis:names:tc:SAML:2.0:nameid-format:persistent (see [SAML2Core] sect. 8.3)

eGov-022

MUST

MUST

222

urn:oasis:names:tc:SAML:2.0:nameid-format:transient (see [SAML2Core] sect. 8.3)

2.4. Attribute Name Formats

In conjunction with their support of the SAML V2.0 profiles referenced by subsequent sections, Identity Provider and Service Provider implementations MUST support the generation and consumption of <saml2:Attribute> elements that conform to the SAML V2.0 X.500/LDAP Attribute Profile [SAML-X500]. The ability to support <saml2:AttributeValue> elements whose values are not simple strings (e.g., <saml2:NameID>, or other XML values) is OPTIONAL. Such content could be base64-encoded as an alternative.

Table 4. Supported SAML attribute elements
RequID IDP SP Line Requirement

eGov-030

MUST

MUST

225

Support attribute name format urn:oasis:names:tc:SAML:2.0:attrname-format:uri (see [SAML-X500] sect. 2.3)

eGov-031

MUST

MUST

231

Support xs:string as attribute values; other types are optional (see [SAML2Core] sect. 2.7.3.1.1)

2.5. Browser Single Sign-On

RequID IDP SP Line Requirement

eGov-032

MUST

MUST

233

Support the implementation profile of the SAML V2.0 Web Browser SSO Profile [SAML2Prof].

2.5.1. Identity Provider Discovery

Table 5. IDP discovery protocol
RequID IDP SP Line Requirement

eGov-033

MUST

MUST

227

Support the Identity Provider Discovery Service Protocol Profile in conformance with section 2.4.1 of [IdPDisco].

2.5.2. Authentication Requests

Table 6. Authentication Request Binding and Security Requirements
RequID IDP SP Line Requirement

eGov-040

MUST

MUST

241

Support the use of the HTTP-Redirect binding [SAML2Bind] for the transmission of <saml2p:AuthnRequest> messages, including the generation or verification of signatures in conjunction with this binding.
Table 7. Authentication Request Message Contents
RequID IDP SP Line Requirement

eGov-041

MUST

247

Support the inclusion of at least the following <saml2p:AuthnRequest> child elements and attributes (when appropriate).

  • AssertionConsumerServiceURL

  • ProtocolBinding

  • ForceAuthn

  • IsPassive

  • AttributeConsumingServiceIndex

  • <saml2p:RequestedAuthnContext>

  • <saml2p:NameIDPolicy>

eGov-042

MUST

257

Support all <saml2p:AuthnRequest> child elements and attributes defined by [SAML2Core], but MAY provide that support in the form of returning appropriate errors when confronted by particular request options.

eGov-043

MUST

262

MUST support any allowable content of the <saml2p:RequestedAuthnContext> element but MAY limit their support of the element to the value "exact" for the Comparison attribute.

eGov-044

MUST

260

MUST fully support the options enumerated in [eGov-041], and be configurable to utilize those options in a useful manner as defined by [SAML2Core].

eGov-045

MUST

266

MUST support verification of requested AssertionConsumerServiceURL locations via comparison to <md:AssertionConsumerService> elements supplied via metadata using case-sensitive string comparison. It is OPTIONAL to support other means of comparison (e.g., canonicalization or other manipulation of URL values) or alternative verification mechanisms.

2.5.3. Responses

Table 8. Response Binding and Security Requirements
RequID IDP SP Line Requirement

eGov-050

MUST

MUST

274

Support the use of the HTTP-POST and HTTP-Artifact bindings [SAML2Bind] for the transmission of <saml2p:Response> messages.

eGov-051

MAY

MAY

277

Support for other bindings, and for artifact types other than urn:oasis:names:tc:SAML:2.0:artifact-04

eGov-052

MUST

MUST

279

Support the generation and consumption of unsolicited <saml2p:Response> messages (i.e., responses that are not the result of a <saml2p:AuthnRequest> message). (see [SAML2Prof] sect. 4.1.5)

eGov-053

MUST

282

Support the issuance of <saml2p:Response> messages (with appropriate status codes) in the event of an error condition, provided that the user agent remains available and an acceptable location to which to deliver the response is available. The criteria for "acceptability" of a response location are not formally specified, but are subject to Identity Provider policy and reflect its responsibility to protect users from being sent to untrusted or possibly malicious parties. Note that this is a stronger requirement than the comparable language in [SAML2Prof].

eGov-054

MUST

MUST

290

Support the signing of <saml2:Assertion> elements in responses; support for signing of the <saml2p:Response> element is OPTIONAL.

eGov-055

MUST

MUST

293

Support the use of XML Encryption via the <saml2:EncryptedAssertion> element when using the HTTP-POST binding; support for the <saml2:EncryptedID> and <saml2:EncryptedAttribute> elements is OPTIONAL.
Table 9. Response Message Contents
RequID IDP SP Line Requirement

eGov-061

MUST

299

Allow the number of <saml2:Assertion>, <saml2:AuthnStatement>, and <saml2:AttributeStatement> elements in the <saml2p:Response> message to be limited to one.

eGov-062

MAY

302

Limit support to a single instance of <saml2:Assertion>, <saml2:AuthnStatement>, and <saml2:AttributeStatement> elements when processing <saml2p:Response> messages

eGov-063

MUST

304

Support the inclusion of a Consent attribute in <saml2p:Response> messages

eGov-064

MUST

305

Support the inclusion of a SessionIndex attribute in <saml2:AuthnStatement> elements

eGov-065

MUST

307

Implementations that provide some form of session semantics MUST support the <saml2:AuthnStatement> element’s SessionNotOnOrAfter attribute

eGov-066

MUST

310

Support the acceptance/rejection of assertions based on the content of the <saml2:AuthnStatement> element’s <saml2:AuthnContext> element.

eGov-067

MUST

312

Support the acceptance/rejection of particular <saml2:AuthnContext> content based on the identity of the Identity Provider.

eGov-068

SHOULD

314

Support support the acceptance/rejection of particular <saml2:AuthnContext> content based on SAML V2.0 metadata as specified in [IAP]

2.5.4. Artifact Resolution

Implementations MUST support the SAML V2.0 Artifact Resolution profile [SAML2Prof] as constrained by the following requirements.

Table 10. Response Message Contents
RequID IDP SP Line Requirement

eGov-070

MUST

MUST

323

Support the use of the SAML SOAP (using HTTP as a transport) binding [SAML2Bind] for the transmission of <saml2p:ArtifactResolve> messages.

eGov-071

MUST

MUST

326

Support the use of SAML message signatures and TLS server authentication to authenticate artifact resolution requests

eGov-072

MUST

MUST

330

Support the use of the SAML SOAP (using HTTP as a transport) binding [SAML2Bind] for the transmission of <saml2p:ArtifactResponse> messages.

eGov-073

MUST

MUST

333

Support the use of SAML message signatures and TLS server authentication to authenticate artifact resolution responses

2.6. Browser Holder of Key Single Sign-On

This section defines an implementation profile of the SAML V2.0 Holder-of-Key Web Browser SSO Profile Version 1.0 [HoKSSO].

Table 11. HoK profile
RequID IDP SP Line Requirement

eGov-074

MAY

MAY

337

Support this implementation profile of the SAML V2.0 Holder-of-Key Web Browser SSO Profile Version 1.0 [HoKSSO]. The implementation requirements defined in section "Browser Single Sign-On" for the non-holder-of-key profile apply to implementations of this profile.

2.7. SAML 2.0 Proxying

Section 3.4.1.5 of [SAML2Core] defines a formalized approach to proxying the SAML 2.0 Authentication Request protocol between multiple Identity Providers. This section defines an implementation profile for this behavior suitable for composition with the Single Sign-On profiles defined in sections 2.5 and 2.6. The requirements of the profile are imposed on Identity Provider implementations acting as a proxy.

Table 12. Requirements for Proxying Identity Provider implementations
RequID IDP SP Source Format Identifier

eGov-081

MUST

MUST

350

(If acting as a proxy) support the technical requirements outlined in section 3.4.1.5.1 of [SAML2Core]

eGov-082

MUST

MUST

350

(When processing Authentication Requests) support the mapping of incoming to outgoing <saml2p:RequestedAuthnContext> and <saml2p:NameIDPolicy> elements, such that deployers may choose to pass through values or map between different vocabularies as required.

eGov-083

MUST

MUST

354

(When processing Authentication Requests) support the suppression/eliding of <saml2p:RequesterID> elements from outgoing <saml2p:AuthnRequest> messages to allow for hiding the identity of the Service Provider from proxied Identity Providers.

eGov-084

MUST

MUST

359

(When processing WebSSO Response) support the mapping of incoming to outgoing <saml2:AuthnContext> elements, such that deployers may choose to pass through values or map between different vocabularies as required.

eGov-085

MUST

MUST

362

(When processing WebSSO Response) support the suppression of <saml2:AuthenticatingAuthority> elements from outgoing <saml2:AuthnContext> elements to allow for hiding the identity of the proxied Identity Provider from Service Providers.

2.8. Single Logout

RequID IDP SP Line Requirement

eGOV-090

MUST

MUST

367

This section defines an implementation profile of the SAML V2.0 Single Logout Profile [SAML2Prof].

For clarification, the technical requirements for each message type below reflect the intent to normatively require initiation of logout by a Service Provider using either the front- or back-channel, and initiation/propagation of logout by an Identity Provider using the back-channel.

2.8.1. Logout Requests

Table 13. Binding and Security Requirements
RequID IDP SP Line Requirement

eGOV-091

MUST

375

Support the SAML SOAP (using HTTP as a transport) binding [SAML2Bind] for the issuance of <saml2p:LogoutRequest> messages.

eGOV-092

MUST

377

Support the SAML SOAP (using HTTP as a transport) and HTTP-Redirect bindings [SAML2Bind] for the reception of <saml2p:LogoutRequest> messages.

eGOV-093

MUST

380

Support the SAML SOAP (using HTTP as a transport) binding [SAML2Bind] for both issuance and reception of <saml2p:LogoutRequest> messages.

eGOV-094

MUST

MUST

384

Support the use of SAML message signatures and TLS server authentication to authenticate <saml2p:LogoutRequest> messages.

eGOV-095

MUST

MUST

388

Support the use of XML Encryption via the <saml2:EncryptedID> element when using the HTTP-Redirect binding.
Table 14. User Interface Behavior
RequID IDP SP Line Requirement

eGOV-096

MUST

392

Support both user-initiated termination of the local session only and user-initiated Single Logout.

eGOV-097

MUST

393

Upon receipt of a <saml2p:LogoutRequest> message via a front-channel binding, support user intervention governing the choice of propagating logout to other Service Providers, or limiting the operation to the Identity Provider.

eGOV-098

MUST

393

Return status information to the requesting entity (e.g. partial logout indication) as appropriate when using front-channel binding.

eGOV-099

MUST

399

Support both user-initiated termination of the local session only and user-initiated Single Logout.

eGOV-100

MUST

399

Support the administrative initiation of Single Logout for any active session, subject to appropriate policy.

2.8.2. Logout Responses

Table 15. Binding and Security Requirements
RequID IDP SP Line Requirement

eGOV-101

MUST

405

Support the SAML SOAP (using HTTP as a transport) and HTTP-Redirect bindings [SAML2Bind] for the issuance of <saml2p:LogoutResponse> messages.

eGOV-102

MUST

407

Support the SAML SOAP (using HTTP as a transport) binding [SAML2Bind] for the reception of <saml2p:LogoutResponse> messages.

eGOV-103

MUST

414

Support the use of SAML message signatures and TLS server authentication to authenticate <saml2p:LogoutResponse> messages.

3. Conformance Classes

3.1. Standard

Conforming Identity Provider and/or Service Provider implementations MUST support the normative requirements in sections 2.2, 2.3, 2.4, and 2.5.

3.1.1. Signature and Encryption Algorithms

Table 16. Signature and Digest Algorithms for the Creation and Verification of XML Signatures
RequID Line Requirement

eGov-110

426

MUST support http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 (defined in [RFC4051])

eGov-111

428

MUST support http://www.w3.org/2001/04/xmlenc#sha256 (defined in [XMLEnc])

eGov-112

432

SHOULD support http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256 (defined in [RFC4051])
Table 17. Block Encryption, Key Transport and Key Agreement Algorithms for the Creation and Verification of XML Encryption
RequID Line Requirement

eGov-113

436

MUST support http://www.w3.org/2001/04/xmlenc#tripledes-cbc

eGov-114

437

MUST support http://www.w3.org/2001/04/xmlenc#aes128-cbc

eGov-115

438

MUST support http://www.w3.org/2001/04/xmlenc#aes256-cbc

eGov-116

441

MUST support http://www.w3.org/2001/04/xmlenc#rsa-1_5

eGov-117

442

MUST support http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p

eGov-118

445

SHOULD support http://www.w3.org/2009/xmlenc11#ECDH-ES (defined in [XMLEnc11])

3.2. Standard with Logout

Conforming Identity Provider and/or Service Provider implementations MUST meet the conformance requirements in section 3.1, and MUST in addition support the normative requirements in section 2.8.

3.3. Standard with Logout

Conforming Identity Provider and/or Service Provider implementations MUST meet the conformance requirements in section 3.1, and MUST in addition support the normative requirements in sections 2.6, 2.7, and 2.8.

4. References

4.1. Normative References