8 Replies Latest reply on Nov 19, 2008 6:01 PM by clevelam

    LoginFilter vs. WebAuthenticator

    clevelam

      In what situations would you implement a JAAS Login Filter vs. using JBOSS' WebAuthenticator class?

      I'm starting to feel like the filter approach greater flexibility.

        • 1. Re: LoginFilter vs. WebAuthenticator
          ragavgomatam

          Would you like the credentials to be propagated to ejb tier ? If not, feel free to use Filters

          • 2. Re: LoginFilter vs. WebAuthenticator
            clevelam

            I don't have any EJBs.

            Question regarding the filter approach. The examples that I have seen online do login call, chain.doFilter (to call next filter or resource), then logout.

            The login / logout calls make database calls. This seems expensive to me to do login / logout on every resource call.

            Additionally, I have a requirement to prevent multiple sessions for having access to the resources. Meaning I want to wait until person 1 is completely done with the app before I allow person 2 in.

            To work this out.. is there a filter pattern that does not call logout everytime and store's login credentials somewhere ???

            I chose the Webauthenticator because once authenticated all resources can be restricted in the web.xml and the authenticated user has access until he logs out. And no more login calls need to be made.

            Please provide an example.

            • 3. Re: LoginFilter vs. WebAuthenticator
              ragavgomatam

               

              Additionally, I have a requirement to prevent multiple sessions for having access to the resources. Meaning I want to wait until person 1 is completely done with the app before I allow person 2 in.


              This does not make sense with a web application. Explain please

              OR is it

              You don't want the same person from logging in twice into the same application , while the first session is alive ?


              • 4. Re: LoginFilter vs. WebAuthenticator
                clevelam

                Similiar to what you said. If a user shares his credentials with a friend. I do not want two sessions using the same credentials.

                • 5. Re: LoginFilter vs. WebAuthenticator
                  ragavgomatam

                  Try this.

                  When person 1 logs in, use a filter to capture the credentials & store it in the ServletContext. This should remain in the ServletContext as long as person 1's session is valid. When person 1 logs out, call invalidate on HttpSession, set up a HttpSessonListener, that will call the ServletContext & remove the credientials from there.

                  If Person 1 tries to log in from another computer or another browser, while he is logged in , the filter checks to see if the credential exists in the ServletContext. If it exists there, it rejects the log in, else allows it to proceed through.

                  Here we use the ServletContext, as it is shared across the whole application. You may try with the get the ServletContext from a method available in the FilterConfig

                  • 6. Re: LoginFilter vs. WebAuthenticator
                    clevelam

                    I think I get the idea.

                    There is something I'm missing about what's described above. I'm assuming the Filter is called on every reguest. When the 1st user who stores his credentials in the servlet context.. goes to the next resource in the app... wouldnt the check be done... and reject the user.

                    Also... we're are now saying only attempt to login a user... in the filter... the filter will no longer be used to logout... correct ?

                    Maybe if i store a session id as "logged in proof" in the servlet context.... I can check for that credential.. if it's there I know the users logged in so i can go to the next resource... otherwise I reject them.

                    • 7. Re: LoginFilter vs. WebAuthenticator
                      ragavgomatam

                      Yes. The approach I mentioned will have to altered slightly. Add the HttpSessionId to ServletContext too. Check for the existence of both credential & sesion id. That means user is logged in & active. So if the same user tries to log in again, his credential will be same but sessionId will be different. So may be a combination of credential + sessionId may be a key / value in ServletContext. Check for this .

                      Also during log out clear this from ServletContext. Log out will call a HttpSession.Invalidate(), followed by a call to HttpSessionListener that will clear out the ServletContext entries.

                      OR

                      You may set up a ServletContextListener, that ensures that Credential/session id contract is unique.

                      • 8. Re: LoginFilter vs. WebAuthenticator
                        clevelam

                        Great. That sounds like it will work. Thanks for the pointers.