BASIC authentication for application on Wildfly with users in keycloak

[Subijay Bhattacharya]

We have been using keycloak adapter with Wildlfy 26 and we added keycloak as a separate subsystem, security-realm and security-domain. It is working fine.
I know Wildfly 26+ now comes with elytron-oidc-client subsystem and thus there is no need for installing the keycloak adapter separately.

In our EAR file we have few WAR files. Some of them are web consoles and needs the OIDC's Keycloak redirect behaviour. While others are WAR files that exposes REST or SOAP APIs and these APIs support BASIC authentication. The users of these authentication also reside in keycloak.

For implementing the web console redirection, I can follow https://github.com/wildfly-security-incubator/elytron-examples/tree/main/simple-webapp-oidc

However, I am not clear on how to tackle the BASIC authentication. What I am looking for is https://github.com/wildfly-security-incubator/elytron-examples/tree/main/resteasy-client-integration but instead of authenticating the users against wildfly, I want it to be authenticated against keycloak.

If I can retrieve a bearer token using credentials obtained from Basic auth - it should also be fine.

Could you please help me on this? How I can achieve this w/o Keycloak adapter?

Thanks

Subijay

[Diana Krepinska]

Hello Subijay,

I am not sure if this is answering your question. But does configuration like this https://github.com/wildfly-security/wildfly-elytron/blob/1.x/tests/base/src/test/resources/org/wildfly/security/sasl/oauth2/wildfly-oauth2-test-config-v1_0.xml#L80 cover what you need? you can configure resource owner credentials that would contain credentials from BASIC and configure an endpoint token from where the bearer token can be retrieved.

[Subijay Bhattacharya]

Thanks Diana for the reply.

The configuration that you provided - I am looking something like that. But instead of any configuration, can I do it via code (dynamically)? My users will reside in keycloak and they are not predefined. It can be any user. My application will receive the credentials (BASIC) in http header (Authorization header) and my application need to validate the credentials against keycloak.

I was hoping if this class can be used somehow?  org.wildfly.security.http.oidc.BasicAuthRequestAuthenticator present in wildfly-elytron-http-oidc-1.19.1.Final.jar

Thanks

Subijay

[Diana Krepinska]

Yes, the org.wildfly.security.http.oidc.BasicAuthRequestAuthenticator class does seem to be doing what you are asking for, it retrieves the credentials from the authorization header and uses them to get the bearer token. There is no example for this yet, but this class should be used when you have basic enabled for the deployment, which can be configured by using "enable-basic-auth" property in your oidc.json file

[Subijay Bhattacharya]

Thanks Diana.

I would like to try out using the class org.wildfly.security.http.oidc.BasicAuthRequestAuthenticator but I am not sure how to pass the OidcHttpFacade.

new BasicAuthRequestAuthenticator( OidcHttpFacade facade ,  OidcClientConfiguration oidcClientConfiguration);

Is this something you can help? How to create the  OidcHttpFacade 

I figured out how to pass OidcClientConfiguration.

Thanks

Subijay

[Farah Juma]

Hi Subijay,

The ability to retrieve a bearer token using credentials obtained from Basic auth was added to elytron-oidc-client starting in WildFly 26.1.2.Final.

Were you already using this functionality with the previous Keycloak OIDC adapter?

If you were previously using this functionality via keycloak subsystem configuration, you should be able to copy/paste the same configuration into the elytron-oidc-client subsystem instead.

If you were previously using this functionality via a keycloak.json file, you should be able to rename that file to oidc.json and update the auth-method in your application's web.xml file to OIDC instead of KEYCLOAK.

As Diana mentioned, the main thing needed to enable this is to set enable-basic-auth to true in either the elytron-oidc-client subsystem configuration or in your application's oidc.json configuration.

We don't have an example for this yet but could create one if that would be helpful.

In the meantime, you could check out some of our other OIDC related examples to see how configuration for elytron-oidc-client can be added:

https://wildfly-security.github.io/wildfly-elytron/blog/securing-wildfly-apps-openid-connect/

https://wildfly-security.github.io/wildfly-elytron/blog/bearer-only-support-openid-connect/

[Subijay Bhattacharya]

Hi Farah,

Thanks for the updates. I have seen the OIDC examples and have tried myself. They will certainly help me with the OIDC redirection part.

However, it will be really helpful you can create an example for the basic auth.

I can provide some info on how we are doing this today with keycloak adapters.

We do things a bit programmatically. So we implemented org.keycloak.adapters.KeycloakConfigResolver.

class MyResolver implements  KeycloakConfigResolver {

    @Override

    public KeycloakDeployment resolve(OIDCHttpFacade.Request request) {

        // We create org.keycloak.representations.adapters.config.AdapterConfig

        // we set setEnableBasicAuth to true if a deployment (where we expose rest and soap api) needs BASIC authentication. Else we set it to false.

    }

}

Then we implemented a filter class extending org.keycloak.adapters.servlet.KeycloakOIDCFilter

class MyBasicAuthFilter extends  KeycloakOIDCFilter {

    @Override

    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain){

        super.doFilter(........)

    }

}

And register the filter in web.xml. The keycloak filter class takes care of the rest. It also sends the response with 403/401 if unauthenticated

I see in wildfly there is also a OidcClientConfigurationResolver class which I can potentially use in place of  KeycloakConfigResolver.

What I do not see is the substitute of  KeycloakOIDCFilter class. Even if it is not present, its fine. I can change my doFilter() implementation to validate the BASIC credential. And for this I was looking for a class in Wildfly that can perform the job. And org.wildfly.security.http.oidc.BasicAuthRequestAuthenticator looked promising.

However, if there is alternative way to achieve this, I will be happy to try that out as well. So, if you can come up with any example, it will be helpful.

[Subijay Bhattacharya]

Hi Farah,

I was able to use "resteasy-client-integration-example" project and converted it to OIDC for BASIC auth and now its getting authenticated against users present in my keycloak. Thanks for the guide. 

I tested the "hello" service using curl and also from postman. All good. However, when I hit the url from browser, the browser does not prompt for credentials. With BASIC auth I believe the browser has to prompt the user to enter credential (example attached). Rather, I get Bad Request. If I make "Standard flow" option switched ON in Keycloak, redirection happens and then after authentication "Hello <user>" is shown. But this is not truly BASIC. Is this something wildfly can take care of in future releases?

One more help please. How do I get the logged in username?

Now that its getting authenticated against keycloak, I see "Hello 5e97de64-1ce1-45f7-9e92-3b424032051a" in response.

securityContext.getUserPrincipal().getName(); no longer return me the username. Rather the userId is returned.

[Subijay Bhattacharya]

I found the answer to username. I was using elytron-oidc-client configuration in standalone.xml. There I added 

<principal-attribute>preferred_username</principal-attribute>

After this httpServletRequest.getUserPrincipal() will give the name of the logged in user and not the id.

I believe adding the same in oidc.json will also work. Did not try that though.

The browser pop for the credential still remains an open item. I think the elytron-oidc-client adapater need to handle this.

[Farah Juma]

That's right, instead of the subsystem configuration, the principal-attribute can be configured in the deployment configuration in the oidc.json file as follows:

"principal-attribute" : "preferred_username"

Were you seeing the browser pop up previously when using the Keycloak Adapter?

[Subijay Bhattacharya]

No not really. I figured out that we had a filter where we check if Authorization header was present or not. If not present, send 401 and WWW-Authenticate in response header. I am using the same filter class now and that solved my purpose.

I am good to go now🙂. Thanks for all the help.