Introduce wildcard authorization

_docs_integrate/migration-from-v6-to-v7.md

@@ -37,11 +37,10 @@ The step-by-step instructions can be consulted to start the migration to version
   For this reason, the old data must be deleted.
   Alternatively, the database can be deleted as a whole and [set up again]({% link _docs_operate/setup-with-docker-compose.md %}).
 - The [image](https://github.com/nmshd/connector?tab=readme-ov-file#connector) used to run the Connector must be updated to version 7.
-- The [configuration]({% link _docs_operate/configuration.md %}) value `database.dbNamePrefix` of the Connector was removed. Before, it defaulted to `acc-`. If you want to access a database called `acc-connector`, you have to set the `database.dbName` configuration value to `acc-connector` instead of `connector` only.
-- Configuring API keys for the Connector has changed.
-  - The `apiKey` property in the configuration file has been replaced by a more structured configuration under `authentication.apiKey.keys.<key-id>.key`.
-  - Additionally, the support for the `API_KEY` environment variable has been removed, that could be used to define an API key using a short environment variable. As an alternative, the `authentication.apiKey.keys.<key-id>.key` configuration property can be set using an [environment variable]({% link _docs_operate/configuration.md %}#environment-variables).
-  - You can read more about the authentication configuration in the [configuration documentation]({% link _docs_operate/configuration.md %}#authentication).
+- Some changes must be made to the [configuration]({% link _docs_operate/configuration.md %}) of the Connector.
+  - The `database.dbNamePrefix` field of the [database configuration]({% link _docs_operate/configuration.md %}#database) was removed. Before, it defaulted to `acc-`. If a database called `acc-connector` is to be accessed, the value of the `database.dbName` field must be set to `acc-connector` instead of `connector` only.
+  - To support additional authentication methods beyond API key authentication, the `apiKey` field was replaced by the `authentication.apiKey.keys.<key-id>.key` parameter of the [authentication configuration]({% link _docs_operate/configuration.md %}#authentication). The `authentication.apiKey.keys.<key-id>.scopes` field provides a convenient way to configure the permissions that apply when the API key identified by `<key-id>` is used.
+  - Additionally, the support for the `API_KEY` [environment variable]({% link _docs_operate/configuration.md %}#environment-variables) has been removed, that could be used to define an API key using a short environment variable. As an alternative, the `authentication.apiKey.keys.<key-id>.key` configuration property can be set using an environment variable.
 
 ### Removed and Changed Data Structures
 

_docs_operate/configuration.md

@@ -348,6 +348,14 @@ The `apiKey` authentication method is used to authenticate requests using an API
 
     The date and time when the API key expires. This is optional and can be used to automatically disable the API key after a certain period of time. The date must be in ISO 8601 format (e.g. `2063-10-01T00:00:00Z`).
 
+  - **scopes** `optional`
+
+    An optional array of strings that defines roles, specifying the permissions granted to anyone using the API key.
+    By default, administrator rights are assigned, represented explicitly by `"**"`, providing unrestricted access.
+    Roles can also be limited to specific resources, for example, `"core:messages"` allows access only to the Connector routes related to messages.
+    A wildcard `"*"` can be used within a namespace to allow access to every resource in that namespace.
+    For instance, `core:*` allows access to `core:messages`, `core:relationships`, and any other resources within the `core` namespace.
+
 ###### jwtBearer
 
 **Example Configuration:**