6.4.4. 認証情報の委譲
Kerberos 5 は、認証情報の委譲の概念をサポートしています。このシナリオでは、アプリケーションを使用して Kerberos チケットを再使用して、Kerberos が保護された他のサービスと相互作用できるようになります。SPNEGO プロトコルは Red Hat Single Sign-On サーバーで処理されるため、GSS 認証情報を OpenID Connect トークンクレーム 内のアプリケーションまたは Red Hat Single Sign-On サーバーからアプリケーションに送信される SAML アサーション属性のいずれかに伝播する必要があります。この要求をトークンまたはアサーションに挿入するには、各アプリケーションは gss 委任認証情報
と呼ばれる組み込みプロトコルマッパーを有効にする必要があります。これは、アプリケーションのクライアントページの Mappers
タブで有効にされます。詳細は、「プロトコルマッパー」の章を参照してください。
アプリケーションは、Red Hat Single Sign-On を使用して他のサービスに対して 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);
krb5.conf
ファイルで 転送可能
な kerberos チケットを設定し、委譲された認証情報のサポートをブラウザーに追加する必要があることに注意してください。
認証情報の委譲にはセキュリティーへの影響があるため、必要性が及ぶ場合に限り使用してください。HTTPS と併用することが強く推奨されます。詳細は、「アプリケーションをシングルサインオン向けに設定」の例を参照してください。