The IAM server has a RESTful API that is used to manage users, change their personal information, add or remove them from a group, add Open ID Connect accounts, x509 certificates, ssh keys, ecc.
The API may be accessed through an active web session within the application or through authorizing a client application through OAuth. The SCIM protocol, in fact, does not define a scheme for authentication and authorization therefore implementers are free to choose mechanisms appropriate to their use cases. All examples assume OAuth2 bearer token; e.g.
GET /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1
Host: example.com
Authorization: Bearer h480djs93hd8
The SCIM protocol specifies well known endpoints and HTTP methods for managing Resources defined in the core schema i.e., User and Group Resources correspond to /Users and /Groups respectively.
IAM SCIM Endpoints
IAM maps User and Group resource endpoints to:
/scim/Users
/scim/Groups
For each endpoint, the following methods are allowed:
HTTP Method
Description
GET
Retrieves a complete or partial Resource.
POST
Create new Resource or bulk modify Resources.
PUT
Replace completely a Resource.
PATCH
Modifies a Resource with a set of specified changes (partial update).
DELETE
Deletes a Resource.
GET /scim/Users/{id}
Retrieves all the information about the user identified by id and returns results in application/json.
Requires ROLE_ADMIN or scope scim:read.
GET http://localhost:8080/scim/Users/2cb10ac5-5b1a-47a0-8f60-48995999f18d
Successful Resource creation is indicated with a 201 ("Created") response code. Upon successful creation, the response body contains the newly created User.
SCIM defines a standard set of operations that can be used to filter, sort, and paginate response results. The operations are specified by adding query parameters to the Resource's endpoint.
Pagination parameters can be used together to "page through" large numbers of Resources. Pagination is not session based so clients must never assume repeatable results.
The following table describes the URL pagination parameters.
Parameter
Description
Default
startIndex
The 1-based index of the first search result.
1
count
Non-negative Integer. Specifies the desired maximum number of search results per page; e.g., 10.
None.
The following table describes the query response pagination attributes.
Element
Description
itemsPerPage
Non-negative Integer. Specifies the number of search results returned in a query response page; e.g., 10.
totalResults
Non-negative Integer. Specifies the total number of results matching the client query; e.g., 1000.
startIndex
The 1-based index of the first result in the current set of search results; e.g., 1.
The below example returns the first 10 users (implicit startIndex as 1):
The details of the returned users can be reduced/filtered by specifying the needed attribute(s). The below example returns only the userName for all Users:
GET http://localhost:8080/scim/Users?attributes=userName
PUT performs a full update. Clients should retrieve the entire resource and then PUT the desired modifications as the operation overwrites all previously stored data. A successful PUT operation returns a 200 OK response code and the entire resource within the response body.
Example of changing the userName from john_lennon to j.lennon and setting active as true:
GET http://localhost:8080/scim/Users/e380b4e3-7b63-47c2-b156-3699be9ebcfe
PATCH enables consumers to send only the attributes requiring modification, reducing network and processing overhead. Attributes may be deleted, replaced, merged, or added in a single request. The body of a PATCH request MUST contain a partial resource with the desired modifications. The server MUST return either a 200 OK response code and the entire Resource within the response body, or a 204 No Content response code and the appropriate response headers for a successful PATCH request.
The following example shows how to replace the userName:
Example: Client attempt to retrieve the previously deleted User:
GET /scim/Users/4380e98c-02f2-4d10-85ba-9fbbdb819ed8
{
"status": "404",
"detail": "No user mapped to id '4380e98c-02f2-4d10-85ba-9fbbdb819ed8'",
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:Error"
]
}
GET /scim/Groups/{id}
Retrieves all the information about the group identified by id and returns results in application/json.
Requires ROLE_ADMIN or scope scim:read.
GET /scim/Groups/c617d586-54e6-411d-8e38-64967798fa8a
Successful Resource creation is indicated with a 201 ("Created") response code. Upon successful creation, the response body contains the newly created User.
PUT performs a full update. Clients should retrieve the entire resource and then PUT the desired modifications as the operation overwrites all previously stored data. A successful PUT operation returns a 200 OK response code and the entire resource within the response body.
Example of replacing group with a different displayName:
Example: Client attempt to retrieve the previously deleted User:
GET /scim/Groups/5bae2407-08e3-4171-b180-4b4a0196e7b6
{
"status": "404",
"detail": "No group mapped to id '5bae2407-08e3-4171-b180-4b4a0196e7b6'",
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:Error"
]
}