The PingAuthorize Server provides Authorization Policy Decision APIs to support non-API use cases.

The Authorization Policy Decision APIs consist of the following policy decision point (PDP) APIs:

• XACML-JSON PDP API

  This API provides a standards-based interface.

  Standards-based enforcement points request policy decisions based on a subset of the XACML-JSON standard. For more information, see XACML 3.0 JSON Profile 1.1.

• JSON PDP API

  This API provides a simple interface.

The Authorization Policy Decision APIs can indicate when a request or response triggers advice, but the application server must implement the advice.

To make a PDP API available, you must:

• Configure the PingAuthorize Server with a feature-enabled license during setup.
• Configure the PDP Service. For more information, see Use policies in a production environment.
• For the XACML-JSON PDP API, configure an Access Token Validator. For more information, see Access Token Validators.

The XACML-JSON PDP API provides a standards-based HTTP API for decisions determined based on the policies configured within the PingAuthorize Server Policy Decision Service.

The XACML-JSON PDP API is implemented as a single endpoint that consuming application servers can access using POST requests to the /pdp path. The HTTP requests must include the appropriate Content-Type and Accept headers, and request bodies must adhere to the XACML-JSON standard. For more information, see Requests and responses.

The XACML-JSON PDP API supports the Multirequests JSON object, which allows a client to make multiple decision requests in a single HTTP request.

A successful XACML-JSON PDP API request goes through a two-phase flow:

1. The client makes the XACML-JSON request, which is received by the XACML-JSON PDP API. The API converts the request to a PingAuthorize Server batch decision request and attempts to authorize the client.

2. On successful authorization, the request is handed off to the Policy Decision Service to process decisions in batch for the XACML-JSON PDP API. The API then converts the batch decision responses to a XACML-JSON response and writes the response to the client.

Before calculating a decision, the XACML-JSON PDP API attempts to authorize the client making the XACML-JSON PDP API request by invoking the Policy Decision Service.

To target a PDP authorization request in-policy, it must apply to the PDP Service and the authorize Action. The default policies included with PingAuthorize Server perform this authorization by only permitting requests with active access tokens that contain the urn:pingauthorize:pdp scope.

For example, under the default policies, the following request would result in an authorized client when the PDP is configured with a mock access token validator:

curl --insecure -X POST \
  -H 'Authorization: Bearer {"active":true,"scope":"urn:pingauthorize:pdp", "sub":"<valid-subject>"}' \
  -H 'Content-Type: application/xacml+json' \
  -d '{"Request":{}}' "https://<your-pingauthorize-host>:<your-pingauthorize-port>/pdp"

The default policies are intended to provide a foundation. You can modify these policies if additional authorization logic is required.

On successful client authorization, the XACML-JSON PDP API invokes the Policy Decision Service with the batch decision requests converted from the XACML-JSON request.

When writing policy for the XACML-JSON PDP API endpoint, you should note the mapping between the XACML-JSON schema and the PingAuthorize Server decision request. For more information, see Requests and Responses.

After the Policy Decision Service determines a decision response, it hands the response back to the XACML-JSON PDP API to provide to the client.

The POST /pdp operation authorizes the client using the MultiRequests JSON object. On successful client authorization, the XACML-JSON PDP API invokes the Policy Decision Service with batch decision requests converted from the XACML-JSON request.

The {{apiPath}} variable in this request represents the client's PingAuthorize host and port. For example, https://<your-pingauthorize-host>:<your-pingauthorize-port>.

The JSON policy decision point (PDP) API provides an HTTP API for decisions determined by the policies configured within the PingAuthorize Server Policy Decision Service.

The JSON PDP API is implemented with an individual decision request endpoint, a batch request endpoint, and a query decision request endpoint that consuming application servers can access using POST requests to the /governance-engine, /governance-engine/batch, or /governance-engine/query paths, respectively.

A successful JSON PDP API request goes through the following flow:

1. The client makes the JSON request, which is received by the JSON PDP API. The API forwards the request to the PDP.

2. When the PDP returns a response, the API sends the response to the client.

By default, decision responses from the JSON PDP API will include, at minimum, basic information about the server instance, the API resources, and the inbound and outbound flow of data. You can use the X-Respond-With request header to modify the verbosity of the decision response. Add one X-Respond-With request header for each decision response view you wish to receive. For more information about decision response views and allowed values, see About the Decision Response View.

Batch requests consist of an array named "requests" of JSON objects, each of which is a standard JSON PDP API single decision request.

After the Policy Decision Service determines a decision response, it hands the response back to the JSON PDP API to provide to the client. JSON PDP API responses include decisions, such as Permit or Deny, and any obligations or advice that matched during policy processing.

The batch decision responses are guaranteed to be returned in the same order as the received responses. For example, the first response in the batch responses corresponds to a decision on the first request in the batch requests.

A valid JSON PDP API request is a simple JSON object that can be forwarded to the Policy Decision Service. Policies can match a decision request by Service, Domain, Action, or other attributes.

The following table describes the values contained in a valid JSON PDP API request.

Policy queries enable you to drive user interfaces and proactively evaluate authorization policy behavior through dynamic decision requests containing unbounded and multivalued attributes.

Decision requests with query attributes check which combinations of subject, action, and resource produce a PERMIT decision result in a specified context. Open-ended and multivalued requests increase decision efficiency by eliminating the need for batch requests to answer such questions as "Which accounts can this user access?" or "Can this user read or delete this resource?"

If a decision request including a subject, action, and resource produces a PERMIT response, that subject is authorized to perform that action on that resource. Policy administrators specify which users (subjects) can access system resources and which actions they can perform on those resources, given a range of dynamic, contextual data points evaluated at runtime. This data can include user roles, identity attributes, organization rules and policies, or a combination of them.

Related topics

The PingAuthorize Policy Editor APIs provide the tools to implement attribute-based access control and dynamic authorization management.

Authentication

Before making requests to the PingAuthorize Policy Editor endpoints, you must be authenticated. The following authentication methods are supported:

Paginated responses

Many of the PingAuthorize Policy Editor endpoints have the term “Paginated” appended to the response (e.g. Collection of Policy (Paginated)). Since these endpoints typically return several entities in a single response body, pagination limits the number of entities returned by specifying query parameters.

The following example represents a JSON paginated response:

{
    "pagination": {
        "page": 1,
        "pageSize": 10,
        "totalItems": 1,
        "totalPages": 1
    },
    "data": [
        {
            <data>
        }
    ]
}

In this example, the first page is returned with a limit of 10 entities. Since there is only a single entity and page, represented by the totalItems and totalPages properties, a second page is not queryable. In this case, the totalItems needs to reach 11 for a second page to be queryable.

Query parameters for paginated responses

Use the following query parameters for pagination:

These endpoints provide the capabilities to read the history of a specific entity version, such as a trust framework, policy manager, and test suite entities.

Entity types

The following table shows entity types and descriptions:

The PingAuthorize Trust Framework defines all the entities that your organization can use to build policies. These entities include, for example, the HTTP request attributes that describe API requests protected by PingAuthorize Server and the services that identify the REST APIs themselves.

The PingAuthorize trust framework service provides endpoints to define the entities and configurations to target policies and rules when making dynamic authorization requests.

Authorization Trust Framework definition data model

Authorization test case (definition) data model

Authorization test scenario (definition) data model

Authorization assertion (definition) data model

Authorization attribute (definition) data model

Authorization effective permissions data model

Authorization condition (definition) data model

Authorization identity class (definition) data model

Authorization identity provider (definition) data model

Authorization service (definition) data model

Authorization value processor (definition) data model

Authorization entity path segment data model

DefinitionType (ENUM)

ServiceType (ENUM)

ValueType (ENUM)

Response codes

Trust Framework testing in PingAuthorize enables you to validate the type conversion of policy information points (PIP) included in decision requests and the logical behavior of conditions.

The PingAuthorize Trust Framework test endpoint allows you to test attribute, condition, and service definitions.

Authorization entity testing data model

Authorization decision status data model

Authorization decision error data model

The Policy Manager APIs provide a powerful way to implement attribute-based access control and dynamic authorization for your organization's services and data. These APIs allow you to define and enforce policies that determine whether a given resource request should be permitted or denied, enabling fine-grained, context-aware access control.

Use the following components in policies and rules to capture authorization logic:

• Conditions: Define authorization logic by comparing one thing to another.

• Targets: Use comparisons to help the decision service determine which policies or rules are relevant to a particular request.

• Statements: Instruct the decision service to perform additional processing in conjunction with an authorization decision. In addition to allowing or blocking access to a resource, using statements, the decision service can attach information to decision responses and filter and transform API payloads.

• Combining algorithms: To evaluate the overall decision of a policy, the decision service applies a combining algorithm. The algorithm determines how rules are combined to produce an authorization decision.

