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:48:45 +00:00
|
|
|
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.
|
2021-10-15 13:46:00 +00:00
|
|
|
|
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:54:42 +00:00
|
|
|
- [ ] 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.
|
2021-10-15 13:15:04 +00:00
|
|
|
- [ ] Create a new set of services in IROH that will be the future Customer
|
2021-10-15 13:50:03 +00:00
|
|
|
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.
|
2021-10-15 13:43:26 +00:00
|
|
|
|
|
|
|
We could start to think about providing more and more API accesses.
|
|
|
|
|
2021-10-15 13:44:48 +00:00
|
|
|
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.
|
2021-10-15 13:53:23 +00:00
|
|
|
*** Customer Selection (?)
|
|
|
|
|
|
|
|
If we have a global node deployed where users could login
|
2021-10-15 13:52:07 +00:00
|
|
|
|
|
|
|
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.
|
2021-10-15 13:58:20 +00:00
|
|
|
|
2021-10-15 14:03:50 +00:00
|
|
|
|
|
|
|
**** Tasks
|
|
|
|
|
2021-10-15 14:05:41 +00:00
|
|
|
- [ ] 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.
|
2021-10-15 14:03:50 +00:00
|
|
|
|
2021-10-15 14:02:14 +00:00
|
|
|
*** Customer Invitations
|
|
|
|
|
2021-10-15 14:08:41 +00:00
|
|
|
We could probably reuse the SecureX invitation API to invite people into a
|
|
|
|
=Customer=
|
2021-10-15 14:02:14 +00:00
|
|
|
|
2021-10-15 13:58:20 +00:00
|
|
|
*** Tenant management
|
|
|
|
|
|
|
|
- At this step we should be able to login user at their User Identity level (SXSO login).
|
2021-10-15 13:59:23 +00:00
|
|
|
- The User Identity should be linked to a single Customer(?).
|
2021-10-15 14:00:53 +00:00
|
|
|
- The IROH nodes should support new APIs that could be called using the
|
|
|
|
tokens from the customer manager node.
|
2021-10-15 13:58:20 +00:00
|
|
|
|
2021-10-15 14:00:53 +00:00
|
|
|
Now we could be able to create/update/move across orgs/move across regions
|
|
|
|
module-instances (tenants).
|
2021-10-15 13:52:07 +00:00
|
|
|
|
2021-10-15 13:57:01 +00:00
|
|
|
** Long term Customer Manager
|
|
|
|
*** Reflections After different discussion we
|
2021-10-15 13:12:18 +00:00
|
|
|
assume that:
|
2021-10-15 13:06:13 +00:00
|
|
|
|
2021-10-15 14:07:40 +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=.
|
2021-10-15 13:06:13 +00:00
|
|
|
2. SecureX Sign-On should if possible provide Customer metas in the claims
|
2021-10-15 14:07:40 +00:00
|
|
|
of the OpenID Connect flow. Typically the =CUSTOMER_NAME=, and perhaps
|
2021-10-15 13:06:13 +00:00
|
|
|
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.
|