About user attributes

Another feature that most services take advantage of when using Shibboleth is the ability to receive data about the user from the Identity Provider. This data, known as user attributes, can be anything that the Identity Provider knows about the user and that may be helpful to the Service Provider.

The ability to preserve a user’s privacy is a principal concern within all Shibboleth products. Both the Identity Provider and Service Provider allow the deployer to set attribute filter policies to address these concerns. Within the Identity provider this policy controls which attributes will be released to which Service Providers, whilst within the Service Provider this policy controls what information will be accepted from which Identity Providers.

Users can access to IdP using their Active Directory (u-gov/IRIS/esse3) credentials, so sharing credentials is strictly forbidden on pain of attributes revocation and userid locking, until to userid revocation.

UniCA’s IdP may release to SPs the following attributes (every SP gets them totally or just a restricted set, the minimum set being composed by mail, ePTID, ePSA)

ou Organizational Unit
sAMAccountName username
cn common name
givenName user’s first name
sn user’s surname
email user’s mail address
telephoneNumber user’s telephone number (if exists) see (1)
employeeNumber user’s matriculation number see (2)
preferredLanguage user’s preferred or mother language
eduPersonEntitlement special entitlement needed for some services see (3)
eduPersonPrincipalName scoped attribute from userID see (4)
eduPersonAffiliation user’s affiliation degree within his organization see (5)
eduPersonScopedAffiliation scoped attribute from ePA above see (4)
eduPersonTargetedID special attribute needed to manage sessions anonymously see (6)
schacHomeOrganization User’s organization scoped attribute
schacHomeOrganizationType User’s organization type
l (localityName) User’s place of residence see 7
st (stateOrProvinceName) User’s province of residence see 7
c (country) User’s country of residence



(1) phone number is mandatory for some SPs (mostly libray services as Nilde)

(2) not yet implemented

(3) depending on requested services: we implement library-dedicated entitlements, Moodle-dedicated entitlements and other ones.

(4) Scoped attributes are derived from non scoped ones by adding domain part.

(5) Affiliation attribute gets 4 degrees:

Member – Staff teaching staff, technical staff, librarians, clericals, emeriti (the latter getting member, staff, emeritus as values instead of member, staff).
Member – Student students
Affiliate Visiting Professors and so on
Alum (not yet implemented) alumni

(6) ePTID is astored attribute that allows anonymous sessions and it’s created directly by Shibboleth by the means of a random string generating algorithm
(value = IdPNameQualifier!SPNameQualifier!opaqueString): e.g. we could have the following value for ePTID: https://idp.unica.it/idp/shibboleth!https://sp2-test.garr.it/shibboleth!2YNU7YCQnZw1yh9cBSm0H2e8Yjs=

(7) l and st are mandatory for accessing Moodle; l and st attributes aren’t implemented on Oracle db for foreigners students.


Starting from IdP version 3 (October 2016), some user data are stored into IdP itself, instead of being calculated each time; in detail, they are:

localEntity –> IdP entityID
peerEntity  –> SP entityID
persistentId –> calculated as localEntity!peerEntity!opaquestring (e.g.: https://idp3.unica.it/idp/shibboleth!https://sp.unica.it/shibboleth! FXvsCKPDyhfP3+6K2O0XGNtRVaM=
principalName –>see table above
localId –> userid with which user logged into IdP
peerProvidedId  –> userid prvided from SP (if any, otherwise, NULL)
creationDate –> record creation Unix-date (msec)
deactivationDate –> uid deactivation Unix-date (msec; in this case, NULL)