OpenID の設定：カスタムアプリケーションでのシングルサインオンの接続

オンラインで編集

VerifyOpenID Connect を使用したシングルサインオンにより、アプリケーションは. によって実行される認証に基づいてユーザーの身元を確認できるようになります。ユーザーは、アプリケーションでアカウントを登録する必要はありません。ユーザーはログインのためにに Verify リダイレクトされます。 Verify ユーザーの身元を確認し、IDトークンを介して情報を送信し、ユーザーがリソースにアクセスして使用する権限を有していることを、信頼先に対して確認します。 https://<tenant-host>/oidc/endpoint/default/.well-known/openid-configurationこのアプリケーションは、ディスカバリーエンドポイントを持つ OpenID Connectプロバイダーを使用しています。

始める前に

注：このタスクの代替方法については、「動的なクライアント登録」を参照してください。

このタスクを完了するには管理者権限が必要です。
少なくとも 2 つのブラウザー・ウィンドウを開いて、セットアップを完了します。 1つは管理コンソール Verify 用、もう1つは対象アプリケーションの管理コンソール用です。
- IBM® Verify 管理者として管理コンソールにログインしてください。
- 管理者アカウントを使用して、ターゲット・アプリケーション管理コンソールにログインします。
[ 全般 ] タブで、アプリケーションインスタンスの基本情報を設定する必要があります。「アプリケーションの基本情報の設定」を参照してください。

このタスクについて

Verify 既定のアプリケーションテンプレートには、「 OpenID Connect 」のサインオンオプションがありません。 Verifyを使用して、カスタムアプリケーションテンプレートユーザー認証を OpenID 接続に委任する依拠当事者またはクライアントアプリケーションとして機能するようにアプリケーションを設定します。

Configure Verify とリライイング・パーティが相互に通信できるように設定します。 OpenID Connectのシングルサインオンを有効にするには、以下を指定する必要があります：

依拠当事者からの特定のデータを持つ Verify。
Verify からの特定のデータを持つ依拠当事者。

OpenID の接続先として、Webアプリケーションやモバイルアプリケーションを設定 IBM Verify Access できます。

手順

[サインオン] タブに移動します。
「サインオン方法」で、「 OpenID 」を選択し、「 1.0 」に接続します。

信頼当事者に関する基本情報を提供 Verify してください。


