Korean Identity Management(KIM)

title; Internet-Scale Identity Systems; An Overview and Comparison
link; http://www.pingidentity.com/resources/90

이 백서는 인터넷 규모에서 적용 가능한 Identity 시스템으로 SAML, CardSpace, OpenID, ID-WSF를 선택하여 간단한 기술적 내용을 소개하고 비교합니다. 몇 페이지 되지 않지만 기술적인 분석을 통해 차별성을 명확히 보여주어 많은 도움이 되었습니다.

그 중에서 제가 포스팅 할 내용은 OpenID 입니다. 이 백서에서는 OpenID의 스펙상 문제에 대해서 이야기하고 있습니다.

OpenID는 처음부터 매우 작은 시나리오를 처리하기 위해 설계되어 있습니다. 블로그에 코멘트를 남길 때 번거롭게 로그인하는 불편함과, 익명 로그인을 허가할 경우에 발생할 수 있는 스팸 코멘트를 차단하기 위해서 입니다. 하지만 OpenID는 너무 open 되어 있기 떄문에 스팸 코멘트에 효과적으로 대처하기 어려울 수 있습니다. 이전 포스트에서도 소개했던 익명 OpenID 서버가 여러 개로 늘어나서 스패머들이 활용하기 시작한다면, 지금 OpenID를 도입하셨던 분들은 어떻게 하실까요? OpenID를 지원하지 않을 것입니다.

OpenID was initally designed to address a very simple use case - enabling blog commenting in a controlled manner to protect against comment spam and misattribution.

OpenID는 url을 자신의 id로 하여 사용할 수 있습니다. 보통 하나의 id만 있어도 OpenID를 적용한 모든 사이트에서 사용 가능합니다. 하나의 OpenID을 사용한다면 자신을 좀 더 일관성있게 표현할 수 있고, reputation 측면에서도 유용합니다. 하지만 privacy 측면에서 바라본다면, 하나의 OpenID는 privacy 침해 문제를 일으킬 수 있습니다. 지금 구글에 자신이 사용하는 id를 입력해 보면, privacy 가 어떻게 노출될 수 있는지 느낄 것입니다.

if the user provides the same URI to multiple RPs this URI could enable inappropriate correlation by malicious RPs.

OpenID는 이 문제를 해결하기 위해서 자신의 url이 아니라 idp의 주소를 넘겨주는 방법을 선택적으로 제공한다고 합니다. 그러면 로그인하기 전에는 사용자의 OpenID가 노출되지 않겠죠. 하지만 로그인 한 뒤에는 IDP가 사용자의 id를 SP로 넘겨줍니다. 저는 IDP가 SP로 넘겨주는 id를 어떻게 설정하는지 여부에 따라서 privacy 문제가 해결될 수 있다고 생각합니다.

Partially to address this concern, OpenID 2.0 has added the option for the user to provide merely the address of their IDP and not a URL that uniquely identifies them at their IDP.

OpenID는 인터넷 상에서 unique 한 id를 사용합니다. 이 방법은 reputation을 제공해 주겠지만, privacy 침해 문제 또한 일으킬 수 있습니다. 하지만 sp가 사용자의 unique한 id를 알 수 없게 만들면 문제가 해결되지 않을까요? 사용자가 idp에 openid로 로그인 한 뒤에 여러 개의 설정된 id 중에서 원하는 id를 사용하는 방식이 괜찮을 것 같다고 생각합니다.

OpenID를 사용하면서 가장 번거로운 것은 자신의 url을 매번 입력해야 한다는 것입니다. 꼭 타이핑 할 필요는 없습니다. cookie에 자신의 url 또는 IDP의 주소를 설정해 두는 방법을 사용하면 됩니다. 이 방법은 SAML에서 제공하는 IDP introduction cookie라는 기술입니다. OpenID에서도 동일하게 제공할 수 있습니다.

마지막으로 백서에서 소개하는 시나리오 중에서 틀렸다고 생각하는 부분이 있어서 적어봅니다. 아래 그림은 CardSpace와 OpenID, SAML을 연계하는 시나리오를 보여주고 있는데, 중간에 있는 isp.com은 OpenID와는 dynamic trust를 유지하고 SAML과는 static trust를 유지하고 있습니다.
우선 SAML을 사용하려면 isp.com은 games.com과 ID 정보를 교환해야 합니다. 시나리오에서 말하는 것처럼 동작하려면 OpenID로 로그인 한 뒤에 isp.com의 로컬 id를 추출하고, games.com 과 합의된 id로 SAML 메시지를 보내야 합니다.
제가 의문스러운 부분은 OpenID로 isp.com에 로그인 한 뒤에, isp.com에 저장된 로컬 id를 추출하기 위해서는 미리 OpenID와 로컬id를 연동하는 작업이 처리되어야 한다는 것입니다. 그런 작업이 있다면 이미 dynamic trust가 아니죠. 미리 합의된 OpenID를 사용한다면 그건 static trust가 되는 것입니다. dynamic trust가 되려면 어떤 OpenID를 쓰더라도 사용자의 로컬id를 제대로 이끌어 내야 할텐데, 그게 가능할까요? 그래서 저는 이 시나리오가 틀렸다고 생각합니다. 다른 분들은 어떻게 생각하시나요?