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

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

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.

Tasks
  • Design a user-identity and customer schema
  • New stores to create: customers and user-identities. This change might force a DB Migration of the users DB in all IROH nodes.

Customer Invitations

We could probably reuse the SecureX invitation API to invite people into a Customer

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:

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.