Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

SEC-1020: PreAuthenticatedProcessingFilter using session attributes #1273

spring-issuemaster opened this Issue Oct 24, 2008 · 1 comment


None yet
1 participant

Andrew McCall(Migrated from SEC-1020) said:

I’ve created a PreAuthenticatedProcessingFilter allowing a user to login using a session attribute, it’s heavily based on the existing RequestHeaderPreAuthenticatedProcessingFilter.

The filter is useful if you’ve already authenticated a user, in my own projects I’ve been using it to automatically log a user in once they’ve completed a signup process. Since I already know who they are.

Usage is very similar to the site minder configuration from the reference manual

The code is below, I’m happy to supply it as a patch, or in alternate format if required.

package org.springframework.security.ui.preauth

import org.springframework.security.ui.preauth.AbstractPreAuthenticatedProcessingFilter;
import org.springframework.security.ui.preauth.PreAuthenticatedCredentialsNotFoundException;
import org.springframework.security.ui.FilterChainOrder;

import javax.servlet.http.HttpServletRequest;

- A simple pre-authenticated filter which obtains the username from a session attribute.

- As with most pre-authenticated scenarios, it is essential that the external authentication system is set up
- correctly as this filter does no authentication whatsoever. All the protection is assumed to be provided externally
- and if this filter is included inappropriately in a configuration, it would be possible to assume the
- identity of a user merely by setting the correct header name. This also means it should not be used in combination
- with other Spring Security authentication mechanisms such as form login, as this would imply there was a means of
- bypassing the external system which would be risky.

- The property principalRequestHeader is the name of the request header that contains the username. It
- defaults to “PRE_AUTH_PRINCIPAL”.
- @author Andrew McCall
public class SessionPreAuthenticatedProcessingFilter extends AbstractPreAuthenticatedProcessingFilter {

private String principalSessionAttribute = “PRE_AUTH_FILTER_PRINCIPAL”; private String credentialsSessionAttribute; /** - Read, clear and returns the session attribute named by principalSessionAttribute from the request. * - @throws PreAuthenticatedCredentialsNotFoundException if the header is missing */ protected Object getPreAuthenticatedPrincipal(HttpServletRequest httpServletRequest) { Object principal = httpServletRequest.getSession().getAttribute(principalSessionAttribute); httpServletRequest.getSession().setAttribute(principalSessionAttribute, null); return principal; } /** - Credentials aren’t usually applicable, but if a credentialsRequestHeader is set, this - will be read and used as the credentials value. Otherwise a dummy value will be used. */ protected Object getPreAuthenticatedCredentials(HttpServletRequest httpServletRequest) { if (credentialsSessionAttribute != null) { Object credentials = httpServletRequest.getSession().getAttribute(credentialsSessionAttribute); return credentials; } return “N/A”; } public int getOrder() { return FilterChainOrder.PRE_AUTH_FILTER; } public void setPrincipalSessionAttribute(String principalSessionAttribute) { this.principalSessionAttribute = principalSessionAttribute; } public void setCredentialsSessionAttribute(String credentialsSessionAttribute) { this.credentialsSessionAttribute = credentialsSessionAttribute; } }

Luke Taylor said:

Thanks for the contribution, but I don’t really think this would really add much to the codebase. If you have the ability to set a session attribute, then you can generally also set the current authentication object as part of the process (authentication the user immediately), rather than setting up al pre-authentication configuration which seems like overkill.

in any case, the pre-authentication code is really intended for user’s to extend according to their requirements rather than to provide all possible configuration scenarios out of the box. We are trying to avoid adding code unnecessarily these days where it is easy for the user to provide their own customization.

@spring-issuemaster spring-issuemaster added this to the 3.0.0 M1 milestone Feb 5, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment