geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: ActiveIO
Date Tue, 12 Jul 2005 17:55:06 GMT

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

david jencks

> Kresten Krab Thorup
> "We do not inherit the Earth from our parents, we borrow it from our 
> children." Saint Exupery

View raw message