Shibboleth, Federating with external vendors
For IT Pros. If you wish to use Shibboleth federation so that people can use their NetID and password to log in to third party vendors (such as a textbook publisher or other online service provider), you'll need to gather the following information.
The desired situation
You want to use Shibboleth to securely authenticate people to a third party service provider, so that University people are allowed to use their NetIDs and passwords to access appropriate access to online resources without needing to create separate accounts in the third party system. (A common example involves access to online course materials provided by a textbook publisher.)
If the vendor is a member of the InCommon federation, the process will be simpler than if they don't, but it's still possible to make the connection work.
What to tell the vendor
- The University of Illinois is a member of InCommon.
- Our entity ID is urn:mace:incommon:uiuc.edu.
- Note: We strongly prefer vendors to take our metadata from InCommon directly. While it is possible to get our metadata from https://shibboleth.illinois.edu/idp/shibboleth instead, consuming metadata from the local URL has known risks.
- If the vendor can't accept XML metadata from our campus IDP, they may ask for a "single sign on URL" or a "login URL."
They will need three pieces of information:
- Either the POST or the redirect form of the login URL:
- POST: https://shibboleth.illinois.edu/idp/profile/SAML2/POST/SSO
- Redirect: https://shibboleth.illinois.edu/idp/profile/SAML2/POST/SSO
- The logout URL:
- The X509 certificate file:
If this service will be used by students:
Before the University can release data about students to vendors, we need to understand their data stewardship practices and get the Registrar's agreement.
Ask the vendor for this connection information:
- What name identifier format does your service require from our campus Identity Provider?
- The vendor may need a name identifier in the form of an email address, a persistent value (such as an encrypted version of the person's UIN), or a transient value (such as a random unique number used for this particular system). The transient value is recommended when possible.
- What other attributes does your service require from our campus Identity Provider?
- Other information such as first and last name, email address, or affiliation with the University may be relevant to providing resources to particular individuals.
- Do you accept encrypted assertions?
- We prefer to use encrypted assertions, but if unencrypted assertions are necessary, please contact email@example.com to make arrangements.
- Are you a member of InCommon?
- If so:
- If not:
- How do we obtain your service provider metadata?
- This will be an XML document that describes how our campus Shibboleth identity provider communicates with the vendor.
- If the vendor does not have a document like this, you'll need to ask them the following three questions.
- If you don't have either InCommon membership or a service provider metadata XML document:
- What is your Entity ID?
- What is your assertion consumer service endpoint?
- This is the URL to which we should send our assertion from the IDP.
- What are your X509 SAML certificates?
- These are the certificates used for signing and encryption. They're not the same as an SSL certificate protecting a website.
Give the vendor's information to shibboleth-mgr:
After you've exchanged this information with the vendor, send this information to firstname.lastname@example.org so that we can configure our campus IDP to communicate with the vendor's service.