deft/notes/cisco_org_level_entities.org

61 lines
2.2 KiB
Org Mode
Raw Permalink Normal View History

2022-05-02 15:10:18 +00:00
:PROPERTIES:
:ID: b30f9e63-e655-40e6-9a58-5a390a7921bb
:END:
2022-05-02 15:20:37 +00:00
#+TITLE: Cisco: Org Level OAuth2 Clients
2022-05-02 15:10:18 +00:00
#+Author: Yann Esposito
#+Date: [2022-05-02]
- tags :: [[id:ce893df9-32a4-44e0-9eb5-b9817141ee6a][cisco]]
- source ::
2022-05-02 15:12:03 +00:00
2022-05-02 15:20:37 +00:00
* Org Level Clients
2022-05-02 15:13:33 +00:00
2022-05-04 13:20:16 +00:00
*Goal*: When the creator of an OAuth2 client leaves the company.
we wish to keep the client working while disabling the user.
2022-05-02 15:13:33 +00:00
2022-05-04 13:20:16 +00:00
** Technical Solution
2022-05-02 15:16:11 +00:00
2022-05-04 13:26:45 +00:00
We should provide a field that marks a client as being owned by the org and
2022-05-04 13:23:53 +00:00
not by a particular user.
2022-05-02 15:22:55 +00:00
What does this mean:
1. Every admin of the org should be able to see and edit the client
2022-05-02 15:24:04 +00:00
2. During the creation of the client we should add an option such that we
know this client is an org-level client
2022-05-02 15:20:37 +00:00
2022-05-02 15:25:09 +00:00
Looking at the code, it means that we should just change the
2022-05-02 15:27:27 +00:00
~iroh-auth.oauth2-client-service.core/accessible-for?~ function.
We should probably add a new optional field to ease both the creation and
2022-05-04 13:27:53 +00:00
the search for org-level clients.
2022-05-02 15:27:27 +00:00
2022-05-02 15:28:49 +00:00
I propose to add an optional ~org-level?~ field.
2022-05-04 13:23:53 +00:00
If true during the creation then we should set the ~owner-id~ to be equal to
the ~org-id~.
2022-05-02 15:26:10 +00:00
2022-05-02 15:29:52 +00:00
** Security concerns
2022-05-02 15:16:11 +00:00
2022-05-02 15:31:17 +00:00
While not mandatory, handling an ownership change should mean we would like
2022-05-04 13:26:45 +00:00
to provide a way to change the client's secret.
2022-05-02 15:31:17 +00:00
So we should provide a *Client Secret Reset* mechanism.
Probably a single POST endpoint that would generate a new password.
2022-05-04 13:27:53 +00:00
And as we would not want to break the clients during a password change, the
2022-05-02 15:32:27 +00:00
client should probably support two passwords temporarily.
So having a configurable by the user grace period during which the old
password will still be accepted.
2022-05-02 15:34:03 +00:00
2022-05-04 13:27:53 +00:00
So it means adding the following optional fields to the client object:
2022-05-02 15:34:03 +00:00
- ~old-password~: the old password on password change
- ~old-password-valid-until~: the date after which the old password will be rejected.
2022-05-04 13:29:25 +00:00
The time during which two passwords could be accepted could last up to a few weeks.
2022-05-04 13:26:45 +00:00
2022-05-02 15:35:06 +00:00
* Tasks
- [ ] Support org-level client:
2022-05-04 13:29:25 +00:00
1. add an ~org-level?~ boolean field. If this field is true then the
2022-05-02 15:35:06 +00:00
client must not have any ~owner-id~ field.
2022-05-04 13:29:25 +00:00
2. org-level clients should be visible to all admins, for reading and searching
2022-05-02 15:36:59 +00:00
3. we should provide a new route to promote normal clients to org-level clients.
- [ ] OPTIONAL Support client-secret reset