EDQとCognitoユーザー・プールの統合

10 EDQとCognitoユーザー・プールの統合

この章では、Cognitoユーザー・プールをOracle Enterprise Data Quality (EDQ)と統合する方法について説明します。

ノート:

この機能が適用されるのは、EDQ 12.2.1.4.3以降のリリースです。

この章の内容は次のとおりです。

ユーザー・プールの作成
EDQは、アイデンティティ・ストアとしてAmazon Cognitoユーザー・プールと統合できます。ユーザーおよびグループのログインは、Amazon Cognito REST APIを使用して行われます。Amazon CognitoでEDQを使用するには、まずAmazon Cognitoコンソールを使用してユーザー・プールを作成する必要があります。
REST APIコール用のIAMユーザーの作成
Cognito REST APIのコールは、標準のAWSリクエスト署名を使用して認証されます。IAMユーザーを作成するときには、EDQに必要な権限のみを指定することをお薦めします。まず、必要な権限を持つIAMポリシーを作成します。IAMユーザーを作成し、直接またはグループを介して新しいポリシーをアタッチします。ユーザーの資格証明を作成し、キーおよび関連するシークレットを書き留めます。
EDQ login.propertiesファイルの編集
EDQでのユーザー認証は、EDQ構成領域のsecurity/login.propertiesというファイルを使用して構成されます。このファイルは「ローカル」構成で作成する必要があります。この場所にディレクトリ"security"が存在しない場合は、手動で作成する必要があります。login.propertiesを編集し、Cognitoのレルムを定義する必要があります。
Webサービスに対するOAuth2 Bearer認証の有効化
EDQとCognitoユーザー・プールの統合は、OpenID Connect SSO認証などのSSOメカニズムに基づいています。ユーザー名とパスワードを使用したプログラムによる認証はサポートされていません。

ユーザー・プールの作成

EDQは、アイデンティティ・ストアとしてAmazon Cognitoユーザー・プールと統合できます。ユーザーおよびグループのログインは、Amazon Cognito REST APIを使用して行われます。Amazon CognitoでEDQを使用するには、まずAmazon Cognitoコンソールを使用してユーザー・プールを作成する必要があります。

Amazon Incognitoユーザー・プールを作成するには、次のステップに従います。

Amazon Cognitoコンソールにログインします。プロンプトが表示されたら、AWS資格証明を入力します。
「ユーザー・プール」を選択します。
ページの右上隅で、ユーザー・プールの作成を選択してウィザードを開きます。既存のユーザー・プールを使用することもできます。
パスワード・ポリシー、マルチファクタ認証(MFA)要件およびユーザー・アカウントのリカバリ・オプションを選択します。
ユーザー・サインアップ・エクスペリエンスを構成して、サインアップ時に新規ユーザーがどのようにアイデンティティを検証するかを決定します。必須属性としてEメールと名前が選択されていることを確認します。Cognitoでは、デフォルトの「組織」属性は提供されません。EDQにそれが必要な場合は、カスタム属性を作成します。
必要に応じてユーザー・メッセージ配信を構成し、サインアップ、アカウント確認、MFAおよびアカウント・リカバリのために電子メールおよびSMSメッセージをユーザーに送信します。事前設定された初期パスワード付きで管理者によってユーザーが作成される場合、メッセージ配信を構成する必要はありません。
アプリケーションの統合で、ユーザー・プールに名前を付け、ホストされたUIを構成して、アプリケーション・クライアントを作成します。詳細は、「ホストされたWeb UIを有効にするアプリケーションの追加」を参照してください。
アプリケーションの統合で、タイプとして機密クライアントを選択し、クライアント・シークレットの生成が選択されていることを確認します。
許可されたコールバックURLに、https://server/edq/oidc/callbackと入力します
既存のユーザー・プールを使用する場合は、認可コード付与フローをサポートする新しいアプリケーション・クライアントを追加し、コールバックURLを構成できます。プールの作成後にコールバックURLを追加して、複数のEDQインスタンスをサポートすることができます。
Advanced app client settings拡張アプリケーション・クライアント設定で、許可されるサインアウトURLとしてhttps://server/edq/oidc/loggedoutを追加します。

WebLogicを使用している場合は、サインアウトURLにポート番号を含めなければならない場合があります。追加のサインアウトURLとして、https://server:443/edq/oidc/loggedoutを追加します。
サマリー画面で選択内容を確認し、ユーザー・プールの作成をクリックして続行します。

親トピック: EDQとCognitoユーザー・プールの統合

REST APIコール用のIAMユーザーの作成

Cognito REST APIのコールは、標準のAWSリクエスト署名を使用して認証されます。IAMユーザーを作成するときには、EDQに必要な権限のみを指定することをお薦めします。まず、必要な権限を持つIAMポリシーを作成します。IAMユーザーを作成し、直接またはグループを介して新しいポリシーをアタッチします。ユーザーの資格証明を作成し、キーおよび関連するシークレットを書き留めます。

