Authentication, Authorization and Audit in Veridium Manager
Context
Certain user actions can be considered to have a greater impact than others and need a higher degree of security. Security access control establishes effective controls and insight into "Who has access to What".
Groups, roles and permissions
One of the most coherent methods to implement authorization is Role Based Access Control – RBAC, an industry standard used to implement user permissions as access rights to application resources.
Some of the characteristics include:
Many-to-many relationship among individual users and privileges/permissions
User/role relations that can be defined independent of role/privilege relations
Accommodates traditional but robust group-based access control.
Based on configurable Groups and Roles, the system is able to provide a standard mechanism to manage user permissions, which are the abstraction of operations(i.e. run report, block identity, renew administrator certificate) and objects (ex device, identity, administrator) from system and are treated as resources from security perspective. This allows a separation between business level and system (application) level.
At system initialization, a default set of groups, roles, permissions will be registered and, later on, any administrator with the right privileges can create additional groups and roles and change the permissions assignment to roles or roles assignment to groups.
Managing groups, roles and permissions can be done in Veridium Manager by accessing Settings / Groups and Roles section. Note however that the list of permissions is static because it is the main building block of the authorization mechanism and must be in relationship with specific embedded system operations.
Mostly, the permissions existing in the system revolve around 4 types of operations:
read resource
write resource
remove resource
all the above
The permissions are enforced on both frontend side in Veridium Manager, and on backend side on the API operations level.
Default permissions
The following table describes the logical sections in Veridium Manager web application along with the list of potential permissions that will be checked for authorization authenticated user.
Logical Section in Veridium Manager | List of permission options |
---|---|
| 'Cross Application Administrators', 'Application Administrators', 'Members profiles administrators', 'Accounts administrators' |
| ‘Cross Application Administrators’ |
| 'Cross Application Administrators', 'Application Administrators', 'Technical Support', 'Members profiles administrators', 'Accounts administrators' |
| 'Cross Application Administrators', 'Application Administrators', 'Technical Support', 'Members profiles administrators', 'Accounts administrators' |
| 'Cross Application Administrators', 'Application Administrators' |
| 'Cross Application Administrators', 'Application Administrators', 'Members profiles administrators', 'Accounts administrators' |
| 'Cross Application Administrators', 'Application Administrators', 'System history', 'User can load reports', 'Technical Support' |
| 'Configuration settings administrators', 'Cross Application Administrators', 'System Administrators', 'Certificate Administrators', 'Mobile settings administrators', 'License administrators', 'Permissions administrators' |
| 'Cross Application Administrators', 'Application Administrators', 'Members profiles administrators', 'Accounts administrators' |
| 'Cross Application Administrators', 'Application Administrators', 'Members profiles administrators', 'Accounts administrators' |
Administrators management
During initial system setup, an administrator with the highest elevated permissions will be created. Afterwards, in order to manage existing administrators and provide access to more users, an existing administrator can go to Veridium Manager application, Settings / Administrators.
Authenticating in Veridium Manager can be done in 2 distinct ways, that will be described in the section below.
Certificate authentication
The default mechanism is by using client certificates upon user creation.
Creating new administrator with client certificate
Go to Settings / Administrators
Click on Add Administrator on the right-side
A) Provide the requested input information
Account external ID is recommended to follow the username.admin format to better separate users that are both administrators and regular VeridiumID identities.
Name of the user that will logged on each operation that affects the system resources and that will be displayed on the top right corner
Email address used to receive the certificate upon creating or when renewing takes place
How to receive the client certificate: either by downloading to the current station or by sending it directly to the email address set previously
Groups assigned to this user. This is used to compute the roles and permissions that will used to provide authorization on specific operations
B) Or use the “Search admin in active directory” field
4. The new user must install the received client certificate and trust it on OS level to prevent multiple pop-ups when accessing Veridium Manager application.
SSO header authentication
Another mechanism in place for authenticating and authorization in Veridium Manager is by using an external Single Sign-On Service that will forward specific custom headers to the admin application in order to identify, validate and authorize the user. This is done via internal operations by querying the repository connected via an LDAP connection and further apply logic to compute the user assigned permissions.
By default, this mechanism is disabled upon initialization, but can be enabled and configured by going to Veridium Manager / Settings / Admin Auth and by checking the following configuration:
Enable functionality flag must be set to enabled
The desired authentication setting should match the one set in SSO service
When accessing the Veridium Manager application, the system will lazy check the user identified via headers, automatically create an administrator entry if none exist, compute and apply the permissions based on the configure group mapping.
Note that for this scenario, the single point of administration for users becomes the user repository and not VeridiumID. That means in order to restrict access or change assigned permissions for a specific administrator, that specific entry should be directly managed in the user repository (i.e. changing the user groups or removing the user in Active Directory will have an immediate effect in identifying the user/computing permissions in Veridium Manager).
SAML authentication
This method uses the existing Veridium enrollment and authentication flows' configuration for Veridium Manager admin login.
This requires an existing user in a Directory Service connected to Veridium via LDAP. Administrators would enroll via the Self-Service Portal and be assigned the corresponding permissions based on AD group membership mapping that is already present in previous versions. User attribute sync will be done during authentication, so when entering the Veridium Manager at the end of a successful authentication, the user will be presented with the appropriate permissions inside it.
Authentication is done through Shibboleth which is configured to consider Veridium as both the Service Provider and the IdP for this scenario.
To enable SAML authentication within Veridium Manager, it is imperative to initiate the process by confirming the existence of a well-configured application entry for "veridium-manager." This verification can be performed by navigating to the "Applications" section in the management console.
If the application setup is not in place, you can proceed by visiting the "Admin Auth Settings" page. Within the SAML submenu, the initial step involves thorough verification of the URL placeholders to ensure they are correctly updated. Following this crucial verification step, you can proceed to configure Veridium as the Identity Provider (IdP) by selecting the appropriate action from the menu on the right side of the page.
With all the necessary configurations in place, you can seamlessly activate SAML authentication by simply toggling the switch located within the "General" submenu of the "Admin Auth Settings" page and make sure that you groups are allowed to use SAML.
More information regarding SAML authentication can be found here
Group mapping permission for authentication
This feature empowers Veridium groups to mandate the activation of SAML and/or Certificate authentication methods for user access to the application. To validate the group mapping, navigate to the 'Admin Auth Settings' and access the 'General' submenu. Here, you'll find an expanded Group Mapping section, featuring two new fields that define whether SAML and/or Certificate authentication is mandatory.
Audit
Action Logs
An action log entry is a record describing a specific sensitive operation made by an user with access to Veridium Manager application. This is mostly important to identify specific problems appeared when changes are made to the configuration and they affect the overall functionality of the system.
In general terms, details about each resource that is changed (via POST, PUT and DELETE HTTP methods) are stored in the repository along with the request parameters, IP address, date and time of the operation and, if possible, a status of the operation.
To see the latest entries, go to Veridium Manager / Audit / Action logs. Searching and sorting can be applied to the list of entries for a more powerful insight on system operations and administrators’ activity.
Administrators report
In order to download a CSV report on existing administrator, go to Audit / Reports and click on Administrators entry. Note that the resulted report will contain the users registered in the specific timeframe set on the top-right corner of the screen.
Identity details and Session details
There are new permissions that limit the access on veridium manager for Identity Details and Session details
View AD details
→ this permission is used for Identity details Directory service info
The action will be disabled if the user does not have View AD details permission
View location
→ this permission is used for Identity details and Session details for location data
Location column should not be visible if the user does not have the Location permission.
Also, In the audit → authentication session the Location column should not be visible.
In session details, the map is not displayed and location should not be present in any Identity or Session responses. Moreover, the raw data will not contain information about the location.
View UBA info
→ this permission is used for uba details. If the user does not have the permission, uba data should not be present in session details and in the Raw data.
View session details raw
→ this permission is used for session details, if the user does not have the permission, the Raw button from session details will be disabled.
View history details
→ this permission is used for history details in the session details. if the user does not have the permission, the history details will not be available.
As you can see, the user does not have permission for location, uba info and raw data. So, the map is not visible, the uba information is not present, and the raw data button is disabled.