About the University Identity Provider

Initial Setup Process

The University of Minnesota operates a Shibboleth Identity Provider (IdP) for Single Sign-On (i.e. you only have to authenticate once, and subsequent attempts to use services requiring authentication will not require you to log in again). 

Shibboleth is a system that controls access to restricted web-based resources. The entity providing the restricted web service or content is referred to as the Service Provider (SP). When the University enters into an agreement with an SP, the SP is responsible for verifying the identity of University users attempting to access their restricted content. The process of authentication is as follows: 

  1. When the SP detects a user attempting to access restricted content, it generates an authentication request to the University's Shibboleth Identity Provider (IdP).
  2. The University's IdP authenticates the username and password, then sends an authentication response to the SP. An SP may request various attributes from the IdP -- for example, the user's first name; the IdP only returns attributes included in the agreement between the University and the SP.
  3. The SP verifies the IdP's response and sends the request through to the resource which allows the University user to access the restricted content.

To set up an SP to authenticate University users for web-based services or content, complete the Shibboleth request form. You will need to include the SAML metadata for your Service Provider (SP) as part of the request process.

We always set up your Service Provider (SP) on the test IdP first, as it is faster and easier to make changes to the IdP configuration to support a SP in test than in production. Once the configuration has stabilized and you are satisfied with your testing, you can ask OIT to migrate your metadata to the production IdP.

We are also members of the InCommon Federation, which handles metadata exchange between participants and facilitates interoperation between IdPs and SPs in the federation. If your SP is part of InCommon, you do not need to import our metadata or give us your metadata; it is all handled through the federation. You may still need to request attributes if the default is not sufficient.

Available Attributes

If you need additional attributes about users returned when they authenticate, you will need to submit a Real-Time Directory Data access request form (ARF) so it can be routed to appropriate data owners for approval. Then we can configure our IdP to release the requested attributes to your SP. Here is a list of attributes currently available from our IdP.

Logout

If you are logged into an application that uses Shibboleth for authentication, and you wish to use an additional application in the same browser, you will not be required to sign in again. This is because the University of Minnesota uses “single sign-on” (SSO). We do not, however, support “single log out.” This means that if you log out of one of those applications, you will remain signed in to the other application. However, if you wish to access yet another application after signing out of one, it will require you to sign in again, even though you are already signed in to a Shibboleth application and the University uses single sign-on. For maximum security protection, you should always clear cookies and close your browser window after you sign out of your applications. This is the only way to ensure that you are completely logged out.

Applications that offer a "logout" function can use our custom Shibboleth Logout endpoint to force a logout from the IdP (and thus require re-authentication before they can use your application again).

Guest accounts

Guest accounts can authenticate like any other accounts. You can configure your SP to reject guest accounts by checking the isGuest attribute, which will be released by default to all SPs.

Two-factor authentication

Our IdP supports multi-factor authentication using Duo Security. Note that most users are now required to use Duo Security regardless of whether a particular service provider requires it (guest accounts are the main exception). Thus your service provider will largely benefit from this protection even if you do not take additional steps to require multi-factor authentication.