SAML V2.0 Implementation Profile for Federation Interoperability
2.0 Common Requirements
2.1. General
[IIP-G01]
Implementations MUST allow for reasonable clock skew between systems when interpreting xsd:dateTime values and enforcing security policies based thereupon.
Implemented in python-saml library and set by default as 5 minutes.
[IIP-G02]
When specific constraints are absent in the SAML standards or profile documents, implementations MUST be able to accept, without error or truncation, element and attribute values of type xs:string that are comprised of any combination of valid XML characters and contain up to 256 characters. This requirement applies both to types defined within the SAML standards (such as transient and persistent NameIDs) and to user-defined types.
python-saml library and Circulation Manager don’t impose any restrictions on string length.
[IIP-G03]
Implementations MUST not send and MUST have the ability to reject SAML protocol messages containing a DTD (Document Type Definition).
python-saml library and Circulation Manager don’t send messages containing a DTD. However, they CAN accept them.
2.2. Metadata and Trust Management
2.2.1. Metadata Exchange
[IIP-MD01]
Identity Providers MUST and Service Providers SHOULD support the acquisition of SAML metadata rooted in <md:EntityDescriptor> elements via the Metadata Query Protocol, defined in [SAML-MDQ] and [MDQ]. Implementations that claim support for this protocol MUST be able to request and utilize metadata from one or more MDQ responders for any peer entity from which a SAML protocol message is received.
[IIP-MD02]
Implementations MUST support the routine consumption of SAML metadata from a remote location via HTTP/1.1 [RFC2616] on a scheduled/recurring basis, with the contents automatically applied upon successful validation. HTTP/1.1 redirects (status codes 301, 302, and 307) MUST be honored. Implementations MUST support the consumption of SAML metadata rooted in both <md:EntityDescriptor> and <md:EntitiesDescriptor> elements by this mechanism. In the latter case, any number of child elements MUST be allowed.
[IIP-MD03]
Implementations MUST be able to validate the authenticity and integrity of SAML metadata by verifying an enveloped XML Signature [XMLSig] attached to the root element of the metadata. Public keys used for signature verification of the metadata MUST be configured out of band. These keys MAY be contained in X.509 certificates but it MUST be possible to ignore the other contents of the certificate and verify the XML Signature based solely on the public key. It MUST be possible to limit the use of a trusted key to a single metadata source.
[IIP-MD04]
Implementations MUST be capable of rejecting SAML metadata if any one of the following conditions is true:
- The validUntil XML attribute on the root element is missing
- The value of the validUntil XML attribute on the root element is a xsd:dateTime in the past
- The value of the validUntil XML attribute on the root element is a xsd:dateTime too far into the future, where "too far into the future" is a configurable option.
Implemented in python-saml library.
2.2.2. Metadata Usage
[IIP-MD05]
Implementations MUST support SAML Metadata as defined in the following OASIS specifications:
- SAML V2.0 Metadata [SAML2Meta], as updated by Errata [SAML2Errata]
- SAML V2.0 Metadata Schema [SAML2MD-xsd]
- SAML V2.0 Metadata Interoperability Profile [SAML2MDIOP]
- SAML V2.0 Metadata Extension for Entity Attributes [MetaAttr]
- SAML V2.0 Metadata Extension for Algorithm Support [SAML2MetaAlgSup]
- SAML V2.0 Metadata Extensions for Login and Discovery User Interface [MetaUi]
The above list of specifications includes all material relevant to functionality required by this profile, but is not intended to be exhaustive. In accordance with the Extensibility section, other metadata extension content may be present and MUST NOT prevent consumption and use of the metadata.
[IIP-MD06]
Implementations MUST support the interpretation and application of metadata as defined by the SAML V2.0 Metadata Interoperability Profile [SAML2MDIOP]. It follows that implementations MUST be capable of interoperating (leading to success or failure as dictated by default configuration) with any number of SAML peers for which metadata is available, without additional inputs or separate configuration. In accordance with the SAML V2.0 Metadata Interoperability Profile [SAML2MDIOP], metadata MUST be:
“usable as a self-contained vehicle for communicating trust such that a user of a conforming implementation can be guaranteed that any and all rules for processing digital signatures, encrypted XML... can be derived from the metadata alone, with no additional trust requirements imposed.”
