feat: add SYSTEM_OWNER role (#6765)

* define roles and permissions

* support system user memberships

* don't limit system users

* cleanup permissions

* restrict memberships to aggregates

* default to SYSTEM_OWNER

* update unit tests

* test: system user token test (#6778)

* update unit tests

* refactor: make authz testable

* move session constants

* cleanup

* comment

* comment

* decode member type string to enum (#6780)

* decode member type string to enum

* handle all membership types

* decode enums where necessary

* decode member type in steps config

* update system api docs

* add technical advisory

* tweak docs a bit

* comment in comment

* lint

* extract token from Bearer header prefix

* review changes

* fix tests

* fix: add fix for activityhandler

* add isSystemUser

* remove IsSystemUser from activity info

* fix: add fix for activityhandler

---------

Co-authored-by: Stefan Benz <stefan@caos.ch>

docs/docs/guides/integrate/access-zitadel-system-api.md

@@ -49,6 +49,33 @@ SystemAPIUsers:
       KeyData: <base64 encoded value of system-user-1.pub>
 ```
 
+You can define memberships for the user as well:
+
+```yaml
+SystemAPIUsers:
+ - system-user-1:
+     Path: /system-user-1.pub
+     Memberships:
+       # MemberType System allows the user to access all APIs for all instances or organizations
+       - MemberType: System
+         Roles:
+           - "SYSTEM_OWNER"
+           - "IAM_OWNER"
+           - "ORG_OWNER"
+       # MemberType IAM and Organization let you restrict access to a specific instance or organization by specifying the AggregateID
+       - MemberType: IAM
+         Roles: "IAM_OWNER"
+         AggregateID: "123456789012345678"
+       - MemberType: Organization
+         Roles: "ORG_OWNER"
+         AggregateID: "123456789012345678"
+ - superuser2:
+     # If no memberships are specified, the user has a membership of type System with the role "SYSTEM_OWNER"
+     KeyData: <base64 encoded key>     # or you can directly embed it as base64 encoded value
+```
+
+If you don't specify any memberships, you are allowed to access the whole [ZITADEL System API](/apis/resources/system).
+
 ## Generate JWT
 
 Similar to the OAuth 2.0 JWT Profile, we will create and sign a JWT. For this API, the JWT will not be used to authenticate against ZITADEL Authorization Server, but rather directly to the API itself.
@@ -145,8 +172,6 @@ You should get a successful response with a `totalResult` number of 1 and the de
 }
 ```
 
-With this token you are allowed to access the whole [ZITADEL System API](/apis/resources/system).
-
 ## Summary
 
 * Create an RSA keypair

docs/docs/support/advisory/a10007.md

@@ -0,0 +1,63 @@
+---
+title: Technical Advisory 10007
+---
+
+## Date and Version
+
+Version: Upcoming
+
+Date: Upcoming
+
+## Affected Users
+
+This advisory applies to self-hosted ZITADEL installations with custom roles to permissions mappings in the *InternalAuthZ.RolePermissionMappings* configuration section.
+
+## Description
+
+In upcoming ZITADEL versions, RBAC also applies to [system users defined in the ZITADEL runtime configuration](/guides/integrate/access-zitadel-system-api#runtime-configuration).
+This enables fine grained access control to the system API as well as other APIs for system users.
+ZITADEL defines the new default roles *SYSTEM_OWNER* and *SYSTEM_OWNER_VIEWER*.
+System users without any memberships defined in the configuration will be assigned the *SYSTEM_OWNER* role.
+**Self-hosting users who define their own custom mapping at the *InternalAuthZ.RolePermissionMappings* configuration section**, have to define the *SYSTEM_OWNER* role in their configuration too to be able to access the system API with the default system user membership.
+
+## Statement
+
+This change is tracked in the following PR: [feat: add SYSTEM_OWNER role](https://github.com/zitadel/zitadel/pull/6765).
+As soon as the release version is published, we will include the version here.
+
+## Mitigation
+
+If you have a custom role mapping configured, make sure you configure the new role *SYSTEM_OWNER* before migrating to upcoming ZITADEL versions.
+As a reference, these are the default mappings:
+
+```yaml
+InternalAuthZ:
+  RolePermissionMappings:
+    - Role: "SYSTEM_OWNER"
+      Permissions:
+        - "system.instance.read"
+        - "system.instance.write"
+        - "system.instance.delete"
+        - "system.domain.read"
+        - "system.domain.write"
+        - "system.domain.delete"
+        - "system.debug.read"
+        - "system.debug.write"
+        - "system.debug.delete"
+        - "system.feature.write"
+        - "system.limits.write"
+        - "system.limits.delete"
+        - "system.quota.write"
+        - "system.quota.delete"
+        - "system.iam.member.read"
+    - Role: "SYSTEM_OWNER_VIEWER"
+      Permissions:
+        - "system.instance.read"
+        - "system.domain.read"
+        - "system.debug.read"
+...
+```
+
+## Impact
+
+If the system users don't have the correct memberships and roles which resolve to permissions, the system users lose access to the system API. 

docs/docs/support/technical_advisory.mdx

@@ -130,6 +130,18 @@ We understand that these advisories may include breaking changes, and we aim to
     <td>2.39.0</td>
     <td>Calendar week 41/42 2023</td>
   </tr>
+  <tr>
+    <td>
+      <a href="./advisory/a10007">A-10006</a>
+    </td>
+    <td>Additional grant to cockroach database user</td>
+    <td>Breaking Behaviour Change</td>
+    <td>
+      Upcoming Versions require the SYSTEM_OWNER role to be available in the permission role mappings. Self-hosting ZITADEL users who define custom permission role mappings need to make sure their system users don't lose access to the system API.
+    </td>
+    <td>Upcoming</td>
+    <td>Upcoming</td>
+  </tr>
 </table>
 
 ## Subscribe to our Mailing List