フィールド	説明
アプリケーション URL	これは、 OpenID Connect の依存先へのログインに使用されるシングルサインオン初期化 URL です。アプリケーションは、この URL を使用して、ユーザーの詳細が含まれている ID トークンを Verify に要求します。ユーザーがこの URL を介してアプリケーションにアクセスすると、ユーザーは認証のために Verify にリダイレクトされます。この情報は、許可プロバイダーまたは OpenID Connect プロバイダーをそのサイトで構成するときに、依拠当事者から取得できます。
付与タイプ	Verifyこれは、依存先がIDトークンを取得するために利用できる仕組みを示しています。 Verify 以下の助成金種別に対応しています：許可コード注：認証コードがデフォルトのグラントタイプとして事前選択されており、PKCEもデフォルトで選択されています。暗黙的デバイス・フロー注：「デバイスフロー」を選択すると、QRコードを生成することもできます。コンテキスト・ベースの許可 JWT ベアラー `JWT bearer default identity sourceJWKS URI`注： JWTベアラーを選択した場合、、 `JWT bearer user identification` およびを設定するオプションがあります。 JWTベアラーグラントタイプの使用方法の詳細については、「グラントタイプ」を参照してください。許可コード、暗黙的、デバイス・フロー、および ROPC の任意の組み合わせ。少なくとも 1 つの付与タイプを選択する必要があります。選択した唯一の付与タイプが ROPC である場合、「アクセス・ポリシー」セクションは表示されません。「助成金の種類」を参照して、対象となる助成金の種類を簡単に比較し、申請にどの種類を設定すべきかを確認してください。
クライアント ID	これは、 OpenID Connectの信頼先であるクライアントアプリケーションに割り当てられる一意の公開識別子です。許可サーバーはこの情報を使用して、依拠当事者と許可要求を識別します。この情報は、カスタム OpenID Connect アプリケーションを保存すると自動的に生成されます。アプリケーションの管理コンソールで Verify を OpenID Connect プロバイダーとして構成する場合は、この情報を依拠当事者に提供する必要があります。依拠当事者は、アクセス・トークンを要求するたびにクライアント ID を使用します。
Kubernetes シークレット	Kubernetes 秘密 YAML ファイルは、Red Hat OpenShift との接続に使用されます。メタデータを取得するには、Kubernetes 秘密 YAML ファイルをダウンロードする必要があります。
パブリック・クライアント (クライアント秘密鍵なし)	クライアントが、アプリケーションによって提供される必要のある秘密鍵を持たないことを示します。注：これを選択すると、「クライアントシークレット」フィールドは非表示になり、「署名アルゴリズム」オプションから以下のアルゴリズムが削除されます： HS256 HS384 HS512 クライアント秘密鍵を生成するのは、クライアント・タイプが機密の場合のみです。機密クライアントは、クライアント ID とクライアント秘密鍵をセキュアな方法で保持でき、これらの資格情報を無許可の関係者に表示することはありません。クライアント秘密鍵は、クライアント・アプリケーションおよび許可サーバーのみが知っているようにする必要があります。
クライアント秘密鍵	このデータは、依拠当事者を認証し、ID トークンの許可コードを交換するために、クライアント ID とともに使用されます。この情報は、カスタム OpenID Connect アプリケーションを保存すると自動的に生成されます。アプリケーションの管理コンソールで Verify を OpenID Connect プロバイダーとして構成する場合は、この情報を依拠当事者に提供する必要があります。
クライアント認証方式	クライアント認証を必要とするトークン・エンドポイントなどのエンドポイントの認証方式を示します。 Verify は、以下のクライアント認証方式をサポートしています。デフォルトクライアント秘密鍵 Basic クライアント秘密鍵 POST クライアント秘密鍵 JWT 秘密鍵 JWT デフォルトのままにした場合、クライアント秘密鍵 Basic と POST の両方が許可されます。依拠当事者がサポートしている場合は、秘密鍵 JWT を構成として使用します。クライアントシークレットJWTおよび秘密鍵JWTの詳細については、「クライアントシークレットJWTの作成」および「秘密鍵JWTの作成」を参照してください。
クライアント・アサーション JTI の検証 (Validate client assertion JTI)	クライアント・アサーション JWT 内の JTI が単一使用に対して検証されるかどうかを示します。このオプションは、クライアント秘密鍵 JWT クライアント認証方式または秘密鍵 JWT クライアント認証方式が選択されている場合にのみ表示されます。
許可された署名検証鍵 (Allowed signature verification keys)	クライアント・アサーション JWT の検証に使用できる署名検証鍵 ID。このオプションは、秘密鍵 JWT クライアント認証方式が選択されている場合にのみ表示されます。
Proof Key for Code Exchange (PKCE) の検証が必要	PKCE は、許可コード傍受攻撃を軽減するために使用されます。これは、許可コード・フローの続行前に、コードのチャレンジを必要とします。このオプションが表示されるのは、許可コードの付与フローを選択したときのみです。
リダイレクト URI	これはコールバック URL で、Verify がその認証応答を依拠当事者に送信するアドレスです。ユーザーは、Verify によって認証および許可された後、この URL にリダイレクトされます。少なくとも 1 つの URI を指定する必要があります。コールバック URI がアプリケーションのドメインである場合、それはテナントのドメインであってもかまいません。注：ドメインにはワイルドカードを使用できます。 URIパスではワイルドカードはサポートされていませんが、「*」文字は有効なURIパス文字であり、リテラル文字列として扱われます。最大 400 個の URI を追加できます。この情報は、許可プロバイダーまたは OpenID Connect プロバイダーをそのサイトで構成するときに、依拠当事者から取得できます。
JWKS URI	依拠当事者が公開鍵を JSON Web Key (JWK) 形式で公開する URI。この URI は、JWT 署名の検証に使用されます。システムは、到達不能または応答しない JWKS URI を拒否できます。 JWKS のサイズが大きすぎる場合も、システムは JWKS URL を拒否できます。依拠当事者が JWKS URI を公開しない場合は、X509 証明書の形式で公開鍵をシステムに追加できます。「証明書の管理」を参照してください。パブリック証明書に関連付けられる「フレンドリー名」は、JWT の鍵 ID (kid) ヘッダーの値です。
JWT ベアラーのユーザー識別 (JWT bearer user identification) JWT ベアラー付与タイプでのみ使用できます。	この構成は、当該 JWT ベアラー・トークンに関連付けられているユーザーを識別するための JWT ベアラー・サブジェクト (sub) の解釈をシステムに通知します。サブルーチンは、`User ID`、`Username`、または`External ID`にすることができます。
JWT ベアラーのデフォルト ID ソース (JWT bearer default identity source) JWT ベアラー付与タイプでのみ使用できます。	JWT でレルムが指定されない場合は、これが sub で識別されるユーザーが属するデフォルトの ID ソース・レルムとなります。 `JWT bearer user identification`オプションが`User ID`に設定されている場合、この設定は適用されません。

