Shibboleth Protocol Options

Shibboleth uses either Security Assertion Markup Language (SAML) or OpenID Connect (OIDC), two industry standard protocols, to share the attributes (SAML) or claims (OIDC). This means you can set it up to work with a wide variety of vendor-provided software and services. There are a few key differences between SAML and OIDC.

SAML

For most services, SAML will be your best choice. Most services that use Shibboleth at U-M use Shibboleth with SAML. It enables you to do the following:

  • Restrict access only to people who should have access based on authoritative information about their relationship(s) to the university.
  • Allow people from other institutions that are a part of the InCommon Federation or eduGAIN federation to log in using their institutional credentials.
  • Personalize the user experience of your application according to user affiliation.
  • Protect information on a server by requiring a person to be authenticated to gain access. Shibboleth can be used to protect all the information on a server or only specific resources on the server.

OIDC

This is a brand new option for Shibboleth at U-M as of 2018, and support is still being developed. It is being made available because there are some services that require it specifically and do not work with SAML. Here are some aspects of OIDC to be aware of if you wish to use it:

  • Ease of configuration. The configuration process is simpler for OIDC than that for SAML.
  • Mobile application friendly.
  • Only allows you to authenticate persons with U-M credentials. OIDC does not yet support a federated access model.
  • Service Providers using OIDC are currently not able to require two-factor. Two-factor will be enforced if an individual is opted-in to use two-factor, however.
  • U-M supports a subset of the standard OIDC claims (attributes):
    • Name and parts of name
    • uniqname
    • Email address

See also: