Dawes, Phil wrote:

> Unfortunately, unlike Jetty, JbossSX does require that the principal be the
> same for each subsequent call into the security layer after the initial
> auth, since JaasSecurityManager caches the subject information based on
> principal. This means AFAIK I can't switch the principal to a different one
> after the authenticate. 
> 
> <thinks>
> Although I suppose Jetty could use a Principal which allowed the name to be
> changed retrospectively without changing the hashcode - would this work?.
> </thinks>

Note that on each request that needs to be authenticated, Jetty will
follow the same code.  It will call realm.authenticate passing the
subjectDN as the principal name.  So the name does not really change
within the principal.

It is just that Jetty does not care if the principal passed back
from that call has the same name as was passed.  It is the returned
principal that is used to setup the user and principal methods on the
request.

It is up to the realm implementation if it passed back the same
principal or a new one each time.

Having said that - I see no problem with your suggestion from the
Jetty side of things - but I'll defer to Jules to comment on the
Jetty/JBoss realm implementation.

I'll put the changes into ClientCertAuthenticator anyway as I think
they are generally a good idea:

             Principal principal = certs[i].getSubjectDN();
             if (principal==null)
                 principal=certs[i].getIssuerDN();
             UserPrincipal user =
                 realm.authenticate(principal==null?"clientcert":principal.getName(),
                                    certs[i],request);


While we are thinking about authentication, somebody needs to get
some spare cycles to implement runAs for servlets.  Jan was just about
to start on that, but then got sucked into the Duetche Bank void for the
next n months....   Scott had made some suggestions for that - but I
never got time to digest them.

cheers



> I ought to elaborate - the real problem for me is not thinking of a name for
> a dummy principal to use. The real problem is that after authentication, the
> application writers will want to get more information about the user other
> than just the principal name. In order to do this we have a service which
> returns information about the user when passed the authenticated principal.
> This means that the principal name needs to be something sensible (currently
> UserID in our weblogic setup).
> 
> Weblogic has an api (like jetty's) which allows the principal to be created
> after the authentication, thus allowing the realm to dictate what the
> authenticated principal name is. 
> 
> How does this sound as a solution:
> 
> - jetty ClientCertAuthenticator uses subjectDN, or failing that,
> CertSerial&Issuer as the username (not important really)
> 
> - The Jetty JbossUserRealm creates a principal which can have its name
> changed without changing the object hashcode.
> 
> - Realm calls isValid(principal, cert)
> 
> - Home baked JAAS LoginModule authenticates certificate, and populates
> active subject on commit.
> 
> - Realm then sets the principal name to be that of the first principal in
> the active subject.
> 
> This means that the author of the JAAS login module can dictate what name of
> the principal after the authentication has taken place, and the Jetty
> JbossUserRealm is still pretty generic.
> 
> Does this sound reasonable? 
> 


-- 
Greg Wilkins<[EMAIL PROTECTED]>             Phone/fax: +44 7092063462
Mort Bay Consulting Australia and UK.          http://www.mortbay.com



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to