From 052f65ca42f79c25bbf8a2ba345c300dc79216f3 Mon Sep 17 00:00:00 2001 From: Dan Moore Date: Thu, 31 Aug 2023 08:35:50 -0600 Subject: [PATCH 1/9] Corrected grammar, changed from list to sentence --- site/docs/v1/tech/shared/_scim-limits.adoc | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/site/docs/v1/tech/shared/_scim-limits.adoc b/site/docs/v1/tech/shared/_scim-limits.adoc index bcc90912b7..b5cd4aa9f2 100644 --- a/site/docs/v1/tech/shared/_scim-limits.adoc +++ b/site/docs/v1/tech/shared/_scim-limits.adoc @@ -1,6 +1,4 @@ -The current SCIM implementation does not support: - -* Bulk operations +The current SCIM implementation does not support bulk operations. Bulk API operations are available via link:/docs/v1/tech/apis/[FusionAuth APIs], but are not currently supported via SCIM compatible endpoints. If this functionality is required, please file a https://github.com/fusionauth/fusionauth-issues/issues[GitHub issue] explaining your use case. @@ -15,6 +13,6 @@ Either works. The correct choice depends on if you want to do the processing wit While it is not enforced, or a hard limitation, it is recommended to configure at most one SCIM server per tenant. -While you can have multiple SCIM servers per configured within one tenant, at the end of the day you only have one user data store per tenant. +While you can have multiple SCIM servers configured within one tenant, at the end of the day you only have one user data store per tenant. Conflicts with creation, updates and deletion could happen; they won't be automatically resolved by FusionAuth. If you need to use multiple SCIM servers, ensure your clients can handle such conflicts. From db1fec2593616658a6cb6d5c42aff1c7d4e3b508 Mon Sep 17 00:00:00 2001 From: Dan Moore Date: Thu, 31 Aug 2023 08:44:01 -0600 Subject: [PATCH 2/9] Add more color to the scim tenant limitations. --- site/docs/v1/tech/shared/_scim-limits.adoc | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/site/docs/v1/tech/shared/_scim-limits.adoc b/site/docs/v1/tech/shared/_scim-limits.adoc index b5cd4aa9f2..a91f9fa1bc 100644 --- a/site/docs/v1/tech/shared/_scim-limits.adoc +++ b/site/docs/v1/tech/shared/_scim-limits.adoc @@ -11,8 +11,10 @@ You cannot create a FusionAuth Registration for a user provisioned with SCIM. If Either works. The correct choice depends on if you want to do the processing within FusionAuth using a lambda or using an external server. -While it is not enforced, or a hard limitation, it is recommended to configure at most one SCIM server per tenant. +While it is not enforced, or a hard limitation, it is recommended to configure at most one SCIM server per tenant. While you can have multiple SCIM servers configured to provision users in one FusionAuth tenant, at the end of the day you only have one user data store in each tenant. Conflicts with creation, updates and deletion could happen; they won't be automatically resolved by FusionAuth. If you need to use multiple SCIM servers, ensure your clients can handle such conflicts. -While you can have multiple SCIM servers configured within one tenant, at the end of the day you only have one user data store per tenant. - -Conflicts with creation, updates and deletion could happen; they won't be automatically resolved by FusionAuth. If you need to use multiple SCIM servers, ensure your clients can handle such conflicts. +Okay, okay, you want multiple SCIM clients to provision users into a single FusionAuth tenant. Let's talk about the complexities. Imagine you have an Okta SCIM client provisioning users into a FusionAuth tenant and an Azure AD SCIM client provisioning users into the same tenant. Issues with this approach include: +* The user and group lambdas would have to be smart enough to handle the mapping for both sources. You'd include logic differentiating between an user from Okta and a user from Azure AD, and handle the fields differently.You don't get information from the incoming SCIM request about the source, but you might be able to examine an email domain or a marker attribute to determine where the user was coming from. +* Collisions of users will not be handled by FusionAuth. In particular, if the Okta SCIM client created 'richard@example.com' in the tenant, then later the Azure AD SCIM client tried to create 'dan@example.com', there would be a failure in the second case. One workaround would be for the lambda to be smart enough to resolve the collision. It might adding a suffix or prefix to make the email address unique. +* Deletion requests from the Okta SCIM client could delete users created by the Azure AD server and vice versa. +* the bearer access token can be different, but must have the same lifetime, since that is configured at the Entity Type level. From 36bf1a785e6b3356071a45da3e54d8ffa2e73602 Mon Sep 17 00:00:00 2001 From: Dan Moore Date: Thu, 31 Aug 2023 08:44:38 -0600 Subject: [PATCH 3/9] Add more color to the scim tenant limitations, part 2. --- site/docs/v1/tech/shared/_scim-limits.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/site/docs/v1/tech/shared/_scim-limits.adoc b/site/docs/v1/tech/shared/_scim-limits.adoc index a91f9fa1bc..fc3c8d3132 100644 --- a/site/docs/v1/tech/shared/_scim-limits.adoc +++ b/site/docs/v1/tech/shared/_scim-limits.adoc @@ -16,5 +16,5 @@ While it is not enforced, or a hard limitation, it is recommended to configure a Okay, okay, you want multiple SCIM clients to provision users into a single FusionAuth tenant. Let's talk about the complexities. Imagine you have an Okta SCIM client provisioning users into a FusionAuth tenant and an Azure AD SCIM client provisioning users into the same tenant. Issues with this approach include: * The user and group lambdas would have to be smart enough to handle the mapping for both sources. You'd include logic differentiating between an user from Okta and a user from Azure AD, and handle the fields differently.You don't get information from the incoming SCIM request about the source, but you might be able to examine an email domain or a marker attribute to determine where the user was coming from. * Collisions of users will not be handled by FusionAuth. In particular, if the Okta SCIM client created 'richard@example.com' in the tenant, then later the Azure AD SCIM client tried to create 'dan@example.com', there would be a failure in the second case. One workaround would be for the lambda to be smart enough to resolve the collision. It might adding a suffix or prefix to make the email address unique. -* Deletion requests from the Okta SCIM client could delete users created by the Azure AD server and vice versa. +* Update or deletion requests from the Okta SCIM client could modify users created by the Azure AD server and vice versa. * the bearer access token can be different, but must have the same lifetime, since that is configured at the Entity Type level. From 63edf724e1122d219381fb6e62a763fad6126c1b Mon Sep 17 00:00:00 2001 From: Dan Moore Date: Thu, 31 Aug 2023 08:48:58 -0600 Subject: [PATCH 4/9] cleaned up 'adding registrations' inconsistencies --- site/docs/v1/tech/core-concepts/scim.adoc | 2 +- site/docs/v1/tech/shared/_scim-limits.adoc | 7 +------ 2 files changed, 2 insertions(+), 7 deletions(-) diff --git a/site/docs/v1/tech/core-concepts/scim.adoc b/site/docs/v1/tech/core-concepts/scim.adoc index 5c4ce07550..92f54d365d 100644 --- a/site/docs/v1/tech/core-concepts/scim.adoc +++ b/site/docs/v1/tech/core-concepts/scim.adoc @@ -195,7 +195,7 @@ With SCIM, users are provisioned. They are not registered for applications withi Options to automatically add a registration to a new user include: * Listen for the link:/docs/v1/tech/events-webhooks/events/user-create-complete[user.create.complete] webhook and add the registration using an API call on the receiver. -* Make an API call from the link:/docs/v1/tech/lambdas/scim-user-response-converter[user response complete lambda]. Ensure this idempotent as the lambda will be called any time the user is updated as well. +* Make an API call registering the user to an application from the link:/docs/v1/tech/lambdas/scim-user-response-converter[SCIM User Response Converter lambda] which is called after the user is created. Ensure this idempotent as the lambda will be called any time the user is updated as well. * If you enable self service registration for your application, and the user logs in to the application, they will be automatically registered for the application. link:/docs/v1/tech/core-concepts/registrations#registrations-and-self-service-registration[Learn more]. == SCIM Client Authentication diff --git a/site/docs/v1/tech/shared/_scim-limits.adoc b/site/docs/v1/tech/shared/_scim-limits.adoc index fc3c8d3132..24cbf324fc 100644 --- a/site/docs/v1/tech/shared/_scim-limits.adoc +++ b/site/docs/v1/tech/shared/_scim-limits.adoc @@ -4,12 +4,7 @@ Bulk API operations are available via link:/docs/v1/tech/apis/[FusionAuth APIs], The list operation is limited to 10,000 users if you are using the Elasticsearch search engine. This https://github.com/FusionAuth/fusionauth-issues/issues/494[GitHub issue] discusses this limitation. -You cannot create a FusionAuth Registration for a user provisioned with SCIM. If you need to register the user for one or more Applications, you have a few options. You may: - -* use the link:/docs/v1/tech/lambdas/scim-user-request-converter[SCIM User Request Converter Lambda]. -* use the link:/docs/v1/tech/events-webhooks/events/user-create-complete[`user.create.complete` webhook]. - -Either works. The correct choice depends on if you want to do the processing within FusionAuth using a lambda or using an external server. +You cannot create a FusionAuth Registration for a user provisioned with SCIM directly during the provisioning process. See link:/docs/v1/tech/core-concepts/scim#adding-registrations[Adding Registrations] for workarounds. While it is not enforced, or a hard limitation, it is recommended to configure at most one SCIM server per tenant. While you can have multiple SCIM servers configured to provision users in one FusionAuth tenant, at the end of the day you only have one user data store in each tenant. Conflicts with creation, updates and deletion could happen; they won't be automatically resolved by FusionAuth. If you need to use multiple SCIM servers, ensure your clients can handle such conflicts. From 3d2360297f429e7872358a2a6f686deca124ffc6 Mon Sep 17 00:00:00 2001 From: Dan Moore Date: Thu, 31 Aug 2023 11:15:44 -0600 Subject: [PATCH 5/9] fixing formatting --- site/docs/v1/tech/shared/_scim-limits.adoc | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/site/docs/v1/tech/shared/_scim-limits.adoc b/site/docs/v1/tech/shared/_scim-limits.adoc index 24cbf324fc..324ee25be7 100644 --- a/site/docs/v1/tech/shared/_scim-limits.adoc +++ b/site/docs/v1/tech/shared/_scim-limits.adoc @@ -8,8 +8,11 @@ You cannot create a FusionAuth Registration for a user provisioned with SCIM dir While it is not enforced, or a hard limitation, it is recommended to configure at most one SCIM server per tenant. While you can have multiple SCIM servers configured to provision users in one FusionAuth tenant, at the end of the day you only have one user data store in each tenant. Conflicts with creation, updates and deletion could happen; they won't be automatically resolved by FusionAuth. If you need to use multiple SCIM servers, ensure your clients can handle such conflicts. -Okay, okay, you want multiple SCIM clients to provision users into a single FusionAuth tenant. Let's talk about the complexities. Imagine you have an Okta SCIM client provisioning users into a FusionAuth tenant and an Azure AD SCIM client provisioning users into the same tenant. Issues with this approach include: +Okay, okay, you want multiple SCIM clients to provision users into a single FusionAuth tenant. Let's talk about the complexities. Imagine you have an Okta SCIM client provisioning users into a FusionAuth tenant and an Azure AD SCIM client provisioning users into the same tenant. + +Issues with this approach include: + * The user and group lambdas would have to be smart enough to handle the mapping for both sources. You'd include logic differentiating between an user from Okta and a user from Azure AD, and handle the fields differently.You don't get information from the incoming SCIM request about the source, but you might be able to examine an email domain or a marker attribute to determine where the user was coming from. -* Collisions of users will not be handled by FusionAuth. In particular, if the Okta SCIM client created 'richard@example.com' in the tenant, then later the Azure AD SCIM client tried to create 'dan@example.com', there would be a failure in the second case. One workaround would be for the lambda to be smart enough to resolve the collision. It might adding a suffix or prefix to make the email address unique. +* Collisions of users will not be handled by FusionAuth. In particular, if the Okta SCIM client created 'richard@example.com' in the tenant, then later the Azure AD SCIM client tried to create 'richard@example.com', there would be a failure in the second case. One workaround would be for the lambda to be smart enough to resolve the collision. It might adding a suffix or prefix to make the email address unique. * Update or deletion requests from the Okta SCIM client could modify users created by the Azure AD server and vice versa. * the bearer access token can be different, but must have the same lifetime, since that is configured at the Entity Type level. From 9a8760835512c54ecf947398defb91ef4c418ac9 Mon Sep 17 00:00:00 2001 From: Dan Moore Date: Thu, 31 Aug 2023 11:17:13 -0600 Subject: [PATCH 6/9] explained why token lifetimes matter. --- site/docs/v1/tech/shared/_scim-limits.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/site/docs/v1/tech/shared/_scim-limits.adoc b/site/docs/v1/tech/shared/_scim-limits.adoc index 324ee25be7..a138301681 100644 --- a/site/docs/v1/tech/shared/_scim-limits.adoc +++ b/site/docs/v1/tech/shared/_scim-limits.adoc @@ -15,4 +15,4 @@ Issues with this approach include: * The user and group lambdas would have to be smart enough to handle the mapping for both sources. You'd include logic differentiating between an user from Okta and a user from Azure AD, and handle the fields differently.You don't get information from the incoming SCIM request about the source, but you might be able to examine an email domain or a marker attribute to determine where the user was coming from. * Collisions of users will not be handled by FusionAuth. In particular, if the Okta SCIM client created 'richard@example.com' in the tenant, then later the Azure AD SCIM client tried to create 'richard@example.com', there would be a failure in the second case. One workaround would be for the lambda to be smart enough to resolve the collision. It might adding a suffix or prefix to make the email address unique. * Update or deletion requests from the Okta SCIM client could modify users created by the Azure AD server and vice versa. -* the bearer access token can be different, but must have the same lifetime, since that is configured at the Entity Type level. +* The bearer access token used to authenticate each SCIM client can be different, but they must have the same lifetime, since that is configured at the Entity Type level. You couldn't have Okta's credentials be valid for a year but Azure AD's credentials be valid for six months. From b43279ce0d026eb360b8d9b4869f85ddceb67e4b Mon Sep 17 00:00:00 2001 From: Dan Moore Date: Thu, 31 Aug 2023 11:22:45 -0600 Subject: [PATCH 7/9] reworking based on feedback from the PR --- site/docs/v1/tech/shared/_scim-limits.adoc | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/site/docs/v1/tech/shared/_scim-limits.adoc b/site/docs/v1/tech/shared/_scim-limits.adoc index a138301681..d271983a00 100644 --- a/site/docs/v1/tech/shared/_scim-limits.adoc +++ b/site/docs/v1/tech/shared/_scim-limits.adoc @@ -6,13 +6,13 @@ The list operation is limited to 10,000 users if you are using the Elasticsearch You cannot create a FusionAuth Registration for a user provisioned with SCIM directly during the provisioning process. See link:/docs/v1/tech/core-concepts/scim#adding-registrations[Adding Registrations] for workarounds. -While it is not enforced, or a hard limitation, it is recommended to configure at most one SCIM server per tenant. While you can have multiple SCIM servers configured to provision users in one FusionAuth tenant, at the end of the day you only have one user data store in each tenant. Conflicts with creation, updates and deletion could happen; they won't be automatically resolved by FusionAuth. If you need to use multiple SCIM servers, ensure your clients can handle such conflicts. +While it is not enforced, or a hard limitation, it is recommended to configure at most one SCIM client per tenant. While you can have multiple SCIM client configured to provision users in one FusionAuth tenant, at the end of the day you only have one user data store in each tenant. Conflicts with creation, updates and deletion could happen; they won't be automatically resolved by FusionAuth. If you need multiple SCIM clients provisioning users into a single tenant, ensure you handle conflicts. Okay, okay, you want multiple SCIM clients to provision users into a single FusionAuth tenant. Let's talk about the complexities. Imagine you have an Okta SCIM client provisioning users into a FusionAuth tenant and an Azure AD SCIM client provisioning users into the same tenant. Issues with this approach include: -* The user and group lambdas would have to be smart enough to handle the mapping for both sources. You'd include logic differentiating between an user from Okta and a user from Azure AD, and handle the fields differently.You don't get information from the incoming SCIM request about the source, but you might be able to examine an email domain or a marker attribute to determine where the user was coming from. -* Collisions of users will not be handled by FusionAuth. In particular, if the Okta SCIM client created 'richard@example.com' in the tenant, then later the Azure AD SCIM client tried to create 'richard@example.com', there would be a failure in the second case. One workaround would be for the lambda to be smart enough to resolve the collision. It might adding a suffix or prefix to make the email address unique. -* Update or deletion requests from the Okta SCIM client could modify users created by the Azure AD server and vice versa. +* The user and group lambdas would have to include logic to differentiate between a user from Okta and a user from Azure AD and handle the fields differently. The incoming SCIM request does not include information about the source, but you might be able to examine an email domain or a marker attribute to determine where the user was coming from. +* User collisions are not handled by FusionAuth. If the Okta SCIM client created an account for a user with the email address `richard@example.com` in the tenant, then later the Azure AD SCIM client tried to create an account for a user with the email address `richard@example.com`, the second account creation would fail. One workaround would be for the lambda to resolve the collision, for exampley by adding a suffix or prefix to make the email address unique. +* Update or deletion requests from the Okta SCIM client could modify users created by the Azure AD SCIM client and vice versa. * The bearer access token used to authenticate each SCIM client can be different, but they must have the same lifetime, since that is configured at the Entity Type level. You couldn't have Okta's credentials be valid for a year but Azure AD's credentials be valid for six months. From 0f18a201bc73236cf687dbe37a5511188902d2d7 Mon Sep 17 00:00:00 2001 From: Dan Moore Date: Thu, 31 Aug 2023 11:24:06 -0600 Subject: [PATCH 8/9] fixing bulk operations section formatting --- site/docs/v1/tech/shared/_scim-limits.adoc | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/site/docs/v1/tech/shared/_scim-limits.adoc b/site/docs/v1/tech/shared/_scim-limits.adoc index d271983a00..b0bc847758 100644 --- a/site/docs/v1/tech/shared/_scim-limits.adoc +++ b/site/docs/v1/tech/shared/_scim-limits.adoc @@ -1,6 +1,4 @@ -The current SCIM implementation does not support bulk operations. - -Bulk API operations are available via link:/docs/v1/tech/apis/[FusionAuth APIs], but are not currently supported via SCIM compatible endpoints. If this functionality is required, please file a https://github.com/fusionauth/fusionauth-issues/issues[GitHub issue] explaining your use case. +The current SCIM implementation does not support bulk operations using SCIM. Bulk operations on users, such as addition and deletion, are available via link:/docs/v1/tech/apis/[FusionAuth APIs], but are not currently supported via SCIM compatible endpoints. If this functionality is required, please file a https://github.com/fusionauth/fusionauth-issues/issues[GitHub issue] explaining your use case. The list operation is limited to 10,000 users if you are using the Elasticsearch search engine. This https://github.com/FusionAuth/fusionauth-issues/issues/494[GitHub issue] discusses this limitation. From 40835790eb19e8fe8bab42a95cbc10b0880e0a7a Mon Sep 17 00:00:00 2001 From: Dan Moore Date: Thu, 31 Aug 2023 11:25:13 -0600 Subject: [PATCH 9/9] spelling/grammar fixes --- site/docs/v1/tech/shared/_scim-limits.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/site/docs/v1/tech/shared/_scim-limits.adoc b/site/docs/v1/tech/shared/_scim-limits.adoc index b0bc847758..d09ed928f6 100644 --- a/site/docs/v1/tech/shared/_scim-limits.adoc +++ b/site/docs/v1/tech/shared/_scim-limits.adoc @@ -4,13 +4,13 @@ The list operation is limited to 10,000 users if you are using the Elasticsearch You cannot create a FusionAuth Registration for a user provisioned with SCIM directly during the provisioning process. See link:/docs/v1/tech/core-concepts/scim#adding-registrations[Adding Registrations] for workarounds. -While it is not enforced, or a hard limitation, it is recommended to configure at most one SCIM client per tenant. While you can have multiple SCIM client configured to provision users in one FusionAuth tenant, at the end of the day you only have one user data store in each tenant. Conflicts with creation, updates and deletion could happen; they won't be automatically resolved by FusionAuth. If you need multiple SCIM clients provisioning users into a single tenant, ensure you handle conflicts. +While it is not enforced, or a hard limitation, it is recommended to configure at most one SCIM client per tenant. While you can have multiple SCIM clients configured to provision users in one FusionAuth tenant, at the end of the day you only have one user data store in each tenant. Conflicts with creation, updates and deletion could happen; they won't be automatically resolved by FusionAuth. If you need multiple SCIM clients provisioning users into a single tenant, ensure you handle conflicts. Okay, okay, you want multiple SCIM clients to provision users into a single FusionAuth tenant. Let's talk about the complexities. Imagine you have an Okta SCIM client provisioning users into a FusionAuth tenant and an Azure AD SCIM client provisioning users into the same tenant. Issues with this approach include: * The user and group lambdas would have to include logic to differentiate between a user from Okta and a user from Azure AD and handle the fields differently. The incoming SCIM request does not include information about the source, but you might be able to examine an email domain or a marker attribute to determine where the user was coming from. -* User collisions are not handled by FusionAuth. If the Okta SCIM client created an account for a user with the email address `richard@example.com` in the tenant, then later the Azure AD SCIM client tried to create an account for a user with the email address `richard@example.com`, the second account creation would fail. One workaround would be for the lambda to resolve the collision, for exampley by adding a suffix or prefix to make the email address unique. +* User collisions are not handled by FusionAuth. If the Okta SCIM client created an account for a user with the email address `richard@example.com` in the tenant, then later the Azure AD SCIM client tried to create an account for a user with the email address `richard@example.com`, the second account creation would fail. One workaround would be for the lambda to resolve the collision, for example by adding a suffix or prefix to make the email address unique. * Update or deletion requests from the Okta SCIM client could modify users created by the Azure AD SCIM client and vice versa. * The bearer access token used to authenticate each SCIM client can be different, but they must have the same lifetime, since that is configured at the Entity Type level. You couldn't have Okta's credentials be valid for a year but Azure AD's credentials be valid for six months.