2021-10-15 13:06:13 +00:00
|
|
|
: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
|
2021-10-15 13:16:18 +00:00
|
|
|
*** Local Account Switch (Tenancy Switching)
|
2021-10-15 13:06:13 +00:00
|
|
|
|
|
|
|
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.
|
|
|
|
|
2021-10-15 13:17:30 +00:00
|
|
|
*** backend-to-backend OAuth2 tokens exchange
|
|
|
|
|
|
|
|
> *code already delivered, not deployed*
|
2021-10-15 13:06:13 +00:00
|
|
|
|
2021-10-15 13:18:58 +00:00
|
|
|
Idea, give other teams a trusted client.
|
|
|
|
With this client and a user-id the team could get tokens for this user-id.
|
|
|
|
|
2021-10-15 13:06:13 +00:00
|
|
|
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..
|
2021-10-15 13:18:58 +00:00
|
|
|
*** org-level credentials
|
|
|
|
|
2021-10-15 13:35:32 +00:00
|
|
|
We simulate the existence of an org-level user.
|
2021-10-15 13:37:01 +00:00
|
|
|
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
|
2021-10-15 13:39:12 +00:00
|
|
|
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>=.
|
|
|
|
|
2021-10-15 13:40:14 +00:00
|
|
|
It looks like this could work, but this need to be tested first as we might
|
|
|
|
miss a technical detail making this difficult.
|
2021-10-15 13:32:44 +00:00
|
|
|
|
2021-10-15 13:40:14 +00:00
|
|
|
** Intermediate steps (optional)
|
|
|
|
*** Cross region Account switching
|
2021-10-15 13:07:52 +00:00
|
|
|
|
|
|
|
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.
|
|
|
|
|
2021-10-15 13:10:19 +00:00
|
|
|
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.
|
2021-10-15 13:09:15 +00:00
|
|
|
|
2021-10-15 13:12:18 +00:00
|
|
|
**** Tasks
|
2021-10-15 13:06:13 +00:00
|
|
|
|
2021-10-15 13:12:18 +00:00
|
|
|
- [ ] Support sub-routes in IROH using another public key for JWT.
|
2021-10-15 13:16:18 +00:00
|
|
|
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).
|
2021-10-15 13:12:18 +00:00
|
|
|
|
2021-10-15 13:15:04 +00:00
|
|
|
- [ ] 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.
|
2021-10-15 13:40:14 +00:00
|
|
|
*** Cross region invitations?
|
2021-10-15 13:15:04 +00:00
|
|
|
|
2021-10-15 13:12:18 +00:00
|
|
|
** Long term Customer Manager *** Reflections After different discussion we
|
|
|
|
assume that:
|
2021-10-15 13:06:13 +00:00
|
|
|
|
|
|
|
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.
|
|
|
|
|
2021-10-15 13:09:15 +00:00
|
|
|
It doesn't look like we will stop supporting non 3rd party IdP login?
|
2021-10-15 13:06:13 +00:00
|
|
|
|
|
|
|
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.
|
2021-10-15 13:09:15 +00:00
|
|
|
|
2021-10-15 13:06:13 +00:00
|
|
|
*** 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.
|