-
Notifications
You must be signed in to change notification settings - Fork 7
Authentication Delegation
Currently Agate deals with its user registry only (except the Shiro's Ini Realm). The purpose of this specification is to describe how to apply the capability of Shiro to deal with multiple realms to implement Authentication Delegation: the user profile is still described in the Agate's database, but the authentication happens any another user registry (LDAP, SQL etc.)
Integrate Agate to an ID provider that already exists in the hosting infrastructure.
| # | Who | What | How | Result |
|---|---|---|---|---|
| 1 | administrator | declares a new alternate realm | using a form in the Administration section | A corresponding shiro realm is added to the Agate configuration |
| 2 | user | enters username and password | from the Agate's login form | User is authenticated by one of the realm |
| 3 | user | sign up based on a selected realm | by choosing the realm and filling the user profile form | The user exists in the database but its authentication is delegated to the realm of its choice |
Agate data model, REST resources and UI.
There are two kinds of realms that can be integrated:
- direct authentication: username/password realms such as LDAP/ActiveDirectory or JDBC realms.
- indirect authentication: open ID connect realms
In Agate there is already a separation between the user profile (User class) and the user name and password (UserCredentials class). The latter only applies to the AgateRealm. The User class also already defines what is the realm name against which the authentication should be performed; currently its value is always agate-user-realm.
Shiro configuration can be modified in the shiro.ini but, it's better to take control of the realms that are being declared and to expose a form in the web user interface to create them.
Then the domain will be extended with the configuration of the realms that can be added. The realms that are to be implemented:
- DefaultLdapRealm
- ActiveDirectoryRealm (not sure how much it is different from the DefaultLdapRealm)
- JdbcRealm
A realm definition must have at least the properties:
- name (unique identifier)
- a default title (that can be overridden by translations)
- a default description (that can be overridden by translations)
- a flag to indicate a whether this realm is active or not (if inactive and there are users, these will not be able to login)
- a list of groups to apply when a user signup with this realm
- a flag to indicate whether this realm is the default one (there can none in which case, the Agate user realm is the default)
- a flag to indicate whether this realm can be exposed to sign up
| REST | Description |
|---|---|
| GET /config/realms | Get all the realm definitions |
| GET /config/realm-summaries | Get the realm short definitions (name, default or localized title and description) |
| GET /config/realm/name | Get a single realm definition (no password included) |
| POST /config/realms | Create a new realm definition |
| PUT /config/realm/name | Update an existing realm definition |
| DELETE /config/realm/name | Delete a realm definition |
| GET /config/realm/name/usernames | Get the names of the users that are attached to this realm. From this list the UI can make links to the corresponding user profile pages |
| PUT /config/realm/name/active | Make realm active |
| DELETE /config/realm/name/active | Make realm inactive |
| PUT /config/realm/name/groups | Update the list of group names. This list can be empty. |
On realm definition delete action, Agate must verify that there are no users attached to this realm (otherwise they would not be able to login).
On sign up, user can select a realm to which he/she will be authenticated.
| REST | Description |
|---|---|
| GET /realms | Get the realm short definitions (name, default or localized title and description) |
It should be possible for the administrator (not the user owning the profile) to change the realm of a user.
Realm list should provide the following information:
- name (the unique identifier of the realm)
- type (LDAP, ActiveDirectory, SQL)
Realm page should expose:
- the realm detailed information (no password display)
- the list of the user names in this realm as links to their respective user profile page
From this page it should be possible to switch the activity (active/inactive) of a realm using a toggle button (confirmation popup, warn administrator when there are users in this realm).
Realm forms are straightforward. A good option would be to use schema-form to make the creation/update form and to store the JSON representation of a specific realm instance.
On realm creation, its activity flag is set to inactive. The groups are also to be added afterwards in the realm page.
On realm edition if there is a password field and this is empty, the password is not changed (correct behavior or password should be always provided?).
- configure a openldap server and test
- configure a SQL database and test
Use PAM4J library for delegating authentication to the underlying unix OS. This would allow to have RStudio (free version) and Agate sharing the same user registry (although an alternate solution would be to make PAM delegate authentication to LDAP...). See shiro-libpam4j.
Use Open ID Connect to sign up (retrieve user profile to pre-fill the user form) and to sign in (using the access/id tokens that would have been stored after sign up? (what happen when these are expiring?)).