BASE Core specification User authentication and management

User authentication and management

1. A user is authenticated by a unique login name and a password.
2. BASE can be configured to use internal or external authentication.
3. Support for external authentication is provided by standardized plugin modules that can be added to BASE independently of the core system.
4. If the technical solution allows it, internal authentication may also be implemented as a plugin.

1.2 Internal authentication only

1. BASE maintains a list of valid login/password combinations.
2. It should be possible to set an expiration date for a user account, after which the user will not be able to log on to BASE.

1.3 External authentication only

1. The primary role of the external authentication system is to accept or reject the login/password combination.
2. If the user is accepted, the authentication system should return a unique ID identifying the user. The ID must always be the same. The uniue ID may be the same as the login name, but doesn't have to.
3. BASE maintains a list of known unique IDs.
4. Optionally, BASE can be configured to cache the login/password combinations. This will make it possible to log on to BASE even if the external authentication system currently is unavailable. It should also be possible to limit the time the cached data is valid. The limit may be infinite.
5. [QUESTION] What about single-sign-on systems for external authentication? If a user is logged in, can this information be carried on to BASE? This would affect point 1.1 since a user can be authenticated by something else than a login/password combination, for example a cookie.
   Answer: This is difficult and depends on the client application. For example, a web based authentication system may use a cookie, which cannot be used by standalone applications. In other words, this cannot be a core feature.
6. Account expiration handling should be done by the external system, BASE should not enforce any time limit when using external authentication.

1. BASE maintains additional information about a user, ie. email address, phone number, etc.
2. The only required information about a user is the login name and the full name.
3. Preferrably, the email address should also be known.

2.1 Internal authentication only

1. User accounts can be manually created, updated or deleted by an administrator.
2. Users may update their own information, except the login name and the full name.
3. [CLIENT] A client application may allow self-registration. The privileges initially assigned to such an account should be configurable. The normal configuration would be to allow less than for a normal account. Note! The client application must of course be logged in with permission to create user accounts.

2.2 External authentication only

1. The external authentication system may, but is not required to, provide additional information, ie. email address, phone number, etc., about the user.
2. If the authentication system doesn't provide a full name, the full name is set to the same value as the login.
3. If a user not formely known to BASE is logging in and is accepted by the external system, a new account is created, including any available additional information. BASE can be configured to automatically add a new user to a specific group and/or role.
4. If the external system provides additional information, BASE can be configured to automatically update changes to the information. This is done at login time.
5. If the external system provides additional information, BASE can be configured to advice client application to disallow changes to that information. A client application is not required to follow that advice. Note! This is because we want to allow batch updates for synchronizing information between the external system and BASE (see the Batch processing section).
6. If a user already known to BASE is rejected by the authentication system, the account should be flagged as deleted.
7. It is still possible to create, update or delete existing accounts in BASE, but that information is not verified against the external system. Note! This is because we want to allow batch updates for synchronizing information between the external system and BASE (see the Batch processing section).
8. BASE can only query the external system for information. Information in the external system cannot be created, modified or deleted.
9. [WEB CLIENT] If a user not formerly known to BASE is accepted by the external system, one of the following may happen:
   • If the external system doesn't supply additional information, the user is presented with a form to add that information manually.
   • If the external system supply additional information and BASE is configured to allow modifications, the same form as above is shown, but with the supplied values already entered.
   • If BASE is configured not to allow modifications to the additional information the values supplied by the authentication system are stored and the login proceeds as normal.
   The web client should respect the advice to not allow modification to additional information.
10. [OTHER CLIENT] If a user not formerly known to BASE is accepted by the external system, the client may choose to reject the user access to BASE. If the client rejects the user it should let the user know about another client application, for example the web client, that can be used to enter BASE for the first time.

1. Batch processing is allowed for both authentication types.
2. User accounts can be added, updated or deleted in batch by uploading a formatted file containing the user information. How the file should be formatted is not specified by BASE, but by standardized plugin modules. Such modules can be added to BASE independently of the core system.
3. [NOTE] Another way to implement batch updates is to make a client application that uses the BASE API. Such a program may, for example, be scheduled for nightly runs to synchronize information between BASE and an external system.

1. Groups are used for organising users into units. Usually this maps into real-world groups, for example, "lab group 1", "lab group 2", etc. Groups are used in the access control mechanism to control access to individual, existing items (see the Access to items section).
2. Groups are added, updated and deleted by an administrator.
3. Users are assigned to groups by an administrator.
4. A user that is a member of a group may see information about other members.
5. [QUESTION] What about groups and external authentication systems? Should BASE allow such systems to also provide group information. In that case, can the external system also provide group membership information? How is this information synchronized?
   Answer: No
6. [QUESTION] What about groups within groups?
   Answer: Yes, this would be a nice feature. But only if it can be implemented in a relatively simple way.
7. [QUESTION] Batch updating of group information?
   Answer: Yes. This can the be used to synchronize external systems with BASE.

1. Roles are used for organising users by function and responsibility, for example, server administrators, head of the lab, regular user, reviewer, etc. Roles are used in the access control mechanism to control access to all items of a specific type and other operations not involving any particular items (see Role-based access to items section).
2. Roles are added, updated and deleted by an administrator.
3. Users are assigned to roles by an administrator.
4. [QUESTION] What about roles and external authentication systems? Should BASE allow such systems to also provide role information. In that case, can the external system also provide role membership information? How is this information synchronized?
   Answer: No
5. [QUESTION] What about roles in groups?
   Answer: Hmm... what does this really mean? Answer is no.
6. [QUESTION] What about "group roles"? Ie. users that have a special role within a group, for example, "leader of lab group 1". Such a user could for example have access to everything that is produced by members of the group. It should also be possible to have different roles in different groups.
   Answer: Not optimal. What if a user is a member of two groups, then some things are actually only for group 1 and some things only for group 2? Can the introduction of "projects" avoid this? By adding items and permissions to projects it might be possible to get generic permissions for all items within a project.
7. [QUESTION] Batch updating of role information?
   Answer: Yes...