Spring_security_saved_request_key

[lumpynose]

In the api docs for org.springframework.security.ui.AbstractProcessing Filter for the defaultTargetUrl they say

defaultTargetUrl: indicates the URL that should be used for redirection if the HttpSession attribute named SPRING_SECURITY_SAVED_REQUEST_KEY does not indicate the target URL once authentication is completed successfully.

On my desktop Windows system, running tomcat-6.0.18, and another system, a linux server running the same version of tomcat, I correctly get redirected back to whatever page I was on before I triggered authentication (I'm using CAS). But on our web farm, which has one or more apache httpds in front of tomcat, I'm being redirected back to what defaultTargetUrl is set to.

Has anyone else experienced this? Or have any ideas why SPRING_SECURITY_SAVED_REQUEST_KEY isn't set?

[Luke Taylor]

Have you debugged the session handling (i.e. is it the same session) ?

You should be able to track everything (the saved request being store, redirection to logon and the subsequent incoming URL which should match the request) from the debug log.

[jonnio]

Have you checked the apache configs for any rewrites and or redirects? What is the security section of your web.xml set for?

[spra85]

I'm having this exact same problem. Were you able to discover a solution?

[lumpynose]

Sorry, I've fixed it, but it was so long ago I don't remember what I did to fix it. The only thing that I have a vague memory about is needing to specify the port, although if your site/app is on port 80 that shouldn't be necessary, and I'm not sure the port problem was for this problem or something else.

Here are the config lines from my maven pom.xml file; the cas.whatever names match up fairly closely with the property names in the cas .xml file.

        <server.hostName>localhost</server.hostName>
        <server.port>8080</server.port>

        <webapp.name>people_locator</webapp.name>

        <cas.login.url>https://auth-test.berkeley.edu/cas/login</cas.login.url>
        <cas.serviceTicketValidator.url>https://auth-test.berkeley.edu/cas/</cas.serviceTicketValidator.url>
        <cas.serviceProperties.url>http://${server.hostName}:${server.port}/${webapp.name}/j_spring_cas_security_check</cas.serviceProperties.url>

And here's my xml config file for CAS & Spring Security.

<?xml version="1.0" encoding="UTF-8"?>

<!-- people locator -->

<beans:beans
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:security="http://www.springframework.org/schema/security"
    xmlns:beans="http://www.springframework.org/schema/beans"
    xmlns:context="http://www.springframework.org/schema/context"
    xsi:schemaLocation="
        http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
        http://www.springframework.org/schema/security
        http://www.springframework.org/schema/security/spring-security-2.0.2.xsd">

    <!-- order is significant for the intercept-url properties -->
    <security:http entry-point-ref="casProcessingFilterEntryPoint">
        <security:intercept-url
            pattern="/casFailed.zug"
            filters="none"
        />

        <security:intercept-url
            pattern="/admin/**"
            access="ROLE_ADMIN"
        />

        <security:intercept-url
            pattern="/localLogin.zug"
            access="ROLE_AUTHENTICATED"
        />

        <security:logout />
    </security:http>

    <security:authentication-manager
        alias="authenticationManager"
    />

    <beans:bean id="casProcessingFilter" class="org.springframework.security.ui.cas.CasProcessingFilter">
        <security:custom-filter
            after="CAS_PROCESSING_FILTER"
        />

        <beans:property
            name="authenticationManager"
            ref="authenticationManager"
        />

        <beans:property
            name="authenticationFailureUrl"
            value="/casFailed.zug"
        />

        <beans:property
            name="defaultTargetUrl"
            value="/search.zug"
        />
    </beans:bean>

    <beans:bean id="casProcessingFilterEntryPoint" class="org.springframework.security.ui.cas.CasProcessingFilterEntryPoint">
        <!-- https://auth-test.berkeley.edu/cas/login -->
        <beans:property
            name="loginUrl"
            value="${cas.login.url}"
        />

        <beans:property
            name="serviceProperties"
            ref="serviceProperties"
        />
    </beans:bean>

    <beans:bean id="casAuthenticationProvider" class="org.springframework.security.providers.cas.CasAuthenticationProvider">
        <security:custom-authentication-provider />

        <!-- eduUserDetailsService is a @Service annotated class -->
        <beans:property
            name="userDetailsService"
            ref="eduUserDetailsService"
        />

        <beans:property
            name="serviceProperties"
            ref="serviceProperties"
        />

        <beans:property name="ticketValidator">
            <beans:bean class="org.jasig.cas.client.validation.Cas20ServiceTicketValidator">
                <!-- serviceValidate is appended to the url by Cas20ServiceTicketValidator -->
                <!-- https://auth-test.berkeley.edu/cas/ -->
                <beans:constructor-arg
                    index="0"
                    value="${cas.serviceTicketValidator.url}"
                />
            </beans:bean>
        </beans:property>

        <beans:property
            name="key"
            value="user"
        />
    </beans:bean>

    <beans:bean id="serviceProperties" class="org.springframework.security.ui.cas.ServiceProperties">
        <!-- http://localhost:8080/people_locator/j_spring_cas_security_check -->
        <beans:property
            name="service"
            value="${cas.serviceProperties.url}"
        />

        <beans:property
            name="sendRenew"
            value="false"
        />
    </beans:bean>
</beans:beans>

[lumpynose]

My setup may be a bit weird; rather than use the anonymous user I just send the user to the login page if they want to login (the only page which requires authentication) and then authenticate them. Otherwise (i.e., until they authenticate) throughout the app they're known to be unauthenticated and can't see the things that an authenticated user can.

One way to think about it is that everything is read-only when you're not authenticated and read/write when you are authenticated.