PingOne Advanced Identity Cloud

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, the user is given a set of default roles, as described in Authentication and Roles. 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 aren’t meant to be provisioned or synchronized with external systems.

  • Internal roles can’t be given assignments.

  • Event scripts, such as onCreate, can’t be attached to internal roles.

  • The internal role schema isn’t 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://<tenant-env-fqdn>/openidm/info/login"
{
  "_id": "login",
  "authenticationId": "psmith",
  "authorization": {
    "userRolesProperty": "authzRoles",
    "component": "managed/realm-name_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 a router authorization script and the access configuration.

Advanced Identity Cloud calls the router authorization for each request and checks against your access configuration to determine whether to allow HTTP requests.

The onResponse and relationshipFilter filters provide additional filtering to ensure the user has the appropriate access to observe the data of the related object. Learn more in Relationships between objects.

You can configure delegated administration to bypass this access control.

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 
curl \
--header "Authorization: Bearer <access-token>" \
--header "Accept-API-Version: resource=1.0"  \
--request GET \
"https://<tenant-env-fqdn>/openidm/config/access"
{
  "_id": "access",
  "configs": [
    {
      "pattern": "info/*",
      "roles": "*",
      "methods": "read",
      "actions": "*"
    },
    {
      "pattern": "authentication",
      "roles": "*",
      "methods": "read,action",
      "actions": "login,logout"
    },
    ...
  ]
}
Replace the access configuration 
curl \
--header "Authorization: Bearer <access-token>" \
--header "Content-type: application/json" \
--header "Accept-API-Version: resource=1.0"  \
--request PUT \
--data '{
  "_id": "access",
  "configs": [ {access-config-object} ]
}' \
"https://<tenant-env-fqdn>/openidm/config/access"
{
  "_id": "access",
  "configs": [ {access-config-object} ]
}

Access configuration format

The access configuration includes a set of rules that govern access to specific endpoints. These rules are tested in the order 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 shows the access configuration structure:

{
    "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/realm-name_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 example access file do not list all the 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.

excludePatterns

An optional parameter that lets you specify endpoints to which access shouldn’t be granted.

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 IDM admin console. This mechanism works in the same way as the granting of managed roles. Learn more about granting managed roles in Grant Roles to a User. To grant an internal role manually through the IDM admin console:

  1. In the Advanced Identity Cloud admin console, click Native Consoles > Identity Management.

  2. Click Manage Users and click a user.

  3. On the Authorization Roles tab, click Add Authorization Roles.

  4. 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 grant an internal role over REST manually, 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 "Authorization: Bearer <access-token>" \
--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://<tenant-env-fqdn>/openidm/managed/realm-name_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.

Because internal roles aren’t managed objects, you can’t manipulate them in the same way as managed roles. You can’t 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 "Authorization: Bearer <access-token>" \
--header "Content-Type: application/json" \
--cacert ca-cert.pem \
--request POST \
--data '{"_ref":"managed/realm-name_user/bjensen"}' \
"https://<tenant-env-fqdn>/openidm/internal/role/3042798d-37fd-49aa-bae3-52598d2c8dc4/authzMembers?_action=create"

Secure RCS access[1]

You can secure the openicf WebSocket endpoint used for communication between Advanced Identity Cloud and RCS client mode. Specifying the authorization roles allowed to connect to the openicf servlet for each RCS instance ensures that RCS access to Advanced Identity Cloud is protected can only be accessed by trusted RCS clients. The openicf servlet in your access configuration lets you manage authorization for the openicf endpoint.

  1. In your authentication configuration, 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
    {
    "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 to define authorization for the openicf endpoint. Learn more about changing the access configuration over REST.

    Example
    {
    "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.
1. Not available in the Advanced Identity Cloud regular channel yet. Currently included in the rapid channel for sandbox environments.