This example shows how to correctly configure permissions so POST requests with the "userAdd" scope will succeed on a PingDirectoryProxy Server deployment. This example assumes that you have set up an LDAP mapping SCIM 2.0 Resource Type for the inetOrgPerson objectclass (see Configuring an LDAP Mapping SCIM 2.0 resource type).

  1. If the SCIM Resource Type being targeted already has a value for the create-dn-pattern property, skip to step 2. Otherwise, run the following dsconfig command on the PingDirectoryProxy Server.
    dsconfig set-scim-resource-type-prop \
    --type-name Users \
    --set create-dn-pattern:entryUUID=generated,ou=People,dc=example,dc=com
    
  2. Send the following request to the PingDirectoryProxy Server's SCIM /Users endpoint. The HTTP port may vary depending on how the deployment was configured.
    curl -k -X POST \
    https://localhost:8443/scim/v2/Users/ \
    -H 'Authorization: Bearer {"active":true}' \
    -H 'Content-type: application/json' \
    --data '{"username":"user.test", "name":{"formatted":"Test",
    "familyName":"User"}, "schemas":["urn:pingidentity:schemas:User:1.0"]}'

    The response from the server should have a status of 403 and should contain a correlation ID, similar to the following:

    {
    "schemas":["urn:ietf:params:scim:api:messages:2.0:Error"],
    "status":"403",
    "detail":"Request failed:
    correlationID='faa707b3-5d48-42e6-9e78-2c8dbb1e2cac'"
    }

    This is the expected response since this SCIM request does not have the permission needed to write to an entry. See Troubleshoot the SCIM 2.0 Servlet Extension for instructions on viewing the full server error message.

  3. An ACI should now be added to the backend server's ou=People,dc=example,dc=com subtree. This ACI grants permission to add entries to the said subtree as long as the SCIM request contains the userAdd scope. The following ldapmodify command for creating the ACI must be run on the backend PingDirectory Server server and not the PingDirectoryProxy Server endpoint . Note that this ACI does not grant write access to attributes, which means modify operations will not succeed. See Overview of access control for more information on configuring ACIs,.
    $ ldapmodify
    dn:ou=People,dc=example,dc=com
    changetype:modify
    add:aci
    aci:(version 3.0; acl "ACI for userAdd scope"; allow (add)
    oauthscope="userAdd";)
  4. Send the POST request to the SCIM / Users endpoint again, this time including the userAdd scope in the bearer token:
    curl -k -X POST \
    https://localhost:8443/scim/v2/Users \
    -H 'Authorization: Bearer {"active":true, "scope":"userAdd"}' \
    -H 'Content-type: application/json' \
    --data '{"username":"user.test", "name":{"formatted":"Test",
    "familyName":"User"}, "schemas":["urn:pingidentity:schemas:User:1.0"]}'

    The response from the server should now contain the created SCIM resource, which should also contain values for the name and username attributes, similar to the following:

    {
    "name":{
    "familyName":"User",
    "formatted":"Test"
    },
    "username":"user.test",
    "id":"6f9a89b8-e766-478c-9667-def049daf6bc",
    "meta":{
    "resourceType":"Users",
    "location":"https://localhost:8443/scim/v2/Users/6f9a89b8-e766-478c-9667-
    def049daf6bc"
    },
    "schemas":["urn:pingidentity:schemas:User:1.0"]
    }