refactor: rename Management API -> Identity API (#366)

* refactor: rename Management API -> Identity API

* refactor files, class names, etc.

.github/workflows/apidoc.yaml

@@ -30,7 +30,7 @@ jobs:
     runs-on: ubuntu-latest
     strategy:
       matrix:
-        apiGroup: [ 'ih-resolution-api', 'ih-management-api' ]
+        apiGroup: [ 'ih-resolution-api', 'identity-api' ]
     env:
       rootDir: resources/openapi/yaml/${{ matrix.apiGroup }}
       SWAGGERHUB_API_KEY: ${{ secrets.SWAGGERHUB_TOKEN }}

.github/workflows/verify.yaml

@@ -54,7 +54,7 @@ jobs:
             -e "EDC_IH_IAM_PUBLICKEY_PATH=/opt/keys/key.pem" \
             -e "EDC_IH_IAM_ID=did:web:test" \
             -e "WEB_HTTP_IDENTITY_PORT=8182" \
-            -e "WEB_HTTP_IDENTITY_PATH=/api/management" \
+            -e "WEB_HTTP_IDENTITY_PATH=/api/identity" \
             -e "WEB_HTTP_RESOLUTION_PORT=10001" \
             -e "WEB_HTTP_RESOLUTION_PATH=/api/v1/resolution/" \
             identity-hub:latest

docs/developer/architecture/identity-trust-protocol/identity-and-trust-modules.md

@@ -6,9 +6,10 @@
 
 Contains the `VerifiablePresentationService` and a `CredentialManager`.<br/>
 Its job is to
+
 - generate and serve VPs (through the [Hub API](#hub-api))
-- CRUD VCs, for example when the Issuer wants to write a VC via the [Hub API](#management-api) or
-the [Management API](#management-api)
+- CRUD VCs, for example when the Issuer wants to write a VC via the [Hub API](#identity-api) or
+  the [Identity API](#identity-api)
 - run the `VerifiableCredentialManager`
 - exchanges protocol messages with the Issuer, e.g. in response to a credential-offer
 
@@ -18,7 +19,7 @@ is triggered , it moves into the `REISSUE_REQUESTING` state. Generally, renewals
 
 1. an incoming credential offer
 2. the state machine detects a nearing expiry (if auto-renewal is active)
-3. a manual action via the management API
+3. a manual action via the Identity API
 
 ## DID Module
 
@@ -28,7 +29,7 @@ Contains the `DidResourceManager`. Its job is to
 - publish/overwrite DID documents using the publishers
 - react to key rotation events from the [KeyPair module](#keypair-module): adds new keys to the DID, removes old ones,
   etc.
-- react to manual action via the management API
+- react to manual action via the Identity API
 
 ## KeyPair Module
 
@@ -37,7 +38,7 @@ Contains the `KeyPairStateMachine`. Its job is to
 - generate and maintain key pairs using a state machine
 - check for automatic renewal, e.g. if keys are configured with a max lifetime
 - send out events when a key is rotated
-- react to manual action via the management API
+- react to manual action via the Identity API
 
 ## Auth/Permission Module
 
@@ -80,7 +81,7 @@ the [Storage API](https://github.com/eclipse-tractusx/identity-trust/blob/main/s
 Is
 contains model classes, validators and JSON-LD-transformers.
 
-## Management API
+## Identity API
 
 This module contains implementations to maintain internal data structures, such as:
 

docs/developer/architecture/identity-trust-protocol/identity.hub.architecture.md

@@ -36,7 +36,7 @@ Two deployment topologies will be supported:
 A participant context (PC) functions as a unit of management and control for `identity resources` in the Identity Hub.
 All resources are contained and accessed through a PC. Contexts are tied to the participant identity as defined in
 the [DSP specifications](https://github.com/International-Data-Spaces-Association/ids-specification) and created through
-the [IH Management API](#311-elevated-privilege-operations).
+the [Identity API](#311-elevated-privilege-operations).
 
 Access control for public client API endpoints is scoped to a specific PC. For example, an access token as defined in
 the [Base Identity Protocol specification]() is associated with a specific context and may not be used to access
@@ -240,9 +240,9 @@ public class AccessDefinition {
 > Note read access should not since some resources should be public. However, for C-X a read token for most types should
 > be required.
 
-## 2.5. Management APIs
+## 2.5. Identity APIs
 
-The `Management API` executes authorized client requests to perform operational tasks against the Identity Hub
+The `Identity API` executes authorized client requests to perform operational tasks against the Identity Hub
 installation. Operations fall into two groups: those requiring elevated privileges that affect the installation as a
 whole, and those that are scoped to a specific participant context.
 
@@ -259,10 +259,10 @@ The following diagram depicts the Identity Hub module dependency graph:
 The term `installation` is used to denote an Identity Hub deployment that is operated as a unit. An `installation` may
 be a single runtime instance or a cluster of instances.
 
-## 3.1. Management API
+## 3.1. Identity API
 
-The `Management API` is executes authorized client requests to perform operational tasks against the Identity Hub
-installation.
+The `Identity API` executes authorized client requests to perform operational tasks against the Identity Hub
+installation such as adding or manipulating key pairs, DID documents etc.
 
 ### 3.1.1. Elevated Privilege Operations
 

docs/developer/architecture/identity-trust-protocol/identity.hub.modules.puml

@@ -20,7 +20,7 @@ title Identity Hub Modules
 
 frame "APIs" {
    component  "Hub API" as HubApi <<api module>>
-   component "Management API" as ManagementApi <<api module>>
+   component "Identity API" as IdentityApi <<api module>>
 }
 
 component "Aggregate Services Module" as AggregateServices
@@ -39,7 +39,7 @@ frame "Libraries" {
 }
 
 AggregateServices -up-> HubApi
-AggregateServices -up-> ManagementApi
+AggregateServices -up-> IdentityApi
 
 AuthModule -up-> AggregateServices
 

docs/developer/architecture/mgmt-api.security.md

@@ -1,4 +1,4 @@
-# On IdentityHub Management API security
+# On IdentityHub Identity API security
 
 ## 1. Definition of terms
 
@@ -11,10 +11,10 @@
   IdentityHub!**
 - _Participant context_: this is the unit of management, that owns all resources. Its identifier must be equal to
   the `participantId` that is defined
-  in [DSP](https://github.com/International-Data-Spaces-Association/ids-specification). For the purposes of management
+  in [DSP](https://github.com/International-Data-Spaces-Association/ids-specification). For the purposes of Identity
   API operations, IdentityHub assumes the ID of the `ParticipantContext` to be equal to the ID of
   the `ServicePrincipal`.
-- Management API: collective term for all endpoints that serve the purpose of managing participant contexts and their
+- Identity API: collective term for all endpoints that serve the purpose of managing participant contexts and their
   resources. Also referred to as: mgmt api
 - API Key: a secret string that is used to authenticate/authorize a request and that is typically sent in the HTTP
   header. Also referred to as: API token, API secret, credential
@@ -25,10 +25,10 @@
 
 ### 2.1 Authentication of ServicePrincipals
 
-When Management API requests are received by the web server, it (or a related function) must be able to derive
+When Identity API requests are received by the web server, it (or a related function) must be able to derive
 the `ServicePrincipal` from the request context. In other words, it must be able to determine which participant sent the
 request.
-For that, the Management API should employ methods that are widely known, such as Basic Auth or API keys.
+For that, the Identity API should employ methods that are widely known, such as Basic Auth or API keys.
 
 Authentication (=user identification) should happen before the request is matched onto a controller method, so that the
 handling controller method can inject the `ServicePrincipal` using standard JAX-RS features:
@@ -55,7 +55,7 @@ service is needed to perform the resource lookup.
 
 ### 2.3 Elevated access
 
-Some operations in the Management API _require_ elevated access rights, for example modifying participant contexts, or
+Some operations in the Identity API _require_ elevated access rights, for example modifying participant contexts, or
 listing resources across multiple participant contexts. The elevated access is tied to
 a [built-in role](#51-built-in-roles). The super-user has that role.
 
@@ -66,7 +66,7 @@ super-user's `ServicePrincipal` does not technically own a resource, permissions
 
 ### 3.1 Authenticating a request
 
-To access the Management API, every request must contain the `x-api-key` header, which contains the API key of the
+To access the Identity API, every request must contain the `x-api-key` header, which contains the API key of the
 participant. This is a string that contains the service principal's ID (=`spId`) followed by a randomly generated
 character sequence. Both parts are base64-encoded:
 
@@ -94,7 +94,7 @@ inject it for further processing.
 API keys are generated automatically when a new `ParticipantContext` is created. This API operation requires elevated
 access and can thus only be done by the super-user, and returns the new API key in the HTTP response.
 
-IdentityHub's Management API does not provide a feature for participant self-registration, as it is not an
+IdentityHub's Identity API does not provide a feature for participant self-registration, as it is not an
 end-user-facing API. This is intentional. New participant contexts must be created by the super-user.
 
 > The initial API key must be transmitted to the participant by the super-user in a secure out-of-band channel.
@@ -103,7 +103,7 @@ end-user-facing API. This is intentional. New participant contexts must be creat
 ### 3.3 Regenerating the API key
 
 Once the participant has received the initial API key, it is highly recommended that it is immediately regenerated using
-the Management API. Note that the initial API Key is required for that operation:
+the Identity API. Note that the initial API Key is required for that operation:
 
 ```shell
 curl -X POST -H "x-api-key: <initial-api-key>" "http://your-identityhub.com/.../v1/participants/<participant-id>/token"
@@ -157,9 +157,9 @@ a `KeyPairResource` with `id`.
 As mentioned before, the `AuthorizationService` is responsible to establish the link between service principal and
 resource. It is a normal service which can be injected into controller classes.
 
-Every management API module then contributes a _lookup function_ and the resource type it handles, which
+Every Identity API module then contributes a _lookup function_ and the resource type it handles, which
 the `AuthorizationService` maintains and to which it dispatches based on resource class. For example the DID document
-management API module:
+management Identity API module:
 
 ```java
 
@@ -259,7 +259,7 @@ permission levels may be required. Thus, the RBAC system used by EDC is extensib
 1. role concept
 2. access permissions based on roles
 
-#### 5.2.1 Customize roles via Management API
+#### 5.2.1 Customize roles via Identity API
 
 Roles are just labels that a `ParticipantContext` has attached to them, and there is no need for a complicated rule
 engine. The super-user can assign arbitrary roles to participants.
@@ -315,7 +315,7 @@ However, swapping out the authorization module is possible, and necessary if RBA
 
 ## 7. General security considerations
 
-- the Management API is **not** intended for public consumption and thus should **never** be exposed to the internet
+- the Identity API is **not** intended for public consumption and thus should **never** be exposed to the internet
   directly.
 - if management operations must be accessbile over the internet, additional security measures such as API gateways,
   firewalls, additional authorization frontends, etc. must be in place. The specifics of that are beyond the scope of an

e2e-tests/api-tests/src/test/java/org/eclipse/edc/identityhub/tests/DidManagementApiEndToEndTest.java

@@ -37,7 +37,7 @@
 import static org.mockito.Mockito.verifyNoInteractions;
 
 @EndToEndTest
-public class DidManagementApiEndToEndTest extends ManagementApiEndToEndTest {
+public class DidManagementApiEndToEndTest extends IdentityApiEndToEndTest {
 
     @Test
     void publishDid_notOwner_expect403() {
@@ -60,7 +60,7 @@ void publishDid_notOwner_expect403() {
         reset(subscriber); // need to reset here, to ignore a previous interaction
 
         // attempt to publish user1's DID document, which should fail
-        RUNTIME_CONFIGURATION.getManagementEndpoint().baseRequest()
+        RUNTIME_CONFIGURATION.getIdentityApiEndpoint().baseRequest()
                 .contentType(JSON)
                 .header(new Header("x-api-key", user2Token))
                 .body("""
@@ -89,7 +89,7 @@ void publishDid() {
         assertThat(Arrays.asList(token, superUserKey))
                 .allSatisfy(t -> {
                     reset(subscriber);
-                    RUNTIME_CONFIGURATION.getManagementEndpoint().baseRequest()
+                    RUNTIME_CONFIGURATION.getIdentityApiEndpoint().baseRequest()
                             .contentType(JSON)
                             .header(new Header("x-api-key", t))
                             .body("""
@@ -136,7 +136,7 @@ void unpublishDid_notOwner_expect403() {
         reset(subscriber); // need to reset here, to ignore a previous interaction
 
         // attempt to publish user1's DID document, which should fail
-        RUNTIME_CONFIGURATION.getManagementEndpoint().baseRequest()
+        RUNTIME_CONFIGURATION.getIdentityApiEndpoint().baseRequest()
                 .contentType(JSON)
                 .header(new Header("x-api-key", user2Token))
                 .body("""
@@ -165,7 +165,7 @@ void unpublishDid() {
         assertThat(Arrays.asList(token, superUserKey))
                 .allSatisfy(t -> {
                     reset(subscriber);
-                    RUNTIME_CONFIGURATION.getManagementEndpoint().baseRequest()
+                    RUNTIME_CONFIGURATION.getIdentityApiEndpoint().baseRequest()
                             .contentType(JSON)
                             .header(new Header("x-api-key", t))
                             .body("""
@@ -198,7 +198,7 @@ void getState_nowOwner_expect403() {
         var user2 = "user2";
         var token2 = createParticipant(user2);
 
-        RUNTIME_CONFIGURATION.getManagementEndpoint().baseRequest()
+        RUNTIME_CONFIGURATION.getIdentityApiEndpoint().baseRequest()
                 .header(new Header("x-api-key", token2))
                 .contentType(JSON)
                 .body(""" 
@@ -217,7 +217,7 @@ void getAll() {
         var superUserKey = createSuperUser();
         range(0, 20).forEach(i -> createParticipant("user-" + i));
 
-        var docs = RUNTIME_CONFIGURATION.getManagementEndpoint().baseRequest()
+        var docs = RUNTIME_CONFIGURATION.getIdentityApiEndpoint().baseRequest()
                 .contentType(JSON)
                 .header(new Header("x-api-key", superUserKey))
                 .get("/v1alpha/dids")
@@ -234,7 +234,7 @@ void getAll_withDefaultPaging() {
         var superUserKey = createSuperUser();
         range(0, 70).forEach(i -> createParticipant("user-" + i));
 
-        var docs = RUNTIME_CONFIGURATION.getManagementEndpoint().baseRequest()
+        var docs = RUNTIME_CONFIGURATION.getIdentityApiEndpoint().baseRequest()
                 .contentType(JSON)
                 .header(new Header("x-api-key", superUserKey))
                 .get("/v1alpha/dids")
@@ -251,7 +251,7 @@ void getAll_withPaging() {
         var superUserKey = createSuperUser();
         range(0, 20).forEach(i -> createParticipant("user-" + i));
 
-        var docs = RUNTIME_CONFIGURATION.getManagementEndpoint().baseRequest()
+        var docs = RUNTIME_CONFIGURATION.getIdentityApiEndpoint().baseRequest()
                 .contentType(JSON)
                 .header(new Header("x-api-key", superUserKey))
                 .get("/v1alpha/dids?offset=5&limit=10")
@@ -268,7 +268,7 @@ void getAll_notAuthorized() {
 
         var attackerToken = createParticipant("attacker");
 
-        RUNTIME_CONFIGURATION.getManagementEndpoint().baseRequest()
+        RUNTIME_CONFIGURATION.getIdentityApiEndpoint().baseRequest()
                 .contentType(JSON)
                 .header(new Header("x-api-key", attackerToken))
                 .get("/v1alpha/dids")

e2e-tests/api-tests/src/test/java/org/eclipse/edc/identityhub/tests/ManagementApiEndToEndTest.java → e2e-tests/api-tests/src/test/java/org/eclipse/edc/identityhub/tests/IdentityApiEndToEndTest.java

@@ -41,9 +41,9 @@
 import java.util.Map;
 
 /**
- * Base class for all management API tests
+ * Base class for all Identity API tests
  */
-public abstract class ManagementApiEndToEndTest {
+public abstract class IdentityApiEndToEndTest {
     public static final String SUPER_USER = "super-user";
     protected static final IdentityHubRuntimeConfiguration RUNTIME_CONFIGURATION = IdentityHubRuntimeConfiguration.Builder.newInstance()
             .name("identity-hub")