Re: [JBoss-dev] authenticating using a non-text credential (ObjectCallback)

[Scott M Stark]

>login. When dealing with public key information, what is our principal? What is our credential? I kinda assumed the DN >would be the principal and the Certificate the credential. (ya, I know that isn't what is currently happening in the code) Right, that is what I'm saying should be done. Take the cert dn and create a SimplePrincipal with the dn as the name, or alternatively, if it is an X509Certificate obtain the Principal via the getSubjectDN method, and pass in the cert as the crendential. Its the current use of null as the Principal that is the problem as this refers to the anonymous principal. After authentication there is no real principal associated with the calling thread that could be used as the propagation context of the callee. This means that if the EJB that was invoked by the soap msg tries to access other secured resources its screwed.     xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx ----- Original Message ----- From: Jason Essington To: [EMAIL PROTECTED] Sent: Friday, December 06, 2002 8:11 AM Subject: Re: [JBoss-dev] authenticating using a non-text credential (ObjectCallback) Hmm, so I am trying to do too many things in my login module. Or maybe I am a bit confused about what role an X509 Certificate really plays in this scenario. The certificate contains information about the principal (the DN) so it appears to perform both the role of principal and credential. Which is it really? Here are my thoughts on the process thus far.: 1) An incoming signed message (that has the required public key information embedded) is passed to the SigVerificationHandler who uses the embedded key information to verify the message. Actually I suppose it is possible that the key information would not be embedded in the message so this guy would have to use a key resolver to acquire the public key information from a keystore or keyserver of some sort. At any rate by the time SigVerificationHandler is finished with the message, we have the public key and the message has been validated. 2) The message is then passed to the SigAuthenticationHandler who's job it is to decide wether or not the key is to be trusted then perform the login. I Suppose this guy's job would be to find the key in a Truststore of some sort, then perform a login. The SigAuthenticationHandler, is where we should decide what or who our principal is prior to performing the login. When dealing with public key information, what is our principal? What is our credential? I kinda assumed the DN would be the principal and the Certificate the credential. (ya, I know that isn't what is currently happening in the code) 3) The message continues along the jboss.net execution path just like none of this weirdness ever happened. Is this really what should be happening to make signature authentication fit into the JBoss security model? Or am I making some very bad assumptions? Thanks for any input. -jason