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 协议，所以您必须将 GSS 凭证传播到 OpenID Connect 令牌声明或 SAML 断言属性中的应用程序。红帽构建的 Keycloak 从红帽构建的 Keycloak 服务器将其传送到您的应用程序。要将此声明插入到令牌或断言中，每个应用程序都必须启用内置协议映射器 gss delegation 凭据。此 映射程序位于应用程序客户端页面的映射程序 选项卡中。如需了解更多详细信息 ，请参阅协议映射程序 章节。

在使用应用程序对其他服务进行 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 协议中 ，域 是一组 Kerberos 主体。这些主体的定义存在于 Kerberos 数据库中，通常是 LDAP 服务器。

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

红帽构建的 Keycloak 服务器支持跨域信任。要实现此目的，请执行以下操作：

查找用户基于 LDAP 存储供应商选项 Kerberos 主体属性。当为实例配置了类似 userPrincipalName 的值的实例时，在用户 john@A 的 SPNEGO 身份验证后，红帽构建的 Keycloak 将尝试查找与 john@A 等效属性 userPrincipalName 的 LDAP 用户。如果 Kerberos 主体属性 留空，则 Keycloak 的红帽构建将根据其 kerberos 主体的前缀，并带有域省略的内容。例如，Kerberos 主体用户 john@A 必须在用户名 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。仅在 realm 与配置的 Kerberos 域 匹配时，可能会从生成的用户名中省略 realm 后缀。例如，只要 Kerberos 提供程序上配置了 Kerberos 域是 A，即 Kerberos 主体 john @ A 的 john。

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