Basics
The "currency" of the Shibboleth software is attributes. An attribute is a named set of values about an authenticated user. The values are typically strings, but can be more complex XML-based data. When a user logs into your service provider software, Shibboleth obtains a set of attributes for that user and maps them (based on rules you create) into environment variables and/or HTTP headers for your application to consume. In most cases, the LSU Shibboleth administrators or even users themselves create rules that specify which attributes are passed to which service provider. Even public attributes that uniquely identify users such as the LSU Internet Username are suppressed unless the service requires this information.
Well-behaved applications using Shibboleth recognize first and foremost that the attributes they receive about users belong to the user, and the user may choose to suppress them. This is a reality, but applications are free to deny access should they not receive what they need. Therefore, you should design your applications to look for attributes as needed, but never require them in order to receive a meaningful response, even if that response is just "sorry, I need your username to continue". Very little can be assumed, but the result is a more robust application.
As described in the Shibboleth documentation, when multiple values are supplied for an attribute, they are generally separated by a semicolon in the variable or header.
Attribute List
The following is a fairly complete list of the information currently available through Shibboleth from the LSU identity provider service. Some attributes may also be available from other InCommon identity providers, subject to appropriate privacy policies and application need. This is by no means exhaustive of the information that may eventually be available through Shibboleth, nor does it imply that something you need can't be made available if it's present in a reasonable form in the university's directory service or administrative systems. The answer may be no, but you can ask.
The columns for "Default Header" should not be read as constraining you. Any header name can be assigned as needed. Check and modify your configuration as needed if you have questions or need to make adjustments.
| Full Name | Default Header (2.x) | Datatype | Multi? |
|---|---|---|---|
|
(SAML1) urn:mace:dir:attribute-def:eduPersonScopedAffiliation
(SAML2) urn:oid:1.3.6.1.4.1.5923.1.1.1.9 |
HTTP_AFFILIATION | Domain-Qualified String Enumeration | Y |
|
(SAML1) urn:mace:dir:attribute-def:eduPersonPrincipalName
(SAML2) urn:oid:1.3.6.1.4.1.5923.1.1.1.6 |
REMOTE_USER / HTTP_EPPN | Domain-Qualified String | |
|
(SAML1) urn:mace:dir:attribute-def:eduPersonEntitlement
(SAML2) urn:oid:1.3.6.1.4.1.5923.1.1.1.7 |
HTTP_ENTITLEMENT | URI | Y |
| urn:oid:1.3.6.1.4.1.5923.1.1.1.10 (eduPersonTargetedID) | HTTP_PERSISTENT_ID | String | |
|
(SAML1) urn:mace:dir:attribute-def:displayName
(SAML2) urn:oid:2.16.840.1.113730.3.1.241 |
HTTP_DISPLAYNAME | String | |
|
(SAML1) urn:mace:dir:attribute-def:sn
(SAML2) urn:oid:2.5.4.4 |
HTTP_SN | String | Y |
|
(SAML1) urn:mace:dir:attribute-def:givenName
(SAML2) urn:oid:2.5.4.42 |
HTTP_GIVENNAME | String | Y |
|
(SAML1) urn:mace:dir:attribute-def:mail
(SAML2) urn:oid:0.9.2342.19200300.100.1.3 |
HTTP_EMAIL | String | Y |
- eduPersonScopedAffiliation
- Formal Definition
- https://wiki.refeds.org/display/STAN/eduPerson+2021-11#eduPerson202111-eduPersonScopedAffiliation
- Description
-
Multiple values of the form value @ domain , where domain is a DNS subdomain representing the organization or sub-organization of the affiliation (e.g., "lsu.edu") and value is one of:
- member
- student
- employee
- faculty
- staff
- alum
- affiliate
Note that these values are NOT case-sensitive, and capital or mixed-case values are permitted (e.g., MEMBER, Member, MeMbEr).
- LSU-Specific Information
-
Only the values student , faculty , staff , retiree , and affiliate are currently supported, and the only domain value currently applied is "lsu.edu" and represents the university as a whole.
student is assigned to any user with an "active" program of study. This is based on expected or past enrollment in classes.
faculty is assigned to any user possessing employee and whose appointment(s) include one with a faculty title.
staff is assigned to any user possessing employee but not faculty.
retiree is assigned to any user having officially retired from the university.
affiliate is assigned to any other user.
- Usage Notes
-
Affiliation is a good rough approximation of the relationship of the user to the university or organization specified in the domain. A user can possess many affiliations, though some values are mutually exclusive. This attribute is typically available to any Shibboleth service provider, and is a good way to filter or block users of a given general type. In particular, member is an indication that the user is somebody with relatively official standing with the university at the present time, and does not apply to guests, other temporary accounts, terminated employees, unpaid/unregistered students, and other exceptional cases. At this time, affiliation values are the best way to provision/deprovision access when employees or students leave the university, until such time as the accounts themselves are more promptly disabled.
- eduPersonPrincipalName
- Formal Definition
- https://wiki.refeds.org/display/STAN/eduPerson+2021-11#eduPerson202111-eduPersonPrincipalName
- Description
-
A single value of the form user@domain, where domain is a DNS subdomain representing the security domain of the user (e.g., "lsu.edu") and user is generally a username, NetID, UserID, etc. of the sort typically assigned for authentication to network services within the security domain.
- LSU-Specific Information
-
ITS assigns myLSU accounts as the primary means of campus-wide authentication. The official campus e-mail address is then constructed by appending "@lsu.edu" to the username. The eduPersonPrincipalName of an account that corresponds to a myLSU account is the same as that e-mail address, and currently takes the form "lastname#@lsu.edu". Other kinds of accounts might be issued in the future and could look different, but the value of this attribute will always be unique at any given time for each active account.
At the present time, myLSU accounts (and by extension, EPPNs) are not generally reassigned, but ITS reserves the right to recycle older myLSU accounts in the future. Even today, the value often changes for a given physical user, however, because account renaming is generally permitted.
- Usage Notes
-
EPPN is typically considered the Shibboleth-equivalent of a username. It typically has most of the properties usually associated with usernames (such as uniqueness and a naming convention of some sort), with the added property of global uniqueness through the use of a suffix/qualifier. An application that tracks information based on it can therefore interact with users via any number of identity providers without fear of duplicates, although the possibility for recycling/reassignment does still exist within the domain of a given identity provider.
Note that in most cases, a user can freely change their local account name (in the case of a name change due to marriage, for example), and the corresponding EPPN will typically change as well. This can cause a loss of service until name changes propagate throughout every application storing the value. For a less dynamic identifier, see also the eduPersonTargetedID attribute.
- eduPersonEntitlement
- Formal Definition
- https://wiki.refeds.org/display/STAN/eduPerson+2021-11#eduPerson202111-eduPersonEntitlement
- Description
-
Muliple values, each a URI, representing a license, permission, right, etc. to access a resource or service in a particular fashion. Entitlements represent an assertion of authorization to something, precomputed and asserted by the identity provider. This attribute is typically used to assert privileges maintained centrally rather than within specific application databases.
- LSU-Specific Information
-
Currently, the only entitlement supported is urn:mace:dir:entitlement:common-lib-terms attribute. This value is used to indicate that the holder of the entitlement has access to library resources.
- Usage Notes
-
Entitlements should not in general be parsed or interpreted based on the structure or content of the values, but simply compared as strings. They represent a delegation of control by an application over who possesses the right to use a resource to the identity provider, potentially simplifying application logic in the process and centralizing control over the policy, blacklisting or whitelisting, etc.
- eduPersonTargetedID
- Formal Definition
- https://wiki.refeds.org/display/STAN/eduPerson+2021-11#eduPerson202111-eduPersonTargetedID
- Description
-
A single string value of no more than 256 characters that uniquely identifiers a user in an opaque, privacy-preserving fashion. In most cases, the value will be different for a given user across each service provider accessed, to prevent correlation of activity.
- LSU-Specific Information
-
LSU's identity provider supports this attribute.
- Usage Notes
-
This attribute offers a powerful alternative to the use of eduPersonPrincipalName as a user identifier within applications and databases. Its power lies in the fact that it offers a significant degree of privacy and control for users. It also tends to be more stable than EPPN because it doesn't change merely in response to superficial name changes. It still may change, but generally in a more controlled fashion. It also requires a policy of non-reassignment. That is, while a given user may be associated with more than one value over time, a single value once assigned will never be assigned to any other user.
When appropriate, the value can remain consistent across multiple service providers, if those systems have a demonstrated relationship and need to share information about the user's activities. Such sharing must be tightly controlled.
Note that the values are not guaranteed to be unique except for a given identity provider. The value should therefore be combined with the content of the HTTP_SHIB_IDENTITY_PROVIDER header to create a unique pair. An application might choose to store the two values separately as a pair, or combine them using a separator of some sort.
- displayName
- Formal Definition
- https://wiki.refeds.org/display/STAN/eduPerson+2021-11#eduPerson202111-displayName
- Description
-
A string value containing a user's legal name, suitable for display. Preferred over handling first and last name independently to better address international students.
- LSU-Specific Information
-
LSU's identity provider uses a format of "First Last" based on the data maintained for the university's directory service. If the person has a preferred name, it will be shown here. Otherwise, the full name will be shown.
- sn
- Formal Definition
- https://wiki.refeds.org/display/STAN/eduPerson+2021-11#eduPerson202111-sn
- Description
-
Multiple string values containing components of the users's "family" name or surname.
- LSU-Specific Information
-
LSU's identity provider does not separate hyphenated or multi-part surnames into multiple values. The attribute is currently single-valued. The value is derived from the data maintained for the university's public directory service, which is in turn derived from systems of official record.
- givenName
- Formal Definition
- https://wiki.refeds.org/display/STAN/eduPerson+2021-11#eduPerson202111-givenName
- Description
-
Multiple string values containing the part of the user's name that is not their surname or middle name.
- LSU-Specific Information
-
LSU's identity provider does not separate hyphenated or multi-part given names into multiple values. The attribute is currently single-valued. The value is derived from the data maintained for the university's public directory service, which is in turn derived from systems of official record.
- Formal Definition
- https://wiki.refeds.org/display/STAN/eduPerson+2021-11#eduPerson202111-mail
- Description
-
Multiple string values containing SMTP-compatible email addresses believed to belong to the user.
- LSU-Specific Information
-
Most campus users have a university-assigned email address at which official university e-mail is sent. This address has the form myLsuAccount@lsu.edu and is the same as their eduPersonPrincipalName .
