Additional Endpoint Allowing for SCIM Client Entity Removal when Provisioned Users exist in FusionAuth (externalId)

[jobannon]

Problem

Currently, if I setup a SCIM Client Entity, and use this integration to create users (that is, FusionAuth is the SCIM Server), each user created will have an externalId which creates a join between FusionAuth the SCIM server and the SCIM client.

FusionAuth currently validates if an [scim client] entity is "in-use" (that is, the SCIM client entity, user, and eternalId are linked). If so, this [scim client] entity can not be removed until the FusionAuth user is removed. Functionally this externalId acts as a foreign key to the SP/SCIM client for this user. If this link is severed (that is the [scim client] entity removed from FusionAuth) then the user will be orphaned (in a way).

Solution

Allowing an [scim client] entity to be removed but blocking when the SCIM Client Entity has a user created (externalId) makes sense. It prevents accidentally completely "messing up" a SCIM integration in production. However, FusionAuth should offer a seperate API endpoint to remove [scim client] entities, even when attached/connected to a user in FusionAuth via SCIM (with all disclaimers provided in the API doc - ie - this action is very dangerous and destructive).

Perhaps something like

//...
DELETE `<host>/api/entity-scim/<entityId>
//...

This would offer a completely discrete endpoint that would not allow for inadvertent destruction of SCIM connections.

Alternatives/workarounds

• Remove all FusionAuth users that have an externalId to the specific client entity (SCIM connection) in FusionAuth.
  • These users cannot be searched for in FusionAuth itself, but would have to be identified in the other side of the SCIM connection.
  • Once these users have been removed, the FusionAuth [scim client] entity can be removed.

Additional context

https://inversoft.slack.com/archives/C03P8K9R69Z/p1702674277517269

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.

[robotdan]

This behavior is by design, but perhaps something we should revisit.

We did not want to make it easy to remove the user mapping from the external SCIM client and the FusionAuth SCIM server.

Because we model the SCIM client and SCIM server using FusionAuth Entities, we did not want to allow you to use the Entity
API to potentially catastrophically affect your SCIM integration so directly. Using the Entity API directly felt too easy, and not the impact to your SCIM integration would not be obvious enough.

In a production sense, there seems to be little reason to every remove this mapping all-together. Perhaps there are some testing use cases, or some production use cases, where you know for sure that you will never ever ever want to reconnect to a specific SCIM client.

If we want to support this use case, we will likely need to add a new SCIM API to permanently delete the mappings from a SCIM client and the FusionAuth SCIM Server. Once this was complete you could then delete the Entity using the Entity API.