SSO, XSS
브라우저에서 사용되는 자바스크립트는 잘 알고 있다시피, DOM 구조상 document 개체의 domain이 다르면 접근할 수 없는 것으로 알려져 있습니다. (참고) 그 규칙에 따라서, 브라우저 제작사들은 적절한 접근제한을 가하고 있습니다.

몇가지 상황에서 우회로를 뚫어 보겠습니다.


세션키 전달


같은 데이터베이스를 사용하지만, TLD나 1차 도메인 명이 다른 두 개의 다른 도메인으로 운영되되는 사이트를 운영할 때는 싱글사인온 같은 문제가 발생합니다. 한가지 팁으로 사용되는 방법으로는 현재의 window.name에 값을 저장하고 도메인이 달라지는 다음 페이지에서 window.name을 조사하여 전달하는 방식을 iframe에 응용하는 것입니다.

example.com: main.html
<html><body>
<iframe src="http://example.net/othersite.html" name="SESS_12345678"></iframe>
</body></html>
example.net: othersite.html
<html><head>
<script>if( document.cookie.indexOf( 'SESSION' ) < 0 && window.name.substr(0,4) == 'SESS' ){
    document.cookie = "SESSION="+window.name.substr(5);
    document.location.href = document.location.href; /* 다시 로드 */
}
</script>
</head></html>

변화하는 값 전달

위의 예는 페이지가 로드될 때 한 번 일어날 수 있는 상황에서 사용됩니다. 다음 소개하는 예는 IE에서만 동작하는 팁입니다.

example.com: main.html
<html>
<body>
<iframe width="300px" height="1024px" src="http://example.net/othersite.html" name="other"></iframe>
<script>
setInterval( function() {
    window.frames['other'].name = (new Date()).getTime();
}, 1000 );
</script>
</body></html>
example.net: othersite.html
<html><body>
<span id="display"></span>
<script>
setInterval( function() {
    document.getElementById('display').innerHTML = window.name;
}, 1000 );
</script></body>
</html>
IE에서만 동작하는 이유는 window.frames['other'].name 속성이 접근가능하기 때문입니다. 분명히, 다른 도메인인데도 불구하고, 해당 윈도우의 속성을 변경할 수 있게 되고, 그것을 통해서 두 도메인간 데이터를 교환할 수 있는 방법이 존재하는 것입니다. IETester를 이용해서 확인한 결과 5.5~8Beta1까지 모두 사용이 가능하더군요.

FF, Opera, Safari에서는 위 코드가 모두 접근 오류를 일으키고 실행되지 않습니다.


신고
  1. http://create74.com/ 2008.06.07 22:32 신고

    이런 놀이를 하시다니 --;
    일전에 타 도메인간 작업놀이 하다 열받은 기억이 --;

    • 최호진 2008.06.08 01:46 신고

      오픈소셜 컨테이너가 저런류의 잡지식을 원~합니다.

대체, sign on, log on, sign in, log in 을 구별하는 따위의 시도를 할 필요가 있습니까?

경험상 아주 오랜 전통으로 login 이라는 용어가 제일 Unix 시스템에 접근하기 위해 먼저 쓰였습니다. "로그인"이라는 단어가 생소하던 시절에 일종의 신조어 격이었습니다. 그러다가 Windows 3.1이 작업그룹을 지원하는 Windows for workgroups 버전을 내놓으면서 로그인이라는 유닉스 계열과 뭔가 다르게 작업하기 위해 sign-on 이라는 용어를 사용한 것으로 압니다. (희미한 기억속의 일이므로 이것을 사실화하여 논문에 인용하지 마시길.)

구별하기 좋아하는 사람은 log in과 sign on을 하나의 시스템에 들어가는 것과 하나의 정보체계에 들어 있는 작업그룹에 들어가는 것으로 구별하고 싶어할지 모르겠습니다. 또, Web으로 인증하는 것을 sign in 이라고 표현하고 싶을지도 모르고, 인증 후 프롬프트가 떨어지지 않는 시스템에 대한 것을 Log-on이라고 표현하고 싶을지도 모르겠습니다. 제발 이런 구별을 하지 말아주세요. 뭔가 부끄러워 보입니다. 이런 용어들이 모두 다 인증을 시도하여 성공했다는 뜻으로 시스템을 구성할 때 선택한 용어들일 뿐입니다.

이전의 글들에 SSO 를 써놨더니, 몇몇 리퍼러들이 특이 해 보이는 것들이 잡혔습니다. Single Sign-On과 Signle Log-On 을 각각 SSO, SLO 로 표현하고 이것들을 검색하다가 왔더군요. 어떤 글에는 SSO와 SLO를 동시에 만족하는 솔루션 어쩌고 저쩌고도 있습니다. 시스템 통합 쪽에서 이런 말들을 쓰나보네요. 검색해보면 나올만한 곳에서 다음과 같은 식으로 구별을 하는 것을 보았습니다.

http://blog.naver.com/nalin04/150013996820

SSO 와 SLO의 차이
둘다 한번의 인증으로 시스템을 모두 사용하는 개념입니다.
Single Sign On의 경우에는 계정정보가 시스템별로 존재하고 공통인증모듈 하나만 존재하는 반면, Sing LogOn는 계정정보가 하나의 시스템에 존재하고, 각각의 시스템에는 서로 별도의 인증부분이 존재 합니다.

두줄요약
daum.net 로그인시 naver.com에도 로그인되게 SSO
mail.naver.com 로그인시 blog.naver.com 에도 로그인되게 SLO

[출처:네이버 웹페이지]

