Ideas about service accounts

book/src/developers/designs/service_accounts.md

@@ -0,0 +1,119 @@
+# Service Account Improvements - 2025
+
+Initially when service accounts were added to Kanidm they were simply meant to be "detached"
+accounts that could be used for some API access to Kani, or some other background tasks.
+
+But as the server has evolved we need to consider how we can use these in other ways.
+
+We have extented the OAuth2 client types to now almost act like a service account, especially
+with the behaviour of things like a client credentials grant.
+
+At this point we need to decide how to proceed with service accounts and what shape they could
+take in the future.
+
+## Prior Art
+
+* (Microsoft AD-DS Service Accounts)[https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-service-accounts]
+* (FreeIPA Service Principals)[https://www.freeipa.org/page/Administrators_Guide#managing-service-principals]
+
+Note that both of these have some kerberos centric ideas as KRB requires service accounts to mutually
+authenticate to clients, which means they need to maintain credentials. This is different to our needs,
+but there are still some ideas in these docs worth knowing about and considering like group managed
+service accounts (gMSA).
+
+## High Level Suggestions
+
+There are the ideas today that I have - there may be others!
+
+* Service Accounts can have attached roles.
+* Keep concerns separate.
+* Bit of A, bit of B, cleanup.
+
+## Current state of affairs
+
+We have:
+
+* Break glass accounts are service accounts, may not have delegated management.
+* OAuth2 is not a service account, supports delegated management.
+* Service accounts can be group or user managed.
+* Applications (To Be Introduced) is an extension of a Service account.
+
+From this we can see that we have some separation, but also some cross over of functionality.
+break glass isn't delegated, but service account is, OAuth2 isn't an SA, but Applications are.
+
+## Attach roles to service accounts.
+
+In this approach we centre the service account, and allow optional extension of other concerns. This
+would make OAuth2 applications an extension of a service account. Similar Application as well.
+
+This would mean that we create a service account first, then need a way to extend it with the
+application or oauth2 types.
+
+PROS:
+
+* OAuth2 applications get the ability to have api tokens to kani for other functionality
+* Fullstacks like a mail server get a single SA that does everything
+* These whole stack service accounts get access to every auth type and feature available
+
+CONS:
+
+* Makes the API around service accounts a bit messier
+* Compromise of the SA or SA Manager may lead to higher impact due to more features in one place
+* May be confusing to administrators
+* More "inheritance" of schema classes, when we may want to try to simplify to single classes in line with SCIM.
+* Harder to audit capabilities
+
+## Separate Concerns
+
+In this approach we split our concerns. This is similar to today, but taken a bit further.
+
+In this example, we would split Application to *just* be about the concern of an authentication
+domain for LDAP applications. OAuth2 stays as *just* a configuration of the client and it's behaviour.
+
+We would change the break glass accounts to be a separate type to Service Account. Service Account
+becomes closer to the concept of a pure api access account. The break glass accounts become a
+dedicated "emergency access account" type.
+
+PROS:
+
+* Similar to today, only small cleanup needed
+* Separation of concerns and credentials limit's blast radius of a possible compromise.
+* Easier auditing of capabilities of each account
+
+CONS:
+
+* More administrative overhead to manage the multiple accounts
+* Stacked applications will need mulitple configurations for a role - OAuth2, LDAP application, Service accounts for example in an email server with a WebUI.
+
+## Bit of A, bit of B, cleanup
+
+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.
+
+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   |
+|-----------------|------------------|------------------------------|---------------------|
+| OAuth2          | Yes              | 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                 |
+
+PROS:
+
+* Minimises changes to existing deployments
+* 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
+
+
+
+
+
+