8.4. Kerberos

Kerberos 서버를 설정하는 단계는 운영 체제(OS) 및 Kerberos 벤더에 따라 다릅니다. Kerberos 서버 설정 및 구성에 대한 지침은 Windows Active Directory, MIT Kerberos 및 OS 설명서를 참조하십시오.

설치하는 동안 다음 단계를 수행합니다.

sudo kadmin.local

그런 다음 HTTP 주체를 추가하고 다음과 같은 명령을 사용하여 키를 키 탭 파일에 내보냅니다.

addprinc -randkey HTTP/www.mydomain.org@MYDOMAIN.ORG
ktadd -k /tmp/http.keytab HTTP/www.mydomain.org@MYDOMAIN.ORG

Red Hat Single Sign-On이 실행 중인 호스트에서 키 탭 파일 /tmp/http.keytab 에 액세스할 수 있는지 확인합니다.

시스템에 Kerberos 클라이언트를 설치합니다.

클라이언트 시스템에는 Kerberos 클라이언트가 있어야 하며 위에 설명된 대로 10.0.0.15.conf 를 설정해야 합니다. 클라이언트 머신은 브라우저에서도 10.0.0.1EGO 로그인 지원을 활성화해야 합니다. Firefox 브라우저를 사용하는 경우 Kerberos용 Firefox 구성을 참조하십시오.

.mydomain.org URI는 network.negotiate-auth.trusted-uris 구성 옵션에 있어야 합니다.

Windows 도메인에서 클라이언트는 구성을 조정할 필요가 없습니다. Internet Explorer 및 Edge는 이미 SelectEGO 인증에 참여할 수 있습니다.

Kerberos는 자격 증명 위임을 지원합니다. 애플리케이션은 Kerberos 티켓으로 보호되는 다른 서비스와 상호 작용하기 위해 다시 사용할 수 있도록 Kerberos 티켓에 액세스해야 할 수 있습니다. Red Hat Single Sign-On 서버에서 ChronyEGO 프로토콜을 처리했기 때문에 GSS 인증 정보를 OpenID Connect 토큰 클레임 또는 SAML 어설션 특성 내에서 애플리케이션에 전파해야 합니다. Red Hat Single Sign-On은 이를 Red Hat Single Sign-On 서버에서 애플리케이션에 전송합니다. 이 클레임을 토큰 또는 어설션에 삽입하려면 각 애플리케이션에서 기본 제공 프로토콜 매퍼 위임 자격 증명을 활성화해야 합니다. 이 매퍼는 애플리케이션 클라이언트 페이지의 Mappers 탭에서 사용할 수 있습니다. 자세한 내용은 프로토콜 맵퍼 장을 참조하십시오.

애플리케이션은 다른 서비스에 대해 GSS를 호출하기 전에 Red Hat Single Sign-On에서 수신하는 클레임을 역직렬화해야 합니다. 액세스 토큰에서 GSSCredential 오브젝트로 인증 정보를 역직렬화할 때 이 인증 정보를 사용하여 GSSContext를 GSSManager.createContext 메서드로 전달합니다. 예를 들면 다음과 같습니다.

// Obtain accessToken in your application.
KeycloakPrincipal keycloakPrincipal = (KeycloakPrincipal) servletReq.getUserPrincipal();
AccessToken accessToken = keycloakPrincipal.getKeycloakSecurityContext().getToken();

// Retrieve Kerberos credential from accessToken and deserialize it
String serializedGssCredential = (String) accessToken.getOtherClaims().
    get(org.keycloak.common.constants.KerberosConstants.GSS_DELEGATION_CREDENTIAL);

GSSCredential deserializedGssCredential = org.keycloak.common.util.KerberosSerializationUtils.
    deserializeCredential(serializedGssCredential);

// Create GSSContext to call other Kerberos-secured services
GSSContext context = gssManager.createContext(serviceName, krb5Oid,
    deserializedGssCredential, GSSContext.DEFAULT_LIFETIME);

Kerberos 프로토콜에서 영역은 Kerberos 사용자 집합입니다. 이러한 주체의 정의는 일반적으로 LDAP 서버인 Kerberos 데이터베이스에 있습니다.

Kerberos 프로토콜은 교차 영역 신뢰를 허용합니다. 예를 들어, 2개의 Kerberos 영역인 A 및 B가 존재하는 경우 교차 영역 신뢰를 통해 영역 A에서 영역 B의 리소스에 액세스할 수 있습니다. 영역 B는 영역 A를 신뢰합니다.

Red Hat Single Sign-On 서버는 교차 영역 신뢰를 지원합니다. 이를 구현하려면 다음을 수행합니다.

사용자를 찾는 것은 LDAP 스토리지 공급자 옵션 Kerberos 주체 속성을 기반으로 합니다. userPrincipalName 과 같은 값이 있는 인스턴스에 대해 구성된 경우, john@A ; 사용자 john@A )의 CryostatEGO 인증 후 Red Hat Single Sign-On은 john@A 와 동등한 userPrincipalName 특성을 사용하여 LDAP 사용자를 조회하려고 합니다. Kerberos 주체 속성이 비어 있으면 Red Hat Single Sign-On은 해당 영역을 생략한 kerberos 주체 접두사를 기반으로 LDAP 사용자를 조회합니다. 예를 들어 Kerberos 주체 사용자 john@A 는 사용자 이름 john 아래의 LDAP에서 사용할 수 있어야 하므로 일반적으로 uid= john,ou=People,dc=example,dc=com 과 같은 LDAP DN에서 사용할 수 있습니다. 영역 A 및 B의 사용자가 인증하도록 하려면 LDAP에서 A 영역 A와 B의 사용자를 모두 찾을 수 있는지 확인합니다.

여러 Kerberos 영역의 사용자는 모든 사용자에게 인증에 사용되는 kerberos 주체를 참조하는 KERBEROS_PRINCIPAL 속성이 있으므로 인증할 수 있으며, 이는 이 사용자를 추가로 조회하는 데 사용됩니다. kerberos 영역 A 및 B 모두에 사용자 john 이 있는 경우 충돌을 방지하기 위해 Red Hat Single Sign-On 사용자의 사용자 이름에 kerberos 영역이 소문자로 포함될 수 있습니다. 예를 들어 사용자 이름은 john@a 입니다. 구성된 Kerberos 영역과 realm이 일치하는 경우에만 realm 접미사가 생성된 사용자 이름에서 생략될 수 있습니다. 예를 들어 Kerberos 공급자에서 Kerberos 영역을 구성하는 경우 Kerberos 주체 john @ A 의 사용자 이름은 john입니다.

문제가 있는 경우 추가 로깅을 활성화하여 문제를 디버깅합니다.