You need the following information:

  • The runtime engine service port of the PingFederate server, usually 9031
  • The client ID of an OAuth 2.0 client configured on the PingFederate server
  • The client secret of the OAuth 2.0 client
  • The IP address of the PingFederate server

After you configure a PingFederate server to issue OAuth 2 tokens, you must make these tokens compatible with SCIM 2.0 operations on PingDirectory Server or PingDirectoryProxy Server.

This section explains how to set up an access token validator to handle this task.

  1. Register the PingFederate server using the following command.
    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"
    Note:

    In this example, the hostname verification method is set to allow-all and the Blind Trust manager provider is used for the sake of simplicity. You should not use these settings for production environments.

  2. Create the access token validator using the following command.
    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
    Note:

    Take the client-id and client-secret values from the PingFederate OAuth 2 client that will be used with the PingDirectory Server or PingDirectoryProxy Server.

  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. Test the validator by sending a GET request to /scim/v2/ServiceProviderConfig.

    This endpoint does not require any scopes to access, just a valid bearer token. The sever 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"
        }
    }