Kantara Initiative

eGov Working Group:

Proposed Deployment Profile Template

 

 

File name: KI-eGov Deployment Profile Template v0.3.doc

Version: 0.3

Status: Draft

Date modified: 6 October, 2010 14:10

 

 

For further information contact:

Bob Sunday  

Security and Identity Management

Chief Information Officer Branch

Treasury Board Secretariat

613-941-4764

Email: robert.sunday@tbs-sct.gc.ca

 

 

To be Approved by:

 

 

 

 


Revision Record Sheet

 

VERSION
NO.

DESCRIPTION

DATE
ISSUED

Status

AUTHOR & NOTES

0.3

Initial template based on ongoing deployment profile work.

6 October 2010

Draft

Bob Sunday , TBS

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Foreword

 

Release Note for this version 0.3

This document is extracted from ongoing work at the Government of Canada to define the next revision of its SAML2 WebSSO Deployment Profile. Comments on this template are welcome and we hope to be able to share the completed Deployment Profile when it becomes available.

 

Table of Contents

1 Introduction ..............................................................................................................................................................................

1.1 The Vision ...............................................................................................................................................................................

1.2 Overview of the Deployment Requirements .......................................................................................................................

1.3 Compliance to the Deployment Requirements ...................................................................................................................

1.4 Differences from the Former Interface Architecture and Specification ...........................................................................

1.4.1 Focus is on deployment rather than underlying technology .........................................................................................

1.4.2 Support of Level of Assurance is explicitly required .....................................................................................................

1.4.3 ..........................................................................................................................................................................................

1.5 Document References ............................................................................................................................................................

1.6 Glossary and Acronyms .........................................................................................................................................................

2 Deployment Requirements (Normative) .....................................................................................................................

2.1 Constraints on the Kantara Initiative eGov 2.0 Profile ......................................................................................................

2.2 Additional Constraints on the [SAML2 *] specifications ..................................................................................................

2.3 Additional Extensions relative to the [SAML2 *] specifications .......................................................................................

2.4 Additional XXX Requirements .............................................................................................................................................

2.4.1 Required Assertion Attributes .........................................................................................................................................

2.4.2 XXX Levels of Assurance .................................................................................................................................................

2.4.3 Other ...................................................................................................................................................................................

2.4.4 Security ...............................................................................................................................................................................

2.4.5 Metadata .............................................................................................................................................................................

2.4.6 Exception Handling ..........................................................................................................................................................

1                         Introduction

1.1                   The Vision

A diagram goes very well here.

Further detail on the Vision can be found in other documents such as [XXX-Vision]

1.2                   Overview of the Deployment Requirements

These Deployment Requirements are a deployment level profile for participation in the XXX environment. It applies to deployments configured to participate as both Service Providers (SP’s) and Identity Providers (IdP’s). In the XXX context, SP’s are also called Relying Parties (RP’s) and IdP’s are called Credential Providers (CP’s) or Credential Service Providers (CSP’s).

This deployment profile is not a tutorial or guidance document. Further guidance can be found in documents such as [XXX-ConOps].

1.3                   Compliance to the Deployment Requirements

This deployment profile is based on but does not require full compliance with the eGov 2.0 Profile [eGov 2.0] published by the Kantara Initiative. The normative requirements of this Deployment Profile in terms of the applicable sections of the eGov 2.0 Profile are detailed in Section 2 of this document. The eGov 2.0 Profile is based on the SAML 2.0 specifications created by the Security Services Technical Committee (SSTC) of OASIS. The profile constrains the base SAML 2.0 features, elements, attributes and other values required for approved eGovernment federations and deployments. Unless otherwise specified, SAML operations and features follow those found in the OASIS SAML 2.0 specifications.

NOTE: Interoperability testing conducted by external bodies, such as the Kantara Initiative, may assist confirmation of compliance. However, these external tests do not form a complete and final confirmation of compliance with these deployment requirements. Additional testing may be required by the XXX Credential Federation Governance Body (CFGB) to allow participation.

1.4                   Differences from the Former Interface Architecture and Specification

