--- title: Authorization and roles description: IDM provides role-based authorization that restricts direct HTTP access to REST interface URLs. This access control applies to direct HTTP calls only. Access for internal calls (for example, calls from scripts) is not affected by this mechanism. component: pingidm version: 8.1 page_id: pingidm:auth-guide:authorization-and-roles canonical_url: https://docs.pingidentity.com/pingidm/8.1/auth-guide/authorization-and-roles.html keywords: ["Authorization", "Roles", "Scripts"] section_ids: router-authz-js: Modify and extend the router authorization script access-json: Configure access control in access.json access-control-rest: Change the access configuration over REST get_the_current_access_configuration: Get the Current Access Configuration replace_the_access_configuration: Replace the Access Configuration granting-internal-roles: Grant internal authorization roles manually managing-workflow-access: Secure access to workflows secure-openicf-access: Secure RCS access --- # Authorization and roles IDM provides role-based authorization that restricts direct HTTP access to REST interface URLs. This access control applies to direct HTTP calls only. Access for internal calls (for example, calls from scripts) is not affected by this mechanism. When a user authenticates, they are given a set of default *roles*, as described in [Authentication and Roles](authentication-and-roles.html). The authorization configuration grants access rights to users, based on these roles acquired during authentication. You can use internal and managed roles to restrict access, with the following caveats: * Internal roles are not meant to be provisioned or synchronized with external systems. * Internal roles cannot be given assignments. * Event scripts (such as `onCreate`) cannot be attached to internal roles. * The internal role schema is not configurable. Authorization roles are referenced in a user's `authzRoles` property by default, and are assigned when the user authenticates. By default, managed users are assigned the `openidm-authorized` role when they authenticate. The following request shows the authorization roles for user psmith when that user logs in to the server: ``` curl \ --header "X-OpenIDM-Username: psmith" \ --header "X-OpenIDM-Password: Passw0rd" \ --header "Accept-API-Version: resource=1.0" \ --cacert ca-cert.pem \ --request GET \ "https://localhost:8443/openidm/info/login" { "_id": "login", "authenticationId": "psmith", "authorization": { "userRolesProperty": "authzRoles", "component": "managed/user", "authLogin": false, "authenticationIdProperty": "username", "roles": [ "internal/role/openidm-authorized" ], "ipAddress": "0:0:0:0:0:0:0:1", "authenticationId": "psmith", "protectedAttributeList": [ "password" ], "id": "psmith", "moduleId": "MANAGED_USER", "queryId": "credential-query" } } ``` The authorization implementation is configured in two files: * `openidm/bin/defaults/script/router-authz.js` * `project-dir/conf/access.json` IDM calls the `router-authz.js` script for each request, through an `onRequest` hook defined in the `router.json` file. `router-authz.js` references your project's access configuration (`access.json` ) to determine the allowed HTTP requests. If access is denied, according to the configuration defined in `access.json` , the `router-authz.js` script throws an exception, and IDM denies the request. `router.json` also defines an `onResponse` script, `relationshipFilter`. This provides additional filtering to ensure that the user has the appropriate access to see the data of the related object. You can change this behavior by extending or updating `/bin/defaults/script/relationshipFilter.js` , or by removing the `onResponse` script if you don't want additional filtering on relationships. For more information about relationships, refer to [Configuring relationships](../objects-guide/relationships.html). | | | | - | --------------------------------------------------------------------------------------------------------------------- | | | You can configure [delegated administration](delegated-admin.html) to grant access that bypasses this access control. | ## Modify and extend the router authorization script The router authorization script (`router-authz.js` contains a number of functions that enforce access rules. For example, the following function controls whether users with a certain role can start a specified process: ```javascript function isAllowedToStartProcess() { var processDefinitionId = request.content._processDefinitionId; var key = request.content._key; return isProcessOnUsersList(function (process) { return (process._id === processDefinitionId) || (process.key === key); }); } ``` You can extend the default authorization mechanism by defining additional functions in `router-authz.js` and by creating new access control rules in `access.json`. | | | | - | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | Some authorization-related functions in `router-authz.js` should *not* be altered, because they affect the security of the server. Such functions are indicated in the comments in that file. | ## Configure access control in `access.json` The `access.json` configuration includes a set of rules that govern access to specific endpoints. These rules are tested in the order in which they appear in the file. You can define more than one rule for the same endpoint. If one rule passes, the request is allowed. If all the rules fail, the request is denied. The following rule (from a default `access.json` file) shows the access configuration structure: ```json { "pattern" : "system/*", "roles" : "internal/role/openidm-admin", "methods" : "action", "actions" : "test,testConfig,createconfiguration,liveSync,authenticate" } ``` This rule specifies that users with the `openidm-admin` role can perform the listed actions on all `system` endpoints. The parameters in each access rule are as follows: * `pattern` The REST endpoint for which access is being controlled. `"*"` specifies access to all endpoints in that path. For example, `"managed/user/*"` specifies access to all managed user objects. * `roles` A comma-separated list of the roles to which this access configuration applies. The `roles` referenced here align with the object's security context (`security.authorization.roles`). The `authzRoles` relationship property of a managed user produces this security context value during authentication. * `methods` A comma-separated list of the methods that can be performed with this access. Methods can include `create, read, update, delete, patch, action, query`. A value of `"*"` indicates that all methods are allowed. A value of `""` indicates that no methods are allowed. * `actions` A comma-separated list of the allowed actions. The possible actions depend on the resource (URL) that is being exposed. Note that the `actions` in the default `access.json` file do not list all the [supported actions](../scripting-guide/scripting-func-ref.html#supported-actions) on each resource. A value of `"*"` indicates that all actions exposed for that resource are allowed. A value of `""` indicates that no actions are allowed. * `customAuthz` An optional parameter that lets you define a custom function for additional authorization checks. Custom functions are defined in `router-authz.js` . * `excludePatterns` An optional parameter that lets you specify endpoints to which access should not be granted. ## Change the access configuration over REST You can manage the access configuration at the endpoint `openidm/config/access`. To change an access rule, first get the current access configuration, amend it to change the access rule, then submit the updated configuration in a PUT request. This example restricts access to the `info` endpoint to users who have authenticated: ### Get the Current Access Configuration Request ```none curl \ --header "X-OpenIDM-Username: openidm-admin" \ --header "X-OpenIDM-Password: openidm-admin" \ --header "Accept-API-Version: resource=1.0" \ --request GET \ "http://localhost:8080/openidm/config/access" ``` > **Collapse: Show response** > > Response > > ```json > { > "_id": "access", > "configs": [ > { > "pattern": "health", > "roles": "*", > "methods": "read", > "actions": "" > }, > { > "pattern": "info/*", > "roles": "*", > "methods": "read", > "actions": "*" > }, > ... > ] > } > ``` ### Replace the Access Configuration Shortened request ```none curl \ --header "X-OpenIDM-Username: openidm-admin" \ --header "X-OpenIDM-Password: openidm-admin" \ --header "Content-type: application/json" \ --header "Accept-API-Version: resource=1.0" \ --request PUT \ --data '{ "_id": "access", "configs": [ access-config-object ] }' \ "http://localhost:8080/openidm/config/access" ``` > **Collapse: Show response** > > Response > > ```json > { > "_id": "access", > "configs": [ > { > "pattern": "health", > "roles": "*", > "methods": "read", > "actions": "" > }, > { > "pattern": "info/*", > "roles": "internal/role/openidm-authorized", > "methods": "read", > "actions": "*" > }, > ... > ] > } > ``` ## Grant internal authorization roles manually Apart from the default roles that users get when they authenticate, you can grant internal authorization roles manually, over REST or using the admin UI. This mechanism works in the same way as the granting of managed roles. For information about granting managed roles, refer to [Grant Roles to a User](../objects-guide/roles-over-rest.html#granting-role-user). To grant an internal role manually through the admin UI: 1. From the navigation bar, click Manage > User, and click a user. 2. From the Authorization Roles tab, click Add Authorization Roles. 3. Select Internal Role as the Type, click in the Authorization Roles field to select from the list of defined Internal Roles, and click Add. To manually grant an internal role over REST, add a reference to the internal role to the user's `authzRoles` property. The following command adds the `openidm-admin` role to user bjensen (with ID `9dce06d4-2fc1-4830-a92b-bd35c2f6bcbb`): ``` curl \ --header "X-OpenIDM-Username: openidm-admin" \ --header "X-OpenIDM-Password: openidm-admin" \ --header "Accept-API-Version: resource=1.0" \ --header "Content-Type: application/json" \ --cacert ca-cert.pem \ --request PATCH \ --data '[ { "operation": "add", "field": "/authzRoles/-", "value": {"_ref" : "internal/role/openidm-admin"} } ]' \ "https://localhost:8443/openidm/managed/user/9dce06d4-2fc1-4830-a92b-bd35c2f6bcbb" { "_id": "9dce06d4-2fc1-4830-a92b-bd35c2f6bcbb", "_rev": "0000000050c62938", "mail": "bjensen@example.com", "givenName": "Barbara", "sn": "Jensen", "description": "Created By CSV", "userName": "bjensen", "telephoneNumber": "1234567", "accountStatus": "active", "effectiveRoles": [], "effectiveAssignments": [] } ``` You can also grant internal roles dynamically using [conditional role grants](../objects-guide/roles-over-rest.html#conditional-role-grants). | | | | - | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | Because internal roles are not managed objects, you cannot manipulate them in the same way as managed roles. Therefore, you cannot add a user to an internal role, as you would to a managed role.To add users directly to an internal role, add the users as values of the role's `authzMembers` property. For example:``` curl \ --header "X-OpenIDM-Username: openidm-admin" \ --header "X-OpenIDM-Password: openidm-admin" \ --header "Content-Type: application/json" \ --cacert ca-cert.pem \ --request POST \ --data '{"_ref":"managed/user/bjensen"}' \ "https://localhost:8443/openidm/internal/role/3042798d-37fd-49aa-bae3-52598d2c8dc4/authzMembers?_action=create" ``` | ## Secure access to workflows The end-user UI is integrated with the embedded Flowable workflow engine, enabling users to interact with workflows. Available workflows are displayed under the Processes item on the dashboard. For a workflow to be displayed here, the workflow definition file must be present in the `openidm/workflow` directory. | | | | - | ------------------------------------------------------------------------------------------------------------------------- | | | The end-user UI is not bundled with PingIDM. Learn more in [Install the end-user UI](../setup-guide/idm-enduser-ui.html). | General access to workflow-related endpoints is based on the access rules defined in the `conf/access.json` file. The configuration defined in `conf/process-access.json` specifies who can invoke workflows. By default, all users with the role `openidm-authorized` or `openidm-admin` can invoke any available workflow. The default `process-access.json` file is as follows: ```json { "workflowAccess" : [ { "propertiesCheck" : { "property" : "_id", "matches" : ".*", "requiresRole" : "internal/role/openidm-authorized" } }, { "propertiesCheck" : { "property" : "_id", "matches" : ".*", "requiresRole" : "internal/role/openidm-admin" } } ] } ``` * `property` Specifies the property used to identify the process definition. By default, process definitions are identified by their `_id`. * `matches` A regular expression match is performed on the process definitions, according to the specified property. The default (`"matches" : ".*"`) implies that all process definition IDs match. * `requiresRole` Specifies the authorization role that is required for users to have access to the matched process definition IDs. In the default file, users with the role `openidm-authorized` or `openidm-admin` have access. To extend the process action definition file, identify the processes to which users should have access, and specify the qualifying authorization roles. For example, if you want to allow access to users with a role of `ldap`, add the following code block to the `process-access.json` file: ```json { "propertiesCheck" : { "property" : "_id", "matches" : ".*", "requiresRole" : "ldap" } } ``` To configure multiple roles with access to the same workflow process, simply add additional `propertiesCheck` objects. The following example grants access to users with a role of doctor and nurse to the same workflows: ```json { "propertiesCheck" : { "property" : "_id", "matches" : ".*", "requiresRole" : "doctor" } }, { "propertiesCheck" : { "property" : "_id", "matches" : ".*", "requiresRole" : "nurse" } } ``` ## Secure RCS access You can secure the `openicf` WebSocket endpoint used for communication between IDM and RCS client mode. This allows you to control which users or roles can connect to this endpoint on behalf of a specific RCS instance. The `openicf` servlet in your access configuration (`access.json`) lets you manage authorization for the `openicf` endpoint. 1. In your authentication configuration *(tooltip: You can manage the authentication configuration over REST at the config/authentication endpoint, or directly in the conf/authentication.json file.)* (`conf/authentication.json`), add a specific role to the `roles` array of the RCS static user mapping. This role authorizes access to the `openicf` endpoint for the specified RCS. Example ```json { "subject": "rcsclient", "localUser": "internal/user/idm-provisioning", "roles": [ "internal/role/myrcsserver-authorized" (1) ], "executeAugmentationScript": false } ``` | | | | ----- | ----------------------------------------------------------------------------------------------------------------------- | | **1** | In this example, the role `internal/role/myrcsserver-authorized` is added to the authenticated user's security context. | 2. Add a new rule in your access configuration (`conf/access.json`) to define authorization for the `openicf` endpoint. Example ```json { "servlet": "openicf", (2) "pattern": "myrcsserver", (3) "roles": "internal/role/myrcsserver-authorized", (1) "methods": "read" } ``` This rule ensures that: | | | | ----- | ------------------------------------------------------------------------------------ | | **1** | only users possessing the `internal/role/myrcsserver-authorized` role can access the | | **2** | `openicf` WebSocket endpoint | | **3** | for the RCS named `myrcsserver`. |