How to manually set an authenticated user in Spring Security / SpringMVC

Question

After a new user submits a 'New account' form, I want to manually log that user in so they don't have to login on the subsequent page.

The normal form login page going through the spring security interceptor works just fine.

In the new-account-form controller I am creating a UsernamePasswordAuthenticationToken and setting it in the SecurityContext manually:

SecurityContextHolder.getContext().setAuthentication(authentication);

On that same page I later check that the user is logged in with:

SecurityContextHolder.getContext().getAuthentication().getAuthorities();

This returns the authorities I set earlier in the authentication. All is well.

But when this same code is called on the very next page I load, the authentication token is just UserAnonymous.

I'm not clear why it did not keep the authentication I set on the previous request. Any thoughts?

Could it have to do with session ID's not being set up correctly?
Is there something that is possibly overwriting my authentication somehow?
Perhaps I just need another step to save the authentication?
Or is there something I need to do to declare the authentication across the whole session rather than a single request somehow?

Just looking for some thoughts that might help me see what's happening here.

You can follow my answer to http://stackoverflow.com/questions/4824395/spring-security-forward-directive-cant-forward-to-login-form/7972971#7972971 — AlexK, Nov 01 '11 at 21:17
Readers, beware of the answers to this question if they tell you to do: `SecurityContextHolder.getContext().setAuthentication(authentication)`. It works, and is common, but there are serious functionality shortcomings that you will meet if you just do that. For more info, see my question, and the answer: https://stackoverflow.com/questions/47233187/spring-security-manual-login-best-practice — goat, Nov 28 '17 at 02:47
Here is a related issue: https://stackoverflow.com/questions/69681254/how-to-configure-springboot-authentication-for-restcontroller — Mircea Lutic, Oct 22 '21 at 18:06
Here is a related issue: https://stackoverflow.com/questions/69681254/how-to-configure-springboot-authentication-for-restcontroller — Mircea Lutic, Oct 22 '21 at 18:07

score 77 · Answer 1 · edited Jan 30 '23 at 14:52

77

I couldn't find any other full solutions so I thought I would post mine. This may be a bit of a hack, but it resolved the issue to the above problem:

    @Autowired
    AuthenticationServiceImpl authenticationManager;

    public void login(HttpServletRequest request, String userName, String password) {
    
        UsernamePasswordAuthenticationToken authRequest = new UsernamePasswordAuthenticationToken(userName, password);

        // Authenticate the user
        Authentication authentication = authenticationManager.authenticate(authRequest);
        SecurityContext securityContext = SecurityContextHolder.getContext();
        securityContext.setAuthentication(authentication);

        // Create a new session and add the security context.
        HttpSession session = request.getSession(true);
        session.setAttribute("SPRING_SECURITY_CONTEXT", securityContext);
    }

edited Jan 30 '23 at 14:52

James Jithin

10,183
5
36
51

answered Dec 01 '11 at 03:34

Stuart McIntyre

918
6
8

7

+1 - This helped me! I was missing the SPRING_SECURITY_CONTEXT update. ...But how "dirty" is this? – l3dx Nov 01 '12 at 17:12
21

where do you get `authenticationManager` from? – Isaac Nov 16 '12 at 19:05
2

authenticationManager is autowired in your class like this @Autowired AuthenticationServiceImpl authenticationManager. And there must also be a bean injection in your xml configuration, so Spring knows what to inject. – Sep 12 '13 at 10:30
@Is7aq You could just auto wire it. – Venugopal Madathil Jul 10 '14 at 10:23
1

where is the implementation of AuthenticationServiceImpl ? What does this class holds? – PAA Apr 14 '15 at 13:45
4

Why is it necessary to create a new session? Doesn't SecurityContext handle that? – Vlad Manuel Mureșan Mar 16 '16 at 14:37
@VladManuelMureșan Manual SecurityContext creation does not automatically configure the session. see David Parks answer – coderatchet May 25 '17 at 23:53
1

I did not need to muck with the session using `SPRING_SECURITY_CONTEXT`. `securityContext.setAuthentication()` was enough – goat Nov 10 '17 at 23:03
3

I think people should be aware that doing this manual login via `setAuthentication()` bypasses some of the spring stuff, such as enforcing maximum concurrent sessions limit for a user, changing the users session id upon login to prevent session fixation, automatic registration of the session into a `SessionRegistry`, and maybe more. – goat Nov 10 '17 at 23:42
"SecurityContext securityContext = SecurityContextHolder.getContext().setAuthentication(null);" doing this will logout the user ? – Youssef Boudaya Jun 15 '21 at 14:16