This document differs from the [XXX-Former] in a number of areas:

  1. Focus is on deployment rather than underlying technology
  2. Support of Level of Assurance is explicitly required

These differences are generally described below, but the normative conformance requirements to this deployment profile are specified in this document in Section 2 titled: “ Deployment Requirements (Normative)

1.4.1              Focus is on deployment rather than underlying technology

This deployment requirements document is meant to relax the rules (but not the conformance requirements) that have previously required the underlying software products at the RP’s and IdP’s to have passed Liberty Alliance Interoperability testing.

The new rules will require the IdP “Service” and the RP “Service” to be interoperability tested and certified against the rules in this deployment requirements document. Of course, using COTS software that has passed the Liberty Alliance or Kantara Initiative Interoperability testing will greatly improve the chances of successfully meeting these deployment requirements.

1.4.2              Support of Level of Assurance is explicitly required

Support for Level of Assurance as specified in [SAML2 LoA] will be required. The XXX LoA’s are defined in [XXX-LoA] and specified in this Deployment Requirements in Section 2.4.2 , XXX Levels of Assurance .

RP’s MUST request a specific level of assurance with the “exact” compare operator. The RP may request more than one level in priority order. E.g. this is useful when a level 2 is required but the RP is willing to accept (and perhaps pay for) a level 3 if a level 2 is not possible.

CP’s MUST provide the exact LoA requested and MUST reject any LoA request that is not defined as a  XXX LoA. CP’s that are not configured to support the LoA requested MUST reject the authentication request with an appropriate status code.

The Metadata requirements will include additional support for Level of Assurance as specified in [SAML2 LoA].

1.4.3             

Additional comments as desired

1.5                   Document References

[SAML2 *] All the SAML2 document references are available at
http://docs.oasis-open.org/security/saml/v2.0

[SAML2 Conf]

[SAML2 Core]

[SAML2 Discov]

[SAML2 LoA]

[SAML2 Meta ]

[SAML2 Prof]

[XXX-ConOps] To be produced

[XXX-Glossary] To be produced

[XXX-LoA]

[eGov 1.5] “Liberty Alliance eGov Profile 1.5” available from
http://www.projectliberty.org/liberty/content/download/4711/32210/file/Liberty_Alliance_eGov_Profile_1.5_Final.pdf

[eGov 2.0] “Kantara Initiative eGovernment 3 Implementation Profile of SAML V2.0 Version 2.0” available from
http://kantarainitiative.org/confluence/download/attachments/42140355/kantara-report-egov-saml2-profile-2.0.pdf?version=1&modificationDate=1277407787000

1.6                   Glossary and Acronyms

See [XXX-Glossary]

 

 


2                         Deployment Requirements (Normative)

2.1                   Constraints on the Kantara Initiative eGov 2.0 Profile

Thi s specificatio n build s upo n th e SAM L 2. 0 suit e o f specifications [SAML2 *] and the profile of SAML2 referred to as Kantara Initiative eGovernment Implementation Profile of SAML2 version 2.0 [eGov 2.0]

This deployment profile is based on and, unless otherwise specified, requires compliance with the Kantara Initiative eGovernment Implementation Profile of SAML2 version 2.0 [eGov 2.0]. While the Kantara eGov 2.0 profile is an “implementation” profile for vendors of software products, this XXX profile is a “deployment” profile which further constrains and explains the deployment of Service Providers and Credential Providers in the  XXX environment. Where this XXX  does not explicitly provide SAML2 guidance, one must implement in accordance with applicable OASIS SAML 2.0 requirements

The following table is in the order and description of the requirements in [eGov 2.0], Sections 2 & 3 which are repeated word for word. The table is annotated with the support required by the  XXX Program: typically this is either “Support” or “Constrained” or “n/a” (not applicable). Whenever further details are required to fully explain the  requirement, they are provided in the 3 rd column.

There are also requirements which are additional to these eGov 2.0 requirements and they are specified in the subsequent sections. XXX also has constraints on the SAML v2.0 specifications and has a few XXX specific requirements

Note: the following table is only partially filled out as an example of the types of entries expected.


eGov 2.0

XXX
Support Required

