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
On Thursday, December 5, 2002, at 11:40 AM, Scott M Stark wrote:
I don't remeber seeing my reply to this, so maybe a duplicate.
�
The principal for the certificate should be passed in from the layer doing
the validation. Login modules do not define the caller principal, they validate
them. I need to understand the functions of the SigVerificationHandler and
SigAuthenticationHandler in the overall context of a method invocation to
really say how they map to JBossSX and whether additional security APIs
are needed here.
�
Adding the xmlsig stuff to thirdparty is fine.
�
xxxxxxxxxxxxxxxxxxxxxxxx
Scott Stark
Chief Technology Officer
JBoss Group, LLC
xxxxxxxxxxxxxxxxxxxxxxxx
----- Original Message -----
From: Jason Essington
To: [EMAIL PROTECTED]
Sent: Wednesday, November 27, 2002 2:50 PM
Subject: Re: [JBoss-dev] authenticating using a non-text credential (ObjectCallback)
On Wednesday, November 27, 2002, at 01:01 PM, Scott M Stark wrote:
I updated the default CallbackHandler used by the JaasSecurityManager to support ObjectCallbacks
and changed the SigAuthenticationHandler to use the isValid() method.
Thanks Scott.
The use of null as the
principal indicates this is not really an authentication so I need to understand what the context of
the validation is.
Actually the certificate contains the information about the principal we are authenticating ( the CN portion of Distinguished Name for instance ).
By the time the SigAuthenticationHandler sees the certificate, the SigVerificationHandler has already validated the certificate, and the messages signature. At this point we are just trying to decide if the certificate should be trusted.
Maybe it would be better to not assume the certificate has already been validated?
I haven't committed the SigVerificationHandler yet because it requires apache's XML-Security library to compile, and I am not sure if it is o.k. to just go adding things to thirdparty.
If you just want to know if the cert should be accepted why not use the KeyStore
associated with the security domain to see if the cert is know to the security domain and validate
the cert as a X509Certificate?
�
Explain the context some more and if there are cert management functions that should be
part of the SecurityDomain interface I'll look into adding them.
The CertificateLoginModule checks that the certificate exists (and is trusted) in the keystore. If so it creates a SimplePrincipal (using the certificate's alias as the name) that will be returned by the getIdentity() method.
This is admittably a bit of a hack to map certificates to users in the system. I did this rather than using say the CN so that there would be a little bit of control over the user to whom this Certificate gets mapped. I could really use any ideas on a better way to accomplish this?
Once the identity has been divined from the certificate, it's a simple matter for getRoleSets() to find the roles this user should assume.
Let me know if my thought process is way off here. If it is, is there a better way to accomplish what I am attempting?
thanks
-jason
