[keycloak-user] @RolesAllowed on @Stateless

[Bill Burke]

K, I'll look into it.  I may be unaware how to propagate the web layer's 
security context.

On 2/22/2014 6:03 AM, Juraci Paixão Kröhling wrote:
> -----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/java/org/sample/ejb/basic/Endpoint.java#L25
>>
>>   On the "QuickStartCode" branch, I've done the same:
>>
>> https://github.com/jpkrohling/sample-ejb-roles-basic/blob/QuickstartCode/src/main/java/org/sample/ejb/basic/Endpoint.java#L25
>>
>>   So, is this scenario supposed to work already, or is it planned
>> for a future release?
>>
>> Thanks! Juca.
>>> _______________________________________________ keycloak-user
>>> mailing list keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBCgAGBQJTCIQMAAoJEDnJtskdmzLM5cwH/j+Fxfg1hhzHLB70H8KmyaSI
> 3j/0IvovUkSmBJgrV6TfjZtUBczmtPntuU0cJOqIlrsc/21p0XmSOLl0Vx6RLnq3
> 3eSkI8IwlyOwZD5Lal6H4vTrO9EsFvNe+TLWZ5eFwwMItReWvQWAjqQellaAo+Aj
> 00CBEiA2Xvt+S+Z73ijnjkrltZzpkuGB+Ft9ODV1gUp2F6bx/Wu5LyO7duKFlcH4
> DvrGb/O/mXTaXO8VCOr93kZ3TVwLoaC/7QHmzran/BSwbnxD5mKZQTtKNd65FB3H
> 5Bd6HRqcZPusjQwDnKaKDPrIB5LUhp1bi6ItJVC/HP2k8malqRmE2KeJxMrT1q0=
> =R/Oe
> -----END PGP SIGNATURE-----
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com