This document is for FAU staff members. It (1) Provides brief background information about federated identity management, InCommon, Shibboleth and attributes; (2) Describes the procedure for requesting that FAU release attributes to a Shibboleth Service Provider (SP) to permit access to FAU users; (3) Provides detailed information about the attributes available to SPs; and (4) Details the general procedure for reviewing and approving attribute release.
About Federated Identity Management
Many individuals need access to resources based in different university units. Federated identity management grants access to multiple websites with the same login information.
With federated identity management, institutions join together in a group—a federation—and agree to trust each other's identity credentials. This can be analogized with bank ATM access- many banks allow ATM access even if the ATM belongs to a different bank.
-
FAU is a member of the InCommon Federation. This means that InCommon members agree to trust FAU to vouch for the identity of someone who has logged in using FAU's web authentication method.
-
FAU also maintains the Florida Atlantic University Federation, a federation consisting of FAU services that are not part of the InCommon federation.
Federations use federated identity management software to allow them to vouch for their users' identities and to share information about whether those users meet the authorization requirements for a particular service (for example, a license that limits access to students). FAU has agreed to trust other InCommon members when they vouch for the identity of people who have logged in using their authentication methods. These institutions share additional identity information, called "attributes," to allow them to make authorization decisions.
About Shibboleth
The InCommon Federation uses Shibboleth federated identity management software from Internet2. According to Internet2:
Shibboleth is a standards based, open source software package for web single sign-on across or within organizational boundaries. It allows sites to make informed authorization decisions for individual access of protected online resources in a privacy-preserving manner.
Shibboleth has two primary components:
-
Identity Provider (IdP). The Internet2 website describes an IdP as, "the software run by an organization with users wishing to access a restricted service." The FAU IdP, which is run by OIT, can be configured to interact with each service that FAU users wish to access via Shibboleth.
-
Service Provider (SP). Internet2 describes an SP as, "the software run by the provider managing the restricted service." FAU units may wish to install Shibboleth SP software to allow users at other institutions to access the web-based services that they provide. For details about and help setting up an SP at FAU, see the Shibboleth Documentation.
About Attributes
Attributes are specific bits of information about people. They include such things as a person's name and email address. There are established attributes with specific names that are used for federated identity management. Institutions can also create their own attributes.
Attributes can be used
-
To determine if someone is authorized to use a particular service. For example, a particular service might be provided only to faculty members.
-
To customize services for people after they have logged in. For example, once you are logged in, a service page may greet you by name and show you a customized menu based on what you are authorized to use.
A basic set of attributes has been pre-approved for release to SPs that are members of the InCommon or Florida Atlantic University federation. Requests for release of additional attributes must go through an approval process.
Attributes Pre-Approved for FAU Release
These attributes are pre-approved by FAU for release, upon confirmation by the user, to Shibboleth-enabled SPs that are members of InCommon or that have been added to the FAU federation.
These pre-approved attributes are based on InCommon's recommended Essential Attribute Bundle. LDAP is the authoritative source for most of these attributes.
|
Attribute (Friendly Name)
|
Definition
|
Encoding
|
| eduPersonPrincipalName |
This is netid@fau.edu, where netid has been replaced with the person's actual netid. This is not the person's email, it is the netid with @fau.edu added to the end.
For example, a person whose netid is doctor_owlsley who has a health email of doctor_owlsley@health.fau.edu will still have an eduPersonPrincipalName of doctor_owlsley@fau.edu
|
SAML 1
urn:mace:dir:attribute-def:eduPersonPrincipalName
SAML 2
urn:oid:1.3.6.1.4.1.5923.1.1.1.6 |
| mail |
This is the person's email address. It is not the email forwarding address. This is netid@fau.edu, where netid has been replaced with the person's actual netid. |
SAML1
urn:mace:dir:attribute-def:mail
SAML2
urn:oid:0.9.2342.19200300.100.1.3 |
| eduPersonAffiliation |
One or more of these values is/are returned: student, faculty, staff, employee, alum, affiliate, member. See below for details about which affiliations fit into these attributes. |
SAML1
urn:mace:dir:attribute-def:eduPersonAffiliation
SAML2
urn:oid:1.3.6.1.4.1.5923.1.1.1.1 |
| eduPersonScopedAffiliation |
The institution the person is affiliated with is added to the eduPersonAffiliation attribute. Our affiliations are appended with @fau.edu. These values are not email addresses. |
SAML 1
urn:mace:dir:attribute-def:eduPersonScopedAffiliation
SAML 2
urn:oid:1.3.6.1.4.1.5923.1.1.1.9 |
| givenName |
This is the person's first name. |
SAML1
urn:mace:dir:attribute-def:givenName
SAML2
urn:oid:2.5.4.42 |
| sn |
Sn stands for surname. It is the person's last name. |
SAML1
urn:mace:dir:attribute-def:sn
SAML2
urn:oid:2.5.4.4 |
| eduPersonEntitlement |
This is the standard entitlement attribute used by InCommon. It is used to determine whether a user is entitled to use a particular service. It is pulled from Grouper groups which can, in turn, be pulled from AD or specific other locations or even managed manually. |
SAML1
urn:mace:dir:attribute-def:eduPersonEntitlement
SAML2
urn:oid:1.3.6.1.4.1.5923.1.1.1.7 |
| cn |
Cn stands for commonName. It is the person's full name. |
SAML1
urn:mace:dir:attribute-def:cn
SAML2
urn:oid:2.5.4.3 |
| uid |
This is the person’s netid at FAU.
There are cases where a person's netid is UPPERCASE in our system. If the SP is case-sensitive, a custom uid will need to be requested so we can force it to lowercase.
|
SAML1
urn:mace:dir:attribute-def:uid
SAML2
urn:oid:0.9.2342.19200300.100.1.1 |
| transientId |
This is a randomly generated, short-lived, opaque identifier that can later be mapped back to the user by a transient principal connector. |
SAML1
urn:mace:shibboleth:1.0:nameIdentifier
SAML2
urn:oasis:names:tc:SAML:2.0:nameid-format:transient |
The table below shows which eduPersonAffiliation attributes released by the FAU Shibboleth IdP correspond to which attribute types.
|
eduPersonAffiliation
|
Description
|
| student |
Student, EnrolledStudent |
| faculty |
Faculty |
| staff |
RegularStaff |
| employee |
Faculty, RegularStaff, TemporaryStaff |
| alumni |
Alumni |
| affiliate |
SponsoredAffiliate |
| member |
Student, EnrolledStudent, Faculty, RegularStaff, TemporaryStaff, Retiree, Alumni |
Requesting that FAU Withhold Specific Attributes
There are situations in which the SP may not need access to the user's name, email address, or other identity information. University units can request that any of the auto-release attributes listed above be withheld from a particular InCommon-member SP.
To request that an attribute be withheld from an SP, please submit a Single Sign On ticket.
Requesting FAU Release of Additional Attributes
Important Please submit your request as soon as you know you will need release of additional attributes beyond those pre-approved. This will leave the Single Sign On Integration team and the appropriate data steward enough time to review and implement your request.
In general, an attribute will not be released unless there is a business reason for its release. If you request release of an attribute, please be sure that there is a real need for its release.
To request approval of release of additional attributes, fill out and submit the online Single Sign On ticket.
Note that requests must be made by FAU staff representing a university department or unit.
The following table contains examples of commonly requested attributes and their encodings.
|
Attribute
|
Definition
|
Encoding
|
| employeeNumber |
This is the person's Znumber.
Courtesy accounts are not assigned a Znumber by default. If you need to test logins on courtesy accounts with Znumbers, you will need to request that one be added to that courtesy account.
|
SAML1
urn:mace:dir:attribute-def:employeeNumber
SAML2
urn:oid:2.16.840.1.113730.3.1.3 |
How Attribute Release Requests Are Handled
OIT reviews requests for release of additional attributes for technical feasibility and completeness. If the Single Sign On Integration team has questions about your attribute release request, they will contact you. Both the review process and the set-up for attribute release are iterative, and you may be asked for clarification or additional information at any point in the process.
If the attributes you are requesting fall under established review procedures, OIT will pass your request on to the appropriate data steward(s), manager(s) or review group.
Straightforward requests may be approved within a few business days and implemented in just a few more days after that.
Complex or difficult requests may require several weeks for approval and several additional weeks for setup. A request can take extra processing time if it entails new data feeds, custom programming, or if several units/institutions need to coordinate with each other. Please take this into account when creating your project plan.
This document has been adapted from the University of Michigan: https://documentation.its.umich.edu/node/262