Skip to main content

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 SecureAuth platform or web applications protected by the SecureAuth authorization server may enable automatic 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 SecureAuth 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 SecureAuth. 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

How_Automated_User_Provisioning_Works.svg

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 SecureAuth platform itself.

  2. The application sends a request to the SecureAuth 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. SecureAuth 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.

    SecureAuth 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)

In this section: