4. Channel Security

jsessionid를 오직 안전한 채널을 통해서만 전송할 수 있는 HTTPS를 사용하기 위해서는 필터들의 가장 상위에 있었던 ChannelProcessingFilter를 사용하면 됩니다.

web.xml에 FilterToBeanProxy 사용해서 등록한 뒤에 애플리케이션 컨텍스트에 다음과 같이 등록합니다.

<bean id=”channelProcessingFilter” class=”org.acegisecurity.securechannel.ChannelProcessingFilter”>
<property name=”channelDecisionManager”><ref bean=”channelDecisionManager”/></property>
<property name=”filterInvocationDefinitionSource”>
<value>
CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
\A/secure/.*\Z=REQUIRES_SECURE_CHANNEL
\A/acegilogin.jsp.*\Z=REQUIRES_SECURE_CHANNEL
\A/j_acegi_security_check.*\Z=REQUIRES_SECURE_CHANNEL
\A.*\Z=REQUIRES_INSECURE_CHANNEL
</value>
</property>
</bean>

<bean id=”channelDecisionManager” class=”org.acegisecurity.securechannel.ChannelDecisionManagerImpl”>
<property name=”channelProcessors”>
<list>
<ref bean=”secureChannelProcessor”/>
<ref bean=”insecureChannelProcessor”/>
</list>
</property>
</bean>

<bean id=”secureChannelProcessor” class=”org.acegisecurity.securechannel.SecureChannelProcessor”/>
<bean id=”insecureChannelProcessor” class=”org.acegisecurity.securechannel.InsecureChannelProcessor”/>

이런 이런… 이러니까 ‘XML 지옥’이라는 말이 나오면서 XML을 기피하게 되는 것 같습니다. 저 중에서 거~의 대부분의 상황에서 기본으로 .. 그냥 저렇게만 붙여 넣어서 사용하면 되는 부분을 빼면 색칠한 부분이 됩니다. Spring Security 2.0에서 태그 한방으로 모두 처리가 되리라 예상해 봅니다.

그림으로 그려보면 다음과 같은 관계에 있습니다.

사용자 삽입 이미지헥헥헥;;;

3.2 Filters

위의 필터들을 등록하는 방법은 크게 두 가지로 web.xml에 FilterToBeanProxy 를 사용하여 등록하는 방법과 Application Context에 FiterChainProxy를 사용하는 방법이 있습니다.

web.xml에 모든 필터를 등록할 때는 다음의 순서를 꼭 지켜야 합니다.

  1. ChannelProcessingFilter, 다른 프로토콜로 redirect할 필요가 있을 수도 있기 때문에…
  2. ConcurrentSessionFilter, 주체에 의한 요청을 반영하여 SessionRegistry를 갱신해야 할 필요에 의해서..
  3. HttpSessionContextIntegrationFilter,
    웹 요청이 시작될 때 SecurityContextHolder에 SecurityContext가 설정될 수 있고, 요청이 끝날
    때SecurityContext에 변경이 생기면 HttpSession에 복사할 수 있도록…
  4. Authentication
    processing mechanisms – AuthenticationProcessingFilter,
    CasProcessingFilter, BasicProcessingFilter,
    HttpRequestIntegrationFilter, JbossIntegrationFilter etc –
    SecurityContextHolder가 유효한 Authentication 요청 토큰을 갖도록 수정할 수 있도록…
  5. The
    SecurityContextHolderAwareRequestFilter, if you are using it to install
    an Acegi Security aware HttpServletRequestWrapper into your servlet
    container
  6. RememberMeProcessingFilter, 이전 인증 절치 매커니즘에 의해
    SecurityContextHolder가 변경되지 않았고, 쿠키등을 사용하여 ‘remember-me’ 서비스를 사용할 수
    있다면, 기억해 둔 Authentication 객체를 채워넣는다.
  7. AnonymousProcessingFilter, 이전 인증 절치 매커니즘에 의해 SecurityContextHolder가 변경되지 않았다면, 익명 Authentication 객체를 채워 넣는다.
  8. ExceptionTranslationFilter, Acegi Security 예외를 잡아서 HTTP 에러 응답을 반환하거나 적당한 AuthenticationEntryPoint가 실행되도록 한다.
  9. FilterSecurityInterceptor, 웹 URI를 보호하기 위해..