親トピック: EDQとCognitoユーザー・プールの統合

EDQ login.propertiesファイルの編集

EDQでのユーザー認証は、EDQ構成領域のsecurity/login.propertiesというファイルを使用して構成されます。このファイルは「ローカル」構成で作成する必要があります。この場所にディレクトリ"security"が存在しない場合は、手動で作成する必要があります。login.propertiesを編集し、Cognitoのレルムを定義する必要があります。

次のことに注意してください。

EDQがHTTPS接続をサポートしていることを確認してください。
Marketplaceイメージは、Apache HTTPDフロント・エンドにSSLを実装するため、これ以上のアクションは必要ありません。
Webフロント・エンドを使用せずにEDQに接続する場合は、アプリケーション・サーバーでHTTPSを構成する必要があります。

詳細は、WebLogicまたはTomcatのドキュメントを参照してください。

# Realms

realms = cognito

cognito.realm                   = yourdomain.com
cognito.label                   = Cognito user pool
cognito.type                    = cognito

cognito.region                  = eu-west-1
cognito.pool                    = eu-west-1_z9wkvtsPx
cognito.proxy                   = proxyserver:port
cognito.access_key              = AKIAVWUKAYEFKZM7GFVU
cognito.access_secret           = lapirJ3l8n4+lD43TCDReFXexS....
cognito.prof.defaultusergroup   = edq-users
cognito.xgmap                   = edq-admins -> Administrators

cognito.extra.oidc              = true
cognito.extra.oidc.clientid     = 2p4st7jlu6ne49rchiump9ulqc
cognito.extra.oidc.clientsecret = ...
cognito.extra.oidc.redirect_uri = https://server/edq/oidc/callback

内容は次のとおりです。

realmは、Amazon Cognitoユーザー・プールで使用するドメインです。
regionはユーザー・プールのリージョンです。
poolはユーザー・プールIDです。
proxyは、EDQサーバーからインターネットへのアクセスに必要なプロキシ・サーバーのホストおよびポートです。プロキシが不要な場合、この設定は省略します。
IAMユーザーのアクセス・キーおよびシークレットへのaccess_keyおよびaccess_secret。
defaultusergroupは、EDQを使用するユーザーを含むグループの名前です。ここでは、例としてグループedq-usersが使用されています。
extra.oidc.clientidおよびextra.oidc.clientsecretは、ユーザー・プール・アプリケーション・クライアントの値です。
extra.oidc.redirect_uriは、Cognitoアプリケーションに入力されるリダイレクトURIです。URIは正確に一致する必要があります。
xgmapは、管理ログインに必要なブートストラップ・グループ・マッピングです。この例の場合、Cognitoグループedq-adminsはEDQ管理者グループにマップされます。EDQコンソールで他のグループ・マッピングを設定できます。

サーバーを再起動すると、EDQ launchpadへの参照はCognitoログイン・ページにリダイレクトされます。独自のログイン・ページを指定することも、CSSを使用して標準ページをカスタマイズすることもできます。

ユーザー属性の選択

親トピック: EDQとCognitoユーザー・プールの統合

ユーザー属性の選択

EDQでの内部および外部ユーザーは、ユーザー名、電子メール・アドレス、氏名(John Smithなど)、電話番号および組織名で表されます。氏名、電話および組織は、将来の拡張を可能にするために「vcard」属性として格納されます。Cognitoユーザー・プールと統合する場合、これらの値はユーザー・オブジェクトから属性を読み取ることによって導出されます。

値	Cognitoユーザー属性	login.propertiesのプロパティのオーバーライド
ユーザー名	Username	cognito.prof.usernameattr
電子メール・アドレス	email	cognito.prof.vcard.email.pref
氏名	name	cognito.prof.vcard.fn
電話番号	phone_number	cognito.prof.vcard.tel.work
組織		cognito.prof.vcard.org

Cognitoに標準の組織属性はありません。ユーザー・プールの作成時にカスタム属性を定義した場合は、login.propertiesで参照できます。たとえば:

cognito.prof.vcard.org = custom:organization

vcard. propertiesには複数の属性を指定できます。結果として、空以外の値を持つ最初の属性が使用されます。たとえば、カスタム組織属性と部門属性がある場合は、次のように設定できます。

cognito.prof.vcard.org = custom:department custom:organization

cognito.prof.userdisplaynameプロパティを構成することもできます。値は、ユーザー属性から構築された式です。ユーザーがEDQに表示されるたびに、結果の値が使用されます。設定されていない場合は、username@realmが使用されます。たとえば、john.smith@yourdomain.comです。ユーザー名が電子メール・アドレスの場合、またはレルムが1つのみの場合は、cognito.prof.userdisplaynameをオーバーライドして別の属性を使用できます。たとえば、ユーザー名を表示名として使用するには、次のように設定します。

cognito.prof.userdisplayname = Username

値は、よりエキゾチックな値を指定できるようにする式です。たとえば、john.smith (John Smith)などの値を作成するには、次のように設定します。

cognito.prof.userdisplayname = Username || ' (' || name || ')'

親トピック: EDQ login.propertiesファイル

Webサービスに対するOAuth2 Bearer認証の有効化

EDQとCognitoユーザー・プールの統合は、OpenID Connect SSO認証などのSSOメカニズムに基づいています。ユーザー名とパスワードを使用したプログラムによる認証はサポートされていません。

CognitoがEDQの唯一のアイデンティティ・ストアとして構成されている場合、次の機能は使用できません。

EDQ WebサービスのコールのBasic認証。
JMX接続の認証。
EDQ LaunchpadまたはJavaアプリケーションへの明示的なログイン。
組込みSSHサーバーへの接続

EDQへのJMX (JConsole、JMXTools)またはSSH接続を引き続き使用する場合、login.propertiesで「内部」レルムを有効にすることをお薦めします。

realms = internal, cognito

そのうえで、「dnadmin」などの内部ユーザーを認証に使用します。

CognitoのよるWebサービス認証の場合、EDQはOAuth2 Bearerアクセス・トークンを使用した認証をサポートします。コール側は、クライアント資格証明または認可コード・フローを使用してアクセス・トークンを取得し、それを認可ヘッダーでEDQに渡します。たとえば、次のようになります。

Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Im5PbzNaRHJPRFhFSzFqS1doWHNs......

認可コード・フローから取得したユーザー資格証明は、通常のログインと同じ方法でユーザー・アイデンティティを使用してマップされます。

アクセス・トークンおよびトークン検証の詳細は、Cognitoのドキュメントを参照してください。

次の項で説明するように、クライアント資格証明は、カスタム・ロールを使用してマップされます。

親トピック: EDQとCognitoユーザー・プールの統合

ユーザー・プールでのカスタム・スコープの構成

クライアント資格証明コールの認可は、カスタムOAuth2スコープをEDQグループにマッピングすることによって行われます。最初のステップでは、必要なカスタム・スコープをユーザー・プールに作成します。

ユーザー・プールでカスタム・スコープを構成するには:

ユーザー・プールのプロパティの「リソース・サーバー」セクションで、「リソース・サーバーの作成」をクリックします。
リソース・サーバー名およびリソース・サーバー識別子を入力します。URIは実際のサーバー・インスタンスを参照しないため、urn:edqなどの単純なURIを使用できます。
カスタム・スコープの追加をクリックします。
スコープ名と説明を入力します。
「作成」をクリックします。

親トピック: Webサービスに対するOAuth2 Bearer認証の有効化

クライアント資格証明アプリケーションの構成

ユーザー・プールにカスタム・スコープを追加したら、ユーザー・プール・プロパティでそれらをマップする必要があります。

接続の資格証明を構成するには:

ユーザー・プールのプロパティで、新しいクライアントを作成します。
機密クライアントを選択し、クライアント・シークレットの生成が有効になっていることを確認します。
コールバックURLを削除し、OAuth 2.0付与タイプとして「クライアント資格証明」を選択します。
カスタム・スコープ・セクションの「ユーザー・プールでのカスタム・スコープの構成」でリソース・サーバーに定義したスコープを選択します。

親トピック: Webサービスに対するOAuth2 Bearer認証の有効化

EDQの構成

cognito.extra.oauth2.scopemap = urn:edq/callws -> Data Stewards

ここで、scopemapは、urn:edq/callwsカスタム・スコープをEDQデータ・スチュワード・グループにマップします。

親トピック: Webサービスに対するOAuth2 Bearer認証の有効化

EDQでのアプリケーション表示の構成

OAuth2を使用してEDQサービスを呼び出すクライアント・アプリケーションには、標準ユーザーと同じ方法で内部「ユーザー」IDが割り当てられます。ケース管理など、ユーザーの更新に関する履歴情報が表示されるアプリケーションでは、アプリケーションは「アプリケーション: NAME」として表示されます。NAMEはアプリケーション・クライアントの表示名です。表示形式は、login.propertiesのappusernameプロファイル・プロパティを使用して構成できます。

cognito.prof.appusername = OAuth2 application: {0}

ここで、プロパティ値{0}はアプリケーション名で置き換えられます。

アプリケーション名の表示を有効にするために、Cognitoから取得したユーザーのリストが、アプリケーション・クライアントの問合せで拡張されます。問合せには、ListUserPoolClients APIが使用されます。デフォルトでは、EDQのクライアント・コールを行ったことがないアプリケーションは含まれません。アプリケーションがEDQに最初のコールを行う場合、その名前はケース管理ですぐには表示できません。これが問題である場合、すべてのアプリケーションが取得されるようにプロファイルのshowappsプロパティを「all」に設定できます。

cognito.prof.showapps = all

アプリケーション・リストを無効にするには、showappsを「none」に設定します。この場合、IAMユーザーにListUserPoolClients権限は必要ありません。

cognito.prof.showapps = none

親トピック: Webサービスに対するOAuth2 Bearer認証の有効化