클라이언트는 회사 솔루션 (Active Directory)을 기반으로하는 "단일 사인온"인증 기능을 사용자에게 제공하기 위해 주요 응용 프로그램이 필요합니다. 이것은 비즈니스 응용 프로그램이 브라우저에서 제공하는 자격 증명을 신뢰하고 표준 로그인/암호 쌍을 제공하도록 사용자에게 요청하지 않음을 의미합니다. 서버/브라우저 트러스트는 Windows 통합 인증 메커니즘을 기반으로합니다.ASP.Net 웹 응용 프로그램의 단일 사인온
우리는 닷넷 프레임 워크 2.0에서 IIS 5에서 호스팅되는 ASP.Net 웹 응용 프로그램입니다. 우리는 SSO 기능을 구현해야합니다. 우리는 어떻게합니까?
저는 이것이 거의 모든 인트라넷 응용 프로그램이 따르는 요구 사항이라고 확신합니다.
IIS에서 Windows 통합 로그인을 방금 활성화 한 경우 # 1 항목으로 설정됩니다.
다른 요구 사항과 충돌하기 때문에 # 2도 가능할지 모르겠습니다. 브라우저는 로컬로 로그인 한 사용자의 자격 증명 만 전달합니다 (# 1에서 요구하는대로). 광고를 통해 인증 할 웹 양식을 만든 경우 귀하의 서술/단락에 나열된 요구 사항을 위반하게됩니다.
귀하의 고객은 # 2가 실제로 무엇을 의미한다고 생각합니까? 그들이 뭘 원하는거야? 다른 사용자로 로그인하는 방법? 그들은 단지 컴퓨터에서 로그 오프하고 다른 사용자로 로그인 할 수 있습니다.
일반적으로 SSO 요구 사항은 WS-Federation 또는 SAML 2.0과 같은 클레임 기반 프로토콜에서 가장 잘 처리됩니다. 원칙적으로 개방형 표준이기 때문에 이러한 프로토콜을 직접 구현할 수 있지만 많은 전문 지식이 필요합니다.
새로운 Windows Identity Foundation (이전의 Geneva 프레임 워크)에는 SSO 시나리오를 사용할 수있는 프로토콜 구현이 포함되어 있지만 플랫폼을 업그레이드해야합니다.
ID 및 암호를 입력하라는 메시지가 표시되지 않고 사용자 지정 양식 인증을 사용하십시오.
전제 조건 : 1> 데이터베이스 테이블 등등 이메일, 역할과 사용자의 세부 사항을 가진 사용자 프로필 3>가에서 사용자의 도메인과 이름을 읽을 수있는 VBCOM 또는 ActiveX 또는 다른 구성 요소를 쓰기 저장됩니다 2> 기업 활성 디렉토리 브라우저를 통해 Windows 컴퓨터.
단계 : 모든 양식에 대한 pageload에서 < 3> Active Directory에 연결하려면 < 2> 구성 요소를 호출하십시오. 그 방법은 Windows 시스템에서 현재 사용자 이름, 도메인을 읽어야합니다. 세부 정보가 포함 된 AD를 검색합니다. 그렇다면 AD 사용자 프로필에서 이메일 주소 또는 고유 키 중 하나를 쿼리하고 추출하십시오. 전자 메일, 역할과 같은 응용 프로그램 관련 사용자 세부 정보를 저장 한 데이터베이스 <>이 키 쿼리를 사용하십시오. AD의 사용자 전자 메일이 테이블의 전자 메일과 일치하는 경우 사용자가 존재하지 않거나 역할이 null/restricted 인 경우 액세스 권한을 거부하는 적절한 권한을 사용자에게 부여합니다. 유효한 사용자가 암호화 된 쿠키를 만들고 다른 응용 프로그램에서 읽을 수 있으면 실제로 모든 종류의 SSO를 구현할 수 있습니다.