[undertow-dev] Undertow Security: PicketBox5

[Darran Lofthouse]

On 11/14/2012 03:38 PM, Anil Saldhana 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.

It is not just the tests it is the actual implementations assuming that 
there is a servlet container - the other problem is that the HTTP Digest 
implementation is mandating the presence of an underlying session.

> 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

The test case that would be of greatest interest to me based on your 
supported mechanisms would be one that demonstrates how Digest and 
Client Cert authentication can be paired together for the same secured 
resource.

>>     - 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. :) :)

Actually this is exactly a case where focussing on what can not be done 
is important.

We keep falling into the same trap of implementing the simplest 
scenarios first and then finding it difficult to add additional 
capabilities as our whole architecture is justified based on the simple 
exchanges.

An example is the JBoss Negotiation project which is now about 95% 
working around these architectures we have selected and 5% about 
enabling SPNEGO - in Undertow this mechanism has been implemented with a 
fraction of the complexity.

> 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.

Based on what you are showing here I would suggest two areas to focus on 
for HTTP Digest authentication to prove it can be completed: -
  - Full support for RFC2617 including different strategies for nonce 
handling most notably full support for the nonce count attribute, 
MD5-sess and a valid stale attribute in the challenges.
  - Implementing the qop of auth-int - there is more than just sending a 
challenge if we don't have an authenticated user we still have headers 
that need to be sent if there is an authenticated user.

> 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 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. ;)

Do you have more information about the capabilities, not only do we need 
the option to add additional authentication mechanisms we need the 
ability to combine them together to be a central aspect of this.

>> 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.

Those are the same use cases that we extracted from various discussions 
and fed into the requirements documents that we are working to for 
Undertow.  As our SPI for authentication mechanisms stabilises Bill is 
the first person I am planning to take it to to discuss in more detail.

>> 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
>

-- 
Darran Lofthouse - Principal Software Engineer

Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (USA), Mark Hegarty (Ireland), Matt Parson
(USA), Charlie Peters (USA)