A SCIM datasource consumes the web-based API of a SCIM server. The SCIM datasource can be setup to verify credentials, but it is also possible to use it for account management.
To access the SCIM server, the connection settings that specify hostname, port and context must be configured, as well as the HTTP-client that is configured with the appropriate server- and client certificates, when needed.
The SCIM data-sources supports SCIM version 1.1 and 2.0.
It is recommended to use SCIM 2.0 when possible, it contains a richer feature set for account and credential management.
SCIM 1.1 support account retrieval and credential verification. It also support account creation and updates, but is limited to the PUT operation, which means that any update of the account means a full retrieval of the account, and then a PUT operation to set it back. If the backend fails to return all values this may cause inconsistencies in the backend data.
Special care should be taken with the password, since it should never be returned on a GET, it must not be overwritten if not set during PUT.
The SCIM 1.1 data source is configured by creating an http client and adding it to the scim configuration.
SCIM 1.1 only support filter queries to be sent via GET. This is inappropriate when queying for a user and password to match. Therefore the SCIM 1.1 client in Curity support the credential query to be executed as a SCIM 2.0 search query using POST. If the backend can support this it is recommended to enable that setting to avoid the risk of password being caught by proxies.
See the developer guide for details on how the scim 1.1 data source operates.
Create an http client that can connect to your SCIM backend.
SCIM 2.0 is a protocol for CRUD operations of users and other resources. It consists of two parts, the protocol for the CRUD operations and a schema for defining a resource. They are defined in RFC 7643 and RFC 7644.
Curity Identity Server can use the User endpoint of SCIM 2.0 to provide credential management and as a source of attributes.
To use a SCIM 2.0 web service, web-service-settings needs to be configured. This is where you set things like hostname context, tls-settings and such.
See Http Clients for more details.
When using a SCIM 2.0 data source to verify credential using a credential manager, Curity Identity Server use a POST request to the /Users/.search endpoint to find the user account and verify the credentials. The filter can be configured by setting verify-password-filter, the default is userName eq ":username" and password eq ":password" and active eq true. As you can see, the default filter searches for a user with matching username and password, and with the active flag set. If this is not sufficient, the filter string can be changed. To read more about filters, see SCIM 2.0 Filtering.
userName eq ":username" and password eq ":password" and active eq true
When using the SCIM 2.0 data source to append attributes or with an account manager, there are multiple filters to set to customize the search queries.
scim-attribute-to-fetch is a specific list of attribute names to fetch from the server. All other attributes will be excluded, except the ones marked as return:always in RFC 7643.
scim-excluded-attribute-to-fetch is a list of attributes that will be excluded from the result.
To configure the way Curity Identity Server finds the user account, the search-filter can be configured. The default value is userName eq :username. As an example, you can configure the filter to be userName eq :username or email.value eq :username if your not sure if the username in session is the username or the email address of the user.
userName eq :username
userName eq :username or email.value eq :username
Curity Identity Server supports using the HTTP PATCH method to update resources. This is an optional method, and not all servers support it. For that reason, Curity Identity Server queries the /ServiceProviderConfig endpoint of the server to find out if PATCH is supported. This query happens on each reconfiguration.
If you are certain of the capabilities of your server, you can disable this query by setting supports-http-patch to true or false.
If PATCH is not supported by the server, Curity Identity Server needs to make two request for an update. One GET to get the full current account, and one PUT to replace the account with the updated information.
<verify-password-filter>userName eq ":username" and password eq ":password"</verify-password-filter>
<search-filter-mail>emails.value eq ":email"</search-filter-mail>
<search-filter-phone>phones.value eq ":phone"</search-filter-phone>
<search-filter>userName eq ":username"</search-filter>
<verify-password-filter>(userName eq ":username" or emails eq ":username") and password eq ":password" and active eq true</verify-password-filter>