EDQとAzure Active Directoryの統合

8 EDQとAzure Active Directoryの統合

この章では、Azure Active Directory (AD)をOracle Enterprise Data Quality (EDQ)と統合する方法について説明します。

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

Azure ADでのEDQアプリケーションの登録
EDQは、アイデンティティ・ストアとしてAzure ADと統合できます。ユーザーおよびグループの問合せでMicrosoft Graph v1.0 REST APIを使用してAzure ADのデータにアクセスできるように、Azure ADでEDQアプリケーションを登録する必要があります。
アプリケーションでのOpenID Connect SSOの有効化
OpenID Connectを使用してSSOを有効にするには、EDQサーバーへのリダイレクトURIを構成する必要があります。単一のアプリケーション登録で複数のサーバーをサポートできるように、追加のEDQサーバーのリダイレクトURIを追加できます。
OpenID認証での複数のURIリダイレクトの有効化
OpenID統合フレームワークはEDQ 12.2.1.4.3で拡張され、受信ホスト名に基づく複数のリダイレクトURIを構成できるようになります。そのため、ロード・バランサを通じた、またはロード・バランサの背後にある特定のホストへのログインが可能になります。
EDQ login.propertiesファイルの編集
EDQでのユーザー認証は、EDQ構成領域のsecurity/login.propertiesというファイルを使用して構成されます。このファイルは「ローカル」構成で作成する必要があります。この場所にディレクトリ"security"が存在しない場合は、手動で作成する必要があります。login.propertiesを編集し、Azure ADのレルムを定義する必要があります。
Webサービスに対するOAuth2 Bearer認証の有効化
Azure ADでの認証は、OpenID ConnectやSAMLなどのSSOメカニズムに基づいています。ユーザー名とパスワードを使用したプログラムによる認証はサポートされていません。

Azure ADでのEDQアプリケーションの登録

EDQは、アイデンティティ・ストアとしてAzure ADと統合できます。ユーザーおよびグループの問合せでMicrosoft Graph v1.0 REST APIを使用してAzure ADのデータにアクセスできるように、Azure ADでEDQアプリケーションを登録する必要があります。

Azure ADでEDQアプリケーションを登録するには、

Azureポータルで、Azure ADインスタンス(デフォルトでは「デフォルト・ディレクトリ」という名前)に移動します。
左側にある「管理」メニューで、「アプリの登録」をクリックします。
「新規登録」をクリックし、次の手順を実行します。
- 名前を入力します。たとえば、edqgraphとします。
- 「この組織ディレクトリのみに含まれるアカウント(デフォルト・ディレクトリのみ - シングル・テナント)」を選択します
「登録」をクリックして、新しいアプリケーション登録を作成します。
「概要」画面が表示されます。
アプリケーション(クライアント) IDをコピーして保存します。このIDは、OAuth2クライアント資格証明認証のクライアントIDとして使用されます。
画面の左上にある「クライアント資格証明」をクリックします。
「新規クライアント・シークレット」をクリックし、次を実行します。
- 説明を入力します。
- クライアント・シークレットの失効日を選択します。
- 「追加」をクリックします。
- 新しいシークレット値をコピーして保存します。
  
  ノート:
  シークレットが失効する前に、EDQ構成を更新してください。
「API権限」をクリックし、「アクセス許可の追加」をクリックします。
Microsoft APIで、Microsoft Graphを選択します。
アプリケーションは、実際のサインイン・ユーザーとしてではなくバックグラウンド・サービスとして実行されます。権限を設定するには、次を実行します。
- 「アプリケーション権限」を選択します。
- 「アプリケーション」を展開し、Application.Read.Allを選択します。
- 「グループ」を展開し、Group.Read.Allを選択します。
- 「ユーザー」を展開し、User.Read.Allを選択します。
ノート:
単一の権限Directory.Read.Allは、ユーザー、グループおよびアプリケーションのアクセスをカバーします。
「API権限」ページで、「デフォルト・ディレクトリの管理者の同意の付与」をクリックします。
こうすると、アプリケーションは、追加の同意プロンプトなしで権限を使用できます。

これで、アプリケーションを使用して、Microsoft Graph REST APIコールで使用するOAuth2クライアント資格証明をリクエストできるようになりました。

親トピック: EDQとAzure Active Directoryの統合

アプリケーションでのOpenID Connect SSOの有効化

OpenID Connectを使用してSSOを有効にするには、EDQサーバーへのリダイレクトURIを構成する必要があります。単一のアプリケーション登録で複数のサーバーをサポートできるように、追加のEDQサーバーのリダイレクトURIを追加できます。

OpenID Connectを使用してSSOを有効にするには:

