2013-12-17 4 views
2

Я обновляю старую программу для использования Spring Security. Ранее он использовал защиту Acegi и кэшировал учетные данные после начальной проверки заголовка SSO в файл cookie сеанса; с Spring Security 3.1.4, я смог получить программу проверки заголовка имени SSO (SM_USER - и нет, мы больше не используем Siteminder, но чтобы избежать болезненных обновлений программного обеспечения при переключении на OAM, мы настроили OAM на вставить заголовок SM_USER в запросы) и работать локально с установкой клапана в tomcat (6.0); однако при развертывании в среду dev, с активным SSO, он терпит неудачу только на POSTS, а затем только на страницы, которые используют один и тот же URL, но разные HTTP RequestMethod. Рассматривая сетевой трафик, кажется, что разница между старым кодом и новым заключается в том, что новый код делает запрос OO SSO auth, а затем перенаправление posthut передает данные POST и изменяет RequestMethod на GET; поэтому я подумал, что, возможно, добавление кэширования учетных данных обратно в приложение устранит проблему; но мне трудно найти конфигурацию, которую я могу добавить, чтобы активировать кеширование, и вот где я обращаюсь к вам.Spring Security - кеширование учетных данных из SSO

Это конфигурация безопасности, которая делает в аутентификации запроса, и работает локально:

<security:http use-expressions="true" auto-config="true" entry-point-ref="http403EntryPoint"> 
     <security:intercept-url pattern="/**" access="isAuthenticated()" /> 
     <security:intercept-url pattern="/fastjump/auth/admin/*" access="hasRole('ROLE_ADMINISTRATOR')" /> 
     <security:intercept-url pattern="/fastjump/auth/*" access="permitAll" /> 
     <security:custom-filter position="PRE_AUTH_FILTER" ref="siteminderFilter" /> 
    </security:http> 

    <bean id="siteminderFilter" class="org.springframework.security.web.authentication.preauth.RequestHeaderAuthenticationFilter"> 
     <property name="principalRequestHeader" value="SM_USER"/> 
     <property name="authenticationManager" ref="authenticationManager" /> 
    </bean> 

    <bean id="preauthAuthProvider" class="org.springframework.security.web.authentication.preauth.PreAuthenticatedAuthenticationProvider"> 
     <property name="preAuthenticatedUserDetailsService"> 
      <bean id="userDetailsServiceWrapper" class="org.springframework.security.core.userdetails.UserDetailsByNameServiceWrapper"> 
       <property name="userDetailsService" ref="userDetailsService"/> 
      </bean> 
     </property> 
    </bean> 

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


    <!-- This is the class that handles actually looking up the user from the persistent store and associating their 
    GrantedAuthority objects. This custom implementation uses a PersonService object to do the lookup. --> 
    <bean id="userDetailsService" class="corporate.fastjump.security.DefaultUserDetailsService"> 
     <property name="personService" ref="personService"/> 
     <property name="fastJumpService" ref="fastJumpService"/> 
    </bean> 

    <bean id="http403EntryPoint" class="org.springframework.security.web.authentication.Http403ForbiddenEntryPoint"/> 

Я попытался добавить следующее к конфигурации безопасности:

<bean id="filterChainProxy" class="org.springframework.security.web.FilterChainProxy"> 
    <security:filter-chain-map> 
     <security:filter-chain filters="httpSessionContextIntegrationFilter, securityContextHolderAwareRequest, siteminderFilter" pattern="/fastjump/auth/**"/> 
    </security:filter-chain-map> 
</bean> 

<bean id="httpSessionContextIntegrationFilter" class="org.springframework.security.web.context.SecurityContextPersistenceFilter"> 
    <property name="securityContextRepository"> 
     <bean class="org.springframework.security.web.context.HttpSessionSecurityContextRepository"> 
      <property name="allowSessionCreation" value="false"/> 
     </bean> 
    </property> 
</bean> 

<bean id="securityContextHolderAwareRequest" class="org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter"> 
</bean> 

И это к web.xml:

<!-- This filter is used to implement request level authorization. --> 
<filter> 
    <filter-name>springSecurityFilterChain</filter-name> 
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class> 
</filter> 

<!-- Note that we only send requests which require authentication and authorization services through the 
Spring Security filters --> 
<filter-mapping> 
    <filter-name>springSecurityFilterChain</filter-name> 
    <url-pattern>/auth/*</url-pattern> 
</filter-mapping> 

Но это теперь добавляет основной вызов auth в контекст/auth re квесты. Мне не хватает части, которая связывает кеширование с pre auth. У кого-нибудь есть предложения?

ответ

0

Итак, оказывается, что проблема SSO была проблемой, но не так, как мы изначально думали. У нас есть несколько разных доменов SSO (DEV, INT, PROD), и у нас был автозапуск на рассматриваемой странице, который был жестко закодирован, чтобы выйти на веб-службу в домене Prod, и, хотя API веб-службы специально исключен в домен производства из SSO-защиты (он открыт для всех пользователей), запрос запроса на сервер Production вызвал запрос в домен SSO Production и перезаписал сеанс с учетными данными Production. Возврат к серверу Dev и попытка выполнить POST с помощью прокси-счетов не удалось, и в процессе запроса Dev SSO для правильных учетных данных он удалил данные POST и изменил тип запроса html на GET. Наше решение состояло в том, чтобы обновить автозапуск, чтобы логика определяла, на каком сервере он работает (через JavaScript, посмотрите на хост), а затем создайте URL-адрес для задней части автозаполнения на основе той среды, в которой мы находимся.

Смежные вопросы