그럼 web.xml이 너무 복잡해지고 커지기 때문에…권장하고 있는 방법은 Application Context에 FilterChainProxy를 사용하여 모든 필터를 등록하는 방법입니다. 근데 FiterChainProxy를 사용하려면 어차피 web.xml에서 FilterToBeanProxy로 FilterChainProxy를 등록해야 하기 때문에..(어지러우시죠??ㅋㅋ)…네 그렇답니다.ㅋ

즉..web.xml에는 다음과 같이 FiterToBeanProxy를 등록하고(FilterChainProxy를 사용하도록 등록)

    <filter>
        <filter-name>Acegi Filter Chain Proxy</filter-name>
        <filter-class>
            org.acegisecurity.util.FilterToBeanProxy
        </filter-class>
        <init-param>
            <param-name>targetBean</param-name>
            <param-value>filterChainProxy</param-value>
        </init-param>
    </filter>

    <filter-mapping>
        <filter-name>Acegi Filter Chain Proxy</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>

Application Context에 FilterChainProxy를 등록합니다.

    <!–  if you wish to use channel security, add “channelProcessingFilter,” in front
        of “httpSessionContextIntegrationFilter” in the list below –>
    <bean id=”filterChainProxy”
        class=”org.acegisecurity.util.FilterChainProxy”>
        <property name=”filterInvocationDefinitionSource”>
            <value>
                CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
                PATTERN_TYPE_APACHE_ANT
                /**=httpSessionContextIntegrationFilter,formAuthenticationProcessingFilter,exceptionTranslationFilter,filterSecurityInterceptor
            </value>
        </property>
    </bean>

여기서 참조하는 필터들은 모두 Application Context에 bean으로 등록되어 있고 그 bean의 이름으로 FilterChainProxy에서 참조하고 있습니다.

2.2 Shared Components

사용자 삽입 이미지
파란색은 클래스 하늘색은 인터페이스 입니다. 모든 선은 dependency를 나타내고 있으며 Authentication 과 UserDetails의 사이가 점선인 관계는 직접적인 종속성은 없지만 Authentication 클래스의 getPrincipal() 메소드를 통해서 반환되는 Object 타입의 객체를 UserDetails 로 변환하여 사용할 수 있기 때문입니다.

1.1. What is Acegi Security?

Acegi Security는 J2EE 기반 엔터프라이즈 애플리케이션에 폭넓은 보안 서비스를 제공한다. 특히 Spring을 사용하고 있다면 보다 쉽게 Acegi에 접근할 수 있을 것이다.

기존 Servlet이나 EJB 스펙의 보안은 WAR나 EAR단위로 이식을 할 수 없었기 때문에, 서버 환경이 바뀌면 새 환경에 맞게 여러 설정을 변경해야했다. Acegi는 이러한 불편을 극복함은 물론이고, 이밖에도 여러 유용한 기능을 포함하고 있다.

두 가지 주요 기능을 제공한다.

  • Authentication(인증) : principal[footnote]일반적인 user를 의미[/footnote]을 인식
  • Authorization(권한) : principal이 애플리케이션에서 해당 행위를 할 수 있는지 결정

인증 차원에서 Acegi는 다양한 인증 모델을 지원한다.

위와 같이 다양한 인증 모델을 지원하기 때문에 많은 곳에서 사용하고 있지만, 혹여나 Acegi에서 지원하고 있지 않은 인증 모델들 중에 맘에 드는 것이 없을 수도 있다. Acegi는 오픈 프레임임웤이기 때문에 알아서 구현하면 된다. 표준을 사용하지 않는 별도의 인증 시스템을 구현하여 사용하고 있는 기존 시스템에 적용하고 싶을 수도 있다. 이 때도 Acegi는 잘~ 적용될 수 있다.

어떻게 인증을 거치느냐에 따라 세 종류의 권한 기능을 제공한다. authorizing web requests, authorizing methods can be invoked, authorizing access to individual domain object instances 이 녀석들을 이해 하려면 Servlet 스팩의 웹 패턴 보안, EJB 컨테이너가 관리하는 보안(CMS)과 파일 시스템 보안에 대해 살펴보라. Acegi는 이들 모두에 대해 고려했으며, 차후에 자세히 설명하겠다.