The FusionAuth SCIM Server currently advertises and allows integrators to create a schema. This schema might suggest to the SCIM client what attributes are required, etc. However, the current implementation of SCIM Server in FusionAuth does not validate the schema before provisioning a user or group.
If you would like to prevent a user/group from being provisioned or modified in FusionAuth, the only current workaround requires an error thrown in the SCIM Request Converter or the SCIM Response Converter. This failure will prevent the action intended by the SCIM Client, however, the message reported back to the client will be vague and indicate a general provisioning error has occurred in a lambda. For example, we might relay an error message that looks like this to a SCIM Client:
StatusCode: InternalServerError Message: Processing of the HTTP request resulted in an exception. Please see the HTTP response returned by the 'Response' property of this exception for details. Web Response: {"detail":"Lambda Id [xxxxxxxxxxxxxxxxxxxxxxxxxx] [LambdaInvocationException] A lambda threw an exception during execution. Consult the event log to determine the root cause.","schemas":["urn:ietf:params:scim:api:messages:2.0:Error"],"status":"500"}. This operation was retried 1 times. It will be retried again after this date: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Note that this is also a 500 status code and error and we could, in theory return a 400 status code and message for validation errors.
The SCIM specification indicates the SCIM server can [optionally(?)] enforce validation (see specification here)
[2](https://datatracker.ietf.org/doc/html/rfc7643#section-2). SCIM Schema
A SCIM server provides a set of resources, the allowable contents of
which are defined by a set of schema URIs and a resource type.
SCIM's schema is not a document-centric one such as with
[[XML-Schema](https://datatracker.ietf.org/doc/html/rfc7643#ref-XML-Schema)]. Instead, SCIM's support of schema is attribute based,
where each attribute may have different type, mutability,
cardinality, or returnability. Validation of documents and messages
is always performed by an intended receiver, as specified by the SCIM
specifications. Validation is performed by the receiver in the
context of a SCIM protocol request (see [[RFC7644](https://datatracker.ietf.org/doc/html/rfc7644)]). For example, a
SCIM service provider, upon receiving a request to replace an
existing resource with a replacement JSON object, evaluates each
asserted attribute based on its characteristics as defined in the
relevant schema (e.g., mutability) and decides which attributes may
be replaced or ignored.
Solution
FusionAuth should allow for validation of the schema and provide enriched error objects back to the end user regarding failure states and validation errors. This may mean that they Errors schema needs to be extended as well, to relay more information about the validation failure to the SCIM Client.
Alternatives/workarounds
If you would like to implement validation login with FusionAuth as the SCIM server, then you can by checking the incoming request in a lambda and throwing an error if the data does not match what you would expect.
IE--
throw new Error('Attribute "name.givenName" missing');
Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.
Problem
The FusionAuth SCIM Server currently advertises and allows integrators to create a schema. This schema might suggest to the SCIM client what attributes are required, etc. However, the current implementation of SCIM Server in FusionAuth does not validate the schema before provisioning a user or group.
If you would like to prevent a user/group from being provisioned or modified in FusionAuth, the only current workaround requires an error thrown in the SCIM Request Converter or the SCIM Response Converter. This failure will prevent the action intended by the SCIM Client, however, the message reported back to the client will be vague and indicate a general provisioning error has occurred in a lambda. For example, we might relay an error message that looks like this to a SCIM Client:
Note that this is also a
500status code and error and we could, in theory return a400status code and message for validation errors.The SCIM specification indicates the SCIM server can [optionally(?)] enforce validation (see specification here)
Solution
FusionAuth should allow for validation of the schema and provide enriched error objects back to the end user regarding failure states and validation errors. This may mean that they Errors schema needs to be extended as well, to relay more information about the validation failure to the SCIM Client.
Alternatives/workarounds
If you would like to implement validation login with FusionAuth as the SCIM server, then you can by checking the incoming request in a lambda and throwing an error if the data does not match what you would expect.
IE--
Additional context
Ticket - 74429
Community guidelines
All issues filed in this repository must abide by the FusionAuth community guidelines.
How to vote
Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.