[keycloak-user] Keycloak admin role to group not working

Wed May 4 13:02:19 EDT 2016

I'd like to rewrite it to be all REST to be nice and modern and cool :)

On 4 May 2016 at 17:15, Marek Posolda <mposolda at redhat.com> wrote:

> +1 to use the token. If relying on token is bad for security, then
> "external" application would be broken too, isn't it?
>
> But another issue is, that account management doesn't have token as there
> is not full OIDC here. It relies just on the cookie authentication. We can
> sort it easily by having helper methods "isMemberOf", which will take all
> direct and indirect roles memberhips though.
>
> Or are we going to rewrite account management to be angular+REST ? It
> seems it will help with much more things (REST endpoints for users, no CSRF
> issues, possibly better UI).
>
> Marek
>
>
>
>
> On 04/05/16 17:09, Stian Thorgersen wrote:
>
> We really need to remove this stuff and just rely on the token.
> On 4 May 2016 17:06, "Marek Posolda" < <mposolda at redhat.com>
> mposolda at redhat.com> wrote:
>
>> Yeah, information is available. Problem is that it's ignored :-)
>>
>> Both admin console and account management are just using "user.hasRole"
>> when asking if user is member of particular role. This returns false for
>> the role mappings, which are available indirectly through groups.
>>
>> Marek
>>
>> On 04/05/16 16:50, Bill Burke wrote:
>>
>> This was by design.  Since the information is available to these built-in
>> applications, it seemed that much safer to ignore the token permissions.
>>
>> On 5/4/2016 10:43 AM, Marek Posolda wrote:
>>
>> Just tested the scenario and I confirm there is an issue. It would work
>> for all your external applications, as roles, which are indirectly assigned
>> to user through group mappings, are correctly available inside accessToken.
>> However Keycloak builtin applications (admin console and account
>> management) doesn't read roles from the token, hence it doesn't work there.
>> I've created JIRA for:
>> admin console: https://issues.jboss.org/browse/KEYCLOAK-2969
>> account management: https://issues.jboss.org/browse/KEYCLOAK-2970
>>
>> Marek
>>
>> On 02/05/16 22:33, Jason Axley wrote:
>>
>> I have an LDAP user who is definitely listed as being in a given LDAP
>> group in Keycloak admin console.
>>
>> If I grant the User the admin Realm Role in the master realm, they can
>> login and access the admin console for the master realm.
>>
>> However, if I remove the direct role grant from the user and add it to
>> the LDAP group, keycloak doesn’t think the user has the role and gives an
>> error that the user “You don't have access to the requested resource.”
>> with the below exception:
>>
>> 2016-05-02 20:25:37,677 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n]
>> (default task-2) RESTEASY002005: Failed executing GET /admin/serverinfo:
>> org.keycloak.services.ForbiddenException
>>
>> at
>> org.keycloak.services.resources.admin.AdminRoot.getServerInfo(AdminRoot.java:231)
>>
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>
>> at java.lang.reflect.Method.invoke(Method.java:483)
>>
>> at
>> org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:79)
>>
>> at
>> org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:58)
>>
>> at
>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:100)
>>
>> at
>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395)
>>
>> at
>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202)
>>
>> at
>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
>>
>> at
>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
>>
>> at
>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
>>
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>>
>> at
>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
>>
>> at
>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
>>
>> at
>> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:78)
>>
>> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>>
>> at
>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
>>
>> at
>> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
>>
>> at
>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
>>
>> at
>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>>
>> at
>> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>>
>> at
>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>
>> at
>> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
>>
>> at
>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>>
>> at
>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>
>> at
>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
>>
>> at
>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
>>
>> at
>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
>>
>> at
>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
>>
>> at
>> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
>>
>> at
>> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
>>
>> at
>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>
>> at
>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>>
>> at
>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>
>> at
>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>
>> at
>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
>>
>> at
>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
>>
>> at
>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
>>
>> at
>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
>>
>> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
>>
>> at
>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
>>
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>
>> at java.lang.Thread.run(Thread.java:745)
>>
>>
>>
>> Is there something magical that needs to be configured for this to work?
>> Or does this look like a bug?
>>
>> I also did a quick test where I created a new local group and did the
>> same role assignment to the group, and assigned the group to the same LDAP
>> user and it did not grant access.
>>
>> -Jason
>>
>> *Jason Axley*
>>
>> Sr. Security Engineer, Expedia Worldwide Engineering Team
>>
>> 425-679-4157 (o) | 206-484-2778 (m) | 206-55-AXLEY (gv)
>>
>> 333 108th Ave NE, 9S-282, Bellevue, WA 98004
>>
>> EWE Security Wiki <https://confluence/display/POS/EWE+Security>
>>
>>
>> _______________________________________________
>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>>
>>
>> _______________________________________________
>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>
>>
>>
>> _______________________________________________
>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160504/d3e4f26f/attachment-0001.html 