Logout in JSF with Security managed by Glassfish v3.1

[Fidel Alejandro Torrealba V]

Hi, I havent found a real solution for this problem, even when it is really common...

I have this context:

- JSF application running on Glassfish Server v3.1, JDK6. All in my personal computer with WinVista (This last should not be important).
- Using SSL and Basic authentication (Security of the container)
- I have done my logout() method in my backing bean invalidating the session and sending a redirect.

I can not make the container show again the Login box to validate the user, and be able to change of user... And my user always can go back, pressing the BACK button in the browser or just writing the URL, and continue doing thnigs there when is supposed that there should not be a existing session.

I am getting the name of the user the my backing bean is created:

    private void setName() {
        this.name = FacesContext.getCurrentInstance().getExternalContext().getUserPrincipal().getName();

    }

And I use this name to perform operations...

Then for logout my xhtml has the code:

<h:panelGroup id="logOut"> <h:form> <h:commandLink id="linkLogOut" action="#{visitor.logout}" value=" Clic here to Log Out" /> </h:form> </h:panelGroup>

That calls this method in my bean::

    public void logout() throws IOException {
       // FacesContext.getCurrentInstance().getExternalContext().invalidateSession();
        this.name = null;
        FacesContext fc = FacesContext.getCurrentInstance();
        HttpSession session = (HttpSession)fc.getExternalContext().getSession(false);
        session.invalidate();
    FacesContext.getCurrentInstance().getExternalContext().redirect("https://localhost:8080/");
    }

I am declaring my backing bean with:

    @Named(value="visitor")
    @SessionScoped

...Also I was doing the redirect from the the deployment descriptor... and it was the same.

If I close the browser the the session is lost and the container ask me again for user/pass.

Any suggestions?

Thanks a lot!

Alejandro.

[Tim Holloway]

This is one of those things where it helps to see what you're doing, but I have my suspicions, so let me explain How Things Work and see if they suggest anything.

The first thing to realize is that having a session isn't the same thing as being logged in, although to log out, you destroy the session. JSF tends to accentuate that, since it requires more use of session-scope objects than most J2EE frameworks.

The second thing to realize is that J2EE container-managed security is based on incoming URLs. If you submit an unsecured URL, you won't be prompted for login, but if you submit a secured URL, you will, regardless of where you jumped in from. And it's worth noting that it is the URL that's being secured, not the backing beans or other internal objects. This can cause grief in JSF, where the URL you use isn't always the one primarily attached to the View in question.

The third thing to realize - and this is probably where your problem lies - is that BASIC security is tied to your browser. There's really no way to log out of a BASIC security session except to shut down your browser. Not even closing the application window is sufficient.

This last item is one of several reasons why most J2EE container-secured apps use FORM based authentication instead of BASIC authentication.

[Sarah Timberlake]

@Alejandro...

I have developed a logout feature in the JSF 2.0 but without SSL . what I did was to invalidate the session and return it back to the home page . It has worked fine so far...

public String logoutUser() {
try {
HttpSession session = getRequest().getSession(true);
session.invalidate();
loggedIn = false;
} catch (Exception e) {
logger.log(Level.SEVERE, "Exception " + e);
}
return "homepage";
}

Here , I have an extra flag called loggedIn to make sure if the user is still logged in .

Hope it helps .

:-)

[Tim Holloway]

Welcome to the JavaRanch, Sarah!

Alejandro is using J2EE's built-in Container Manager security system. It is always possible to tell if you're logged in under this system by simply looking at the HttpServletRequest. If the userId and UserPrincipal properties are null, the user is not logged in. Otherwise, the user is logged in. These properties operate in parallel, so when one is null, so is the other.

Your sample code omits something critical, which is the location of your "loggedIn" variable. It obviously isn't in the session, since logging out destroys the session. If you implement it as a backing bean property, the backing bean has gone out of scope when the session is destroyed. If you put it in a static class, a single instance would apply for all users, which would be a serious issue if you have more than one person logged in at once. And if you put it in a class instance, it's probably going to be shared in a multi-threaded environment, which leads to basically the same problem as putting it in a static class.

[Sarah Timberlake]

Thanks Tim...
well thats true ... may be something can be done in Session Listener...

public void sessionDestroyed(HttpSessionEvent se) {
HttpSession session = se.getSession();
// codes here...
}

I believe the data can be collected here just before the session is destroyed... I am focusing more on how not to let the user go back into the previous loggedin mode after the logout (ofcourse it has some tradeoffs)
and I am totally with you on "There's really no way to log out of a BASIC security session except to shut down your browser".

Thanks

[Sarah Timberlake]

One more option ... instead of using managedBean we can use ejb session bean as a one in JSF 2.0 and EJB 3.1 . That way , we don't need to go through managedbean at all and hence can get rid of the abovementioned shortcomings ....

[Fidel Alejandro Torrealba V]

Hi!!! Thank you so much for all your answers.

I took some days off... and did not reply this thread.

I just want to share my solution.

Basic authentication is bound to the browser, and once you have done login, should should close the browser to finish the logoff... what is not so elegant.

I changed to FORM authentication, creating my form, and posting the user information to a servlet who validates the user credentials against my realm, and this servlet redirect the user to either the application or to an error page. Obviously the proper configuration ifor security-constrain in web.xml have to be done.

I am sharing my solution here:

Login page:

<!-- This is the login page that implement the "Form Base" login -->
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://java.sun.com/jsf/html">
    <h:head>
        <title>Login Form</title>
    </h:head>
    <h:body>
        <h2>Welcome to the secure messaging service!:</h2>
        <form name="loginForm" method="POST" action="j_security_check">
            <p><strong>Please type your user name: </strong>
                <input type="text" name="j_username" size="25" /></p>
            <p><strong>Please type your password: </strong>
                <input type="password" size="15" name="j_password" /></p>
            <p>
                <input type="submit" value="Submit"/>
                <input type="reset" value="Reset"/>
            </p>
        </form>
    </h:body>
</html>

My validation servlet method:

 protected void processRequest(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException {
    try {
            String username;
            String password;
            username = request.getParameter("j_username").toString();
            password = request.getParameter("j_password").toString();
            request.login(username, password);
            response.sendRedirect("/SecureMessageWebInterface/");
        } catch (Exception e) {
            response.sendRedirect("error.xhtml");
        }           
    }

And the required part of the configuration file....

    <security-constraint>
        <display-name>Web Interface</display-name>
        <web-resource-collection>
            <web-resource-name>SSL Pages</web-resource-name>
            <description/>
            <url-pattern>/</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <description>All site is restricted</description>
            <role-name>user</role-name>
        </auth-constraint>
        <user-data-constraint>
            <description>Secure connection is required</description>
            <transport-guarantee>CONFIDENTIAL</transport-guarantee>
        </user-data-constraint>
    </security-constraint>
    <login-config>
        <auth-method>FORM</auth-method>
        <realm-name>webapps</realm-name>
        <form-login-config>
            <form-login-page>/login.xhtml</form-login-page>
            <form-error-page>/error.xhtml</form-error-page>
        </form-login-config>
    </login-config>

I hope this can be useful for someone else.

All the best,

Alejandro.