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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Bill,

Many thanks for this.  

My specific use case has been solved through some further discussion with Stuart about the population (or otherwise) of the ServletSercurityInfo (see http://lists.jboss.org/pipermail/undertow-dev/2014-February/000712.html).  

It turns out there was a bug in the JASPIAuthenticationMechanism (see https://issues.jboss.org/browse/WFLY-2938) that was treating annotated servlets differently from constraints configured in web.xml (hence my initial confusion).  

This bug was effectively stopping me from configuring security constraints in web.xml that would allow successful JASPI authentication and the resteasy.role.based.security feature to work.

That said, this just goes to show how “distance” between the JAX-RS implementation and the web container implementation can cause some subtle issues :)

At the recent London JBUG, and afterwards, I had some discussion about building some solution more directly on Undertow (servlet-based or otherwise).  I must admit however that I was / am getting slightly out of my depth!

With regard to my initial proposal, as per your explanation, it looks like the enhancement approach here is incorrect.  

If there’s mileage in the Undertow based JAX-RS implementation however, I’d be interested in being involved.

Best

Paul

On 18 Feb 2014, at 15:15, Bill Burke <bb...@re...> wrote:

> BTW, another reason this won't work (and I'm stupid for not saying it earlier) is that there is one servlet deployed for each @ApplicationPath.
> 
> On 2/12/2014 10:11 AM, Paul K Moore wrote:
>> Bill, many thanks for the prompt reply.
>> 
>> Thoughts inline.
>> 
>> Paul
>> 
>> On 12 Feb 2014, at 14:28, Bill Burke <bb...@re...
>> <mailto:bb...@re...>> wrote:
>> 
>>> Resteasy's vanilla @RoleAllowed implementation is just a simple JAX-RS
>>> filter that just delegates to SecurityContext.isUserInRole() which
>>> delegates to the HttpServletRequest.
>> 
>> Understood.
>> 
>>> 
>>> 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?
>> 
>> Because the
>> org.wildfly.extension.undertow.security.jaspi.JASPIAuthenticationMechanism
>> <https://github.com/wildfly/wildfly/blob/master/undertow/src/main/java/org/wildfly/extension/undertow/security/jaspi/JASPIAuthenticationMechanism.java?source=cc> uses
>> the Undertow ServletSecurityInfo to determine whether or not to set the
>> isMandatory flag (see esp the isMandatory() method).  My JASPI
>> ServerAuthModule uses the isMandatory flag to determine whether to
>> attempt an authentication, or not.
>> 
>> The use of the isMandatory flag in this manner is how (I understand) the
>> JASPI[C] spec specifies that the requirement for authentication should
>> be communicated to the ServerAuthModule.
>> 
>>> 
>>> 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.
>> 
>> Understood, but I’m thinking less from the perspective of the deployment
>> descriptor servlet constraints and more along the lines of the
>> @ServletSecurity annotations, which seems quite aligned to the @Path etc
>> JAX-RS annotations, and certainly more powerful than the wildcard
>> servlet constraints.
>> 
>> e.g.
>> 
>> @ServletSecurity(@HttpConstraint(rolesAllowed = { "quickstarts" }))
>> 
>> from
>> https://github.com/jboss-developer/jboss-eap-quickstarts/blob/master/servlet-security/src/main/java/org/jboss/as/quickstarts/servlet_security/SecuredServlet.java
>> 
>>> 
>>> 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?
>> 
>> Yes, but the ServletSecurityInfo gets populated as part of the request
>> handling, and I was thinking that propagating the @RolesAllowed
>> annotations into this configuration might be a sensible (container
>> aligned) thing to do.
>> 
>> I freely admit however that I’ve (currently) no idea at which point in
>> the lifecycle the SSI is populated and therefore whether the approach is
>> plausible?
>> 
>>> 
>>> 
>>> 
>>> 
>>> 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
>>> 
>>> ------------------------------------------------------------------------------
>>> 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