Additional authentication check

[seprak]

Hello,

I'm using spring security 2. I have configured form login and authentication and authorization using LDAP. In addition I need to perform container based authentication (programaticaly) which is neccessary to use AS SSO functionality.

org.jboss.web.tomcat.security.login.WebAuthentication webAuthentication = new org.jboss.web.tomcat.security.login.WebAuthentication();
boolean success = webAuthentication.login(this.getUserName(), this.getPassword()))

Where should I do this? Do I need to create custom filter?

Thanks

[Rob Winch]

See if the PreAuthentication scenarios help.

PS: I cannot tell for sure with only the few lines of code you posted, so this may be nothing. However, looking at the code you posted the code may not be thread safe. The reason I am wondering this is that I see this.getUsername() and this.getPassword(). Unless you create a new instance of "this" for each user or are performing some sort of locking, then you will encounter a race condition. If you are creating a new instance of "this" each time, then there is nothing to worry about.

[seprak]

Pre authentication scenarios are applied when i'm already authenticated by the contanier before springs filter chain is invoked. In my scenario this is not the case. Im authenticating with spring (LdapProvider) but additionaly I need to authenticate with JBoss. I would like to do that programatically (provided code). I was thinking to implement my own provider that will do this but ProviderManager invokes only first provider and when it authenticates it returns the result. All other subsequent providers are ignored.
The code you see is taken from other application(method in request-scoped JSF bean). I have attached it just for informative purpose.

[seprak]

To simplify: I need following code

org.jboss.web.tomcat.security.login.WebAuthentication webAuthentication = new org.jboss.web.tomcat.security.login.WebAuthentication();
    boolean result = webAuthentication.login(this.getUserName(), this.getPassword());

to be invoked after sucessfull LdapProvider authentication, and I would like that result influences overall user authentication with spring security (result=true: authentication sucess, result=false: authentication failure).

My spring security configuration:

	<security:http entry-point-ref="authenticationProcessingFilterEntryPoint" 
				   access-decision-manager-ref="httpRequestAccessDecisionManager" 
				   access-denied-page="/j_spring_security_logout">
		<security:intercept-url pattern="/faces/login.xhtml*" filters="none" />
		<security:intercept-url pattern="/faces/pages/public/**" filters="none" />
		<security:intercept-url pattern="/faces/pages/**" access="ROLE_USER,ROLE_REGISTERED,ROLE_FIRMREGISTERED"  />
		<security:intercept-url pattern="/**" filters="none" />
		<security:logout invalidate-session="true" />
	</security:http>

	<!-- Role-based access. At least one from specified roles must be present to get positive answer -->
	<bean id="httpRequestAccessDecisionManager" class="org.springframework.security.vote.AffirmativeBased">
		<property name="allowIfAllAbstainDecisions" value="false" />
	  	<property name="decisionVoters">
  		  <list>
  	    	<ref bean="roleVoterCert"/>
  		  </list>
  		</property>
   	</bean>

   	<bean id="roleVoterCert" class="org.springframework.security.vote.RoleVoter">
		<property name="rolePrefix" value="" />
	</bean>
	

	<bean id="authenticationProcessingFilter"
		class="org.springframework.security.ui.webapp.AuthenticationProcessingFilter">
		<security:custom-filter position="AUTHENTICATION_PROCESSING_FILTER" />
		<property name="defaultTargetUrl" value="/faces/pages/main/processes.xhtml" />
		<property name="authenticationFailureUrl" value="/faces/pages/public/index.xhtml?error" />
		<property name="authenticationManager" ref="authenticationManager" />
		<property name="alwaysUseDefaultTargetUrl" value="true" />
		<property name="usernameParameter" value="j_username" />
		<property name="passwordParameter" value="j_password" />
	</bean>


	<bean id="authenticationProcessingFilterEntryPoint"
		class="org.springframework.security.ui.webapp.AuthenticationProcessingFilterEntryPoint">
		<property name="loginFormUrl" value="/faces/pages/public/index.xhtml" />
	</bean>

	<!-- Default namespace configured authentication manager -->
	<security:authentication-manager alias="authenticationManager" />

	<bean id="ldapAuthProvider"
		class="org.springframework.security.providers.ldap.LdapAuthenticationProvider">
		<security:custom-authentication-provider />
		<property name="userDetailsContextMapper" ref="userInfoUserDetailsContextMapper" />
		<constructor-arg>
			<bean
				class="org.springframework.security.providers.ldap.authenticator.BindAuthenticator">
				<constructor-arg ref="defaultLdapContextSource" />
				<property name="userSearch">
					<bean id="userSearch"
						class="org.springframework.security.ldap.search.FilterBasedLdapUserSearch">
						<constructor-arg index="0" value="" />
						<constructor-arg index="1" value="(uid={0})" />
						<constructor-arg index="2" ref="defaultLdapContextSource" />
					</bean>
				</property>

			</bean>
		</constructor-arg>
		<constructor-arg>
			<bean
				class="org.springframework.security.ldap.populator.DefaultLdapAuthoritiesPopulator">
				<constructor-arg ref="defaultLdapContextSource" />
				<constructor-arg><value>o=roles,dc=app</value></constructor-arg>
				<property name="groupRoleAttribute" value="cn" />
				<property name="groupSearchFilter" value="(uniqueMember={0})" />
			</bean>
		</constructor-arg>
	</bean>

