통합 인증을 사용하는 인트라넷 포털을 개발 중이지만 사이트의 일부 섹션은 도메인에없는 사용자에게 노출됩니다. 해당 사용자의 경우 익명 액세스를 사용할 계획입니다. 그러나 전체 응용 프로그램에 대한 우리의 표시 논리는 포털에 로그인 한 사용자를 기반으로하므로이 방법을 충분히 사용하지는 못합니다. 두 유형의 사용자 모두 URL이 같아야하고 두 환경 사이를 전환해야합니다.SharePoint 환경의 인증
인증을 위해 페이지의 사용자 컨트롤을 사용해 보았지만 문제가 발생하지 않았습니다. 페이지에 도달하면 표준 Windows 인증 회색 상자가 나타납니다.
HTTP 응용 프로그램과 같이 IIS 수준에서 요청을 가로 챌 수있는 방법이 있습니까? 해당하는 경우 익명 액세스를 사용하지 않도록 설정하고 인증되지 않은 사용자의 경우 가장 적은 권한을 가진 도메인 계정으로 가장하고 홈 페이지로 리디렉션합니다.
SharePoint는 실제로 인증 유형을 혼합하는 시나리오에 맞게 설계되지 않았습니다. 그것은 하나의 인증 유형웹 응용 프로그램을 바칩니다. 그런 다음 다른 주소에서 다른 유형의 인증을 사용하도록 웹 응용 프로그램을 '확장'할 수 있습니다. 예를 들어 인트라넷 포털은 Windows 인증을 사용합니다. 그런 다음 다른 포트 또는 도메인 이름에서 익명 인증을 사용하도록 확장 될 수 있습니다.
두 가지 별도의 웹 응용 프로그램을 구성하는 것이 하나의 옵션입니다. 하나는 인증이 필요한 사용자를위한 것입니다. 다른 하나는 익명 액세스를위한 것입니다. 적절한 위치에 콘텐츠를 구성하고 필요에 따라 둘 사이를 연결하십시오. 이 접근법을 사용하는 경우 도메인 내의 사용자는 인증 된 사이트에 연결할 때 로그인 프롬프트를받지 않아야합니다. 도메인 외부의 사용자는 로그인 상자를 받게되며 액세스 할 수 없습니다.
인트라넷에 액세스해야하는 경우 도메인 외부 사용자에 대해 폼 인증을 사용해보십시오. 다시 한번 사이트의 '폼 인증 된'부분은 고유 한 도메인 이름 또는 포트로 확장됩니다. 이는 처음 연결할 때 페이지의 양식에 자격 증명을 입력하라는 메시지가 표시된다는 의미입니다.
Authentication Resource Center에서 인증에 대한 자세한 내용을 읽어보십시오.
몇 가지 마지막 점 ... 자신의 컨트롤을 작성하는 대신 SharePoint의 기본 인증 메커니즘을 사용할 수 있다면 제대로 테스트되고 안전하게 수행되므로 사용할 수 있습니다. 또한 은 다른 방법이 필요 없다고 확신하지 않는 한 SharePoint의 IIS 설정을 변경하지 않으려합니다. SharePoint는 이러한 내용을 정기적으로 업데이트하고 변경 사항을 덮어 쓰거나 다른 방법으로 슬픔을 줄 수 있습니다.