14 ユーザーと権限の管理
ユーザーと権限の概要
ユーザー定義の処理を開始するには、「システム」→「ユーザー管理」の順に選択します。 図14-1に示す画面が表示されます。
この画面には、現在定義されているシステム・ユーザーが表示されます。 ユーザー・アカウントごとに、アカウント名、フルネーム、電子メール・アドレスおよび認証メカニズムが表示されます。 ユーザー・アカウントのロールとステータスは、図14-2に示すカラー・コード・スキームを使用して表示されます。
システム・アカウント・タイプ
ユーザー・アカウントだけでなく、RUEIユーザー・インタフェースへのアクセス権を持たないシステム・アカウントも作成できます。 ADF監視サービスを使用する場合などは、これらのアカウントを使用して、サービス・レベルでRUEIと対話します。 システム・アカウントには完全なアクセス・レベルがあり、「表14-4」で説明する権限を持つように構成できます。
ユーザー認証
システム・ユーザーの認証は、RUEIそのものがデータベースに格納されているユーザー情報を使用して実行することも、外部の認証サーバーによって実行することもできます。 現在、RUEIは2つの外部認証メカニズムをサポートしています: LDAPサーバー経由、またはoAuth2シングル・サインオン・フレームワーク経由。 いずれの場合も、サーバーがRUEIと一緒に機能するように構成されている必要があります。 LDAPサーバーを構成する手順は、「LDAPサーバーのユーザー認証の構成」で説明されていますが、oAuth2シングル・サインオン・フレームワークを構成する手順は、「oAuth2ユーザー認証」で説明されています。
ユーザー・アカウントのロールと権限の概要
ここでは、構成機能やレポート・データへのアクセスをRUEIが管理する方法を説明します。 次の情報をよく確認することをお薦めします。
各RUEIユーザーにはロールが割り当てられます。 このロールにより、ユーザーが実行できるアクションとユーザーがアクセスできる情報の種類が決まります。 表14-1でこれらのロールについて説明します。
表14-1 ユーザー・アカウントのロール
| ロール | 説明 |
|---|---|
|
管理者 |
RUEIの初期構成を行い、システムで使用される基本的なネットワーク関連構成(メール設定やコレクタ添付)のメンテナンスを管理するユーザーです。 また、管理者権限を割り当てられたユーザーは、システムの第1レベル・サポートの役割も持ち、現在の構成のバックアップ、拡張システム設定の構成、およびシステムの操作権限のある他のユーザーの管理などを担当します。 |
|
セキュリティ担当者 |
組織のネットワーク・セキュリティ・ポリシーの影響を受けるすべてのシステム設定を管理するユーザーです。 具体的には、次のことを行います。
|
|
ビジネス・ユーザー |
事業目標に照らしてビジターの行動の評価に取り組むユーザーです。 したがって、business intelligenceを使用してシステムに提供されるbusiness intelligenceを使用すると、Webサイトで最も人気のあるパスやビジターが特定のページやセクションをどのように扱うかなど、様々な問題をモニターできます。 顧客満足度、保持率、ロイヤルティの向上、変換率の向上、Webサイト・ベースのマーケティング・アクティビティの有効性のモニタリングに関心を与えることがあります。 このユーザーは、割り当てられている権限に基づいてダッシュボード機能やオンデマンドで郵送されるレポートを使用し、組織の事業概要のメンテナンスを行います。 また、このレポートやデータのエクスポートを、ITスペシャリストに詳細な分析の基本データとして提供します。 |
|
ITユーザー |
Web環境の監視に必要となるIT情報およびその他の技術情報のサポートに従事するユーザーです。 一般に、未達成のSLAやKPIをより深く分析することを担当します。 レポート作成機能やデータ・ブラウザ機能をフル活用し、レポートされた例外またはエラーを特定します。 たとえば、特定のネットワーク・ドメインのユーザーのセッションのみが失敗していることを突き止めます。 |
|
レポート・データのエクスポート |
これらのユーザーはBasic認証を使用してレポートにアクセスします。 この機能の詳細は、「レポート・データのエクスポート」を参照してください。 |
|
セッション診断 |
これらのユーザーは、「セッション診断」ページにアクセスできます。 詳細は、「セッション診断機能の使用」を参照してください。 |
|
KPI構成の表示/編集 |
これらのユーザーは、KPI構成を表示/編集できます。 「ビジネス」またはITアクセス権内で「なし」または「概要」アクセス・レベルを持つユーザーは、KPI構成の表示のみが可能です。 ビジネスまたはITのアクセス権(「照会」、「アナリティク」、「完全」、「管理者」、「セキュリティ担当者」など)を持つユーザーはKPI構成を編集できます。 |
|
ダッシュボード・テンプレートの編集 |
ユーザーはテンプレートを作成、編集および公開できます。 |
ユーザー・アカウントのロール
ユーザーには、組織で必要とされる構成に応じて、これらのロールの組合せを実行する権限を付与できます。 定義できるユーザーの数には制限がありません。
スーパー管理者と権限が割り当てられた管理者
RUEIにはスーパー管理者という1つの事前定義済ユーザーがあることに注意してください。 このユーザーは、他のすべてのユーザーとは異なり、初期パスワードがset-admin-password.shスクリプトを使用して設定され、常にローカルで認証されています。 業務上の要件によっては、他のユーザーに管理者権限を割り当てることができます。 ただし、そのようなユーザーはスーパー管理者の管理下に置かれます。 管理者権限が割り当てられた他のユーザーとスーパー管理者を明確に区別する必要がある場合は、スーパー管理者をadminユーザーと表記します。
相互のプロパティを変更する管理者
デフォルトでは、管理者権限を持つユーザーは、他の管理者のプロパティを変更したり、管理者ユーザー・アカウントを作成および削除できます。 セキュリティ要件と一致しない場合、この機能を無効にできます。 この手順の詳細は、『Oracle Real User Experience Insight管理者ガイド』に記載されています。
ユーザー・アカウントのアクセス・レベル権限
ロールに加えて、各ユーザー(管理者以外)には、ビジネス関連およびIT関連の情報のための個別のアクセス・レベル権限を割り当てることもできます。 これらの権限では、ユーザーがアクセスできるモジュール(データ・ブラウザ、KPI概要、システムなど)が定義されます。 これについては表14-2で説明します。
KPI定義を表示するために必要な最小権限は、「概要」アクセス・レベル以上です。 「完全」アクセス・レベルのユーザーのみが、KPI定義を変更したり、KPIをコピー/削除できます。
表14-2 ビジネス・ユーザーおよびITユーザーのアクセス・レベル権限
| アクセス・レベル | ビジネス・ユーザー | ITユーザー |
|---|---|---|
|
なし |
アクセス権限がありません。 |
アクセス権限がありません。 |
|
概要脚注1 |
ダッシュボード、KPI概要およびアラート履歴を表示可能。 |
ダッシュボード、KPI概要およびアラート履歴を表示可能。 |
|
照会 |
レポートへの読取り専用アクセス権限があり、PDFダウンロードを作成可能。 |
レポートへの読取り専用アクセス権限があり、PDFダウンロードを作成可能。 |
|
分析 |
|
|
|
フル |
|
|
脚注1
ビジネス・ユーザーまたはITユーザーのいずれかとして少なくとも概要レベルの権限がないユーザーはログインできません。
ユーザー・ロールおよびアクセス・レベル権限の管理については、「ユーザー・アカウントのロールと権限について」で説明します。
これにより、ビジネス・ユーザーおよびITユーザーは自分に関連する情報をただちに見つけることができます。 たとえば、ビジネス・ユーザーがレポート・ライブラリにアクセスすると、ビジネス・ユーザーに必要なレポートのみのリストがフィルタリングされ、作業対象のレポートに反映されます。
「表14-3」は、セッション診断データにアクセスするために必要な最小限の権限の概要を示します:
表14-3 セッション診断のためのITおよびビジネス・ユーザー権限
| アクセス・レベル | すべてのアプリケーション | 特定のアプリケーション |
|---|---|---|
|
概要 |
アクセス権なし |
アクセス権なし |
|
照会 |
アクセス権なし |
アクセス権なし |
|
分析 |
アクセス |
アクセス権なし |
|
フル |
アクセス |
アクセス |
ノート:
特定のアプリケーション、サービスまたはスイートに対する認可を制限することにより、アナリティク・ユーザーはセッション診断データ・コンテンツへのアクセスをブロックします。 セッション診断データにアクセスするには、アナリティク・ユーザーにすべてのapplication/suites/serviceの権限が必要です(特定のアプリケーションへのアクセスには不十分です)。
システム・アカウント・ロールの権限
現在システム・アカウントに関連付けられたロールはなく、次の権限のみ存在します:
表14-4 システム・アカウント権限
| アクセス・レベル | システム・アカウント |
|---|---|
|
ADF監視サービス |
これらのユーザーはRUEIを使用してADFアプリケーションを監視します。 ADFを使用するためのRUEIの設定の詳細は、RUEIインストレーション・ガイドを参照してください。 |
|
Enterprise Managerアクセス |
これらのユーザーは、Oracle Enterprise ManagerでRUEIデータを使用できます。 Oracle Enterprise Managerを使用するためのRUEIの設定の詳細は、RUEIインストレーション・ガイドを参照してください。 ユーザーがOracle Enterprise Managerアプリケーション・パフォーマンス管理(APM)機能内のRUEIデータにアクセスするには、認可が必要です。 この機能については、『Oracle Enterprise Manager Cloud Control Oracle Fusion Middlewareマネージメント・ガイド』で詳細に説明されています。 |
新規ユーザーの追加
新規ユーザーを作成する手順は、次のとおりです。
- 「システム」→「ユーザー管理」を選択し、タスクバーの「新規アカウントの追加」コマンド・ボタンをクリックします(図14-1を参照)。 図14-3に示すようなダイアログが表示されます。
LDAPまたはoAuth2サーバー接続が構成されている場合(「LDAPサーバーのユーザー認証の構成」を参照)、「図14-3」に示すダイアログにLDAP認証オプションが表示されます。
図14-3 アカウントの追加ウィザード
- 図14-4に示すダイアログを使用して、新しいアカウントに関する次の情報を指定します:
-
インストール済RUEI内でユーザーを識別するユーザー名。 この名前は一意である必要があります。 ユーザー名は大/小文字が区別されます。 oAuth2サーバー・ユーザー認証が有効な場合、ユーザーはoAuth2ユーザーとして自動的に作成されます。 この場合、指定されたユーザー名は、oAuthサーバー内で定義されたユーザー名と同じである必要があります。
-
ユーザーのフルネーム。
-
ユーザーの電子メール・アドレス。 これがレポートと電子メール・アラートの送信先アドレスになります。 正しいアドレスであることを確認してください。
-
ユーザーをインストール済RUEIでのローカルの設定と照合して認証する場合は、新規ユーザーのパスワードを指定および確認入力しておく必要があります。 パスワード要件の詳細は、「パスワード・セキュリティ・ポリシーの実施」を参照してください。 新規パスワードは、7日以内にユーザーが変更する必要があります。あるいは、ロックアウトされます。
-
必要に応じて、「無効」チェック・ボックスを使用して、当座の間ユーザーを無効化できます。 また、後で有効化することもできます。
図14-4 「ユーザーの詳細」ダイアログ
図14-3で構成済のLDAPサーバーに対してユーザーを認証するように選択した場合は、「LDAPからユーザー・データを取得」ボタンをクリックして、構成済のLDAPサーバーからユーザーの設定を取得できます。
ノート:
リモート認証(LDAPまたはoAuth2)の場合、「アカウントの詳細」には「新しいパスワード」および「パスワード確認」エントリ・フィールドが含まれず、ローカル・パスワードを指定する必要はありません。
-
- 「標準」タブで、ビジネス・アクセス・レベル・メニューのチェック・ボックスとITアクセス・レベル・メニューを選択して、新規ユーザーに割り当てるロールと権限を指定します。
図14-5 ユーザー・アカウントの権限
- システム・アカウントを追加する場合は、図14-6に示すダイアログが表示されます。
図14-6 システム・アカウントの権限
システム・アカウントには、アプリケーション、スイートおよびサービス・データへのフル・アクセス権があります。 ADF監視サービスおよびEnterprise Managerアクセスの設定の詳細は、RUEIインストレーション・ガイドを参照してください。
既存のユーザーの変更
ユーザー定義を変更するには、「システム」→「ユーザー管理」の順に選択します。 図14-1に示す「ユーザー管理」パネルが表示されます。 目的のユーザーを右クリックします。 図14-7に示すコンテキスト・メニューが表示されます。
図14-7 ユーザー・メニュー
「図14-7 ユーザー・メニュー」の説明
「表14-5」に示されているオプションを使用できます。
表14-5 ユーザー・コンテキスト・メニュー・オプション
| オプション | 説明 |
|---|---|
|
編集 |
ユーザーの定義を変更できます。 これについては、「ユーザー設定の変更」で説明しています。 |
|
アカウントの有効化/無効化 |
当座の間、ユーザー・アカウントを有効化または無効化できます。 現時点で定義されているすべてのユーザーは、SSO認証が有効化されると無効になります。また、すべてのSSOユーザー・アカウントはSSO認証が無効化されると無効になることに注意してください。 |
|
切替え |
選択したユーザーに一時的に切り替えることができます。 これは、そのユーザーに表示権限があるモジュールやレポートを表示する場合に役立ちます。 自身のロールに戻るには、「ビュー」メニューから「スイッチ・バック」を選択します。 選択したユーザー・アカウントが無効の場合には、このオプションは使用できないことに注意してください。 |
|
削除 |
選択したユーザーをシステムのユーザー管理から削除します。 そのユーザーが作成したプライベート・レポートも削除されるため、注意してください。 ただし、そのユーザーが作成したパブリック・レポートは引き続き他のユーザーから使用できます。 |
ユーザーの設定の変更
既存のユーザーの設定を変更する手順は、次のとおりです。
- ラジオ・ボタンを使用して、ユーザーの設定を、インストール済RUEIでの設定(デフォルト)または構成済のLDAPサーバーのどちらと照合して認証するかを指定します。 準備ができたら、「次へ」をクリックします。 LDAPサーバーが構成されている場合は、図14-4に示したダイアログが表示されます。 そうでない場合は、図14-8に示すダイアログが表示されます。
- 必要に応じて、表示された任意の情報を変更します。 赤のアスタリスクが付いているフィールドは必須であることに注意してください。 つまり、空白にはできません。
「無効」チェック・ボックスを使用して、ユーザーによるこのアカウントの使用を無効化できます。 無効化したユーザーは後で有効化することもできます。
ユーザーが正しいパスワードの入力を5回連続して失敗すると、ユーザー・アカウントは自動的にロックされます。このような場合は、「ロック済」チェック・ボックスの選択を解除してロックをリセットできます。 パスワードのセキュリティについては、「パスワード・セキュリティ・ポリシーの実施」で説明しています。 このチェック・ボックスを使用して、ユーザーのアカウントのロックを解除できます。 準備ができたら、「次へ」をクリックします。 図14-9に示すダイアログが表示されます。
ノート:
このインタフェースでユーザー・パスワードを変更した場合、ユーザーは7日以内に(「環境のカスタマイズ」で説明する手順を使用して)パスワードを変更する必要があります。そうしないと、アカウントがロックされます。
例14-1 スーパー管理者のパスワードのリセット
adminユーザーのパスワードをリセットする必要が生じた場合は、set-admin-password.shスクリプトを使用して対応できます。 この詳細は、『Oracle Real User Experience Insightインストレーション・ガイド』を参照してください。 新しいパスワードは7日以内に(「ユーザー設定の変更」で説明する手順によって)変更する必要があることに注意してください。
パスワード・セキュリティ・ポリシーの強制
各ユーザーを定義してRUEIを使用できるように認可する必要があります。 これを行う手順は、「ユーザーと権限の概要」で説明しています。 インストール環境のセキュリティを最適化するために、パスワード設定機能を使用して組織のセキュリティ・ポリシーを強制できます。 具体的には、ユーザー・パスワードの最大長、ユーザーがパスワードを変更する必要がある頻度、新規ユーザー・アカウント作成後のパスワードの変更期限、およびユーザー・アカウントがロックされるまでのログオン試行の失敗回数を制御できます。
インストール環境のパスワードの強制を設定する手順は、次のとおりです。
- 「システム」→「ユーザー管理」→「パスワード設定」をクリックします。 図14-10に示すダイアログが表示されます。
図14-10 パスワード設定
「図14-10 パスワード設定」の説明
例14-2 パスワード強制
ユーザーを作成して認可すると、次のルールが自動的に強制されます。
-
指定の回数の試行が失敗すると、ユーザー・アカウントがロックされます。 ユーザーが再度ログオンできるようにするには、アカウントのロックを解除する必要があります(「ユーザー設定の変更」で説明)。 ただし、ロックされたユーザーにも、メール送信されるレポートやアラートが引き続き届きます。
-
パスワードの有効期限を0に設定し、後で0以外の値に再設定した場合(またはその逆の場合)、新しく指定した方のパスワード有効期限が既存のすべてのユーザー・アカウントに適用されます。
-
ユーザー・パスワードの最小長は8文字です。 ユーザー・パスワードには、英数字以外の文字($、@、&、!など)を少なくとも1文字含める必要があります。
-
パスワードには、定義済のユーザー名またはその姓や名を含めることはできません。 また、ユーザーの直前の3つのパスワードも記憶され、再使用できません。
-
パスワードは大/小文字が区別されます。
モジュールにおける許可データの有効範囲の管理
「完全」アクセス・レベル権限を持つユーザーは、データ・ブラウザ、レポート、KPI概要機能およびダッシュボード内のすべての情報にアクセスできます。 それ以外のすべてのユーザーの場合、アクセスできる情報は各ユーザー・プロファイルの一部として管理されます。 この機能の使用方法の詳細は、「ユーザー・アカウントのロールと権限について」を参照してください。
汎用vs.アプリケーション、スイート、サービス固有の項目、およびアプリケーション・ディメンション・アイテム
KPI、ユーザー・フローおよびダッシュボードは、汎用として定義することも、特定のアプリケーション、スイート、サービスまたはアプリケーション・ディメンションの値にバインドすることもできます。 項目内の情報へのアクセスは、各ユーザーに割り当てられる権限を介して自動的に管理されます。
項目が汎用として定義された場合は、すべてのアプリケーションへのアクセスが承認されているユーザーしか表示できません。 汎用項目には、複数のアプリケーション、スイートまたはサービスの情報が含まれる場合があるためです。 同様に、ユーザーが表示を許可されているのが2つのアプリケーションの情報のみの場合、その2つのアプリケーションに直接関連するKPI、ダッシュボード、データ・ブラウザ情報およびレポートしか表示できません。
ユーザーにアプリケーション・ディメンション値の情報を表示する権限がある場合、このアプリケーション・ディメンション値に関連するKPI、ダッシュボード、データ・ブラウザ情報およびレポートを表示できます。 KPI、ダッシュボード、データ・ブラウザ情報およびレポートがアプリケーション・ディメンションvalue(for example an application group)内のapplications/suites/webサービスのいずれかに関連付けられている場合は、このユーザーが表示できます。
LDAPサーバーのユーザー認証の構成
セキュリティを強化するために、インストール済RUEIのローカルでの設定を使用せずにLDAPサーバーを使用してユーザー認証を有効化するようにRUEIを構成できます。 LDAPサーバー接続が構成されている場合は、定義済のユーザーごとに、使用する認証方式を指定できます。 adminユーザーは事前定義済であり、そのパスワードは初期構成時に設定されるため(『Oracle Real User Experience Insightインストレーション・ガイド』を参照)、管理者ユーザーにはローカル認証のみを使用できます。
LDAP認証を使用する場合は、ユーザー・アカウントを作成する前にLDAP接続を定義することをお薦めします。 これは、以前に指定したユーザー設定の変更を不要にするためです。
LDAPサーバーの証明書の構成
LDAPセキュア・サーバーの証明書は、PEM形式を使用して、/etc/openldap/ldap.confファイルのTLS_CACERTディレクティブで指定する必要があることに注意してください。 証明書ファイルはルート・ユーザーが所有し、RUEIおよびApacheユーザー・グループが読取り可能である必要があります。 LDAPサーバーの証明書のCNは、LDAPサーバーの完全修飾ドメイン名に一致する必要があることに注意してください。
LDAP接続の問題のトラブルシューティング
前述のLDAPセキュア・サーバーの証明書を構成する手順で、機能する接続が確立されない場合は、OpenLDAPユーティリティ(Oracle LinuxまたはRedHat Enterprise Linuxの配布セットに付属)を使用して、LDAPサーバーの構成を検証できます。 このユーティリティをインストールして実行するには、次のコマンドを使用します。
sudo yum install openldap-clients
ldapsearch -x -P 2 -H "LDAP_server_URL" -D
cn=jsmith, dc=oracle, cn-com
LDAP_server_URLではLDAPサーバーの完全なURLを指定し、ペアの組合せはLDAPサーバーの構成によって決まります。 正しく指定すると、そのユーザーに関する情報がLDAPサーバーから返されます。 そうでない場合は、発生した問題(指定したホスト名がLDAPサーバーと一致しない、またはLDAP証明書が正常にインストールされていないなど)がレポートされます。
証明書が機能しない場合は、/etc/openldap/ldap.confファイルでTLS_REQCERTディレクティブをneverに設定すると、証明書の検証やセキュアな接続の継続を中止できることに注意してください。
-
「システム」→「ユーザー管理」→「LDAP接続の構成」をクリックします。 LDAPサーバー接続がすでに構成されている場合、最後のオプションは「LDAP接続の変更」として表示されます。 図14-11に示すダイアログが表示されます。
図14-11 「LDAP設定」ダイアログ
「図14-11 「LDAP設定」ダイアログ」の説明 -
「表14-8」に示す情報を指定します。
表14-8 LDAP設定アナログ・フィールド
フィールド 説明 LDAP認証を許可
LDAPサーバーをユーザー認証に使用できるかどうかを指定します。 デフォルトでは選択されていません(無効化されています)。
サーバー名
使用するLDAPサーバーのホスト名またはIPアドレスを指定します。 サーバー名にプロトコル情報(LDAP://など)を含めないでください。
接続タイプ
LDAPバージョンおよび接続方法を指定します。 デフォルトはV2(非セキュア)です。
ポート番号
LDAPサーバーがリスニングしているポートを指定します。 この情報については、必要に応じてシステム管理者に問い合せてください。 デフォルト・ポートは389または636(SSL暗号化用)です。
検索ベース
ユーザーIDを一意にする必要があるディレクトリ構造の場所を指定します。 この場所には有効なDNを指定する必要があります。 パフォーマンス上の理由により、この場所にはできるかぎり深いディレクトリを指定してください。 デフォルトはディレクトリ・ツリーのルートです。
Anonymous
LDAPサーバー参照を匿名ユーザーを使用して実行する必要があるかどうかを指定します。 選択しない場合は、有効な識別名(DN)を指定する必要があります。このユーザーのパスワードは、新規ユーザーとして作成される際に要求されます。 デフォルトでは、匿名参照が使用されます。
ユーザーID、電子メール・アドレス、フルネーム
LDAPサーバーからユーザー設定を抽出するために使用する必要がある属性を指定します。 デフォルトは標準のLDAP機能に基づいています。 これらの属性については、必要に応じてLDAP管理者に問い合せてください。
-
必要に応じて、「テスト」をクリックして、LDAPサーバーに対して、機能する接続を確立できるかどうかを検査できます。 この詳細は次の項に記載されています。 次に、「保存」をクリックします。
LDAP構成設定に対して指定した変更は即座に有効になります。
LDAPサーバーのテスト
前述のように、LDAPサーバーに対する接続はテストできます。 次を実行します。
- 図14-11内の「テスト」をクリックします。 図14-12に示すダイアログが表示されます。
図14-12 LDAP設定のテスト
「図14-12 LDAP設定のテスト」の説明
oAuth2ユーザー認証
セキュリティを強化するには、oAuth2シングル・サインオン・フレームワークを使用してユーザーを認証するようにRUEIを構成します。 oAuth2がアクティブな場合、RUEIログイン・ページにアクセスするユーザーは、構成済のoAuth2サーバーに自動的にリダイレクトされてログインします。 ユーザーがログインすると、トークンを使用してRUEIにリダイレクトされ、RUEIによってユーザー名が取得されます。
oAuth2サーバーへのクライアントの登録
oAuth2統合を構成するための前提条件として、oAuth2サーバーにクライアント・アカウントを作成します。 必要に応じて次の情報を使用して、アカウント作成手順を完了します。 このプロシージャは、oAuth2プロバイダに依存することに注意してください。
- 3-legged oAuthの指定
- リダイレクトURIは
/ruei/index.phpで終了します。 完全なリダイレクトURIは、oAuth2設定ダイアログに表示されます(次を参照)。
アカウトを作成すると、RUEI構成で設定する必要があるClient IDおよびClient Secretを受け取ります。
oAuth2統合の構成
oAuth2認証を有効にするには、RUEI UIで、「システム」、「ユーザー管理」の順に選択し、ツールバーの「oAuth2の構成」ボタンをクリックします。 oAuth2がすでに構成されている場合は、「oAuth2設定の変更」ボタンを使用します。 次に示すダイアログが表示されます
「oAuth設定」ダイアログのフィールド:
| フィールド | 説明 |
|---|---|
| oAuth2の有効化 | oAuth2統合を有効にするには、このボックスを選択 |
| クライアントID | oAuth2サーバーでクライアントを登録した後に受信したクライアントID |
| クライアント・シークレット | oAuth2サーバーでクライアントを登録した後に受信したクライアント・シークレット |
| リダイレクトURI | サインイン後にユーザーが戻す必要があるRUEI URI。 デフォルト値は、RUEIホスト名とそれに続く/ruei/index.phpです。 通常は、oAuth2サーバーにクライアントを登録するときに、このURIを指定する必要があります
|
| 有効範囲 | これは、oAuth2サーバーからリクエストするアクセス・レベルRUEIを定義します。これは通常、oAuth2サーバーの登録詳細から提供されます。 |
| サーバー・ホスト | oAuth2サーバーへのアクセスに使用するホスト名。 異なるAPI URIのホスト名が異なる場合、またはクライアントがRUEIサーバーとは異なるホスト名を使用する必要がある場合は、「詳細」タブでURLごとに個別のホスト名を指定します。 |
| 認可URL | フロントエンドURL(ホスト・コンポーネントなし)。RUEIはログイン用にユーザーをリダイレクトします。 |
| トークンURL | RUEIサーバーが認可コードを送信し、アクセス・トークンを受信するために使用する、ホスト・コンポーネントがないバックエンドURL。 |
| ログアウトURL | ホスト・コンポーネントがないフロントエンドURL。ここで、RUEIは、ユーザーがログアウト・オプションを選択したときにユーザーをリダイレクトします。 |
「oAuth詳細設定」ダイアログのフィールド:
| フィールド | 説明 |
|---|---|
| プロキシ | RUEIサーバーでoAuth2サーバーへのアクセスにプロキシを使用する必要がある場合は、ここでそのプロキシの名前を指定します。 それ以外の場合は、空白のままにします。 |
| ユーザー フィールド | これは、ユーザー名を含むアクセス・トークンまたは資格証明トークン内のフィールドです。 |
| 資格証明URL | RUEIサーバーがユーザー名情報をフェッチできるホスト・コンポーネントがないバックエンドURL。 ユーザー名情報がログイン・トークンに含まれている場合は、このフィールドを空白のままにできます。 |
| ホストの承認 | サーバー・ホストと異なる場合は、認可URLとともに使用するホスト名。 |
| トークン・ホスト | サーバー・ホストと異なる場合、トークンURLとともに使用するホスト名。 |
| 資格証明ホスト | これがサーバー・ホストと異なる場合、資格証明URLとともに使用するホスト名。 |
| ログアウト・ホスト | ログアウトURLとともに使用するホスト名(サーバー・ホストと異なる場合)。 |
oAuth2ベースのユーザーにRUEIの使用を許可
oAuth2サーバー設定の構成後に、oAuth2ベースのユーザーのRUEIユーザー・アカウントを作成します。 これらのユーザーを作成する場合は、oAuthベースの認証を指定する必要があります。
ローカル・アカウント
組込みの管理アカウントを含むローカル・アカウントを持つユーザーは、oAuth2統合を使用してログインできません。 ローカルでログインするには、/ruei/admin.phpで終わる管理ログインURLにアクセスする必要があります。
外部認証
RUEIは、認証自体を実行するかわりに外部識別ツールを使用して構成することもできます。 この外部識別ツールは、RUEIを保護されたリソースと分離し、認証済ユーザーによるWebサーバーへのアクセスのみを許可します。
次に、この外部ツールは、識別されたユーザーを含むヘッダーを設定します。 これらのヘッダーには、デフォルトではREMOTE_USERという名前が付けられます。
ノート:
インタフェースに直接アクセスしないように十分に注意することが重要です(adminユーザーの場合はadmin.phpを除く)。
外部認証機能を使用する場合、RUEIでは独自の認証が実行されないため、ユーザー・ログイン資格証明の有効性は確認されません。
構成
インストール後、外部認証をアクティブ化するには、次の構成を実行する必要があります。 次のコマンドをRUEI_USERユーザーとして実行します:
execsql config_set_value wi_core extauth_enabled 1
オプションで、次のオプションについて上記を繰り返すことができます(extauth_enabledを下のオプション値に置き換えます):
extauth_header
ユーザーIDを含むHTTPヘッダーで、プレフィクスにHTTP_が付加されます。
extauth_login_url
リダイレクトするログインURL (ヘッダーが空の場合)。
extauth_logout_url
リダイレクトするログアウトURL。
プレースホルダー%sの上のURLsはどちらも、ログインまたはログアウト後に再表示するRUEI URLを指定するために使用できます。