SCIM Connector - User Lifecycle and Access Control

User Lifecycle and Group Provisioning Rules

User Provisioning Life Cycle States

• New User Ingestion: New accounts are created in Fluent Order Management with assigned roles provided they are new to the platform and every role assigned inside the IdP maps cleanly to a corresponding role in Fluent.
• User Attribute Updates: Existing accounts update their assigned profiles and roles provided that all security roles assigned in the IdP possess a respective matching role in Fluent.
• Unmapped Role Restrictions: Users are entirely blocked from creation or profile modification updates if they carry no roles within the IdP, or if the synchronization service identifies any role that lacks a respective counterpart inside Fluent.
• Deactivation Mechanics: Deactivating a user within the IdP hides all corresponding user roles within Fluent Order Management and flips the platform user status to `Inactive`. Reactivating the account inside the IdP restores the user’s previous roles. Accounts containing zero active roles automatically default to an `Inactive` state inside Fluent.
• Deletion Mechanics: Deleting a user profile within the IdP automatically triggers a account deactivation inside Fluent Order Management.

Group Membership Provisioning Constraints

• Group Assignment Addition: Adding a user to an IdP group grants the user all associated group-level roles in addition to their directly assigned personal roles.
• Group Assignment Removal: Removing a user from a group strips away the group-specific roles, but leaves directly assigned roles untouched. Example: If Role D is assigned directly to user X, and user X belongs to a group carrying Role D, removing user X from that group leaves Role D active on their personal account.
• Group Attribute Modifications: When an IdP group updates its member lists or internal roles, those configuration changes propagate to all active members, with the exception of any roles assigned directly to individual user accounts.
• Group Role Extensions: Appending a new role to an IdP group pushes that role out to all group members during the next active provisioning cycle.
• Group Member Additions: Assigning a new member to an IdP group instantly provisions them with all roles mapped to that group entity.
• Group Role Reductions: Removing an internal role from an IdP group strips that role from all corresponding group members.
• Group Member Exclusions: Removing a member from an IdP group strips all associated group roles from that specific user.
• Group Entity Deletion: Deleting an entire group configuration removes those group roles across all previous members, leaving only their directly assigned individual account roles intact.

App Role Naming Convention

• `<FLUENT_CONTEXT_TYPE>`: The active user context envelope. Supported types are restricted to: `ACCOUNT`, `RETAILER`, or `AGENT`.
• `<FLUENT_CONTEXT_ID>`: The specific identity token matching the context type. For `RETAILER` contexts, this maps to the primary Retailer ID; for `AGENT` contexts, it resolves to the physical Location ID; for `ACCOUNT` contexts, it defines the parent Account ID string.
• `<FLUENT_ROLE_ID IDP_LOGICAL_ROLE_ID or>`: The functional target value. This represents either a direct native Fluent role value (`FLUENT_ROLE_ID`) or an internal application role defined within the IdP (`IDP_LOGICAL_ROLE_ID`) mapped to change into multiple downstream platform permissions.

Dynamic Role Mapping Configuration

• Execution Order: Dynamic role conversion rules execute immediately before direct role mapping workflows run, ensuring custom roles transform into standard platform permissions prior to finalizing account provisioning.
• Storage Location: The mapping rules reside entirely within the Fluent platform environment as a system setting (not inside the IdP configuration parameters).
• Configuration Key: `fc.connect.scim-connector.provisioning.pipeline.config`

Platform Scope and System Limitations

• Tested Identity Ecosystems: The SCIM connector framework developed by the Fluent team is formally tested and validated only on Azure Active Directory.
• Group Provisioning Restrictions: The service does not support group provisioning endpoints because the Fluent Commerce platform lacks an internal user-group structural concept. No group endpoints adhering to the SCIM protocol are developed as part of this service layer.
• IdP Feature Constraints: The service supports essential core provisioning and user role assignment functions. Because individual IdPs implement proprietary user management behaviors, the connector does not guarantee compatibility with specialized provisioning sub-features, including:
  • Provisioning a group on-demand within Azure Active Directory.
  • Deactivating or reactivating an isolated group entity.
  • Revoking deleted users inside an Azure Active Directory tenant (currently untested).

Provisioning Scenarios Matrix

• IdP Role `X` can represent a direct name-match to a Fluent role, or a logical role name mapped to multiple Fluent roles inside platform settings.
• IdP Role `C` is dynamically configured to map to Fluent roles `F` and `G`.
• IdP Group `G` is configured to map to Fluent roles `M` and `N`.
• Roles `A` and `B` represent invalid or unmapped roles lacking a corresponding entity inside Fluent.

Validation and Error Handling

1{
2    "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
3    "scimType":"mutability",
4    "detail":"Attribute 'id' is readOnly",
5    "status": "400"
6}

Error Messages Reference Matrix

Error Payload Examples

Scenario 1: Invalid Context ID Exception

1{
2  "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
3  "status": "400",
4  "scimType": "roleInvalidContextId",
5  "detail": "Invalid context id, unable to find a match [RETAILER-1000]"
6}

Scenario 2: Invalid Context Type Exception

1{
2  "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
3  "status": "400",
4  "scimType": "roleInvalidContextType",
5  "detail": "Invalid context type, unable to find a match [CONTEXTWRONG]"
6}

Scenario 3: Unmapped Target Role Exception

1{
2  "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
3  "status": "400",
4  "scimType": "roleInvalid",
5  "detail": "Unable to find a matching Fluent role [WRONGROLE]"
6}

Scenario 4: String Convention Parsing Exception

1{
2  "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
3  "status": "400",
4  "scimType": "roleNameConvention",
5  "detail": "Role does’t match the expected naming convention [CONTEXT-WRONG_1_SUPER_ADMIN_USER]"
6}

Scenario 5: Unsupported SCIM Route Request Exception

1{
2  "schemas": [ "urn:ietf:params:scim:api:messages:2.0:Error" ],
3  "status": "501", 
4  "detail": "Not Implemented" 
5}