Results 1 to 3 of 3

Thread: Single servlet acecss login/auth

  1. #1
    Join Date
    Apr 2008
    Posts
    3

    Default Single servlet acecss login/auth

    I have a set of servlets that we plan to protect using HTTP Digest login. These servlets are basically just single use services and can be called from a CLI using something like curl. My goal is to have spring security force authentication on every request. Since these servlets do not return any UI information, I have been trying to remove all of the filter chain pieces I do not need.

    In my current setup, my supplied digest credentials are used once and then any further requests, regardless of the source, are automatically authenticated with those credentials; not quite what I want

    In my spring config file, I have the following

    Code:
    	<bean id="filterChainProxy"
    		class="org.springframework.security.util.FilterChainProxy">
    		<security:filter-chain-map path-type="ant">
    			<security:filter-chain pattern="/**"
    				filters="digestProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor" />
    		</security:filter-chain-map>
    	</bean>
    
    	<bean id="digestProcessingFilter"
    		class="org.springframework.security.ui.digestauth.DigestProcessingFilter">
    		<property name="userDetailsService"
    			ref="myUserDetailsService" />
    		<property name="authenticationEntryPoint"
    			ref="digestProcessingFilterEntryPoint" />
    	</bean>
    	
    	<bean id="digestProcessingFilterEntryPoint"
    		class="org.springframework.security.ui.digestauth.DigestProcessingFilterEntryPoint">
    		<property name="realmName" value="Server Realm" />
    		<property name="key" value="acegi" />
    		<property name="nonceValiditySeconds" value="10" />
    	</bean>
    
    	<bean id="exceptionTranslationFilter"
    		class="org.springframework.security.ui.ExceptionTranslationFilter">
    		<property name="authenticationEntryPoint"
    			ref="digestProcessingFilterEntryPoint" />
    		<property name="accessDeniedHandler">
    			<bean
    				class="org.springframework.security.ui.AccessDeniedHandlerImpl">
    			</bean>
    		</property>
    	</bean>
    
    	<bean id="filterInvocationInterceptor"
    		class="org.springframework.security.intercept.web.FilterSecurityInterceptor">
    		<property name="authenticationManager"
    			ref="authenticationManager" />
    	    <property name="alwaysReauthenticate" value="true" />
    		<property name="accessDecisionManager">
    			<bean
    				class="org.springframework.security.vote.AffirmativeBased">
    				<property name="allowIfAllAbstainDecisions"
    					value="false" />
    				<property name="decisionVoters">
    					<list>
    						<bean
    							class="org.springframework.security.vote.RoleVoter" />
    						<bean
    							class="org.springframework.security.vote.AuthenticatedVoter" />
    					</list>
    				</property>
    			</bean>
    		</property>
    		<property name="objectDefinitionSource">
    			<security:filter-invocation-definition-source>
    				<security:intercept-url pattern="/**"
    					access="ROLE_USER" />
    			</security:filter-invocation-definition-source>
    		</property>
    	</bean>
    
        <bean id="passwordEncoder"
            class="org.springframework.security.providers.encoding.PlaintextPasswordEncoder">
        </bean>
    
    	<bean id="daoAuthenticationProvider"
    		class="org.springframework.security.providers.dao.DaoAuthenticationProvider">
    		<property name="userDetailsService"
    			ref="myUserDetailsService" />
    		<property name="passwordEncoder" ref="passwordEncoder" />
    	</bean>
    
    	<bean id="authenticationManager"
    		class="org.springframework.security.providers.ProviderManager">
    		<property name="providers">
    			<list>
    				<ref local="daoAuthenticationProvider" />
    			</list>
    		</property>
    	</bean>
    For testing, in my custom UserDetailsService, I am creating a User object and setting hard coded password (Plaintext encoder to start with) and granted authorities (IS_AUTHENTICATED_FULLY, ROLE_USER).

    The only caches that I have seen in the docs and the code in my debugging sessions should be the NullUserCache. How the behavior appears to me is that somewhere in the filter chain, one of the components is holding onto the last authenticated user, but that is not what I am after.

    I have thought about making my own custom filter that will clear out any authenticated sessions after the request has been processed, but I would need to know where the cached item is actually coming from.

    Any ideas, pointers?

    I'm about to head back into the debugger and set breakpoints in each filter that I am currently using to see if I can figure out what exactly is going on.

  2. #2
    Join Date
    Apr 2008
    Posts
    3

    Default

    Walking through the debugger helped some. I'm going to guess I probably have the security framework mis-configured in general.

    So, I found out that the FilterSecurityInterceptor stores the authenticated user in the SecurityContextHolder. The default is suppose to be a thread local.

    It looks like I could quickly create a servlet filter to run after the servlet and call SecurityContenxtHolder.clearContext(), but that seems a little like a hack around something else that I have broke on my own.

    Pointers?

  3. #3
    Join Date
    Apr 2008
    Posts
    3

    Default

    I'll post my own answer here in case someone else runs across this.

    On the FilterSecurityInterceptor, there is an afterInvocationManager property. By default, this is set to null. I created a class that implements AfterInvocationManager. Make the two methods that return booleans just return true. The third method I invoked SecurityContextHolder.clearContext(); and returned null.

    With this change, I have the desired effect. Every request from curl now requires the digest authentication credentials to be supplied.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •