: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
*** 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.

*** Service 2 Service OAuth2 tokens exchange

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..
*** 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.

** 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.

But 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.