[undertow-dev] Undertow Security: PicketBox5

[Anil Saldhana]

On 11/14/2012 10:28 AM, Jason Greene wrote:
> 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?
Jason, if that doc is not marked "Top Secret", may be this list can get 
it? ;)
>
>>> 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.
>>>>>