This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.6.5.4. 要求ヘッダー CR のサンプル
以下のカスタムリソース (CR) は、要求ヘッダーアイデンティティープロバイダーのパラメーターおよび許可される値を示します。
要求ヘッダー CR
- 1
- このプロバイダー名は要求ヘッダーのユーザー名に接頭辞として付加され、アイデンティティー名が作成されます。
- 2
- このプロバイダーのアイデンティティーと
User
オブジェクト間にマッピングが確立される方法を制御します。 - 3
- オプション: 非認証の
/oauth/authorize
要求のリダイレクト先となる URL です。これは、ブラウザーベースのクライアントを認証し、その要求をhttps://<namespace_route>/oauth/authorize
にプロキシーします。https://<namespace_route>/oauth/authorize
にプロキシーする URL は/authorize
(末尾にスラッシュはない) で終了し、OAuth 承認フローが適切に機能するようにサブパスもプロキシーする必要があります。${url}
は現在の URL と置き換えられ、エスケープされてクエリーパラメーターで保護されます。${query}
は最新のクエリー文字列と置き換えられます。この属性が定義されない場合は、loginURL
が使用される必要があります。 - 4
- オプション: 非認証の
/oauth/authorize
要求のリダイレクト先となる URL です。これにより、WWW-Authenticate
チャレンジが予想されるクライアントの認証が行われ、それらの要求がhttps://<namespace_route>/oauth/authorize
にプロキシーされます。${url}
は現在の URL と置き換えられ、エスケープされてクエリーパラメーターで保護されます。${query}
は最新のクエリー文字列と置き換えられます。この属性が定義されない場合は、challengeURL
が使用される必要があります。 - 5
- PEM エンコードされた証明書バンドルを含む OpenShift Container Platform
ConfigMap
オブジェクトへの参照。リモートサーバーによって表示される TLS 証明書を検証するためにトラストアンカーとして使用されます。重要OpenShift Container Platform 4.1 の時点で、
ca
フィールドはこのアイデンティティープロバイダーに必要です。これは、プロキシーが相互 TLS をサポートしている必要があることを意味します。 - 6
- オプション: 共通名 (
cn
) の一覧。これが設定されている場合は、要求ヘッダーのユーザー名をチェックする前に指定される一覧の Common Name (cn
) を持つ有効なクライアント証明書が提示される必要があります。空の場合、すべての Common Name が許可されます。これはca
と組み合わせる場合にのみ使用できます。 - 7
- ユーザーアイデンティティーを順番にチェックする際に使用するヘッダー名。値を含む最初のヘッダーはアイデンティティーとして使用されます。これは必須であり、大文字小文字を区別します。
- 8
- メールアドレスを順番にチェックする際に使用するヘッダー名。値を含む最初のヘッダーはメールアドレスとして使用されます。これは任意であり、大文字小文字を区別します。
- 9
- 表示名を順番にチェックする際に使用するヘッダー名。値を含む最初のヘッダーは表示名として使用されます。これは任意であり、大文字小文字を区別します。
- 10
- 推奨ユーザー名を順番にチェックする際に使用するヘッダー名 (
headers
に指定されるヘッダーで決定される変更不可のアイデンティティーと異なる場合)。値を含む最初のヘッダーは、プロビジョニング時に推奨ユーザー名として使用されます。これは任意であり、大文字小文字を区別します。