At the November TAC F2F, we discussed having a matrix of best practices by which to evaluate registered sites to help set expectations and create peer pressure. This is a preliminary set of suggested criteria.
Policy
- Participant Operational Practices (POP)
- Appropriate Contacts
- Strawman: Each
<md:EntityDescriptor>
element SHOULD contain both an <md:ContactPerson>
element with contactType="support"
and an <md:ContactPerson>
element with contactType="technical"
. The <md:ContactPerson>
elements SHOULD contain at least one <md:EmailAddress>
element. If a contact (either support or technical) is a real person, the <md:givenName>
and <md:surName>
elements SHOULD reflect the person's real name. If a contact is a non-person (such as a mailing list), the <md:givenName>
and <md:surName>
elements SHOULD be omitted.
- Security Incident Response Policy
- IdP Terms of Use (targeted at the user)
- (see the Participation Agreement for basic requirements)
- SP Privacy Policy (targeted at the user)
- Attribute Release Policy
Technical Basics
- Metadata Consumption
- refresh metadata daily
- verify the XML signature
- check the expiration date
- X.509 Certificates in Metadata
- use of self-signed certificates with 2048-bit keys
- no unexpired certificates in metadata
- controlled migration of keys
- User Interface Elements in IdP/SP Metadata
- Requested Attributes in SP Metadata
- In general, it is RECOMMENDED that all service endpoints be protected with SSL/TLS.
- SAML V2.0 Support
- IdPs MUST include a SSL/TLS-protected endpoint that supports the SAML V2.0 HTTP-Redirect binding
- IdPs MUST support the
urn:oasis:names:tc:SAML:2.0:nameid-format:transient
name identifier format
- SPs that support SAML V2.0 should indicate so in metadata (be specific)
- SPs MUST include a SSL/TLS-protected endpoint that supports the SAML V2.0 HTTP-POST binding
- SPs MUST include an encryption key
- SAML V1.1 Support
- IdPs MUST include a SSL/TLS-protected endpoint that supports the Shibboleth 1.x AuthnRequest protocol
- IdPs MUST support the
urn:mace:shibboleth:1.0:nameIdentifier
transient name identifier format
- SPs MUST include a SSL/TLS-protected endpoint that supports the SAML V1.1 Browser/POST profile
- SAML V2.0 Enhanced Client or Proxy (ECP) Support
- IdPs MUST include an endpoint that supports the SAML V2.0 SOAP binding
- does this endpoint need to be SSL/TLS-protected?
- SPs MUST include an endpoint that supports the SAML V2.0 Reverse SOAP (PAOS) binding
- does this endpoint need to be SSL/TLS-protected?
Operational Maturity
- Maintaining Supported Software
- Operational Compliance with Metadata IOP
- Federation a "First Order" UI
- Discovery
- Choices offered should result in an "acceptable" experience
- SP User Interface
- Guidance for the flow through SP, DS, IdP
- Visual "branding" (e.g., InCommon logo in appropriate places)
- Appropriate help links/contacts at each step.
- Error Handling
- Look and Feel
- Useful Contacts
- Identity attributes
- Regular (event-driven? nightly?) synchronization with systems of record
- Documentation of locally-defined attributes
- Education
- For end-users
- Privacy
- Appropriate use
- Protection of secrets
- For service providers
- Privacy requirements
- Good UI practice
Maximizing the Federation
- Documented Attribute Release Process
- IdPs SHOULD support the
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
name identifier format and/or the eduPersonTargetedID
attribute
- IdPs SHOULD support the
urn:oasis:names:tc:SAML:2.0:nameid-format:transient
encrypted name identifier format (requires Shib IdP 2.3)
- since this identifier can be reversed, it is especially useful for security incident response
- Release of "basic" attributes w/o admin involvement (via consent or otherwise)
Parked Items
- Keys of less than a certain age
- We should consider what, if any, age is actually "too old"
- Full saml2int conformance
- InCommon Implementation Profile conformance
- Could identify "exceptions to conformance" to highlight specific missing capabilities or could break profile into separate features in the matrix
Meeting Notes
Meeting Notes - April 21, 2011