Authorization policies specify the statements (directives that instruct the policy decision service to perform additional processing in conjunction with an authorization decision), conditions (authorization logic comparing one thing to another), and combining algorithms (the process for combining multiple rules) to determine an authorization decision.

This enables you to build policies that answer the question "Should this resource-access request be permitted or denied?. The PingAuthorize policies endpoint allows you to create, read, update, and delete policies.

Authorization policy data model

Authorization policy representation data model

Policy node representation

Either a PolicyRepresentation, PolicySetRepresentation, or PolicyNodeReference.

Authorization policy node reference data model

Authorization repetition settings data model

Response codes

A policy set in PingAuthorize is a container for one or more policies. These endpoints provide the ability to create, read, update, and delete policy sets in the PingAuthorize policy manager.

Authorization policy set data model

Authorization policy set representation data model

Policy node representation

Either a PolicyRepresentation, PolicySetRepresentation, or PolicyNodeReference.

Response codes

Policy rules power the fine-grained access control capability of PingAuthorize. Rules contain logical conditions that evaluate to true or false. Policies can include one or more rules to produce a fine-grained authorization decision of Permit, Deny, Indeterminate, or Not Applicable.

To evaluate the overall decision of a policy, the policy decision point (PDP) applies a combining algorithm. The default algorithm that is set on a new policy is The first applicable will be the final decision. This algorithm stops evaluating as soon as it reaches a decision that is not Not Applicable.

Authorization rules data model

Rule node representation

Either a RuleRepresentation or a RuleReference.

Authorization rule representation data model

Authorization rule reference data model

ConditionalPermitElseDeny

ConditionalDenyElsePermit

EffectSettings

CombingAlgorithm

Decision (ENUM)

Response codes

A statement is a directive that instructs the policy enforcement point (PEP) to perform additional actions alongside an authorization decision.

By adding statements to the Library, you can easily add them to your policies. Without statements, policies simply return a permit or deny decision. With statements, you can include additional information in decisions, such as adding response headers on a permit decision or including a message with a deny decision. Statements only apply when a rule or policy returns a permit or deny decision. They are not included in decisions that are indeterminate or not applicable.

The Policy Editor comes with the following pre-configured statements:

• Add Filter: Use the add-filter code to add administrator-required filters to System for Cross-domain Identity Management (SCIM) search queries.

• Combine SCIM Search Authorizations: Use the combine-scim-search-authorizations code to optimize policy processing for SCIM search responses.

• Denied Reason: Use the denied-reason code to allow a policy writer to provide an error message that contains the reason for denying a request.

• Exclude Attributes: Use the exclude-attributes code to specify the attributes to exclude from a JSON response.

• Filter Response: Use the filter-response code to direct PingAuthorize Server to invoke policy iteratively over each item of a JSON array contained within an API response.

• Include Attributes: Use the include-attributes code to limit the attributes that a JSON response can return.

• Modify Attributes: Use the modify-attributes code to modify the values of attributes in the JSON request or response.

• Modify Headers: Use the modify-headers code to modify the values of request headers before PingAuthorize sends them to the upstream server or to modify the values of response headers before PingAuthorize returns them to the client.

• Modify Query: Use the modify-query to modify the query string of the request sent to the API server.

• Modify SCIM Patch: Use the modify-scim-patch code to add operations to a SCIM patch in a modify request before it is submitted to the store adapter.

• Regex Replace Attributes: Use the regex-replace-attributes to specify a regex to search for attributes in a request or response body and replace their values with a regex replacement string.

For more information about statement codes and payloads, see Statements in the PingAuthorize Policy Administration Guide.

The statements endpoint provides operations for creating, reading, updating, and deleting policy statements. Each operation requires either a branch ID or a statement ID in the request URL.

Statements data model

Result filtering data model

Response codes

Targets define the conditions that determine when policies and rules apply to decision requests.

Targets enable the decision service to evaluate whether a policy or rule is relevant to a specific request. If a target's condition is true, the rule or policy will be evaluated. Otherwise, the rule or policy is not applicable to the decision request. The library makes targeting logic available for easy reuse across policies and rules.

The targets endpoint provides operations for creating, reading, updating, and deleting policy targets. Each operation requires either a branch ID or a statement ID in the request URL.

Targets data model

Response codes

Use the test suite to define test cases, test scenarios, and assertions to validate the behavior of Trust Framework and policy entities.

Building a library of test cases supports a test-driven approach to policy and Trust Framework development. This library can serve as a suite of regression checks, ensuring consistent behavior with each new version of your policies or Trust Framework.

