Shibboleth and Cosign

Shibboleth Is Preferred Over Cosign

Shibboleth is the preferred single sign-on option for any new service. The ITS Identity & Access Management team is exploring how the university could begin moving away from use of cosign authentication and toward more modern, flexible, supportable alternatives.

Shibboleth works well if you are outsourcing the service to a non U-M vendor that offers support for Shibboleth and/or SAML. Shibboleth with OpenID Connect is also an option.

Shibboleth also works well when a significant number of the people who will be using your service are members of educational institutions that are members of the InCommon Federation. If your users will be people who are affiliated with an institution, agency, or partner that is a member of a federation other than InCommon, please contact the ITS Service Center.

Consider Alternatives Before Using Cosign

Check the table below to see if Shibboleth will meet your needs. If you feel Cosign is needed for your new service, please contact the ITS Service Center for help to determine if there are alternatives.

Shibboleth & Cosign Compared

Shibboleth Cosign
Inter-institutional U-M users and Friends only.
Limited support for "guests" (transient people with low levels of identity assurance). Full support for guests via Friend Accounts.
Provides both authentication and authorization, including full support for eduPerson schema data and entitlements. Web applications can also do their own authorization, if needed. Provides only authentication, leaving the system administrator and/or application free to select the authorization solution that makes the most sense for their service.
The user's identity is checked by a SP only when the user first accesses that SP within a give session. The user's identity is checked every minute.
No support currently for global logout, multiple factors, reauthentication, idle timeouts, Kerberos ticket proxying, session credential proxying, or IP address checking. Supports all of those listed at left.
Requires system administrators to work with ITS Shibboleth team to setup and configure the SP. Requests for attribute release need to be submitted and approved. Multiple interactions are likely to be required, and may take days or, in complex cases, weeks. System administrators can set up a cosign protected webserver themselves without needing to coordinate with ITS. If special arrangements (exceptions) are needed, these are usually set up within one business day.
Usually requires a WAYF (Where Are You From?) or Discovery Service, even if only embedded into a given SP. No WAYF or Discovery Service required.

Both on One Server?

Shibboleth and Cosign can exist on the same web server, or even on the same virtual host on that server. Getting them to interact, however, is a bit tricky.

However, for any given URL, only one of the two should be enabled. For example, https://example.umich.edu/the-leaders could be protected with Shibboleth while https://example.umich.edu/the-best could be protected with cosign.

Attempting to have both Shibboleth and cosign enabled for the same URL is not supported. Problems may include inconsistent behavior, undocumented and unpredictable interactions, and security problems. In addition, anything that can be made to work now may break at any time in the future as changes are made to the web server software (e.g., Apache HTTPD, Microsoft IIS), Shibboleth, and cosign.