After a PingFederate server has been set up so OAuth 2 tokens can be obtained from the server, some configuration is still needed so that these tokens to be used with SCIM 2 operations on PingDirectory Server or PingDirectoryProxy Server. This section explains how to set up an access token validator, which is the configuration object that handles this task.

The following information is needed:
  • The runtime engine service port of the PingFederate server (generally 9031)
  • The client id of an OAuth 2 client configured on the PingFederate server
  • The client secret of the previously-mentioned OAuth 2 client
  • The IP address of the PingFederate server
  1. In order to create the access token validator, the PingFederate server needs to be registered. This can be done with the following command. Note that the hostname verification method is set to allow-all and the Blind Trust manager provider is used for the sake of simplicity; these settings should not be used for production environments. 
    dsconfig create-external-server \
  --server-name PingFederateInstance \
  --type http \
  --set base-url:https://<PingFed IP address>:<PingFed port> \
  --set hostname-verification-method:allow-all \
  --set "trust-manager-provider:Blind Trust"
  2. Create the access token validator using the following command. Note that the client-id and client-secret values should be taken from the PingFederate OAuth 2 client that will be used with the PingDirectory Server or PingDirectoryProxy Server. 
    dsconfig create-access-token-validator \
  --validator-name PingFederateValidator \
  --type ping-federate \
  --set enabled:true \
  --set authorization-server:PingFederateInstance \
  --set client-id:<client-id> \
  --set client-secret:<client-secret>
  3. Add the access token validator to the SCIM 2 HTTP Servlet configuration with the following command: 
    dsconfig set-http-servlet-extension-prop \
  --extension-name SCIM2 \
  --set access-token-validator:PingFederateValidator
  4. This setup can be tested using the ServiceProviderConfig endpoint, which does not require any scopes to access, just a valid bearer token. A GET request to /scim/v2/ServiceProviderConfig should return a response similar to the following: 
    {
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig"
    ],
    "patch": {
        "supported": true
    },
    "bulk": {
        "supported": false,
        "maxOperations": 0,
        "maxPayloadSize": 0
    },
    "filter": {
        "supported": true,
        "maxResults": 0
    },
    "changePassword": {
        "supported": true
    },
    "sort": {
        "supported": false
    },
    "etag": {
        "supported": false
    },
    "authenticationSchemes": [
        {
            "name": "OAuth 2.0 Bearer Token",
            "description": "The OAuth 2.0 Bearer Token Authentication scheme. OAuth enables clients to access protected resources by obtaining an access token, which is defined in RFC 6750 as \"a string representing an access authorization issued to the client\", rather than using the resource owner's credentials directly.",
            "specUri": "http://tools.ietf.org/html/rfc6750",
            "type": "oauthbearertoken",
            "primary": true
        }
    ],
    "meta": {
        "resourceType": "ServiceProviderConfig",
        "location": "https://localhost:8443/scim/v2/ServiceProviderConfig"
    }
}