@aznamier we do plan to provide a generic Java library for authorization services. It simply doesn't scale to maintain bespoke adapters when you start thinking about Keycloak is something that should be usable from any language and framework, not just to a subset. With that in mind we can focus more on getting started examples with a broader audience, than full fledged adapters for a limited audience. We do also welcome the community to step up and take owner maintainence of the Keycloak adapters if there is a continued strong demand for these.

If "the community" was able to create and maintain such a thing they wouldn't use keycloak. So that's a moot point.
"If you don't like if fork it" is not an option for 99% of the audience.

I'm now Spring expert by no stretch, but I would have assumed Spring Security has a broader support for OIDC than our adapters.

„Would have assumed“ is a bit surprising in the context of a decision with such an impact.

I appreciate that there may be some things missing, but that would be things that could and should be addressed in Spring Security community.

The wording of the blog post gives the impression that OAuth in Spring Security already is the much better alternative already. I wanted to raise the point that this isn’t necessarily the case. True, the missing parts could be addressed by Spring, but there is no telling if and when that will happen. The timeframe for sunsetting the adapters is rather short with regard to future feature development in Spring Security with an existing roadmap. I‘m sure with effort it will work out, but the tone of the blogpost that (almost) everything should be covered seems a bit overconfident to me.

End of the day the sad fact is that we don't have capacity to maintain and continue to evolve the Spring adapters, and would rather like to focus on improving Keycloak itself.

This is a line of reasoning that can’t be argued. For me, an honest statement like that is much better than the blog that basically tries to say: it’s not much of a problem, the adapter isn’t really needed anyway. I appreciate the effort of you and your team, Keycloak has become quite important for our project.

is the keycloak-spring-security-adapter being deprecated?

The Spring Security 5 Resource Server Support can be used to secure Resource Servers with Bearer Access Tokens issued by Keycloak.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-oauth2-resource-server</artifactId>
</dependency>

Example config

spring:
  jackson:
    serialization:
      write-dates-as-timestamps: false
    deserialization:
      # deals with single and multi-valued JWT claims
      accept-single-value-as-array: true
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: ${acme.jwt.issuerUri}
          jwk-set-uri: ${acme.jwt.issuerUri}/protocol/openid-connect/certs

acme:
  jwt:
    issuerUri: https://id.acme.test:8443/auth/realms/acme-internal

Example WebSecurity configuration

    @Override
    protected void configure(HttpSecurity http) throws Exception {

        http.sessionManagement()
                .sessionCreationPolicy(SessionCreationPolicy.STATELESS)
                .and()
                .cors(this::configureCors)
                .authorizeRequests()
                // declarative route configuration
                .mvcMatchers("/api/**").hasAuthority("ROLE_API_ACCESS")
                //...
                .anyRequest().fullyAuthenticated()
                .and()
                .oauth2ResourceServer()
                .jwt()
                // extract Keycloak specific info from JWT
                .jwtAuthenticationConverter(keycloakJwtAuthenticationConverter); 
    }

Here are some small example apps for this:

• Example for Resource Server with Spring Web MVC
• Example for Resource Server with Spring Web Flux (Reactive)

For OpenId Clients the Spring Security 5 Oauth2 Client library can be used, which supports OpenID Connect.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-oauth2-client</artifactId>
</dependency>

Example configuration:

spring:
  thymeleaf:
    cache: false
  security:
    oauth2:
      client:
        registration:
          keycloak:
            client-id: 'customer-account-console'
            client-secret: 'Efc5lvBEx9Z1pfzKlZ5NUIIxUo7wLmp7'
            client-authentication-method: client_secret_post
            authorizationGrantType: authorization_code
            redirect-uri: '{baseUrl}/login/oauth2/code/{registrationId}'
            scope: openid
        provider:
          keycloak:
            issuerUri: https://id.acme.test:8443/auth/realms/acme-demo
            user-name-attribute: preferred_username

Example Java WebSecurity Config:

import com.github.thomasdarimont.keycloak.cac.support.security.KeycloakLogoutHandler;
import lombok.RequiredArgsConstructor;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter;
import org.springframework.security.core.GrantedAuthority;
import org.springframework.security.core.authority.mapping.GrantedAuthoritiesMapper;
import org.springframework.security.oauth2.core.oidc.OidcUserInfo;
import org.springframework.security.oauth2.core.oidc.user.OidcUserAuthority;

