Spring Security
  1. Spring Security
  2. SEC-1020

PreAuthenticatedProcessingFilter using session attributes

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: 3.0.0 M1
    • Component/s: Core
    • Labels:
      None

      Description

      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

      <bean id="postSignupFilter" class="org.springframework.security.ui.preauth.SessionPreAuthenticatedProcessingFilter">
      <security:custom-filter position="PRE_AUTH_FILTER" />
      <property name="principalSessionAttribute" value="PRE_AUTH_FILTER_PRINCIPAL"/>
      <property name="authenticationManager" ref="authenticationManager" />
      </bean>

      <bean id="preauthAuthProvider" class="org.springframework.security.providers.preauth.PreAuthenticatedAuthenticationProvider">
      <security:custom-authentication-provider />
      <property name="preAuthenticatedUserDetailsService">
      <bean id="userDetailsServiceWrapper"
      class="org.springframework.security.userdetails.UserDetailsByNameServiceWrapper">
      <property name="userDetailsService" ref="userDetailsService"/>
      </bean>
      </property>
      </bean>

      <security:authentication-manager alias="authenticationManager" />

      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.
      • <p>
      • 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.
      • <p>
      • The property <tt>principalRequestHeader</tt> 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 <tt>principalSessionAttribute</tt> 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 <tt>credentialsRequestHeader</tt> 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; }

      }

        Activity

        Hide
        Luke Taylor added a comment -

        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.

        Show
        Luke Taylor added a comment - 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.

          People

          • Assignee:
            Luke Taylor
            Reporter:
            Andrew McCall
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: