The Incommon Federation wiki has moved.

Please visit the new InCommon Federation Library wiki for updated content. Remember to update your bookmarks.

Click in the link above if you are not automatically redirected in 15 seconds.



You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Community Review in progress!

This document contains DRAFT material intended for discussion and comment by the InCommon participant community. Comments and questions should be sent to the InCommon participants mailing list (participants@incommon.org).

This document is intended for implementors of SAML software, that is, software that supports SAML Web Browser SSO.

Contents

This document summarizes a set of implementation requirements that will eventually form the basis of an InCommon SAML Implementation Profile. These requirements are a superset of the implementation features required to support the saml2int deployment profile, which reflects a substantial amount of best practice within the global higher education community.


Basic Metadata Requirements

This section includes a basic set of metadata requirements for both IdP and SP deployments.

Metadata Extensions

Extensibility and evolution of the use cases of SAML are of paramount importance to the Research and Education (R&E) community. Thus any SAML implementation must be able to handle, or at least gracefully proceed without error, upon encountering SAML extensions such as metadata entity attributes, [1] use of metadata and authentication context to express assurance, [2] metadata UI elements, [3] etc.

  1. Support for SAML Metadata

    1. Support the following OASIS specifications (linked on the OASIS Security Services Technical Committee wiki page):

      1. SAML V2.0 Metadata as updated by Errata

      2. SAML V2.0 Metadata Schema

      3. SAML V2.0 Metadata Interoperability Profile

  2. Support the following batch metadata process:

    1. consume SAML metadata at least daily (e.g., http://md.incommon.org/InCommon/InCommon-metadata.xml)

    2. root element: <md:EntitiesDescriptor>

    3. root element contains an arbitrary number of <md:EntityDescriptor> child elements

  3. Support the following metadata security model:

    1. the metadata file is signed using XML Signature

      1. the signature uses the SHA-256 digest algorithm

    2. the signature on every metadata file MUST be verified using a well-known, trusted public key

      1. Metadata Signing Certificate for the above metadata file

    3. the root element is decorated with a validUntil XML attribute, which MUST be validated (i.e., not expired and not too far into the future)

  4. Process the content of the SAML2 metadata file as follows:

    1. Run-time configuration of SAML profiles (technical trust configuration) managed via SAML Metadata alone and should allow basic interop with any SP for which metadata is supplied, without the local admin having to “enable access” for that SP

    2. Gracefully accept (and possibly ignore) any and all well-formed extension content (see note at top of document)

    3. Accept and allow the use of long-lived, self-signed, end entity certificates

      1. as specified in the Metadata Interoperability Profile, an expired certificate is treated like any other certificate

      2. likewise the signature on end entity certificates is irrelevant (either SHA-1 or SHA-2, it doesn’t matter)

  5. To fully support key rollover, the implementation MUST support the following features:

    1. An implementation MUST be able to consume and utilize two or more signing keys bound to a single role descriptor. There are two cases that MUST be supported:

      1. Both <md:KeyDescriptor use="signing"> and <md:KeyDescriptor use="signing"> elements in a single role descriptor

      2. Both <md:KeyDescriptor use="signing"> and <md:KeyDescriptor> elements in a single role descriptor

    2. If an implementation supports inbound encryption, it MUST be configurable with up to two decryption keys.

    3. An implementation MAY support (i.e., consume and utilize) multiple encryption keys of the same type per role descriptor in metadata. In particular, the implementation MAY support two <md:KeyDescriptor> elements (with no use XML attribute) in a single role descriptor, but this is not strictly required since it can usually be avoided in practice. Note that supporting multiple key types for encryption (e.g., RSA and EC) implies support for multiple keys in metadata.

IdP Requirements

All IdP deployments MUST satisfy the Basic Metadata Requirements listed above.

Level 1 IdP Requirements

  1. Support for SAML V2.0 Web Browser SSO as defined in the SAML V2.0 Profiles specification as updated by Errata (linked on the OASIS Security Services Technical Committee wiki page)

  2. Assuming SP metadata is available, must respond to any valid AuthnRequest. If unable to satisfy a given request, must respond with a SAML error.

  3. Support for signature creation and validation with 2048-bit and larger RSA keys and at least the SHA-1 and SHA-256 digest algorithms. Signing at either or both of the Response and Assertion layers MUST be supported.

  4. Support for assertion encryption via at least the AES-CBC and AES-GCM data encryption and RSA-OAEP key transport algorithms.

  5. Support for configuring signing and encryption behavior based on the identity of an SP.

  6. Support for the MACE-Dir SAML Attribute Profiles

  7. Support the use of a “default attribute release policy”. If there is no policy associated with a requesting SP, then the default policy is used.

  8. Support the use of an attribute release policy for a specific SP

  9. Support for the “exact” RequestedAuthnContext operator (returning an error or selecting from among multiple login methods, as appropriate)

  10. In general, for the SAML profile(s) supported, all content and features defined by the standard should be evaluated for consideration, and if not supported should be fully documented as such.

Level 2 IdP Requirements

  1. Support the use of an attribute release policy that acts based on the presence of specific EntityAttributes in metadata (via the 3-tuple Name, NameFormat, and AttributeValue)

  2. Support the use of an attribute release policy that acts based on the presence of specific RequestedAttribute elements in metadata (via the 3-tuple Name, NameFormat, and optionally AttributeValues)

  3. Support the SAML 2 ForceAuthn feature

  4. Support the SAML 2 IsPassive feature

  5. Support for all SAML-defined RequestedAuthnContext operators (exact, minimum, maximum, better)

  6. Support for the SAML 2 SingleLogout profile and the SAML V2.0 Asynchronous Single Logout Protocol Extension

  7. Support for the SAML V2.0 Enhanced Client or Proxy Profile Version 2.0

  8. Support for some mechanism for user-granted consent to release attributes

  9. Support for the SAML V2.0 Metadata Profile for Algorithm Support, allowing control over selected signing and encryption algorithms based on metadata.

SP Requirements

All SP deployments MUST satisfy the Basic Metadata Requirements listed above.

Level 1 SP Requirements

  1. Allow flexible configuration of requirements for encrypted and/or signed assertions - allow deployer to require either, both, or none.

  2. Support for SAML V2.0 Web Browser SSO as defined in the SAML V2.0 Profiles specification as updated by Errata (linked on the OASIS Security Services Technical Committee wiki page)

  3. Support for the MACE-Dir SAML Attribute Profiles

  4. Must allow use of a transient NameId (see section 8.3 of OASIS SAML 2.0 core http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf)

References

  1. SAML V2.0 Metadata Extension for Entity Attributes https://wiki.oasis-open.org/security/SAML2MetadataAttr
  2. SAML V2.0 Identity Assurance Profiles https://wiki.oasis-open.org/security/SAML2IDAssuranceProfile
  3. SAML V2.0 Metadata Extensions for Login and Discovery User Interface https://wiki.oasis-open.org/security/SAML2MetadataUI
  4. more
#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels