Hacks using Programmatic Security for a SpringMVC application

[boomkap]

I have implemented programmatic security by reading through the docs and the forums when I ran into issues.

Everything seems to be working fine but one thing is still bothering me.

In my controller, I am using the following calls.

Authentication auth = new AppAuthentication(accessToken);
SecurityContextHolder.getContext().setAuthenticati on(auth);

//AppAuthentication is my custom implementation of the Authentication Interface.

If I do not set the Authentication Context for the current user in the HTTP session, the context is not available to me on subsequent calls.

HttpSession session = request.getSession();
session.setAttribute("SPRING_SECURITY_CONTEXT", SecurityContextHolder.getContext());

Is this the intended approach or more of a hack? What would be preferred approach in this case?

[thobson]

What exactly are you trying to achieve with your custom implementation? If you tell us some more about your overall goals we can recommend an approach.

[boomkap]

The authentication provider is an external system for which I am using OAUTH to authenticate & authorize. I do all of the OAUTH communication in my controller. Once the user is successfully authenticated & authorized externally, I need to make Spring aware of the authenticated user along with any roles I define so I can use the spring security model through out the application.

[Rob Winch]

What does your security configuration look like? If you invoke SecurityContextHolder.getContext().setAuthenticati on(...) on a URL that is not viewed by Spring Security, then it does not get persisted to session automatically. For example, if you are using <http security="none"> (Spring Security 3.2) or <intercept-url filters="none"> (Spring Security 3.1) it will not be persisted by the SecurityContextPersistenceFilter since Spring Security is disabled for that URL. Instead, you should map the URL you are performing authentication to "permitAll" (when use-expressions="true") or "ROLE_ANONYMOUS" (when use-expressions="false").

[boomkap]

Ok, now this is beginning to make some sense. As i was thinking the same thing from the containers perspective.

So for the URL (in this case /signup) that the user submits the data to, I have security set to <security:http pattern="/signup" security="none" />
My thought of having it setup as none was because i thought the container would apply security to that URL in effect defecting the purpose of the URL. But now i see how the option can be defined to allow a permit all on that.
So if i change to - <security:intercept-url pattern="/twitterSignup" access="permitAll" /> you think i do not need to use the lines
HttpSession session = request.getSession();
session.setAttribute("SPRING_SECURITY_CONTEXT", SecurityContextHolder.getContext());

[Rob Winch]

So if i change to - <security:intercept-url pattern="/twitterSignup" access="permitAll" /> you think i do not need to use the lines
HttpSession session = request.getSession();
session.setAttribute("SPRING_SECURITY_CONTEXT", SecurityContextHolder.getContext());

Correct. It sounds like you will have this setup after this change, but if you want more details this presentation discusses how to do signup in Spring Security. Alternatively, you can refer to the SecureMail application that the presentation uses.