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
