Managing user access to various resources and applications in an organization comes with a significant administrative and technological cost. If user permissions are under-provisioned, productivity may suffer. On the other hand, overly provisioned user permissions can pose potential security risks.
To ensure a balance between productivity and security, most organizations require an Role Based Access Control(RBAC) system to handle user permissions to resources.
RBAC system is needed to assign users access to various resources in the organization by grouping the various permissions into roles. Roles are directly assigned to the user instead of individual permissions. Determining what roles should be created in the system for optimal assignment of permissions to the user across various resources and applications requires time commitment and efforts from RBAC and system experts.
The information required to determine if a role should be created in an RBAC system and what permissions are required to be included in it is derived from the response to two questions -
1. What are the commonly grouped permissions and entitlements in the current system?
2. What are the user attributes which drive the permissions currently assigned to them?
Role mining is the process of identifying the roles to be introduced in a RBAC system by analyzing the existing user-permission assignments across various resources in the organization and identifying what business roles may be derived by clustering the existing entitlements of the user and correlating them with user attributes.
Data Collection The first step in role mining is to capture the existing users and their entitlements. The goal of this exercise is to gather information on various user attributes that may have led to their permissions on different resources, such as their department, designation, and location.
Identifying potential business roles To identify potential roles, cluster users based on their attributes and current permission assignments. This can involve techniques such as clustering or association rule mining. The main objective here is to identify roles as groups of permissions and presenting them as potential roles to which the permissions may be mapped in an RBAC system. The users will then be assigned these roles in the RBAC system.
Post processing and Optimization An analysis of the potential roles extracted from the existing data will help the RBAC and system administrators identify the “correctness” of the roles generated. Additional heuristics may be applied to vary the number of roles generated by the system, which in turn affects the number of user-role mappings and user-permission mappings to be done during RBAC implementation.
Increased Efficiency Role mining can streamline the process of provisioning and deprovisioning user access by identifying the most common roles and responsibilities within an organization, making it easier to manage access control.
Principle of Least Access Role mining helps identify common business roles based on the existing permissions, which is mapped with the user’s position in the organization. Administrators of applications and RBAC system may review the permissions currently assigned to the user and map it to the discovered roles to determine over-provisioned roles.
Peer Review and Compliance Role mining allows for identifying the differences in the permissions assigned to the peers in an organization. Role mining can help organizations to demonstrate compliance with industry and regulatory standards, by ensuring that users only have access to the data they need to perform their job functions.
Segregation of Duties and Identifying toxic access Role Mining allows for defining rules based on user attributes and COSO types for permissions, which allows for definition of roles that avoid toxic access (e.g., a role that includes permissions for both checker and maker). Checking the mined roles in an organization helps identify users with toxic access.
Role Mining is implemented in Cymmetri as explained below:
Cymmetri expects the following set of inputs for data collection:
User details (UserId, Department, Location, Designation etc.)
Permission details (ApplicationId, Permission/Entitlement in the application, PermissionId)
User-Permission Mapping (UserId, PermissionId)
Cymmetri iterates through the list of user-permission mappings and performs various heuristics to determine a list of business roles, which identify roles as a group of 1 or more permissions, which is assigned to multiple users.
Cymmetri optimizes over the above-produced business roles to remove roles which have very few users assigned to the permissions assigned to the role. Further optimization is performed by identifying the correlation between user attributes and the role generated.
Entitlements refer to the permissions or rights granted to a user or group to access specific resources or perform certain actions within a system. These entitlements are typically defined based on the user's role, job function, or other relevant attributes associated with the user.
Authorization: Entitlements are closely tied to authorization, which is the process of determining whether a user is allowed to perform a specific action. Access Control: Entitlements are a fundamental component of access control, ensuring that only authorized individuals can access sensitive information or systems. Role-Based Access Control (RBAC): Entitlements are often assigned based on a user's role within an organization, making it easier to manage access permissions for large groups of users. Least Privilege Principle: The principle of least privilege states that users should be granted only the minimum entitlements necessary to perform their job duties, reducing the risk of unauthorized access. Entitlement Management: This refers to the process of managing and controlling entitlements throughout their lifecycle, including granting, revoking, and auditing.
A sales representative might have entitlement to access customer data and place orders.
A system administrator might have entitlement to modify system settings and troubleshoot issues.
A guest user might have entitlement to view public content on a website but not to make purchases.
By effectively managing entitlements, organizations can improve security, compliance, and efficiency.
In Cymmetri, the ability to provide an object (such as a user or group) access to a resource (application, group, role, permission, privileged system) is called provisioning of entitlements.
Broadly classified, the following are the entitlements possible for access based provisioning:
Business Role
Group
Application
Application Role
Privileged System
Cymmetri Role
In Cymmetri the above mentioned entitlements are provisioned to either:
Cymmetri Users
Cymmetri Groups
Cymmetri provides a framework for identifying entitlements within various target applications. The most common of these are accounts or user objects in the target system. The other elements that can be detected are group or group objects and roles.
For account discovery, various Cymmetri connectors provide ready made detection capability. The most common among them are-
Azure AD
REST API Connector
AMAYA Connector
SAP HANA Connector
SCIM Connectors
Apart from the standard reconciliation approach, Cymmetri also provides a 360 degree reconciliation to discover identities / accounts which do not co-relate with Cymmetri records or vice-versa.
After discovery of identities, Cymmetri can be configured to perform the corresponding action such as-
Assign or Link the Cymmetri user and Target system account
Unassign or Unlink the Cymmetri and Target system account
The possible scenarios for identity state can be referred on the conditions which are in turn based on the supported operations.
Cymmetri has ability to manage Business and IT roles through its interface.
The Business Roles can be defined as part of the Cymmetri RBAC Master and SoD policies. Similarly, the Application roles or IT roles can be defined at each application as its own master. Generally, the application roles are maintained at application side and Cymmetri keeps a reference for the target role entitlement.
Cymmetri allows direct syncing with target system to fetch the role master. However, in case the target system does not support APIs for role management, the roles can be added or modified based on bulk import or manually adding or updating in Cymmetri.
Every role definition is saved in the Cymmetri audit log. Changes to the definition are audited and previous role configuration can be restored as needed.
Admin guide to Version Management of Role Definitions with Role Revert Capabilities
This document provides detailed instructions on how administrators can manage role definitions and maintain a version history in Cymmetri Identity Governance and Administration (IGA). The solution supports full versioning of roles and allows roles to be reverted to previous states while maintaining control over target system configurations. When a role is rolled back, the system also ensures that the rollback applies to all target systems where the role has been assigned or deployed.
Role Versioning: All modifications to roles are tracked and stored as separate versions.
Target System Rollback: When a role is rolled back, the target systems where the role has been assigned will also revert to the previous configuration.
Audit Trail: Administrators can view the complete history of changes made to any role.
Rollback Functionality: Ability to revert a role and its assignments to any previous version.
Controlled Access: Only authorized administrators can manage role versions and apply rollbacks.
Administrator-level access to Cymmetri IGA.
Ensure roles and permissions are configured to allow role version management and rollback capabilities.
Target systems should be integrated with Cymmetri IGA and configured for automatic updates when roles are reverted.
Login to Cymmetri IGA using your administrator credentials.
Navigate to Identity Governance.
Click on Role Management.
In the Role Management module, search for the specific role whose version history you want to view.
Select the role from the list.
On the role details page, click on the History/Versioning tab.
A list of all previous versions will be displayed, along with the following information:
Version Number
Date of Modification
Modified by (Administrator’s name)
Description of changes made
To compare two versions of a role:
In the History/Versioning tab, select the two versions you want to compare by checking the boxes next to them.
Click the Compare button.
A side-by-side comparison will be displayed showing the differences in permissions, attributes, and other relevant configurations.
In the Role Management module, select the role you want to roll back.
Go to the History/Versioning tab and locate the version to which you want to revert.
Click the Rollback button next to the desired version.
A confirmation dialog will appear, detailing the rollback process. Confirm your action by clicking Yes.
Role Revert on Target Systems: When rolling back a role, Cymmetri IGA will automatically push the changes to the target systems where this role has been deployed, ensuring the role reversion is applied across all systems where the role is in use.
The role will now be reverted to the selected version, and a new version will be created documenting the rollback action. The target systems will reflect the same version.
The system will generate a notification once the rollback is complete and applied to all integrated target systems.
To view a complete audit log of all role modifications and reverts:
Navigate to the Audit Reports section from the dashboard.
Select Role Change History or Target System Rollback Logs.
Filter the report based on role name, date, or administrator.
The report can be exported in PDF or Excel format for compliance purposes.
Only authorized administrators can manage and roll back role versions and apply the changes to target systems. To assign or revoke this permission:
Navigate to Configurations → Admins.
Select the Domain Admin role or click on Add button to search for a user to assign the Domain Admin role.
When a role version is rolled back and applied to target systems, Cymmetri IGA will trigger notifications to relevant stakeholders and system owners:
Navigate to Notification Settings under Configurations.
Enable the Role Version Rollback and Target System Revert Notification and configure the recipient list.
Customize the email template if required.
Real-Time Monitoring: Use the Monitoring Dashboard to track the status of role rollbacks and ensure that all target systems have received the updated configurations.
Regular Audits: Conduct regular audits of role definitions and their versions to ensure compliance and avoid unauthorized changes.
Testing Before Rollback: Before rolling back a critical role in a production environment, it’s advisable to test the rollback in a staging environment.
Confirm Target System Updates: After a rollback, verify that all target systems reflect the correct version of the role.
Unable to Roll Back: Ensure that you have the required permissions to perform a rollback and that the selected version is valid.
Target Systems Not Updated: If the role reversion has not propagated to the target systems, check the integration settings for those systems and confirm that the connection with Cymmetri IGA is active.
Audit Log Not Displaying Changes: If the audit log doesn’t display recent changes, verify that role versioning is enabled in system settings.
Cymmetri IGA's version management feature allows for seamless role reversion, ensuring that not only are previous versions of roles maintained, but any rollbacks are also applied across all target systems. By following this admin manual, administrators can effectively manage role versions and ensure compliance, security, and consistency across their identity governance landscape.