Identity 8.4.3 - Failing to connect to an OpenID Connect provider - Microsoft Entra ID

Hello,

I’m trying to run identity service following the guide Connect to an OpenID Connect provider guide. But identity is not correctly starting on our environment.

The only error messages I can see in the identity log are:

2024-02-20 07:12:25.825 ERROR 1 — [ main] i.c.i.i.k.c.KeycloakConfiguration : Failure #1. Unable to connect to Keycloak.
2024-02-20 07:12:55.826 WARN 1 — [ main] i.c.i.i.k.c.KeycloakConfiguration : Retrying…
2024-02-20 07:12:55.829 ERROR 1 — [ main] i.c.i.i.k.c.KeycloakConfiguration : Failure #2. Unable to connect to Keycloak.
2024-02-20 07:13:25.829 WARN 1 — [ main] i.c.i.i.k.c.KeycloakConfiguration : Retrying…

I’m wondering also if there isn’t another spring profile to activate?

In the startup log I can see:

2024-02-20 07:12:19.005 INFO 1 — [ main] i.c.i.Application : Starting Application using Java 17.0.10 with PID 1 (/app/identity.jar started by camunda in /app)
2024-02-20 07:12:19.035 DEBUG 1 — [ main] i.c.i.Application : Running with Spring Boot v3.1.6, Spring v6.0.14
2024-02-20 07:12:19.043 INFO 1 — [ main] i.c.i.Application : The following 1 profile is active: “keycloak”

Our Camunda 8 SM infrastructure is deployed using Terraform to AWS ECS Fargate and I’ve set all the documented environment variables at the AWS task definition level:

CAMUNDA_IDENTITY_TYPE=MICROSOFT
CAMUNDA_IDENTITY_ISSUER=https://login.microsoftonline.com//v2.0
CAMUNDA_IDENTITY_ISSUER_BACKEND_URL=https://login.microsoftonline.com//v2.0
CAMUNDA_IDENTITY_CLIENT_ID=<Client ID from step 1>
CAMUNDA_IDENTITY_CLIENT_SECRET=<Client secret from step 3>
CAMUNDA_IDENTITY_AUDIENCE=<Client ID from step 1>

BR
Pascal

I have the impression despite the keycloak reference in the error message, it is maybe simply related to the TLS connection not correctly define for my AWS ECS service.

As read in Troubleshooting Identity

I will pursue my investigations…

[Update] Tried to mount a volume containing our java keystore → same errors

Where KeyCloak Server is running? Based on the error log, it’s unable to connect. Is Camunda 7 running on premise or cloud?

Hello,
This is a Camunda 8 self-managed deployment with, based on the referenced guide, access to Microsoft Entra ID as OpenID.
BR

So no Keycloak running

From Camunda release doc:

Bring your own OIDC Identity Provider

Prior to this functionality, it was necessary to use Keycloak and configure a third-party Identity Provider within Keycloak. Now a Camunda administrator can easily configure their own OpenID Connect (OIDC) Identity Provider directly in the HELM Charts for all Camunda components at one time, removing the need for Keycloak. To speed up configuration for Microsoft Entra (formerly known as Microsoft Azure AD), a detailed guide has been published in the documentation.

Did you apply the changes to helm chart.

global:
identity:
auth:
issuer: https://login.microsoftonline.com/<Client ID from step 1>/v2.0
# this is used for container to container communication
issuerBackendUrl: https://login.microsoftonline.com//v2.0
tokenUrl: https://login.microsoftonline.com//oauth2/v2.0/token
jwksUrl: https://login.microsoftonline.com//discovery/v2.0/keys
type: “MICROSOFT”

You might be missed updating the helm chart value, where type is not changed to MICROSOFT.

zeebe:
clientId: <Client ID from step 1>
audience: <Client ID from step 1>
existingSecret: <Client secret from step 3>
tokenScope: “<Client ID from step 1>/.default”

Please cross check your configuration.

I’m not using Helm chart but the environment variables in my Terraform script (AWS ECS Fargate):

container_definitions = jsonencode([
{
name = “identity-image”
image = “camunda/identity:${var.CAMUNDA_PLATFORM_VERSION}”
portMappings = [

environment = [
{
name = “CAMUNDA_IDENTITY_TYPE”
value = “MICROSOFT”
},
{
name = “CAMUNDA_IDENTITY_ISSUER”
value = “https://login.microsoftonline.com/XXXXXXXXXXXXXXXXXX/v2.0
},
{
name = “CAMUNDA_IDENTITY_ISSUER_BACKEND_URL”
value = “https://login.microsoftonline.com/XXXXXXXXXXXXXXXXXX/v2.0
},
{
name = “CAMUNDA_IDENTITY_CLIENT_ID”
value = “XXXXXXXXXXXXXXXXXX”
},
{
name = “CAMUNDA_IDENTITY_CLIENT_SECRET”
value = “XXXXXXXXXXXXXXXXXX”
},
{
name = “CAMUNDA_IDENTITY_AUDIENCE”
value = “XXXXXXXXXXXXXXXXXX”
},
{
name = “IDENTITY_LOG_LEVEL”
value = “DEBUG”
}
]

As described in the guide

I have not yet tested the Entra ID. Will test the similar setup and let you know the results.

1 Like

But something odd in the configuration. Looking at the guide Using existing Keycloak | Camunda 8 Docs, I can see in the helm chart the property:
identity:
keycloak:
enabled: false
But nothing like that for the Connect to an OpenID Connect provider documentation.

Hi @lugon - does the Identity container not start, or are you unable to access the UI? Identity with a custom OIDC provider currently does not provide a UI (I believe roadmap is to reintroduce the UI in the 8.5 release).

Hi,
I wasn’t so far with my POC…

After scripted, with Terraform, the deployment of the “core” services (based on docker-compose-core.yaml), I was trying to deploy identity.

After 6 tries, the service just exit.

2024-02-22 05:24:43.038 ERROR 1 — [ main] i.c.i.i.k.c.KeycloakConfiguration : RESTEASY004655: Unable to invoke request: org.apache.http.conn.HttpHostConnectException: Connect to localhost:18080 [localhost/127.0.0.1] failed: Connection refused

I’m still wondering if there is not a specific spring profile to activate?

@lugon - I just had a chat with the Identity engineers, and I misunderstood how this feature works! We are going to work some updates to documentation to make this more clear …

When using a custom OIDC provider, Identity isn’t needed at all. You don’t need to start that container/pod. Each component (Operate, Optimize, etc.) communicates with the OIDC provider directly. In other words, it is expected for that container/pod to fail to start in this configuration!

In the upcoming 8.5 release, the Identity service will have new features that further enable custom integrations, and the image may be needed then. But not for 8.4!

Hopefully that helps!

It makes more sense. I will try to update my Terraform scripts accordingly.
Thx for the feedback

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.