Owner, Data Protection Officer (DPO), supervisory authority and data subject rights
Data controller of personal data is Cagliari University, legal representative is the the Rector.
Interested party may request access to their personal data, rectification, cancellation, limitation, opposition to processing and portability, if necessary, by sending a communication to:
- e-mail: privacy@unica.it
- pec :protocollo@pec.unica.it
- ordinary mail University of Cagliari – via Università, 40 – 09124 Cagliari.
Cagliari Universityi, in accordance with EU Regulation 2016/679 – General Data Protection Regulation (RGPD) – Article 37, has appointed the Head of Personal Data Protection (DPO):
- e-mail dpo@unica.it
- pec :protocollo@pec.unica.it
- ordinary mail University of Cagliari – via Università, 40 – 09124 Cagliari.
Interested party, if conditions are met, can lodge a complaint with Italian Data Protection Authority – as Control Authority – according to the established procedures.
More datails about Cagliari University Privacy management can be found on privacy page
Usage rules
you have two ways for getting access to bibliographical databases via FedAuthn:
- looking for the paper you want to read/download on UniCA Libraries webpage and clicking on UniCASearch; as soon as you have found your paper, click on “Availables services” for getting the list of sites from which you can download/access it (obviously, if you’re connected to UniCA wired or wifi network you’ll be recognized by IP and you can download/read it in full text just by clicking on “Read in PDF” link). If you aren’t connected to UniCA network, you must login to the site hosting your paper via Federated Authentication (usually shown as “Institutional login” or “Shibboleth login”). You must choose IDEM-GARR in Federations list (if any) or directly Cagliari University in Universities list and you’ll be redirected to our Shibboleth authn page where you must log in using your UniCA credentials. In case of successful login, you’ll be redirected to requested publication with download/read in full text permissions, even if your IP address isn’t in UniCA network range;
- if you already know in which bibliographical database your publication is stored, go on Servizi IDEM page in this site (is in italian but actually it contains just a links list) and from there click on link to requested bibliographical database; usually you’ll get its WAYF and then you can go on as stated in step before (looking for UniCA in Universities list and so on …).
You can find more informations and examples on IDEM Howto page on this site (in italian). In case of need you can contact us by writing to idem-help AT unica.it or idem-help-studenti AT unica.it (if you’re a student).
About user attributes
Another feature that most services take advantage of when using Shibboleth is the ability to receive data about the user from Identity Provider. This data, known as user attributes, can be anything that 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 Identity Provider and Service Provider allow the deployer to set attribute filter policies to address these concerns. Within 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 ePTID/peristentID, ePSA)
sAMAccountName | username | |
cn | common name | |
givenName | user’s first name | |
sn | user’s surname | |
user’s mail address | ||
telephoneNumber | user’s telephone number (if exists) | see (1) |
employeeNumber | user’s social security code | see (2) |
employeeID | user’s matriculation number | see (2) |
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/persistentID | special attribute needed to manage sessions anonymously | see (6) |
schacHomeOrganization | User’s organization scoped attribute | |
schacHomeOrganizationType | User’s organization type |
—
(1) phone number is mandatory for some SPs (mostly libray services as Nilde)
(2) requested by some SPs
(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/persistentID is a computed 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/persistentID: https://idp.unica.it/idp/shibboleth!https://sp261.unica.it/shibboleth!ZUNJPEPRBJLKQHYEYMALIP5AAPKIKN6W (in this example, persistentID is the one UniCA IdP has released to UniCA test SP when these notes author has logged in).
After authentication against AD, user must approve or decline attributes release from “U-Approve” window that shows every attribute released to SP; she/he can:
- approve only for curren session
- approve for every session unless SP requests do change
- approve everything
- deny everything (in this case, user won’t be able to get access to requested service)
Users can roll-back their attribute release preferences by selecting checkboxes in login page.