1222 what rights does anonymous have (#2436)

Document the default access that anonymous has, as well as default access controls and permission groups.

book/src/SUMMARY.md

@@ -26,6 +26,7 @@
   - [Authentication and Credentials](accounts/authentication.md)
   - [Groups](accounts/groups.md)
   - [Service Accounts](accounts/service.md)
+  - [Anonymous](accounts/anonymous.md)
   - [Account Policy](accounts/policy.md)
   - [POSIX Accounts and Groups](accounts/posix.md)
 
@@ -53,6 +54,8 @@
   - [FreeIPA](sync/freeipa.md)
   - [LDAP](sync/ldap.md)
 
+- [Access Control](access_control/intro.md)
+
 ## Support
 
 - [Troubleshooting](troubleshooting.md)

book/src/access_control/intro.md

@@ -0,0 +1,74 @@
+# Access Control
+
+While Kanidm exists to make authorisation decisions on behalf of other services, internally it must
+make decisions about writes operations to the entries within its database. To make these choices,
+Kanidm has an internal set of access controls which are the rules describing who may perform what
+actions.
+
+## Default Permissions
+
+The project ships default access controls which are designed to limit and isolate the privileges of
+accounts whenever possible.
+
+This separation is the reason why `admin` and `idm_admin` exist as separate accounts. There are two
+distinct access silos within Kanidm. Access to manage Kanidm as a service (such as application
+integrations and domain naming) and access to manage people and groups. This is to limit the
+possible harm that an attacker may make if they gain access to these roles.
+
+## Permission Delegation
+
+A number of types in Kanidm allow permission delegation such as groups and service accounts. This
+allows entries to be assigned an entry manager who has write access to that entity but not all
+entities of the same class.
+
+## High Privilege Groups
+
+Kanidm has a special group called `idm_high_privilege`. This acts as a "taint" on its members to
+indicate that they have an elevated level of access within Kanidm or other systems.
+
+This taint flag exists to prevent lateral movement from other roles that have higher levels of
+privilege.
+
+An example is `idm_service_desk` which has the ability to trigger credential resets for users. This
+is an important aspect of the service desk role. However, a member of the service desk should not be
+able to modify the credentials of their peers, nor should they be able to escalate by accessing the
+credentials of users in a role such as `idm_admins`. Since `idm_service_desk` and `idm_admins` are
+both tainted with `idm_high_privilege` then this lateral movement is not possible. Only high
+privileged roles are able to then reset the accounts of high privilege users.
+
+You may add other groups to `idm_high_privilege` to achieve the same taint effect for other
+services.
+
+## Default Permission Groups
+
+Kanidm ships with default permission groups. You can use these to enable accounts to perform certain
+tasks within Kanidm as required.
+
+| group name                   | description                                                             |
+| ---------------------------- | ----------------------------------------------------------------------- |
+| `domain_admins`              | modify the name of this domain                                          |
+| `idm_access_control_admins`  | write access controls                                                   |
+| `idm_account_policy_admins`  | modify account policy requirements for user authentication              |
+| `idm_group_admins`           | create and modify groups                                                |
+| `idm_oauth2_admins`          | create and modify oauth2 integrations                                   |
+| `idm_people_admins`          | create and modify persons                                               |
+| `idm_people_on_boarding`     | create (but not modify) persons. Intended for use with service accounts |
+| `idm_people_pii_read`        | allow read to personally identifying information                        |
+| `idm_people_self_write_mail` | allow self-modification of the mail attribute                           |
+| `idm_radius_servers`         | read user radius secrets. Intended for use with service accounts        |
+| `idm_radius_service_admins`  | create and reset user radius secrets, and allow users to access radius  |
+| `idm_recycle_bin_admins`     | modify and restore entries from the recycle bin                         |
+| `idm_schema_admins`          | add and modify elements of schema                                       |
+| `idm_service_account_admins` | create and modify service accounts                                      |
+| `idm_unix_admins`            | enable posix attributes on accounts and groups                          |
+
+## Default Roles
+
+Kanidm ships with 3 high level permission groups. These roles have no inherent permissions, they are
+created by being members of the default permission groups.
+
+| group name         | description                                              |
+| ------------------ | -------------------------------------------------------- |
+| `idm_admins`       | manage persons and their groups                          |
+| `idm_service_desk` | assist persons with credential resets or other queries   |
+| `system_admins`    | manage the operation of Kanidm as a database and service |

book/src/accounts/anonymous.md

@@ -0,0 +1,50 @@
+# Anonymous Account
+
+Within Kanidm there is a single "special" account. This is the anonymous service account. This
+allows clients without any credentials to perform limited read actions against Kanidm.
+
+The anonymous account is primarily used by stateless unix clients to read account and group
+information.
+
+## Authentication
+
+Even though anonymous does not have credentials it still must authenticate to establish a session to
+access Kanidm. To achieve this there is a special `anonymous` credential method. Anonymous is the
+only account that may use this credential method.
+
+## OAuth2 / OIDC
+
+Anonymous is a service account which prevents it from using OAuth2/OIDC to access other
+applications.
+
+## Access
+
+By default anonymous has limited access to information in Kanidm. Anonymous may read the following
+data.
+
+> NOTE: The `Name` attribute is the user's public username. This is different to their private and
+> sensitive `LegalName` attribute.
+
+### People
+
+- Name
+- DisplayName
+- MemberOf
+- Uuid
+- GidNumber
+- LoginShell
+- SshPublicKey
+
+### Groups
+
+- Name
+- Member
+- DynMember
+- GidNumber
+
+## Disabling the Anonymous Account
+
+The anonymous is like any other and can be expired to prevent its use. See the
+[account validity section](./people#account-validity)
+
+When disabled, this will prevent stateless unix clients from authenticating to Kanidm.

book/src/accounts/intro.md

@@ -84,39 +84,3 @@ permissions. Each group has a description to explain its purpose. These can be v
 kanidm group list --name idm_admin
 kanidm group get <name>
 ```
-
-## Why Can't I Change admin With idm\_admin?
-
-As a security mechanism there is a distinction between "accounts" and "high permission accounts".
-This is to help prevent elevation attacks, where a member of a service desk could attempt to reset
-the password of idm\_admin or admin, or even a member of HR or System Admin teams to move laterally.
-
-Generally, membership of a "privilege" group that ships with Kanidm, such as:
-
-- idm\_account\_manage\_priv
-- idm\_people\_read\_priv
-- idm\_schema\_manage\_priv
-- many more ...
-
-...indirectly grants you membership to "idm\_high\_privilege". If you are a member of this group,
-the standard "account" and "people" rights groups are NOT able to alter, read or manage these
-accounts. To manage these accounts higher rights are required, such as those held by the admin
-account.
-
-Further, groups that are considered "idm\_high\_privilege" can NOT be managed by the standard
-"idm\_group\_manage\_priv" group.
-
-Management of high privilege accounts and groups is granted through the the "hp" variants of all
-privileges. A non-conclusive list:
-
-- idm\_hp\_account\_read\_priv
-- idm\_hp\_account\_manage\_priv
-- idm\_hp\_account\_write\_priv
-- idm\_hp\_group\_manage\_priv
-- idm\_hp\_group\_write\_priv
-
-Membership of any of these groups should be considered to be equivalent to system administration
-rights in the directory, and by extension, over all network resources that trust Kanidm.
-
-All groups that are flagged as "idm\_high\_privilege" should be audited and monitored to ensure that
-they are not altered.