既存のアプリケーションを編集する場合は、次のクライアント秘密鍵オプションを使用できます。

クライアント秘密鍵を表示するには、を選択します。
クライアント秘密鍵を非表示にするには、を選択します。
を選択すると、クライアントIDまたはシークレットがクリップボードにコピーされます。
[選択] をクリックして、回転されたクライアントシークレットを表示します。
- リストから1つ以上のローテーション済みのクライアントシークレットを選択し、「削除」をクリックして削除してください。
新規クライアント・シークレットを生成するには、を選択します。クライアント秘密鍵が漏えいしたと思われる場合は、このオプションを使用します。クライアント秘密鍵を再生成した場合は、アプリケーションのすべての OAuth クライアントにあるクライアント秘密鍵を更新する必要があります。
- 「現在のシークレットを保持する」のチェックボックスを選択すると、現在のクライアントシークレットがローテーション対象のクライアントシークレットのリストに追加されます。
- 「現在のシークレットを保持する」チェックボックスがオンになっている場合は、クライアントシークレットの説明と有効期限（ブラウザのローカル時間）を選択してください。有効期限が選択されていない場合、アプリケーション設定で設定されたテナントの「ローテーションされたシークレットの有効期間」が適用されます。
- 更新されたクライアントシークレットはハッシュ化されており、もはや平文で復元することはできませんが、指定された有効期限までは引き続き使用可能です。
- 確認後、クライアントシークレットは直ちに更新されます。新しいクライアントシークレットが画面に表示されます。

アクセス・トークンおよびリフレッシュ・トークンが盗まれた場合の無許可アクセスの時間を制限するために、これらのトークンの有効期限を構成します。

アクセス・トークンは、保護リソースへのアクセスを許可するために使用されます。アクセス・トークンの有効期限が切れると、許可は取り消されます。

