Skip to main content

Multiple instances and SSO

Problem​

  1. You want to have multiple instances of Akkess running in different environments
  2. You want to give your users a Single Sign-On (SSO) experience
  3. Your users might exist in multiple tenants and instances
  4. You want to have a seamless experience for your users
  5. You want to give your users a possibility to switch between tenants and systems
  6. You have several different end user applications
  7. Which application that is applicable for the user is based on the user's roles
  8. You want to have a centralized login page for all your applications

Solution​

Abbreviations​

  • FE - Customer made frontend application
  • BE - Customer made backend service

Setup & Pre-conditions​

  1. You have your own FE app and BE service fronting the different Akkess instances and is used as the entry point for the user
  2. The BE service knows about all available Akkess instances and their base URLs
  3. The FE app has UI for displaying login-forms and support for handling the login flows
  4. You have some re-captcha service in place
  5. You have set up a user in each Akkess instance with a role that have permission to read actor's IdP affiliations. The BE service has the credentials for this user.

Flow​

Used data models​

Used end-points​

The Akkess API specs

Query IdP affiliations matching username (Actor)​

Current endpoint does not support cross tenant query.

In Akkess v1.1 endpoint for query actor information cross tenants will be implemented

/actor/v1/actors/~list

Query IdP configurations for Akkess Application (Authentication)​

Use either of the following endpoints depending on if the IdP configuration is public or not

/authentication/v1/applications/{application-expression}/public-identity-provider-policy
/authentication/v1/application-identity-provider-policy

Query actor's tenant affiliations using IdP token (Authorization)​

/authorization/v1/applications/{application-expression}/tenant-actor-affiliations

Issue IAM token​

/authorization/v1/tenants/{tenant-expression}/tokens

BE service permissions​

The be able to call Akkess API the BE service user needs the actor permission - permission.actor.read.

To make the BE service unaware about any sensitive information about the user the response can be projected and only contain the needed information.

If some actors should be filtered out and not accessible by the BE service user the response can be filtered by access right rules.

- Read actors - permission.actor.read
  - Allow only IdP affiliations in the response (optional)
  - Limit actors returned to actors with certain roles, types, statuses, IdP keys (optional)

Conclusion​

Single-Sign-On cross multi instances and applications is not an easy task. But having and powerful architecture makes life much easier when developing systems.

The flow above is easy to implement and will make the user experience seamless.

Copyright © 2019 Akkess