...
- To ensure that scoped attributes are globally unique, a scope in metadata should be a DNS domain controlled by the IdP.
X.509 Certificates in Metadata
See X.509 Certificates in Metadata, particularly:
The certificates registered by a participant contain at least 2048-bit RSA public keys, are self-signed, are not expired, and do not carry revocation-related extensions.
- Certificate migration is performed in a controlled fashion that does not require participants who follow metadata consumption best practices to specially accommodate the change.
- Service providers include and support an encryption key in SP metadata.
SAML Protocol Endpoints
See Endpoints in Metadata, particularly:
- All endpoints are protected with SSL/TLS.
- All entities support SAML V2.0 Web Browser SSO.
Endpoints in IdP Metadata
See IdP Endpoints, particularly:
- IdPs protect all endpoints with SSL/TLS.
- IdPs support SAML V2.0 Web Browser SSO and (optionally) SAML V1.1 Web Browser SSO.
- IdPs support authentication requests via the SAML V2.0 HTTP-Redirect binding and (optionally) the legacy Shibboleth 1.x AuthnRequest protocol.
- IdPs support SAML V2.0 Enhanced Client or Proxy (ECP) authentication requests from non-browser clients via the SAML V2.0 SOAP binding using either Basic Authentication or TLS Client Authentication.
- IdPs (optionally) support SAML V1.1 attribute queries but do not advertise support for SAML V2.0 attribute queries unless necessary.
Endpoints in SP Metadata
See SP Endpoints, particularly:
- SPs protect all endpoints with SSL/TLS.
- SPs support SAML V2.0 Web Browser SSO, the SAML V2.0 Identity Provider Discovery Protocol, and the use of XML Encryption.
- SPs support the SAML V2.0 HTTP-POST binding and (optionally) the SAML V1.1 Browser/POST profile.
- SPs (optionally) support the SAML V2.0 Enhanced Client or Proxy profile.
- SPs that support SAML V1.1 Web Browser SSO also support SAML V1.1 attribute queries.
...
- SPs that seek a wide audience of IdPs without explicit contracts or arrangements ahead of time specify the attributes they need in order to facilitate consent-driven user interfaces.
Operational Maturity
Maintaining Supported Software
See Maintaining Supported Software, particularly:
- Appropriate staff monitor "security" and/or "announce" mailing lists for critical software.
- Software versions are reasonably current and upgraded ahead of "end of life" dates.
Protect Against Failed Metadata Processes
See Protect Against Failed Metadata Processes, particularly:
- Shibboleth IdP
Allocate at least 1500MB of heap space in the JVM
Enable DEBUG-level logging on selected Java classes
Federated User Experience
See Federated User Experience with particular attention to the following.
Initiating Login
- A "Login" link is placed in the upper right corner.
- The main application screen is uncluttered by choices of different login mechanisms.
...
Maximizing the Federation
Identity Provider Attribute Release Process
See Attribute Release Process, particularly:
- IdPs make common identity attributes (identifiers, displayName, mail) available to educationally useful/non-commercial SPs for significant user populations, either subject to opt-in user consent, or with an opt-out process.
- IdPs document and publish their policies and procedures for the release of attributes. The <PrivacyStatementURL> element should link directly or indirectly to this information.
- An "administrative" contact is documented for each IdP and SP identifying a point of contact for attribute release issues.
Persistent Identifier Support
See Persistent Identifier Support, particularly:
- IdPs support the eduPersonPrincipalName and eduPersonTargetedID attributes.
- When SAML 2.0 is used, the "persistent" <NameID> format is used to represent the eduPersonTargetedID attribute.
- The release of eduPersonTargetedID is automated for most or all affiliates (save perhaps for students opting out under FERPA) to SPs that are not otherwise subject to user anonymity requirements, such as some library services.
...