PreAuthentication - Auth Success

[TerpInMD]

Hello,

The form based authentications have a nice hook into them to route the user to a default url once authenticated.

http://static.springsource.org/sprin...-flow-handling

I am looking for, but not finding something similar for the pre authentication filters. These do not have the configurable setAuthenticationSuccessHandler methods.

Once users are authenticated (via site minder), I want them routed to the application root, not to the url with the query string. There are various reasons that I want them to goto the root of the app.


One other question (while I am at it )... are there any suggestions on how to integrate a form based authentication (for development purposes) as well as pre authentication configuration? Can I just wire up multiple providers, with the form based provider returning a null Authentication object if the environment is local development?

See:

http://static.springsource.org/sprin...-services.html

Thanks!

[TerpInMD]

Got it all working. It would be nice if there was a hook into the preauth filters like some of the other for authentication success / failure events. Other than that it really goes together nicely and isn't too difficult (looking back on it anyway ).

[Rob Winch]

I am looking for, but not finding something similar for the pre authentication filters. These do not have the configurable setAuthenticationSuccessHandler methods.

Once users are authenticated (via site minder), I want them routed to the application root, not to the url with the query string. There are various reasons that I want them to goto the root of the app.

You can override the successfulAuthentication method and delegate to an AuthenticationSuccessHandler. Don't forget to call the superclass.

One other question (while I am at it )... are there any suggestions on how to integrate a form based authentication (for development purposes) as well as pre authentication configuration? Can I just wire up multiple providers, with the form based provider returning a null Authentication object if the environment is local development?

I would have two different configurations in your application. For dev add the dev profile to your web.xml application contexts and for prod add the prod configuration to the web.xml I wouldn't leave the dev configuration for production as this could potentially be used to bypass security. Similar to Grails, Spring 3.1 is going to introduce profiles that can be activated in different ways which should help with this.

[TerpInMD]

Thanks for your reply. Its actually not a security concern because if user somehow made it past site minder w/o credentials, the login form would stop them because there is no username/password combo that would get them past the login form....so its actually extra security (unintended)!

I was able to do what I wanted do via successfulAuthentication, though a hook into defaultTargetURL or something of the sorts would be a great addition to AbstractPreAuthenticatedProcessingFilter.

[Rob Winch]

Thanks for your reply. Its actually not a security concern because if user somehow made it past site minder w/o credentials, the login form would stop them because there is no username/password combo that would get them past the login form....so its actually extra security (unintended).

While you are right that the application is secured by putting it behind Siteminder, I view it as another attack surface. Reducing attack surface is all about preventing attacks that were not thought about. This is the same reason that you layer security. For example, if a URL was not marked as requiring security in Siteminder or somehow an attacker tricked Siteminder to think the url didn't need to be secured. Siteminder would let the request through but the principalRequestHeader (i.e. SM_USER) is still removed. If you setup the production Spring Security to fail if the header is not there, then you have reduced the attack surface. If you have the login form in production environment it will not even get triggered if the header is present so it doesn't add more security. Additionally, it presents another opportunity for the attacker to login (i.e. knowing the dev credentials).