-
15. Re: Authentication occures many times
j2ee_junkie,
As I?ve told earlier:
1) I use an EJB. getAuthenticationCachePrincipals() returns [admin]
2) I log out. By timeout or by flushAuthenticationCache(). No other way. getAuthenticationCachePrincipals() returns [] (empty list)
3) I login again (call an EJB). getAuthenticationCachePrincipals() returns [admin]
4) as 2).
My credential object doesn?t implement Comparable. Instead, it overloads equals( Object o ).
What happens in spite of it should NOT happen: after the CACHE is FLUSHED the DIFFERENT credentials are COMPARED!!! This means that something still remains cached!!! Is it a bug? Or can I access this buffer and flush it too?? -
16. Re: Authentication occures many times
smbd,
You were never completely clear as to what the authentication cache contained. However, now I know for sure.
You also have not been completely clear about your security domain config for the Client. Please be more specific about this configuration, as well as how your client initiates access to this domain. Is your client multi-threaded, stand-alone app, or web-based? One thing that stands out as odd is you said you have a custom ClientSideLoginModule that access the SecurityAssociationActions class. However this is an package only visible class. Does this mean that you have packaged your login module with JBoss's jbosssx.jar? How does your ClientSideLoginModule propagate principal and credentials? The info you last provided makes me wonder if your client's security domain has some cache set up so the duplicate comparison is actually from the client's domain.
Finally, in order to help you further, please submit relevant TRACE logging as Scott and I have already requested.
cgriffith -
17. Re: Authentication occures many times
The client auth.conf file contains
MySecurityDomain {
my.package.ClientSideLoginModule required ;
};
It is a simple single-threaded test application. I didn?t use ?useFirstPass? so I just copied the SecurityAssociationActions class to my package ? not a good thing, I?ll change it later. Anyway, ClientSideLoginModule repeats the ClientLoginModule?s behavior:
public boolean commit() throws LoginException{
SecurityAssociationActions.setPrincipalInfo(loginPrincipal, loginCredential, subject);
Set principals = subject.getPrincipals() ;
if( loginPrincipal.getName() != null && !principals.contains( loginPrincipal ) ){
principals.add( loginPrincipal ) ;
}
return true;
}
Client is very thin, it only scans the finger print and performs a call. It has no cache. The comparison happens at server only.
I didn?t want to post my stack trace, because it include the finger prints ? about 150 KB each. Anyway, the log tells this when I try to launch the app for the second time:
2006-02-22 16:38:43,495 DEBUG [org.jboss.remoting.transport.socket.ServerThread] WAKEUP in SERVER THREAD
2006-02-22 16:38:43,495 DEBUG [org.jboss.remoting.transport.socket.ServerThread] beginning dorun
2006-02-22 16:38:43,542 INFO [MyCredentials] MyCredentials->NOT EQUALS
MyCredentials ? the class with the finger print. And then the security check begins?
It seem I?ll have to look through the sources? :(