ProAuth Architecture

The following OpenID Connect features are implemented in the OIDC endpoints:

• OpenID Connect authorization and token endpoints supporting
  • Code Flow
  • Implicit Flow
  • Hybrid Flow
  • Client Credential Grant Flow
  • Refresh Tokens
• User Info Endpoint

All the auth views are fully customizable. The views can be customized on any level, namely customer, subscription, and tenant level. The view customization module always shows the most specific customized view. The same customization functionality also applies on the internationalization feature which enables an administrator to customize the label values for any level and language.

The management API provider is used to manage and configure ProAuth server. The API is protected and a user needs to authorize against the ProAuth resource and needs to be associated with an appropriate security role. The management API is implemented as a REST API with enhanced filtering (OData queries), paging and validation.

The API definition is available as OpenAPI (Swagger) definition as well as generated client packages for .NET and JavaScript.

User and Group provisioning is implemented by a SCIM (System for Cross-domain Identity Management) API. The SCIM API does not support synchronizing any credentials and is only intended to provision users and groups to ProAuth.

The SCIM API is always executed in the context of an IDP instance and therefore uses unique credentials (token) for this specific IDP instance.

If a federated scenario is not applicable, users and groups can be managed in user stores. ProAuth can manage multiple user stores and normally, the users from different legal entities or tenants are separated into different user stores (normally a dedicated database per user store). Therefore the user store API is always executed in the context of a specific user store instance.

The API lets you manage users, groups, and group memberships as well as managing additional user profile data. Managing user credentials like setting initial passwords, resetting passwords is also part of the user store management API.

Whenever a user needs to interact with the user store, the user store views provide the corresponding views (i.e. login views, password change views, etc.). The views can be customized like the auth views.

ProAuth is based on ReaFx framework which offers model based views for CRUD views. 98% of all the admin UI views are completely model based and therefore the definition of those views are stored in the ProAuth configuration database. There is a controller managing the view definitions.

Each release of ProAuth Admin UI will update the view definitions to the latest version. The product does not currently support a customer customizing the admin UI views, even though it is technically possible.

ProAuth is based on ReaFx framework which offers model based views for CRUD views. 98% of all the admin UI views are completely model based and therefore the definition of those views are stored in the ProAuth configuration database. There is a controller managing the view definitions.

Each release of ProAuth Admin UI will update the view definitions to the latest version. The product does not currently support a customer customizing the admin UI views, even though it is technically possible.

Label management for all the labels used in the admin UI based on ReaFx.

Each release of ProAuth Admin UI will update the label definitions to the latest version. The product does not currently support a customer customizing the admin UI labels, even though it is technically possible.

As described in the introduction, ProAuth uses a dedicated authentication pipeline for each tenant and recreates the pipelines on every configuration change. This component manages those pipelines and integrates with the PubSub system to synchronize the pipelines across multiple instances.

The IDP modules are the base implementation to create IDP instances which perform the federated authentication to a specific identity provider of authenticate with a user store instance. Each type of protocol of vendor specific implementation details result in a dedicated module. Most of the modules relay on OpenID Connect and OAuth.

Each module offers a set of configuration options. The options are validated and can be automatically migrated for module version updates.

Customer specific modules can easily be integrated. However the standard product offers a fixed set of modules.

As with the IDP modules, the TwoFactor implementation are defined in dedicated modules. Those module offer a second factor implementation for SMS, e-mail or TOTP.

Each module offers a set of configuration options. The options are validated and can be automatically migrated for module version updates.

Customer specific modules can easily be integrated. However the standard product offers a fixed set of modules.

The job component handles recurring / scheduled jobs in ProAuth.