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
[EMAIL PROTECTED]
"We do not inherit the Earth from our parents, we borrow it from our
children." Saint Exupery