Test scenarios include the subject, resources, actions, and attributes relevant to a decision, as well as optional overrides for attribute and service values. Test cases build on test scenarios by:

• specifying which policy, rule, or Trust Framework definition to test, and
• adding optional assertions to validate the decision result.

After you define a test scenario, you can reference that scenario by ID in your test cases.

For more information about each test suite entity type, see Test Suite in the PingAuthorize Policy Administration Guide.

The test suite endpoint provides operations for creating, reading, updating, and deleting test suite entities. Each operation requires either a branch ID or a statement ID in the request URL.

Test suite data model

Test case data model

Test scenario data model

Test entity data model

Assertion data model

Using the test runner, you can validate policy and Trust Framework configurations through automated testing.

A test run executes one or more test cases, or an entire test suite, and returns the results.

Test runner data model

Response codes

Snapshots provide a comprehensive, point-in-time representation of the system's configuration and policy state. Stored as a .snapshot file, they allow you to capture and preserve the state of your authorization environment, enabling straightforward replication of policy and Trust Framework configuration across environments. Snapshots support version control and change management by allowing teams to safely experiment with policy updates or system changes, and quickly revert to a previous state if necessary.

Each snapshot is associated with a specific commit. For more information on managing snapshots in the Policy Editor, see Snapshot Manager.

Snapshot service data model

Snapshot entity reference data model

Conflict data model

Conflict resolution data model

Response codes

The branch manager provides operations to create snapshots, as well as read, update, and merge policy branches.

Policy branches enable you to manage different sets of Trust Framework definitions and policies by storing these sets in separate branches. This is helpful in development environments, where you might need to quickly reconfigure PingAuthorize between policy branches.

To easily switch between policy branches and test configurations, define Policy External Servers for each branch and update the Policy Decision Service's policy-server property. Learn more in Changing the active policy branch.

Branch manager data model

Resolution data model

Entity reference

Response codes

A snapshot is a set of committed Trust Framework and policy changes made on a branch. You can import and export snapshots to create policy backups and transfer policy configuration between Policy Editor instances.

A deployment package in PingAuthorize is a compiled version of the policy tree. The deployment packages includes all trust framework entities consumed by the policy tree and is the key element that is deployed to PingAuthorize Server.

This service provides the ability to read, create, update, and delete deployment packages.

Authorization deployment package data model

Authorization deployment package approval data model

Check the system status to make sure the Policy Editor instance is running.

System data model

Response codes

Authorization decision response buffer configuration data model

The PingAuthorize Server’s SCIM APIs use the data types and resource format specified by the SCIM 2.0 schema standard, RFC 7643.

SCIM data types

SCIM attributes are typed. The following data types are used:

A SCIM attribute may also be multi-valued. All members of a multi-valued attribute must be of the same data type.

SCIM resource format

A SCIM resource is always represented as a JSON object.

The attributes available in any particular SCIM resource type are defined by the schemas associated with the resource type. A resource type has at least one core schema and may have zero or more extension schemas. An extension schema may be configured to be either required or optional for a resource to be valid.

SCIM schemas provide the means of namespacing JSON attributes. Every schema is identified by a unique schema URN prefix. When specifying attributes, the schema URN prefix is implied for attributes belonging to the core schema but must be provided for attributes belonging to extension schemas. Consider this example resource:

{
  "schemas": [
    "urn:pingidentity:schemas:User:1.0",
    "urn:pingidentity:schemas:sample:profile:1.0"
  ],
  "id": "5caa81af-ec05-41ff-a709-c7378007a99c",
  "meta": {
    "created": "2016-06-07T13:13:30.873Z",
    "lastModified": "2016-06-07T13:13:30.873Z",
    "resourceType": "Users",
    "location": "https://example.com/scim/v2/Users/5caa81af-ec05-41ff-a709-c7378007a99c"
  },
  "userName": "joe.chip",
  "name": {
    "familyName": "Chip",
    "formatted": "Joe Chip",
    "givenName": "Joe"
  },
  "accountVerified": true,
  "urn:pingidentity:schemas:sample:profile:1.0": {
    "termsOfService": [
      {
        "id": "urn:X-pingidentity:ToS:StandardUser:1.0",
        "timeStamp": "2014-11-23T16:36:59Z",
        "collector": "urn:X-pingidentity:App:Mobile:1.0"
      }
    ]
  }
}

This resource has two schemas:

1. A core schema: urn:pingidentity:schemas:User:1.0
2. An extension schema: urn:pingidentity:schemas:sample:profile:1.0

