이제 이론을 살펴보았으므로 어떻게 사용하는지 알아보기로 하자. HTTP 다이제스트 인증을 구현하려면 DigestProcessingFilter를 필터 체인에 정의할 필요가 있다. 애플리케이션 컨텍스트에 DigestProcessingFilter와 필요한 협력자들을 정의할 필요가 있을 것이다:

<bean id="digestProcessingFilter" class="org.acegisecurity.ui.digestauth.DigestProcessingFilter">
  <property name="userDetailsService"><ref local="jdbcDaoImpl"/></property>
  <property name="authenticationEntryPoint"><ref local="digestProcessingFilterEntryPoint"/></property>
  <property name="userCache"><ref local="userCache"/></property>
</bean>

<bean id="digestProcessingFilterEntryPoint" class="org.acegisecurity.ui.digestauth.DigestProcessingFilterEntryPoint">
  <property name="realmName"><value>Contacts Realm via Digest Authentication</value></property>
  <property name="key"><value>acegi</value></property>
  <property name="nonceValiditySeconds"><value>10</value></property>
</bean>
        

설정된 UserDetailsService는 DigestProcessingFilter가 사용자의 클리어 텍스트 비밀번호에 직접 접근해야 하므로 필요하다. 다이제스트 인증은 여러분이 DAO에 들어있는 인코딩된 비밀번호를 사용하고 있을 경우 작동하지 않을 것이다. UserCache와 더불어 DAO 협력자는 일반적으로 DaoAuthenticationProvider와 직접적으로 공유된다. authenticationEntryPoint 프로퍼티는 DigestProcessingFilterEntryPoint이어야 하며, 따라서 DigestProcessingFilter는 다이제스트 연산에 필요한 realmName과 key를 획득할 수 있다.

BasicAuthenticationFilter에서 처럼 인증이 성공할 경우 Authentication 요청 토큰이 SecurityContextHolder에 위치할 것이다. 만약 인증 시도가 성공하거나 HTTP 헤더가 다이제스트 인증 요청을 포함하고 있지 않아 인증이 시도되지 않았을 경우 필터 체인은 평상시대로 진행할 것이다. 필터 체인이 중단되는 유일한 시점은 앞 단락에서 논의했던것 처럼 인증이 실패하거나 AuthenticationEntryPoint가 호출되는 경우이다.

다이제스트 인증의 RFC는 보안성을 증대시키기 위한 광범한 추가 기능들을 제공한다. 예를 들어, 비표는 모든 요청마다 변경될 수 있다. 이렇게 함에도 불구하고 Acegi Security 구현체는 구현체의 복잡성을 최소화하고(그리고 발생할 수 있는 사용자 에이전트의 호환성 없음은 의심할 것도 없이), 서버측 상태를 저장할 필요성을 되도록이면 줄이도록 설계되었다. 만약 여러분이 이러한 기능들을 좀 더 자세히 알아보길 원한다면 RFC 2617을 검토해 보길 바란다. 우리가 아는 한 Acegi Security 구현체는 RFC 2617의 최소한의 표준만을 준수하고 있다.