선택적 kerberos 인증을 수행 할 수 있습니까?선택적 SPNEGO Kerberos 인증
내가 원하는 것 : 클라이언트 (브라우저)가 도메인에 없으면 사용자 이름/비밀번호 웹 로그인으로 리디렉션됩니다. 그렇지 않으면 SPNEGO Kerberos 인증을 수행합니다.
WWW-Authenticate : Negotiate 헤더를 비 도메인 브라우저로 보내면 아무 것도 할 수 없습니다.
인증 방법을 모르는 경우 다른 것을 시도하도록 브라우저에 알리는 옵션이 있습니까? 아니면 "WWW-Authenticate"헤더를 보내기 전에 사용자가 도메인의 일부인지 확인해야합니까?
공개적으로 표준 방식으로 해결 한 사람을 찾지 못했습니다. 예, 언급 한 바와 같이 Basic으로 폴백 할 수 있지만 브라우저에서 볼 때까지 아니요으로 떨어지는 CGI 양식에서 사용자 이름과 비밀번호를 요청하는 인증 방식에는 작동하지 않습니다. Negotiate이 실패하면 인증. 어쩌면 인증 체계가 고장났다는 것을 암시 할 수 있습니까? 나는 모른다.
먼저 내가 아는 것을 말할 것입니다. 우리 사이트는 효과적으로 Cosign으로 보호되어 있으므로 우리는 비슷한 문제가 있습니다 : 특별히 구성된 컴퓨터 만 WWW-Authenticate 헤더에 응답하므로 기본적으로 모든 사용자를 Cosign 로그인 페이지로 보내야합니다. Cosign 서버는 인증 된 GSSAPI/Kerberos 호스트가 로그인 세부 정보를 입력하지 않고 인증 프로세스를 완료 할 수 있도록 해줍니다. 문제 해결 방법을 통해 특정 브라우저에서만 가능합니다.
이 해결 방법은 로그인 페이지에서 SPNEGO로 보호 된 리소스의 HEAD을 시도하는 자바 스크립트 블록으로 구성되어 있습니다. 성공하면 스크립트는 브라우저를 SPNEGO로 보호 된 동일한 페이지의 페이지로 리디렉션합니다. 그러면 적절한 Cosign 쿠키가 부여되고 암호 입력없이 프로세스가 완료됩니다. 브라우저에 JavaScript, Kerberos 지원 또는 적절한 자격 증명이없는 경우 사용자는 평소대로 cosign 로그인 페이지를 볼 수 있습니다.
위의 내용만으로도 귀하의 질문에 대한 답을 얻을 수 있습니다. 개인적으로는 충분하지 않다고 생각 하긴하지만 다음은 토론에 대한 것입니다.
위의 내용은 연결하는 모든 사용자 에이전트가 JavaScript를 지원한다고 주장하기 때문에 불만족 스럽습니다. 웹 브라우저, HTTP 클라이언트 라이브러리) 또는 Kerberos 가능 사용자를 리디렉션하는 임의 경로에 대한 지식 (우리 사이트에서는 하드 코드되지 않은 모든 것에 쓸모가 없습니다.) 나는 더 나은 해결 방법이있을 수 있다고 결론을 내 렸습니다. 그렇지 않을 경우, 표준이 있어야 할 틈이 생겼습니다. 내가 가진 가장 실용적인 제안은 다음과 같습니다.
클라이언트가 초기 응답이 HTTP 401이지만 헤더가 WWW-Authenticate: Negotiate 인 페이지를 검색하려고하는 것은 정상적인 부분입니다. 이것은 GSSAPI/Kerberised 클라이언트가 적절하게 응답 할 수있는 신호입니다. "일반"클라이언트는 단순히 오류 페이지를 표시합니다. 아마도 해결책은이 오류 응답의 일부로 사람 친화적 인 로그인 페이지를 제공하도록 Cosign 서버를 수정하는 것일뿐입니다.
은 기성품의 Apache 및 모듈을 사용하는 것이 기술적으로 어려울 수 있으며 다양한 표준 (또는 적어도 원칙)을 위반할 수 있습니다. 나는 관련 시스템에 대한 전문가가 아니므로, 시도하지 않으면 (또는 때까지) 추측 할 수 있습니다 ...
사용자 이름/비밀번호 확인을 위해 WWW-Authenticate: Basic을 추가로 보냅니다.
나는 OP와 정확히 같은 문제를 겪고 있습니다. 그동안 해결 된 솔루션이 있다면 궁금합니다. 로그인 페이지가 도메인 외부에서 액세스 될 때 Kerberos 프로세스는 401을 수신 한 후 클라이언트 측에서 중지합니다.이 두 인증 방법을 병렬로 실행하는 방법 (gracking JavaScript 해킹 이외의 방법)이 있습니까? –