chore(identity): rename C8 component from indentity to admin

[joaquinfelici]

Pull Request Template

Description

related to camunda/camunda#44432

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactoring (no functional changes)
• Test-only changes (no production code changes)

Testing Checklist

Black-Box Testing Requirements

• Tests follow black-box testing approach: verify behavior through observable outputs (logs, C8 API queries, real-world skip scenarios)
• Tests DO NOT access implementation details (DbClient, IdKeyMapper, ..impl.. packages except logging constants)
• Architecture tests pass (ArchitectureTest validates these rules)

Test Coverage

• Added tests for new functionality
• Updated tests for modified functionality
• All tests pass locally

Architecture Compliance

Run architecture tests to ensure compliance:

mvn test -Dtest=ArchitectureTest

If architecture tests fail, refactor your tests to use:

• LogCapturer for log assertions
• camundaClient.new*SearchRequest() for C8 queries
• Real-World skip scenarios (e.g., migrate children without parents)

Documentation

• Updated TESTING_GUIDELINES.md if adding new test patterns
• Added Javadoc comments for public APIs
• Updated README if user-facing changes

Checklist

• Code follows project style guidelines
• Self-reviewed the code
• Added comments for complex logic
• No new compiler warnings
• Dependent changes have been merged

Related Issues

[tasso94]

Looks good to me. 👍

Two points that are not related to this PR, but we should follow up IMO:

1. With the log output Authorization with ID [dc09b223-125c-11f1-bc85-d251a5285969] was skipped: Permission type [UPDATE] is not supported for resource type [DecisionDefinition], it is hard to understand from a user perspective exactly which authorization is meant. Can we make logs, in general, more verbose and log user/group, permissions, and resource IDs? The authorization ID is a technical detail that users will have difficulty following up on. This one is even less helpful Authorization with ID [bcb6b8ac-63e4-11f0-8c26-5682f3a431b7] was skipped: Failed to migrate authorization with legacy ID: bcb6b8ac-63e4-11f0-8c26-5682f3a431b7
2. We are logging exceptions in error situations, which we don't do for the runtime and history migrator. We do that, but only in unexpected situations. Also, as a user, I must understand from the exception stack trace what's wrong. Can we avoid logging exception stack traces for common cases like 'authorization already exists'?

2026-02-25T16:28:25.835+01:00 ERROR 53572 --- [           main] i.c.m.data.impl.util.ExceptionUtils      : Failed to migrate authorization with legacy ID: bcae2d10-63e4-11f0-8c26-5682f3a431b7

io.camunda.migration.data.exception.IdentityMigratorException: Failed to migrate authorization with legacy ID: bcae2d10-63e4-11f0-8c26-5682f3a431b7
	at io.camunda.migration.data.impl.util.ExceptionUtils.wrapException(ExceptionUtils.java:78)
	at io.camunda.migration.data.impl.util.ExceptionUtils.callApi(ExceptionUtils.java:52)
	at io.camunda.migration.data.impl.clients.C8Client.createAuthorization(C8Client.java:421)
	at io.camunda.migration.data.IdentityMigrator.migrateAuthorization(IdentityMigrator.java:132)
	at io.camunda.migration.data.IdentityMigrator.lambda$migrateAuthorizations$2(IdentityMigrator.java:108)
	at org.springframework.transaction.support.TransactionOperations.lambda$executeWithoutResult$0(TransactionOperations.java:68)
	at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:137)
	at org.springframework.transaction.support.TransactionOperations.executeWithoutResult(TransactionOperations.java:67)
	at io.camunda.migration.data.IdentityMigrator.lambda$migrateAuthorizations$3(IdentityMigrator.java:108)
	at io.camunda.migration.data.IdentityMigrator.lambda$fetchAndHandleSkippedAuthorizations$4(IdentityMigrator.java:225)
	at io.camunda.migration.data.impl.clients.DbClient.fetchAndHandleSkippedForType(DbClient.java:186)
	at io.camunda.migration.data.IdentityMigrator.fetchAndHandleSkippedAuthorizations(IdentityMigrator.java:221)
	at io.camunda.migration.data.IdentityMigrator.fetchAuthorizationsToMigrate(IdentityMigrator.java:211)
	at io.camunda.migration.data.IdentityMigrator.migrateAuthorizations(IdentityMigrator.java:107)
	at io.camunda.migration.data.IdentityMigrator.migrate(IdentityMigrator.java:80)
	at io.camunda.migration.data.IdentityMigrator.start(IdentityMigrator.java:67)
	at io.camunda.migration.data.app.MigratorApp.migrateIdentity(MigratorApp.java:236)
	at io.camunda.migration.data.app.MigratorApp.runMigratorsInOrder(MigratorApp.java:196)
	at io.camunda.migration.data.app.MigratorApp.main(MigratorApp.java:85)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at org.springframework.boot.loader.launch.Launcher.launch(Launcher.java:106)
	at org.springframework.boot.loader.launch.Launcher.launch(Launcher.java:64)
	at org.springframework.boot.loader.launch.PropertiesLauncher.main(PropertiesLauncher.java:580)
