[keycloak-user] Spring Boot Multi-tenancy

Pedro Igor Silva psilva at redhat.com
Thu Oct 18 13:40:32 EDT 2018


Based on other adapters, requests to unprotected resources should not be
processed by Keycloak mechanisms. I need to check why spring is behaving
differently.

Let me look at that and I'll update that JIRA.

Thanks.

On Thu, Oct 18, 2018 at 12:31 PM jeff victor <jeffvictor at gmail.com> wrote:

> Hi Pedro. I have created KEYCLOAK-8616
> <https://issues.jboss.org/browse/KEYCLOAK-8616>.
>
> Could you tell me what the expected behavior for a custom
> KeycloakConfigResolver should be when it is invoked when being redirected
> to /sso/login? Or for any other path that doesn't contain information to
> determine the deployment? I've noticed, for instance, that the resolver
> also gets invoked for other unprotected resources in the project such as /
> or /some-unprotected-path.
>
> Should the resolver return null? Or is the issue that the resolver
> shouldn't be getting invoked at all if the path isn't protected by spring
> security?
>
>
> Thanks,
>
> Jeff
>
> On Thu, Oct 18, 2018 at 3:17 PM Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
>> We recently added support for node registration, but I missed the fact
>> that it should only run when a deployment could be resolved. Could you open
>> a JIRA, please ?
>>
>> Regards.
>> Pedro Igor
>>
>> On Wed, Oct 17, 2018 at 8:39 PM Jeff Victor <jeff at sweetjacket.com> wrote:
>>
>>> I'm trying to get multi-tenancy working in a spring boot project. I've
>>> built the latest 4.6.0 snapshot and as a result am able to register my
>>> own
>>> MultiTenantConfigResolver - as per
>>> https://issues.jboss.org/browse/KEYCLOAK-8444. I have also verified
>>> that my
>>> custom resolver is being called.
>>>
>>> My application requires security to kick in at /admin/** and /customer/**
>>> which correspond to two realms - admin and customer.
>>>
>>> However, anything else should be open. Here is the configuration:
>>>
>>>                 http.authorizeRequests()
>>>
>>>                         .antMatchers("/admin*").authenticated()
>>>
>>>                         .antMatchers("/customer*").authenticated()
>>>
>>>                         .anyRequest().permitAll();
>>>
>>> The issue I'm having is that I don't know what KeycloakDeployment to
>>> return
>>> if someone accesses an unprotected resource like / or even /sso/login.
>>>
>>> In both of those cases my config resolver gets invoked and I return null
>>> which then results in the following exception:
>>>
>>> java.lang.NullPointerException: null
>>>
>>>         at
>>> org.keycloak.adapters.NodesRegistrationManagement.tryRegister(NodesRegistrationManagement.java:43)
>>>
>>>         at
>>> org.keycloak.adapters.springsecurity.filter.KeycloakPreAuthActionsFilter.doFilter(KeycloakPreAuthActionsFilter.java:81)
>>>
>>>         at
>>> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:334)
>>>
>>>         at
>>> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:101)
>>>
>>>         at
>>> org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:334)
>>>
>>> I've seen in other examples of a multi-tenant config resolver that always
>>> return a KeycloakDeployment or if it one can't be determined then it
>>> throws
>>> an exception such as here
>>>
>>> https://github.com/keycloak/keycloak/blob/master/examples/multi-tenant/src/main/java/org/keycloak/example/multitenant/control/PathBasedKeycloakConfigResolver.java
>>> .
>>>
>>> As an example, when debugging it seems that if I return the appropriate
>>> KeycloakDeployment for /admin everything goes well but straight away the
>>> resolver gets invoked again as there has been a redirect to /sso/login.
>>> In
>>> this case how am I to determine which KeycloakDeployment / realm to use?
>>>
>>> Thanks,
>>> Jeff
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>


More information about the keycloak-user mailing list