resteasy-developers — The main list for RESTEasy developers to discuss project development

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

[Ron S. <rs...@re...>]

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
>

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

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

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

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

[Paul K M. <pau...@gm...>]

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

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

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

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

Re: [Resteasy-developers] RON SIGAL WE NEED YOU! Re: RESTEasy, CDI, embedded Jetty, bean validation is ignored

[Abhijit S. <abh...@gm...>]

Last one bounced so sending again...


On Fri, Feb 14, 2014 at 11:02 PM, Abhijit Sarkar
<abh...@gm...>wrote:

> I might've spoken too soon :) Now Weld is blowing up and I'm pretty sure,
> this time it's not my mistake. https://issues.jboss.org/browse/WELD-1606
> I think more testing is required in the servlet containers. Let me know if
> I can help in some way.
>
> Regards,
> Abhijit
>
>
> On Fri, Feb 14, 2014 at 4:18 PM, Ron Sigal <rs...@re...> wrote:
>
>>  Hi Abhijit,
>>
>> That's great news.  Resteasy is Bill Burke's project.  You should start
>> by assuming it works.  ;-)
>>
>> re: "*When the validation fails though, there's no error message
>> returned from the server* (at least not that I see as response to curl).
>> Is it not set in the response?"
>>
>> Actually, an error report should come back.  See
>> http://docs.jboss.org/resteasy/docs/3.0.6.Final/userguide/html/Validation.html#d4e2429
>> .
>>
>> -Ron
>>
>> [Second attempt.  Didn't find lists.sourceforge.ne]
>>
>>  On 02/14/2014 09:28 AM, Abhijit Sarkar wrote:
>>
>>  Ron,
>> I found and fixed the problem, thanks to an eye opener from Michal Gajdos
>> (http://blog.dejavu.sk), who asked if I was trying to validate the
>> return value.
>>
>>  I put the annotation on the method assuming it'd apply to everything in
>> the method signature. What I actually wanted was to validate the parameter!
>> When I moved the annotation from method to parameter, it worked! Here's
>> the working code:
>> https://github.com/abhijitsarkar/groovy/tree/resteasy/movie-manager
>>
>>  Goes to show just how important it is to ask the right question. I
>> spent days on it not realizing it was working all the time.
>>
>>  Question for you: *When the validation fails though, there's no error
>> message returned from the server* (at least not that I see as response
>> to curl). Is it not set in the response?
>>
>>  Thank you much.
>>
>>  Regards,
>> Abhijit
>>
>>
>> On Thu, Feb 13, 2014 at 8:44 PM, Ron Sigal <rs...@re...> wrote:
>>
>>>  Hi Abhijit,
>>>
>>> I will add java:comp/env to the lookup code.  I should have tested with
>>> some environment in addition to AS / WildFly.  Thank you.
>>>
>>> -Ron
>>>
>>> On 02/13/2014 10:02 PM, Abhijit Sarkar wrote:
>>>
>>>  Ron,
>>> You made a good point. The InjectingConstraintValidatorFactory does use
>>> CDI itself for BeanManager injection, although I don't understand why
>>> that'd be a problem. By the time it happens, the BeanManager should've been
>>> bound to the JNDI.
>>>
>>>
>>> https://github.com/hibernate/hibernate-validator/blob/master/cdi/src/main/java/org/hibernate/validator/internal/cdi/InjectingConstraintValidatorFactory.java
>>>
>>>  One thing I noticed is that the JNDI URL you're trying to look up is
>>> only valid for an EE environment. Tomcat/Jetty doesn't allow an application
>>> to bind to java:comp but only java:comp/env. You may wanna retry the lookup
>>> with the later URL if the first one fails. Gosh, I love Java EE but I think
>>> it's different specs have gotten out of hand so much that they only work in
>>> a very restricted environment.
>>>
>>>  Regards,
>>> Abhijit
>>>
>>>
>>> On Thu, Feb 13, 2014 at 5:13 PM, Ron Sigal <rs...@re...> wrote:
>>>
>>>>  Hi Abhijit,
>>>>
>>>> As you've noted, the message
>>>>
>>>>     plugins.validation.ValidatorContextResolver - Unable to find CDI supporting ValidatorFactory. Using default ValidatorFactory
>>>>
>>>> comes from ValidatorContextResolver in resteasy-validator-provider-11:
>>>>
>>>>    ValidatorFactory getValidatorFactory()
>>>>    {
>>>>       ValidatorFactory tmpValidatorFactory = validatorFactory;
>>>>       if (tmpValidatorFactory == null)
>>>>       {
>>>>          synchronized (RD_LOCK)
>>>>          {
>>>>             tmpValidatorFactory = validatorFactory;
>>>>             if (tmpValidatorFactory == null)
>>>>             {
>>>>                try
>>>>                {
>>>>                   Context context = new InitialContext();
>>>>                   validatorFactory = tmpValidatorFactory =
>>>> ValidatorFactory.class.cast(context.lookup("java:comp/ValidatorFactory"));
>>>>                   logger.debug("Using CDI supporting " +
>>>> validatorFactory);
>>>>                }
>>>>                catch (NamingException e)
>>>>                {
>>>>                   logger.info("Unable to find CDI supporting
>>>> ValidatorFactory. Using default ValidatorFactory");
>>>>                   HibernateValidatorConfiguration config =
>>>> Validation.byProvider(HibernateValidator.class).configure();
>>>>                   validatorFactory = tmpValidatorFactory =
>>>> config.buildValidatorFactory();
>>>>                }
>>>>             }
>>>>          }
>>>>       }
>>>>       return validatorFactory;
>>>>    }
>>>>
>>>> Running in WildFly 8, the retrieved ValidatorFactory is
>>>> org.jboss.as.ee.beanvalidation.LazyValidatorFactory, which lives in
>>>> jboss-as-ee-7.1.0.*final*.jar.  I don't know exactly what
>>>> LazyValidatorFactory is, but I found the following in an old email:
>>>>
>>>> >>As of 1.1, Bean Validation integrates with CDI within EE environments
>>>> (when the deployment is CDI-enabled), which e.g. allows to @Inject
>>>> dependencies into validators.
>>>> >>
>>>>  >>A VF bootstrapped via Validation#buildDefaultValidatorFactory() is
>>>> not CDI-enabled, though. Therefore, in WF there will be a CDI portable
>>>> extension provided by the HV project which registers a CDI-enabled
>>>> ValidatorFactory for a deployment. The idea then is that any integrators of
>>>> BV such as JAX-RS/RESTEasy use this VF.
>>>> >
>>>> >Does that exist now?  How do we load that ValidatorFactory?
>>>>
>>>>  There is LazyValidatorFactory in the WildFly EE module[1] which is
>>>> added as attachment to the deployment unit (the key is
>>>> BeanValidationAttachments.VALIDATOR_FACTORY) and also bound to JNDI (under
>>>> "java:comp/ValidatorFactory").
>>>>
>>>>
>>>> It seems similar to the description of
>>>> InjectingConstraintValidatorFactory.  Unless your constraint
>>>> validators themselves are using CDI injection, I'm not sure why falling
>>>> back to the default ValidatorFactory would prevent validation from
>>>> occurring.
>>>>
>>>> I see you've discovered RESTEASY-1008.  I don't think it's the same
>>>> problem, since RESTEASY-1008 describes a situation in which validation
>>>> occurs, but enabling CDI causes problems.  However, RESTEASY-1008 came as a
>>>> surprise, and the two problems could be related.
>>>>
>>>> As a matter of fact, I'm working on RESTEASY-1008 and making some
>>>> progress.  There are a lot of details to deal with, and I'm going to be off
>>>> next week, but as soon as I have some working jars I'll attach to the
>>>> discussion you recently joined at
>>>> https://community.jboss.org/message/854886#854886.  Maybe they will
>>>> help. In the meantime, you could try to make sure either
>>>> LazyValidatorFactory or InjectingConstraintValidatorFactory is
>>>> available.  That seems to be a Jetty issue, which I don't know much about.
>>>>
>>>> -Ron
>>>>
>>>>
>>>> On 02/11/2014 10:29 PM, Bill Burke wrote:
>>>>
>>>> On 2/11/2014 9:02 PM, Abhijit Sarkar wrote:
>>>>
>>>>  Hi Bill,
>>>> 1. CDI itself is enabled (I get not null injections) and
>>>> CdiInjectorFactory is present in
>>>> jetty-override.xml,https://github.com/abhijitsarkar/groovy/blob/master/movie-manager/movie-manager-web/src/main/webapp/WEB-INF/jetty-override.xml.
>>>> 2. The log message is coming
>>>> from org.jboss.resteasy.plugins.validation.ValidatorContextResolver - I
>>>> found that much. What I'm trying to figure out is who's going to do this
>>>> binding in a non Java EE environment.
>>>>
>>>>
>>>>  I don't know how this binding happens.  Hopefully Ron knows...He did
>>>> this integration.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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
>>>>
>>>>
>>>
>>>
>>
>>
>

Re: [Resteasy-developers] RON SIGAL WE NEED YOU! Re: RESTEasy, CDI, embedded Jetty, bean validation is ignored

[Ron S. <rs...@re...>]

Hi Abhijit,

I will add java:comp/env to the lookup code.  I should have tested with 
some environment in addition to AS / WildFly.  Thank you.

-Ron

On 02/13/2014 10:02 PM, Abhijit Sarkar wrote:
> Ron,
> You made a good point. The InjectingConstraintValidatorFactory does 
> use CDI itself for BeanManager injection, although I don't understand 
> why that'd be a problem. By the time it happens, the BeanManager 
> should've been bound to the JNDI.
>
> https://github.com/hibernate/hibernate-validator/blob/master/cdi/src/main/java/org/hibernate/validator/internal/cdi/InjectingConstraintValidatorFactory.java
>
> One thing I noticed is that the JNDI URL you're trying to look up is 
> only valid for an EE environment. Tomcat/Jetty doesn't allow an 
> application to bind to java:comp but only java:comp/env. You may wanna 
> retry the lookup with the later URL if the first one fails. Gosh, I 
> love Java EE but I think it's different specs have gotten out of hand 
> so much that they only work in a very restricted environment.
>
> Regards,
> Abhijit
>
>
> On Thu, Feb 13, 2014 at 5:13 PM, Ron Sigal <rs...@re... 
> <mailto:rs...@re...>> wrote:
>
>     Hi Abhijit,
>
>     As you've noted, the message
>
>          plugins.validation.ValidatorContextResolver - Unable to find CDI supporting ValidatorFactory. Using default ValidatorFactory
>
>     comes from ValidatorContextResolver in resteasy-validator-provider-11:
>
>            ValidatorFactory getValidatorFactory()
>            {
>               ValidatorFactory tmpValidatorFactory = validatorFactory;
>               if (tmpValidatorFactory == null)
>               {
>                  synchronized (RD_LOCK)
>                  {
>                     tmpValidatorFactory = validatorFactory;
>                     if (tmpValidatorFactory == null)
>                     {
>                        try
>                        {
>                           Context context = new InitialContext();
>                           validatorFactory = tmpValidatorFactory =
>         ValidatorFactory.class.cast(context.lookup("java:comp/ValidatorFactory"));
>                           logger.debug("Using CDI supporting " +
>         validatorFactory);
>                        }
>                        catch (NamingException e)
>                        {
>         logger.info <http://logger.info>("Unable to find CDI
>         supporting ValidatorFactory. Using default ValidatorFactory");
>                           HibernateValidatorConfiguration config =
>         Validation.byProvider(HibernateValidator.class).configure();
>                           validatorFactory = tmpValidatorFactory =
>         config.buildValidatorFactory();
>                        }
>                     }
>                  }
>               }
>               return validatorFactory;
>            }
>
>     Running in WildFly 8, the retrieved ValidatorFactory is
>     org.jboss.as.ee.beanvalidation.LazyValidatorFactory, which lives
>     in |jboss-as-ee-7.1.0.*final*.jar.  I don't know exactly what
>     LazyValidatorFactory is, but I found the following in an old email:
>     |
>>     >>As of 1.1, Bean Validation integrates with CDI within EE
>>     environments (when the deployment is CDI-enabled), which e.g.
>>     allows to @Inject dependencies into validators.
>>     >>
>>     >>A VF bootstrapped via Validation#buildDefaultValidatorFactory()
>>     is not CDI-enabled, though. Therefore, in WF there will be a CDI
>>     portable extension provided by the HV project which registers a
>>     CDI-enabled ValidatorFactory for a deployment. The idea then is
>>     that any integrators of BV such as JAX-RS/RESTEasy use this VF.
>>     >
>>     >Does that exist now?  How do we load that ValidatorFactory?
>>
>>     There is LazyValidatorFactory in the WildFly EE module[1] which
>>     is added as attachment to the deployment unit (the key is
>>     BeanValidationAttachments.VALIDATOR_FACTORY) and also bound to
>>     JNDI (under "java:comp/ValidatorFactory").
>>
>
>     It seems similar to the description of
>     InjectingConstraintValidatorFactory. Unless your constraint
>     validators themselves are using CDI injection, I'm not sure why
>     falling back to the default ValidatorFactory would prevent
>     validation from occurring.
>
>     I see you've discovered RESTEASY-1008.  I don't think it's the
>     same problem, since RESTEASY-1008 describes a situation in which
>     validation occurs, but enabling CDI causes problems.  However,
>     RESTEASY-1008 came as a surprise, and the two problems could be
>     related.
>
>     As a matter of fact, I'm working on RESTEASY-1008 and making some
>     progress.  There are a lot of details to deal with, and I'm going
>     to be off next week, but as soon as I have some working jars I'll
>     attach to the discussion you recently joined at
>     https://community.jboss.org/message/854886#854886. Maybe they will
>     help. In the meantime, you could try to make sure either
>     LazyValidatorFactory or InjectingConstraintValidatorFactory is
>     available.  That seems to be a Jetty issue, which I don't know
>     much about.
>
>     -Ron
>
>
>     On 02/11/2014 10:29 PM, Bill Burke wrote:
>>     On 2/11/2014 9:02 PM, Abhijit Sarkar wrote:
>>>     Hi Bill,
>>>     1. CDI itself is enabled (I get not null injections) and
>>>     CdiInjectorFactory is present in
>>>     jetty-override.xml,https://github.com/abhijitsarkar/groovy/blob/master/movie-manager/movie-manager-web/src/main/webapp/WEB-INF/jetty-override.xml.
>>>     2. The log message is coming
>>>     from org.jboss.resteasy.plugins.validation.ValidatorContextResolver - I
>>>     found that much. What I'm trying to figure out is who's going to do this
>>>     binding in a non Java EE environment.
>>>
>>     I don't know how this binding happens.  Hopefully Ron knows...He did
>>     this integration.
>>
>
>
>     ------------------------------------------------------------------------------
>     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...
>     <mailto:Res...@li...>
>     https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>
>

Re: [Resteasy-developers] RON SIGAL WE NEED YOU! Re: RESTEasy, CDI, embedded Jetty, bean validation is ignored

[Ron S. <rs...@re...>]

By the way, if you want to step through the code, Resteasy invokes 
validation in org.jboss.resteasy.core.ResourceMethodInvoker and 
org.jboss.resteasy.core.MethodInjectorImpl, both of which are in the 
resteasy-jaxrs module.

Also, when I get the new validation/CDI stuff working, I'd like to 
create a Jetty test.  If you've figured out the problem by then, maybe 
you can help me.  ;-)

-Ron

On 02/13/2014 06:13 PM, Ron Sigal wrote:
> Hi Abhijit,
>
> As you've noted, the message
>      plugins.validation.ValidatorContextResolver - Unable to find CDI supporting ValidatorFactory. Using default ValidatorFactory
> comes from ValidatorContextResolver in resteasy-validator-provider-11:
>
>        ValidatorFactory getValidatorFactory()
>        {
>           ValidatorFactory tmpValidatorFactory = validatorFactory;
>           if (tmpValidatorFactory == null)
>           {
>              synchronized (RD_LOCK)
>              {
>                 tmpValidatorFactory = validatorFactory;
>                 if (tmpValidatorFactory == null)
>                 {
>                    try
>                    {
>                       Context context = new InitialContext();
>                       validatorFactory = tmpValidatorFactory =
>     ValidatorFactory.class.cast(context.lookup("java:comp/ValidatorFactory"));
>                       logger.debug("Using CDI supporting " +
>     validatorFactory);
>                    }
>                    catch (NamingException e)
>                    {
>                       logger.info("Unable to find CDI supporting
>     ValidatorFactory. Using default ValidatorFactory");
>                       HibernateValidatorConfiguration config =
>     Validation.byProvider(HibernateValidator.class).configure();
>                       validatorFactory = tmpValidatorFactory =
>     config.buildValidatorFactory();
>                    }
>                 }
>              }
>           }
>           return validatorFactory;
>        }
>
> Running in WildFly 8, the retrieved ValidatorFactory is 
> org.jboss.as.ee.beanvalidation.LazyValidatorFactory, which lives in 
> |jboss-as-ee-7.1.0.*final*.jar.  I don't know exactly what 
> LazyValidatorFactory is, but I found the following in an old email:
> |
>> >>As of 1.1, Bean Validation integrates with CDI within EE 
>> environments (when the deployment is CDI-enabled), which e.g. allows 
>> to @Inject dependencies into validators.
>> >>
>> >>A VF bootstrapped via Validation#buildDefaultValidatorFactory() is 
>> not CDI-enabled, though. Therefore, in WF there will be a CDI 
>> portable extension provided by the HV project which registers a 
>> CDI-enabled ValidatorFactory for a deployment. The idea then is that 
>> any integrators of BV such as JAX-RS/RESTEasy use this VF.
>> >
>> >Does that exist now?  How do we load that ValidatorFactory?
>>
>> There is LazyValidatorFactory in the WildFly EE module[1] which is 
>> added as attachment to the deployment unit (the key is 
>> BeanValidationAttachments.VALIDATOR_FACTORY) and also bound to JNDI 
>> (under "java:comp/ValidatorFactory").
>>
>
> It seems similar to the description of 
> InjectingConstraintValidatorFactory. Unless your constraint validators 
> themselves are using CDI injection, I'm not sure why falling back to 
> the default ValidatorFactory would prevent validation from occurring.
>
> I see you've discovered RESTEASY-1008.  I don't think it's the same 
> problem, since RESTEASY-1008 describes a situation in which validation 
> occurs, but enabling CDI causes problems.  However, RESTEASY-1008 came 
> as a surprise, and the two problems could be related.
>
> As a matter of fact, I'm working on RESTEASY-1008 and making some 
> progress.  There are a lot of details to deal with, and I'm going to 
> be off next week, but as soon as I have some working jars I'll attach 
> to the discussion you recently joined at 
> https://community.jboss.org/message/854886#854886. Maybe they will 
> help. In the meantime, you could try to make sure either 
> LazyValidatorFactory or InjectingConstraintValidatorFactory is 
> available.  That seems to be a Jetty issue, which I don't know much about.
>
> -Ron
>
>
> On 02/11/2014 10:29 PM, Bill Burke wrote:
>> On 2/11/2014 9:02 PM, Abhijit Sarkar wrote:
>>> Hi Bill,
>>> 1. CDI itself is enabled (I get not null injections) and
>>> CdiInjectorFactory is present in
>>> jetty-override.xml,https://github.com/abhijitsarkar/groovy/blob/master/movie-manager/movie-manager-web/src/main/webapp/WEB-INF/jetty-override.xml.
>>> 2. The log message is coming
>>> from org.jboss.resteasy.plugins.validation.ValidatorContextResolver - I
>>> found that much. What I'm trying to figure out is who's going to do this
>>> binding in a non Java EE environment.
>>>
>> I don't know how this binding happens.  Hopefully Ron knows...He did
>> this integration.
>>
>
>
>
> ------------------------------------------------------------------------------
> 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

Re: [Resteasy-developers] RON SIGAL WE NEED YOU! Re: RESTEasy, CDI, embedded Jetty, bean validation is ignored

[Ron S. <rs...@re...>]

Hi Abhijit,

As you've noted, the message

     plugins.validation.ValidatorContextResolver - Unable to find CDI supporting ValidatorFactory. Using default ValidatorFactory

comes from ValidatorContextResolver in resteasy-validator-provider-11:

        ValidatorFactory getValidatorFactory()
        {
           ValidatorFactory tmpValidatorFactory = validatorFactory;
           if (tmpValidatorFactory == null)
           {
              synchronized (RD_LOCK)
              {
                 tmpValidatorFactory = validatorFactory;
                 if (tmpValidatorFactory == null)
                 {
                    try
                    {
                       Context context = new InitialContext();
                       validatorFactory = tmpValidatorFactory =
    ValidatorFactory.class.cast(context.lookup("java:comp/ValidatorFactory"));
                       logger.debug("Using CDI supporting " +
    validatorFactory);
                    }
                    catch (NamingException e)
                    {
                       logger.info("Unable to find CDI supporting
    ValidatorFactory. Using default ValidatorFactory");
                       HibernateValidatorConfiguration config =
    Validation.byProvider(HibernateValidator.class).configure();
                       validatorFactory = tmpValidatorFactory =
    config.buildValidatorFactory();
                    }
                 }
              }
           }
           return validatorFactory;
        }

Running in WildFly 8, the retrieved ValidatorFactory is 
org.jboss.as.ee.beanvalidation.LazyValidatorFactory, which lives in 
|jboss-as-ee-7.1.0.*final*.jar. I don't know exactly what 
LazyValidatorFactory is, but I found the following in an old email:
|
> >>As of 1.1, Bean Validation integrates with CDI within EE 
> environments (when the deployment is CDI-enabled), which e.g. allows 
> to @Inject dependencies into validators.
> >>
> >>A VF bootstrapped via Validation#buildDefaultValidatorFactory() is 
> not CDI-enabled, though. Therefore, in WF there will be a CDI portable 
> extension provided by the HV project which registers a CDI-enabled 
> ValidatorFactory for a deployment. The idea then is that any 
> integrators of BV such as JAX-RS/RESTEasy use this VF.
> >
> >Does that exist now?  How do we load that ValidatorFactory?
>
> There is LazyValidatorFactory in the WildFly EE module[1] which is 
> added as attachment to the deployment unit (the key is 
> BeanValidationAttachments.VALIDATOR_FACTORY) and also bound to JNDI 
> (under "java:comp/ValidatorFactory").
>

It seems similar to the description of 
InjectingConstraintValidatorFactory. Unless your constraint validators 
themselves are using CDI injection, I'm not sure why falling back to the 
default ValidatorFactory would prevent validation from occurring.

I see you've discovered RESTEASY-1008.  I don't think it's the same 
problem, since RESTEASY-1008 describes a situation in which validation 
occurs, but enabling CDI causes problems.  However, RESTEASY-1008 came 
as a surprise, and the two problems could be related.

As a matter of fact, I'm working on RESTEASY-1008 and making some 
progress.  There are a lot of details to deal with, and I'm going to be 
off next week, but as soon as I have some working jars I'll attach to 
the discussion you recently joined at 
https://community.jboss.org/message/854886#854886.  Maybe they will 
help. In the meantime, you could try to make sure either 
LazyValidatorFactory or InjectingConstraintValidatorFactory is 
available.  That seems to be a Jetty issue, which I don't know much about.

-Ron


On 02/11/2014 10:29 PM, Bill Burke wrote:
>
> On 2/11/2014 9:02 PM, Abhijit Sarkar wrote:
>> Hi Bill,
>> 1. CDI itself is enabled (I get not null injections) and
>> CdiInjectorFactory is present in
>> jetty-override.xml,https://github.com/abhijitsarkar/groovy/blob/master/movie-manager/movie-manager-web/src/main/webapp/WEB-INF/jetty-override.xml.
>> 2. The log message is coming
>> from org.jboss.resteasy.plugins.validation.ValidatorContextResolver - I
>> found that much. What I'm trying to figure out is who's going to do this
>> binding in a non Java EE environment.
>>
> I don't know how this binding happens.  Hopefully Ron knows...He did
> this integration.
>

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

[Paul K M. <pau...@gm...>]

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

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

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

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

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

[Paul K M. <pau...@gm...>]

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

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

[Resteasy-developers] Proposed Role Based Security enhancement

[Paul K M. <pau...@gm...>]

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

[Resteasy-developers] RON SIGAL WE NEED YOU! Re: RESTEasy, CDI, embedded Jetty, bean validation is ignored

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

On 2/11/2014 9:02 PM, Abhijit Sarkar wrote:
> Hi Bill,
> 1. CDI itself is enabled (I get not null injections) and
> CdiInjectorFactory is present in
> jetty-override.xml,https://github.com/abhijitsarkar/groovy/blob/master/movie-manager/movie-manager-web/src/main/webapp/WEB-INF/jetty-override.xml.
> 2. The log message is coming
> from org.jboss.resteasy.plugins.validation.ValidatorContextResolver - I
> found that much. What I'm trying to figure out is who's going to do this
> binding in a non Java EE environment.
>

I don't know how this binding happens.  Hopefully Ron knows...He did 
this integration.

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

Re: [Resteasy-developers] RESTEasy, CDI, embedded Jetty, bean validation is ignored

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

Not a combination we have tested or tried to get to work.  Honestly, I 
don't understand why you don't just use latest Wildfly/Arquillian as its 
all integrated there.  I can give you hints that may help to get it 
together, but I don't have time to debug it for you.


#1.  CDI integration is not being used in your resteasy deployment.  add 
the following context-param

<context-param>
    <param-name>resteasy.injector.factory</param-name>
    <param-value>org.jboss.resteasy.cdi.CdiInjectorFactory</para-value>
</context-param>

I'm not even sure that will work.

#2  The log message: "Unable to find CDI supporting ValidatorFactory" 
means that Resteasy integration could not find a ValidatorFactory under 
the InitialContext "java:comp/ValidatorFactory"  Maybe CDI is not 
enabled?  I have never embedded Weld in a non JBoss environment.

On 2/11/2014 7:22 PM, Abhijit Sarkar wrote:
> Perhaps I didn't provide enough detail previously. The code can be found
> here
> https://github.com/abhijitsarkar/groovy/tree/master/movie-manager/movie-manager-web
>
> A log gist is here: https://gist.github.com/anonymous/8947319
>
> I've tried everything under the sun without any success. Pls help.
>
>
> On Tue, Feb 11, 2014 at 1:13 AM, Abhijit Sarkar
> <abh...@gm... <mailto:abh...@gm...>> wrote:
>
>     Hi,
>     I've a Groovy project where I use RESTEasy with CDI (Weld) and
>     deploy to embedded Jetty. What I can't seem to get working is bean
>     validation. The documentation says that adding
>     'resteasy-validator-provider-11' along with hibernate validator
>     dependencies (hibernate-validator, hibernate-validator-cdi,
>     javax.el-api, javax.el) is enough. But the bean validation is simply
>     ignored by RESTEasy. I curiously also get the following message in
>     the logs:
>
>     plugins.validation.ValidatorContextResolver - Unable to find CDI
>     supporting ValidatorFactory. Using default ValidatorFactory
>
>     I tried registering Hibernate InjectingConstraintValidatorFactory in
>     META-INF/validation.xml but it depends on a BeanManager being
>     injected and blows up at runtime.
>
>     What can I do to get this working?
>
>     RESTEasy 3.0.6.Final
>     Weld servlet 2.1.2.Final
>     Hibernate validator 5.0.3.Final
>     Jetty embedded 9.1.1.v20140108
>
>     Regards,
>     Abhijit
>
>
>
>
> ------------------------------------------------------------------------------
> 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

Re: [Resteasy-developers] RESTEasy, CDI, embedded Jetty, bean validation is ignored

[Abhijit S. <abh...@gm...>]

Perhaps I didn't provide enough detail previously. The code can be found
here
https://github.com/abhijitsarkar/groovy/tree/master/movie-manager/movie-manager-web

A log gist is here: https://gist.github.com/anonymous/8947319

I've tried everything under the sun without any success. Pls help.


On Tue, Feb 11, 2014 at 1:13 AM, Abhijit Sarkar <abh...@gm...>wrote:

> Hi,
> I've a Groovy project where I use RESTEasy with CDI (Weld) and deploy to
> embedded Jetty. What I can't seem to get working is bean validation. The
> documentation says that adding 'resteasy-validator-provider-11' along with
> hibernate validator dependencies (hibernate-validator,
> hibernate-validator-cdi, javax.el-api, javax.el) is enough. But the bean
> validation is simply ignored by RESTEasy. I curiously also get the
> following message in the logs:
>
> plugins.validation.ValidatorContextResolver - Unable to find CDI
> supporting ValidatorFactory. Using default ValidatorFactory
>
> I tried registering Hibernate InjectingConstraintValidatorFactory in
> META-INF/validation.xml but it depends on a BeanManager being injected and
> blows up at runtime.
>
> What can I do to get this working?
>
> RESTEasy 3.0.6.Final
> Weld servlet 2.1.2.Final
> Hibernate validator 5.0.3.Final
> Jetty embedded 9.1.1.v20140108
>
> Regards,
> Abhijit
>

[Resteasy-developers] RESTEasy, CDI, embedded Jetty, bean validation is ignored

[Abhijit S. <abh...@gm...>]

Hi,
I've a Groovy project where I use RESTEasy with CDI (Weld) and deploy to
embedded Jetty. What I can't seem to get working is bean validation. The
documentation says that adding 'resteasy-validator-provider-11' along with
hibernate validator dependencies (hibernate-validator,
hibernate-validator-cdi, javax.el-api, javax.el) is enough. But the bean
validation is simply ignored by RESTEasy. I curiously also get the
following message in the logs:

plugins.validation.ValidatorContextResolver - Unable to find CDI supporting
ValidatorFactory. Using default ValidatorFactory

I tried registering Hibernate InjectingConstraintValidatorFactory in
META-INF/validation.xml but it depends on a BeanManager being injected and
blows up at runtime.

What can I do to get this working?

RESTEasy 3.0.6.Final
Weld servlet 2.1.2.Final
Hibernate validator 5.0.3.Final
Jetty embedded 9.1.1.v20140108

Regards,
Abhijit

Re: [Resteasy-developers] resteasy-cdi problem in wildfly 8CR1

[Matt D. <mat...@gm...>]

Created https://issues.jboss.org/browse/RESTEASY-1015


On Fri, Jan 31, 2014 at 4:45 PM, Bill Burke <bb...@re...> wrote:

> Log a JIRA and I'll forward it to the apropriate people.  I don't think
> I have the knowledge to fix this.  We made a change in wildfly that all
> JAX-RS instances are managed by CDI because of managed beans and such.
> Maybe it is just a matter of Weld making better decisions about what is
> and what isn't a CDI bean.
>
> On 1/31/2014 6:29 PM, Matt Drees wrote:
> > Hi Resteasy folks,
> >
> > I've been trying to get my app (which currently runs on jboss 7.1)
> > working on WIldfly 8 CR1 flush out any issues before Wildfly 8 Final is
> > released.
> >
> > I hit a problem that I believe to be caused by how resteasy-cdi behaves
> > in a CDI 1.1 environment.
> >
> > My app uses a third-party jax-rs library for using Gson to serialize
> > json.  One of the @Providers in this library is a final class:
> >
> http://grepcode.com/file/repo1.maven.org/maven2/net.derquinse/derquinse-common-jaxrs/1.0.34/net/derquinse/common/jaxrs/ByteSourceBodyWriter.java
> >
> > After switching to Wildfly 8, when I attempt to make a jax-rs request to
> > my app, the request fails with a UnproxyableResolutionException (full
> > stacktrace below [1]), because Weld can't create a proxy for
> > ByteSourceBodyWriter.  And it's true; this class isn't proxyable, and
> > Weld is doing the right thing by complaining about it.
> >
> > I determined that this error didn't occur in JBoss AS7 because in CDI
> > 1.0, there was never a ProcessAnnotatedType event raised for
> > ByteSourceBodyWriter.  This class lived in a jar without a beans.xml
> > file, so Weld ignored it.  In CDI 1.1, however,
> > derquinse-common-jaxrs.jar seems to be treated as an 'implicit' bean
> > archive, and though none of its classes are annotated with scope
> > annotations (so normally they would not be treated as CDI beans),
> > ProcessAnnotatedType events are now raised.  And resteasy-cdi is
> >   picking up these events, detecting that the Providers have no scope
> > annotations, and adding corresponding annotations (@ApplicationScoped,
> > in this case) by wrapping the AnnotatedType. Thus, these classes that
> > weren't intended by the author to be CDI beans are now being treated as
> > CDI beans.
> >
> > To be concrete, this log line (and several other similar lines) occur
> > for wildfly 8, but not for jboss 7.1:
> >
> >     12:08:32,904 DEBUG [org.jboss.resteasy.cdi.ResteasyCdiExtension]
> >     (MSC service thread 1-11) Discovered CDI bean which is a JAX-RS
> >     provider net.derquinse.common.jaxrs.ByteSourceBodyWriter.
> >
> >
> >
> > This seems to be going against the intended behavior [2] of resteasy-cdi
> > -- it is only supposed to modify @Providers that are definitely CDI
> > beans, and leave non-CDI @Providers alone, letting them be managed by
> > Resteasy.
> >
> > I don't know a clean way to fix this.  I think resteasy-cdi needs to
> > determine if the AnnotatedType is intended to be a CDI bean, instead of
> > assuming that AnnotatedType events are fired only for CDI Beans.
> >   Perhaps it can use the type's classloader to determine if it comes
> > from a jar with a beans.xml defined in it. (Though to be complete, it
> > should also determine the bean-discovey-mode of the beans.xml, if any.
> >   This sounds like a lot of work.)
> >
> > Note 1: for my app, I can get around this problem by using a
> > jboss-all.xml file [3], but I think this shouldn't be necessary.
> >
> > Note 2: i'm pretty sure the derquinse-common-jaxrs jar has no
> > scope-annotated class or session beans, so I'm not sure why it's being
> > considered as an implicit bean archive.
> >
> > What are your thoughts?  I can create a jira for you, if you'd like.
> >
> > Thanks,
> > Matt Drees
> >
> >
> >
> > [1]
> > 6:52:56,233 ERROR [org.cru.redegg.loggedErrors] (pool-11-thread-5)
> > error:: java.lang.RuntimeException: Unable to instantiate
> MessageBodyWriter
> > at
> >
> org.jboss.resteasy.spi.ResteasyProviderFactory.registerProvider(ResteasyProviderFactory.java:1383)
> > [resteasy-jaxrs-3.0.6.Final.jar:]
> > at
> >
> org.jboss.resteasy.spi.ResteasyProviderFactory.registerProvider(ResteasyProviderFactory.java:1310)
> > [resteasy-jaxrs-3.0.6.Final.jar:]
> > at
> >
> org.jboss.resteasy.spi.ResteasyProviderFactory.registerProvider(ResteasyProviderFactory.java:1232)
> > [resteasy-jaxrs-3.0.6.Final.jar:]
> > at
> >
> org.jboss.resteasy.spi.ResteasyDeployment.registerProvider(ResteasyDeployment.java:531)
> > [resteasy-jaxrs-3.0.6.Final.jar:]
> > at
> >
> org.jboss.resteasy.spi.ResteasyDeployment.registration(ResteasyDeployment.java:338)
> > [resteasy-jaxrs-3.0.6.Final.jar:]
> > at
> >
> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:241)
> > [resteasy-jaxrs-3.0.6.Final.jar:]
> > at
> >
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112)
> > [resteasy-jaxrs-3.0.6.Final.jar:]
> > at
> >
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
> > [resteasy-jaxrs-3.0.6.Final.jar:]
> > at
> >
> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:204)
> > [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> > at
> >
> io.undertow.servlet.core.ManagedServlet.getServlet(ManagedServlet.java:147)
> > [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> > at
> >
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
> > [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> > at
> >
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
> > [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> > at org.cru.redegg.servlet.RedEggFilter.doFilter(RedEggFilter.java:54)
> > [red-egg-1-20140114.172822-29.jar:]
> > at org.cru.redegg.servlet.RedEggFilter.doFilter(RedEggFilter.java:42)
> > [red-egg-1-20140114.172822-29.jar:]
> > at
> > io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56)
> > [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> > at
> >
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> > [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> > at
> >
> org.ccci.maintenance.MaintenanceServletFilter.doFilter(MaintenanceServletFilter.java:71)
> > [maintenance-filter-server-1-20131218.163934-17.jar:]
> > at
> > io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56)
> > [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> > at
> >
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> > [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> > at org.ccci.servlet.LogoutFilter.doFilter(LogoutFilter.java:52)
> [classes:]
> > at
> > io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56)
> > [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> > at
> >
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> > [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> > at
> >
> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
> > [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> > at
> >
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> > [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> > at
> >
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> > [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> > at
> >
> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:70)
> > at
> >
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> > at
> >
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113)
> > [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> > at
> >
> io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> > [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> > at
> >
> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
> > [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> > at
> >
> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
> > [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> > at
> >
> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:67)
> > [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> > at
> >
> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70)
> > [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> > at
> >
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> > at
> >
> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> > at
> >
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> > at
> >
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> > at
> >
> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240)
> > [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> > at
> >
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
> > [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> > at
> >
> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
> > [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> > at
> >
> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
> > [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:164)
> > [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> > at
> > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:654)
> > [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> > at
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> > [rt.jar:1.7.0_45]
> > at
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> > [rt.jar:1.7.0_45]
> > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> > Caused by: org.jboss.weld.exceptions.UnproxyableResolutionException:
> > WELD-001437: Normal scoped bean class
> > net.derquinse.common.jaxrs.ByteSourceBodyWriter is not proxyable because
> > the type is final or it contains a final method class
> > net.derquinse.common.jaxrs.ByteSourceBodyWriter - <unknown
> > javax.enterprise.inject.spi.Bean instance>.
> > at
> >
> org.jboss.weld.util.Proxies.getUnproxyableClassException(Proxies.java:229)
> > [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> > at
> >
> org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:178)
> [weld-core-impl-2.1.1.Final.jar:2013-12-03
> > 09:59]
> > at
> >
> org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:140)
> [weld-core-impl-2.1.1.Final.jar:2013-12-03
> > 09:59]
> > at
> >
> org.jboss.weld.bean.proxy.ClientProxyProvider.getClientProxy(ClientProxyProvider.java:214)
> > [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> > at
> >
> org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:727)
> > [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> > at
> >
> org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:753)
> > [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> > at
> >
> org.jboss.weld.util.ForwardingBeanManager.getReference(ForwardingBeanManager.java:61)
> > [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> > at
> >
> org.jboss.weld.bean.builtin.BeanManagerProxy.getReference(BeanManagerProxy.java:80)
> > [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> > at
> >
> org.jboss.resteasy.cdi.CdiConstructorInjector.construct(CdiConstructorInjector.java:64)
> > [resteasy-cdi-3.0.6.Final.jar:]
> > at
> >
> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2175)
> > [resteasy-jaxrs-3.0.6.Final.jar:]
> > at
> >
> org.jboss.resteasy.spi.ResteasyProviderFactory.addMessageBodyWriter(ResteasyProviderFactory.java:837)
> > [resteasy-jaxrs-3.0.6.Final.jar:]
> > at
> >
> org.jboss.resteasy.spi.ResteasyProviderFactory.registerProvider(ResteasyProviderFactory.java:1378)
> > [resteasy-jaxrs-3.0.6.Final.jar:]
> > ... 45 more
> >
> > [2]
> >
> http://docs.jboss.org/resteasy/docs/3.0.6.Final/userguide/html/CDI.html#d4e2034
> > [3]
> >
> https://docs.jboss.org/author/display/WFLY8/CDI+Reference#CDIReference-Suppressingimplicitbeanarchives
> >
> >
> >
> ------------------------------------------------------------------------------
> > WatchGuard Dimension instantly turns raw network data into actionable
> > security intelligence. It gives you real-time visual feedback on key
> > security issues and trends.  Skip the complicated setup - simply import
> > a virtual appliance and go from zero to informed in seconds.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&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
>
>
> ------------------------------------------------------------------------------
> WatchGuard Dimension instantly turns raw network data into actionable
> security intelligence. It gives you real-time visual feedback on key
> security issues and trends.  Skip the complicated setup - simply import
> a virtual appliance and go from zero to informed in seconds.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>

Re: [Resteasy-developers] resteasy-cdi problem in wildfly 8CR1

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

Log a JIRA and I'll forward it to the apropriate people.  I don't think 
I have the knowledge to fix this.  We made a change in wildfly that all 
JAX-RS instances are managed by CDI because of managed beans and such. 
Maybe it is just a matter of Weld making better decisions about what is 
and what isn't a CDI bean.

On 1/31/2014 6:29 PM, Matt Drees wrote:
> Hi Resteasy folks,
>
> I've been trying to get my app (which currently runs on jboss 7.1)
> working on WIldfly 8 CR1 flush out any issues before Wildfly 8 Final is
> released.
>
> I hit a problem that I believe to be caused by how resteasy-cdi behaves
> in a CDI 1.1 environment.
>
> My app uses a third-party jax-rs library for using Gson to serialize
> json.  One of the @Providers in this library is a final class:
> http://grepcode.com/file/repo1.maven.org/maven2/net.derquinse/derquinse-common-jaxrs/1.0.34/net/derquinse/common/jaxrs/ByteSourceBodyWriter.java
>
> After switching to Wildfly 8, when I attempt to make a jax-rs request to
> my app, the request fails with a UnproxyableResolutionException (full
> stacktrace below [1]), because Weld can't create a proxy for
> ByteSourceBodyWriter.  And it's true; this class isn't proxyable, and
> Weld is doing the right thing by complaining about it.
>
> I determined that this error didn't occur in JBoss AS7 because in CDI
> 1.0, there was never a ProcessAnnotatedType event raised for
> ByteSourceBodyWriter.  This class lived in a jar without a beans.xml
> file, so Weld ignored it.  In CDI 1.1, however,
> derquinse-common-jaxrs.jar seems to be treated as an 'implicit' bean
> archive, and though none of its classes are annotated with scope
> annotations (so normally they would not be treated as CDI beans),
> ProcessAnnotatedType events are now raised.  And resteasy-cdi is
>   picking up these events, detecting that the Providers have no scope
> annotations, and adding corresponding annotations (@ApplicationScoped,
> in this case) by wrapping the AnnotatedType. Thus, these classes that
> weren't intended by the author to be CDI beans are now being treated as
> CDI beans.
>
> To be concrete, this log line (and several other similar lines) occur
> for wildfly 8, but not for jboss 7.1:
>
>     12:08:32,904 DEBUG [org.jboss.resteasy.cdi.ResteasyCdiExtension]
>     (MSC service thread 1-11) Discovered CDI bean which is a JAX-RS
>     provider net.derquinse.common.jaxrs.ByteSourceBodyWriter.
>
>
>
> This seems to be going against the intended behavior [2] of resteasy-cdi
> -- it is only supposed to modify @Providers that are definitely CDI
> beans, and leave non-CDI @Providers alone, letting them be managed by
> Resteasy.
>
> I don't know a clean way to fix this.  I think resteasy-cdi needs to
> determine if the AnnotatedType is intended to be a CDI bean, instead of
> assuming that AnnotatedType events are fired only for CDI Beans.
>   Perhaps it can use the type's classloader to determine if it comes
> from a jar with a beans.xml defined in it. (Though to be complete, it
> should also determine the bean-discovey-mode of the beans.xml, if any.
>   This sounds like a lot of work.)
>
> Note 1: for my app, I can get around this problem by using a
> jboss-all.xml file [3], but I think this shouldn't be necessary.
>
> Note 2: i'm pretty sure the derquinse-common-jaxrs jar has no
> scope-annotated class or session beans, so I'm not sure why it's being
> considered as an implicit bean archive.
>
> What are your thoughts?  I can create a jira for you, if you'd like.
>
> Thanks,
> Matt Drees
>
>
>
> [1]
> 6:52:56,233 ERROR [org.cru.redegg.loggedErrors] (pool-11-thread-5)
> error:: java.lang.RuntimeException: Unable to instantiate MessageBodyWriter
> at
> org.jboss.resteasy.spi.ResteasyProviderFactory.registerProvider(ResteasyProviderFactory.java:1383)
> [resteasy-jaxrs-3.0.6.Final.jar:]
> at
> org.jboss.resteasy.spi.ResteasyProviderFactory.registerProvider(ResteasyProviderFactory.java:1310)
> [resteasy-jaxrs-3.0.6.Final.jar:]
> at
> org.jboss.resteasy.spi.ResteasyProviderFactory.registerProvider(ResteasyProviderFactory.java:1232)
> [resteasy-jaxrs-3.0.6.Final.jar:]
> at
> org.jboss.resteasy.spi.ResteasyDeployment.registerProvider(ResteasyDeployment.java:531)
> [resteasy-jaxrs-3.0.6.Final.jar:]
> at
> org.jboss.resteasy.spi.ResteasyDeployment.registration(ResteasyDeployment.java:338)
> [resteasy-jaxrs-3.0.6.Final.jar:]
> at
> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:241)
> [resteasy-jaxrs-3.0.6.Final.jar:]
> at
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112)
> [resteasy-jaxrs-3.0.6.Final.jar:]
> at
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
> [resteasy-jaxrs-3.0.6.Final.jar:]
> at
> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:204)
> [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> at
> io.undertow.servlet.core.ManagedServlet.getServlet(ManagedServlet.java:147)
> [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> at
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
> [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
> [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> at org.cru.redegg.servlet.RedEggFilter.doFilter(RedEggFilter.java:54)
> [red-egg-1-20140114.172822-29.jar:]
> at org.cru.redegg.servlet.RedEggFilter.doFilter(RedEggFilter.java:42)
> [red-egg-1-20140114.172822-29.jar:]
> at
> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56)
> [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> at
> org.ccci.maintenance.MaintenanceServletFilter.doFilter(MaintenanceServletFilter.java:71)
> [maintenance-filter-server-1-20131218.163934-17.jar:]
> at
> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56)
> [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> at org.ccci.servlet.LogoutFilter.doFilter(LogoutFilter.java:52) [classes:]
> at
> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56)
> [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> at
> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
> [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> at
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> at
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> at
> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:70)
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> at
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113)
> [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> at
> io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> at
> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
> [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> at
> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
> [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> at
> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:67)
> [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> at
> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70)
> [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> at
> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> at
> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240)
> [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> at
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
> [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> at
> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
> [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> at
> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
> [undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:164)
> [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> at
> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:654)
> [undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [rt.jar:1.7.0_45]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> Caused by: org.jboss.weld.exceptions.UnproxyableResolutionException:
> WELD-001437: Normal scoped bean class
> net.derquinse.common.jaxrs.ByteSourceBodyWriter is not proxyable because
> the type is final or it contains a final method class
> net.derquinse.common.jaxrs.ByteSourceBodyWriter - <unknown
> javax.enterprise.inject.spi.Bean instance>.
> at
> org.jboss.weld.util.Proxies.getUnproxyableClassException(Proxies.java:229)
> [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> at
> org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:178) [weld-core-impl-2.1.1.Final.jar:2013-12-03
> 09:59]
> at
> org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:140) [weld-core-impl-2.1.1.Final.jar:2013-12-03
> 09:59]
> at
> org.jboss.weld.bean.proxy.ClientProxyProvider.getClientProxy(ClientProxyProvider.java:214)
> [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> at
> org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:727)
> [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> at
> org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:753)
> [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> at
> org.jboss.weld.util.ForwardingBeanManager.getReference(ForwardingBeanManager.java:61)
> [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> at
> org.jboss.weld.bean.builtin.BeanManagerProxy.getReference(BeanManagerProxy.java:80)
> [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
> at
> org.jboss.resteasy.cdi.CdiConstructorInjector.construct(CdiConstructorInjector.java:64)
> [resteasy-cdi-3.0.6.Final.jar:]
> at
> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2175)
> [resteasy-jaxrs-3.0.6.Final.jar:]
> at
> org.jboss.resteasy.spi.ResteasyProviderFactory.addMessageBodyWriter(ResteasyProviderFactory.java:837)
> [resteasy-jaxrs-3.0.6.Final.jar:]
> at
> org.jboss.resteasy.spi.ResteasyProviderFactory.registerProvider(ResteasyProviderFactory.java:1378)
> [resteasy-jaxrs-3.0.6.Final.jar:]
> ... 45 more
>
> [2]
> http://docs.jboss.org/resteasy/docs/3.0.6.Final/userguide/html/CDI.html#d4e2034
> [3]
> https://docs.jboss.org/author/display/WFLY8/CDI+Reference#CDIReference-Suppressingimplicitbeanarchives
>
>
> ------------------------------------------------------------------------------
> WatchGuard Dimension instantly turns raw network data into actionable
> security intelligence. It gives you real-time visual feedback on key
> security issues and trends.  Skip the complicated setup - simply import
> a virtual appliance and go from zero to informed in seconds.
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&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

[Resteasy-developers] resteasy-cdi problem in wildfly 8CR1

[Matt D. <mat...@gm...>]

Hi Resteasy folks,

I've been trying to get my app (which currently runs on jboss 7.1) working
on WIldfly 8 CR1 flush out any issues before Wildfly 8 Final is released.

I hit a problem that I believe to be caused by how resteasy-cdi behaves in
a CDI 1.1 environment.

My app uses a third-party jax-rs library for using Gson to serialize json.
 One of the @Providers in this library is a final class:
http://grepcode.com/file/repo1.maven.org/maven2/net.derquinse/derquinse-common-jaxrs/1.0.34/net/derquinse/common/jaxrs/ByteSourceBodyWriter.java

After switching to Wildfly 8, when I attempt to make a jax-rs request to my
app, the request fails with a UnproxyableResolutionException (full
stacktrace below [1]), because Weld can't create a proxy for
ByteSourceBodyWriter.  And it's true; this class isn't proxyable, and Weld
is doing the right thing by complaining about it.

I determined that this error didn't occur in JBoss AS7 because in CDI 1.0,
there was never a ProcessAnnotatedType event raised for
ByteSourceBodyWriter.  This class lived in a jar without a beans.xml file,
so Weld ignored it.  In CDI 1.1, however, derquinse-common-jaxrs.jar seems
to be treated as an 'implicit' bean archive, and though none of its classes
are annotated with scope annotations (so normally they would not be treated
as CDI beans), ProcessAnnotatedType events are now raised.  And
resteasy-cdi is  picking up these events, detecting that the Providers have
no scope annotations, and adding corresponding annotations
(@ApplicationScoped, in this case) by wrapping the AnnotatedType. Thus,
these classes that weren't intended by the author to be CDI beans are now
being treated as CDI beans.

To be concrete, this log line (and several other similar lines) occur for
wildfly 8, but not for jboss 7.1:

12:08:32,904 DEBUG [org.jboss.resteasy.cdi.ResteasyCdiExtension] (MSC
service thread 1-11) Discovered CDI bean which is a JAX-RS provider
net.derquinse.common.jaxrs.ByteSourceBodyWriter.



This seems to be going against the intended behavior [2] of resteasy-cdi --
it is only supposed to modify @Providers that are definitely CDI beans, and
leave non-CDI @Providers alone, letting them be managed by Resteasy.

I don't know a clean way to fix this.  I think resteasy-cdi needs to
determine if the AnnotatedType is intended to be a CDI bean, instead of
assuming that AnnotatedType events are fired only for CDI Beans.  Perhaps
it can use the type's classloader to determine if it comes from a jar with
a beans.xml defined in it. (Though to be complete, it should also determine
the bean-discovey-mode of the beans.xml, if any.  This sounds like a lot of
work.)

Note 1: for my app, I can get around this problem by using a jboss-all.xml
file [3], but I think this shouldn't be necessary.

Note 2: i'm pretty sure the derquinse-common-jaxrs jar has no
scope-annotated class or session beans, so I'm not sure why it's being
considered as an implicit bean archive.

What are your thoughts?  I can create a jira for you, if you'd like.

Thanks,
Matt Drees



[1]
6:52:56,233 ERROR [org.cru.redegg.loggedErrors] (pool-11-thread-5) error::
java.lang.RuntimeException: Unable to instantiate MessageBodyWriter
at
org.jboss.resteasy.spi.ResteasyProviderFactory.registerProvider(ResteasyProviderFactory.java:1383)
[resteasy-jaxrs-3.0.6.Final.jar:]
at
org.jboss.resteasy.spi.ResteasyProviderFactory.registerProvider(ResteasyProviderFactory.java:1310)
[resteasy-jaxrs-3.0.6.Final.jar:]
at
org.jboss.resteasy.spi.ResteasyProviderFactory.registerProvider(ResteasyProviderFactory.java:1232)
[resteasy-jaxrs-3.0.6.Final.jar:]
at
org.jboss.resteasy.spi.ResteasyDeployment.registerProvider(ResteasyDeployment.java:531)
[resteasy-jaxrs-3.0.6.Final.jar:]
at
org.jboss.resteasy.spi.ResteasyDeployment.registration(ResteasyDeployment.java:338)
[resteasy-jaxrs-3.0.6.Final.jar:]
at
org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:241)
[resteasy-jaxrs-3.0.6.Final.jar:]
at
org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112)
[resteasy-jaxrs-3.0.6.Final.jar:]
at
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
[resteasy-jaxrs-3.0.6.Final.jar:]
at
io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:204)
[undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
at
io.undertow.servlet.core.ManagedServlet.getServlet(ManagedServlet.java:147)
[undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
at
io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
[undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
at
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
[undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
at org.cru.redegg.servlet.RedEggFilter.doFilter(RedEggFilter.java:54)
[red-egg-1-20140114.172822-29.jar:]
at org.cru.redegg.servlet.RedEggFilter.doFilter(RedEggFilter.java:42)
[red-egg-1-20140114.172822-29.jar:]
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56)
[undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
at
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
[undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
at
org.ccci.maintenance.MaintenanceServletFilter.doFilter(MaintenanceServletFilter.java:71)
[maintenance-filter-server-1-20131218.163934-17.jar:]
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56)
[undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
at
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
[undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
at org.ccci.servlet.LogoutFilter.doFilter(LogoutFilter.java:52) [classes:]
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56)
[undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
at
io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
[undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
at
io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
[undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
at
io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
[undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
at
io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
[undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
at
org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:70)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
[undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
at
io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113)
[undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
at
io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
[undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
at
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
[undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
at
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
[undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
at
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:67)
[undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
at
io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70)
[undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
[undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
at
org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
[undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
[undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
at
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240)
[undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
at
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
[undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
at
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
[undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
at
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
[undertow-servlet-1.0.0.Beta30.jar:1.0.0.Beta30]
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:164)
[undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:654)
[undertow-core-1.0.0.Beta30.jar:1.0.0.Beta30]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[rt.jar:1.7.0_45]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[rt.jar:1.7.0_45]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
Caused by: org.jboss.weld.exceptions.UnproxyableResolutionException:
WELD-001437: Normal scoped bean class
net.derquinse.common.jaxrs.ByteSourceBodyWriter is not proxyable because
the type is final or it contains a final method class
net.derquinse.common.jaxrs.ByteSourceBodyWriter - <unknown
javax.enterprise.inject.spi.Bean instance>.
at
org.jboss.weld.util.Proxies.getUnproxyableClassException(Proxies.java:229)
[weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
at
org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:178)
[weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
at
org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:140)
[weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
at
org.jboss.weld.bean.proxy.ClientProxyProvider.getClientProxy(ClientProxyProvider.java:214)
[weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
at
org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:727)
[weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
at
org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:753)
[weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
at
org.jboss.weld.util.ForwardingBeanManager.getReference(ForwardingBeanManager.java:61)
[weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
at
org.jboss.weld.bean.builtin.BeanManagerProxy.getReference(BeanManagerProxy.java:80)
[weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59]
at
org.jboss.resteasy.cdi.CdiConstructorInjector.construct(CdiConstructorInjector.java:64)
[resteasy-cdi-3.0.6.Final.jar:]
at
org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2175)
[resteasy-jaxrs-3.0.6.Final.jar:]
at
org.jboss.resteasy.spi.ResteasyProviderFactory.addMessageBodyWriter(ResteasyProviderFactory.java:837)
[resteasy-jaxrs-3.0.6.Final.jar:]
at
org.jboss.resteasy.spi.ResteasyProviderFactory.registerProvider(ResteasyProviderFactory.java:1378)
[resteasy-jaxrs-3.0.6.Final.jar:]
... 45 more

[2]
http://docs.jboss.org/resteasy/docs/3.0.6.Final/userguide/html/CDI.html#d4e2034
[3]
https://docs.jboss.org/author/display/WFLY8/CDI+Reference#CDIReference-Suppressingimplicitbeanarchives

Re: [Resteasy-developers] Keycloak SSO Alpha 1 Released

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

On 1/28/2014 6:52 AM, Adrian Mitev wrote:
> In previous projects I had a requirement for fine-grained security
> control where the a specific permissions were allowed for a given role.
> Each permission corresponded to a functionality or an action that the
> user could perform.
>

Is it ok for roles/permissions to be the same thing as I expressed?  Or 
do you need a separation?

keycloak.org/docs

> Another usefull functionalities for a SSO server:
> * ability for the users to login using digital certificates (smart cards)

On the roamap for 1.0.

> * easy customization of the login page without having to rebuild the
> entire application (probably by externalizing it outside the war file)

Style sheet plugin is in the works and may even be in the next release.

> * i18n of the ui

On the roadmap

> * Account locking
> * Account disabling by administrator
>

Account management is already available.

> BTW will the functionality be based on PicketLink?
>

Maybe.  We might use it to federate LDAP/AD.  We're using an extension 
hybrid of OAuth2/JWT/JSE right now with plans to fully support OpenID 
connect.

If you want to help drive requirements, ping us on the keycloak-dev list.

Bill

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

Re: [Resteasy-developers] Keycloak SSO Alpha 1 Released

[Adrian M. <adr...@gm...>]

In previous projects I had a requirement for fine-grained security control
where the a specific permissions were allowed for a given role. Each
permission corresponded to a functionality or an action that the user could
perform.

Another usefull functionalities for a SSO server:
* ability for the users to login using digital certificates (smart cards)
* easy customization of the login page without having to rebuild the entire
application (probably by externalizing it outside the war file)
* i18n of the ui
* Account locking
* Account disabling by administrator

BTW will the functionality be based on PicketLink?


On Sun, Jan 26, 2014 at 4:46 PM, Bill Burke <bb...@re...> wrote:

> So far the idea is roles and permissions are the same thing.  What we're
> planning to add is the idea of a "composite role".  A composite is a
> role that can be made up of other roles.  Its can by mapped to a user
> and the user will dynamically inherit the fine-grain roles that are
> contained in the "composite role".
>
> Does that make sense?
>
> BTW, we should take this to the keycloak list eventually if we discuss
> more.
>
> On 1/25/2014 1:12 PM, Adrian Mitev wrote:
> > Hi! Do you plan to support permission management where apps provide a
> > set of permissions and the administrator defines a specific permissions
> > for a give role(s)?
> >
> >
> > On Thu, Jan 23, 2014 at 8:23 PM, Bill Burke <bb...@re...
> > <mailto:bb...@re...>> wrote:
> >
> >     Keycloak is an SSO auth server and appliance for web applications and
> >     RESTful web services.  It can act as a Social Broker for Social Login
> >     via Google, Twitter, and Facebook.  It has a nice admin console UI
> for
> >     managing a variety of security metadata and much much more...
> >
> >     Please view my blog for more details on features, videos, downloads,
> and
> >     documentation:
> >
> >
> http://bill.burkecentral.com/2014/01/23/keycloak-sso-released-alpha-1/
> >
> >     --
> >     Bill Burke
> >     JBoss, a division of Red Hat
> >     http://bill.burkecentral.com
> >
> >
> ------------------------------------------------------------------------------
> >     CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> >     Learn Why More Businesses Are Choosing CenturyLink Cloud For
> >     Critical Workloads, Development Environments & Everything In Between.
> >     Get a Quote or Start a Free Trial Today.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> >     _______________________________________________
> >     Resteasy-developers mailing list
> >     Res...@li...
> >     <mailto:Res...@li...>
> >     https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> > Learn Why More Businesses Are Choosing CenturyLink Cloud For
> > Critical Workloads, Development Environments & Everything In Between.
> > Get a Quote or Start a Free Trial Today.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&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
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>

Re: [Resteasy-developers] Keycloak SSO Alpha 1 Released

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

So far the idea is roles and permissions are the same thing.  What we're 
planning to add is the idea of a "composite role".  A composite is a 
role that can be made up of other roles.  Its can by mapped to a user 
and the user will dynamically inherit the fine-grain roles that are 
contained in the "composite role".

Does that make sense?

BTW, we should take this to the keycloak list eventually if we discuss more.

On 1/25/2014 1:12 PM, Adrian Mitev wrote:
> Hi! Do you plan to support permission management where apps provide a
> set of permissions and the administrator defines a specific permissions
> for a give role(s)?
>
>
> On Thu, Jan 23, 2014 at 8:23 PM, Bill Burke <bb...@re...
> <mailto:bb...@re...>> wrote:
>
>     Keycloak is an SSO auth server and appliance for web applications and
>     RESTful web services.  It can act as a Social Broker for Social Login
>     via Google, Twitter, and Facebook.  It has a nice admin console UI for
>     managing a variety of security metadata and much much more...
>
>     Please view my blog for more details on features, videos, downloads, and
>     documentation:
>
>     http://bill.burkecentral.com/2014/01/23/keycloak-sso-released-alpha-1/
>
>     --
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>
>     ------------------------------------------------------------------------------
>     CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>     Learn Why More Businesses Are Choosing CenturyLink Cloud For
>     Critical Workloads, Development Environments & Everything In Between.
>     Get a Quote or Start a Free Trial Today.
>     http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>     _______________________________________________
>     Resteasy-developers mailing list
>     Res...@li...
>     <mailto:Res...@li...>
>     https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>
>
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&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

Re: [Resteasy-developers] Keycloak SSO Alpha 1 Released

[Adrian M. <adr...@gm...>]

Hi! Do you plan to support permission management where apps provide a set
of permissions and the administrator defines a specific permissions for a
give role(s)?


On Thu, Jan 23, 2014 at 8:23 PM, Bill Burke <bb...@re...> wrote:

> Keycloak is an SSO auth server and appliance for web applications and
> RESTful web services.  It can act as a Social Broker for Social Login
> via Google, Twitter, and Facebook.  It has a nice admin console UI for
> managing a variety of security metadata and much much more...
>
> Please view my blog for more details on features, videos, downloads, and
> documentation:
>
> http://bill.burkecentral.com/2014/01/23/keycloak-sso-released-alpha-1/
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>

[Resteasy-developers] Keycloak SSO Alpha 1 Released

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

Keycloak is an SSO auth server and appliance for web applications and 
RESTful web services.  It can act as a Social Broker for Social Login 
via Google, Twitter, and Facebook.  It has a nice admin console UI for 
managing a variety of security metadata and much much more...

Please view my blog for more details on features, videos, downloads, and 
documentation:

http://bill.burkecentral.com/2014/01/23/keycloak-sso-released-alpha-1/

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