XXX Deployment Details

2.2 Metadata and Trust Management

 

 

Identity Provider, Service Provider, and Discovery Service implementations MUST support the use of SAML V2.0 Metadata [SAML2Meta] in conjunction with their support of the SAML V2.0 profiles referenced by subsequent sections. Additional expectations around the use of particular metadata elements related to profile behavior may be encountered in those sections.

Support

 

2.2.1 Metadata Profiles

 

 

Implementations MUST support the SAML V2.0 Metadata Interoperability Profile Version 1.0 [MetaIOP].

Constrained

XXX Deployments MUST NOT use this profile

In addition, implementations MUST support the use of the <md:KeyDescriptor> element as follows:

Support

 

  • Implementations MUST support the <ds:X509Certificate> element as input to subsequent requirements. Support for other key representations, and for other mechanisms for credential distribution, is OPTIONAL.

Constrained

No OPTIONAL mechanisms are supported

  • Implementations MUST support some form of path validation of signing, TLS, and encryption credentials used to secure SAML exchanges against one or more trusted certificate authorities. 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].

Support

XXX Deployments MUST follow the requirements specified in Section 2.4.4 Security

  • Implementations MUST 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.

Support

XXX Deployments MUST follow the requirements specified in Section 2.4.4 Security

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

Constrained

No OPTIONAL additional constraints are supported

Note that these metadata profiles are intended to be mutually exclusive within a given deployment context; they are alternatives, rather than complimentary or compatible uses of the same metadata information.

n/a

 

Implementations SHOULD 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.

Support

 

2.2.2 Metadata Exchange

 

 

It is OPTIONAL for implementations to support the generation or exportation of metadata, but implementations MUST support the publication of metadata using the Well-Known-Location method defined in section 4.1 of [SAML2 Meta] (under the assumption that entityID values used are suitable for such support).

 

 

Implementations MUST support the following mechanisms for the importation of metadata:

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

In the case of HTTP resolution, implementations MUST support use of the "ETag" and "Last-Modified" headers for cache management. Implementations SHOULD 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.

 

 

Importation of multiple entities' metadata contained within an <md:EntitiesDescriptor> element MUST be supported.

 

 

Finally, implementations SHOULD allow for the automated updating/reimportation of metadata without service degradation or interruption.

 

 

2.2.2.1 Metadata Verification

 

 

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

  • Direct comparison against known keys.
  • 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].

Constrained

  • Federation members MUST sign their metadata using the signing certificate issued by the  XXX Service.
  • At consumption time, the Federation member relying upon the metadata MUST check the revocation status of the certificate used to sign the metadata.
    • Only CRL’s are supported

2.3 Name Identifiers

 

 

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

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

Constrained

XXX Deployments MUST support persistent

XXX Deployments MUST NOT support transient

Support for other formats is OPTIONAL.

Constrained

XXX Deployments MUST NOT support other formats

2.4 Attributes

 

 

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].

Constrained

XXX Deployments MUST follow the requirements specified in Section 2.4.1 Required Assertion Attributes

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.

Constrained

XXX Deployments MUST follow the requirements specified in Section 2.4.1 Required Assertion Attributes

2.5 Browser Single Sign-On

 

 

This section defines an implementation profile of the SAML V2.0 Web Browser SSO Profile [SAML2Prof].

Support

 

2.5.1 Identity Provider Discovery

 

 

Service Provider and Discovery Service implementations MUST support the Identity Provider Discovery Service Protocol Profile in conformance with section 2.4.1 of [IdPDisco].

Support

 

2.5.2 Authentication Requests

 

 

2.5.2.1 Binding and Security Requirements

 

 

Identity Provider and Service Provider implementations MUST 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.

 

 

Support for other bindings is OPTIONAL.

 

 

2.5.2.2 Message Content

 

 

In addition to standard core- and profile-driven requirements, Service Provider implementations MUST support the inclusion of at least the following <saml2p:AuthnRequest> child elements and attributes (when appropriate):

Constrained

As specified below

  • AssertionConsumerServiceURL

Constrained

XXX Deployments MUST NOT specify. THE CP will obtain this from the CFGB approved Metadata

  • ProtocolBinding

 

 

  • ForceAuthn

 

 

  • IsPassive

 

 

  • AttributeConsumingServiceIndex

 

 

  • <saml2p:RequestedAuthnContext>

 

 

  • <saml2p:NameIDPolicy>

 

 

Identity Provider implementations MUST 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. However, implementations MUST fully support the options enumerated above, and be configurable to utilize those options in a useful manner as defined by [SAML2Core].

 

 

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

 

 

Identity Provider implementations 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 alternatve verification mechanisms.

 

 

2.5.3 Responses

 

 

2.5.3.1 Binding and Security Requirements

 

 

Identity Provider and Service Provider implementations MUST support the use of the HTTP-POST and HTTP-Artifact bindings [SAML2Bind] for the transmission of <saml2p:Response> messages.

 

 

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

 

 

Identity Provider and Service Provider implementations MUST support the generation and consumption of unsolicited <saml2p:Response> messages (i.e., responses that are not the result of a <saml2p:AuthnRequest> message).

 

 

Identity Provider implementations MUST 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].

 

 

Identity Provider and Service Provider implementations MUST support the signing of <saml2:Assertion> elements in responses; support for signing of the <saml2p:Response> element is OPTIONAL.

 

 

Identity Provider and Service Provider implementations MUST 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.

 

 

2.5.3.2 Message Content

 

 

The Web Browser SSO Profile allows responses to contain any number of assertions and statements. Identity Provider implementations MUST allow the number of and <saml2:AttributeStatement> elements in the <saml2p:Response> message to be limited to one. In turn, Service Provider implementations MAY limit support to a single instance of those elements when processing <saml2p:Response> messages.

Constrained

XXX Deployments MUST only send <saml2p:Response> messages containing a single <saml2:Assertion>

Identity Provider implementations MUST support the inclusion of a Consent attribute in <saml2p:Response> messages, and a SessionIndex attribute in <saml2:AuthnStatement> elements.

 

 

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

 

 

Service Provider implementations MUST support the acceptance/rejection of assertions based on the content of the <saml2:AuthnStatement> element's <saml2:AuthnContext> element. Implementations also MUST support the acceptance/rejection of particular <saml2:AuthnContext> content based on the identity of the Identity Provider. [IAP] provides one such mechanism via SAML V2.0 metadata and is RECOMMENDED; though this specification is in draft form, the technical details are not expected to change prior to eventual approval.

 

 

2.5.4 Artifact Resolution

 

 

Pursuant to the requirement in section 2.5.3.1 for support of the HTTP-Artifact binding [SAML2Bind] for the transmission of <saml2p:Response> messages, implementations MUST support the SAML V2.0 Artifact Resolution profile [SAML2Prof] as constrained by the following subsections.

Constrained

XXX Deployments MUST NOT support the HTTP-Artifact binding

2.5.4.1 Artifact Resolution Requests

 

 

Identity Provider and Service Provider implementations MUST support the use of the SAML SOAP (using HTTP as a transport) binding [SAML2Bind] for the transmission of <saml2p:ArtifactResolve> messages.

n/a

 

Implementations MUST support the use of SAML message signatures and TLS server authentication to authenticate requests; support for TLS client authentication, or other forms of authentication in conjunction with the SAML SOAP binding, is OPTIONAL.

n/a

 

2.5.4.2 Artifact Resolution Responses

 

 

Identity Provider and Service Provider implementations MUST support the use of the SAML SOAP (using HTTP as a transport) binding [SAML2Bind] for the transmission of <saml2p:ArtifactResponse> messages.

n/a

 

Implementations MUST support the use of SAML message signatures and TLS server authentication to authenticate responses; support for TLS client authentication, or other forms of authentication in conjunction with the SAML SOAP binding, is OPTIONAL.

n/a

 

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].

 

 

The implementation requirements defined in section 2.5 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. These requirements are in addition to the technical requirements outlined in section 3.4.1.5.1 of [SAML2Core], which also MUST be supported.

 

 

2.7.1 Authentication Requests

 

 