score 67 · Accepted Answer · answered Jan 12 '11 at 17:48

I had the same problem as you a while back. I can't remember the details but the following code got things working for me. This code is used within a Spring Webflow flow, hence the RequestContext and ExternalContext classes. But the part that is most relevant to you is the doAutoLogin method.

public String registerUser(UserRegistrationFormBean userRegistrationFormBean,
                           RequestContext requestContext,
                           ExternalContext externalContext) {

    try {
        Locale userLocale = requestContext.getExternalContext().getLocale();
        this.userService.createNewUser(userRegistrationFormBean, userLocale, Constants.SYSTEM_USER_ID);
        String emailAddress = userRegistrationFormBean.getChooseEmailAddressFormBean().getEmailAddress();
        String password = userRegistrationFormBean.getChoosePasswordFormBean().getPassword();
        doAutoLogin(emailAddress, password, (HttpServletRequest) externalContext.getNativeRequest());
        return "success";

    } catch (EmailAddressNotUniqueException e) {
        MessageResolver messageResolvable 
                = new MessageBuilder().error()
                                      .source(UserRegistrationFormBean.PROPERTYNAME_EMAIL_ADDRESS)
                                      .code("userRegistration.emailAddress.not.unique")
                                      .build();
        requestContext.getMessageContext().addMessage(messageResolvable);
        return "error";
    }

}


private void doAutoLogin(String username, String password, HttpServletRequest request) {

    try {
        // Must be called from request filtered by Spring Security, otherwise SecurityContextHolder is not updated
        UsernamePasswordAuthenticationToken token = new UsernamePasswordAuthenticationToken(username, password);
        token.setDetails(new WebAuthenticationDetails(request));
        Authentication authentication = this.authenticationProvider.authenticate(token);
        logger.debug("Logging in with [{}]", authentication.getPrincipal());
        SecurityContextHolder.getContext().setAuthentication(authentication);
    } catch (Exception e) {
        SecurityContextHolder.getContext().setAuthentication(null);
        logger.error("Failure in autoLogin", e);
    }

}

Thank you, the code is very helpful in helping me know that I'm troubleshooting in the right area. Looks like I have a smoking gun, it's creating a new session id after the manual authentication, but the old session id is still being identified from the cookie. Gotta figure out why now, but at least I'm clearly on track. Thanks! — David Parks, Jan 13 '11 at 00:47
Anyone following this guidance should also see this related issue: http://stackoverflow.com/questions/4824395/spring-security-forward-directive-cant-forward-to-login-form — David Parks, Jan 31 '11 at 10:51
Can you please explain that how you are getting authenticationProvider — vivex, May 08 '15 at 05:28
@DavidParks did you ever find out a full solution? YOur comment on here is exactly the issue we are facing. — Scott Allen, Jul 27 '16 at 12:07
@Vivek Did you understand how to get `authenticationProvider`? — s1moner3d, Nov 18 '16 at 09:53
@s1moner3d you should be able to get it injected via IoC -> \@Autowired — Hartmut, Dec 12 '16 at 11:07
`@Configuration public class WebConfig extends WebSecurityConfigurerAdapter { @Bean @Override public AuthenticationManager authenticationProvider() throws Exception { return super.authenticationManagerBean(); } }` — slisnychyi, Aug 13 '19 at 20:14

score 20 · Answer 3 · answered Jan 13 '11 at 01:57

20

Ultimately figured out the root of the problem.

When I create the security context manually no session object is created. Only when the request finishes processing does the Spring Security mechanism realize that the session object is null (when it tries to store the security context to the session after the request has been processed).

At the end of the request Spring Security creates a new session object and session ID. However this new session ID never makes it to the browser because it occurs at the end of the request, after the response to the browser has been made. This causes the new session ID (and hence the Security context containing my manually logged on user) to be lost when the next request contains the previous session ID.

answered Jan 13 '11 at 01:57

David Parks

30,789
47
185
328

6

Honestly this feels like a design flaw in spring security more than anything. There are plenty of frameworks written in other languages that would have no problem with this, but Spring Security just breaks. – chubbsondubs Dec 11 '12 at 22:37
5

and the solution is? – s1moner3d Nov 18 '16 at 14:26
3

