SSO 를 지원하기 위한 방법은 여러가지가 있다. (CAS, SAML, Oauth) 이중에서 가장 간단한 구현 방법인 CAS를 다루어 보자.
정리
Central Authentication Service를 줄여서 CAS 라고 부르는데, 이 중앙 인증 서비스가 각 Application service의 사용자 인증을 함께 다룬다는 것이다. Flow는 다음과 같다.
- 사용자는 Application Server에 Request를 보낸다. (이때는 Ticket이 없음)
- Application Server는 사용자에게 Service ID 를 제공함과 동시에 사용자를 CAS Server로 리다이렉트 시킨다.
- CAS Server는 회원의 요청에 포함된 Service ID를 이용하여 해당 Application server에 인증된 회원의 ID를 전달한다.
- 사용자가 전달한 Service ID가 올바른 것인지 확인한다.
- 만약 여기서 접속이 안되어있으면, CAS Server 는 Web Browser에게 접속을 요청할 것이다.
- 여기서 Application Server는 전달받은 Authenticated ID가 CAS Server로부터 올바르게 전달된 것인지 확인한다.
- 어떻게? 왜?
- Application Server는 전달된 ID를 이용하여 Ticket을 발급하고 다시 CAS Server에 전달한다.
- 여기서 CAS Server는 Application으로부터 전달받은 Service ID와 Ticket이 Valid 한지 확인한다.
- 이때 사용자에게 요청받은 Service ID와 Application Server의 Service ID 가 같은지 확인한다.
- Application Server 로부터 온 Service ID와 Ticket이 Valid 한지 확인한다.
- 어떻게? 왜 ?
- CAS Server는 받은 Service 사용 Ticket과 CAS Server 접속 정보를 Cookie에 넣어 사용자에게 전달한다.
- 사용자는 Application Server 에게 Ticket을 제공하여 해당 서비스를 이용한다.
- 사용자가 전달한 Ticket이 올바른 것인지 확인한다.
- Ticket엔 만료 시간이 포함되어야 하며, 매 Ticket 사용마다 해당 만료시간이 Refresh 되어야 한다.
관건
여기서 가장 어려운 부분이 Ticket Validation 부분인 것 같다.
CAS Server와 Application Server 간의 소통 과정에서, 각자로부터 전달받은 Authenticated ID와 Ticket이 Valid 한지, 또 해당 API로의 요청이 조작된 것은 아닌지에 대한 확인을 어떻게 해야하는지가 관건인 것 같다.
CAS Server와 Application Server에 사용자의 접속 상태를 Session을 두는 것이 옳은 것일까도 고민이다.
CAS Server에 대한 인증은 Cookie에 SessionId만 두고 세션에서 접속상태를 관리하는 것이 적절하다고 느껴진다.
Application도 Ticket이 SessionId의 역할을 하는 방식으로 구현하는게 적절한걸까?
머릿속에선 그런 것 같은데, 참 고민이다.
### 참고자료
댓글