-
Notifications
You must be signed in to change notification settings - Fork 18
Shibboleth accounts email, netid and idp
For more details about federated logins (Shibboleth) visit the linked page, what's important in this section is that Shibboleth adds user's attributes into the http request headers.
EPerson (class that represents users in clarin-dspace) requires an email and emails must be unique (no two epersons can have the same email).
With default settings, federated users are autoregistered (automatically created). The process of search/creation is described below.
Firstly, finding an eperson is done using "netid" (that's also a database column name). The value is either eppn[idp] or eptid[idp] (eptid is equal to persistent-id in this context) where eppn and eptid are attributes sent by IdPs and idp is the entityid of an IdP. If no user is found using "netid", search is repeated with the "mail" attribute (database column is called "email") see note1 below). If successful, it might "assign" a shibboleth identity to a previously created local account.
Attributes in the user profile (e.g., first name, last name or even mail in most cases) are updated from the attributes sent by IdPs.
The search by email can find an eperson that already has a "netid" but the netid is different to the current one. Usually this means that user has an account with multiple IdPs and is using a different organization than the last time. But there are also IdPs that let you create an account without even verifying your email (we block these, see https://lindat.mff.cuni.cz/en/how-do-i-sign-up). An error is shown to the user saying to either use the same IdP as the last time and/or to contact the administrators of clarin-dspace. Administrators can reset the netid with a button click in the user profile (Access Control -> People...) if there are reasons for that.
If no eperson has been found (but we have at least one of eppn/eptid/mail attributes), a new eperson is created. If the newly created eperson has no email (mail attribute), clarin-dspace displays a form where the user has to manually fill it. A verification email with a link is sent to that email and the user cannot login before validating the email.
If neither of the attributes is present, clarin-dspace displays an error message describing that the problem is not in clarin-dspace but in the user's IdP. The user is asked to write an email to his IdP.
In short because we don't want to manage identities/accounts. The same email most of the times indeed means the same user, so you don't want to create a new account - that would not carry over the user history (e.g. completed submissions) - but you also don't want to pair "users" from two different idps automatically. The assumptions are a) that most of the users use only one idp (or at most two - university & homeless - so a message along the lines "use your another idp" should not be that confusing) and b) idp's don't change their entity ids regularly (because it's a hassle for everyone involved).
Note that you still can get multiple accounts if a user has multiple idps and a different email with each one.