Feature Description


A lot of applications lack of a good authentication concept and implementation. Often, there is only a limited form of authentication options and those are often highly coupled into the application which makes it hard to maintain and easily adopt to customer requirements. There should be a clear distinction between application logic and authentication implementation and data. Furthermore often applications do not make use of a shared identity provides which makes it easy to impersonate calls between different services.

Authentication Challenges

Modern applications or microservice architecture should rely on a trusted identity provider which decouples the authentication implementation from the services or applications. There should be a single trust from the application, so new federated identity providers or customer specific configurations do not affect the implementation or deployment of the services and applications.

Modern SaaS application with identity provider


Motivation


Dedicated Authentication Service - Single Point of Trust

  • Reduction of dependencies, and maintainability costs
  • Single point of trust - no changes in application if Identity Providers will be extended
  • Separation of Concerns

Modern Authentication Protocols

  • OpenID Connect, OAuth 2.0
  • Federation with a great variety of providers
  • Custom Identity Provider Module interface
  • Enterprise ADFS Integration (OAuth)

Focus on SaaS Companies

  • Management of Identity Providers on Tenant basis (tenants won’t see each others identity providers)
  • Configuration at runtime with management API and UI
  • Tenant specific Layout and Pages
  • Self-Management for Tenants (i.e. Integration in Active Directory)

Sample Authentication Flow


The application redirects a login request to ProAuth. ProAuth checks the configuration for the current context (app, tenant, …) and redirects to the desired federated identity provider or if multiple options are available, shows the user an overview of all applicable providers.

The trust for any federated identity provider is between ProAuth and the federated provider. The application itself has a single trust to ProAuth. ProAuth checks the authentication from the federated provider and issues the ProAuth tokens to the application.

Sample Authentication Flow

Protocols


ProAuth is based on OpenID Connect / OAuth protocols

  • The application can use any OpenID Connect library to integrate with ProAuth
  • Identity Provider Modules can implement any protocol. Also custom solutions may be added to the security pipeline.

Separation of Concerns


Single trust from application to ProAuth

  • No re-testing / re-validation of application if identity providers are changed / added
  • Identity Provider Management at runtime

Different Identity Providers


A large variety of identity providers are supported

  • The different providers are federated by ProAuth
  • Security Tokens are normalized for application by claim rule engine
    • Convert Claims
    • Add Claims
    • Remove Claims
  • Module interface for custom providers
  • Management during runtime

Multi-Tenancy


Identity Providers from multiple tenants can be integrated

  • Higher security since the authentication is managed by the tenant (i.e. Active Directory)
  • Single Sign-On with domain credentials
  • Filtering of Identity Providers by tenant
    • A tenant cannot see other tenant’s identity providers
    • Login-Pages can be customized per Tenant

Key Features


  • Federated Identity Provider
  • Multi-Tenancy
  • Single Trust
  • Modular design
  • Runtime configuration
  • Per tenant and client app configuration
  • Customized authentication views

Contact


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

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