CasAuthenticationProvider는 상태를 갖는 클라이언트(stateful client)와 상태를 갖지 않는 클라이언트(stateless client)를 구별한다. 상태를 갖는 클라이언트는 CasProcessingFilter를 통해 들어오는 것으로 간주한다. 상태를 갖지 않는 클라이언트는 CasProcessingFilter.CAS_STATELESS_IDENTIFIER과 동일한 신원주체를 가진 UsernamePasswordAuthenticationToken를 통해 인증 요청을 나타내는 것이다.

상태를 갖지 않는 클라이언트는 Hessian가 Burlap과 같은 원격 프로토콜일 것이다. 이 경우에도 그대로 BasicProcessingFilter가 사용되며 원격 프로토콜 클라이언트는 위의 정적 문자열과 동일한 사용자명 및 CAS 서비스 티켓과 동일한 비밀번호를 제시할 것으로 예상한다. 클라이언트들은 CAS 서버로부터 직접 CAS 서비스 티켓을 획득해야만 한다.

원격 프로토콜은 자기 자신을 HttpSession의 컨텍스트내에서 표시하는 수단을 갖지 않기 때문에 HttpSession의 HttpSessionIntegrationFilter.ACEGI_SECURITY_AUTHENTICATION_KEY 속성에 의존하여 CasAuthenticationToken에 위치하도록 할 수 있다. 또한 CAS 서버가 TicketValidator에 의해 유효성 검증이 이루어진 다음 그러한 서비스 티켓을 무효화하므로 동일한 서비스 티켓을 연속된 요청에 제시하는 것은 효과가 없을 것이다. 비슷하게 원격 프로토콜 클라이언트에 대해 프록시에서 허가한 티켓을 획득하는 것도 쉽지 않은데, 왜냐하면 그러한 것들이 종종 CAS 서버에 접근할 수 있는 HTTPS URL이 거의 없는 클라이언트 머신에 배포되기 때문이다.

한 가지 분명한 선택사항은 원격 프로토콜 클라이언트들에 대해 CAS를 전혀 사용하지 않는 것이다. 하지만 이렇게 하면 CAS가 제공하는 대부분의 매력적인 기능들을 사용하지 못하게 된다.

중도로서 CasAuthenticationProvider는 StatelessTicketCache를 사용한다. CasAuthenticationProvider는 CasProcessingFilter.CAS_STATELESS_IDENTIFIER과 동일한 신원주체를 표현하는 데 있어 단독적으로 사용된다. 이렇게 했을 때 일어나는 일은 CasAuthenticationProvider가 서비스 티켓에 맞춰진 StatelessTicketCache에 결과 CasAuthenticationToken이 저장된다는 것이다. 따라서 원격 프로토콜은 동일한 서비스 티켓을 제시할 수 있으며 CasAuthenticationProvider는 유효성 검증을 위해 CAS 서버에 접촉할 필요는 없을 것이다(최초 요청과는 별도로).

고급 CAS 사용에 있어 또 다른 측면은 프록시에서 허가한 티켓으로부터 프록시 티켓을 생성하는 것과 관련되어 있다. 위에서 언급했던 것과 같이 우리는 CAS의 ProxyTicketReceptor를 이용하여 이러한 티켓들을 부여받을 것을 권장한다. ProxyTicketReceptor는 여러분이 프록시가 허가하는 IOU 티켓을 제시함으로써 프록시 티켓을 획득할 수 있도록 해주는 정적 메소드를 제공한다. 여러분은 CasAuthenticationToken.getProxyGrantingTicketIou()를 호출하여 프록시에서 허가한 IOU 티켓을 획득할 수 있다.

Acegi Security 클래스들을 이용한 CAS 통합이 쉽고 유용하다는 것을 알게 되길 바란다. 엔터프라이즈 차원의 싱글 사인 온에 온 것을 환영한다!