SAML SSO Vendor Integration
UC Davis offers SAML 2.0 for single sign-on (SSO) authentication.
If you are new to SAML, these links may be useful for an overview:
- https://wiki.shibboleth.net/confluence/display/CONCEPT
- https://spaces.at.internet2.edu/display/federation/InCommon+Federation+Library
Questions for the Vendor and/or Department Sponsor:
- Please provide any document(s) describing your SAML integration requirements and technical specifics.
- What are the Entity IDs for your SAML SPs?
- Development/QA/UAT, if any.
- Production.
- What SAML attributes do you expect to receive? (With SAML 2 URIs, if known)
- Which attribute(s) are required, which are optional?
- Which attribute(s) do you expect/want as identifiers?
- Do you require the identifying attribute to be expressed as a SAML
NameID
? If so, which SAMLNameIDFormat(
s)?
- Do you support:
- SP-initiated SSO?
- Unsolicited SSO (aka IdP-initiated SSO)?
- SAML 2.0 encryption?
- If not, please provide evidence your implementation is either not subject to or has been recently patched against recent XML Signature attacks.
- What is(are) the SSO-initiation URL(s) for your service? I.e., what triggers SAML authentication?
- Does the application require an SSO test account?
- What attributes are needed for the test account? N.b. some attributes, such as student ID, are not available for test accounts.
- A test account generally requires a temporary affiliate (TAF) sponsorship by the department.
- MFA
- Does the application require MFA? If so, does the application support the REFEDS MFA profile?
- Does the application require an exemption from MFA? N.b. an exemption generally requires review/approval by the campus ISO.
- How do you handle logout?
- Log out locally from the application, leaving user's SSO session intact?
- SAML SLO (complete logout)?
- How do you handle provisioning of new users? Do they need to be pre-identified in your system, or do you create accounts on first login (aka just-in-time provisioning)?
- How do you handle account de-provisioning? People may need to have access to your system revoked even though they may still be able to authenticate through UC Davis SSO.
- Given UC Davis manages computing accounts for several different types of affiliates, how do you control access to the application (authorization)?
UC Davis Authentication information/requirements/preferences:
- SAML SSO requires trusted, mutual exchange of SAML metadata.
- UC Davis is a member of the InCommon Federation.
- UCD's IdP metadata may be obtained from the InCommon federation. See:
https://spaces.at.internet2.edu/display/MDQ/Metadata+Distribution+Service+Documentation - The UC Davis SAML IdP entityID is
urn:mace:incommon:ucdavis.edu
- The vendor must verify the digital signature of this metadata to prevent IdP impersonation. Information on signing keys etc. may be found on the InCommon site.
- UCD's IdP metadata may be obtained from the InCommon federation. See:
- UCD prefers the vendor be a member of the InCommon or eduGAIN federations, principally to streamline management of SAML metadata and key rollover.
The alternative has potential for non-trivial downtime in response to SAML metadata changes. - In the absence of federation membership, the vendor must provide their SAML SP metadata though a secure mechanism.
Sending as an email attachment without some additional means of verifying integrity/authenticity is not acceptable.
- UC Davis is a member of the InCommon Federation.
- UCD Requires SAML 2.0
- UCD strongly prefers the use of SAML 2.0 assertion or attribute encryption.
- The vendor's SAML SP must support and validate SAML assertion cryptographic signature.
- UCD prefers the use of SP-initiated SSO.
- UCD strongly prefers the use of standard SAML attributes over vendor-custom SAML attributes. Accommodating custom attributes generally delays deployment.
- Notes
- Pre-loading accounts into the vendor application (vs. just-in-time provisioning on first login) means user identifiers generally need to be known beforehand.
- Some SAML identifiers are persistent, unchanging, and never reused, but it's generally not possible to know these beforehand.
- Email address is not a good good identifier unless co-issued with a SAML persistent-id.
- eduPersonPrincipalName (ePPN) is a common identifier used in SAML authentication
- It is a domain-qualified login ID (e.g., userid@ucdavis.edu).
- ePPN is not the person's email address.
- ePPN SAML 2.0 attribute identifier
urn:oid:1.3.6.1.4.1.5923.1.1.1.6
- Most UCD users will only know the id before the @ symbol.
Please include shibadmin@ucdavis.edu in correspondence.