Azureポータルで、Azure ADインスタンス(デフォルトでは「デフォルト・ディレクトリ」という名前)に移動します。
左側の「管理」メニューで「アプリの登録」をクリックし、「Azure ADでのEDQアプリケーションの登録」で新しく登録したアプリケーションを選択します。
「概要」画面で、画面の右上にある「アプリケーションURIの追加」をクリックします。
次の画面で、「プラットフォームの追加」をクリックします。
プラットフォーム・タイプとして「Web」を選択します。
EDQインスタンスのコールバックURIを次の形式で入力します。
https://server/edq/oidc/callback
serverは、EDQインストールのホスト名です。このURIは、ログイン・フローをサポートするために使用されます。Apache HTTPDやNginxなどのWebサーバーがEDQのフロント・エンドまたはロード・バランサとして使用されている場合は、そのサーバーの名前を入力します。
URIを保存するには、「構成」をクリックします。その他の設定は、そのままにしておくことができます。
「URIの追加」をクリックします
EDQインスタンスのログアウト・フローの次のURIを入力します。
https://server/edq/oidc/loggedout
上部の「保存」をクリックして、変更を保存します。

これで、OpenID接続を使用したSSOに対するアプリケーション登録の準備が整いました。

親トピック: EDQとAzure Active Directoryの統合

OpenID認証の複数のURIリダイレクトの有効化

OpenID統合フレームワークはEDQ 12.2.1.4.3で拡張され、受信ホスト名に基づく複数のリダイレクトURIを構成できるようになります。そのため、ロード・バランサを通じた、またはロード・バランサの背後にある特定のホストへのログインが可能になります。

EDQインスタンスへのログインは、次の方法で設定できます。

自動URIの使用: login.propertiesのリダイレクトURLをautoに設定します。この場合、URLはHTTPリクエストからhttps://HOST/edq/oidc/callbackとして導出されます。
たとえば、ユーザーがhttps://lb.example.com/edq/を参照する場合、リダイレクトURIはhttps://lb.example.com/edq/oidc/callbackとして構築されます。ユーザーがhttps://instance1.example.com/edq/を参照する場合、リダイレクトURIはhttps://instance1.example.com/edq/oidc/callbackとして構築されます。ホスト名は、X-Forwarded-Host HTTPヘッダーを読み取って導出されます。X-Forwarded-Hostが存在しない場合は、Hostヘッダーが使用されます。
ホストからURIへのマッピングの使用: login.propertiesで、ホスト名からURIへのマップを定義します。この場合、ホスト名が各マッピングと比較され、最初の一致が使用されます。特殊な値 autoに加えて、noneを使用して、リダイレクションされないように指定できます。その場合、EDQ Launchpadおよびその他のアプリケーションへの通常の内部ログインが可能になります。より詳細に制御するには、先頭に~を付けてホスト名で正規表現を使用できます。一致がない場合は、デフォルトのリダイレクトURIが使用されます。
たとえば、次のようになります。
```
azure.extra.oidc.redirect_map = localhost -> none, \
                                        testhost -> none, \
                                        myalias -> https://lb.example.com/edq/oidc/callback,
                                        ~host\\d+\.example\.com -> auto
```
この例の説明:
- https://localhost/edq/またはhttps://testhost/edq/への参照はリダイレクトされず、直接ログイン・アクセスが付与されません。
- https://myalias/edq/への参照では、ロード・バランサのリダイレクトが使用されます。
- https://host23.example.com/edq/への参照は、https://host23.example.com/edq/oidc/callbackにリダイレクトされます。

親トピック: EDQとAzure Active Directoryの統合

EDQ login.propertiesファイルの編集

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

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

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

# Realms 
realms = azure 
# yourdomain.com users and groups at Azure AD 
azure.realm                   = yourdomain.com
azure.label                   = Azure AD
azure.type                    = azure 
azure.clientid                = clientid
azure.clientsecret            = clientsecret
azure.tenant                  = tenant ID
azure.proxy                   = <proxy server>:port
azure.prof.groupfilter        = startsWith(displayName, 'edq-')
azure.prof.userdisplayname    = userName
azure.prof.defaultusergroup   = edq-users 
azure.extra.oidc              = true
azure.extra.oidc.redirect_uri = https://server/edq/oidc/callback
azure.xgmap                   = edq-admins -> Administrators

内容は次のとおりです。

- realmは、Azure ADインスタンスのカスタム・ドメインです。
- tenantは、AzureテナントIDです。
- clientidおよびclientsecretは、Azure ADアプリケーションの値です。
- proxyは、EDQサーバーからインターネットへのアクセスに必要なプロキシ・サーバーのホストおよびポートです。プロキシが不要な場合、この設定は省略します。
- groupfilterは、EDQで使用するグループを選択する、Microsoft Graphの$filter式です。例に示されている値は、名前がedq-で始まるすべてのグループを返します。フィルタリングの詳細は、Microsoftのドキュメントを参照してください。すべてのグループを表示する場合は、この設定を省略します。
- defaultusergroupは、EDQを使用するユーザーを含むグループの名前です。ここでは、例としてグループedq-usersが使用されています。
- extra.oidc.redirect_uriは、Azure ADアプリケーションに入力されるリダイレクトURIです。URIは正確に一致する必要があります。
- xgmapは、管理ログインに必要なブートストラップ・グループ・マッピングです。この例の場合、Azureグループedq-adminsはEDQ管理者グループにマップされます。EDQコンソールで他のグループ・マッピングを設定できます。

サーバーを再起動すると、EDQ Launchpadへの参照はMicrosoftログイン・ページにリダイレクトされます。

親トピック: EDQとAzure Active Directoryの統合

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

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

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

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

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

realms = internal, azure

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

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

Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Im5PbzNa ......

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

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

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

親トピック: EDQとAzure Active Directoryの統合

EDQでBearer認証をサポートするためのAzureアプリケーションの構成

EDQでのBearer認証をサポートするようにAzureアプリケーションを構成するには:

Azureポータルで、Azure ADインスタンス(デフォルトでは「デフォルト・ディレクトリ」という名前)に移動します。
左側にある「管理」メニューで、「アプリの登録」をクリックします。
「概要」画面で、画面の右上にある「アプリケーションURIの追加」をクリックし、「設定」をクリックします。
api://1b843028-71bd-47e7-b62e-7859c0a96627などのデフォルト値が指定されますが、Azureディレクトリ・インスタンスで一意であるかぎり、api://の後に任意の値を使用できます。

ノート:
参照しやすいように、このトピックのここからは、値をapi://edqであると想定します。
「保存」をクリックしてURIを格納します。その他の設定は、そのままにしておくことができます。
クライアント資格証明トークンをリクエストするOAuth2コールでは、スコープapi://edq/.defaultを使用する必要があります
EDQ Webサービスをコールするアプリケーションは、アプリケーション・ロールまたはグループ・メンバーシップを使用して認可されます。既存のAzureアプリケーションのロールを定義するには、「アプリケーション・ロール」をクリックし、「アプリケーション・ロールの作成」をクリックします。
ポータルで使用される表示名、構成に使用される値および説明を入力します。
許可されるメンバー・タイプとして「アプリケーション」を選択します。たとえば、単純なWebサービス・コールおよびシステム管理に使用するロールを定義できます。

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

Azure ADでのクライアント・アプリケーションの作成

OAuth2クライアント資格証明を使用したEDQへのコールは、Azureアプリケーションのかわりに実行されます。

アプリケーションを作成するには、次のステップを実行します。

「Azure ADでのEDQアプリケーションの登録」の説明に従って、アプリケーション登録を作成します。
アプリケーション(クライアント) IDおよびクライアント・シークレットをコピーして保存します。
EDQでの認可にアプリケーション・ロールを使用している場合は、「API権限」をクリックし、「アクセス許可の追加」をクリックします。
「自分のAPI」を選択し、graph+SSOアプリケーションをクリックします。
必要なロールを選択し、管理者の同意を付与します。
新しいクライアント・アプリケーションが、graph+SSOアプリケーションで選択したロールに関連付けられるようになりました。
EDQでのアプリケーション認可にグループ・メンバーシップを使用している場合は、必要なAzureグループを選択し、新しいアプリケーションをメンバーとして追加します。

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

ロールをマップするためのEDQ login.propertiesファイルの編集

login.propertiesに設定を追加して、アクセス・トークンのオーディエンスおよび発行元の要求を確認し、rolemap設定を追加してアプリケーション・ロールをEDQグループにマップします。login.propertiesに次の内容を追加します。

azure.extra.oauth2.token.aud = api://edq
azure.extra.oauth2.token.iss = https://sts.windows.net/TENANTID/
azure.extra.oauth2.rolemap   = administration -> Administrators, callers -> Data Stewards

rolemapの設定例では、管理ロールをEDQ管理者グループにマップし、コール元ロールをEDQデータ・スチュワード・グループにマップします。EDQでのアプリケーション認可にグループを使用している場合、ロールマップ設定は不要です。

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

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

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

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

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

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

azure.prof.showallapps = true

appfilterプロファイル・プロパティを使用して、アプリケーションを名前でフィルタできます。

azure.prof.appfilter   = startsWith(displayName, 'Studio')

OAuth2クライアント・コールがインストールに使用されていない場合、appfilterプロパティを特別な値'none'に設定することで、アプリケーション・リストを無効にできます。

azure.prof.appfilter = none

この場合、グラフのApplication.Read.All権限は必要ありません。

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