View Full Version : Different authenticationDao for different URL Mappings
Nov 11th, 2004, 12:51 PM
Hello, I have a scenario where I have two types of users that need to be authenticated in different ways. User type A needs to be authenticated via Active Directory, and User Type B needs to be authenticated by a web service call. What I want to do is to have multiple url mappings and a different authenticationDao associated with each mapping.
Is this correctly possible, and if so what would be the best way from me to do this?
Thanks for any help,
Nov 11th, 2004, 02:49 PM
Your SecurityEnforcementFilter can only launch one AuthenticationEntryPoint. So you'll probably need to write a custom AuthenticationEntryPoint to "launch" the appropriate authentication based on the URI. For example, launch AuthenticationProcessingFilterEntryPoint if an interactive user or BasicProcessingFilter if a web service. Then again, you could just decide all web services should know they need to present BASIC credentials and just use AuthenticationProcessingFilterEntryPoint outright.
As for the different authentication mechanisms delegating to different authentication backends, your BasicProcessingFilter and AuthenticationProcessingFilter will process the authentication requests. It's probably easiest therefore to wire up separate AuthenticationManagers and AuthenticationProviders for each authentication mechanism, connecting the correct AuthenticationManager bean to the respective XxxxProcessingFilter.
Alternatively, have both BasicProcessingFilter and AuthenticationProcessingFilter delegate to the standard single AuthenticationManager and the standard DaoAuthenticationProvider. Simply write a custom AuthenticationDao that can poll a series of AuthenticationDao beans. Thus a username will first try to be found against your (say) JdbcAuthenticationDao and then an ActiveDirectoryAuthenticationDao.
Note also you might need to use PasswordDaoAuthenticationProvider rather than DaoAuthenticationProvider, as the Active Directory DAO might need both the username and password so it can attempt binding.
Powered by vBulletin® Version 4.2.1 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.