4 mins read

Automated User Provisioning

Elevate user management and authorization capabilities by provisioning users automatically (Just In Time) from third-party Identity Providers to Identity Pools.

Provisioning Users Just In Time

Organizations that utilize third-party Identity Providers to sign in to Cloudentity platform or web applications protected by the Cloudentity authorization server may enable automatical user provisioning to Identity Pools for:

  • Unified User Representation: Establish a comprehensive view of all users in one centralized location, irrespective of whether the users authenticate locally or via third-party Identity Providers. This facilitates greater visibility into all users interacting with applications or the Cloudentity admin portal.

  • Attribute Augmentation: Enhance user attributes with locally stored identity-related data such as additional attributes, permissions, roles, and relationships. This enhancement fosters improved authorization decisions and local assignment of user roles, permissions, or entitlements.

  • Operational Attribute Capture: Track operational attributes at the user level, such as the last authentication time, even for users utilizing external IDPs. This helps in maintaining an accurate and updated record of user activity and interactions.

  • Hybrid Authentication Support: Leverage the ability to offer hybrid authentication where the first factor is provided by the IDP, and the second factor is orchestrated by Cloudentity. This approach enables more robust and secure authentication capabilities, particularly with regards to the second factor.

Just In Time User Provisioning

How Automated User Provisioning Works

sequenceDiagram autonumber participant user as User participant app as Application participant acp as Cloudentity participant tpp as Third Party Identity Provider
with provisioning Enabled user->>app: Access Note over user, app: The user accesses the application
and selects the Sign In button app->>acp: /authorize acp->>user: Redirect user to sign-in page user->>tpp: Authenticate with TPP IDP acp->>user: Redirect back to application rect rgb(191, 223, 255) acp->>acp: Lookup User by Federation Identifier alt User found acp->>acp: Update Provisioned Attributes else User not found acp->>acp: List Users by Correlation Identifier Note over acp, acp: Cloudentity checks for account linking if there are accounts
with the the correlated attributes (for example, with the same email) in any TPP IDPs acp->>acp: Create user in Identity Pool or link accounts acp->>acp: Track Audit Event end end

The above diagram illustrates when and how automated user provisioning takes place.

  1. The user accesses the application and selects the sign in button.

    The application can be the Cloudentity platform itself.

  2. The application sends a request to the Cloudentity OAuth /authorize endpoint.

  3. The user is redirected to the login page.

  4. The user selects a third party Identity Provider and authenticates themselves.

  5. The user gets redirected back to the application.

  6. Cloudentity looks up the user by the federation identifier.

    The process gets much faster once the user authenticates at least one.

    The federation identifier is a hashed IDP identifier : original IDP subject (sub).

  7. If the user is found, their provisioned attributes are updated.

  8. If the user is not found, all users are listed by the correlation identifier to cover account linking scenarios.

    Cloudentity checks for any users existing with the corellated identifier to prevent the situation when there would be two accounts created coming from different IDPs but with the same, for example, email address.

    If the corellation is found, the user’s provisioned attributes get updated.

  9. If no correlation is found, the user account is automatically created in the configured Identity Pool.

  10. Audit event is sent.

The audit events are sent on user creation, update, or failure to provision the user.

Email/Phone Verification

During Identity Pool user registration, the user provides their email/phone number that needs to be verified. For example, consider the part of the Create User API payload schema:

"verifiable_addresses": [
      "address": "string",
      "address_lc": "string",
      "created_at": "2019-08-24T14:15:22Z",
      "id": "string",
      "preferred_contact_method": "sms",
      "status": "active",
      "tenant_id": "default",
      "type": "mobile",
      "updated_at": "2019-08-24T14:15:22Z",
      "user_id": "string",
      "user_pool_id": "default",
      "verified": true,
      "verified_at": "2019-08-24T14:15:22Z"

You can see that the user entity has an Array of verifiable_addresses, where each address is a separate JSON object.

When users get provisioned with their attributes coming from their authentication context, you have an option to control whether their email/phone number needs verification or not. You can configure provisioned attributes in a way where email or phone is used as a value of the user JSON schema’s verifiable_addresses object. To control whether the verified flag is set to true or `false, you can map the email address to:

  • Email/Phone verified: value of the email/phone number is taken from the authentication context and the email/phone is staticly set to verified ("verified": true).

  • Email/Phone uverified: value of the email/phone number is taken from the authentication context and the email/phone is staticly set to unverified ("verified": false).

  • Email/Phone OIDC Discovery: option available for OIDC-based IDPs. The value of the email/phone number is taken from the authentication context and the verified flag is set to the value dynamically discovered from the OIDC standard claim (either email_verified claim or phone_number_verified)

Updated: Jul 19, 2023