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 22 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, primarily software that supports the SAML Web Browser SSO profile, though some of the material is generally applicable to other SAML profiles.

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, and is itself expected to undergo further changes that will more closely align it with the requirements outlined in this draft.

Because this document is a draft, implementors are cautioned that it may (likely will) change before it takes a final form and should not implement in isolation without staying involved with its development.

Extensibility

The extensibility of SAML is of paramount importance to allowing deployments to evolve and meet future needs . The SAML standard has explicit requirements for extensibility in both metadata and in protocol messages, and implementations MUST successfully consume any and all well-formed extensions. Most extension points in SAML have optional semantics, which means that ignoring extension content is a valid and acceptable practice. Unless otherwise noted as a required feature, extensions in metadata and protocol <Extensions> elements MAY be ignored but MUST NOT result in failures.

Basic SAML Metadata Requirements

This section includes a basic set of SAML metadata requirements for both IdP and SP implementations. Support of metadata was strictly optional in the original SAML standard, but it is a critical component of modern SAML deployments.

  1. MUST support SAML Metadata and the following OASIS specifications (linked on the OASIS Security Services Technical Committee wiki page):

    1. SAML V2.0 Metadata [SAML2MD] as updated by Errata [SAML2Errata]

    2. SAML V2.0 Metadata Schema [SAML2MD-xsd]

    3. SAML V2.0 Metadata Interoperability Profile [SAML2MDIOP]

  2. MUST support the routine consumption of SAML metadata from a remote location via HTTP on a scheduled/recurring basis, with the content of the metadata applying automatically upon successful verification. HTTP caching and compression SHOULD be supported

  3. MUST support the consumption of SAML metadata rooted in either <md:EntityDescriptor> or <md:EntitiesDescriptor> elements (in the latter case containing any number of child elements)

  4. MUST support metadata verification based on verification of an XML Signature (at least the RSA with SHA-256 algorithm MUST be supported) against a well-known key. Support for verification by certificate MAY be supported but it MUST be possible to configure verification based solely on the public key in a certificate.

  5. MUST support metadata verification based on the presence of the validUntil XML attribute, and MUST have the ability to enforce limitations on the duration of validity (e.g., it must be possible to block consumption of metadata without such an attribute or one that is too far into the future)
  6. Per [SAML2MDIOP], all run-time configuration of SAML profiles (technical trust and general operational configuration) MUST be manageable via SAML Metadata alone. Further, it MUST be possible to configure an IdP or SP to allow basic interop with any peer for which metadata is supplied, without intervention by the deployer.
  7. Further per [SAML2MDIOP], support for any number of long-lived, self-signed end entity certificates is REQUIRED, as is support for expired certificates, and certificates signed with any digest algorithm. Implementations MAY support alternative syntaxes for bare public keys with equivalent semantics to the same keys appearing in a certificate.

  8. To properly support key rollover:

    1. Implementations MUST be able to consume and utilize two or more signing or encryption keys bound to a single role descriptor. Note that <md:KeyDescriptor> elements containing no use attribute MUST be valid as both signing or encryption keys.

    2. If an implementation supports inbound encryption, it MUST itself be configurable with up to two decryption keys (this is not a metadata requirement but applies to the configuration of keys used by the implementation).

    3. With respect to encryption, implementations MAY use any encryption key of a given type found in a peer's metadata and need not define explicitly which one will be used if more than one is present. Note that multiple keys of different types (e.g., RSA and EC) may well be present in metadata precisely to support different algorithms.

IdP Requirements

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

Level 1 IdP Requirements

  1. Support for SAML V2.0 Web Browser SSO as defined in SAML V2.0 Profiles [SAML2Prof] as updated by Errata [SAML2Errata] (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. (this requirement needs work)

  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 V2.0 SingleLogout profile and the SAML V2.0 Asynchronous Single Logout Protocol Extension [SAML2ASLO]

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

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

  9. Support for the SAML V2.0 Metadata Profile for Algorithm Support, [SAML2MDAlgSupport] which allows control over selected signing and encryption algorithms based on metadata.

SP Requirements

All SP implementations 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

 

#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels