About the University Identity Provider
We run a Shibboleth Identity Provider (IdP) for single-signon (i.e. you only have to authenticate once, and subsequent attempts to use services requiring authentication will not require you to log in again).
Before you can authenticate against our IdP, you must send us your SP's metadata.
We always install your SP metadata on the test IdP first, as it is faster and easier for us to make changes to the IdP configuration to support your SP in test than in production. Once your configuration has stabilized and you are satisfied with your testing, you can ask us to migrate your metadata to the production IdP.
The test instance of the IdP uses the test X.500 directory for authentication and attribute retrieval. Most people are not populated in the test directory. Ask Identity Management to copy to the test directory any users you plan to test with (send a list of Internet IDs or EmplIDs to firstname.lastname@example.org).
If you need additional attributes about users returned when they authenticate, you may need to fill out the Access Request Form and send it in to OIT Data Security so it can be routed to the data owners for approval. Then we can configure our IdP to release the requested attributes to your SP.
Here is a comprehensive list of attributes currently available from our IdP. We also have an attribute-map.xml file that has these attributes already defined. Just download it and replace your existing attribute-map.xml file with it.
Retrieving additional attributes with Shibboleth describes how to configure your SP and application to work with additional attributes step-by-step.
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 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 reauthentication before they can use your application again).
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. See the attribute list above for the SAML attribute name. If the user is logging in with a guest account, the isGuest attribute will have the value "Y". If not, it will have the value "N". If you are using Apache .htaccess or httpd.conf rules to enforce access control, use this line:
Require isGuest N
If you are using the RequestMap to enforce access control, use something like this:
<Path name="secure" authType="shibboleth" requireSession="true">
To ensure the appropriate guest account link appears on the login page, update your metadata to include a displayGuestLink attribute to your EntityDescriptor element with the value "standard" for standard guest accounts (formerlyguestable=1) or "portal" for portal guest accounts (formerly guestable=3):
There is an additional IdP that allows you to authenticate as yourself, but get the attributes for another user. This "spoofing" (also known as "masquerading" or "testing") IdP requires permission from OIT Data Security to use.
Use this metadata for the spoofing IdP:
The spoofing metadata, like the test IdP, uses the test X.500 directory for authentication and attributes.
Our IdP supports Two Factor authentication using Duo.