Proxying Identity Provider implementations MUST 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.

 

 

Proxying Identity Provider implementations MUST 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.

 

 

2.7.2 Responses

 

 

Proxying Identity Provider implementations MUST 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.

 

 

Proxying Identity Provider implementations MUST 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

 

 

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

 

 

2.8.1.1 Binding and Security Requirements

 

 

Identity Provider implementations MUST support the SAML SOAP (using HTTP as a transport) binding [SAML2Bind] for the issuance of <saml2p:LogoutRequest> messages, and MUST support the SAML SOAP (using HTTP as a transport) and HTTP-Redirect bindings [SAML2Bind] for the reception of <saml2p:LogoutRequest> messages.

 

 

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

 

 

Support for other bindings is OPTIONAL.

 

 

Implementations MUST support the use of SAML message signatures and TLS server authentication to authenticate <saml2p:LogoutRequest> messages; support for TLS client authentication, or other forms of authentication in conjunction with the SAML SOAP binding, is OPTIONAL.

 

 

Identity Provider and Service Provider implementations MUST support the use of XML Encryption via the <saml2:EncryptedID> element when using the HTTP-Redirect binding.

 

 

2.8.1.2 User Interface Behavior

 

 

Identity Provider implementations MUST support both user-initiated termination of the local session only and user-initiated Single Logout. Upon receipt of a <saml2p:LogoutRequest> message via a front-channel binding, Identity Provider implementations MUST support user intervention governing the choice of propagating logout to other Service Providers, or limiting the operation to the Identity Provider. Of course, implementations MUST return status information to the requesting entity (e.g. partial logout indication) as appropriate.

 

 

Service Provider implementations MUST support both user-initiated termination of the local session only and user-initiated Single Logout.

 

 

Identity Provider implementations MUST also support the administrative initiation of Single Logout for any active session, subject to appropriate policy.

 

 

2.8.2 Logout Responses

 

 

2.8.2.1 Binding and Security Requirements

 

 

Identity Provider implementations MUST support the SAML SOAP (using HTTP as a transport) and HTTP-Redirect bindings [SAML2Bind] for the issuance of <saml2p:LogoutResponse> messages, and MUST support the SAML SOAP (using HTTP as a transport) binding [SAML2Bind] for the reception of <saml2p:LogoutResponse> messages.

 

 

Service Provider implementations MUST support the SAML SOAP (using HTTP as a transport) binding [SAML2 Bind] for both issuance and reception of <saml2p:LogoutResponse> messages.

 

 

Support for other bindings is OPTIONAL.

 

 

Implementations MUST support the use of SAML message signatures and TLS server authentication to authenticate <saml2p:LogoutResponse> messages; support for TLS client authentication, or other forms of authentication in conjunction with the SAML SOAP binding, is OPTIONAL.

 

 

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

 

 

Implementations MUST support the signature and digest algorithms identified by the following URIs in conjunction with the creation and verification of XML Signatures [XMLSig]:

 

 

Implementations SHOULD support the signature and digest algorithms identified by the following URIs in conjunction with the creation and verification of XML Signatures [XMLSig]:

 

 

Implementations MUST support the block encryption algorithms identified by the following URIs in conjunction with the use of XML Encryption [XMLEnc]:

  • http://www.w3.org/2001/04/xmlenc#tripledes-cbc
  • http://www.w3.org/2001/04/xmlenc#aes128-cbc
  • http://www.w3.org/2001/04/xmlenc#aes256-cbc

 

 

Implementations MUST support the key transport algorithms identified by the following URIs in conjunction with the use of XML Encryption [XMLEnc]:

 

 

Implementations SHOULD support the key agreement algorithms identified by the following URIs in conjunction with the use of XML Encryption [XMLEnc]:

