8.5. 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 build of Keycloak が実行されているホスト上で、keytab ファイル /tmp/http.keytab にアクセスできることを確認します。

Kerberos クライアントをマシンにインストールします。

クライアントマシンには Kerberos クライアントが必要であり、上記 のように、krb5.conf を設定する必要があります。クライアントマシンは、ブラウザーの SPNEGO ログインサポートも有効にする必要があります。Firefox ブラウザーを使用している場合は、configuring Firefox for Kerberos を参照してください。

.mydomain.org URI は network.negotiate-auth.trusted-uris 設定オプションになければなりません。

Windows ドメインでは、クライアントは設定を調整する必要はありません。Internet Explorer および Edge は、すでに SPNEGO 認証に参加できます。

Kerberos は認証情報の委譲をサポートします。アプリケーションは Kerberos チケットを再利用して Kerberos でセキュリティーが保護された他のサービスと対話できるように、チケットへのアクセスが必要になる場合があります。Red Hat build of Keycloak サーバーが SPNEGO プロトコルを処理するため、OpenID Connect トークン要求または SAML アサーション属性内のアプリケーションに GSS 認証情報を反映させる必要があります。Red Hat build of Keycloak はこれを Red Hat build of Keycloak サーバーからアプリケーションに送信します。この要求をトークンまたはアサーションに挿入するには、各アプリケーションはビルトインプロトコルマッパー gss delegation credential を有効にする必要があります。このマッパーは、アプリケーションのクライアントページの Mappers タブで利用できます。詳細は、プロトコルマッパー の章を参照してください。

アプリケーションは、Red Hat build of Keycloak から受信する要求を使用して他のサービスに対して 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 プロトコルでは、レルム は Kerberos プリンシパルのセットです。これらのプリンシパルの定義は Kerberos データベース (通常は LDAP サーバー) に存在します。

Kerberos プロトコルは、レルム間の信頼を許可します。たとえば、2 つの Kerberos レルム A および B が存在する場合は、レルム間の信頼により、レルム A のユーザーがレルム B のリソースにアクセスできるようになります。レルム B がレルム A を信頼します。

Red Hat build of Keycloak サーバーは、レルム間の信頼をサポートします。これを実装するには、以下を実行します。

ユーザーの検索は、LDAP ストレージプロバイダーオプションの Kerberos principal attribute に基づきます。これがたとえば userPrincipalName などの値で設定されている場合、ユーザー john@A の SPNEGO 認証後、Red Hat build of Keycloak は john@A と同等の userPrincipalName 属性を持つ LDAP ユーザーを検索しようとします。Kerberos principal attribute が空のままの場合、Red Hat build of Keycloak は、レルムを省略した Kerberos プリンシパルの接頭辞に基づき LDAP ユーザーを検索します。たとえば、Kerberos プリンシパルユーザーの john@A は、LDAP 内 (通常は uid=john,ou=People,dc=example,dc=com などの LDAP DN 配下) でユーザー名 john として使用できる必要があります。レルム A および B からのユーザーを認証する場合は、LDAP がレルム A と B 両方からのユーザーを見つけられるようにします。

すべてのユーザーは、認証に使用される Kerberos プリンシパルを参照する KERBEROS_PRINCIPAL 属性を持ち、これを使用してさらにユーザーを検索するため、複数の Kerberos レルムからのユーザーの認証が許可されています。Kerberos レルム A と B の両方に john というユーザーが存在する場合、競合を回避するために Red Hat build of Keycloak ユーザーのユーザー名には Kerberos レルムが小文字で含まれる場合があります。たとえば、ユーザー名は john@a になります。設定された Kerberos realm とレルムが一致する場合に備えて、生成されたユーザー名からレルムの接尾辞が省略される場合があります。たとえば、Kerberos プロバイダーで設定された Kerberos realm が A である限り、Kerberos プリンシパル john@A のインスタンスユーザー名は john になります。

問題がある場合は、追加のロギングを有効にして問題をデバッグしてください。