It is possible to use SCIM via the REST HTTP interface to POST, GET, DELETE, PUT and PATCH user and group configurations. This section will cover the schemas used to create, update and remove users and groups, as well as the limitations when using SCIM for
.
For more information regarding the specifications for SCIM, please see RFC: https://tools.ietf.org/html/rfc7643
For information regarding the API endpoints, please see RFC: https://tools.ietf.org/html/rfc7644#section-3.2
Note | ||
---|---|---|
| ||
When importing the user configurations into desktop. or when upgrading , the users will be disabled after the import operation or the upgrade. In order to enable the users, you can use PATCH or PUT, a user with attribute active : true. You can also enable the user by ticking the checkbox for the users you want to enable from the User tab in Access Controller on theWhen creating a new user from SCIM, the user will be enabled by default. |
These are the limitations for using SCIM instead of the
desktop.- Only users with write access for application Access Controller should be able to Add, update and delete users or groups.
- A user can only be created once using the HTTP method POST
- The password attribute is not mandatory when you create a user with POST , however the user will not be able to login to the desktop without to without a password.
- All user details can be modified except the username.
- The users assigned group can only be updated using the HTTP method PUT
- When using PUT to assign a user's group, no default group will be selected.
- You can only POST an access group with same name one time, the group name can not be changed.
It is not possible to set or change the applications connected to the access group using the HTTP methods available via SCIM, this is only possible using the desktop.
Custom Schema
has an additional schema for the "User" resource. The Schema URI for it is:
...
The following attributes are defined:
successor
: The successor user takes over all configs when the current user is removed.value:
The identifier of the successor user.Info title Example 71a36bb7-816f-460d-b580-3bd9352b0953
display:
A human-readable name, primarily used for display purposes. It is read-only.
validityPeriod
: The validity period of a user. Format is:yyyy-mm-ddThh:mm:ss
from
: The "DateTime" the user should be valid from.Info title Example 2021-03-18T23:00:00Z
to:
The "DateTime" the user should be valid to.Info title Example 2021-03-23T22:59:59Z
Note title Note The
to
field should always be greater or equal tofrom
field.
User related APIs
This section will cover all the REST HTTP APIs that are used for user related operations.
...
You can use this to create a user:
Info | ||
---|---|---|
| ||
The schemas and userName fields as shown below are mandatory. They must be filled in. The rest of the fields are optional |
...
You can use this to update all the values for a user:
Info | ||
---|---|---|
| ||
The schemas and userName fields as shown below are mandatory. They must be filled in. The rest of the fields are optional |
...
You can use this to update specific values for a user:
Info | ||
---|---|---|
| ||
The schemas, Operations, op and value fields as shown below are mandatory. They must be filled in. The rest of the fields are optional |
...
You can use this to create a group:
Info | ||
---|---|---|
| ||
The schemas and userName fields as shown below are mandatory. They must be filled in. The rest of the fields are optional |
...
You can use this to update a group:
Info | ||
---|---|---|
| ||
The schemas and userName fields as shown below are mandatory. They must be filled in. The rest of the fields are optional |
...