Account Management
Users of the DINA system are managed with Keycloak. Account management module is built on Kaycloak, with the goal of providing simple UI for collection managers to manage user accounts within their collection.
Currently (10/2017) the Account management module can handle
- Self-registration with email verification
- Enabling & disabling users by administrator
- Registration done by administrator
- User login, logout & password recovery
Other modules in development should do login/logout through the Keycloak Alpha instance at https://alpha-sso.dina-project.net The user accounts on this instance can be wiped nightly, so if stable accounts are needed, they have to be added to the deployment script (or other solutions discussed).
Keycloak master user Highest user level in Keycloak, can create and edit the DINA realm.
Superuser (= Sysadmin) Keycloak user that has full access to all features on the DINA realm on Keycloak. Not a DINA UI user (at least not yet).
Administrator Can approve new basic users.
Basic user Approved by admin. Can login to DINA collections module to add and edit specimens. Since there are not yet multiple collections, there's no need of managing rights per collection.
Unapproved user User that has not been approved by admin. Cannot login to DINA.
Collection/Organization administrator (TO BE DONE LATER) Can approve new users to use a single collection/organization on the DINA collections module.
Accounts module is set up as multiple Docker containers (=multi.-container application) which are set up using docker compose. Build and startup processes are managed by Makefiles. All of these are included in the Accounts repository.
The application consists of following parts
- UI: JavaScript/Ember UI
- JSON-API: Wrapper API for Keycloak API written in Java/Wildfly
- Keycloak: The Keycloak service including UI and API
- MySQL: database for Keycloak
When the application is started for the first time (using 'docker-compose up' or 'make up'), the JSON-API sets up following Keycloak configuration:
From env/.envaccounts file:
- Keycloak master UI and password
- Keycloak URL
From env/.envapi file:
- 'dina' realm
- Email server settings
- Password policy
- UI URL (e.g. for CORS settings) and JSON-API URL
- superadmin, admin and example basic users (username/email, password, first name, last name)
Note: Subsequent startups ignore settings for master username & password, Keycloak URL, realm and users. If these have to be changed, that has to be done through the Keyclocak admin console.
When a user self-registrates, the JSON-API accesses the Keycloak API authenticating itself with the master username and password.
When the user logs in to Accounts module, JSON-API sends the login info to Keycloak API and recives a token, which is personal for the user. Then the token is used by Ember to access the JSON-API, which passes it to Keycloak API for authorization.
Other modules are supposed to have their own login systems, which authenticate the user using accounts module JSON-API directly (Keycloak acting as a centralized authentication service), get a token in response, and then use that token to authorize the user to use the module API.
Other modules need persistent at least some information on Keycloak (at least client and URL for CORS), options to do this are:
- Set the alpha or beta Accounts module to persist data (how to manage changes vs. peristence?)
- Set the user information to Accounts module setup system
- Use their own or centralized standalone Keycloak instance, which persists data
Example of a diagram made with draw.io. Numbers referring to issues on Redmine.
- 8-n characters
- 1-n special character(s)
- Can be same as previous password