Kerberos 認証の構成

Kerberos これは、秘密鍵暗号技術を用いてクライアント・サーバー型アプリケーションに強力なネットワーク認証を提供するように設計された、安全なチケットベースの認証プロトコルです。

始める前に

注： Kerberos はリクエスト制の機能です。 VDEV-196042 （ Kerberos Desktop SSO via krb5 ）。この機能のご利用をご希望の場合は、 IBM の営業担当者、または IBM の担当者に連絡し、本機能の有効化を希望する旨をお伝えください。権限をお持ちの場合は、機能番号を記載してサポートチケットを作成することも可能です。 IBM® Verify 無料トライアル期間中は、サポートチケットを作成することはできません。

このタスクを完了するには管理者権限が必要です。
IBM Verify 管理者として管理コンソールにログインしてください。詳細については、「 IBM Verify へのアクセス」を参照してください。

このタスクについて

Kerberos 認証、認可、およびアカウンティングという3つの主要なセキュリティサービスを提供しています。これにより、パスワードを平文で送信することなく、セキュリティが確保されていないネットワーク上でユーザー認証を行うことができます。これにより、ユーザーは一度本人確認を行うだけで、認証情報を再入力することなく複数のサービスにアクセスできるようになります。

Kerberos を利用するメリット：

ネットワーク経由でのパスワードの送信を防止します。
リプレイ攻撃を防ぐ（タイムスタンプにより、チケットの有効期限が制限される）。
シングルサインオンを実現するため、大規模な企業ネットワーク向けの拡張性の高いソリューションとなります。

Kerberosの主要な構成要素

キー配布センター（KDC）
- 中央認証機関
- 以下の2つの論理コンポーネントで構成されています：
  - 認証サーバー（AS）：ユーザーの身元を確認する
  - チケット発行サーバー（TGS）：サービスチケットを発行する
クライアント：アクセスを要求するユーザーまたはアプリケーション。
サービスサーバー：クライアントがアクセスしようとするリソース（例：ファイルサーバー、メールサーバー）。

SPNEGOと Kerberos の連携方法

SPNEGO（Simple and Protected GSS-API Negotiation Mechanism）は、異種環境において Kerberos の機能を拡張する重要な補助プロトコルです。

以下は、ブラウザがSPNEGOを使用して Kerberos で保護されたWebアプリケーションにアクセスする際の認証プロセスについて説明します

クライアントは、Webリソースへのアクセス要求をWebアプリケーションに送信します。
リクエストはSPNEGOによって解析され、必要なAuthorisationヘッダーが含まれているかどうかが確認されます。リクエストにヘッダーが含まれていない場合、またはヘッダーがGSS仕様に準拠していない場合、ブラウザに対して次にサポートされている認証アルゴリズムのレスポンスが送信されます。この処理は、必要なトークンが自動的に受信されるまで続きます。
ブラウザは現在、KDC内のTGSに対して Kerberos のサービスチケットを要求しています。
TGSは Active Directory ユーザーと内部的に接続し、時間ベースのチケットをブラウザに返します。
TGSによって生成されたチケットは、現在Authorisationヘッダーで送信され、SPNEGOを通じて解析されます。 SPNEGOはユーザー情報を取得し、GSS APIを呼び出します。
このAPIは、 Kerberos の設定（ KRB5 Config）を読み込み、チケットの有効性を確認します。検証に合格した場合、リクエストはWebアプリケーションのリソースに送信されます。
Webアプリケーションリソースがリクエストを処理し、レスポンスがブラウザに送信されます。

手順

Verifyで管理者としてログインしてください。プロフィールアイコンに移動し、「管理者モードに切り替える」をクリックしてください。
[セキュリティ ] > [ Kerberos ] を選択します。
ファイルを .keytab アップロードしてください。詳細については、「keytab ファイルの設定」を参照してください。
keytabファイル（キーテーブルファイル）とは、 Kerberos のプリンシパルおよびそれに関連付けられた暗号化された鍵を格納するファイルのことです。これにより、サービスやアプリケーションは、ユーザーによるパスワードの入力や平文でのパスワード保存を必要とせずに、 Kerberos に対して自動的に認証を行うことができます。
ファイルの内容には、 Kerberos のプリンシパル、暗号化キー、キーバージョン番号（KVNO）、および暗号化タイプが含まれる場合があります。
指定されたフィールドにサービスプリンシパル名（SPN）を入力してください。複数のSPNを追加できます。詳細については、「サービスプリンシパル名の設定」を参照してください。
サービスプリンシパル名（SPN）は、 Kerberos 環境におけるサービスインスタンスを一意に識別するための識別子です。これは、基本的に、クライアントが特定のサーバー上で実行されている特定のサービスに対して認証チケットを要求する際に使用するアドレスです。これはサービスを一意に識別し、クライアントがKDCから適切なサービスチケットを要求できるようにします。
注:
- 1つのアカウントに複数のSPNを割り当てることができます。
- 各SPNは、1つのアカウントにのみ登録できます。
- 重複するSPNは、認証エラーの原因となります。
ドロップダウンメニューから、対応している IDプロバイダーを選択してください。

注：システムには、 IBMid およびソーシャルID以外のすべてのIDプロバイダーが一覧表示されます。
IBM Verifyジャスト・イン・タイム（JIT）プロビジョニングを有効にするユーザーが初めてで認証を行う際に、サービスプロバイダーでユーザーアカウントを作成または更新するため。サービスプロバイダーが、ユーザーがサービスプロバイダーへのアクセスを試みる前に、ユーザーの識別情報を作成したり把握したりする必要がない場合には、JITプロビジョニングを使用してください。
ユーザーマッピングルール：CELxエディタを使用して、ユーザーのプロビジョニング時にKerberos userPrincipalName を変換する式を、次の形式で定義できます。 {"p": {"username": [$expression$]}} ここで $expression 、はカスタム式を表します。
例えば、以下のとおりです。
```
{"p": {"username": [requestContext.userPrincipalName[0].split('@')[0]]}}
```
CEL評価規則
- CEL式はJSONを返さなければなりません。それ以外のデータ型が返された場合、リクエストは失敗します
- CEL式が無効または誤っている場合、評価は失敗します。
注:
- デフォルトでは、 IDプロバイダーとして「クラウドディレクトリ」が選択されており、かつCEL式でソースが明示的に変更されていない場合、選択されたIDプロバイダーが考慮されます。
- CEL を通じて ID プロバイダーが明示的に設定されている場合、その設定が選択された ID プロバイダーよりも優先されます。
- この動作は、 SAML やOIDCなどの他のIDソースについても同様です。
詳細については、「属性関数」を参照してください。
ルールが機能していることを確認します。
1. 「表示」を選択します。
  userPrincipalNameJSONエディタのサンプルでは、. が表示されます。
2. 「テストを実行」を選択します。
3. 「結果」セクションに正しい値が返されていることを確認してください。
  カスタムルールの作成に関する詳細については、「属性関数」を参照してください。
4. 「保存」を選択します。