Information for U-M information technology staff members who want to use Shibboleth to provide access to a U-M web resource or to get access to an external web resource for users in their department or unit.
Expand All Content
Shibboleth provides extended privacy functionality that allows browser users and their home site to control the attributes released to each application. Using Shibboleth-enabled access simplifies identity and permissions management for organizations supporting both users and applications.
Shibboleth was and is being developed in an open and participatory environment, is freely available, and is released under the Apache Software License.
|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, or 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.|
Use cosign if your web application, site, or service will be used primarily by U-M students, faculty, staff, alumni, or sponsored affiliates. Non U-M people can create Friend accounts to use cosign-protected sites. Cosign is a particularly good choice if you need strong security features such as global logout, multiple authentication factors (e.g., Duo), reauthentication, idle timeouts, or IP checking.
Use Shibboleth if 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 email@example.com for more.
Use Shibboleth if you are outsourcing the service to a non U-M vendor that offers support for Shibboleth and/or SAML.
Yes, they 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.
Shibboleth is designed to protect web servers, but the range of resources it protects via the web is very broad, and includes library collections, digital media, computing clusters, collaboration sites, sites such as CIC—and more. You can use Shibboleth to protect all the information on a given server, or specific resources on the server.
- For Windows configurations, see How to Set Up a Shibboleth 2.X Service Provider on Windows and IIS.
- For other configurations, see Shibboleth Installation.
- If you would like to set up Shibboleth on your own web server, submit the Shibboleth Configuration Request form.
Access control can be implemented either from within a web application or by using the access control mechanisms native to the web server software, or by the Shibboleth service provider software.
Entitlements are multiple values representing a license, permission, right, and so on to access a resource or service in a particular fashion. Entitlements represent an assertion of authorization to something, precomputed and asserted by the identity provider. This attribute is typically used to assert privileges maintained centrally rather than within specific application databases.
Overall, based on the fact that Shibboleth provides federated identity management to allow logon to multiple service providers, the length of valid authentication in Shibboleth is dependent on the SP being accessed. Shibboleth works using federated identities, so there is a coordinated autonomy between the identity provider (U-M) and the service provider in how they process and handle these requests.