Jetty 12.0.x SPNEGO: 전체 principal이 아니라 서비스 이름을 설정하세요

Jetty SPNEGO 구성에는 세 가지 이름이 있습니다. 인증을 매칭하는 URI, JAAS로 로그인하는 사용자, 티켓을 요청하는 대상 서비스입니다. 각각 역할이 다릅니다.

Jetty 12.0.x 구현에서 인증 객체의 일부는 다음과 같습니다.

var auth = new org.eclipse.jetty.client.SPNEGOAuthentication(
    java.net.URI.create("http://proxy.example:8080"));
auth.setServiceName("HTTP");

이 조각은 서비스 구성 요소를 보여 주며, 완전한 프록시 인증 절차가 아닙니다. JAAS 로그인, 프록시 라우팅, 요청의 인증 교환은 별개로 남습니다.

이 구현에서 Jetty는 getServiceName(), @ 문자, 인증 교환에 사용할 호스트를 결합해 GSS 호스트 기반 이름을 만듭니다. [email protected]을 서비스 구성 요소로 넘기면 호스트가 하나 더 붙습니다. 전체 Kerberos principal을 받는다고 가정하지 말고 이 setter의 계약을 읽으세요.

결과 GSS 이름은 개념적으로 HTTP@hostname 형태입니다. KDC의 대응 서비스 principal은 보통 HTTP/hostname으로 표현됩니다. 선택한 프록시 이름이 실제로 등록된 서비스와 일치해야 합니다은 해당 계정에 대한 것이며, IP 주소나 별칭은 다른 티켓 대상을 선택할 수 있습니다.

407 경로도 확인하세요

Jetty 12.0.x에서 authenticate()는 request.getHost()에서 GSS 호스트 이름을 가져오고 기본 Authorization 헤더로 결과를 구성합니다. 프록시 URI로 인증 객체를 매칭한다고 해서 그 선택이 저절로 프록시의 호스트 이름과 Proxy-Authorization으로 바뀌지는 않습니다.

따라서 프록시 통합에는 해당 교환에 맞는 올바른 요청 호스트와 프록시 범위의 결과가 필요합니다. HTTPS CONNECT 요청과 일반 오리진 요청은 호스트 값이 다를 수 있습니다. 서비스 이름 setter가 407 전체 흐름을 제공한다고 가정하지 말고 설치된 구현의 동작을 확인하세요.

407의 경우 해당 요청이 사용한 프록시 인증 교환과 호스트를 확인하세요. 401은 오리진 인증에 속합니다. 유효한 사용자 티켓만으로는 Jetty가 올바른 서비스 티켓을 요청했는지, 중간 장치가 이를 수락했는지 증명되지 않습니다.