Access Management Permissions

Solutions rely on their own and external data resources to deliver functionality to end users. It's critical that solutions can protect resources and securely access platform and other solution resources.

Developers define permissions for their solutions to protect and share resources with other solutions. They also declare permissions to request access to Cisco Observability Platform or other solution resources.

Permissions to Protect Resources

The developer must do the following before defining permissions to protect and share the solution's resources:

• Identify Resources - Make a comprehensive list of all the objects and URI resources that the solution owns and manages.
• Determine Access Level to Resource - For each resource, determine what level of access the solution, users, and potentially other solutions should have.
• Define Resource Type and Location - Specify the type of each resource (whether it's a URI or object), its location, and the method of access.
• Assign Permissions to Roles: - Define different roles or extend default roles based on their responsibilities and needs. These roles could be related to user roles, system roles, or specific tasks within the solution. Once roles are defined, the developer assigns permissions to these roles. Each permission specifies what actions a role can perform on a specific resource.

How to Configure Permissions

Developers define solution permissions in a JSON file that consists of an array of permission objects. The permission object specifies the resource type, the access level (read, write), the resource location, and method.

This example permission identifies the resource type (httpAction), location (value of pathPattern), and sets the access to READ.

Copy[
    {
        "name": "getAllDashboards",
        "description": "Permissions for reading all dashboards",
        "displayName": "Read all Dashboards",
        "name": "readObject",
        "description": "Permissions for reading an object",
        "displayName": "Read an object",
        "actionAndResources": [
            {
                "action": {
                    "type": "HttpAction",
                    "classification": "READ",
                    "method": "GET",
                    "pathPattern": "/v1/testing/dashboards"
                    "pathPattern": "/mysolution-rest-endpoints/read"
                }
            }
        ]
    },
    "..."
]

Map Permissions to Roles

Developers map permissions to roles in a JSON file that consists of the two arrays roles and permissions. The solution's permission is referenced with the syntax <solutionName>:getAllDashboards.

The roles array can list both default roles as well as custom roles of the solution. The default roles are identified by the system solution iam. The roles for the solution use the syntax <solutionName>:<role>. The permissions array map the permissions to each role in the `roles array. See Access Management Roles.

In the example roles-to-permissions.json file below, the listed roles have permission to mysolution:getAllDashboards and mysolution:readObject. Thus, a user is assigned to the role Observer (iam:observer) would be able to get all the dashboards of this solution.

Copy[
    {
        "name": "getAllDashboards",
        "name": "readObject",
        "roles": [
            "iam:observer"
            "mysolution:basicRole",
            "iam:observer",
            "iam:agent",
            "iam:tenantAdmin",
            "iam:configManager",
            "iam:troubleshooter"
        ],
        "permissions": [
            {
                "id": "mysolution:getAllDashboards"
                "id": "mysolution:readObject"
            }
        ]
    },
    "..."
]

Permissions to Access Other Resources

To access resources from the platform or other solutions, solutions need to list the permissions that they require.

The developer must do the following before listing the permissions needed by the solution:

• Identify Resources - Make a comprehensive list of all the objects and URI resources that the solution needs to access from the platform and other solutions.
• Find the Required Permissions - For each resource, determine what permission is needed to access the resources. For example, the developer would refer to the Default Platform Permissions to find the necessary permissions to access each platform resource.
• Determine If User Is Involved in the Interaction: The developer must decide if the action to fetch data from the platform or other solution requires user direction. For example, a user action can trigger the solution to send a request to fetch data from the platform or other solutions. In contrast, the solution may not need user authorization to access resources from the platform. For example, the solution can fetch certain configurations from the platform in the background through a cron job.

Declare Permissions to Access Other Resources

Developers declare the required permissions to access other resources in a JSON file that consists of a permissions array. The array contains objects for each permission, identifying the permissionw with the syntax <solutioName>:<permission> and the property can_access_in_background. The property can_access_in_background determines whether the request can be made with or without the user's interaction.

For example, a solution could be configured to require user interaction to request access to user data or post MELT (metrics, events, logs, and traces). Permissions could also be configured to enable actions to run in the background without user interaction, such as reading configuration data without requiring the user's interaction.

In the example file solution-permissions.json, the permission to get health rules requires user authorization (cannot access in the background), whereas, the permission to read access configs from otherSolution can run in the background, thus, not needing user interaction.

Copy{
  "permissions": [
    {
      "id": "healthruleapiservice:getHealthRules",
      "can_access_in_background": false
    },
    {
      "id": "otherSolution:readAccessConfigs",
       "can_access_in_background": true
    }
  ],
  "name": "default"
}

Examples of Solutions Accessing Platform and Other Solution's Resources

Permissions can be configured to enable the example solutions to do the following: 

• Digital Experience Monitoring (DEM) - post MELT data to a tenant.
• Synthetic Monitoring - read a tenant's configuration data.
• Microsite App - access tenant data or an API exposed by another solution.