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.

This is a probably safer mechanism than Webhooks that do not involve any =client-secret=.
Ideally the webhooks should only provide user ids, and the other team will
be able to retrieve credential tokens for this user via this
backend-to-backend token delivery route.

One major advantage is also that the tokens scopes (and many other properties)
will be managed in a centralized client.

Ideally every Cisco team that integrate within IROH should have a single client.

*** org-level credentials

We simulate the existence of an org-level user.
We do not create a new entry in the DB, instead, we simply add a logic in
=get-user= function such that if the name matches something like
=admin-<org-id>= we retrieve an admin user data.

This way this should not break the existing mechanism of security regarding
authorizations and OAuth2.

Then in order to detach an entity to the org-level (typically a client or
an application grant) we could simply change the =user-id= to match this
=admin-<org-id>=.

It looks like this could work, but this need to be tested first as we might
miss a technical detail making this difficult.

** Intermediate steps (optional)
*** Cross region 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).
- [ ] Support login via SXSO-only but returning a non IROH JWT, but a
  Customer Manager JWT. This is the biggest work to be done. Currently the
  code to login takes great care at checking some claims in the JWTs.
  We need to support User-Identity session instead of User session.
- [ ] 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.
  This will be the occasion to test the latency between nodes and see if this
  is not problem.
*** Organization managements Once we have a deployed a global node that

could makes call to all IROH nodes.

We could start to think about providing more and more API accesses.

Typically one step could be a way to control the orgs from this centralized
node.
Typically, see all your orgs across all regions and disable/rename the orgs.
*** Customer Selection (?)

If we have a global node deployed where users could login

At this step we could also imagine that a User-Identity might belongs to
multiple Customers. This would probably also be the right moment to provide
APIs managing these.

*** Customer Invitations

For customers using their own IdP and specific email domain names

*** Tenant management

- At this step we should be able to login user at their User Identity level (SXSO login).
- The User Identity should be linked to a single Customer(?).
- The IROH nodes should support new APIs that could be called using the
  tokens from the customer manager node.

Now we could be able to create/update/move across orgs/move across regions
module-instances (tenants).

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