表 1. トークンの設定
フィールド	説明
アクセス・トークン存続時間 (秒)	アクセス・トークンの有効期限が切れるまでの時間の長さを秒単位で設定します。アクセス・トークンの有効期限を設定して、クライアント・アプリケーションで情報漏えいがあったときに、攻撃者が盗まれたトークンを使用してリソースにアクセスできる時間を制限します。指定できるのは正の整数のみです。デフォルト値は `7200` 秒です。許可される最小値は `1` 秒で、最大値は `2147483647` 秒です。
アクセス・トークンの形式	アクセストークンが不透明な文字列として生成されるかどうかを示します。これは、`Default`設定、またはJWT形式で。
対象者	トークンの受信者とするターゲットを指定します。これらの値は、JWT 形式のトークンの場合はaudクレームにリストされ、イントロスペクション・ペイロードには単一ストリングまたはストリングの配列のいずれかとしてリストされます。
イントロスペクション属性マッピング (Introspection attribute mapping)	この属性マッピング・リストは、イントロスペクション・ペイロードおよび JWT 形式のアクセス・トークンのクレームを含めるために使用します。
Attribute Name	依拠当事者が使用し、Verify から求められる属性の名前。以下の属性名は使用できません： aud, exp, groupIds, groupUids at_hash, c_hash, rt_hash, s_hash, iat, iss,, nonce, sub, client_id, grant_id, grant_type、および scope。
属性	ディレクトリ > 属性で各タイプに対して定義したすべての属性ソースを一覧表示します。選択した属性ソースの値は、ID トークンの定義済み依拠当事者の属性名の属性値として割り当てられます。
リフレッシュ・トークンの生成	クライアントアプリケーションが、 OpenID Connect IDプロバイダーの認証サーバーから新しいアクセストークンを取得するために、リフレッシュトークンを要求および使用できるかどうかを示します。このオプションは、アプリケーションがアクセストークンを使用してAPI経由 Verify で操作を実行する場合にのみ使用してください。前のアクセス・トークンが期限切れになった場合にのみ、新規アクセス・トークンを取得する必要があります「付与タイプ」として「暗黙的」を選択した場合、このオプションは無関係です。
リフレッシュ・トークン存続時間 (秒)	リフレッシュ・トークンの有効期限が切れるまでの時間の長さを秒単位で設定します。この設定により、ユーザーが再認証できる頻度が決まります。リフレッシュトークンの有効期限を設定し、一定時間が経過した後に Verify ユーザーがシングルサインオン操作を再度実行するようにします。このオプションは、「リフレッシュ・トークンの生成」を有効にした場合にのみ表示されます。リフレッシュ・トークンは、保護リソースへのアクセスを継続するための新規アクセス・トークンを取得するために使用されます。指定できるのは正の整数のみです。デフォルト値は `604800` 秒です。許可される最小値は `1` 秒で、最大値は `2147483647` 秒です。
リフレッシュ・トークン存続時間の更新	このオプションでは、リフレッシュ・トークンを使用して新しいトークン・セットが取得される際にリフレッシュ・トークン存続時間を更新するかどうかを指定します。このチェック・ボックスを選択すると、リフレッシュ・トークンが更新されるたびに、「リフレッシュ・トークン存続時間」で設定した存続時間が更新されます。選択しない場合は、元の「リフレッシュ・トークン存続時間」に達した時点で、更新されたリフレッシュ・トークンの有効期限が切れます。

IDトークンの署名および暗号化オプションを指定します。信頼側は、この署名を使用して、トークンに含まれるユーザーの主張の完全性および真正性、ならびにトークンに署名した OpenID Connect IDプロバイダーの真正性を検証します。トークンは、リライング・パーティーのみが復号できるように暗号化することができます。

表 2. 署名と暗号化のオプション
フィールド	説明
署名アルゴリズム	IDトークンに署名するために Verify 使用するアルゴリズム。このアルゴリズムは、依拠当事者が Verifyに登録したものと一致する必要があります。以下のハッシュ・アルゴリズムから選択して、署名を検証します。 HS256 HS384 HS512 ES256 ES384 ES512 PS256 PS384 PS512 RS256 (デフォルト値) RS384 RS512 注: ES256 署名アルゴリズムが選択されている場合、証明書は P-256 を指定した ECDSA でなければなりません。 ES384 署名アルゴリズムが選択されている場合、証明書は P-384 を指定した ECDSA でなければなりません。 ES512 署名アルゴリズムが選択されている場合、証明書は P-521を指定した ECDSA でなければなりません。クライアント秘密鍵を生成しないことを選択した場合、HS アルゴリズムは表示されません。
署名証明書	このオプションは、いずれかの RS、ES、または PS 署名アルゴリズムを選択した場合にのみ表示されます。この証明書を使用して、シングル・サインオン時に ID トークンに署名します。セキュリティ > 証明書 > 個人証明書「デフォルトの選択」とは、で設定したデフォルトの個人証明書を指します。
暗号化アルゴリズム	コンテンツ暗号鍵 (CEK) の値を暗号化または決定するために使用される暗号アルゴリズム。以下のアルゴリズムがサポートされています。 RSA-OAEP RSA-OAEP-256
コンテンツ・アルゴリズム	暗号化テキストおよび認証タグを生成するために、プレーン・テキストで認証済み暗号化を実行するために使用されるコンテンツ暗号化アルゴリズム。以下のアルゴリズムがサポートされています。 A128GCM A192GCM A256GCM
暗号鍵	暗号化に使用する鍵の証明書ラベルまたは鍵 ID。