and what is the solution? – Thiago May 05 '17 at 19:59
One working solution in @KevinS answer above (see the code after the "Create a new session and add the security context." comment) – Rolch2015 Jun 10 '23 at 22:35

Stephen C · Answer 4 · 2011-12-01T03:48:22.547

5

Turn on debug logging to get a better picture of what is going on.

You can tell if the session cookies are being set by using a browser-side debugger to look at the headers returned in HTTP responses. (There are other ways too.)

One possibility is that SpringSecurity is setting secure session cookies, and your next page requested has an "http" URL instead of an "https" URL. (The browser won't send a secure cookie for an "http" URL.)

edited Dec 01 '11 at 03:48

answered Jan 12 '11 at 03:10

Stephen C

698,415
94
811
1,216

Thanks these were all very helpful and relevant suggestions! – David Parks Jan 13 '11 at 00:48

score 5 · Answer 5 · edited Feb 27 '18 at 07:32

The new filtering feature in Servlet 2.4 basically alleviates the restriction that filters can only operate in the request flow before and after the actual request processing by the application server. Instead, Servlet 2.4 filters can now interact with the request dispatcher at every dispatch point. This means that when a Web resource forwards a request to another resource (for instance, a servlet forwarding the request to a JSP page in the same application), a filter can be operating before the request is handled by the targeted resource. It also means that should a Web resource include the output or function from other Web resources (for instance, a JSP page including the output from multiple other JSP pages), Servlet 2.4 filters can work before and after each of the included resources. .

To turn on that feature you need:

web.xml

<filter>   
    <filter-name>springSecurityFilterChain</filter-name>   
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class> 
</filter>  
<filter-mapping>   
    <filter-name>springSecurityFilterChain</filter-name>   
    <url-pattern>/<strike>*</strike></url-pattern>
    <dispatcher>REQUEST</dispatcher>
    <dispatcher>FORWARD</dispatcher>
</filter-mapping>

RegistrationController

return "forward:/login?j_username=" + registrationModel.getUserEmail()
        + "&j_password=" + registrationModel.getPassword();

Good info, but putting the username and password into the url is bad. 1) no escaping is done, so a username or password with special character is likely to break, or even worse, be used as a security exploit vector. 2) passwords in urls are bad because urls often get logged to disk, which is pretty bad for security - all your passwords in plaintext just sitting there. — goat, Jan 11 '19 at 18:20

JonnyRaa · Answer 6 · 2014-06-19T11:26:10.633

I was trying to test an extjs application and after sucessfully setting a testingAuthenticationToken this suddenly stopped working with no obvious cause.

I couldn't get the above answers to work so my solution was to skip out this bit of spring in the test environment. I introduced a seam around spring like this:

public class SpringUserAccessor implements UserAccessor
{
    @Override
    public User getUser()
    {
        SecurityContext context = SecurityContextHolder.getContext();
        Authentication authentication = context.getAuthentication();
        return (User) authentication.getPrincipal();
    }
}

User is a custom type here.

I'm then wrapping it in a class which just has an option for the test code to switch spring out.

public class CurrentUserAccessor
{
    private static UserAccessor _accessor;

    public CurrentUserAccessor()
    {
        _accessor = new SpringUserAccessor();
    }

    public User getUser()
    {
        return _accessor.getUser();
    }

    public static void UseTestingAccessor(User user)
    {
        _accessor = new TestUserAccessor(user);
    }
}

The test version just looks like this:

public class TestUserAccessor implements UserAccessor
{
    private static User _user;

    public TestUserAccessor(User user)
    {
        _user = user;
    }

    @Override
    public User getUser()
    {
        return _user;
    }
}

In the calling code I'm still using a proper user loaded from the database:

    User user = (User) _userService.loadUserByUsername(username);
    CurrentUserAccessor.UseTestingAccessor(user);

Obviously this wont be suitable if you actually need to use the security but I'm running with a no-security setup for the testing deployment. I thought someone else might run into a similar situation. This is a pattern I've used for mocking out static dependencies before. The other alternative is you can maintain the staticness of the wrapper class but I prefer this one as the dependencies of the code are more explicit since you have to pass CurrentUserAccessor into classes where it is required.

why not just disable security in test env, if that's what you intend to do — eis, Jun 03 '21 at 11:25

How to manually set an authenticated user in Spring Security / SpringMVC

6 Answers6

Linked