Authentication on the production system is deferred to the DARIAH Identity Provider.
The server performs shibboleth authentication, with credentials coming from the DARIAH Identity provider .
The login/logout actions take place at the server after visiting
Logout in two stages
/logout performs a logout from this app, but not from the DARIAH Identity Provider. To do the latter, one has to go to
/slogout and close the browser.
When users log in, the details from DARIAH identity provider will be stored in the user table.
User details are stored upon every login. When the DARIAH identity provider has changed attributes of a user, these new attributes will be picked up and stored, replacing older values. So the user table updates itself automatically. These updates reach our user table only for those users that actually log in, at the moment that they do log in.
The system may contain records for users that have never logged in. This happens when future users of the system are assigned to field values by their email address. Whenever such a user logs in, the attributes obtained during the authentication will flow into the incomplete user record if it exists, otherwise a new user record will be made. The new user will find him/herself in all places where his/her email address had been entered.
The systems maintains user-associated attributes from two sources:
Attributes from the DARIAH identity provider
|user field in this app||attribute provided by DARIAH||comments|
| || ||a string by which the user is identified in the DARIAH context|
|the email address according to the DARIAH identity provider|
| || |
| || |
| || ||common name, probably just |
| || ||organization to which the user is affiliated|
| || ||a semicolon separated string of groups within the DARIAH organization to which the user belongs, e.g. |
| || ||the type of relation the user has with DARIAH, such as |
We do not use
unscoped-affiliation, which is the
affiliation without the
Attributes generated by this app
| ||whether the user is allowed to login. Default |
| ||the basis on which the identity of the user has been established. See the values below.|
| ||the permission level of this user. See the values below.|
| ||when the user has logged in most recently|
| ||whether the last login attempt was successful|
Like almost all records in the system, the provenance fields are added as well.
Display of user attributes
When a user is presented on the interface, we choose between the following representations, in order of highest preference first.
name, coming from the DARIAH attribute
(org) if available.
When giving users permissions, the groups they are in play an important role. The attributes
group contain the necessary information.
|absent||the user has never been authenticated. Used for people that occur in the system, but have not yet logged in.|
| ||the user has been logged in by the DARIAH identity provider|
| ||the user has been imported from the FileMaker legacy data. This kind of user cannot log in.|
| ||the user has logged in on the development system. This kind of user should not be present in the production system!|
See the permission model .
| ||successful login attempt|
| ||unsuccessful login attempt|