Authenticate to an external Keycloak instance

[ghost]

Hi Eric!

I'm trying to setup an Apiman 1.2.2.Final instance in Wildfly 10 to work with an external Keycloak 1.7 instance and it is getting difficult to correctly login with the admin user into the Apiman console ([apiman_server]:[port]/apimanui). I followed the setup steps of the Production Guide.
It is throwing this validation error message in Apiman's output:

11:49:32,468 ERROR [org.keycloak.adapters.OAuthRequestAuthenticator](default task-2) failed to turn code into token
11:49:32,469 ERROR [org.keycloak.adapters.OAuthRequestAuthenticator](default task-2) status from server: 400
11:49:32,470 ERROR [org.keycloak.adapters.OAuthRequestAuthenticator](default task-2) {"error_description":"Client secret not provided in request","error":"unauthorized_client"}

Keycloak's output:

12:42:39,443 WARN [org.keycloak.events](default task-11) type=CODE_TO_TOKEN_ERROR, realmId=apiman, clientId=apimanui, userId=null, ipAddress=127.0.0.1, error=
invalid_client_credentials, grant_type=authorization_code

It is apparently obvious that it is because a wrong Client Secret. So I copied the client secrets of each client (apiman, apimanui, apiman-gateway-api) from Apiman realm in Keycloak to the standalone-apiman.xml, matching each secret with its corresponding secure-deployment tag, I didn't find another config where I can set the client secret. I've also set the corresponding realm values in the realm-public-key and auth-server-url tags of the standalone-apiman.xml and disabled the internal Keycloak instance.
I did also try to authenticate with a new Keycloak 1.9 instance, but I got the same result.

Am I missing some configuration or doing something wrong?

Added part of my standalone-apiman.xml below.

Thanks a lot in advance!

• Santiago

    <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
        <realm name="apiman">
            <realm-public-key>MIGfM...........AB</realm-public-key>
            <auth-server-url>http://localhost:8180/auth</auth-server-url>
            <ssl-required>none</ssl-required>
            <enable-cors>false</enable-cors>
            <principal-attribute>preferred_username</principal-attribute>
        </realm>
        <secure-deployment name="apiman.war">
            <realm>apiman</realm>
            <resource>apiman</resource>
            <bearer-only>true</bearer-only>
            <enable-basic-auth>true</enable-basic-auth>
            <disable-trust-manager>true</disable-trust-manager>
            <credential name="secret">9475b660-0035-432c-bf03-ca736f1e7391</credential>
        </secure-deployment>
        <secure-deployment name="apimanui.war">
            <realm>apiman</realm>
            <resource>apimanui</resource>
            <public-client>true</public-client>
            <disable-trust-manager>true</disable-trust-manager>
            <credential name="secret">5a140d95-eeab-4499-8020-bbc0909de8a8</credential>
        </secure-deployment>
        <secure-deployment name="apiman-gateway-api.war">
            <realm>apiman</realm>
            <resource>apiman-gateway-api</resource>
            <bearer-only>true</bearer-only>
            <enable-basic-auth>true</enable-basic-auth>
            <disable-trust-manager>true</disable-trust-manager>
            <credential name="secret">9c32a99c-5d6a-408d-bd69-a7cff6d1092b</credential>
        </secure-deployment>
    </subsystem>

[EricWittmann]

Hi Santiago.

Yeah, our apiman realm file is more of a starting point than anything - it requires some tweaking and poking in order to get it working with an external KC server.

For this problem I think you can try two different things.

First, try removing the element from the secure-deployment config for the "apimanui.war" app.

If that doesn't work, then you could switch all your clients (in the KC admin UI) to "Public" instead of "Confidential". That way a secret credential isn't required.

[ghost]

First try didn't work but the second one worked like a charm.

Thanks Eric.

[EricWittmann]

Yeah we've had some trouble with getting Confidential clients to work. I think @msavy may have some insight into it. :)