SSO(Single Sign On) 구현에 대해서 질문을 하셨는데, 까다로운 주제 중에 하나라고 생각됩니다. SSO 구현은 경우에 따라서 쉬울 수도 어려울 수도 있습니다.

  • 쿠키 VS 세션 : 쿠키나 세션 방식을 사용하는데 선호의 문제가 아닌, 환경의 문제를 먼저 따져봐야 합니다.
  • 만약, 같은 도메인을 사용하고 2차 도메인만 다르다면, 쿠키를 사용하여 SSO을 구현할 수 있습니다. 도메인 자체가 다르다면 쿠키를 사용할 수 없습니다.예를 들어, a.site.com b.site.com www.site.com 등은 쿠키를 공유할 수 있습니다. 하지만, www.siteA.comwww.siteB.com은 쿠키를 공유할 수 없습니다. 쿠키 설정할때는, 쿠키 Path를 루트로 잡아주시면 쿠키를 사용하여 인증작업을 진행할 수 있습니다.
  • 세션은 기본적으로 메모리상에 적재되기 때문에 사이트가 다른 경우 사용하기가 어렵습니다. 이럴 경우에는 세션 서버로 사용할 데이터베이스를 지정하여, 세션 정보를 공유하는 방법이 있습니다. 예를 들어 www.siteB.com?redirectUrl=리다이렉트경로&sessionId=ab0dmdbd0929d....에서 SessionID를 데이터베이스에서 검색해 있을 경우 인증해 주는 것입니다. 이때 문제는 A 사이트에서 발행한 SessionID의 소유자가 B 서버에서 인증하는 것이 안전한지 여부를 고려해야 합니다.
  • 쿠키, 세션 둘 다 사용할 수 없다면, 마지막으로 인증토큰을 만드는 방법입니다. A사이트에서 B사이트에 인증할때, http://www.siteB.com/Login.aspx?redirectUrl=리다이렉트경로&token=ab0dmdbd0929d.... 와 같은 식으로 넘겨주고 SiteB에서는 token 정보를 복호화하여 인증을 해줍니다. 여기서 token 값은 암호화된 값으로 사용자아이디,토큰유효시간 등의 사용자를 인증할 수 있는 정보를 담고 있어야 합니다. 그리고 A 사이트와 B 사이트에 이 암호를 암호/복호화 키값을 공유해야 합니다. 예전에 SAP 포털에 작업했을때, SAP 포털에서 인트라넷 SSO 작업을 수행할 때, SAP에서 발행하는 인증토큰을 복호화하여 사용자 정보를 인증해주는 SSO 작업을 수행해 준 적이 있습니다.
  • 앞에서 말씀드린 세션이나 인증토큰을 사용한 경우에 세션이나 토큰의 유효시간을 길게 할 경우에 보안상의 문제가 될 가능성이 존재합니다. 사이트 A에서 사이트 B로 이동할 때 넘겨주는 SessionID나 인증토큰 정보를 해커가 그대로 사용할 경우에 사용자 가장이 가능하기 때문입니다.
  • 지금까지 SSO를 간단하게 구현하는 몇가지 방법을 말씀드렸습니다. 넓은 관점에서는 앞에서 말씀드린 세션이나 인증토큰을 사용하는 방법은 유사합니다. 세션은 데이터베이스에서 정보를 찾고 인증토큰은 토큰 자체에 인증정보가 포한된다는 차이점이 있을 뿐입니다



출처 - http://blog.naver.com/PostView.nhn?blogId=lawyerle&logNo=70104126015



'Security > SSO' 카테고리의 다른 글

sso - 인증 방식  (0) 2013.06.15
josso - 2.3.0 설치 in fedora  (0) 2013.06.14
josso - josso 1 설치 가이드  (0) 2013.06.12
sso - 구현 방법 모색  (0) 2013.06.10
sso - 구현 방법, 쿠키 연동  (0) 2013.06.10
josso - 관련 자료 소개  (0) 2013.06.10
Posted by linuxism

댓글을 달아 주세요