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>
|
2021-10-15 14:13:16 +00:00
|
|
|
|
|
|
|
|
|
|
|
** Questions
|
|
|
|
|
|
|
|
One supposition is not entirely unambiguous in the Customer Manager document.
|
2021-10-15 14:29:23 +00:00
|
|
|
Can we assume that a /user identity/ (login via SXSO) can have at most a
|
|
|
|
single /customer/?
|
2021-10-15 14:13:16 +00:00
|
|
|
|
2021-10-15 14:30:31 +00:00
|
|
|
Where should be the source of truth?
|
2021-10-15 14:13:16 +00:00
|
|
|
|
2021-10-15 14:30:31 +00:00
|
|
|
- Does SXSO select the customer at user login?
|
|
|
|
- Does the customer is associated in the customer manager after the user
|
|
|
|
authentication via SXSO?
|
2021-10-15 14:13:16 +00:00
|
|
|
|
2021-10-15 13:06:13 +00:00
|
|
|
** 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 14:25:00 +00:00
|
|
|
This new API should solve many points mentionned in the /Application - SecureX Integrations/
|
|
|
|
part of the document:
|
|
|
|
|
|
|
|
#+begin_quote
|
|
|
|
- Clients can acquire tokens, possibly from the Customer Manager, to access SecureX APIs for a target SecureX Organization
|
2021-10-15 14:26:29 +00:00
|
|
|
- Access is pre-authorized, and tokens can be acquired without user consent
|
|
|
|
- Achievable using the OAuth Client Credentials Grant using a confidential client with a client secret or
|
|
|
|
certificate. Source application tenant is provided as part of the token request.
|
2021-10-15 14:25:00 +00:00
|
|
|
#+end_quote
|
|
|
|
|
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 14:25:00 +00:00
|
|
|
This with the previous backend-to-backend route should solve the following entry:
|
|
|
|
|
|
|
|
#+begin_quote
|
|
|
|
- These tokens provide access on behalf of the source application tenant and not on behalf of a user
|
|
|
|
#+end_quote
|
|
|
|
|
|
|
|
|
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
|
2021-10-15 14:09:47 +00:00
|
|
|
=Customer= in the Customer Manager. This invitation will probably be a lot
|
|
|
|
simpler as it will not involve SecureX org selection and a single region.
|
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
|
|
|
|