ID トークンを通じて、サポートおよび提供している Verify ユーザー属性を、依存先に対してマッピングします。

Verify 標準のJSONクレームスキーマを拡張し、従業員の役職、上司、部署などの追加属性を含める可能性があります。

注：以下の属性は、デフォルトですでにIDトークンに追加されています： userType, uniqueSecurityName, displayName realmName,, name, preferred_username jti,, at_hash, ext。これらの属性の一部は、値を返さないように設定された属性ソースにマッピングすることで、IDトークンから削除することができます。

「属性マッピング」セクションは、表3 に説明されている以下の要素で構成されています。

既知のすべてのユーザー属性を送信するためのチェック・ボックス・オプション。
属性名、およびそれらに対応する Verify 内の属性ソースを追加するオプション。

表 3. 属性のマッピング
情報	説明
すべての既知のユーザー属性を ID トークンで送信	これを選択すると、 OpenID Connect プロバイダーの IDソースから利用可能な、既知のすべてのユーザー認証情報属性が、 IDトークンに自動的に含まれます。既知のユーザー資格情報属性は、次の項目で構成されます。標準属性これらの属性は Verify クラウドディレクトリには、 [ディレクトリ] > [属性] に表示される組み込み属性が含まれています。拡張属性これらの属性は、「認証」>「 IDプロバイダー」で設定した SAML Enterprise IDプロバイダーからのものです。選択しない場合には、依拠当事者が ID トークンで要求する特定の属性のみを定義します。属性名および属性ソースを指定します。
Attribute Name	Verifyが依拠当事者から使用し、かつ必要とする属性の名前。以下の属性名は使用できません： aud, exp, groupIds, groupUids, at_hash, c_hash rt_hash, s_hash, iat, iss, nonce,, client_id, grant_id, grant_type、および scope。 `sub`属性名がの場合、この属性マッピングは、イントロスペクション応答、JWTアクセストークン、userinfo応答、およびIDトークン内のの `sub` 値を変更します。
属性	ディレクトリ > 属性で各タイプに対して定義したすべての属性ソースを一覧表示します。選択した属性ソースの値は、ID トークンの定義済み依拠当事者の属性名の属性値として割り当てられます。注：属性のソース値に「タグなし」と表示されている場合、その属性の用途が変更されたためです。その属性を使用する既存のアプリケーションは、変更された用途に合わせて別の属性を使用するようリマップされるまで、この属性を使用し続けることができます。例えば、既存の属性で「シングル・サインオン (SSO)」チェック・ボックスがクリアされても、その属性を既に SSO に使用しているアプリケーションでは、SSO に対するその属性の使用を続行できます。プロビジョニングの用途が削除された場合のプロビジョニング属性のマッピングも、同じ動作となります。

ユーザーがアプリケーションにアクセスする方法を決定する ID ソースとポリシーを選択します。
1. このアプリケーションにサインインするために使用できる ID ソースを選択してください。
  
  デフォルト設定では、テナント用に構成されているすべてのエンタープライズ ID ソースからのアクセスが許可されます。アプリケーションにサインインするために使用できる ID ソースを制限するには、「サポートされている特定の ID ソースを選択」を選択します。サインインを許可する ID ソースのチェック・ボックスを選択します。
