Menu
▾
▴
resteasy-developers
|
From: Paul K M. <pau...@gm...> - 2014-02-12 13:11:32
|
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, 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.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 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 |
|
From: Bill B. <bb...@re...> - 2014-02-12 14:30:57
|
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
|
|
From: Paul K M. <pau...@gm...> - 2014-02-12 15:11:19
|
Bill, many thanks for the prompt reply.
Thoughts inline.
Paul
On 12 Feb 2014, at 14:28, Bill Burke <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 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
|
|
From: Bill B. <bb...@re...> - 2014-02-12 15:41:59
|
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. > You can specify a security constraint in web.xml that forces authentication but allows all roles. Then do fine grain RBAC using @RoleAllowed and the simple Resteasy rbac filter, can't you? Never used JASPI, so maybe I'm just not understanding the full scope of the problem. What does ServerAuthModule need to know? That auth needs to happen? Or does it have to know roles allowed too? >> >> 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. > web.xml == @ServletSecurity. They are the same metadata excpet that XML takes precendence over annotations. Same thing in EJB land with ejb-jar.xml. Servlet URL mappings do not support regular expressions AFAIK i.e. @Path("{path : (foo|bar)/\\d+") or even something as simple as: @Path("foo/{stuff}/do-it") > 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? I'm not sure you are right. I think this stuff is expected to be deploy-time generated metadata and not dynamic, per request. to be able to make it dynamic you'd probably have to write a Undertow Handler and add this through the JAX-RS subsystem. You need to know that Resteasy does not even see the HTTP request until after it has passed through the servlet layer. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Paul K M. <pau...@gm...> - 2014-02-12 16:33:02
|
On 12 Feb 2014, at 15:41, Bill Burke <bb...@re...> wrote: > > > 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. >> > > You can specify a security constraint in web.xml that forces authentication but allows all roles. Then do fine grain RBAC using @RoleAllowed and the simple Resteasy rbac filter, can't you? Never used JASPI, so maybe I'm just not understanding the full scope of the problem. What does ServerAuthModule need to know? That auth needs to happen? Or does it have to know roles allowed too? > >>> >>> 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. >> > > web.xml == @ServletSecurity. They are the same metadata excpet that XML takes precendence over annotations. Same thing in EJB land with ejb-jar.xml. > > Servlet URL mappings do not support regular expressions AFAIK > > i.e. > > @Path("{path : (foo|bar)/\\d+") > > or even something as simple as: > > @Path("foo/{stuff}/do-it") > > > >> 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? > > I'm not sure you are right. I think this stuff is expected to be deploy-time generated metadata and not dynamic, per request. to be able to make it dynamic you'd probably have to write a Undertow Handler and add this through the JAX-RS subsystem. > > You need to know that Resteasy does not even see the HTTP request until after it has passed through the servlet layer. Hmmm, I hadn’t appreciated that Resteasy was as independent from the servlet layer (am tracing through ServletContainerDispatcher now). I suspect there is some tension here as JASPI is particularly aligned with the web container. It might be that I need to setup security constraints for those resources that I want to further protect with the role based filter (to your earlier point), and allow other resources straight through. I suspect also I’m just about to run into the limitations of the the URL mapping limitations. Will continue with the trace, and report back. Thanks > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com |
|
From: Bill B. <bb...@re...> - 2014-02-18 15:15:49
|
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 |
|
From: Paul K M. <pau...@gm...> - 2014-02-19 14:05:08
|
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 |
|
From: Bill B. <bb...@re...> - 2014-02-19 14:31:38
|
On 2/19/2014 9:04 AM, Paul K Moore wrote: > If there’s mileage in the Undertow based JAX-RS implementation however, > I’d be interested in being involved. > What I want to do is retire Resteasy's embedded servlet container (TJWS) and replace it with Undertow for all our testsuite. A servlet and non-servlet version. This is mostly uninteresting grunt work though. Bill -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com |
|
From: Ron S. <rs...@re...> - 2014-02-24 12:59:14
|
I can do that. On 02/19/2014 10:31 AM, Bill Burke wrote: > > On 2/19/2014 9:04 AM, Paul K Moore wrote: >> If there’s mileage in the Undertow based JAX-RS implementation however, >> I’d be interested in being involved. >> > What I want to do is retire Resteasy's embedded servlet container (TJWS) > and replace it with Undertow for all our testsuite. A servlet and > non-servlet version. This is mostly uninteresting grunt work though. > > Bill > |
Thanks for helping keep SourceForge clean.
X