The core schema attribute userName may be specified as userName or as urn:pingidentity:schemas:User:1.0.

The extension schema attribute termsOfService may only be specified as urn:pingidentity:schemas:sample:profile:1.0.

Common attributes

In addition to core schema and extension schema attributes, all SCIM resources of any type may have certain common attributes. These attributes never need to be namespaced with a URN.

List responses

Some SCIM responses, such as search responses, contain multiple resources. These responses are called list responses and have a consistent format using the following fields:

By default, the access token provided by the client in the request (see Authentication) is used to control access to requested resources. The PingAuthorize Server’s access control policies are customizable, but in general, the scopes granted by the access token determine which resources and attributes are returned.

If access controls determine that the client cannot access the requested resource, then a response with a 403 status code is returned.

{
    "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:Error"
    ],
    "scimType": "insufficient_scope",
    "status": 403,
    "detail": "Requested operation not allowed by the granted OAuth2 scopes."
}

A client may be allowed to access a resource but not all of its attributes. Clients should be prepared to receive incomplete resources, including resources stripped of attributes that are required by the schema.

For information about how to configure an application appropriately for SCIM API access, see configuring scopes in the PingAuthorize Server client developer guide.

Clients authenticate to the SCIM APIs by using bearer token authentication, as defined by RFC 6750. Every request must include an Authorization request header, where the header value uses the form Bearer {access token}.

A bearer token must be obtained from an external authorization server, such as PingFederate.

For each resource type, the PingAuthorize Server exposes a SCIM endpoint. For example:

• /scim/v2/Users
• /scim/v2/Products
• /scim/v2/Suppliers

Making requests

Each resource is addressable by an identifier; the combination of a resource type name (Users) and the identifier (5caa81af-ec05-41ff-a709-c7378007a99c) uniquely identifies the resource to the PingAuthorize Server. For example:

/scim/v2/Users/5caa81af-ec05-41ff-a709-c7378007a99c

Media types

All requests and responses use the UTF-8 character encoding and are formatted as JSON. Clients must accept either the application/scim+json or application/json media types, and the request should always provide an Accept request header with one or both values.

When providing a request body (as with POST, PUT, and PATCH requests), clients should include a Content-Type request header with the value application/scim+json or application/json.

Updating resources

SCIM resources are modified using the PUT and PATCH methods, described by sections 3.5.1 and 3.5.2 of RFC 7644, respectively. See the user profile API reference for examples.

Because access controls enforced by the PingAuthorize Server’s policies and scopes can limit a client’s view of a resource, the server must assume that the client may not have access to all attributes of a resource. This is important for PUT requests, because the server needs to distinguish between a case in which the client explicitly wishes to remove an attribute and a case in which the client does not know about an attribute. The general rule is that the server ignores an attribute that is omitted from a PUT request, rather than deleting it. If a client explicitly wishes to delete an attribute, then it should set its value to null.

When a client requests a modification, the PingAuthorize Server computes the difference between the current state of the resource and the state specified by the modification request, applying a minimal set of changes when passing the modification request to the user store. In effect, this means that a PUT request is ultimately treated as if it were a PATCH request. This prevents unnecessary modifications from being sent to the user store and, more importantly, also prevents the client from inadvertently removing attributes that it did not specify because it did not have access to them.

The PingAuthorize Server performs this diffing logic at the attribute and sub-attribute level, comparing each attribute in a modification request against the corresponding attribute in the current resource. For multivalued, complex attributes, the server iterates through the values in the modification request and tries to find the corresponding value in the current resource to determine a match. If it is found, it then diffs at the sub-attribute level.

This behavior is summarized by the following table.

For example, if the current value of a resource’s phoneNumbers attribute is:

"phoneNumbers": [
   {
      "value": "054-757-2291",
      "type": "work",
      "primary":"true"
   }
]

And a modification request includes:

"phoneNumbers": [
   {
      "value": "054-757-2291",
      "primary": "false"
   }
]

Then the final result is:

"phoneNumbers": [
   {
      "value": "054-757-2291",
      "type": "work",
      "primary": "false"
   }
]

When finding a matching value in a complex attribute, matches of the value, $ref, type, and display sub-attribute values are given more weight when compared to values of other sub-attributes. This is done because the above sub-attribute values are typically unique for any given complex attribute.

Specifying attributes to return

By default, all attributes that the client is authorized to read will be returned when a resource is requested. Your application can provide special query parameters to override this behavior.

The /Me endpoint

