10:33 p.m.
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>
4:43 p.m.
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 list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
4:50 p.m.
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 list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
5:04 p.m.
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 list
>> keycloak-user(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
5:09 p.m.
We really need to remove this stuff and just rely on the token.
On 4 May 2016 17:06, "Marek Posolda" <mposolda(a)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@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing
listkeycloak-user@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@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
5:15 p.m.
+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(a)redhat.com
<mailto:mposolda@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 <tel:425-679-4157> (o) | 206-484-2778
>>> <tel: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 list
>>> keycloak-user(a)lists.jboss.org
>>> <mailto:keycloak-user@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user
7:02 p.m.
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(a)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(a)redhat.com>
mposolda(a)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@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
>
> _______________________________________________
> keycloak-user mailing
listkeycloak-user@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@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
2920
days inactive
2922
days old
6 comments
4 participants
participants (4)
-
Bill Burke -
Jason Axley -
Marek Posolda -
Stian Thorgersen