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)
|givenName||user’s first name|
|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)