MVP AAA Architecture

The Architecture describe target architecture, I propose to define here the MVP IAM deployment architecture using DebiaiAas to demonstrate the associated capabilities.

It will be integrated in an evolution of the initial working environment description.

TODO update the updated

In this MVP description we propose to implement and deploy a AAA concept has been define for network access, but can be extend / manage at an application level

We what to define here what is needed to build are first application with AAA managment

Proposed hypothesis for this version

Authentification

Authentification shall rely on third party as much as possible :

• google auth for safenai user
• a default email / password falback for people without auth access can be propose
• ...

For authentification we have the following element to consider :

• front :
  • login / logout button component to share with all our applications
  • login page outside of the application that propose all authentification method supported
  • the way we share token gather from authentification with other applications
• infra :
  • redirection of unauthentified user
  • control the token as a valid authentification

Autorization

For autorization, we have the following elements to consider

• front
  • A dedicated application to manage which user / group / organization have which autorizations
  • A way to manage users and token information in front application (cf debiai proposal)
• infra
  • The deployement that will control the autorization in deployed application (keycloak ?)

Accounting

• Traçeability of who log when
• traçeability of action performed
• ...

Warning :

• Two level of traceability
  • security, audit, ....
  • functional traceability (in klarity)

For MVP : we focus on the minimal monitoring to perform asscociated to security and audit.

Selective domain name per environment

• safenai.io : public environment (for static web site, public information)
• <customer>.safenai.xx : production environment (for DebiaiAAS in prod, and klarity in prod)
• <customer>.safenai.yy : integration environment (for release candidate of application)

Rational behind this proposal :

• DNS associated to environment DNS are automatically update by kubernetes, it's better to separate DNS of these 3 environments.

Environement

• First deploy for our integration environement with :

Target capability of the front app for connection

• Deployment might be use to demonstrate our ability to manage
  • registration of user with different pattern
    • safenai access control : google authentification ?
    • third-party access control
      • social network
      • eu id ?
      • france auth services ?
    • fallback : mail + password / reset email ?
  • Provide an application to manage user right / groups
    • allow each user to :
      • see to which organisation he is registered
      • see to which group he is associated in this organisation
      • request to join an organization
      • request to leave an organization
      • request to join an organization group
    • access only user in "owner" or "xxx" group of an organization
      • see who are in the organization, in which groups
      • accept or add a user in the organization
      • remove a user from the organization
      • accept / add a user to a group
  • Each action perform in the application
    • the front can use the user groups to agree / prevent the opération to be available / performed (web component use in our front app)
    • the k3s/k8s cluster shall control ressource access associated to organization / project / group ?
  • backend-service can get users groups / projects / organization from a temporary token to check service access

QUESTION :

• Group might be grant at a global / project scope for user in the MVP to be discuss
• Do we need to integrate this in the MVP ?
• Shall we reuse some work of "ISX 360" project ?
• Is there any ready to use application to customize / adapt for this product ?

Selected solution

• front
  • share SSO token between safenai app (see debiai solution)
  • display authorisation information of the user
  • For user grant, shall we need a custom app or rely on keycloak console provided to customers ?
  • use this shall to grant access to debiai solution as registered user.
• infra
  • use securing-k3s-applications-with-oauth2-proxy ?
  • deploy keycloak
  • add support of third partie google
• service
  • implement in data provider autorization strategy to demonstrate the capability before integration in klarity dashboard

Usefull ressources

keycloak authorization_servicesnginx-and-keycloaksecuring-a-react-app-using-keycloaksecuring-k3s-applications-with-oauth2-proxy