yogsototh/deft
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
deft/notes/customer_manager.org
Yann Esposito (Yogsototh) 0b6b5f8ec9
notes/customer_manager.org
2021-10-15 15:32:44 +02:00

4.9 KiB
Raw Blame History

Customer Manager

tags
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

(def user-id (str "admin" (hash (str org-id salt) ))

We shall probably add a field to hide this user something like `:role :org-internal-admin`

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:

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

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.