8.5. Kerberos

设置 Kerberos 服务器的步骤取决于操作系统(OS)和 Kerberos 供应商。有关设置和配置 Kerberos 服务器的说明，请参阅 Windows Active Directory、MIT Kerberos 和您的操作系统文档。

在设置过程中，执行以下步骤：

sudo kadmin.local

然后，使用命令添加 HTTP 主体并将其密钥导出到 keytab 文件中，例如：

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

确保运行红帽构建的 Keycloak 的主机上可以访问 keytab 文件 /tmp/http.keytab。

在您的机器上安装 Kerberos 客户端。

客户端计算机必须具有 Kerberos 客户端并设置 krb5.conf，如上所述。客户端机器还必须在其浏览器中启用 SPNEGO 登录支持。如果您使用 Firefox 浏览器，请参阅为 Kerberos 配置 Firefox。

.mydomain.org URI 必须位于 network.negotiate-auth.trusted-uris 配置选项中。

在 Windows 域中，客户端不需要调整其配置。Internet Explorer 和 Edge 可以参与 SPNEGO 身份验证。

Kerberos 支持凭据委派。应用程序可能需要访问 Kerberos 票据，以便它们可以重复使用它与 Kerberos 保护的其他服务交互。由于红帽构建的 Keycloak 服务器处理 SPNEGO 协议，因此您必须在 OpenID Connect 令牌声明或 SAML 断言属性中将 GSS 凭证传播到您的应用程序。红帽构建的 Keycloak 会从红帽构建的 Keycloak 服务器将其传送到您的应用程序。要将此声明插入到令牌或断言中，每个应用都必须启用内置协议映射器 gss 委派凭据。这个映射程序可在应用程序的客户端页面的 Mappers 选项卡中提供。如需了解更多详细信息 ，请参阅协议映射程序 章节。

在使用应用程序对其他服务发出 GSS 调用前，应用程序必须反序列化来自红帽构建的 Keycloak 的声明。当您将凭证从访问令牌反序列化到 GSSCredential 对象时，请使用传递给 GSSManager.createContext 方法的这个凭证创建 GSSContext。例如：

// 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 协议中，realm 是一组 Kerberos 主体。这些主体的定义存在于 Kerberos 数据库中，通常是 LDAP 服务器。

Kerberos 协议允许跨域信任。例如，如果存在 2 个 Kerberos 域 A 和 B，则跨域信任将允许 realm A 中的用户访问 realm B 的资源。realm B 信任域 A.

Red Hat build of Keycloak 服务器支持跨域信任。要实现此目标，请执行以下操作：

查找用户基于 LDAP 存储提供者选项 Kerberos 主体属性。当这与 userPrincipalName 等值配置实例时，在用户 john@A 的 SPNEGO 身份验证后，红帽构建的 Keycloak 将尝试查找具有与 john@A 等效属性 userPrincipalName 的 LDAP 用户。如果 Kerberos 主体属性 留空，则红帽构建的 Keycloak 将根据其 kerberos 主体的前缀查找 LDAP 用户，并省略域。例如，Kerberos 主体用户 john@A 必须在 username john 下的 LDAP 中提供，因此通常位于 LDAP DN 下，如 uid=john,ou=People,dc=example,dc=com。如果您希望来自域 A 和 B 的用户进行身份验证，请确保 LDAP 可从域 A 和 B 中找到用户。

允许多个 Kerberos 域中的用户进行身份验证，因为每个用户都有属性 KERBEROS_PRINCIPAL 引用用于身份验证的 kerberos 主体，这用于进一步查找此用户。为了避免 kerberos 域 A 和 B 中存在用户 john 冲突，红帽构建的 Keycloak 用户的用户名可能包含 kerberos 域小写。例如，用户名应为 john@a。仅在域与配置的 Kerberos 域 匹配时，可以从生成的用户名中省略 realm 后缀。例如，只要 Kerberos 提供者上配置了 Kerberos 域是 A，Kerberos 主体 john 为 john。

如果您有问题，请启用额外的日志记录来调试问题：