Understanding Proxy System Transformations

Using conditions is supported for both the proxy, Read Transformation, and the proxy, Write Transformation. However, when conditions are applied to users or groups in the proxy, Read Transformation, the number of returned resources may be "0" or less than the actual number of read entities. This is because some of the entities are filtered out as they do not match the applied condition.

In the following example, the returned resources are "0" because all 5 users (items) returned per page are filtered out as they do not match a condition.

12345678910

SCIM proxy client request: GET /Users?startIndex=6&count=5
SCIM proxy application response:
{
 "startIndex": 6,
 "itemsPerPage": 5,
 "totalResults": 11,
 "Resources": [],
 "schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"]
}

As proxy operations cannot be maintained by the Identity Provisioning UI, you need to manage resources (users, groups, and schemas) by sending SCIM 2.0 API requests to certain endpoints. The following contains a list of all endpoints and operations available in the Identity Provisioning service. Each provisioning system, however, supports only a specific set of operations.

Depending on the infrastructure/environment your Identity Provisioning tenant (bundle or standalone) runs on, use the relevant URI patterns to call an endpoint:

In this example, "name" is the first-level attribute. The "familyName", "givenName" and "middleName" are second-level attributes and cannot be used as the query parameter value.

12345
"name": { 
 "familyName": 
 "Armstrong", "givenName": 
 "Julie", "middleName": "Grace" 
 },

The query parameter value is the resource attribute name. In case you want to specify multiple attribute names, you need to separate them by comma. Using " " (space) or "," (comma) is not a valid value and results in returning all the resource attributes.

In order for an attribute to be included or excluded from the response, the attribute's schema must be defined in the Schemas attribute of the user resource. For example, if you want to return all users with the custom attribute roomNumber in the response, the custom schema must be defined in the Schemas attribute of the user resource.

The attributes and the excludedAttributes query parameters can be combined with other parameters, such as filtering, paging of resources, and paging of multi-value attributes.

• attributes - When specified, this query parameter defines which user or group resource attributes to be included in the response.

This request example returns all users with the active and userName attributes in the response.

This request example combines the attributes query parameter with filtering of a user by userName. It returns only the TestUser with both attributes: active and displayName in the response.

In case an attribute is defined in two schemas (for example, the emails attribute is defined in the core schema and in the custom schema), you need to specify the schema URI and the attribute name as the query parameter value. By doing this, the users will be returned with emails attribute from the specified schema. Otherwise, if you only specify emails without the schema URI, the emails attribute from both schemas will be returned.

• excludedAttributes - When specified, this query parameter defines which user or group resource attributes to be excluded in the response.

This request example returns all users with all attributes excluding userType in the response.

This request example returns all groups with all attributes excluding schemas in the response.

This request example combines the excludedAttributes query parameter with paging parameters startIndex and count of users. It returns 3 users starting with the first one as the first query result with all attributes, excluding schemas in the response.