2008-10-24 2 views
4

싱글 사인온 (single sign-on)을 원한다고 여러 사이트 (Asp.Net)가 있습니다 ...싱글 사인온을 이해하는 사이트 네트워크는 어떻게 만듭니 까?

사용자가 Site1을 방문하여 Site1에 중앙 싱글 사인온 서버 (SSS).

그러면 SSS는 사용자가 로그온하지 않았는지 (확실하지 않음) 사용자를 로그온 화면 (SSS에서 계속)으로 리디렉션합니다.

인증되면 사용자는 Site1로 다시 리디렉션됩니다.

Site1은이 도착을 새 것으로 처리하고 사용자가 로그온 한 경우 SSS에 요청할 수 있습니다. 이번에 SSS는 해당 사용자가 실제로 로그온했음을 알릴 것입니다. 그래서 Site1은 향후 참조를 위해 세션에이 사실을 저장할 수 있습니다 (아마도 적절한 시간 초과가있을 수 있습니다)

Site1에는 사용자가 선택할 수있는 Site2에 대한 링크가 포함됩니다.

Site2에 도착하면 Site2가 사용자를 인증하려고 시도합니다.

이미 Site1을 방문한 동일한 사용자로 Site2에 도착하는 사용자를 식별하고 두 번째로 로그인 할 필요가 없도록 이미 인증되었음을 알 수 있습니까?

참고 : SSS는 계정 생성을 제어하는 ​​개인 시스템이어야합니다. 그래서 외부의 OpenID 서버에 의존 할 수 없다는 게 두렵습니다.

업데이트 : 현재 Site1, Site2 및 SSS가 동일한 도메인 내에 있음을 보장 할 수 없습니다. 라고 생각하면 쿠키가 잘라냅니다.

+0

이것은 포르노 사이트 네트워크입니까? ;) – User

답변

2

OpenID를 너무 빨리 버리지 마십시오. 사이트 소유자는 지원할 OpenID 공급자를 선택할 수 있습니다. 자신의 OpenID 서버를 실행하고 신뢰할 수있는 서버 만 선택할 수 있습니다.

또한 OpenID는 인증을위한 시스템입니다. 즉, 사용자 X가 자신이 말하는 사람들임을 증명하는 방식입니다.

여기 StackOverflow에서 누군가가 OpenID를 사용하여 로그온 할 때 자동으로 계정을 만들지 만 그렇게 할 필요는 없습니다. 각 계정과 연결된 OpenID를 사용하여 계정 생성을 완전히 제어 할 수 있습니다.

(일반적으로) 작성하고 유지 보수 할 필요가없는 소프트웨어는 좋은 점을 기억하십시오.

+0

"자신의 OpenID 서버를 실행하고 신뢰할 수만 있습니다." - 좋아, 그 재미있는 소리 ... 어떤 제안이 연구를 시작하는 곳? –

+0

여기부터 시작하겠습니다. http://openid.net/developers/ – Bevan

0

공유 세션 상태 서버를 사용해 볼 수 있습니다.

+0

그게 재미있을 것 같은데 ...하지만 어떤 독특한 정보를 Site1과 Site2가이 서버에 전달하여 둘 다 동일한 사람으로 사용자를 표시하게 할 수 있습니까? –

0

쿠키를 사용하여 사용자의 인증 티켓을 저장하고 만들 수 있습니다. 우리는 여러 번 해봤고 꽤 잘 진행되었습니다.

+0

쿠키가 도메인 특정 적이라고 생각했습니다. Site1, Site2 및 SSS *는 다른 도메인에있을 수 있으므로 서로 쿠키를 읽을 수 없습니까? –

+0

글쎄, 어떻게 처리 했는가. 우리는 사이트에 기본 사인을 가지고 있습니다. 우리는 site1이라고 부르며, site1은 site2에 대한 링크를 가지고 있습니다.이 링크를 따라 가면 site1은 site2의 인증 양식에 사용자 이름을 사용하여 해당 페이지에 대한 게시를 수행 한 다음 티켓을 만듭니다. 미안, 우리가 그걸로 usecookie하지 않았다는 걸 잊어 버렸다. – thismat

+0

기본적으로 site1은 SSO 솔루션이되고 site2에 대한 인증을 처리합니다.하지만 site2를 처음 방문하는 경우 인증을 처리하는 사이트로 리디렉션해야합니다. 큰 문제는 아닙니다. – thismat

1

GET 또는 POST가있는 사이트간에 DB 생성 토큰을 전달한 다음 동일한 토큰을 DB에 직접 연결하는 웹 서비스로 다시 확인합니다.

사용자가 사이트 1 (www.domain1.com)에 들어가기를 원합니다. 사이트 1에서 로컬 도메인 로그인 세션/쿠키를 확인하고 찾을 수 없으면 http://logindomain.com/?return=www.domain1.com으로 사용자를 리디렉션합니다. 이전 로그인 아이디 쿠키 (로그인 사이트에서 제휴 사이트로)가 있으면 사이트 1로 다시 보내십시오.그렇지 않다면 KERBEROS 검사, Forms auth, openID 등 필요한 사용자 인증을 수행하여 고유 한 토큰을 생성하십시오. 그 쿠키를 logindomain의 쿠키에 저장하고 토큰이 첨부 된 "return"이 가리키는 곳으로 다시 리다이렉션하십시오 : http://www.domain1.com/?token=123456. domain1이 웹 서비스 (또는 토큰 DB에서 직접)에 대해 토큰의 유효성을 검사하면 사용자 자격 증명으로 자체 로컬 로그인 세션/쿠키를 설정할 수 있습니다.

이제 사이트 2 (www.domain2.com)에 로그인하여 로그인하십시오. 돌아 오는 var 세트로 다시 logindomain으로 리디렉션되지만 이번에는 비밀번호를 묻지 않습니다 - 이미 SSO 쿠키에 토큰이 있습니다. 즉시 http://www.domain2.com/?token=123456 (사이트 1과 동일한 토큰 사용)으로 리디렉션됩니다. Domain2는 토큰의 유효성을 다시 확인하고 암호 확인없이 사용자를 허용합니다.

즉석에서 로그인 URL을 변경하거나 하이브리드 AD/Forms Auth 괴물을 만들려고 시도하는 경우 빌드가 정해졌지만 조금 더 복잡해 지지만 제대로 작동하고 정확하게 일치합니다 높은 수준) IBM과 MS의 독점적 인 SSO 시스템이 말하는 것은 무엇입니까?

관련 문제