mart-w/kanidm
1
0
Fork 0
mirror of https://github.com/kanidm/kanidm.git synced 2025-04-12 21:35:39 +02:00
Code Issues Actions Packages Projects Releases Wiki Activity

Update

Browse source
This commit is contained in:
William Brown 2025-03-29 15:25:23 +10:00
parent fa36325618
commit e35d4fddc1
1 changed files with 7 additions and 5 deletions

12
book/src/developers/designs/service_accounts.md
View file

@ -87,15 +87,18 @@ CONS:
## Bit of A, bit of B, cleanup
AKA Capabilities
Rather than fully merge all the types, or fully split them, have a *little* merge of some bits, allowing
some limited extension of actions to specific actors.
some limited extension of actions to specific actors. Effectively we end up granting *capabilities*
to different roles, and we can add extra capabilities later if we want.
OAuth2 and Applications would gain the ability to have API tokens associated for some tasks and
could act on Kanidm, but they wouldn't be fully fleshed service accounts.
| | Api Token | OAuth2 Sessions | Interactive Login |
| Capabilities | Api Token | OAuth2 Sessions | Interactive Login |
|-----------------|------------------|------------------------------|---------------------|
| OAuth2 | Yes | Via Client Credentials Grant | No |
| OAuth2 | No | Via Client Credentials Grant | No |
| Application | Yes | No | No |
| Service Account | Yes (rw capable) | Yes (via session grant (TBD) | Yes (to be removed) |
| Break Glass | No | No | Yes |
@ -106,11 +109,10 @@ PROS:
* Grants some new abilities within limits to other roles
* While not as locked down as separate concern proposal, still minimises the risk of compromise of an SA
CONS:
* Requires admins to have multiple accounts in some contexts (as above).
* Auditing requires knowledge of what each roles capabilities are
* Auditing requires knowledge of what each roles capabilities are, and what the capabilities do