[Rob Winch]

There are a few ways I can think of doing this with 3.x, but that won't do you any good. The best way I can think of doing this with 2.x is to create a CompositeAuthenticationProvider which delegates to the LdapAuthenticationProvider and custom AuthenticationProvider that does your additional logic using WebAuthentication. If both pass, then you return the successful authentication.

HTH,

[richardl]

There are a few ways I can think of doing this with 3.x, but that won't do you any good.
HTH,

Can you mention the few ways with 3.x? I have tried to force re-auth by returning null from a custom filter but the chain doesn't redirect to the login page. What would be the optimal way to address additional authentication?

[Rob Winch]

Returning null wasn't quite the approach I had in mind. While a bit more difficult to configure (since you cannot use the namespace) try creating your own AuthentictionProvder that extends LdapAuthenticationProvider and overrides createSuccessfulAuthentication. Call the super and then do you additional checks. If it does not a pass your checks throw an AuthenticationException. You can find an example of how to configure ldap w/out the namespace in the ldap sample application.

[richardl]

Returning null wasn't quite the approach I had in mind. While a bit more difficult to configure (since you cannot use the namespace) try creating your own AuthentictionProvder that extends LdapAuthenticationProvider and overrides createSuccessfulAuthentication. Call the super and then do you additional checks. If it does not a pass your checks throw an AuthenticationException. You can find an example of how to configure ldap w/out the namespace in the ldap sample application.

My issue is that the additional checks require additional input from the user. Because of this I have to get back to somewhere where the user can enter more info. After reading the code and documentation for AbstractAuthenticationProcessingFilter I figured out that returning a null from attemptAuthentication also expects that the response has been handled. What I tried was redirecting the response to the referer (sic) which is the login page the user came from. Hopefully this will not muck with the saved request. Is this a valid approach?

[Rob Winch]

My issue is that the additional checks require additional input from the user. Because of this I have to get back to somewhere where the user can enter more info. After reading the code and documentation for AbstractAuthenticationProcessingFilter I figured out that returning a null from attemptAuthentication also expects that the response has been handled. What I tried was redirecting the response to the referer (sic) which is the login page the user came from. Hopefully this will not muck with the saved request. Is this a valid approach?

I did not realize you were requiring additional information from the user. I would probably try to avoid using the referrer header as the way of determining where to redirect. This reduces the trust on what is input into the application (which usually ends up being good for application security). Instead, I would probably specify the URL in your Spring configuration. The other thing you may have problems with is if you return null, then the Authentication is not saved. Perhaps you are setting it manually in the AuthenticationProvider though. Other than that if you got it up and running, from what you have posted I don't see any problems with the solution.