Users and projects
Authentication and authorization are separated in ASM and configured independently, and the security model uses two levels of management:
system-level authentication using an authentication module
application-based authorization for project access based on roles defined in the authentication module
Authentication
ASM authentication is the process for determining who can log in to the system. See the Manage users in Keycloak topic for more information on how to create users in the authentication module.
Authorization
ASM authorization is the process of determining what a logged-in user can do in the system. ASM will accept authenticated users who have been assigned an ASM role. Then, at the application level, we define authorization rules for users authenticated at the system level. See the Users section below for more information about user management in ASM.
By default, the ASM role set consists of three different roles:
- asm-admins - this role is required in order to log in into the ASM UI and access the Administration view. This allows the project administrator to create and manage projects and their members. The role can be used in combination with the asm-users role, in which case the project administrator can also be assigned to work in a project. Without the added asm-users role, however, the project administrator will not have access to all ASM functionality and will be limited to project administration only.
- asm-users - this role is required in order for the user to log in into the ASM UI and access a project within ASM. After a user with this role has been assigned to a project, the user will be able to log in and access the Services Manager and the project. Application-based authentication is used to determine the user's level of permission (read-only or all). All gives the user unrestricted access to all data and functions in the Services Manager, though the user will not be able to manage the project without also having the asm-admins role.
- domain-auditor - this role is required for users who should have access to historical data, for example for auditing. Consequently, a user need this role to have access to the Roll back functionality of ASM.
For those with an asm-users role, access to projects and permission to edit data depends on the settings applied at the application security management level. When a user is assigned to a project, the user is given either Read-only or All permission within the project. The project administrator can modify permissions at any point. See the Project setup section below for more information about project administration.
A user can be assigned all three roles, which is recommended for the administrator to be able to work with projects as well as the administration view.
Users
The Users view shows a list of users by name, login name and assigned project. From this view, administrators can remove users, assign them to one or more projects, and grant them permissions.
Add users
Before a user can sign in to ASM, a user record must be created and mapped to a role in the authentication module. See the Managing users in Keycloak topic for details.
The new user can then log in to the system using the username and password provided to them by the system administrator.
A user has to log in at least once before they can be assigned to a project.
Users view
The user record in ASM is created automatically when the user signs in. The administrator is then able to assign this user to the desired project(s) with the needed permissions.
Assign users to projects
Selecting a user in the list of users opens the editor and permits the administrator to change the user's project assignment and permissions. Clicking Apply closes the editor and applies the changes to the user selected.
Once in the list, the user can log in and see the assigned projects. In case a user has administrative permission but no user permission, only the Administration view will become available. Clicking Apply closes the editor and adds the name and assigned project information in the list in the Users window.
Selecting the check box to the left of the user name activates the Remove button and allows an administrator to remove the user from a project.
If a user is removed from a project during an active session, the session will be interrupted and the user will not be able to complete the intended actions.
User permissions in a project
Once access to the Axiomatics Services Manager has been gained, the user will either have unrestricted access to all data within the project or be limited to read-only access.
The level of permission is assigned by the project administrator when the user is added as a member to the project. Unrestricted access is referred to as All and limited access as Read-only. A user can be assigned to a project in the Project setup view as well.
Changes in project assignment, name, or level of permission
When a user is unassigned from a project while working in the project, the user will see the following message on the very next action:
Clicking OK will automatically log out the user. On logging back in, the message will appear saying that the user has not been assigned to a project.
When the project name is changed, a project member working in the project will be unaware of the change. However, a change in the project name does not affect membership in the project.
When the level of permission assigned to a member of a project changes from All to Read-only while the user is working in the project, the user can continue to work with All privileges. However, after logging out and logging in again, the user will find that the read-only permission has taken effect and the user will be unable to modify the project as before.
Delete a user in ASM
The process of deleting a user must be carried out both in ASM and Keycloak.
- Delete the user in Keycloak. See the Manage users in Keycloak topic for details.
- Remove the user assignment from the project(s) in ASM. Not mandatory, but strongly recommended.
- Remove the user from the Users list in ASM. Not mandatory, but strongly recommended.
If steps 2 and 3 are not carried out, the user will remain "Active" in the internal ASM database, which means that they will be visible in the Users and Project setup views. If a user is logged in when the user record is deleted in Keycloak, the user is immediately barred from executing any action in ASM.
Projects
A project administrator can create multiple projects and assign members to these projects. This type of administration tasks can be performed from the Administration section of the Axiomatics Services Manager.
All users must be assigned to a project before they can work on it. Accessing the Axiomatics Services Manager before such an assignment has been made, the user is greeted with a message stating that they have not yet been assigned to a project.
Administrators can access the project administration features using the Switch to administration view option in the User menu.
Project setup
The Project setup window opens by default after clicking Administration. It shows project names and their associated project members. Here administrators can set up and manage projects.
The Project setup view
Create projects
Clicking Create opens an editor where the new project can be defined, with a project name, and project members (that is, users) assigned. Members can be assigned one of the following permission levels:
- All for unrestricted access to all project data
- Read-only for read-only access to the data but no permission to modify, add to, or remove it.
See Users for more information about creating users.
Any user with both asm-admins and asm-users roles, if assigned to a project, will have full access rights to that project regardless of the permissions explicitly assigned in the Project Information editor. This means it is currently not possible to configure read-only access rights for users with asm-admins role.
Clicking Apply closes the editor and creates the new project, which then appears in the Project setup list.
Manage projects
Clicking a row in the list of projects reopens the editor to let the administrator change the project name, add and remove members, and change their roles and permissions. Clicking Apply closes the editor and applies the changes to the project.
Remove projects
- Select the check box to the left of the project name. This action activates the Remove button.
- Click the Remove button to remove the selected project.
All assigned users must be removed (unassigned) from the project before it is possible to remove it. Only one project at a time can be removed. There is no undo for this action.
Removing a project will permanently delete all entities belonging to that project, such as domains, policies, attribute connectors, and historical objects.