deft/notes/cisco_org_level_entities.org

62 lines
2.3 KiB
Org Mode
Raw 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
the search of org-level clients.
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-02 15:32:27 +00:00
And as we would not want to break the clients during password change, the
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
So it means adding a the following optional fields to the client object:
- ~old-password~: the old password on password change
- ~old-password-valid-until~: the date after which the old password will be rejected.
The time during which two password could be accepted is probably value that
could in the worst case scenario last for a few weeks.
2022-05-04 13:26:45 +00:00
2022-05-02 15:35:06 +00:00
* Tasks
- [ ] Support org-level client:
1. add a ~org-level?~ boolean field. If this field is true then the
client must not have any ~owner-id~ field.
2022-05-02 15:36:59 +00:00
2. org-level clients should be visible to all admins, for read and search
3. we should provide a new route to promote normal clients to org-level clients.
- [ ] OPTIONAL Support client-secret reset