import java.util.HashSet;
import java.util.Set;

@Configuration
@RequiredArgsConstructor
class WebSecurityConfig extends WebSecurityConfigurerAdapter {

    private final KeycloakLogoutHandler keycloakLogoutHandler;

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.authorizeRequests() //
                .anyRequest().fullyAuthenticated() //
                .and().oauth2Client() //
                .and().oauth2Login().tokenEndpoint().and().userInfoEndpoint().userAuthoritiesMapper(userAuthoritiesMapper()) //
                .and().and()
                .logout().addLogoutHandler(keycloakLogoutHandler)
        ;
    }

    private GrantedAuthoritiesMapper userAuthoritiesMapper() {
        return (authorities) -> {
            Set<GrantedAuthority> mappedAuthorities = new HashSet<>();

            authorities.forEach(authority -> {
                if (authority instanceof OidcUserAuthority) {
                    OidcUserAuthority oidcUserAuthority = (OidcUserAuthority) authority;

                    OidcUserInfo userInfo = oidcUserAuthority.getUserInfo();

//                    List<SimpleGrantedAuthority> groupAuthorities = userInfo.getClaimAsStringList("groups").stream().map(g -> new SimpleGrantedAuthority("ROLE_" + g.toUpperCase())).collect(Collectors.toList());
//                    mappedAuthorities.addAll(groupAuthorities);
                }
            });

            return mappedAuthorities;
        };
    }
}

I achieved much simpler (I believe) than above conf: https://github.com/ch4mpy/spring-addons/tree/master/samples/tutorials

(should have originally posted in this thread than root, sorry)

Here is what above resource-server configuration should be with the lib I linked:

<dependency>
    <groupId>com.c4-soft.springaddons</groupId>
    <!-- there are variants for "webflux" instead of "webmvc", and "introspcting" instead of "jwt" -->
    <artifactId>spring-addons-webmvc-jwt-resource-server</artifactId>
    <version>6.0.2</version>
</dependency>

