PingDirectory

Authentication methods

The Consent Service supports the following HTTP authentication methods and the use of token validators for authorization.

Supported HTTP authentication methods

The Consent Service supports the following HTTP authentication methods that are enabled by default:

Basic authentication

With basic authentication, the client provides an encoded user name-password pair in the HTTP Authorization request header. When the Consent Service receives a request using basic authentication, it maps the user name credential to a distinguished name (DN) using an identity mapper. This DN is designated the auth DN and is used to make subsequent authorization decisions. The Consent Service then performs an Lightweight Directory Access Protocol (LDAP) bind using the DN and password to determine if the request can be processed.

Bearer token authentication

With bearer token authentication, the client provides an access token in the HTTP Authorization request header. The access token is always obtained by the client from an external OAuth 2 authorization server and encapsulates information "claims" about a user identity, the client identity, and the requests that the client is authorized to make.

The Consent servlet looks at the request’s Authorization header to determine which authentication type is being used by the client.

Configuring token validators

The PingDirectory server must be configured to accept access tokens using one or both of the following access token validators:

PingFederate access token validator

Supports access tokens issued by a PingFederate authorization server. This validator verifies an access token and discovers its claims by making a request to the PingFederate server’s token introspection endpoint.

If you are using PingFederate 10.0 or earlier, ensure that PingFederate is configured to respond to OAuth and OpenID Connect (OIDC) requests selecting the check boxes mentioned in steps 2 and 3 in Enabling the OAuth AS role.

Starting with PingFederate 10.1, these items are always enabled.
JWT access token validator

Supports signed or encrypted JSON Web Token (JWT) access tokens issued by an arbitrary authorization server. This validator checks an access token by cryptographically verifying the token’s signature using a trusted public certificate. The token’s claims are encoded in the token itself, so discovering the token’s claims does not require an outgoing token introspection request.

The token validator uses its identity mapper to map the subject claim to a DN. This DN is designated the auth DN and is used along with the token’s claims to make subsequent authorization decisions.

If the PingDirectory server is configured with at least one access token validator, the Consent Service uses this access token validator. If the PingDirectory server is configured with more than one access token validator, the validators are consulted in order until one is able to successfully authenticate the request. If the PingDirectory server is configured with multiple access token validators, but only one should be used by the Consent Service, the access token validator can be configured by setting the access-token-validator property of the Consent HTTP Servlet Extension.

Configuring an access token validator for the Consent Service requires the following from the authorization server configuration:

  • The values that the authorization server sets for subject claims must be mappable to a DN in the PingDirectory server.

  • The authorization server must be configured to authorize clients and grant scopes appropriately for privileged or unprivileged Consent API access.

  • The authorization server must be configured to issue tokens with scopes corresponding to the Consent Service’s unprivileged-scope-name and privileged-scope-name configuration.

See the authorization server’s documentation for guidance.