I'm a SCIM newbie.
In SCIM work flow, I'm just curious how to create new user on service provider side. If I create new user into local user table on service provider side, and then send a SCIM post user request. This request might fail due to several reasons, ex: network disconnect, service shutdown, data validation fail, etc.
So I plan to use SCIM api on service provider side to create new user. The work flow will looks like below Desgin#1.
The Desgin#2 I think it's incorrect, because I can find some problme will occur in this design like race condition.
Is my conception correct?
(1) Design#1: I intend to use this. All user operations are performed by IdP side.
I can avoid some problem like race condition.
┌───────────────────┐ ┌───────────────────────┐
│ │ │ │
│ SCIM IdP Side │ │ Service Provider Side │
│ │ │ │
│ (ex: Okta, Azure )│ │ (ex: my website) │
│ │ │ │
│ [IdP] │ │ [SP] │
│ │ │ │
└────────┬──────────┘ └────────────┬──────────┘
│ │
│ │
│ │
│◄─────────────────────────────────────┤
│ (1) POST USER Through SCIM Protocol │
│ │
│ │
│ │
│ │
│ │
├─────────────────────────────────────►│
│ (2) IdP created successfully, │
│ got by SP and the create │
│ user entry in SP's database │
│ │
│ Also notify other SP by SCIM │
│ protocol(new user created) │
▼ ▼
(2) Design#2: I think this will cause race conditon, once we have lots of SP resouce creating
┌───────────────────┐ ┌───────────────────────┐
│ │ │ │
│ SCIM IdP Side │ │ Service Provider Side │
│ │ │ │
│ (ex: Okta, Azure )│ │ (ex: my website) │
│ │ │ │
│ [IDP] │ │ [SP] │
│ │ │ │
└────────┬──────────┘ └────────────┬──────────┘
│ │
│ ├────────┐
│ │ │ (1) SP create new user in
│ │ │ local Database
│ │ │
│ │ │
│ │ │
│ │ │
│◄─────────────────────────────────────┤◄───────┘
│ (2) After user is created locally, │
│ POST USER Through SCIM Protocol │
│ to remote IdP Side. │
│ │
│ │
├─────────────────────────────────────►│
│ (3) Also notify other SP by SCIM │
│ protocol(new user created) │
▼ ▼
You seem to be familiar with SAML terminology and are getting it mixed up with SCIM. To be fair they are related with some shared wording, but without reading the RFC to be 100% accurate, it can be explained in other words that might help straighten it out.
I think of a simple 1:1 SCIM relationship as a Directory Service and a Downstream Application. As I say, these are not part of the RFC but aid in understanding.
It's the responsibility of the Directory Service to hold user's identity and personal information. Because of the nature of this information, they are also often Identity Providers (Okta, AAD), but not necessarily.
When an integration between a Directory Service and a Downstream Application (using SCIM) is set up, the normal flow of user information is one way.
This is important.
Things manage users in the Directory Service. This can be any CRUD operation, and once completed in it's own database (the source of the truth about the user), the SCIM web-based calls will be made to provision, edit, or delete the user in the downstream application.
The SCIM protocol does not define the specific requests that need to be made. For example to create a new user in the downstream application, the identity service must first check to see if the user already exists and act appropriately. Something like this would be a sensible implementation:
Depending on your application, you may not allow any user management at all, and the users are simply managed exclusively by the SCIM protocol. This is totally fine. However, it gets more complex if you;
If either of these things are the case then you must take special efforts to block the users or administrators from changing fields that SCIM is responsible for. There is no automatic triggering for an application to tell the directory service that a change has occurred.
While services like Okta allow for bulk importing from a downstream application back into itself, this is a chosen implementation and not really what SCIM was intended for in this scenario.
In summary: Directory Services are the definitive source for your user information. You will get user data from this service, and will not supply data to it via SCIM, or be the trigger for creating users from your application.
Hope that explains things a bit.