(Obviously still draft at this point)
(Mostly expected for inclusion in saml2int, but may require additional review)
SP-Initiated SSO
Service Providers must support the direct generation of authentication request messages conforming to the SAML Authentication Request Protocol [SAML Core, 3.4].
Service Providers that want to bypass user-initiated discovery then Service Providers SHOULD support this profile http://docs.oasis-open.org/security/saml/Post2.0/sstc-request-initiation.html
Requiring the use of unsolicited responses (or so called “IdP-initiated SSO requests) is not a substitute for this requirement.
Addresses: Deployment Issue 4; saml2int section: 8.1
SP Deep Link support
Applications that support deep linking and direct addressability of protected resources MUST be maintain support for such links in the presence of Web Browser SSO. That is, it MUST be possible to request an arbitrary protected resource and (authorization permitting) have it supplied as the result of a successful SAML SSO profile exchange. In addition, it is RECOMMENDED that Service Providers support the preservation of POST bodies across a successful SSO profile exchange, subject to size limitations dictated by policy or implementation constraints.
The SAML binding-specific RelayState feature is typically used to maintain state required to satisfy both of these requirements, the exact detail of which is left to implementations.
Support for unsolicited responses (or so-called IdP-initiated SSO) is not a substitute for this requirement.
Addresses: Deployment Issue 5; saml2int section: n/a
Clockskew support
Deployers MUST support a minimum of three (3) and a maximum of five (5) minutes of clock skew – in either direction -- when interpreting xsd:dateTime values in assertions and enforcing security policies based thereupon.
The following is a non-exhaustive list of items to which this directive applies: NotBefore, NotOnOrAfter, and validUntil XML attributes found on Conditions, SubjectConfirmationData, LogoutRequest, EntityDescriptor, EntitiesDescriptor, RoleDescriptor, and AffiliationDescriptor elements.
Addresses: Deployment Issue 9, 46; saml2int section: 8.1, 9.1
Keys in metadata
Public keys used for encryption and signature verification SHOULD be communicated using long-lived, unexpired, self-signed certificates.
This is recommended to avoid problems with libraries that will not allow processing of expired certificates.
Addresses: Deployment Issue 12; saml2int section: 5
Authentication Context requests
An SP that only accepts specific AuthnContextClassRef value(s) in assertions MUST specify those allowable values in the RequestedAuthnContext element of AuthnRequests it generates, with the match attribute set to "exact".
An SP that does not require specific AuthnContextClassRef value(s) in assertions MUST NOT include any RequestedAuthnContext elements in AuthnRequests it generates.
Addresses: Deployment Issue 17; saml2int section: 8.2, 9.2
Attribute Values Constraints
When consuming attributes with standard definitions, Service Providers SHOULD NOT impose constraints that are not part of the definitions of those attributes. This may imply supporting extra long attribute values, multiple attribute values, broad character set support,and the like.
Addresses: Deployment Issue 16, 44; saml2int section: 6, 7
IdP Error URLs
IdP deployers MUST provide a working error URL in published metadata
Relying parties SHOULD direct clients to this URL when an authentication error occurs that cannot be resolved locally.
<Is this still a best practice?>
Addresses: Deployment Issue 49; saml2int section: 5
Subject ID Value Uniqueness
(Do we want a qualification statement for non-SubjectIDs? E.g., ePSA, ePE)
SPs MUST be able to avoid inappropriate Subject ID value collisions across different IdPs.
SPs and IdPs SHOULD use qualified identifiers to support this requirement, with the SPs validating that IdPs assert appropriate qualifiers per IdP. It is RECOMMENDED that the "Scope" Metadata extension be used to support qualified identifiers. (Is this the correct reference? http://macedir.org/docs/internet2-mace-dir-saml-attributes-latest.pdf)
Where IdPs do not assert qualified identifiers for Subject IDs, SPs SHOULD instead internally associate each SubjectID with the asserting IdP.
Addresses: Deployment Issue 45, 48; saml2int section: 7, 9.2
XML Encryption
Deployments MUST support encryption of assertions using XML Encryption for the Web SSO profile.
Deployments that support SLO MUST support encrypted NameIDs for the SLO Profile. (This doesn't sound like XML encryption, but just encryption...)
Encryption MUST support the AES-GCM cipher for this encryption (XMLENC: http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/)
Addresses: Deployment Issue 10; saml2int section: 5, 9.1
Provisioning and Authorization of SAML-only Users
Applications that creates new user profile when new a SubjectID is received (Just In Time, or On the Fly provisioning) SHOULD also rely on a separate attribute's value(s) to trigger provisioning of user access. Conversely, absence of that separate attribute, or specific values thereof, should cause user deprovisioning (or deauthorization) to occur.
Deployments SHOULD rely on standard eduPerson attributes intended for this purpose, specifically eduPerson(Scoped)Affiliation and/or eduPersonEntitlement where appropriate.
IdPs MUST NOT be required to block assertions from being generated at the IdP as a substitute for the SP accepting attributes indicating the user's authorization status. (This may be the actual requirement)
Addresses: Deployment Issue 7, 8; saml2int section:n/a
Metadata
I think we still have open questions on how to formulate the Metadata requirements.
Support for Multiple IdPs
Service Providers MUST allow clients the option to authenticate specific resource URLs against more than one identity provider. (This language is from the Impl Profile)
When more than one Identity Provider authenticates the same resource URL, IdP selection SHOULD be supported using the OASIS SSTC SAML v2.0 Identity Provider Discovery Profile.
Addresses: Deployment Issue 13, 14, 43; saml2int section:8 (or new)
Forced Re-authentication
Identity providers must ensure that a request for forced reauthentication (ForceAuthn="true") results in the Subject being required to authenticate in a way that proves that the Subject is present.
If the IdP cannot prove subject presence, the IdP MUST [respond with an error?] [respond with the previous authninstant?]
Addresses: Deployment Issue 35; saml2int section:n/a