SCIM - Protocol v1.1 compliance

The SCIM Protocol is an application level, REST protocol for provisioning and managing identity data on the web.

The protocol supports creation, modification, retrieval and discovery of core identity resources (e.g. users and groups, as well as custom resource extensions). For more details, refer to SCIM:Protocol 1.1.

Note: OneWelcome’s SCIM interface supports the functional behaviour as described below. Sensible queries can be used to incidentally search for users. Structural usage of SCIM filtering as a part of a regular flow in client applications may however have a performance penalty. Therefore this needs to be discussed with OneWelcome to ensure the default indexes allow for sufficient performance and possibly to have OneWelcome create additional indexes.

Caption:

• compliance is indicated
• ✅ indicates compliance
• ✳️ indicates optional features that are supported
• 🔆 indicates optional features that are not supported
• ✖️ indicate non compliance
• semantics for specific fields are described.

Authentication and Authorisation

The OneWelcome SCIM API supports all the authentication methods as described in SCIM:Protocol 1.1 - Authentication and Authorization section.

Access to OneWelcome’s SCIM API can be protected by using one of the following mechanisms:

• OAuth2 bearer token (default).
• Basic authentication using username and password is should be avoided.
• OAuth2 Fine-Grined

In addition to each of these methods, OneWelcome provides the following optional features that can be configured upon request:

• Client certificate authentication;
• IP-filtering to add another layer of security.

When basic authentication is used, the client is authorised to use all the methods on the SCIM user endpoint.

For basic authentication the API detailed description can be found here: link to scim api v1.1 .

When OAuth bearer tokens are used, the authorisations for the client can be limited and are controlled by the OAuth scopes associated with the OAuth access token. The following scope values are used by the SCIM API: SCIM:user:get, SCIM:user:post, SCIM:user:delete, SCIM:user:put, SCIM:user:patch, SCIM:user:query

The v.1.1 API version that is protected with the above scopes is detailed presented here: link to v1.1 secure

Note: The scope value SCIM:user:get is needed to retrieve a known user as per Retrieving a known Resource. The scope value SCIM:user:query is needed to query users as per List/Query Resources.

API

The following table indicates which operations are supported by OneWelcome.

Customers that choose to use OneWelcome's 'multi-branding' capabilities, will be provided with multiple endpoints per brand. Often multi-branding is combined with using multiple segments case in which separate endpoints per required combination of segment and brand are set-up.

Creating Resources

Differences between a user POST (protected with SCIM:user:post scope for OAuth bearer token authorisation) -request and response:

• An ID is added (this is required for updating and deleting the user).
• Meta information is added (of particular interest is the version, which is discussed in the update section).
• In case a User is created, the password value is not returned in the response.

For more details, refer to SCIM:Protocol 1.1 - Creating Resources section.

Updating Resources

The SCIM resources should be updated using PUT (protected with SCIM:user:put scope for OAuth bearer token authorisation) and PATCH (protected with SCIM:user:patch scope for OAuth bearer token authorisation) http methods. The first one method is used for updating all the details for the user and the PATCH method is used for partially update for the user.

Retrieving Resources

For more details, refer to SCIM:Protocol 1:0 - Retrieving Resources section.

• Retrieving a known Resource
  • GET method
  • SCIM:user:get scope for OAuth bearer token authorisation

✅ compliant

• List/Query Resources
  • GET method
  • SCIM:user:query scope for OAuth bearer token authorisation

✅ compliant

• Filtering
  • Filtering using GET method and filter query sent as query param
    • Filtering is supported, with a few limitations and it can be done with multiple attribute operators (presented in the below table) concatenated using AND or OR operators. The attribute operators will be put on filter query param. Also the filtering can be done based on count, startIndex, sortOrder and attributes. Example of filtering (query params values):
      • fliter: emails.value co "email" OR username eq "username" AND name.familyName eq "User_Family_ Name" OR name.middle eq "User_Middle_Name" AND (age gt "16" AND age lt "50")
      • count: 10
      • startIndex: 1
      • sortOrder: ascending
      • attributes: emails,phoneNumbers Note: Attributes are separated by comma without any spaces.

Attribute operators