-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello, I'm playing with Keycloak on a pet project, and I'm really impressed with it. It looks really nice and it's easy to get it working fast. I have one question, though. I know it's early and it's alpha, but I wonder if this is a bug or a non-implemented feature :-) Basically, I wanted to annotate a REST method with @RolesAllowed("admin") for a DELETE request, and @RolesAllowed("user") for a @GET, something that works on with the usual scenario. With Keycloak, however, it seems that it's not being properly propagated to the EJB layer, so, I get a execution denied on the GET, even if the user has the "user" role. I've done a quick experiment, and it's available here: https://github.com/jpkrohling/sample-ejb-roles-basic On the master branch, the implementation with Keycloak. At the "Endpoint" class, I've added the output from Wildfly 8 as a comment: https://github.com/jpkrohling/sample-ejb-roles-basic/blob/master/src/main... On the "QuickStartCode" branch, I've done the same: https://github.com/jpkrohling/sample-ejb-roles-basic/blob/QuickstartCode/... So, is this scenario supposed to work already, or is it planned for a future release? Thanks! Juca. _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Ok, tried that, but didn't seem to work. I did some debugging, and the EJB layer is trying to get the information from the security-domain "other", which is the default one in absence of a per-deployment definition. This "other" security-domain is trying to get the auth information from the Authorization header, comparing with the application-users.properties file. Is it possible that the integration is only at the Web layer (undertow), not EJB? I'm not familiar with the internals of KC (or undertow, for that matter) at this level, but wouldn't a LoginModule be required for such integration? - - Juca. On 02/21/2014 09:39 PM, Bill Burke wrote: > This should only be a JAX-RS issue. You need to define a allow all > roles security constraint for your JAX-RS services: > > <security-constraint> <web-resource-collection> > <url-pattern>/v1/*</url-pattern> </web-resource-collection> <!-- > <user-data-constraint> > <transport-guarantee>CONFIDENTIAL</transport-guarantee> > </user-data-constraint> --> <auth-constraint> > <role-name>*</role-name> </auth-constraint> </security-constraint> > > You may also need to define all the security roles in web.xml too, > I don't remember. So, you're telling the servlet layer to > authenticate but to allow all roles, then, in the EJB/JAX-RS layer > it should be checking against @RolesAllowed. Let me know if that > helps. > > > > > On 2/21/2014 2:45 PM, Juraci Paixão Kröhling wrote: Hello, > > I'm playing with Keycloak on a pet project, and I'm really > impressed with it. It looks really nice and it's easy to get it > working fast. > > I have one question, though. I know it's early and it's alpha, but > I wonder if this is a bug or a non-implemented feature :-) > > Basically, I wanted to annotate a REST method with > @RolesAllowed("admin") for a DELETE request, and > @RolesAllowed("user") for a @GET, something that works on with the > usual scenario. > > With Keycloak, however, it seems that it's not being properly > propagated to the EJB layer, so, I get a execution denied on the > GET, even if the user has the "user" role. > > I've done a quick experiment, and it's available here: > > https://github.com/jpkrohling/sample-ejb-roles-basic > > On the master branch, the implementation with Keycloak. At the > "Endpoint" class, I've added the output from Wildfly 8 as a > comment: > > https://github.com/jpkrohling/sample-ejb-roles-basic/blob/master/src/main... > > On the "QuickStartCode" branch, I've done the same: > > https://github.com/jpkrohling/sample-ejb-roles-basic/blob/QuickstartCode/... > > So, is this scenario supposed to work already, or is it planned > for a future release? > > Thanks! Juca. >> _______________________________________________ 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