Introduction
Access Management is an extensible authorization system controlling access to APIs and resources for users and solutions. It features a rich way of access management with attribute-based access control (ABAC) and role-based access control (RBAC).
This extensible authorization system offers customization, flexibility, and integration with other systems and solutions for consistent user experiences. Moreover, it provides centralized control over access, ensuring only authorized users and solutions have access to resources, and mechanisms for protecting and sharing resources.
What is an Extensible Access Management
Access Management allows for the addition of custom roles and capabilities as well as the ability to map those roles and capabilities to custom REST endpoints. This extensibility enables you to create RBAC configurations defined and managed within solution packages. Access Management leverages the custom roles and RBAC configuration to meet the specific needs of different solution packages.
Benefits of Access Management
Access Management can manage access to resources and offer the following advantages over other authorization systems:
Customization: An extensible access management system allows for the customization of roles and capabilities to meet the specific needs of different solution packages and ensure that users can access only the resources they need.
Scalability: As organizations grow and their security needs become more complex, an extensible access management system can scale to meet those needs without requiring a complete overhaul.
Flexibility: An extensible access management system allows adding or removing roles and capabilities as needed, making it easier to adapt to changing security requirements.
Integration: An extensible access management system can integrate with other systems and solutions to ensure consistent user experiences across different platforms and applications.
Control: An extensible access management system gives administrators centralized control over access to resources, ensuring access is granted only to authorized users.
Solutions and Authorization
There is a relationship between user and solution permissions within the Cisco Observability Platform. The Cisco Observability Platform allows solutions to act like users and perform specific actions on behalf of users, but with restrictions to prevent privilege escalation.
In this system, users are granted roles and permissions based on their job functions or responsibilities, and solutions are granted roles and permissions that they explicitly request; however, whenever an API call is made to the platform by the solution, only the intersection of the solution's permissions and the user's permissions are allowed. Thus, the solution cannot perform actions beyond what the user is allowed to do, and the user cannot gain permissions that they do not already have because their Tenant administrator has given them access to a solution.
The system enforces the intersection of permissions between the user and the solution to prevent privilege escalation. In other words, a request made by the solution on behalf of a user must have the required permission granted to both the user and the solution.
Overall, the system aims to provide a secure and controlled environment where users and solutions can perform their respective functions without compromising the security and integrity of the system.
Access Management Use Cases
The best way to illustrate how Access Management manages and enforces permissions between users and solutions is to look at an example.
We will look at the solution "Investigate" that bundles two roles mapping permissions to custom REST endpoints, and then look at how a user named "Fred" and the application would be able to access that REST endpoint.
Suppose the following artifacts are bundled in the "Investigate" solution, and "Fred" has been assigned to the IT_Investigator and the IT_administrator roles. The roles are mapped to the permissions can_launch_investigations and can_get_asset_details that map to the custom REST API endpoints to launch investigations and get asset details.
IT_Investigator Role
| Artifact |
Description |
| Role |
IT_Investigator |
| Permission |
can_launch_investigations |
| RBAC Config |
Associates can_launch_investigations with the IT_Investigator role |
| Type Definition |
JSON schema for an investigation |
| Custom REST Endpoint |
Endpoint for launching an investigation |
IT_administrator Role
| Artifact |
Description |
| Role |
IT_administrator |
| Permission |
can_get_asset_details |
| RBAC Config |
Associates can_get_asset_details with the IT_administrator role |
| Type Definition |
JSON schema for an asset |
| Custom REST Endpoint |
Endpoint for getting asset details |
Let's look at what happens when Fred wants to launch an investigation on a laptop:
- Fred tries to launch an investigation for a laptop asset.
- Access Management looks at the RBAC configuration and determines that the REST endpoint requires the permission
can_launch_investigation.
- Access Management confirms that Fred does have the
can_launch_investigation permission because he has been assigned to the role IT_Investigator.
- The launch investigation on the asset request is forwarded to the launch investigation REST endpoint.
- The launch investigation REST endpoint has custom logic to check a few details of the asset (investigations can only be launched on "active" IT assets).
- The request to perform this check is determined to require the REST endpoint that is mapped to the permission
can_get_asset_details.
- The request proceeds because Fred also possesses the
can_get_asset_details permission because he has also been assigned to the IT_Admin role.
- Having ascertained that the asset is active and can be investigated, the application code creates objects representing a new investigation.