1 2 Previous Next 17 Replies Latest reply on Feb 22, 2006 10:07 AM by smbd

    Authentication occures many times

    smbd

      Hi, everyone!

      I've encountered a problem with a login module. The system my organization is developing already has a module, that is UsernamePasswordLoginModule's descendant. It works fine.

      A am developing another login module for the same actions, inheriting from AbstractServerLoginModule. It works OK, but it is called every time any bean's (that is protected by my module's security domain) method is called. So, I'm getting my login() and commit() methods called for 5-6 times a single action is performed.

      I do not use the options and shared state in my login module, but it doesn't seem to be the reason.

      Where can be the reason of these multiple calls?

        • 1. Re: Authentication occures many times
          starksm64

          Print a stack trace to illustrate who is calling the login module.

          • 2. Re: Authentication occures many times
            smbd

            There is no error and no stack trace :)

            The credential for login is the finger print. It is slightly different every next time and a special third party library deals with the comparing math. But this comparison takes a long time that is acceptable only once ? in the LoginModule?s login() method. In credential?s equals() method I use a straightforward (and faster) byte-by-byte comparison.

            When user logins for the first time everything is OK. The credential is cached and compared against it when needed.

            Next time the client logins to the server his credential (finger print) is a little bit different. And it IS NOT exactly equal to the previous CACHED credential. And every time the server calls a security domain protected bean?s method, the login() method with its long math third party comparison is called. That would be OK for the first time, but after the successful login-commit and the call to the protected method are performed, the CACHED credentials remain THE SAME (previuos). So the newly authenticated credentials don?t get cached.

            I tried flushing the cached credentials (as shown at http://www.jboss.org/wiki/Wiki.jsp?page=CachingLoginCredentials) in the logout() method or just before committing the authentication, or in logout() but it doesn?t help. May be the credentials cache is not flushed, but I don?t know how to verify it.

            The question is how can I ensure that this newly accepted finger print credential is cached and the future comparisons will be held against it?

            • 3. Re: Authentication occures many times
              j2ee_junkie

              smbd,

              Could you please submit more details. We have no info about your client, what your login-configuration is, how the authenticated Principal is being propagated to AS, and as Scott suggest, we need TRACE level logging of the authentication process to see what is going on.

              Also, I believe you may need to change your authentication scheme a bit to fit your scenario or get a better understanding of the authentication system. Read chapter 8 of the server guide. Your statements are inconsistent to me. First you say that every time the user performs a login to system the fingerprint credential is a little different (which I would expect), but then you say you do not want to have to check the new credential. Isn't that what login is for? Next, you want the system to cache the credentials so that next time the client logs in with a different credential the cached credential is used, but then you say that you flushed the credentials on logout or in commit.

              It all just does not jive. Please be more clear. I would love to help you on this, cgriffith

              I

              • 4. Re: Authentication occures many times
                smbd

                I?ll try to be more clear.

                The client uses a custom client login module, because ClientLoginModule doesn?t send ObjectCallback. This custom client login module uses SecurityAssociation.

                The client logins to the server (actually only to the client side login module) and calls two security domain protected methods consequently.

                At server-side the server login module authenticates the client. As I understand, the callbacks (credentials) are cached at that time. Then, before every of the two method calls it compares the subject?s credentials against the cached credentials. Everything is OK.

                Then the same client tries to repeat the same action. The difference is that the finger print is not absolutely the same. And this time, the login() method is not called immediately. First, the credentials are compared. And the finger print is not absolutely the same. And the finger print is passed to the login module to be authenticated. And the login module authenticates it successfully (#2). It?s OK.

                Then, the first method is called. But when comparing the credentials before the second method call, the currently provided credentials are compared against the credentials cached when the client was authenticated for the VERY FIRST time. This means that when the login module worked previous time (#2) it didn?t cache the credentials?

                The client will be authenticated again, but this demands more time than just comparing the array or its MD5 code. It?s unacceptable to perform the fill authentication before every of the 100 or 1000 method calls.

                I think a good approach will be to clear the cache every time a login module is used and, if authentication is successful, to cache newly provided credentials.

                I hope I expressed more clear :)

                • 5. Re: Authentication occures many times
                  j2ee_junkie

                  smbd,

                  Thanks for trying to be more clear about your situation. However, I am still having trouble. You still have told us very little about your client and the login-config of server. So let me try to repeat the situation back to you to see if I understand.

                  First though, I want to point out that you could have used ClientLoginModule in your situation if you used the useFirstPass configuration and passed the object throught the shared state. In this situation you can use an Object as the credentials.

                  O.K. so ...

                  1.)A user attempts to use the client application (or some restricted aspect of the application) and the client discovers that the user has not authenticated yet.

                  2.) The client uses JAAS configured with a custom LoginModule I'll call LM_A to get the users fingerprint and authenticate the fingerprint.

                  3.)However during this process, LM_A must access a secured EJB.

                  Is this correct so far? If so, how is LM_A authenticated with JBoss?
                  At this point things start to get fuzzy from your description.

                  4.) Assume step 3 was successfull, user has now authenticated themselves to the client only.

                  5.)Then the client must access JBoss AS in order to fullfill orginal task in step #1

                  6.) The client then needs to authenticate itself with JBoss server.
                  How is this happing for you? Some credential must be sent.

                  7.) Assume #6 magically happens and JBoss caches the credentials sent in step #6

                  8.) Then JBoss performs task and returns result to client.

                  Again things become unclear from your description.

                  9.) User attempts to perform the same task, however you say that the fingerprint credential is different. Unless you are aquiring a whole new version of the fingerprint credential, how has it changed. Shouldn't your client cache the fingerprint during step during step #4?

                  Please try again, and be more clear about what happens at each stage. Also, TRACE logging would be nice.

                  cgriffith

                  • 6. Re: Authentication occures many times
                    smbd

                    OK, let?s try once more.

                    I have a JBoss AS. 4.0.2.

                    I have a ServerSideLoginModule and a ClientSideLoginModule. All authentications happens at server side i.e. inside ServerSideLoginModule. ClientSideLoginModule just like JBoss ClientLoginModule simply propagates the necessary callbacks to the server using SecurityAssociationActions.setPrincipalInfo().

                    Thank you for the tip about using first pass in ClientLoginModule. I?ll try it.

                    Also I have two EJB3 deployed: EJB#1 and EJB#2. They both are protected by MySecurityDomain. The login-config.xml has these lines

                    <application-policy name = "MySecurityDomain">
                    <authentication>
                    <login-module code = "my.package.ServerSideLoginModule"
                    flag = "required" >
                    </login-module>
                    </authentication>
                    </application-policy>
                    


                    What happens step by step.

                    1) user logins to ClientSideLoginModule. The callback handler scans the finger print and the module sets the principal info, i.e. the finger print and name

                    2) user calls an EJB#1 method
                    a) the credentials are propagated to the server
                    b) the ServerSideLoginModule is invoked. It authenticates the subject, and stores the finger print in subject?s private credentials and name as SimplePrincipal
                    c) somewhere here, as I think, the credentials, i.e. the finger print and name are cached as CACHED#1
                    d) before the call to EJB#1 method, the current subject?s credentials are checked against the CACHED#1. As they are equal (actually, the same) -> e)
                    e) the EJB#1 method is called

                    3) user calls EJB#2 method
                    a) before the call to EJB#2 method, the current subject?s credentials are checked against the CACHED#1. As they are equal -> b)
                    b) the EJB#2 method is called

                    4) ServerSideLoginModule.logout() is not called as the timeout time has not expired yet

                    5) the client shuts down the application and then launches it again

                    6) user logins to ClientSideLoginModule. The callback handler scans the finger print and the module sets the principal info, i.e. the finger print. Man cannot put the finger on the scanner ABSOLUTELY THE SAME, it goes a little bit left or right, or up, or down. The special library handler this inaccuracy but the byte array is still different

                    7) user calls an EJB#1 method
                    a) the credentials are propagated to the server
                    b) the ServerSideLoginModule is NOT invoked
                    c) the given credentials, i.e. the finger print and name are compared to the credentials in CACHED#1. They are not equal
                    d) the ServerSideLoginModule is invoked. It authenticates the subject, and stores the finger print in subject?s private credentials and name as SimplePrincipal
                    e) the current credentials are not cached as CACHED#2 as seen in 7)h)
                    f) the EJB#1 method is called
                    g) ServerSideLoginModule.logout() is called, removing the finger print and name from subject?s private credentials and principals
                    h) before calling the EJB#2 method the current subject?s credentials are compared against the CACHED#1. They are not equal.
                    i) the ServerSideLoginModule is invoked. It authenticates the subject, and stores the finger print in subject?s private credentials and name as SimplePrincipal
                    j) the current credentials are not cached as CACHED#2
                    k) the EJB#2 method is called
                    l) ServerSideLoginModule.logout() is called, removing the finger print and name from subject?s private credentials and principals

                    I tried flushing the cache before saving the name and finger print in ServerSideLoginModule.commit(). There was no effect. I wrote this way:
                    String domain = "jmx-console";
                    Principal user = new SimplePrincipal(principalName);
                    ObjectName jaasMgr = new ObjectName("jboss.security:service=JaasSecurityManager");
                    Object[] params = {domain, user};
                    String[] signature = {"java.lang.String", Principal.class.getName() };
                    MBeanServer server = (javax.management.MBeanServer) MBeanServerFactory.findMBeanServer(null).get(0);
                    server.invoke(jaasMgr, "flushAuthenticationCache", params, signature);


                    I think it would be satisfactory if server cached the last authenticated credentials.

                    The TRACE logging is so huge that I?d try do without it. Hope this can resolve some understanding troubles :)






                    • 7. Re: Authentication occures many times
                      smbd

                      Another interesting notice.

                      When I flush the credentials for my security domain via JMX-console the authenticated user (its principal name) disappears from the list of cached principals (using getAuthenticationCachePrincipals).

                      But when aftr that I try my test (calling EJB#1 and EJB#2 methods) the credentials are first of all compared to some other. So, the cache for principals is cleared, but not the cache for credentials.
                      Am I right?

                      • 8. Re: Authentication occures many times
                        j2ee_junkie

                        smbd,

                        Thank you for giving this one more try. You have explained your situation much better. I really think you problem stems from the fact that you do not log your users out of system when client is closed. Especially since your principals have moving credentials.

                        cgriffith

                        • 9. Re: Authentication occures many times
                          smbd

                          Yes, I think this can help.

                          But how can I logout from the server? Calling the logout() method at client side doesn't logout the user from the server. It calls only ClientSideLoginModule's method and is not propagated to JBoss. My ServerSideLoginModule?s logout() method is called only in 7)g) of my first Friday post.

                          As I understand one can logout from the server only by timeout.

                          • 10. Re: Authentication occures many times
                            j2ee_junkie

                            So far as I can see, the best way is to follow the code you mentioned earlier at http://www.jboss.org/wiki/Wiki.jsp?page=CachingLoginCredentials. I would like to see what others on this forum have to offer on this subject.

                            • 11. Re: Authentication occures many times
                              smbd

                              It seems like the code from http://www.jboss.org/wiki/Wiki.jsp?page=CachingLoginCredentials doesn't work as I wrote in my previous posts! Or, I hope I've done something wrong. Anyway, I faced the situation that there is no authenticated subject but the credentials provided by the client are compared with some other credentials...

                              • 12. Re: Authentication occures many times
                                starksm64

                                Flushing the server authentication cache triggers a logout on the associated login modules.

                                • 13. Re: Authentication occures many times
                                  smbd

                                  Thank you for your replying, Scott. Logout is called when flushing the authentication cache, I?ve checked it :).

                                  The problem it that this cache seems not to be flushed completely, i.e. the credentials remain cached!

                                  For example, I login to the server, perform some actions. Then I flush the cache (via jmx-console or programmatically) and the server login module?s logout() is called.

                                  If this matters, on commit() and logout() I store and remove the subject?s principal and roles in principals collection, login name as public credential and finger print as private credential.

                                  Then I launch the same client application. And this time FIRST OF ALL the credentials are compared! I have my custom class for finger print callback (as ObjectCallback) and when it is compared it logs this event.

                                  This means that some credentials are still cached! And this situation repeats until the timeout expires. Can I perform these timeout actions programmatically myself?

                                  • 14. Re: Authentication occures many times
                                    j2ee_junkie

                                    Smbd,

                                    It would be a good idea to see what the authentication cache contains. So log a user into your client, and then access a secured EJB (thus causing the server login). Then using jmx-console inspect the contents of the authentication cache. It is in mbean jboss.security,service=JAASSecurityManager. The method is getAuthenticationCachePrincipals(). Use the domain name as parameter.

                                    Then log user out of application (client and server) and check this cache again. Then log user back in and inspace the cache again. Finally log user out and check cache again. Let me know what you find.

                                    Also, when a user has authenticated to server, the principal and credentials are cached. When same principal access the server again, the credentials are obtained from cache and compared to the credentials being supplied by invocation. So may question to you is, does your credential Object implement Comparable, and if so, how is this comparison made?

                                    later, cgriffith

                                    1 2 Previous Next