Defining permissions for SCIM 2.0 requests

Successfully executing a System for Cross-domain Identity Management (SCIM) request on a server depends on both the configured access control instruction (ACI) in the server and the scopes present in the OAuth bearer token used to authenticate the request.

You must define ACIs on the backend PingDirectory servers. Don’t define ACIs on the PingDirectoryProxy server.

The server can authorize SCIM 2.0 requests in one of the following ways:

Internally, the server processes all SCIM 2.0 requests using the cn=SCIM2 Servlet,cn=Root DNs,cn=config service account. Allowing a requested operation depends on the relevant ACIs, which can include both the rights granted to that service account and any rights granted to scopes contained in the OAuth bearer token. The oauthscope bind rule is useful because it allows the administrator to use the supplied OAuth scopes in ACI logic.
If user mapping is enabled, the subject of the OAuth bearer token is mapped to an account in the server. In this case, whether a requested operation is allowed depends on the ACIs that apply to the mapped user for the requested operation. You can also use the oauthscope bind rule to grant rights based on scopes in the presented token.

Because of implementation details, access to the objectclass operational LDAP attribute is necessary for SCIM requests to properly execute. Don’t give the service account access to objectclass on a global level. Instead, add the ACI granting objectclass access to the LDAP subtree to expose to clients.

Learn more in Configuring Permissions for SCIM 2.0 Operations.

ACIs that don’t use the oauthscope bind rule can still apply to requested operations.

For example, an ACI that grants unconditional read access to any authenticated LDAP user also grants unconditional read access to SCIM requests regardless of the provided OAuth scopes. This is because the requests are processed through the service account.