Skip to content


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 .

/login /logout /slogout

The login/logout actions take place at the server after visiting /login, /logout or /slogout.

Logout in two stages

Currently, /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.

User records

When users log in, the details from DARIAH identity provider will be stored in the user table.

Auto update

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.

Future users

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
eppn eppn a string by which the user is identified in the DARIAH context
email mail the email address according to the DARIAH identity provider
firstName givenName
lastName sn
name cn common name, probably just firstName lastName
org o organization to which the user is affiliated
membership isMemberOf a semicolon separated string of groups within the DARIAH organization to which the user belongs, e.g. lr_DARIAH-User, humanities-at-scale-contributors, dariah-eu-contributors
rel affiliation the type of relation the user has with DARIAH, such as
Ignored attributes

We do not use unscoped-affiliation, which is the affiliation without the part.

Attributes generated by this app
user field comments
mayLogin whether the user is allowed to login. Default true, but the back office can use this field to prevent a user from logging in. When a user leaves, we advise to set mayLogin to true. It is not an option to delete a user, because (s)he can be the creator/modifier of records that are still in the system.
authority the basis on which the identity of the user has been established. See the values below.
group the permission level of this user. See the values below.
dateLastLogin when the user has logged in most recently
statusLastLogin 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 cn (common name)
  • firstName lastName
  • email
  • eppn-autority

We append (org) if available.


When giving users permissions, the groups they are in play an important role. The attributes authority and group contain the necessary information.

authority values
authority comments
absent the user has never been authenticated. Used for people that occur in the system, but have not yet logged in.
DARIAH the user has been logged in by the DARIAH identity provider
legacy the user has been imported from the FileMaker legacy data. This kind of user cannot log in.
local the user has logged in on the development system. This kind of user should not be present in the production system!
group values

See the permission model .

statusLastLogin values
statusLastLogin comments
Approved successful login attempt
Rejected unsuccessful login attempt