차이 구별하시느라 수고하셨습니다. 네.....

유독 한글로 되어 있는 곳에서는 SLO는 Single Log-on 이라는 뜻으로 쓰이던데, 영문으로 검색해보니 SSO/SLO 라는 표현이 자주 보여 살펴보니 SLO가 Single Log-off 였습니다.

댓글 어떠한 분도 질문을 하셨고, 종종 Consumer Site에서 로그아웃하는 것을 IdP 입장에서 알 수 있느냐라고 물어 오시는데, 프로토콜 상 알 수 없다고 답했습니다.

Single Log Off 는 사실 SSO를 이루는 Token을 파기함으로써 클라이언트 입장에서는 더이상 로그인된 상태를 유지할 수 없게 되는 것과, 더불어 로그인 정보를 유지하여 공유하는 서버가 존재하여야 하고 이 서버에서도 로그인 토큰을 제거하는 형식으로 구성되어 있을 때 가능합니다.

OpenID는 현 스펙상 서버들간에 로그인 정보를 공유하는 어떤 체계가 존재하지 않기 때문에 Single Log-Off를 구현하기가 어렵습니다.

노파심에서 그러는데, 제발 저 네가지 용어를 구별하는 시도는 하지 말아주세요. 단, 뉘앙스의 차이가 있다는 착안에서 경험을 정리하는 것은 좋습니다만, 그것이 용어로 발전하기에는 어색합니다.
신고
  1. 세레 2009.08.15 14:16 신고

    제 블로그 http://legendre.tistory.com/338
    에 저도 나중에 비슷한 용어 글을 쓰고 혹시 전에 이미 이런 주제를 고민하신 분이 있지 않을까 해서 찾아보다가 이 글을 찾게 되었네요. 트랙백을 보내지 못해 이렇게 댓글이라도 남겨요. 좋은 글 잘 읽었습니다. 감사합니다.

단일 사용자 로그인(Single Sign On; SSO)은 다음과 같은 상황에서 일어납니다.
  1. 사용자 인증
  2. 인증을 공유할 같은 도메인 혹은 그 서브 도메인의 서버들
  3. 각 서버들은 그 기원이 서로 다른 서비스로 운영됨.
  4. 각 서비스들이 요구하는 사용자 정보는 최소한으로 ID 이며, 그 외에 이메일, 이름 등이 있음.
이를 위해서는
  1. 가장 공통의 인증을 위한 미들웨어 강제로 사용하는 방법이 있을 수 있고,
  2. 웹이라면 쿠키의 서브 도메인에 설정하는 기능을 이용하여, 전달 받은 쿠키를 공유하는 DB 질의를 통해서 접근하는 방법이 있으며
  3. 토큰하나를 캐시나 URL에 인코딩하여 전달한 뒤, 토큰의 진의 여부를 결정해주는 내부 서버를 두어 필요시마다 서버들간 대화를 하게 만들 수도 있고,
  4. 무식하게는 ID와 패스워드가 몰래몰래 네트웍을 날아다니게 만들 수 도 있습니다.`
OpenID는 하나의 사이트에 로그인할 때, 세 번의 질문을 하게 됩니다. 하나는 OpenID를 묻는 것이고, 두번째는 OpenID 자체의 소유여부를 확인하기 위한 비밀번호 등이고, 세번째는 인증정보를 전달할 도메인을 확인하고자함입니다. 대개 두번째 질문은 한 동안은 묻지 않고 유지 됩니다. 세번째도 만약 신뢰하는 사이트라면 묻지 않게 됩니다.

OpenID가 SSO를 구현하는데 사용된다고 합니다만, 이를 위해서는 로그인사이트(Consumer Site; Relying Party)들이 정교한 처리를 해주어야합니다. 몇몇의 서비스를 이용해 보셨지만, 한 사이트를 사용하다가 다른 사이트에 이동하게 되면, 적어도 셋 중 최초 자신의 OpenID는 넣어야 인증이 됩니다.

정교한 처리란, 이 OpenID 마저 다시 넣지 않는 개발이 필요한 것인데, 만약 그 사이트에 두 번째 들어간다면 처음 로그인할 때 쿠키를 설정해놓고 들어 오자마자 쿠키에 씌여 있는 OpenID로 로그인 시도를 할 수 있겠지요. (Jyte.com이 그런 행위를 하는 것 같습니다만, 때에 따라 그렇지 않은 것을 보아서 정확한 구조는 파악 못하였습니다.)

OpenID가 SSO에 사용된다는 것은, 최초 OpenID를 제출하고, 이것의 OpenID의 소유자임을 확인한 브라우져 세션에 대해 "계속 승인"으로 설정한 경우, OpenID를 제출하는 것만으로 로그인이 가능하다는 것을 의미합니다. 따라서, 최초에 제기한 조건들을 충분히 만족하지 않고, 이러한 가장 큰 이유는 로그인하는 서비스들이 모두 분산되어 있는 상황이기 때문입니다. 애초부터, 같은 조직이 아닌 서비스들을 단일 사용자 로그인을 지원한다는 것 자체는 보안상 상당히 취약한 생각입니다.

다음 글에는 환상을 품을 만한 실험 한 결과를 공유해 보겠습니다.

신고
  1. 하늘이 2007.04.08 02:13 신고

    오옷 실험 결과가 기대됩니다. +_+)=b
    (매일 오픈 아이디에 대해서는 눈팅만 해오다가 이제서야 먼가 하나 빤짝 도전해보려는 선량한 시민이랍니다. 흐흣)

+ Recent posts