11:32 p.m.
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...
Maybe Stefan from our side can help out. I would guess we can produce a
prototype branch with undertow + PBox5.
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.
11:40 p.m.
On 11/13/2012 04:32 PM, 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.
In a word: why?
What does PicketBox provide that Undertow needs? I'd be highly
skeptical unless it's clear what requirements were fed *into* PicketBox
to begin with. We know what we need; the burden of justification lies
on you in this case.
The test cases that you may want to review:
https://github.com/picketbox/picketbox/tree/master/http/src/test/java/org...
Maybe Stefan from our side can help out. I would guess we can produce a
prototype branch with undertow + PBox5.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
--
- DML
12:29 a.m.
What are the security requirements of Undertow?
That would help Anil explain if Picketbox fits in or not.
On 13/11/2012 23:40, David M. Lloyd wrote:
On 11/13/2012 04:32 PM, 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.
In a word: why?
What does PicketBox provide that Undertow needs? I'd be highly
skeptical unless it's clear what requirements were fed *into* PicketBox
to begin with. We know what we need; the burden of justification lies
on you in this case.
> The test cases that you may want to review:
>
https://github.com/picketbox/picketbox/tree/master/http/src/test/java/org...
>
> Maybe Stefan from our side can help out. I would guess we can produce a
> prototype branch with undertow + PBox5.
>
> 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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Dimitris Andreadis
Software Engineering Manager
JBoss Application Server
by Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
http://dandreadis.blogspot.com/
12:44 a.m.
On 11/13/2012 04:40 PM, David M. Lloyd wrote:
On 11/13/2012 04:32 PM, 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.
In a word: why?
What does PicketBox provide that Undertow needs? I'd be highly
skeptical unless it's clear what requirements were fed *into* PicketBox
to begin with. We know what we need; the burden of justification lies
on you in this case.
At a bare minimum from Undertow perspective, PicketBox5 has
implemented
the Servlet security mechanisms in a container independent fashion .
You can take a look at that. If Undertow needs to implement servlet
security mechanism, we can provide you a PBox5 tiny library to
integrate into undertow or you will have to code it yourself, unless you
have already done that. :)
> The test cases that you may want to review:
>
https://github.com/picketbox/picketbox/tree/master/http/src/test/java/org...
>
> Maybe Stefan from our side can help out. I would guess we can produce a
> prototype branch with undertow + PBox5.
>
> 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.
>
1 a.m.
On 11/13/2012 05:44 PM, Anil Saldhana wrote:
On 11/13/2012 04:40 PM, David M. Lloyd wrote:
> On 11/13/2012 04:32 PM, 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.
> In a word: why?
>
> What does PicketBox provide that Undertow needs? I'd be highly
> skeptical unless it's clear what requirements were fed *into* PicketBox
> to begin with. We know what we need; the burden of justification lies
> on you in this case.
At a bare minimum from Undertow perspective, PicketBox5 has implemented
the Servlet security mechanisms in a container independent fashion .
You can take a look at that. If Undertow needs to implement servlet
security mechanism, we can provide you a PBox5 tiny library to
integrate into undertow or you will have to code it yourself, unless you
have already done that. :)
There is one use case that Mike Brock had mentioned a
month back that we
want to validate with PBox5.
The issue on non-http session management for calls coming in from
different paths (web sockets, http etc)
and provide step-up/step-down authentication/authorization. I need to
check with Mike on this from Errai perspective. :)
>> The test cases that you may want to review:
>>
https://github.com/picketbox/picketbox/tree/master/http/src/test/java/org...
>>
>> Maybe Stefan from our side can help out. I would guess we can produce a
>> prototype branch with undertow + PBox5.
We are willing to do the prototype
for you and you can tell us you like
it or not. :)
>> 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.
>>
>>
7:49 a.m.
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...
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
1:06 p.m.
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.
- 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.
- 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.
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.
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...
>
> 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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
4:38 p.m.
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...
- 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. :)
- 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...
>>
>> 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.
5:28 p.m.
On Nov 14, 2012, at 9:38 AM, Anil Saldhana <Anil.Saldhana(a)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...
> - 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...
>>>
>>> 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
5:40 p.m.
On 11/14/2012 10:28 AM, Jason Greene wrote:
On Nov 14, 2012, at 9:38 AM, Anil Saldhana
<Anil.Saldhana(a)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...
>
>> - 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...
>>>>
>>>> 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.
>>>>
11:33 p.m.
On Nov 14, 2012, at 10:40 AM, Anil Saldhana <Anil.Saldhana(a)redhat.com> wrote:
On 11/14/2012 10:28 AM, Jason Greene wrote:
>>
> 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? ;)
Here you go:
https://docs.google.com/document/pub?id=15kEFSBAaHp8maIoecj5FzYKAVoUD6nEo...
5:03 p.m.
Jason,
thank you for the document.
a) What tool did you use for the document? Docbook? I want to create
similar requirements documents. :)
b) Can you add the following under session management? I am seeing this
a lot from the field (I heard it 5 mins ago). It is also the same that
Mike Brock had mentioned.
"Session management will not solely be tied to HTTPSession. A generic
session management strategy will be employed"
Please reword it as necessary.
On 11/14/2012 04:33 PM, Jason Greene wrote:
On Nov 14, 2012, at 10:40 AM, Anil Saldhana
<Anil.Saldhana(a)redhat.com> wrote:
> On 11/14/2012 10:28 AM, Jason Greene wrote:
>> 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? ;)
Here you go:
https://docs.google.com/document/pub?id=15kEFSBAaHp8maIoecj5FzYKAVoUD6nEo...
5:11 p.m.
On Nov 15, 2012, at 10:03 AM, Anil Saldhana <Anil.Saldhana(a)redhat.com> wrote:
Jason,
thank you for the document.
a) What tool did you use for the document? Docbook? I want to create similar
requirements documents. :)
David created it from a group ether pad we did awhile back. I'm not sure what he used.
b) Can you add the following under session management? I am seeing
this a lot from the field (I heard it 5 mins ago). It is also the same that Mike Brock had
mentioned.
"Session management will not solely be tied to HTTPSession. A generic session
management strategy will be employed"
Ah yes, I completely agree with this one.
Please reword it as necessary.
On 11/14/2012 04:33 PM, Jason Greene wrote:
> On Nov 14, 2012, at 10:40 AM, Anil Saldhana <Anil.Saldhana(a)redhat.com> wrote:
>
>> On 11/14/2012 10:28 AM, Jason Greene wrote:
>>> 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? ;)
>
> Here you go:
>
> https://docs.google.com/document/pub?id=15kEFSBAaHp8maIoecj5FzYKAVoUD6nEo...
>
>
5:28 p.m.
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...
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...
>>>
>>> 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(a)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)
5:30 p.m.
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...
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...
>>>
>>> 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
1:08 a.m.
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...
> - 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...
>>>
>>>
>>> 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
12:05 a.m.
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...
>
>
>
>> - 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...
>>>>
>>>>
>>>>
>>>> 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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
3:43 a.m.
>>>>>
>>>>> 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.
Ok, hopefully we will have something this week.
So far we are passing the JSF and JSTL TCK tests, with only ~70 tests in
total to go between servlet and JSP, mostly security related, so this is
a high priority for me.
Stuart
>>>> 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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
4:34 p.m.
On 11/26/2012 08:43 PM, Stuart Douglas wrote:
>>>>>> 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.
Ok, hopefully we will have something this week.
So far we are passing the JSF and JSTL TCK tests, with only ~70 tests in
total to go between servlet and JSP, mostly security related, so this is
a high priority for me.
Stuart
Stuart - fyi - here is the requirements document for PicketBox5.
(https://docs.jboss.org/author/display/SECURITY/PicketBox+Requirements+Doc...).
The big items for us are multiple authentication schemes, general
session management, step-up/down security, logout and events. I will
request Stefan to be available for any consultation/help with Undertow
security.
>>>>> 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.
>>>>>>
4167
days inactive
4181
days old
18 comments
7 participants
participants (7)
-
Anil Saldhana -
Darran Lofthouse -
Darran Lofthouse -
David M. Lloyd -
Dimitris Andreadis -
Jason Greene -
Stuart Douglas