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
oauthscopeACI 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
oauthscopebind 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.
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.