deft/notes/customer_manager.org

:PROPERTIES:
:ID:       99fd9444-ae5d-4d51-a295-a936fc01928a
:END:
#+TITLE: Customer Manager
#+Author: Yann Esposito
#+Date: [2021-10-15]

- tags :: [[id:91f33b35-6e4e-4213-b214-972ee20722df][Cisco]]
- source :: 

* Customer Manager
DEADLINE: <2021-10-15 Fri>
** Quick wins along the way
*** Local Account Switch (Tenancy Switching)

The API will provide two new routes:

- =GET /iroh/session/accounts=
 => returns a list of accounts + URLs
- =POST /iroh/session/switch-account=
  => revoke current JWT / returns a new access and refresh token for the
  new account

The clients (UI) could use these endpoint to:
- list the accounts
- switch the account

The tenant/session is still  local to the domain name/application (SecureX/CTR/Orbital)

**** Notes

The call to switch account should revoke the JWT to prevent a bug in the UI
that will continue to use an older access token from the wrong org/tenant.

*** backend-to-backend OAuth2 tokens exchange

> *code already delivered, not deployed*

Idea, give other teams a trusted client.
With this client and a user-id the team could get tokens for this user-id.

The API will provide a new custom route.
So teams could be given a unique OAuth2 client that will be /trusted/ by
IROH administrators.

With this client and a user id, the team will get back a couple
access/refresh token for their client (limited to their scopes).

This makes it possible, once a user is authenticated inside IROH-Auth to
hand tokens to other teams.
One mechanism to handle this situation is the webhooks.
But we could also use OpenID Connect, etc..
*** org-level credentials

The idea is quite simple.
For every org creation, create an associated user in the DB.
This user-id will probably be specific in order to find it fast.
And in order to limit the risk of finding the user I suggest to use

#+begin_src clojure
(def user-id (str "admin" (hash (str org-id salt) ))
#+end_src

*** Maybe? Cross domain Account switching

This could be the occasion to make a new global deployment.
A specific node with credentials that could be used to call all IROH nodes.

This could be challenging to have this in a few weeks, but this open the
notion of /Customer Manager Session/ at the User-Identity level.

**** Tasks

- [ ] Support sub-routes in IROH using another public key for JWT.
  Also the claims will be different.
  The claims will not contain any =user-id= nor =org-id=, but only
  =user-identity-id= and probably =idp-id= (not sure).

- [ ] Create a new set of services in IROH that will be the future Customer
  Manager. And see with the ops how we could deploy it. I would guess
  deploy this on NAM, and the node will call the 3 IROH nodes.

** Long term Customer Manager *** Reflections After different discussion we
assume that:

1. SecureX Sign-On will be responsible to provide a unique CUSTOMER_ID to
   an USER_IDENTITY.
   So an SXSO User Identity should only be used by a single CUSTOMER_ID.
2. SecureX Sign-On should if possible provide Customer metas in the claims
   of the OpenID Connect flow. Typically the CUSTOMER NAME, and perhaps
   other details.

**** *Warnings*

It looks assumed in the documentation that MOST user domain email will be
enough to determine who is the customer that a user identity belongs to.

It doesn't look like we will stop supporting non 3rd party IdP login?

So it means the we already have a design-space complexity.

If the User Identity is linked to a Customer or not.
Without 3rd party IdP login we could imagine a user could belong to
multiple Customers. I think we should assume, for sake of simplicity that
this should not be the case, and our customer control access to their
platform via providing (or not) an email using their own domain name.

*** Customers

We need to build a single world wide API which would handle the
organization shown in "Proposed Solution" diagram.

A global Customer (Acme)

The global customer should have at most one SecureX org per environment
(NAM, EU, APJC).

We should be able to list all tenants for this global customer across all environments.
Typically, say Acme bought 1 Umbrella contract per region, 1 AMP contract
for AMP and 1 AMP contract for EU.
Then we should be able to display:

#+begin_src
Acme
  + NAM
    - Umbrella-tenant-1
    - AMP-tenant-1
  + EU
    - Umbrella-tenant-2
    - AMP-tenant-2
  + APJC
    - Umbrella-tenant-3
#+end_src

The constraint being that a tenant can only be placed once on all environments.

**** Consequences on IROH-INT

The part searching for the list of module instances in IROH will need to
first query the list of modules to the Customer Manager.
It means that a structure similar to the modules instances should be placed
into the Customer Manager.
But we have a probably better proposal.
Instead of centralizing everything, the Customer Manager could call IROH
APIs to move/manage modules between envs.