To access the One Identity Manager database, the SCIM plugin be authenticated. Authentication is carried out by the One Identity Manager authentication modules. For more information, see the One Identity Manager Authorization and Authentication Guide.
The authentication modules are checked in the following order and the first successful authentication module is used for logging in. Ensure sure that at least one authentication module is enabled and configured.
Active Directory user account (ADSAccount)
Employee (role-based) (RoleBasedPerson)
Active Directory user account (role-based) (RoleBasedADSAccount)
HTTP Header (role-based) (RoleBasedHTTPHeader)
HTTP Header (HTTPHeader)
OAuth 2.0/OpenID Connect (role-based) (OAuthRoleBased)
The SCIM 2.0 schema exported to the /Schemas endpoint is generated from the One Identity Manager schema. The table definitions to take into account are supplied as are the M:N figures to publish. A data object description with simple and complex properties is created for each table.
Columns in a table
The columns of a table are mapped to simple properties of integral types.
Foreign key relations
The foreign key relations of a table are only included in the schema if the reference's target table is also part of the schema. In this case, a complex property is published with the foreign key's column name. This complex property has the value, $ref, and displayName properties.
The complex property is marked in the schema with the "returned" : "request" attribute. To be able to read this data, the property must be explicitly requested by the SCIM client using the attributes URL parameter.
M:N tables are published under the members complex property in the schema. This also applies if there are several M:N tables to take into account. This complex property defines an array of subelements that have the value, type, $ref, and display properties.
The members complex property is marked in the schema with the attribute "returned" : "request". To be able to read this data, the property must be explicitly requested by the SCIM client via the URL parameter attributes.
If several M:N tables are grouped together, the distinction, from which table the respective element originates, is made on the basis of the value in the type property. Ensure that the value in the type property is also passed when writing to the property. The values accepted as correct are defined in the schema on the respective type subattribute as a list in canonicalValues.
If the value for type cannot be determined for the SCIM client, it can be left blank and is not transmitted with the PUT or PATCH request. The SCIM plugin tries to determine the correct type. The element's ID passed in the value property is used to search in all One Identity Manager tables that are part of the members definition. If the object is found in the process, the operation can be performed.
To process filter expressions with relational comparison operators, the user account used requires the Perform filter functions for SCIM plugin in the API server program function (ApiServer_SCIM). Exceptions are the equals test (eq) and the presence of a value (pr). This applies to both filters in the URL parameter filter and when using the Path filter in patch operations.
If certain users are allowed to handle filter expressions, you can assign the permissions to the users through permissions groups.
The QBM_ApiServer_SCIM permissions group is provided for non role-based login. This group owns the program function. Add the system users to the permissions groups. Administrative system users automatically obtain these permissions groups.
The QER_4_ApiServer_SCIM permissions group is provided for role-based login. This group owns the program function. The permissions group is linked to the Base roles | API Server SCIM filter application role. Add the employees to the application role.
Base URL requests
The SCIM 2.0 specification provides optional requests for the SCIM service provider base URL. These requests can contain a filter expression if required. This is mainly used to search for objects when their endpoint is not known exactly and so the search must be across endpoints.
The SCIM plugin supports these requests. In the filter, only logical OR operations and the comparison operators eq, sw, ew as well as co are allowed, which must reference the Resourcetype metadata.
https://<servername>.<domainname>/ApiServer/scim/v2?filter=(meta.Resourcetype eq “Locality”) or (meta.Resourcetype sw “D”)
The result can contain a list of objects of different types, but the number of returned elements must not exceed 10,000 for load and performance reasons. Otherwise an error message of type tooMany is returned. The search condition should be refined and the result should be more restricted.
Endpoint URL requests
The SCIM 2.0 specification provides for optional filter, attributes, count, and startIndex parameters for requests to the endpoints defined by /ResourceTypes. Requests with the ID of a concrete object (the URL contains the id of the object) can have the excludedAttributes and attributes parameters. The SCIM plugin supports these parameters.
Endpoint requests return a list of all elements (or all elements matching the filter). This allows the SCIM client to initiate index-based paging by specifying the desired number of records per page ( count and startIndex parameters).
Example: Endpoint request
Example: Request the first 100 elements of an endpoint with paging
Example: Endpoint request with filter
http://<servername>.<domainname>/ApiServer/scim/v2/Person?filter=InternalName co "Y"
Example: Endpoint request with filter and output of two additional properties
http://<servername>.<domainname>/ApiServer/scim/v2/Person?filter=InternalName co "Y"&attributes=ExitDate,TechnicalEntryDate
Example: Endpoint request for an object
Example: Endpoint request for specific properties of an object
The tasks queued in the DBQueue are the result of triggering, modifications to configuration parameters (for example, changes to a configuration parameter concerning inheritance) or running scheduled tasks. The DBQueue Processor processes tasks in the DBQueue. The DBQueue Processor uses several slots for running tasks in parallel. Internal tasks are processed by the Database Agent Service. Ensure that the Database Agent Service is installed and configured.
Detailed information about this topic