2. ユーザーがアプリケーションにアクセスする方法を決定するポリシーを選択します。
  割り当てられているデフォルトのアクセス・ポリシー (「すべてのデバイスからのアクセスを許可する」) を引き続き使用できます。あるいは、チェックボックスのチェックを外し、[ ] をクリックして、あらかじめ定義されたアクセスポリシーのリストから選択することもできます。アクセスポリシーを選択すると、各グラントタイプのチェックボックスを選択することで、そのアクセスポリシーをAPIグラントタイプに適用できます。詳細については、「アクセスポリシー」を参照してください。
ユーザーの同意を求めるかどうかを選択します。
ユーザーの同意の要求を Open ID Connect アプリケーションに追加できます。これは、リソース所有者パスワード資格情報 (ROPC) 以外のすべての付与タイプで使用できます。アプリケーションに関して選択した唯一の付与タイプが ROPC である場合、「ユーザーの同意」オプションは非表示になります。デフォルトの「同意を確認する」が選択されたままである場合は、ユーザーに、スコープおよび API アクセス資格に明示的に同意するように求めるプロンプトが出されます。ユーザーは、API アクセスの許可を付与または拒否できます。既存の Open ID Connect アプリケーションは同意を要求しません。ユーザーの同意を確認する場合は、それらのアプリケーションを編集する必要があります。「アプリケーションの同意の管理」を参照してください。
アプリケーションが作成されると、「同意を確認する」の下に、「同意タイプ」フィールドが「拡張」の値とともに表示されます。「拡張」の値は、ユーザーの同意が DPCM に保管されていることを示します。古い OIDC カスタム・アプリケーションでは、このフィールドは同意を DPCM にマイグレーションした後に表示されます。
オプション： カスタムスコープを制限する。
カスタム・スコープは、サポートされる OIDC/OAuth 付与フローで OIDC/OAuth クライアントによって要求できます。デフォルトの設定である「カスタム・スコープの制限」が有効になっている場合、フローの終わりにクライアントに付与されるスコープは、このセクションで指定されるスコープに制限されます。「カスタム・スコープの制限」が無効になっている場合、フローが完了すると、要求されるすべてのカスタム・スコープが付与されます。
注：標準スコープ openid, profile, email, phone, および address は制限できません。
1. 「カスタムスコープを制限する」チェックボックスがオンになっていることを確認してください。
2. 付与するカスタム・スコープの名前と説明を入力します。
  スコープ名は、依拠当事者/クライアントによって要求される OAuth2/OIDC スコープを指します。説明は、スコープの分かりやすい説明です。
  
  もう 1 組のスコープ・フィールドが表示されます。
3. 付与するカスタム・スコープごとに、前のステップを繰り返します。
オプション： サインオントークンにAPIのアクセス権限を付与します。
「API アクセスを制限する (Restrict API access)」は、新規アプリケーションのデフォルトの設定です。アプリケーションにはサインオン・トークン資格がありません。 API アクセスのための資格を付与するには、以下の手順を実行します。
1. 編集アイコンを選択します。
  「API クライアントの編集」ウィザードが開始されます。
2. サインオン・トークンに付与するユーザー許可と非ユーザー許可を選択します。
  [ユーザートークンのデフォルト権限 ] チェックボックスをオンにするか、 [API アクセスを制限] チェックボックスをオフにすると、ユーザートークンに対して一連のデフォルトの権限が付与されます。
3. 「保存」を選択します。
「保存」を選択します。

次の手順

信頼先に対し、と信頼先の間 Verify で OpenID Connectのサインオン設定を完了するために必要な情報を Verify 提供してください。ユーザー・インターフェースで提供されている説明を参照してください。
構成済みアプリケーションへのアクセスを許可するユーザーまたはグループの資格を追加します。「アプリケーションの権限の管理（管理者またはアプリケーション所有者による）」を参照してください。
ユーザーに対するセキュリティー管理を強化するために、ユーザーが構成済みアプリケーションにサインオンする際に、2 要素認証を実施します。「認証要素の設定」を参照してください。