A special endpoint is available at /scim/v2/Me that acts as an alias for the currently authenticated user, the user associated with the bearer token.

For example, if the currently authenticated user is available via the path /scim/v2/Users/5caa81af-ec05-41ff-a709-c7378007a99c, then the same user resource will also be available through /scim/v2/Me. The two paths are interchangeable, and the /Me endpoint can be substituted in any request path where the combination of resource type and identifier might otherwise be used.

This includes sub-resources. For example, for an authenticated user with the ID 5caa81af-ec05-41ff-a709-c7378007a99c, the paths /scim/v2/Users/5caa81af-ec05-41ff-a709-c7378007a99c/password and /scim/v2/Me/password both identify the user’s password sub-resource.

Filtering searches

Some but not all endpoints support an optional filter parameter for filtering responses containing multiple resources. As a rule of thumb, if a SCIM path returns a single resource, it does not support filtering. If it returns multiple resources, then it generally supports filtering. For example, /scim/v2/Users supports filtering, but /scim/v2/Users/{userId} does not.

SCIM filtering is described in detail by RFC 7644, section 3.4.2.2, and that should be considered an authoritative reference. The following discussion should not be considered exhaustive.

The value of the filter parameter is a search filter, which typically takes the form <attribute> <operator> <value>. For example:

filter=userName eq "pkd"

Search responses are always list responses, except in the case of an error.

The following attribute operators are supported:

The following logical operators are supported:

The following grouping operators are supported:

The following is a sample of filtering by a core attribute:

filter=userName eq "pkd"

The following is a sample of filtering by an extended attribute using the ‘starts with’ operator:

filter=urn:pingidentity:schemas:sample:profile:1.0:birthDate sw "1939"

The following is a sample of a complex filter:

filter=emails[value eq "glen@runciter.com"]

The following is a sample of a complex filter with two expressions:

filter=emails[value eq "glen@runciter.com" and type eq "work"]

For more information about searching with SCIM, including caveats, see the client developer guide.

Pagination

The client can provide pagination parameters to page through search result sets.

The PingAuthorize Server provides three service metadata endpoints, ServiceProviderConfig, Schemas, and ResourceTypes, which clients may use to discover information about the service’s capabilities, configuration, schemas, and resource types.

Clients do not necessarily need to rely on the service metadata endpoints. Clients may be developed based on an out-of-band understanding of the service configuration and data.

The user profile endpoint exposes user attributes from the PingAuthorize Server’s user store as SCIM resources.

Note that the schemas used, the resource type, and the endpoint name may all be configured differently than shown here.

This guide assumes that the PingAuthorize Server is configured to serve user resources at the /scim/v2/Users endpoint. The information in this reference is applicable to any resource type, however.

A special endpoint is available at /scim/v2/Me that acts as an alias for the currently authenticated user, the user associated with the bearer token.

For example, if the currently authenticated user is available via the path /scim/v2/Users/5caa81af-ec05-41ff-a709-c7378007a99c, then the same user resource will also be available through /scim/v2/Me. The two paths are interchangeable, and the /Me endpoint can be substituted in any request path where the combination of resource type and identifier might otherwise be used.

This includes sub-resources. For example, for an authenticated user with the ID 5caa81af-ec05-41ff-a709-c7378007a99c, the paths /scim/v2/Users/5caa81af-ec05-41ff-a709-c7378007a99c/password and /scim/v2/Me/password both identify the user’s password sub-resource.

Like all other responses, errors are returned as SCIM responses with a media type of application/scim+json.

{
    "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:Error"
    ],
    "scimType": "invalid_token",
    "status": 401,
    "detail": "Access token is expired or otherwise invalid."
}

Password update errors

If an error response is returned because of a password update failure, then an additional field will be provided under the urn:unboundid:scim:api:messages:2.0:PasswordUpdateError schema URN.

{
     "detail": "The provided new password cannot be the same as the current password or any password in the user's password history",
     "schemas": [
         "urn:pingidentity:scim:api:messages:2.0:PasswordUpdateError"
     ],
     "scimType": "invalidValue",
     "status": 400,
     "urn:pingidentity:scim:api:messages:2.0:PasswordUpdateError": {
         "passwordRequirements": [
             {
                 "additionalInfo": "The provided new password cannot be the same as the current password or any password in the user's password history.",
                 "description": "The new password must not be the same as the current password.",
                 "requirementSatisfied": false,
                 "type": "notCurrentPassword"
             }
         ]
     }
 }

The following changes have been made to the PingAuthorize SCIM API.