Caused by: io.camunda.client.api.command.ProblemException: Failed with code 409: 'Conflict'. Details: 'class ProblemDetail {
    type: about:blank
    title: ALREADY_EXISTS
    status: 409
    detail: Command 'CREATE' rejected with code 'ALREADY_EXISTS': Expected to create authorization for owner 'jonny1' for resource identifier 'jonny1', but an authorization for this resource identifier already exists.
    instance: /v2/authorizations
}'
	at io.camunda.client.impl.http.ApiCallback.handleErrorResponse(ApiCallback.java:149)
	at io.camunda.client.impl.http.ApiCallback.completed(ApiCallback.java:74)
	at io.camunda.client.impl.http.ApiCallback.completed(ApiCallback.java:34)
	at org.apache.hc.core5.concurrent.BasicFuture.completed(BasicFuture.java:148)
	at org.apache.hc.core5.concurrent.ComplexFuture.completed(ComplexFuture.java:72)
	at org.apache.hc.client5.http.impl.async.InternalAbstractHttpAsyncClient$2$1.completed(InternalAbstractHttpAsyncClient.java:321)
	at org.apache.hc.core5.http.nio.support.AbstractAsyncResponseConsumer$1.completed(AbstractAsyncResponseConsumer.java:101)
	at org.apache.hc.core5.http.nio.entity.AbstractBinAsyncEntityConsumer.completed(AbstractBinAsyncEntityConsumer.java:87)
	at org.apache.hc.core5.http.nio.entity.AbstractBinDataConsumer.streamEnd(AbstractBinDataConsumer.java:83)
	at org.apache.hc.core5.http.nio.support.AbstractAsyncResponseConsumer.streamEnd(AbstractAsyncResponseConsumer.java:142)
	at org.apache.hc.client5.http.impl.async.HttpAsyncMainClientExec$1.streamEnd(HttpAsyncMainClientExec.java:283)
	at org.apache.hc.core5.http.impl.nio.ClientHttp1StreamHandler.dataEnd(ClientHttp1StreamHandler.java:285)
	at org.apache.hc.core5.http.impl.nio.ClientHttp1StreamDuplexer.dataEnd(ClientHttp1StreamDuplexer.java:371)
	at org.apache.hc.core5.http.impl.nio.AbstractHttp1StreamDuplexer.onInput(AbstractHttp1StreamDuplexer.java:340)
	at org.apache.hc.core5.http.impl.nio.AbstractHttp1IOEventHandler.inputReady(AbstractHttp1IOEventHandler.java:64)
	at org.apache.hc.core5.http.impl.nio.ClientHttp1IOEventHandler.inputReady(ClientHttp1IOEventHandler.java:41)
	at org.apache.hc.core5.reactor.InternalDataChannel.onIOEvent(InternalDataChannel.java:139)
	at org.apache.hc.core5.reactor.InternalChannel.handleIOEvent(InternalChannel.java:51)
	at org.apache.hc.core5.reactor.SingleCoreIOReactor.processEvents(SingleCoreIOReactor.java:176)
	at org.apache.hc.core5.reactor.SingleCoreIOReactor.doExecute(SingleCoreIOReactor.java:125)
	at org.apache.hc.core5.reactor.AbstractSingleCoreIOReactor.execute(AbstractSingleCoreIOReactor.java:92)
	at org.apache.hc.core5.reactor.IOReactorWorker.run(IOReactorWorker.java:44)
	at java.base/java.lang.Thread.run(Thread.java:1583)

[joaquinfelici]

Hey @tasso94 ,

Good points. I agree with both. The reason for point 2 is that the callApi() method by default logs the exception stack trace when something goes wrong, I guess we can create another method for cases like this. I will create a follow-up to tackle these two enhancements.

Edit: #1043