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.

Services opened to any user account (including guests and non-person accounts)

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.

• eduPersonPrincipalName (eppn) attribute: Check to make sure it ends in @illinois.edu.
• You can further protect your setup by adding a whitelist metadata filter to your Shibboleth configuration. This is explained in the Urbana campus-specific configuration scenario.

Services opened to university people (excluding guests and non-person accounts)

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 (eppn) attribute: To restrict access specifically to members of the University of Illinois, check that this value is present and ends in @illinois.edu. (If other universities' members should also be permitted, don't limit the results to @illinois.edu.)
  
  In addition, you should also check:
   
• eduPersonAffiliation attribute: If this attribute is present, the user is a member of a university and not a guest account holder of certain affiliated institutions.
  
  You can check for specific eduPersonAffiliation values for more granularity. Below are the most common affiliation values but a full list of mappings is available in the following KB, Identity Management, Role Types, uiucEduRole, uiucEduType, eduPersonAffiliation Mappings:
  • Students, not including Uni High students: Values student, member.
  • Faculty and staff: Values staff, employee, member.
  • Retirees, Uni High students, and other special types: Value member.
  • IEI and affiliated agencies: Value affiliate.
  • Extra Help employees: Value employee, member.

Notes:

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/community-organizations/.

Services available to members of an Active Directory group

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.

• isMemberOf attribute: Provides access to the group membership information in Active Directory. The values are not identically formatted, but the same data is provided.

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.

Notes:

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)

Services that are manually provisioned

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.