[undertow-dev] Undertow Security: PicketBox5

Anil Saldhana Anil.Saldhana at redhat.com
Mon Nov 26 18:05:41 EST 2012


On 11/15/2012 06:08 PM, Stuart Douglas wrote:
>
>
> 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.
>>
>> 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. :) :)
>> 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. :)
>
>  From what I have seen it looks like the best approach at the moment 
> will be to keep the actual authentication mechanisms in Undertow, 
> while delegating everything else to PicketLink/PicketBox via a SPI. 
> This way we have all the HTTP specific stuff in Undertow.
>
> There are a number of problems with just using a servlet based 
> solution, the main one being that this limits us to servlet use cases, 
> so we would have to re-implement this anyway to support the domain 
> http server.
>
> Even for our servlet implementation using filters is not ideal. At the 
> moment we have a mode where if no filters are configured static 
> resources can be served directly from memory using non-blocking IO, 
> without ever delegating to a thread pool. If we had to add a blanket 
> security filter then this would no longer be possible.
>
> The undertow architecture also gives us quite a lot of flexibility in 
> terms of how this is all implemented, a lot of which we loose if we go 
> to a pure servlet based approach. For example using pure Undertow 
> handlers you could potentially apply a blanket authentication scheme 
> to the whole server, which is not really possible with a pure servlet 
> implementation.
>
> Another advantage of pure Undertow handlers is that they give you more 
> flexibility in controlling how the request is actually written out.
>
> For example with RFC2617 integrity protection the Authentication-Info 
> header may need to be placed after the end of a HTTP request in the 
> trailing headers section, if chunked encoding is being used. 
> Unfortunately the serlvet API does not really have any way of setting 
> trailing headers, so the only way to implement this is to buffer the 
> whole response and then calculate the hash used in Authentication-Info.
>
>
> Stuart
>
>>
>>> - 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.
>>> 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.
>>>>
Let us try this approach. We will keep an eye out for the SPI.
>>>> 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



More information about the undertow-dev mailing list