Whether or not a SCIM request is executed on a server depends primarily on both the configured Access Control Instructions (ACIs) in the server and the scopes which are present in the provided OAuth bearer token used to authenticate the request.

SCIM 2.0 requests can be authorized in one of the two following ways:

  • By default, requests are processed using the cn=SCIM2 Servlet,cn=Root DNs,cn=config service account. Whether a requested operation is allowed depends on the ACIs that apply to the operation, which can include both the rights granted to that service account and any rights granted to scopes contained in the OAuth bearer token using the oauthscope ACI bind rule.
  • 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. However, you shouldn't give the service account access to objectclass on a global level. Instead, add the ACI granting objectclass access to the LDAP subtree you want to expose to clients. See Configuring permissions for SCIM 2.0 operations for an example of this.

Note:

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 will also grant unconditional read access to SCIM requests regardless of the provided OAuth scopes because the requests are processed through the service account.