geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Piper <>
Subject Re: ActiveIO
Date Wed, 20 Jul 2005 09:04:44 GMT
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
>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.



View raw message