com:
  c4-soft:
    springaddons:
      security:
        issuers:
        - location: ${acme.jwt.issuerUri}
          authorities:
            claims: 
            - realm_access.roles
            - resource_access.${acme.jwt.client}.roles
        cors:
        - path: /api/**

acme:
  jwt:
    issuerUri: https://id.acme.test:8443/auth/realms/acme-internal
    client: user-proxies-client

@EnableGlobalMethodSecurity(prePostEnabled = true)
public class WebSecurityConfig {
    @Bean
    ExpressionInterceptUrlRegistryPostProcessor expressionInterceptUrlRegistryPostProcessor() {
        return (ExpressionUrlAuthorizationConfigurer<HttpSecurity>.ExpressionInterceptUrlRegistry registry) -> registry.mvcMatchers("/api/**").hasAuthority("ROLE_API_ACCESS").anyRequest().fullyAuthenticated();
    }
}

@thomasdarimont am I right?

Im looking into this as well, and found no evidence in spring security that it supports UMA at all, when migrating towards spring security should one still use the keycloak-authz-client for uma then?

For authorization services specifically let's move the conversations around that to #11681

We don't have (and never had) support for SAML in the Keycloak Spring adapters.

For authorization services specifically let's move the conversations around that to #11681

can it support both basic auth and bearer like the keycloak spring boot library?
and client seceret grant and password grants?

Keycloak spring boot libary did an awsome job in that respect, and it was super easy to extend it for multitenancy use cases..
and best part it had the same set of feature set oas keycloakd oidc servelt libraries.. both the spring boot and servlet variant used the same underlying auth code ( which dealt nicely with basic auth, bearer, and differnt grant types like password, client secret ) etc.

How are you using basic auth exactly? As a relay to password-grant flow (or client-credentials one) to fetch an identity from Keycloak for each request to a REST API (a bit like introspection but of a basic authentication header instead of a Bearer one) ? Or do you wish to open a session used by following requests?

Hi ch4mpy. I have the same issue as kkcmadhu, I have an REST API in Spring Boot 2.7 using the Keycloak adapter, I have a mixture of client devices most of which only support basic auth, but a few can use the password grant flow to get a bearer token. Having authenticated the device I then use the retrieved identity to authorise what resources can be accessed. So I guess it is kind of relaying the basic auth request to a password grant flow.
I need to have a solution in place to upgrade Spring Boot beyond version 3.0 which supports basic auth using Keycloak, I have some success connecting my bearer token based clients in Spring Boot 3 but I can not find examples of relaying the basic auth to the Keycloak backend to obtain the security principle , roles, etc.
Could your library handle the basic auth relay?

@dazfitzg see my other answer below

@stianst I would really appreciate your help. thanks.

@ahmedgazie just remove Keycloak dependencies from your Spring project.

You should find everything you need from the tutorials I linked earlier: https://github.com/ch4mpy/spring-addons/tree/master/samples/tutorials

It exposes how to setup your resource-server security:

• with just spring-boot-starter-oauth2-resource-server: https://github.com/ch4mpy/spring-addons/blob/master/samples/tutorials/resource-server_with_jwtauthenticationtoken
• with spring-addons-webmvc-jwt-resource-server which saves a lot of Java conf compared to preceeding
• advanced usage of spring-addons-webmvc-jwt-resource-server with more private claims parsing (including those you added with your own Keycloak mappers), Authentication extension and security SpEL enrichment to create DSLs like @PreAuthorize("is(#username) or isNice() or onBehalfOf(#username).can('greet')")

Ah, so the keycloak-admin-client and keycloak-authz-client are not deprecated?

@westmc IM not a dev on keycloak.. But from what I've understood the way forward are using spring security and keycloak auth and keycloack admin clients..

You are right about the disadvantages of authorisation services. However, the reason why this Policy Enforcement Point / Policy Decision Point pattern is used is that you can make these kinds of decisions in a central place and you can change them at runtime without changing and deploying code. And there is quite a price for this feature as you said.

I forgot about the "central place", will edit my answer. Central place has cons too: when the number of rules grows, it can get quite difficult to identify all those that apply to a specific ressource. I prefer having spring-security rules annotated on controller methods. Also, if you define one, you should put your custom spring-security DSL in a shared library and use it accross your micro-services. That would make the rules definition "central".

Only remains the ability to edit rules at runtime. Most of the time, editing roles or context is enough and that does not require re-deployment. As far as I remember, when rules syntax itself needed changes, I also had other business rules to apply and had to deploy anyway (but, again, this is pretty unfrequent)...

Again, I'm not part of Keycloak team at all and did not participate in any deprecation decision. I'm just an open-source contributor proposing tools around OIDC & spring (not even specifically Keycloak) and exposing my personal thoughts about a proprietary solution.

Writing a service to wrap REST calls to "Authorization services" shouldn't be that much effort. That's the magic of open source: you can do it and share it with the community (like I did with my spring-boot starters for resource-servers and unit-test framework).

@kkcmadhu, regarding mapping of authorities from realm and client roles (and even any other private claims you configure with custom mappers), just have look at the lib I wrote and linked above: you define from just properties from which claims authorities should be mapped and with which prefix (none by default but some Spring projects are used to ROLE_ or SCOPE_) and case transformation (none by default, but some projects are used to uppercase authorities when roles are frequently lowercase in Keycloak).

I wrote it initially to have a single adaptor for any OIDC authorization-server (had to switch from Keycloak to MS Identity-Server depending on the environment on some project) but it does a perfect job for your realm / client roles need.

A spring-boot 3 (+spring-boot-starter-oauth2-resource-server) based resource server example can be found here: https://github.com/thomasdarimont/keycloak-project-example/tree/main/apps/backend-api-springboot3

A spring-boot 3 (+spring-boot-starter-oauth2-client) based oidc client example application can be found here:
https://github.com/thomasdarimont/keycloak-project-example/tree/main/apps/frontend-webapp-springboot3

@thomasdarimont I'm curious about what you think of the resource-server configuration simplifications I proposed in this PR

What do you mean exactly by implementing SSO? Because, to me, this is something more on the side of the authorization-server than resource-server or client and has little to do with Spring...

If you mean client configuration in addition to resource-server, then maybe this can be of any help: https://github.com/ch4mpy/spring-addons/tree/master/samples/tutorials/resource-server_with_ui

Yes and no. Someone (aka: the adapter) has to trigger the logout and inform the authorization-server. Also, someone has to handle the following request from the server via admin url to perform the log out (when it wasn't your application that triggered the logout). And again, this request (k_logout) has to be handled by the adapter.

Ok, I know this features as RP-Initiated Logout (a client requests user logout to Keycloak) and Back-Channel Logout (Keycloak notifies all registered clients that a user was logged out).

The first is illustrated in @thomasdarimont client sample

The second is not implemented yet in spring-security-client but it should be soon (hopefully).

For those interested in the "Single Sign Out" feature (and eased client configuration) , I Just released thin wrappers around spring-boot-starter-oauth2-client. It contains client side of Back-Channel Logout for both servlet and reactive applications.

The servlet starter usage is illustrated in a tutorial for an app exposing both a REST API (resource server) and the Thymeleaf UI to query it (OAuth2 client with login, RP-Initiated logout and Back-Channel Logout).

The reactive starter usage is illustrated in spring-cloud-gateway used as Backend For Frontend (OAuth2 client with login, RP-Initiated logout, Back-Channel Logout, and TokenRelay filter). BFF is quite trendy lately to hide OAuth2 tokens from the browser (and the JavaScript code running in it). Browser is secured with sessions on the BFF, the BFF stores tokens in session and then replaces session cookies with OAuth2 access tokens before forwarding requests from the browser to the API.

The supported tenants are all within the same trusted Identity and Access Management (IAM), split by realm. The IAM is configured in the application properties, the realms are dynamic and represent different tenants ( which can come and go - hence not wanting them stored in configuration ).

Here is the JwtIssuerAuthenticationManagerResolver (for servlets), but it is quite far from what you need.

Maybe something like that would be a better match:

@Component
static class IamAuthenticationManagerResolver implements AuthenticationManagerResolver<HttpServletRequest> {
    private final URI issuerBaseUri;
    private final Converter<Jwt, ? extends AbstractAuthenticationToken> jwtAuthenticationConverter;
    private final Map<String, JwtAuthenticationProvider> jwtManagers = new ConcurrentHashMap<>();
    private final JwtIssuerAuthenticationManagerResolver delegate = new JwtIssuerAuthenticationManagerResolver((AuthenticationManagerResolver<String>) this::getAuthenticationManager);

    public IamAuthenticationManagerResolver(@Value("${issuer-base-uri}") URI issuerBaseUri,
            Converter<Jwt, ? extends AbstractAuthenticationToken> jwtAuthenticationConverter) {
        this.issuerBaseUri = issuerBaseUri;
        this.jwtAuthenticationConverter = jwtAuthenticationConverter;
    }

    @Override
    public AuthenticationManager resolve(HttpServletRequest context) {
        return delegate.resolve(context);
    }

    public AuthenticationManager getAuthenticationManager(String issuerUriString) {
        final var issuerUri = URI.create(issuerUriString);
        if (!Objects.equals(issuerUri.getHost(), issuerBaseUri.getHost())
                || !Objects.equals(issuerUri.getPort(), issuerBaseUri.getPort())) {
            throw new InvalidIssuerException(issuerUriString);
        }
        if (!this.jwtManagers.containsKey(issuerUriString)) {
            this.jwtManagers.put(issuerUriString, getProvider(issuerUriString));
        }
        return jwtManagers.get(issuerUriString)::authenticate;
    }

    private JwtAuthenticationProvider getProvider(String issuerUriString) {
        var provider = new JwtAuthenticationProvider(JwtDecoders.fromIssuerLocation(issuerUriString));
        provider.setJwtAuthenticationConverter(jwtAuthenticationConverter);
        return provider;
    }

    @ResponseStatus(code = HttpStatus.UNAUTHORIZED)
    static class InvalidIssuerException extends RuntimeException {
        public InvalidIssuerException(String issuerUriString) {
            super("Issuer %s is not trusted".formatted(issuerUriString));
        }
    }
}

Please note that If you define a component as the one above in a boot application with "my" starter, it should replace the default one (the AuthenticationManagerResolver<HttpServletRequest> is @ConditionalOnMissingBean) and you'll still benefit other features like the configurable authorities converter

@ch4mpy ,

like @garethmetcalf
I too have my own implentation of multitenancy, written on top of keycloak spring booot 2 library, i just manage to change the realm name based on header, url , query param or any thing which application is configured to look realm names at various places, at the out set my spring boot config looks something like this

`my-custom-keycloak-adapter.tenant-resolution-statergy : Custom
my-custom-keycloak-adapter.tenant-resolution-param-value: com.mycompany.keycloak.resolver.UserTypeBasedTenantResolver

my-custom-keycloak-adapte.alt.internal-user-tenant-resolution-statergy : ApplicationArgumentBased
my-custom-keycloak-adapte.alt.internal-user-tenant-resolution-param-value : somehardcodedrealname
my-custom-keycloak-adapte.alt.external-user-tenant-resolution-statergy : PathIndexBased
my-custom-keycloak-adapte.alt.external-user-tenant-resolution-param-value : 3

`
Here if the user is identifed as internaer user ( with specific header name which the UserTypeBasedTenantResolver class know how to resolve), i connect to a hard coded realm, other wise i recognize the traffic as external traffic and pick the tenant name from 3rd item in the path index.

Likewise i can configure my application to support varis differt tenant-resoultion-staterg like header based, cookie based, path index based, fixed real name, etc etc..

I am now looking to port this to spring boot 3.. Will check if your library can be a fit

@kkcmadhu, as stated before, if you implement an AuthenticationManagerResolver<HttpServletRequest> with your logic and expose it as a @Bean, it should work with "my" starters.

Please note I recently refreshed my introduction tutorials to explain how to configure Spring Boot 3 without my starters. I expect it to be clearer:

• intro with prerequisites and OAuth2 reminder
• servlet-resource-server
• servlet-client
• reactive-resource-server
• reactive-resource-server

Off course, those tutorials have much more verbose Java configuration than tutorials using "my" starters...

@garethmetcalf I added a tutorial very close to what you need (I think).

It was actually an interesting use case to demo my starters customization. There was a small caveat I hadn't anticipated: the application properties for each issuer (issuer location as well as authorities and username mapping) is by default resolved by issuer URI. I had to change the way issuer properties are resolved too, so that it is based on issuer URI scheme, host and port, but not path (which we cannot know in advance).

Thanks @stianst much appriciated .It was really kind of you to revaulate the plan and to offer support for these adapters a while more!

I'd like to stress that "my" starters are not intended to replace Keycloak adapters. As already stated, their aim is to ease Spring Boot 3 applications OAuth2 configuration with OpenID Providers (not specifically Keycloak, any of it).

Basic authentication has nothing to do with OAuth2 in general and OpenID in particular. As a consequence, do not expect anything about it in spring-addons starters.

However, as you pointed it, this starters are totally integrated with spring-security (it is doing no more than configuring it), and adding Basic authentication in application with and without spring-addons is done exactly the same way: add a security filter-chain with a matcher for Basic authentication before the security filter-chain for OAuth2 resource server.

In your case, such a Bearer security filter-chain could be configured with an authentication manager acting in 3 steps:

• use password grant flow to fetch an access token
• replace request Basic Authorization header with a Bearer one containing the access token just fetched
• delegate to the authentication manager configured for the OAuth2 filterchain

Off course, in a multi-tenant environment, to initiate password-grant flow, you have to resolve the right:

• token endpoint,
• client-id
• client-secret

An option would be using a custom header (let's say X-Realm) in addition to the Basic Authorization one.

Complete configuration with "my" starters: the OAuth2 security filter-chain is auto-configured and quite a few beans reused (authorities and authentication mappers, authentication manager resolver, configuration properties, ...), which makes the configuration much shorter):

@Configuration
public class BasicAuthSecurityConfig {

    @Bean
    @Order(Ordered.LOWEST_PRECEDENCE - 1)
    SecurityFilterChain basicAuthFilterChain(
            HttpSecurity http,
            ServerProperties serverProperties,
            SpringAddonsSecurityProperties addonsProperties,
            TokenEndpointsProperties tokenEndpointsProperties,
            AuthenticationManagerResolver<HttpServletRequest> authenticationManagerResolver,
            ExpressionInterceptUrlRegistryPostProcessor authorizePostProcessor,
            HttpSecurityPostProcessor httpPostProcessor)
            throws Exception {

        // process only requests with HTTP Basic Authorization
        http.securityMatcher((HttpServletRequest request) -> {
            return Optional.ofNullable(request.getHeader(HttpHeaders.AUTHORIZATION)).map(h -> {
                return h.toLowerCase().startsWith("basic ");
            }).orElse(false);
        });

        http.httpBasic(withDefaults());

        http.userDetailsService((String username) -> {
            return new User(username, "", List.of());
        });

        final var keycloakIssuer = Stream.of(addonsProperties.getIssuers())
                .filter(iss -> iss.getLocation().toString().contains("/realms/")).findAny()
                .map(IssuerProperties::getLocation).orElse(null);
        final var keycloakBaseUri = UriComponentsBuilder.fromUri(keycloakIssuer).replacePath(null).build().toString();

        http.authenticationManager(
                new KeycloakPasswordFlowAuthenticationManager(keycloakBaseUri, tokenEndpointsProperties,
                        authenticationManagerResolver));

        ServletConfigurationSupport.configureResourceServer(http, serverProperties, addonsProperties, authorizePostProcessor, httpPostProcessor);

        return http.build();
    }

    static class KeycloakPasswordFlowAuthenticationManager implements AuthenticationManager {
        private final String baseUri;
        private final TokenEndpointsProperties tokenEndpointsProperties;
        private final AuthenticationManagerResolver<HttpServletRequest> jwtAuthenticationManagerResolver;
        private final Map<String, WebClient> webClients = new ConcurrentHashMap<>();

        public KeycloakPasswordFlowAuthenticationManager(
                String baseUri,
                TokenEndpointsProperties tokenEndpointsProperties,
                AuthenticationManagerResolver<HttpServletRequest> jwtAuthenticationManagerResolver) {
            this.baseUri = baseUri;
            this.tokenEndpointsProperties = tokenEndpointsProperties;
            this.jwtAuthenticationManagerResolver = jwtAuthenticationManagerResolver;
        }

        @Override
        public Authentication authenticate(Authentication authentication) throws AuthenticationException {
            try {
                final var requestAttributes = RequestContextHolder.getRequestAttributes();
                if (!(requestAttributes instanceof ServletRequestAttributes)) {
                    throw new AuthenticationFailureException("Missing servlet Request context");
                }
                final var request = ((ServletRequestAttributes) requestAttributes).getRequest();
                final var realm = request.getHeader("X-Realm");
                final var realmProperties = tokenEndpointsProperties.getRealms().get(realm);
                final var webClient = getWebClient(baseUri, realmProperties, realm);
                final var tokenResponse = webClient.post()
                        .body(
                                BodyInserters.fromFormData("grant_type", "password")
                                        .with("client_id", realmProperties.getClientId())
                                        .with("username", authentication.getName())
                                        .with("password", authentication.getCredentials().toString()))
                        .retrieve().bodyToFlux(TokenResponseDto.class)
                        .onErrorMap(e -> new AuthenticationFailureException(e)).blockLast();

                // Change request Authorization header: make it a Bearer authorization with the
                // just retrieved access token (instead of a "Basic" one)
                request.setAttribute(HttpHeaders.AUTHORIZATION, "Bearer %s".formatted(tokenResponse.accessToken()));

                // Delegate to the JWT authentication manager we already defined for the OAuth2
                // security filter-chain
                return jwtAuthenticationManagerResolver.resolve(request)
                        .authenticate(new BearerTokenAuthenticationToken(tokenResponse.accessToken()));
            } catch (Throwable e) {
                throw new AuthenticationFailureException(e);
            }
        }

        private WebClient getWebClient(String issuerUri, TokenEndpointsProperties.RealmProperties realmProperties,
                String realm) {
            if (!webClients.containsKey(realm)) {
                final var builder = WebClient.builder()
                        .baseUrl("%s/realms/%s/protocol/openid-connect/token".formatted(issuerUri, realm));
                if (StringUtils.hasText(realmProperties.getClientSecret())) {
                    builder.filter(ExchangeFilterFunctions.basicAuthentication(realmProperties.getClientId(),
                            realmProperties.getClientSecret()));
                }
                builder.defaultHeader(HttpHeaders.CONTENT_TYPE, MediaType.APPLICATION_FORM_URLENCODED_VALUE);
                webClients.put(realm, builder.build());
            }
            return webClients.get(realm);
        }

        static record TokenResponseDto(@JsonProperty("access_token") String accessToken) {
        }

        static class AuthenticationFailureException extends RuntimeException {
            private static final long serialVersionUID = -96469109512884829L;

            public AuthenticationFailureException(Throwable e) {
                super(e);
            }

            public AuthenticationFailureException(String e) {
                super(e);
            }
        }
    }

    @Data
    @Configuration
    @ConfigurationProperties(prefix = "token-endpoints")
    public class TokenEndpointsProperties {
        private Map<String, RealmProperties> realms = new HashMap<>();

        @Data
        static class RealmProperties {
            private String clientId;
            private String clientSecret;
        }

        public RealmProperties get(String realm) throws MisconfigurationException {
            if (!realms.containsKey(realm)) {
                throw new MisconfigurationException(
                        "Missing authorities mapping properties for %s".formatted(realm.toString()));
            }
            return realms.get(realm);
        }

        static class MisconfigurationException extends RuntimeException {
            private static final long serialVersionUID = 5887967904749547431L;

            public MisconfigurationException(String msg) {
                super(msg);
            }
        }
    }
}

with those properties:

scheme: http
origins: ${scheme}://localhost:4200
keycloak-port: 8442
master-realm: ${scheme}://localhost:${keycloak-port}/realms/master
other-realm: ${scheme}://localhost:${keycloak-port}/realms/other
spring-addons-confidential-secret: change-me

server:
  error:
    include-message: always
  ssl:
    enabled: false

spring:
  lifecycle:
    timeout-per-shutdown-phase: 30s

com:
  c4-soft:
    springaddons:
      security:
        cors:
        - path: /**
          allowed-origins: ${origins}
        issuers:
        - location: ${master-realm}
          username-claim: preferred_username
          authorities:
          - path: $.realm_access.roles
          - path: $.resource_access.*.roles
        - location: ${other-realm}
          username-claim: preferred_username
          authorities:
          - path: $.realm_access.roles
          - path: $.resource_access.*.roles
        permit-all:
        - "/greet/public"
        
token-endpoints:
  realms:
    master:
      client-id: spring-addons-confidential
      client-secret: ${spring-addons-confidential-secret}
    other:
      client-id: spring-addons-confidential
      client-secret: ${spring-addons-confidential-secret}

---
scheme: https
keycloak-port: 8443

server:
  ssl:
    enabled: true

spring:
  config:
    activate:
      on-profile: ssl

With the configuration above, you can authenticate with Basic authentication on master or other realm, provided that your request contains a X-Realm header (containing one of the configured realm names) in addition to the Basic Authorization one (containing username and password)

Hi @stianst and other keycloak maintainers,
as i highlighted password grant , basic auth support in keycloak filter (both spring and servlet) are crucial for us, and we would like to stick with keycloak spring boot adapter..
With some effort i was able to make keycloak-springboot-3-adapter, If you think it will add value to the community, i can raise a PR for the same, do let me know your views.

Hi @kkcmadhu ,

I am in same situation as you. Would you mind telling how did you build the keycloak-springboot-3-adapter? And where are you referring it from? pom dependency?

The assumption that you can't have both Basic and Bearer authorization with Spring Boot 3 is wrong and I already contributed a solution just above.

I have a working sample in this project with a security filterchain for Basic auth in this config file and another security filter-chain for an OAuth2 resource server in this other configuration file (which is using "my" starter for simplification purposes but could be written with just spring-boot-starter-oauth2-resource-server as done in this configuration file from another project). Mind the @Order and securityMatcher in the Basic auth configuration.