For IT Pros: While Shibboleth handles authentication (proving the user is who the user claims), each Shibboleth-protected service will need to make its own decisions about authorization (whether that user is one who is permitted to access this service).
The Shibboleth service performs authentication: verifying the user's identity. In very few cases is this enough to determine whether or not the user should have access to a service â€“ a step called authorization. Authorizing all users based solely on the fact that they successfully authenticated would mean opening up a service to everyone including guest users, arbitrary non-person accounts, and, in some cases, even users from other universities (including guest users and arbitrary non-person accounts from those other universities).
The authorization step is the responsibility of any Shibboleth-protected service. Users are usually authorized based on information, or attributes, returned to a service from Shibboleth after a successful authentication. There are as many ways to authorize a user as there are services using Shibboleth. Only you know what's best for your service. Consider who needs access to the service and how to best identify them.
Here are some of the more common authorization options.
If all UOFI Active Directory user accounts (including guests and arbitrary non-person accounts) are authorized to use this service, then very little needs to be checked after a user logs in.
If unaffiliated guests and non-person accounts are not authorized to use the service, you'll want to use both of the following two eduPerson attributes to control authentication based on people's University affiliation.
eduPersonPrincipalName preferred to uid: It's very important in this case to use eppn, not uid, to get the user's identity. Two users from different universities might have the same NetID. The uid attribute is unscoped: it doesn't end in @illinois.edu. So, two users from different campuses with the same NetID would be seen as the same user. This is a consideration even if you're using a whitelist metadata filter if there's a chance your service might be opened up to other universities in the future.
Alternatively, you may wish to use iTrustAffiliation instead of eduPersonAffiliation. This attribute has a more fine-grained list of affiliations that, for the Urbana campus, matches values seen in the Active Directory uiucEduType attribute. The downside is that only the three University of Illinois campuses are members of the I-Trust federation at this time, and so only the three Illinois campuses offer the iTrust* attributes. If you're federating with other universities, they won't have iTrustAffiliation.
Check attributes with the other university whose members you're authorizing: Other universities may choose to use the values of eduPersonAffiliation differently than the University of Illinois does. The values are a standard set, but each university may have a different way of defining the distinctions between, for example, "staff" and "employee" or "member" and "affiliate". To be certain, it's advisable to check with the other university's Shibboleth Identity Provider service management. Support contacts for InCommon Identity Providers can be found at https://www.incommon.org/federation/info/all-entities.html#IdPs (external link)
If the users accessing your service are already defined in a group in Active Directory, that's a great way to handle authorization. Group memberships for an authenticated user are available from the isMemberOf attribute. You'll notice that the format of the values of this attribute don't look identical to what you'd see in Active Directory, but the same data is all there. You may also choose to query Active Directory directly from your application to check for group memberships. This is an extra step, but if your application is already doing it, it has the same end result.
Specifically, if a user is a member of:
CN=My Application,OU=My Department,OU=Urbana, DC=ad, DC=uillinois,DC=edu
The value corresponding to that membership returned for isMemberOf would be:
urn:mace:uiuc.edu:urbana:my department:my application
The DC= components are removed, and the remaining components are included, all in lower-case. Multiple values will be separated by a semicolon.
Only direct group memberships are returned: Nested group memberships are not returned as part of the attribute's values. So, if the example group, My Application, is in turn a member of a group called All Departmental Applications, Active Directory considers a user who's a member of My Application to be an indirect member of All Departmental Applications. Urbana's Shibboleth Identity Provider only returns direct group memberships.
Different universities use different values: Other universities may also provide an isMemberOf attribute for their users, but in that case the values will not begin with "urn:mace:uiuc.edu".
Check attributes with the other university whose members you're authorizing: Other universities may choose to use the values of isMemberOf differently than the University of Illinois does. The format and specific values returned are up to each university. It's advisable to check with the other university's Shibboleth Identity Provider service management. Support contacts for InCommon Identity Providers can be found at https://www.incommon.org/federation/info/all-entities.html#IdPs (external link)
Some services are only opened to a small number of users that must be manually granted access by a service administrator. In this case, the local user store or database is your authorization check, and you can simply use eduPersonPrincipalName or uid as the attribute from Shibboleth. Be cautious, as mentioned above, when using uid, as two people from different universities may have the same uid.