Re: [Resteasy-developers] Proposed Role Based Security enhancement

[Bill B. <bb...@re...>]

Resteasy's vanilla @RoleAllowed implementation is just a simple JAX-RS 
filter that just delegates to SecurityContext.isUserInRole() which 
delegates to the HttpServletRequest.

Is there a reason why you need @RolesAllowed metadata to be exposed 
through Undertow ServletSecurityInfo?  Can't you just apply a more 
generic constraint at the web.xml level?

BTW, I don't think this improvement you want is feasible.  You *could* 
do it, but it would be incomplete and error prone.  This is because 
Servlet constraints have a very limited URL matching mechanism.  You are 
allowed only one simple wildcard.  This is not the case in JAX-RS.

JAX-RS service locators compound the problem even more as endpoints are 
dynamically resolved per request!

@Path("locator")
java.lang.Object getLocator() {...}

So, a locator could return an Object in which it may or may not have a 
JAX-RS method that is annotated with @RoleAllowed.  There's just no way 
to determine any of this at deploy time.

Am I making sense?




On 2/12/2014 8:11 AM, Paul K Moore wrote:
> Hi all,
>
> First post here, so feel free to redirect if necessary.
>
> I am working on a REST API based on RestEasy 3.0.6 in a Wildfly
> 8.0.0.Final-SNAPSHOT environment.
>
> I’ve implemented @RolesAllowed based security as recommended in the
> documentation
> <http://docs.jboss.org/resteasy/docs/3.0.6.Final/userguide/html/Securing_JAX-RS_and_RESTeasy.html>,
> using the resteasy.role.based.security feature, and the relevant
> ServletDispatcher and SecurityConstraints.
>
>  From a security perspective, I’m using a custom JASPI ServerAuthModule
> and LoginModule. As part of the Wildfly JASPI implementation, the
> JASPIAuthenticationMechanism
> <https://github.com/wildfly/wildfly/blob/master/undertow/src/main/java/org/wildfly/extension/undertow/security/jaspi/JASPIAuthenticationMechanism.java?source=cc>.isMandatory()
> determines whether the servlet is protected by querying the
> ServletSecurity constraints. Currently, this fails as the
> ServletSecurityInfo does not contain the @RolesAllowed annotation(s).
>
> I was wondering if the RestEasy role based security implementation could
> be improved to update the ServletSecurityInfo, so that:
> i) RestEasy aligned with the more recent Servlet standards, and
> ii) any dependencies (such as JASPIAuthenticationMechanism) would
> naturally work, and
> iii) much of the container plumbing could be removed from most modern
> (Servlet 3.0+) RestEasy deployments
>

You would have to do this work at the

> I am happy to have a look at implementing such an enhancement, but would
> appreciate some guidance on:
> a) whether this approach is reasonable,
> b) appropriate points of the RestEasy internals which would make sense
> to start the integration (presumably partly in the scan processing, and
> partly in the dispatch)
>
> Thanks
>
> Paul
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience.  Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>

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