(This is a Last Call Working Draft of XML Encryption 1.1, and this normative requirement is contingent on W3C ratification of this specification without normative changes to this algorithm's definition.)

 

 

Support for other algorithms is OPTIONAL.

 

 

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 Full

 

 

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.

 

 

End of table

 

 

 

 


2.2                   Additional Constraints on the [SAML2 *] specifications

In addition to the constraints imposed by this deployment profile on the eGov 2.0 Profile [eGov 2.0] published by the Kantara Initiative, this XXX deployment requirements document also imposes some additional constraints on the underlying SAML 2.0 specifications published by the Security Services Technical Committee (SSTC) of OASIS.

 

SAML2 *

XXX
Support Required

XXX Deployment Details

[SAML2 Core]
Section 3.2.1, Line 1489
<saml:Issuer>

Constrained

SP Authentication Request <saml:Issuer>

  • MUST be present
  • MUST be a URL reference within the XXX governance domain
    • The XXX procedures to assign these are specified in [XXX-ConOps].

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

End of table

 

 

 

2.3                  
Additional Extensions relative to the [SAML2 *] specifications

In addition to the constraints imposed by this deployment profile on the eGov 2.0 Profile [eGov 2.0] published by the Kantara Initiative, this XXX deployment requirements document also extends the underlying SAML 2.0 specifications published by the Security Services Technical Committee (SSTC) of OASIS.

 

SAML2 *

XXX
Support Required

XXX Deployment Details

[SAML2 Core]
Section 3.4.1.4, Line 2068
< Response >

Extended

The IdP MAY NOT logically abandon the < AuthnRequest > under any circumstances within its control

Note: this extends the eGov 2.0 requirement stated above on page 17

 

 

 

 

 

 

End of table

 

 

 


2.4                   Additional XXX Requirements

In addition to the constraints imposed by this deployment profile on the eGov 2.0 Profile [eGov 2.0] published by the Kantara Initiative, and the additional constraints and extensions on the underlying SAML 2.0 specifications published by the Security Services Technical Committee (SSTC) of OASIS, this XXX Deployment Requirements document also imposes some additional requirements for the ’s XXX environment.

2.4.1              Required Assertion Attributes

 

XXX Requirement

XXX
Support Required

XXX Deployment Details

[SAML2 Core]
Section 2.7.3, Line 1165
< AttributeStatement >

Extended

XXX SP and IdP Deployments MUST support XXX mandatory attributes:

[SAML2 Core]
Section 2.7.3, Line 1165
< AttributeStatement >

Extended

XXX IdP Deployments MAY support XXX optional attributes:

[SAML2 Core]
Section 2.7.3, Line 1165
< AttributeStatement >

Constrained

XXX SP Deployments SHALL NOT support receiving any other attributes

  • A XXX SP Deployment MUST discard any other attributes and not use the attribute values for any processing.

End of table

 

 

 

2.4.1.1                              Mandatory Attributes

 

Name (URI)

Description

Format

Datatype

XXX::authentication:basic:specVer

The version of the interface specification

MUST be “2.0” for this interface specification

xs:string

 

 

 

 

 

2.4.1.2                              Optional Attributes

 

Name (URI)

Description

Format

Datatype

None defined

 

 

 

 

 

 

 

 

2.4.2              XXX Levels of Assurance

Authentication Requests and Responses for the XXX credentials will carry the required Level of Assurance. There are 4 Levels of Assurance that are defined in [XXX-LoA] and used by the XXX Program. The URI’s representing these LoA’s have the following values:

  • http://xxx.org/assurance/loa1
  • http://xxx.org/assurance/loa2
  • http://xxx.org/assurance/loa3
  • http://xxx.org/assurance/loa4

The schemas corresponding to these values are available from the XXX CFGB

 

2.4.3              Other

Other requirements to be defined as required

 

2.4.4              Security

To establish trust and secure communications this interface specification relies heavily on X.509v3 cryptographic key pairs. This section outlines the different certificates that are required as well as specifics on their use.

2.4.4.1                              The XXX Certificates

Possession of a valid certificate issued by the XXX Service demonstrates membership in the XXX Credential Federation. The XXX Service issues two certificates to each RP (one used for digital signature and one used for encryption), and one certificate to each CP (used for digital signature).

  • These certificates MUST be maintained in compliance with the Subscriber responsibilities (as specified by the XXX CFGB).

2.4.4.2                              Digital Signature

All SAML messages, or parts thereof, MUST be signed by the sender using the XXX Service signature certificate that was issued to them. The signature allows the recipient of the message to authenticate the sender, and confirm that the message has not been altered since the time of signature.

  • The recipient MUST authenticate the sender and verify the signature upon receipt of the message.
  • The recipient MUST verify the revocation status of the sender certificate used to sign the message. Federation member systems MUST use the following method for revocation verification:
  • CRL – the CRL location (in the directory or web site) can be statically configured into the software, and CRL downloaded periodically. See [XXX-PKI] for details regarding distinguished name location and directory hostname.
  • If certificate revocation status cannot be determined, the Federation member system MUST reject the message.

2.4.4.3                              Encryption

Encryption ensures that only the intended recipient can decipher the message and gain access to confidential information.

  • All confidential information in a SAML message MUST be encrypted.
  • Encryption MUST use the public key of the intended recipient’s XXX-issued encryption certificate.

2.4.4.4                              TLS web sites

This interface specification relies on the use of HTTP over TLS (HTTPS) to transport messages.

  • Any HTTPS site managed by a Federation member MUST be secured using a certificate trusted by default by commercially available browsers.
  • Use of SSLv3.0/TLS must be compliant with XXX guidelines and departmental policies.
  • HTTPS over TLS (v1.1 or higher) MUST be used unless not supported by the browser
  • HTTPS over TLS (v1.0) MAY be used
  • HTTPS over SSL (v3.0 or higher) MAY be used only if TLS (v1.0 or higher) is not supported by the browser .
  • Earlier versions of SSL MUST NOT be used

 

2.4.5              Metadata

Thi s interfac e specificatio n use s [SAML 2 Metadata ] t o eas e softwar e configuratio n an d communication . This section defines the normative requirements for specific metadata attributes.

2.4.5.1                              <EntityDescriptor>

 

XXX Requirement

XXX
Support Required

XXX Deployment Details

[SAML2 Metadata]
Section 2.3.2, Line 371
< entityID >

Constrained

  • entityID MUST be agreed upon by the entity and the XXX CFGB.
  • entityID MUST be unique within the Federation.

 

 

 

 

 

 

 

2.4.5.2                              <IDPSSODescriptor> Element

 

XXX Requirement

XXX
Support Required

XXX Deployment Details

 

 

 

 

 

 

 

 

 

 

2.4.5.3                              <SPSSODescriptor> Element

 

XXX Requirement

XXX
Support Required

XXX Deployment Details

 

 

 

 

 

 

 

 

 

 

2.4.6             
Exception Handling

 

XXX Interface Support Required

XXX Deployment Details

The XXX member SAML service MUST handle error conditions gracefully

Specifically, the XXX member SAML service MUST handle the list of possible errors provided in 2.4.6.1 Errors to be handled

 

2.4.6.1                              Errors to be handled

The following table list s error s tha t th e Federatio n membe r SAM L servic e MUS T handl e gracefully (i.e. in a controlled user-friendly manner) . Thi s i s no t a complet e lis t o f al l possibl e error s. Th e tabl e categorize s error s b y SAM L event .

 

Error Condition

XXX Deployment Requirements

Error Processing <Response>

  • Incorrect/Unknown <Issuer>
  • Incorrect Version
  • Unrecognized InResponseTo
  • Unacceptable IssueInstant
  • Status not Success

 

Error Processing <Assertion>

  • Signature Invalid
  • Signature Certificate Revoked
  • Cannot determine revocation status
  • <Assertion> Time Invalid
  • Cannot Decrypt <Assertion>
  • Incorrect Recipient
  • Incorrect Version

 

Error Processing <AuthnRequest>

  • Unknown <Issuer>
  • Signature Invalid
  • Signature Certificate Revoked
  • Cannot determine revocation status

 

Error processing SLO Request

  • Unknown <Issuer>
  • Signature Invalid
  • Signature Certificate Revoked
  • Cannot determine revocation status

 

Error processing SLO <Response>

  • Unknown <Issuer>
  • Signature Invalid
  • Unknown status
  • Signature Certificate Revoked
  • Cannot determine revocation status