You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Blevins <da...@visi.com> on 2005/07/08 04:51:22 UTC
Re: ActiveIO (was: Donation of a CORBA Orb)
On Thu, Jul 07, 2005 at 12:16:19PM -0400, Davanum Srinivas wrote:
> Hiram,
>
> Could you please make sure that the project gets worked on here at
> Apache? Am a bit concerned about code getting forked out and then
> becoming geronimo becoming a dependency on an external project.
There's the "f" word again :)
Hiram, you can correct me if I'm wrong, but thought the ActiveIO code
was created from the ActiveMQ transport system?
We had several conversations over a period of months on just using the
ActiveMQ transports in OpenEJB and Geronimo so there would be
something common to cut-down on duplicating efforts. We didn't use
any Geronimo IO code cause it, well... sucked :)
Even then, I think you pretty much rewrote everything.
Is my memory of history accurate or have I demented myself?
-David
Re: ActiveIO
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
David Blevins wrote, On 7/8/2005 3:01 PM:
>On Fri, Jul 08, 2005 at 11:39:31AM -0700, Alan D. Cabrera wrote:
>
>
>>David Blevins wrote, On 7/7/2005 7:51 PM:
>>
>>
>>
>>>We had several conversations over a period of months on just using the
>>>ActiveMQ transports in OpenEJB and Geronimo so there would be
>>>something common to cut-down on duplicating efforts. We didn't use
>>>any Geronimo IO code cause it, well... sucked :)
>>>
>>>
>>>
>>>
>>Eh? I wouldn't characterize it as sucky code. I would say that it was
>>sleep deprived...
>>
>>
>
>Sorry, Alan :) How about this:
>
> It was raw potential, greatness in the making and a few sleep
> statements shy from sheer perfection.
>
>/me climbs under a rock and hides
>
ROTFL!
/me cleans the coffee spewed on keyboard...
Regards,
Alan
Re: ActiveIO
Posted by David Blevins <da...@visi.com>.
On Fri, Jul 08, 2005 at 11:39:31AM -0700, Alan D. Cabrera wrote:
> David Blevins wrote, On 7/7/2005 7:51 PM:
>
> >We had several conversations over a period of months on just using the
> >ActiveMQ transports in OpenEJB and Geronimo so there would be
> >something common to cut-down on duplicating efforts. We didn't use
> >any Geronimo IO code cause it, well... sucked :)
> >
> >
> Eh? I wouldn't characterize it as sucky code. I would say that it was
> sleep deprived...
Sorry, Alan :) How about this:
It was raw potential, greatness in the making and a few sleep
statements shy from sheer perfection.
/me climbs under a rock and hides
-David
Re: ActiveIO
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
David Blevins wrote, On 7/7/2005 7:51 PM:
>We had several conversations over a period of months on just using the
>ActiveMQ transports in OpenEJB and Geronimo so there would be
>something common to cut-down on duplicating efforts. We didn't use
>any Geronimo IO code cause it, well... sucked :)
>
>
Eh? I wouldn't characterize it as sucky code. I would say that it was
sleep deprived...
Regards,
Alan
Re: ActiveIO
Posted by Andy Piper <an...@bea.com>.
At 11:41 AM 7/12/2005, David Jencks wrote:
>>If an application does a JAAS-based certificate login, then the private
>>credentials thus stored in the current subject should be used to do the
>>client-side of an client authentication on a successive remote corba SSL
>>call. Thus making the client system identity identical to the logged in
>>user.
>
>While I like the idea of allowing this as an option, my understanding is
>this is not csiv2 compliant: I think this is what the ITTX509CertChain is
>for. Please correct me if I'm wrong.
One of the problems with CSIv2 is that no-one has defined what it means in
relation to J2EE client security. The only mandated things are those
described in the EJB 2.x spec and those are server-server only and give
vendors a great deal of leeway. We have ongoing customer expectation issues
with secure interop between WAS and WLS - both of which are CTS compliant -
because of different interpretations of the spec.
The use of X509 cert chains in SSL handshake and the SAS protocol are
somewhat orthogonal issues. Its perfectly possible to establish trust at
the SSL level using one set of certs and assert identity at the SAS level
using another. The CSIv2 spec supports both and I don't think it is illegal
to do either. The spec does say that the SAS protocol support is to
potentially overcome limitations at the transport level.
So I suspect you could do either and still be CTS compliant. I would say
that using certs to establish identity in the SSL handshake has been used
by appserver vendors for a very long time and is therefore likely to be
supported by more appservers than at the SAS protocol level. WLS for
instance supports inbound certs via ITTX509CertChain but does not currently
provide a client mechanism instead relying on SSL.
HTH
andy
Re: ActiveIO
Posted by David Jencks <dj...@gluecode.com>.
On Jul 12, 2005, at 11:27 AM, Kresten Krab Thorup wrote:
>> David Jencks wrote:
>>
>> On Jul 12, 2005, at 1:14 AM, Kresten Krab Thorup wrote:
>>
>>> For client sockets, things are slightly more complicated because we
>>> need to support that the user is authenticated with an X509
>>> certificate. In this case, the credentials of the user (which would
>>> typically be sitting inside the current Subject) needs to be passed
>>> along to the socket creation so that the SSL logic can create an
>>> X509KeyManager that can service this information to the server if he
>>> needs it to establish the clients credentials.
>>>
>>
>> Is this correct? Or one possibility we should support? My
>> understanding is that normally in csiv2 the ssl layer client
>> authentication authenticates the client system itself, whereas the
>> user's identity is transferred in an SAS identity token. If the
>> client
>> system is a standalone client rather than a server, the client system
>> identity would presumably be the same as the user identity. Have I
>> missed something?
>>
>
> Here is the example I'm thinking of:
>
> If an application does a JAAS-based certificate login, then the private
> credentials thus stored in the current subject should be used to do the
> client-side of an client authentication on a successive remote corba
> SSL
> call. Thus making the client system identity identical to the logged
> in
> user.
While I like the idea of allowing this as an option, my understanding
is this is not csiv2 compliant: I think this is what the
ITTX509CertChain is for. Please correct me if I'm wrong.
david jencks
>
> Kresten
>
Re: ActiveIO
Posted by Kresten Krab Thorup <kr...@trifork.com>.
> David Jencks wrote:
>
> On Jul 12, 2005, at 1:14 AM, Kresten Krab Thorup wrote:
>
>> For client sockets, things are slightly more complicated because we
>> need to support that the user is authenticated with an X509
>> certificate. In this case, the credentials of the user (which would
>> typically be sitting inside the current Subject) needs to be passed
>> along to the socket creation so that the SSL logic can create an
>> X509KeyManager that can service this information to the server if he
>> needs it to establish the clients credentials.
>>
>
> Is this correct? Or one possibility we should support? My
> understanding is that normally in csiv2 the ssl layer client
> authentication authenticates the client system itself, whereas the
> user's identity is transferred in an SAS identity token. If the client
> system is a standalone client rather than a server, the client system
> identity would presumably be the same as the user identity. Have I
> missed something?
>
Here is the example I'm thinking of:
If an application does a JAAS-based certificate login, then the private
credentials thus stored in the current subject should be used to do the
client-side of an client authentication on a successive remote corba SSL
call. Thus making the client system identity identical to the logged in
user.
Kresten
Re: ActiveIO
Posted by David Jencks <da...@yahoo.com>.
On Jul 12, 2005, at 1:14 AM, Kresten Krab Thorup wrote:
> Here are some notes on SSL configuration from IIOP/CSIv2 point of
> view. This is not API, just what a such API need to do. The Trifork
> ORB (note: Trifork is with just one capital letter) includes some code
> to do this, but it would make sense to integrate this into ActiveIO to
> make it more widely applicable.
>
> For SSL we need a more elaborate configuration scheme. These
> requirements are driven directly off the J2EE CSIv2 interop
> specifications. In essence, we need to be able to specify these
> things on a per-bean level; which is probably best to do by a level of
> indirection, by having "named server socket configuration"s that can
> be referenced symbolically from the container-specific deployment
> descriptors.
We do something sort of like this (tss-link) in openejb today, although
there are architectural problems with the current implementation.
>
> For an SSL ServerSocket we need
>
> protocols=(SSL),(TLS)
> ciphers=<ALGORITHM,...>
> hashes=<ALGORITHM,...>
> keyexchanges=<ALGORITHM,...>
> requireTrustClient=REQUIRE|SUPPORT|NONE
> requireTrustServer=REQUIRE|SUPPORT|NONE
>
> For both cipers, hashes and keyexchangees, the list can include the
> NULL algorithm.
>
> These properties are used to select which cipher suites should be
> enabled for a given socket (the idea is to simply subset the
> "available cipher suites" on the active SSL provider). Cipher suites
> are named like this:
>
> (TLS|SSL)_<KEYEXCHANGE>_WITH_<CIPHER>_<HASH>
>
> If there is a key exchange mechanism (other than anonymous
> Diffie-Hellman "DH_anon"), then the SSL context also needs access to a
> key store with a key corresponding to the key exchange mechanism, and
> also a trust store used to validate the other parties. These two are
> represented by
>
> javax.net.ssl.X509TrustManager
> javax.net.ssl.X509KeyManager
>
> Both of these essentially represent a "keystore that has been opened
> (password unlocked)" as well as some policies for trust and key
> validation. It would make sense to simply expose instances of these
> as GBeans directly in the geronimo infrastructure, and then name these
> objects so they can be referenced from the SSL configuration.
>
> The require-trust parameters determines if client/server side trust is
> required or just supported. In the former case, client hand-shake
> should be completed successfully before the socket is passed back. If
> either of these is REQUIRE then only cipher suites with a non-null key
> exchange mechanism can be allowed.
>
> For client sockets, things are slightly more complicated because we
> need to support that the user is authenticated with an X509
> certificate. In this case, the credentials of the user (which would
> typically be sitting inside the current Subject) needs to be passed
> along to the socket creation so that the SSL logic can create an
> X509KeyManager that can service this information to the server if he
> needs it to establish the clients credentials.
>
Is this correct? Or one possibility we should support? My
understanding is that normally in csiv2 the ssl layer client
authentication authenticates the client system itself, whereas the
user's identity is transferred in an SAS identity token. If the client
system is a standalone client rather than a server, the client system
identity would presumably be the same as the user identity. Have I
missed something?
thanks
david jencks
>
>
> Kresten Krab Thorup
> krab@trifork.com
>
> "We do not inherit the Earth from our parents, we borrow it from our
> children." Saint Exupery
>
Re: ActiveIO
Posted by Kresten Krab Thorup <kr...@trifork.com>.
Here are some notes on SSL configuration from IIOP/CSIv2 point of
view. This is not API, just what a such API need to do. The Trifork
ORB (note: Trifork is with just one capital letter) includes some
code to do this, but it would make sense to integrate this into
ActiveIO to make it more widely applicable.
For SSL we need a more elaborate configuration scheme. These
requirements are driven directly off the J2EE CSIv2 interop
specifications. In essence, we need to be able to specify these
things on a per-bean level; which is probably best to do by a level
of indirection, by having "named server socket configuration"s that
can be referenced symbolically from the container-specific deployment
descriptors.
For an SSL ServerSocket we need
protocols=(SSL),(TLS)
ciphers=<ALGORITHM,...>
hashes=<ALGORITHM,...>
keyexchanges=<ALGORITHM,...>
requireTrustClient=REQUIRE|SUPPORT|NONE
requireTrustServer=REQUIRE|SUPPORT|NONE
For both cipers, hashes and keyexchangees, the list can include the
NULL algorithm.
These properties are used to select which cipher suites should be
enabled for a given socket (the idea is to simply subset the
"available cipher suites" on the active SSL provider). Cipher suites
are named like this:
(TLS|SSL)_<KEYEXCHANGE>_WITH_<CIPHER>_<HASH>
If there is a key exchange mechanism (other than anonymous Diffie-
Hellman "DH_anon"), then the SSL context also needs access to a key
store with a key corresponding to the key exchange mechanism, and
also a trust store used to validate the other parties. These two are
represented by
javax.net.ssl.X509TrustManager
javax.net.ssl.X509KeyManager
Both of these essentially represent a "keystore that has been opened
(password unlocked)" as well as some policies for trust and key
validation. It would make sense to simply expose instances of these
as GBeans directly in the geronimo infrastructure, and then name
these objects so they can be referenced from the SSL configuration.
The require-trust parameters determines if client/server side trust
is required or just supported. In the former case, client hand-shake
should be completed successfully before the socket is passed back.
If either of these is REQUIRE then only cipher suites with a non-null
key exchange mechanism can be allowed.
For client sockets, things are slightly more complicated because we
need to support that the user is authenticated with an X509
certificate. In this case, the credentials of the user (which would
typically be sitting inside the current Subject) needs to be passed
along to the socket creation so that the SSL logic can create an
X509KeyManager that can service this information to the server if he
needs it to establish the clients credentials.
Kresten Krab Thorup
krab@trifork.com
"We do not inherit the Earth from our parents, we borrow it from our
children." Saint Exupery
Re: ActiveIO
Posted by Jacek Laskowski <jl...@apache.org>.
Kresten Krab Thorup wrote:
> Hiram,
>
> I browsed through the ActiveIO code, and it is pretty close to what I
> am looking for for the basic IO stuff. Very nice!
>
> Here's a couple of things that come off my mind...
Thanks Kresten for these comments. They have served me as a gentle
introduction to ActiveIO, which I've never worked before, but upon
following them I'm a little more familiar with what I could expect from
it. Very roughtly, I supposed, but quite enough for a starter.
> - It would also be good to have the half-close functionality. In the
> Trifork ORB, if ORB receives a shut down, all active connection sockets
> are half-closed until active requests are done and responses sent.
It sounds like a 2 phase commit protocol for sockets. At least, it
reminded me about it upon reading it.
> I'll come back later with some thoughts on SSL stuff...
Please do. Keep it going.
> Kresten Krab Thorup
Jacek
Re: ActiveIO
Posted by Panagiotis Astithas <pa...@ebs.gr>.
Hiram Chirino wrote:
>
> On Jul 11, 2005, at 5:59 AM, Kresten Krab Thorup wrote:
>> I'll come back later with some thoughts on SSL stuff...
>>
>
> Thanks for the input Kresten. To spare the geronimo list from this low
> level io talk, you might want to post further thoughts to the activeio
> mailing lists: http://activeio.codehaus.org/maven/mail- lists.html
On the contrary, low level talk is very informative!
Thanks,
Panagiotis
Re: ActiveIO (was: Donation of a CORBA Orb)
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On Jul 11, 2005, at 5:59 AM, Kresten Krab Thorup wrote:
> Hiram,
>
> I browsed through the ActiveIO code, and it is pretty close to what
> I am looking for for the basic IO stuff. Very nice!
>
> Here's a couple of things that come off my mind...
>
> - the NIOAsyncChannel class should use the selector mechanism to
> wait for the ability to write data, rather than Object.wait'ing.
>
Yep, but in that case the producing thread should still do an
Object.wait() for the selector to callback and notify the producing
thread. Right now I'm taking a guess that the amount of time that I
have to wait() is small, while using a selector callback would let me
know explicitly how long the wait is for.
> - it would be benefitial to be able to buffer output enabling
> invocations in the main logic threads to finish fast, and then do
> the I/O in a separate thread (for example directly inside the
> selector thread). This is valuable for "slow clients" that may
> access the server over a modem for example. But this is just nice
> to have.
>
Good idea, we could do this with a filter easily.. in fact I think I
started on a filter that does just that. But, typically, I would
think raw byte buffering better done in the operating system layer.
Socket buffer sizes can be set to improve that.
> Maybe the above two could be combined into an "OutputAsyncChannel"
> interface? Perhaps this could work by means of a special
> FlushPacket that invokes a callback handler when all previous
> packets has been sent.
Our Channel interfaces have a flush() method that is meant to do just
that! (To do it's best to flush all buffered data down the pipe).
>
> - It looks like all writes are synchronous and blocking. We need
> to have a timeout mechanism for both read- and write-operations --
> this is critical for large-scale operations. When there are many
> clients, several of them will typically be inactive for longer
> periods of time, and so there is a lot to be saved by closing down
> connections. Also, some of them will simply hang, become
> disconnected from the network without TCP-level notification, or
> otherwise be ineffective. example: In one of our installations we
> have hundreds of CORBA clients sitting at "work stations" around
> the facility, and most of these are idle most of the time. Corba/
> iiop has a mechanism to reestablish such connections as needed (at
> least the Trifork ORB does that).
>
Sounds good to me. I'm willing to add write operation with a
timeout. I would guess we also need a flush operation with a time too.
> - It would also be good to have the half-close functionality. In
> the Trifork ORB, if ORB receives a shut down, all active connection
> sockets are half-closed until active requests are done and
> responses sent.
>
> One of the difficult problems with TCP sockets is that one does not
> necessarily know if the other end closed the connection (or if he
> is gone). This can result in some pretty annoying hangs higher up
> the stack, and it's a pain to handle those cases all over the place
> in I/O code. The only "generic solution" to this as far as I can
> see is to use reasonable timeouts everywhere.
>
> I'll come back later with some thoughts on SSL stuff...
>
Thanks for the input Kresten. To spare the geronimo list from this
low level io talk, you might want to post further thoughts to the
activeio mailing lists: http://activeio.codehaus.org/maven/mail-
lists.html
>
>
> Kresten Krab Thorup
> krab@trifork.com
>
> "We do not inherit the Earth from our parents, we borrow it from
> our children." Saint Exupery
>
>
>
> On Jul 8, 2005, at 5:35 PM, Hiram Chirino wrote:
>
>
>> Hi David,
>>
>> You are absolutely correct. The ActiveIO stuff was a
>> generalization and abstraction of the IO code in ActiveMQ. Thanks
>> for clarifying a potentially sensitive situation!
>>
>> Regards,
>> Hiram
>>
>> On Jul 7, 2005, at 10:51 PM, David Blevins wrote:
>>
>>
>>
>>> On Thu, Jul 07, 2005 at 12:16:19PM -0400, Davanum Srinivas wrote:
>>>
>>>
>>>
>>>> Hiram,
>>>>
>>>> Could you please make sure that the project gets worked on here at
>>>> Apache? Am a bit concerned about code getting forked out and then
>>>> becoming geronimo becoming a dependency on an external project.
>>>>
>>>>
>>>>
>>>
>>> There's the "f" word again :)
>>>
>>> Hiram, you can correct me if I'm wrong, but thought the ActiveIO
>>> code
>>> was created from the ActiveMQ transport system?
>>>
>>> We had several conversations over a period of months on just
>>> using the
>>> ActiveMQ transports in OpenEJB and Geronimo so there would be
>>> something common to cut-down on duplicating efforts. We didn't use
>>> any Geronimo IO code cause it, well... sucked :)
>>>
>>> Even then, I think you pretty much rewrote everything.
>>>
>>> Is my memory of history accurate or have I demented myself?
>>>
>>> -David
>>>
>>>
>>>
>>
>>
>>
>
>
Re: ActiveIO (was: Donation of a CORBA Orb)
Posted by Kresten Krab Thorup <kr...@trifork.com>.
Hiram,
I browsed through the ActiveIO code, and it is pretty close to what I
am looking for for the basic IO stuff. Very nice!
Here's a couple of things that come off my mind...
- the NIOAsyncChannel class should use the selector mechanism to wait
for the ability to write data, rather than Object.wait'ing.
- it would be benefitial to be able to buffer output enabling
invocations in the main logic threads to finish fast, and then do the
I/O in a separate thread (for example directly inside the selector
thread). This is valuable for "slow clients" that may access the
server over a modem for example. But this is just nice to have.
Maybe the above two could be combined into an "OutputAsyncChannel"
interface? Perhaps this could work by means of a special FlushPacket
that invokes a callback handler when all previous packets has been sent.
- It looks like all writes are synchronous and blocking. We need to
have a timeout mechanism for both read- and write-operations -- this
is critical for large-scale operations. When there are many clients,
several of them will typically be inactive for longer periods of
time, and so there is a lot to be saved by closing down connections.
Also, some of them will simply hang, become disconnected from the
network without TCP-level notification, or otherwise be ineffective.
example: In one of our installations we have hundreds of CORBA
clients sitting at "work stations" around the facility, and most of
these are idle most of the time. Corba/iiop has a mechanism to
reestablish such connections as needed (at least the Trifork ORB
does that).
- It would also be good to have the half-close functionality. In the
Trifork ORB, if ORB receives a shut down, all active connection
sockets are half-closed until active requests are done and responses
sent.
One of the difficult problems with TCP sockets is that one does not
necessarily know if the other end closed the connection (or if he is
gone). This can result in some pretty annoying hangs higher up the
stack, and it's a pain to handle those cases all over the place in I/
O code. The only "generic solution" to this as far as I can see is
to use reasonable timeouts everywhere.
I'll come back later with some thoughts on SSL stuff...
Kresten Krab Thorup
krab@trifork.com
"We do not inherit the Earth from our parents, we borrow it from our
children." Saint Exupery
On Jul 8, 2005, at 5:35 PM, Hiram Chirino wrote:
> Hi David,
>
> You are absolutely correct. The ActiveIO stuff was a
> generalization and abstraction of the IO code in ActiveMQ. Thanks
> for clarifying a potentially sensitive situation!
>
> Regards,
> Hiram
>
> On Jul 7, 2005, at 10:51 PM, David Blevins wrote:
>
>
>> On Thu, Jul 07, 2005 at 12:16:19PM -0400, Davanum Srinivas wrote:
>>
>>
>>> Hiram,
>>>
>>> Could you please make sure that the project gets worked on here at
>>> Apache? Am a bit concerned about code getting forked out and then
>>> becoming geronimo becoming a dependency on an external project.
>>>
>>>
>>
>> There's the "f" word again :)
>>
>> Hiram, you can correct me if I'm wrong, but thought the ActiveIO code
>> was created from the ActiveMQ transport system?
>>
>> We had several conversations over a period of months on just using
>> the
>> ActiveMQ transports in OpenEJB and Geronimo so there would be
>> something common to cut-down on duplicating efforts. We didn't use
>> any Geronimo IO code cause it, well... sucked :)
>>
>> Even then, I think you pretty much rewrote everything.
>>
>> Is my memory of history accurate or have I demented myself?
>>
>> -David
>>
>>
>
>
Re: ActiveIO (was: Donation of a CORBA Orb)
Posted by Hiram Chirino <ch...@apache.org>.
Hi David,
You are absolutely correct. The ActiveIO stuff was a generalization
and abstraction of the IO code in ActiveMQ. Thanks for clarifying a
potentially sensitive situation!
Regards,
Hiram
On Jul 7, 2005, at 10:51 PM, David Blevins wrote:
> On Thu, Jul 07, 2005 at 12:16:19PM -0400, Davanum Srinivas wrote:
>
>> Hiram,
>>
>> Could you please make sure that the project gets worked on here at
>> Apache? Am a bit concerned about code getting forked out and then
>> becoming geronimo becoming a dependency on an external project.
>>
>
> There's the "f" word again :)
>
> Hiram, you can correct me if I'm wrong, but thought the ActiveIO code
> was created from the ActiveMQ transport system?
>
> We had several conversations over a period of months on just using the
> ActiveMQ transports in OpenEJB and Geronimo so there would be
> something common to cut-down on duplicating efforts. We didn't use
> any Geronimo IO code cause it, well... sucked :)
>
> Even then, I think you pretty much rewrote everything.
>
> Is my memory of history accurate or have I demented myself?
>
> -David
>