Feature Description


The primary use-case of ProAuth is to federate with other identity providers. The reason for this design decision is to support modern SaaS application scenarios where enterprise customers expecting to enable single-sign-on with their existing directories and identity providers. However, if this scenario is not applicable for any reasons, ProAuth offers an integrated user store where users and groups can be managed. The user store is the only module which stores user credentials in all other federated scenarios, this is not the case.

Every OIDC compliant identity server can be configured as a federated identity provider. In addition to that, there are further protocols and specific implementations supported.

Often, federated identity providers provide and enforce a second factor on their own. This is fully supported by ProAuth. If this is not the case, or any additional security factor should be checked withing the ProAuth authentication flow, any authentication pipeline can be extended to use additional factors for authentication. Technically, multiple second factor validations could be added to a pipeline, in most cases only one is used.


Most Common Scenarios


The most common scenarios for ProAuth implementations are:

  • Federated IDP / single-sign-on with Azure Active Directory (AAD)
  • Federated IDP / single-sign-on with Active Directory Federation Services (ADFS for on-premises Active Directory)
  • Federated IDP / single-sign-on with any OIDC compliant identity provider (i.e. Octa, Auth0, Google Directory)
  • ProAuth User Store authentication (username / password authentication with login screen)
  • Federated IDP / single-sign-on with social providers (B2C) (Microsoft account, Google account, Facebook account, Twitter account, …)

User data storage


ProAuth stores user information internally in a so called ProAuth user. The data stored comes from the federated identity provider. The user data managed in ProAuth can be extended by adding additional information in the user profile. In addition to that, group memberships can be manually managed in ProAuth (if the federated identity provider is not providing group memberships or if there is a need for additional managed groups).

In federated scenarios, ProAuth only knows about the user after the first login. To prevent that any user can authenticate from a federated directory, the automatic user creation up-on the first login request can be disabled. In this case, the user has to be created upfront by either using an invitation flow or synchronizing the directory with ProAuth. User and group synchronization is provided by offering a SCIM (System for Cross-domain Identity Management) interface. No credentials are synchronized, only user and group data. ProAuth is offering the following out-of-the-box synchronization integration:

  • Azure Active Directory with SCIM Provisioning
  • Active Directory Synchronization with ProAuth Directory Synchronization Tooling

Any other directory supporting the SCIM protocol can be setup for user and group provisioning in ProAuth. In those scenarios, there is no out-of-the-box support provided by ProAuth and the customer has to implement it on their own.

Key Features


  • Federation
  • OpenID Connect
  • Integration of Enterprise Directories

Contact


Did we raise your attention or do you have any questions? Contact us today at:

  • +41 44 508 37 00
  • proauth@4tecture.ch