[undertow-dev] Undertow Security: PicketBox5

[Jason Greene]

On Nov 14, 2012, at 9:38 AM, Anil Saldhana <Anil.Saldhana at redhat.com> wrote:

> I just want to convey that I am not trying to shove PicketBox into 
> Undertow. Comments inline.
> 
> On 11/14/2012 06:06 AM, Darran Lofthouse wrote:
>> Within Undertow we already have an authentication framework coming
>> together based on the requirements identified for the project - at this
>> stage we support SPNEGO, HTTP Basic with HTTP Digest now being close to
>> completion - with HTTP Digest we are supporting all capabilities from
>> RFC2069, RFC2617 and RFC5843.
>> 
>> A couple of comments from a very quick review of the mechanisms you have
>> within PicketBox: -
>>   - The implementation assumes that it is running within a servlet
>> container, Undertow is a highly performant HTTP server that may or may
>> not contain a servlet container.
> The tests I showed you were for servlet security implementation. Those
> definitely require the presence of a servlet container.
> 
> We did implement a generic authentication scheme whose tests are here:
> https://github.com/picketbox/picketbox/tree/master/core/src/test/java/org/picketbox/test/authentication
> 
>>   - Today HTTP Digest is one of the most complex mechanisms out there,
>> to me this is almost the definitive mechanism - prove we can support all
>> capabilities in all three RFCs and we are in a good position for
>> mechanisms not even in existence to be usable with undertow.
>> Unfortunately the PicketBox version does still seem to be tied to
>> RFC2069 with an assumption it is in a servlet container - even then some
>> of the basic RFC2069 capabilities are not implemented.
> Don't always focus on what an implementation cannot do to justify 
> cooking it yourself. :) :)

I don't see anyone justifying, its just a comparison of what is there now and how and if picket box fits in. I don't think anyone cares about who does the cooking, only that the order comes back correct and in a reasonable time frame :)

> What we did with HTTP/Digest is put in an implementation that is on par 
> with what Tomcat and Jetty provided
> and looking for feedback from people to proceed.
> 
> We aim PicketBox5 to work with all web containers and in a JavaSE 
> environment because it is a generic security framework.
> So we should be fine even if Undertow internal architecture does not 
> include it. I am just exploring if there is
> possibility of PicketBox5 making into Undertow, to save you guys coding 
> time. :)

The more contributors the merrier. ;) 

> 
>>   - The second key feature that will prove the approach is correct is
>> the use of multiple mechanisms concurrently, presently Undertow works
>> with SPNEGO combined with either Basic or Digest authentication - once
>> complete it will work with this pair plus Client Cert AND FORM
>> authentication - we should even have the capability to implement a
>> custom FORM implementation with some of the DIGEST capabilities.
> This is not rocket science. This could have been achieved previously 
> with custom tomcat authenticators.
> But Tomcat is not the subject of discussion here.  I understand the 
> intent of combined authentication schemes.
> We did make an attempt at an combined generic authentication scheme in 
> PicketBox5. But don't shoot it down
> without even looking at it. ;)
> 
>> Longer term I also believe we need the set of mechanisms to live
>> together and potentially co-located with the SASL mechanisms as there is
>> a potential to share between these.
> Also I suggest getting Bill Burke involved in discussions because he has 
> a lot of use cases from RESTEasy
> security perspective that he was greatly hampered by the Tomcat 
> architecture. I am sure he will bring in some
> use cases that Undertow security may benefit.

He was involved with building the requirements doc. Have you gotten a copy of that?

>> 
>> Regards,
>> Darran Lofthouse.
>> 
>> 
>> 
>> 
>> On 11/14/2012 06:49 AM, Stuart Douglas wrote:
>>> 
>>> Anil Saldhana wrote:
>>>> Hi All,
>>>>      I was not aware of this mailing list until today.
>>>> 
>>>> 3-4 months ago, we rewrote PicketBox5 to be a generic security framework.
>>>> https://docs.jboss.org/author/display/SECURITY/Java+Application+Security
>>>> https://github.com/picketbox/picketbox
>>>> 
>>>> We neither have JAAS stuff nor Servlet Security
>>>> (FORM,DIGEST,CLIENT-CERT,BASIC) tied to Tomcat Authenticators.
>>>> I am wondering if there is a scope for using PicketBox5 with Undertow.
>>>> Also there is no tie in into any containers in
>>>> PicketBox5.
>>>> 
>>>> The test cases that you may want to review:
>>>> https://github.com/picketbox/picketbox/tree/master/http/src/test/java/org/picketbox/test/authentication/http
>>>> 
>>>> Maybe Stefan from our side can help out.  I would guess we can produce a
>>>> prototype branch with undertow + PBox5.
>>> I have had a look through this today, and the big problem with using
>>> this for Undertow is that it is based on the Servlet API's. We want to
>>> be able to use Undertow as the domain HTTP server as well, and we really
>>> need to be able to re-use the security without adding a servlet
>>> dependency into the AS core.
>>> 
>>> I will go through this more fully tomorrow, as I am still recovering
>>> from my 24 hour flight, but it looks like there are also other things
>>> that this may not support such as multiple authentication mechanisms and
>>> optional authentication.
>>> 
>>> I'm not ruling out using PicketBox, however at this stage I think that
>>> the best approach is probably to have the HTTP authentication mechanisms
>>> in Undertow, where they can make use of the async IO features as much as
>>> possible, and just provide a very simple SPI that we can then back with
>>> PicketBox in order to keep Undertow core free of external dependencies.
>>> 
>>> Stuart
>>> 
>>>> Regards,
>>>> Anil
>>>> 
>>>> PS: Feedback from *Jason Greene*: I'll let Stuart and Darran comment,
>>>> but my thinking is that we want to greatly limit the dependencies of
>>>> standalone undertow. Integration in AS is a different story though. I
>>>> would imagine this means some kind of SPI between undertow and the
>>>> container.
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev