OcpSoft » Spring

Spring Security – What happens after /you/ log in?

Lincoln — Fri, 24 Jul 2009 02:23:59 +0000

So you’ve got Spring Security up and running. Great! Now you’ve got a login page, and you just added a form on the global page menu to allow users to Login from any public page. There’s just one problem. When they log-in from a public page, they’re redirected to the default-login-url! Your users will have to re-navigate to the page they were already viewing when they logged in, or maybe they’ll just use the much dreaded “Back” button. That’s not a good interaction, but we have a solution.

UPDATE: There is a simpler, but less complete solution built in. (See here.) This means appending “?spring-security-redirect=/your/target/url” to your redirect to the Spring Security Filter chain.

Need some /pretty /urls in your JSF web-app? Try PrettyFaces: URL-rewriting for Java EE and JSF. (Free and open-source!)

If you have not already completed integrating Spring Security and JSF, please consider it, as this article depends on having a working JSF login page and managed bean.

Note: This approach will not work if you are invalidating/re-creating the session after a successful authentication (see Session Fixation attacks). Supporting session invalidation would take some extra work that will not be in the scope of this article.

The login form

Here is a basic JSF/Spring Security login form. It would be nice if we could enable or disable the redirect functionality, so we’ll add a hidden form field that is only rendered on demand (here we use Facelets ui:param functionality for our on-off switch.)

 prependId="false">
     test="#{redirect == 'true'}">
         type="hidden" name="redirect" value="true" />
    >
    
     for="j_username"> value="Username:" />
        for="j_username" /> />
    >
     id="j_username" value="#{loginBean.username}"
        required="true" />
 
     />
     />
     for="j_password"> value="Password:" />
        for="j_password" /> />
    >
     id="j_password" value="#{loginBean.password}"
        required="true" />
 
     />
     />
     for="_spring_security_remember_me">
        value="Remember me" /> >
     id="_spring_security_remember_me"
        value="#{loginBean.rememberMe}" />
     />
 
     type="submit" id="login"
        action="#{loginBean.doLogin}" value="Login" />
 
     type="submit" styleClass="faded" id="cancel"
        action="#{loginBean.doCancel}" value="Cancel" immediate="true" />
     />
     />
>

The login action method

First, check to make sure that we actually want to do a redirect after login. Do this by testing for the existence of our hidden form parameter.

Find the full LoginBean code here.

public String doLogin() throws IOException, ServletException
{
    String redirect = FacesUtils.getRequestParameter("redirect");
    if ((redirect != null) && !redirect.isEmpty())
    {
        redirect = PrettyContext.getCurrentInstance().getOriginalRequestUrl();
        Map<String, Object> sessionMap = FacesContext.getCurrentInstance().getExternalContext().getSessionMap();
        sessionMap.put(LoginRedirectFilter.LAST_URL_REDIRECT_KEY, redirect);
    }
    FacesUtils.getExternalContext().dispatch("/j_spring_security_check");
    FacesUtils.getFacesContext().responseComplete();
    return null;
}

Before forwarding to the Spring Security /j_security_login_check intercepting filter chain, we’ll need to set the current URL into a Session attribute: “LoginRedirectFilter.LAST_URL_REDIRECT_KEY”.

This will be used in our custom filter after the user successfully authenticates with Spring Security.

The login filter

Here is where we’ll check for the existence of our session attribute: “LAST_URL_REDIRECT_KEY”. If this key contains a value, then we should redirect the user to that URL. If the key does not contain a value, then we should not perform any redirect, and continue as normal.

One other concern is: what if authentication failed? Let’s assume that Spring Security will redirect the user to the Login Page if they send invalid credentials. We don’t want to trigger a redirect as they try to access the login page, so we also check to make sure we have a successfully authenticated user before redirecting.

import java.io.IOException;
 
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
 
import org.springframework.security.authentication.AnonymousAuthenticationToken;
import org.springframework.security.core.Authentication;
import org.springframework.security.core.context.SecurityContext;
import org.springframework.security.core.context.SecurityContextHolder;
import org.springframework.stereotype.Component;
 
@Component
public class LoginRedirectFilter implements Filter
{
    public static final String LAST_URL_REDIRECT_KEY = LoginRedirectFilter.class.getName() + "LAST_URL_REDIRECT_KEY";
 
    @Override
    public void destroy()
    {}
 
    @Override
    public void doFilter(final ServletRequest request, final ServletResponse response, final FilterChain chain)
            throws IOException, ServletException
    {
        HttpSession session = ((HttpServletRequest) request).getSession();
        String redirectUrl = (String) session.getAttribute(LAST_URL_REDIRECT_KEY);
        if (isAuthenticated() && (redirectUrl != null) && !redirectUrl.isEmpty())
        {
            session.removeAttribute(LAST_URL_REDIRECT_KEY);
            HttpServletResponse resp = (HttpServletResponse) response;
            resp.sendRedirect(redirectUrl);
        }
        else
        {
            chain.doFilter(request, response);
        }
    }
 
    private boolean isAuthenticated()
    {
        boolean result = false;
        SecurityContext context = SecurityContextHolder.getContext();
        if (context instanceof SecurityContext)
        {
            Authentication authentication = context.getAuthentication();
            if (authentication instanceof AnonymousAuthenticationToken)
            {
                // not authenticated
            }
            else if (authentication instanceof Authentication)
            {
                result = true;
            }
        }
        return result;
    }
 
    @Override
    public void init(final FilterConfig filterConfig) throws ServletException
    {}
}

Web.xml

Some specific configuration is required to ensure the proper ordering of our filters. LoginRedirectFilter’s filter-mapping must be placed after any Spring Security filters – otherwise we will redirect too soon, and authentication will never occur. You probably want to place it before any filters that apply business logic.

>
    >loginRedirectFilter>
    >org.springframework.web.filter.DelegatingFilterProxy>
>
>
    >loginRedirectFilter>
    >/*>
>

Putting it all together

This sequence diagram describes the entire process, including what Spring Security will be doing after intercepting the /j_security_check forwarded from LoginBean:
You should now have a functional LoginRedirectFilter configured in tandem with Spring Security. Please feel free to post any suggestions or questions.

Revisited – Acegi/Spring Security & JSF Login Page

Lincoln — Mon, 27 Apr 2009 22:00:07 +0000

A correction has been made to the post: http://ocpsoft.com/java/acegi-spring-security-jsf-login-page/, fixing an issue where FacesMessages were not being displayed on failed authentications.

Because the example had initially used the @PostConstruct annotation to trigger a method to handle the error message, the handleError() method was being called before the actual authentication event had taken place, thus, the handleError() method was triggering before any BadCredentialsExceptions were stored in the Session.

Instead of creating an error handling method in the LoginBean itself, instead attach a PhaseListener which will intercept failed logins, and add the new FacesMessage before the RENDER_RESPONSE phase.

LoginErrorPhaseListener

import javax.faces.context.FacesContext;
import javax.faces.event.PhaseEvent;
import javax.faces.event.PhaseId;
import javax.faces.event.PhaseListener;
 
import org.springframework.security.BadCredentialsException;
import org.springframework.security.ui.AbstractProcessingFilter;
 
impot util.FacesUtils;
 
public class LoginErrorPhaseListener implements PhaseListener
{
    private static final long serialVersionUID = -1216620620302322995L;
 
    @Override
    public void beforePhase(final PhaseEvent arg0)
    {
        Exception e = (Exception) FacesContext.getCurrentInstance().getExternalContext().getSessionMap().get(
                AbstractProcessingFilter.SPRING_SECURITY_LAST_EXCEPTION_KEY);
 
        if (e instanceof BadCredentialsException)
        {
            FacesContext.getCurrentInstance().getExternalContext().getSessionMap().put(
                    AbstractProcessingFilter.SPRING_SECURITY_LAST_EXCEPTION_KEY, null);
            FacesUtils.addErrorMessage("Username or password not valid.");
        }
    }
 
    @Override
    public void afterPhase(final PhaseEvent arg0)
    {}
 
    @Override
    public PhaseId getPhaseId()
    {
        return PhaseId.RENDER_RESPONSE;
    }
 
}

faces-config.xml

 version="1.0" encoding="UTF-8"?>
 version="1.2" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xi="http://www.w3.org/2001/XInclude"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd">
	>
		>login.LoginErrorPhaseListener>
	>
>

Happy developing!

Acegi/Spring Security JSF Integration Project continued

Derek — Fri, 17 Oct 2008 02:17:19 +0000

We’ve gotten a good number of comments from Lincoln’s latest post on Spring Security and JSF. A few comments have asked for further code samples on how to get this example working.

We created a runnable project for this example, and it can be downloaded here.

All you need to do is extract the project to your workspace (We use Eclipse), and import the project. Add the project to your server and start it up. Next open your browser and navigate to:

http://localhost:8080/springsecurity/

Note*: You’ll need to change the URL to your server port number if it isn’t set to 8080.

Assuming all the steps above worked successfully you should see a page like the one below.

Now click on the Secret link. This should force you to the login page. The Secret page requires authentication to view. Go ahead and type in the User: rod Password: koala

You should now be redirected to the Secret page (shown below).

Go back to the Home page and try Logout, and Login with bad credentials and see what you get. I hope this project helps to tie up any loose ends, and helps answer any outstanding questions.

Acegi/Spring Security Integration – JSF Login Page

Lincoln — Fri, 10 Oct 2008 00:35:33 +0000

Tutorials – What a nightmare

Everyone seems to be going through hell to get a fully functional JSF login page working with Spring Security (formerly Acegi,) and yes, I did too, but there’s an EASY way to make this happen. And get this:

It takes just five clear and well written lines of Java code.

First, the solution. Afterwards, the dirty details. (Spring 2.5.2 was used for this example.)
You can find a downloadable working example here. There is also a followup article on post-authentication redirecting, here.

Need some /pretty /urls in your JSF web-app? Try PrettyFaces: URL-rewriting for Java EE and JSF. (Free and open-source!)

The Solution:

public class LoginBean
{
    //managed properties for the login page, username/password/etc...
 
    // This is the action method called when the user clicks the "login" button
    public String doLogin() throws IOException, ServletException
    {
        ExternalContext context = FacesContext.getCurrentInstance().getExternalContext();
 
        RequestDispatcher dispatcher = ((ServletRequest) context.getRequest())
                 .getRequestDispatcher("/j_spring_security_check");
 
        dispatcher.forward((ServletRequest) context.getRequest(),
                (ServletResponse) context.getResponse());
 
        FacesContext.getCurrentInstance().responseComplete();
        // It's OK to return null here because Faces is just going to exit.
        return null;
    }
}

—-

For anyone who was struggling because Spring Security requires you to use a Filter to intercept the login postback, thus either preventing you from being able to do JSF style validation, or visa-versa, creating a scenario where JSF can process results, but blocks Acegi from processing the request parameters.

Simply use an HttpRequestDispatcher to allow both JSf and Spring Security to function one after another. JSF goes first, then delegates work to a Spring Security (thus preserving any request parameters that Spring Security is looking for.) After forwarding, tell JSF you have finished, and not to do any more work, immediately stop processing.

If the login credentials were bad, redirect to the Login page. If the credentials were good, redirect to the requested URL. You can even show a dynamic message for bad credentials. Add the following PhaseListener to your faces-config.xml in order to extract any login errors, and display a message to the user:

import javax.faces.context.FacesContext;
import javax.faces.event.PhaseEvent;
import javax.faces.event.PhaseId;
import javax.faces.event.PhaseListener;
 
import org.springframework.security.BadCredentialsException;
import org.springframework.security.ui.AbstractProcessingFilter;
 
import uk.co.pkit.project.view.util.FacesUtils;
 
public class LoginErrorPhaseListener implements PhaseListener
{
    private static final long serialVersionUID = -1216620620302322995L;
 
    @Override
    public void beforePhase(final PhaseEvent arg0)
    {
        Exception e = (Exception) FacesContext.getCurrentInstance().getExternalContext().getSessionMap().get(
                AbstractProcessingFilter.SPRING_SECURITY_LAST_EXCEPTION_KEY);
 
        if (e instanceof BadCredentialsException)
        {
            FacesContext.getCurrentInstance().getExternalContext().getSessionMap().put(
                    AbstractProcessingFilter.SPRING_SECURITY_LAST_EXCEPTION_KEY, null);
            FacesUtils.addErrorMessage("Username or password not valid.");
        }
    }
 
    @Override
    public void afterPhase(final PhaseEvent arg0)
    {}
 
    @Override
    public PhaseId getPhaseId()
    {
        return PhaseId.RENDER_RESPONSE;
    }
 
}

faces-config.xml

 version="1.0" encoding="UTF-8"?>
 version="1.2" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xi="http://www.w3.org/2001/XInclude"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd">
	>
		>login.LoginErrorPhaseListener>
	>
>

web.xml

You must configure your Spring Security Filter Chain to process Servlet FORWARD as well as REQUESTs.

	>
		>springSecurityFilterChain>
		>org.springframework.web.filter.DelegatingFilterProxy>
	>
	>
		>springSecurityFilterChain>
		>/*>
		>FORWARD>
		>REQUEST>
	>

—-

applicationContext-security.xml

As for the Spring Security configuration, everything can be left pretty standard. The relevant parts of my configuration, for example:

 version="1.0" encoding="UTF-8"?>
 

	xmlns="http://www.springframework.org/schema/security"
	xmlns:beans="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://www.springframework.org/schema/beans
                         http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
                        http://www.springframework.org/schema/security
                         http://www.springframework.org/schema/security/spring-security-2.0.1.xsd">
 
	
		secured-annotations="enabled">
	>
 
	
		auto-config="true"
		access-denied-page="/accessDenied.jsp">
 
		
			pattern="/login*"
			access="IS_AUTHENTICATED_ANONYMOUSLY" />
		
			pattern="/**"
			access="ROLE_USER,ROLE_ADMIN" />
 
		
			login-processing-url="/j_spring_security_check"
			login-page="/login"
			default-target-url="/"
			authentication-failure-url="/login" />
		 logout-url="/logout"
			logout-success-url="/" />
	>
 
	>
                
	>
>

—-

Notice here that the “login-processing-url” is set to “/j_spring_security_check”, which is the location where our HttpRequestDispatcher is going to forward to. You can call this whatever you want, but the two must match exactly.

login.xhtml / login.jspx / login.jsp

(Whatever you use as your JSF page content type, take your pick.)

So the last part of the puzzle is relatively easy. You need a JSF login page that conforms to Spring Security’s parameter naming requirements. When this page submits, its values will be forwarded to the Spring Security Filter Chain.

Notice that you don’t even need to tie the input field values to a JSF backing bean! The values only need to be intercepted by Spring Security on forward. However, if you want to do all that cool validation and stuff that JSF lets you do… go for it. I just wanted to save space in the article, and prove a point that it’s not needed.

 version="1.0" encoding="ISO-8859-1" ?>

	xmlns:jsp="http://java.sun.com/JSP/Page"
	xmlns:h="http://java.sun.com/jsf/html"
	xmlns:f="http://java.sun.com/jsf/core"
	version="2.0">
 
	>
		
			id="loginForm"
			prependId="false">
			 for="j_username"> value="Username:" /> />
			>
			
				id="j_username"
				required="true">
			>
 
			 />
			 />
			 for="j_password"> value="Password:" /> />
			>
			
				id="j_password"
				required="true">
			>
 
			 />
			 />
			 for="_spring_security_remember_me"> 
				value="Remember me" /> >
			
				id="_spring_security_remember_me" />
			 />
 
			
				type="submit"
				id="login"
				action="#{loginBean.doLogin}"
				value="Login" />
 
		>
	>
>

Remember that Spring Security is expecting parameters to be named as they are in this file. j_username, j_password, _spring_security_remember_me. Don’t change these ids unless you change your Spring configuration.

—-

If you’re having problems

Add a LoggerListener to allow Spring Security to print messages to your logging output. This will allow you to view any error messages that may be occurring. (Note: This should be copied verbatim)

	 id="loggerListener"
		class="org.springframework.security.event.authentication.LoggerListener" />

—-

Finished

And that’s all it took. A simple forward to a new servlet. No JSF navigation cases, no extra configuration. Just a little J2EE, and a night of no sleep. I hope this helps a LOT of people who seem to be struggling with the task of integrating these two excellent frameworks.

Considering the forces of this problem, we really required almost no invasiveness in our normal application logic. JSF does its validation and processing without being impacted by Acegi, and Acegi can perform its magic authentication without knowing that JSF was ever the provider of its parameters.

You can see a working example of this guide here.
Enjoy.

Example Authentication Provider for Testing

	
	>
		
			hash="md5" />
		>
			
				name="rod"
				password="a564de63c2d0da68cf47586ee05984d7"
				authorities="ROLE_SUPERVISOR, ROLE_USER, ROLE_TELLER" />
			
				name="dianne"
				password="65d15fe9156f9c4bbffd98085992a44e"
				authorities="ROLE_USER,ROLE_TELLER" />
			
				name="scott"
				password="2b58af6dddbd072ed27ffc86725d7d3a"
				authorities="ROLE_USER" />
			
				name="peter"
				password="22b5c9accc6e1ba628cedc63a72d57f8"
				authorities="ROLE_USER" />
		>
	>