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 <bburke@redhat.com> 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 <bburke@redhat.com
<mailto:bburke@redhat.com>> 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
Resteasy-developers@lists.sourceforge.net
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
Resteasy-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-developers


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