SAML SSO Vendor Integration

Owned by Tom Poage (Unlicensed)
Last updated: Oct 31, 2019
3 min read

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:

Questions for the Vendor and/or Department Sponsor:

  1. Please provide any document(s) describing your SAML integration requirements and technical specifics.
  2. What are the Entity IDs for your SAML SPs?
    1. Development/QA/UAT, if any.
    2. Production.
  3. What SAML attributes do you expect to receive?  (With SAML 2 URIs, if known)
    1. Which attribute(s) are required, which are optional?
    2. Which attribute(s) do you expect/want as identifiers?
    3. Do you require the identifying attribute to be expressed as a SAML NameID? If so, which SAML NameIDFormat(s)?
  4. Do you support:
    1. SP-initiated SSO?
    2. Unsolicited SSO (aka IdP-initiated SSO)?
    3. SAML 2.0 encryption?
      1. If not, please provide evidence your implementation is either not subject to or has been recently patched against recent XML Signature attacks.
  5. What is(are) the SSO-initiation URL(s) for your service? I.e., what triggers SAML authentication?
  6. Does the application require an SSO test account?
    1. What attributes are needed for the test account? N.b. some attributes, such as student ID, are not available for test accounts.
    2. A test account generally requires a temporary affiliate (TAF) sponsorship by the department.
  7. MFA
    1. Does the application require MFA? If so, does the application support the REFEDS MFA profile?
    2. Does the application require an exemption from MFA? N.b. an exemption generally requires review/approval by the campus ISO.
  8. How do you handle logout?
    1. Log out locally from the application, leaving user's SSO session intact?
    2. SAML SLO (complete logout)?
  9. 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)?
  10. 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.
  11. 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:

  1. SAML SSO requires trusted, mutual exchange of SAML metadata.
    1. UC Davis is a member of the InCommon Federation.
      1. UCD's IdP metadata may be obtained from the InCommon federation. See:
        https://spaces.at.internet2.edu/display/MDQ/Metadata+Distribution+Service+Documentation
      2. The UC Davis SAML IdP entityID is urn:mace:incommon:ucdavis.edu
      3. 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.
    2. 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.
    3. 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.
  2. UCD Requires SAML 2.0
    1. UCD strongly prefers the use of SAML 2.0 assertion or attribute encryption.
    2. The vendor's SAML SP must support and validate SAML assertion cryptographic signature.
    3. UCD prefers the use of SP-initiated SSO.
  3. UCD strongly prefers the use of standard SAML attributes over vendor-custom SAML attributes. Accommodating custom attributes generally delays deployment.
  4. Notes
    1. Pre-loading accounts into the vendor application (vs. just-in-time provisioning on first login) means user identifiers generally need to be known beforehand.
    2. Some SAML identifiers are persistent, unchanging, and never reused, but it's generally not possible to know these beforehand.
    3. Email address is not a good good identifier unless co-issued with a SAML persistent-id.
    4. eduPersonPrincipalName (ePPN) is a common identifier used in SAML authentication
      1. It is a domain-qualified login ID (e.g., userid@ucdavis.edu).
      2. ePPN is not the person's email address.
      3. ePPN SAML 2.0 attribute identifier urn:oid:1.3.6.1.4.1.5923.1.1.1.6
      4. Most UCD users will only know the id before the @ symbol.

Please include shibadmin@ucdavis.edu in correspondence.