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).
A Checklist for IdPs Deployed in the InCommon Federation
Effective federation depends on IdPs that are both interoperable and trustworthy. To this end, an IdP deployed in the InCommon Federation is expected to satisfy certain requirements. Some of these requirements are operational while other requirements pertain to the IdP's entity descriptor in metadata.
Is your IdP secure and trustworthy?
A trustworthy IdP is the basic building block of the InCommon Federation.
- All SAML exchanges are protected with XML Signature and/or TLS.
- SAML keys are securely generated and stored (see: IdP Key Handling)
- SAML keys are not shared with other entities
- SAML assertions are signed using:
- a strong 2048-bit key
- the SHA-256 digest algorithm
- All browser-facing SAML endpoints are protected with TLS (see: TLS Server Certificates)
- TLS certificates are trusted by the browser
- TLS keys are securely generated and stored
- The IdP's Logo URL is protected with TLS
Protect your private keys!
Maintain positive control of your private keys at all times. Most importantly, safeguard the IdP signing key, which protects all Federation participants from the disastrous consequences of a key compromise.
Is your IdP interoperable?
By definition, an interoperable IdP strives to provide an overall positive federated user experience.
- Support SAML2 Web Browser SSO
- Publish a SAML2
SingleSignOnService
endpoint that supports the HTTP-Redirect binding - Publish long-lived, self-signed certificates in metadata
- Publish technical and administrative contacts in metadata
- Stabilize the following metadata elements:
- entityID
- Scope
- endpoint locations
- certificates
- Support at least the following user attributes:
- eduPersonPrincipalName (non-reassigned)
- eduPersonTargetedID (optional)
- mail (== ePPN)
- displayName
- givenName
- sn (surName)
- Stabilize the values of persistent identifiers (ePPN and ePTID)
- Adopt a measured attribute release process
- [Level 0 Interoperability] release a persistent identifier to all SPs
- [Level 1 Interoperability] release a minimal subset of the R&S attribute bundle to all R&S SPs
- [Level 2 Interoperability] release the Essential Attribute Bundle to all InCommon SPs
- [Level 3 Interoperability] release the Essential Attribute Bundle to all global SPs
- Test and monitor all SAML endpoints 24x7
Respond to all SAML AuthnRequests
Respond to all SAML AuthnRequests, even if the response is nothing more than a SAML error. This gives the SP an opportunity to properly respond to errors.
Is your IdP discoverable?
A discoverable IdP is an interoperable IdP with the following additional properties:
- Do not assert the
hide-from-discovery
entity attribute in metadata. - Publish the following user interface elements in metadata:
- DisplayName
- Information URL (optional)
- Logo URL
- Publish an appropriate error handling URL in metadata
Read more about Discoverable IdPs...
Support Research & Scholarship
Support the Research & Scholarship Category of services now!