8.4. Kerberos

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

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

sudo kadmin.local

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

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

在运行 Red Hat Single Sign-On 的主机上，确保 keytab 文件 /tmp/http.keytab 可访问。

在机器上安装 Kerberos 客户端。

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

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

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

Kerberos 支持凭据委派。应用程序可能需要访问 Kerberos ticket，以便可以重新使用它与 Kerberos 保护的其他服务交互。因为 Red Hat Single Sign-On 服务器处理 SPNEGO 协议，所以您必须将 GSS 凭证传播到 OpenID Connect 令牌声明或 SAML 断言属性中的应用程序。Red Hat Single Sign-On 从 Red Hat Single Sign-On 服务器将其传输到您的应用程序。要将此声明插入到令牌或断言中，每个应用程序都必须启用内置协议映射程序 gss delegation 凭据。此 映射程序 位于应用程序客户端页面的"映射程序"选项卡中。如需了解更多详细信息 ，请参阅协议映射程序 章节。

应用程序必须反序列化它从 Red Hat Single Sign-On 接收的声明，然后才能向其他服务发出 GSS 调用。当您将凭证从访问令牌映射到 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 Single Sign-On 服务器支持跨域信任。要做到这一点，请执行以下操作：

查找用户基于 LDAP 存储供应商选项 Kerberos 主体属性。当为实例配置了类似 userPrincipalName 的值的实例时，在用户 john@A 的 SPNEGO 身份验证后，Red Hat Single Sign-On 将尝试查找与 john@A 等效属性 userPrincipalName 的 LDAP 用户。如果 Kerberos 主体属性 留空，则 Red Hat Single Sign-On 将根据其 kerberos 主体的前缀并使用域省略来查找 LDAP 用户。例如，Kerberos 主体用户 john@A 必须在用户名 john 下的 LDAP 中可用，因此通常位于 LDAP DN 下，如 uid=john,ou=People,dc=example,dc=com。如果您希望域 A 和 B 中的用户进行身份验证，请确保 LDAP 可以从 realms A 和 B 中查找用户。

支持多个 Kerberos 域中的用户，因为每个用户都有属性 KERBEROS_PRINCIPAL 引用用于身份验证的 kerberos 主体，这用于进一步查找此用户。为了避免在 kerberos realm A 和 B 中用户 john 时存在冲突，Red Hat Single Sign-On 用户的用户名可能包含 kerberos 域小写。例如，用户名将是 john@a。仅在 realm 与配置的 Kerberos 域 匹配时，可能会从生成的用户名中省略 realm 后缀。例如，只要 Kerberos 提供程序上配置了 Kerberos 域是 A，即 Kerberos 主体 john @ A 的 john。

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