[SOA/BPM] Authorization Model in SOA Suite 11g

原文はこちら。
https://blogs.oracle.com/soaproactive/entry/authorization_model_in_soa_suite

---

SOA Suite 11gでどのように認可が行われるのかをWebLogic Server管理コンソールとEnterprise Managerの間で解き明かすことは困難かと思います。このエントリでは、どのように2つが協調して動作するのかを説明し、うまくいけば思ったよりも簡単であることを示すことを目的としています。

SOA Suite 11gでは、一つの認証スタックと2つの認可スタックがあります。

1. 認証（Authentication）はWebLogic Serverが担当します。セキュリティレルムの認証プロバイダーの順番と、それらに設定された制御フラグに基づいて認証します。
2. 認可（Authorization）はWebLogic Serverのグローバル・ロール定義とEnterprise Manager Fusion Middleware ControlのSOAアプリケーション・ロールに分かれています。WebLogic ServerのロールはWeblogic Server管理コンソールでのやりとりを管理し、SOAロールはSOAリソースやアクティビティの権限を管理します。ほとんどの場合、ユーザーは両方にアクセスする必要があります。

では、認可スタックを説明していきます。

WebLogic Serverでは、グローバル・ロールを標準で定義しており、WebLogic Server管理コンソールで設定します。今回の目的では、「Admin」グローバル・ロールを取り上げます。これはEnterprise Managerにも同等のものがあり、こちらも他のロールを代表するものです。標準のドメインでは、このロールには、事前設定された'Administrators'グループをメンバーシップ条件だけがあります。これは、 "Administrators"と呼ばれるグループのメンバーであるすべてのユーザーが、WebLogic Serverの'Admin'グローバル・ロールの権限が付与されることを意味します。ユーザーがWebLogic Server管理コンソールやEnterprise Managerにログインするためには、グループもしくは個々のユーザーに関連付けられる形でWebLogic Serverのグローバル・ロールの少なくとも一つの権限を持っている必要があるので、これは重要です。

WebLogic Serverロールにアクセスするには

1. WebLogic Server管理コンソールにログイン(http://host:port/console)
2. 左のドメイン構造から［セキュリティ・レルム］を選択
3. デフォルトでは、"myrealm"と呼ばれる一つのレルムがあるので、それを選択
4. ［ロールとポリシー］タブを選択
5. リストの［グローバル・ロール］を展開
6. ［Roles］を展開
7. 'Admin'ロールが先頭行にあるので、［ロール条件の表示］をクリックして内容を確認

デフォルト構成では、条件は以下のようになっています。

SOA SuiteのEnterprise Manager Fusion Middleware Controlでは、アプリケーション・ロールをsoa-infraアプリケーションのために利用できますが、そのうちの一つが"SOAAdmin"です。標準でこのロールは一つのメンバー（WebLogic ServerからのAdministratorsグループ）を有しています。このロールが提供する権限にはコンポジットのデプロイやEnterprise Managerでのインスタンス管理などが含まれています。ユーザーとグループだけをEnterprise Managerのアプリケーション・ロールに関連づけることができます。これはつまり、WebLogic Serverの"Admin"グローバル・ロールが明示的にユーザーに付与されますが、WebLogic Serverの"Administrators"グループもしくは明示的にEnterprise Managerで"SOAAdmin"ロールにユーザーを追加しない場合には、自動的にコンポジットのデプロイの権限が付与されません。

Enterprise Managerのsoa-infraロールにアクセスするには

1. Enterprise Manager Fusion Middleware Controlにログイン (http://host:port/em)
2. 左ペインのSOAを展開
3. 'soa-infra'を右クリック
4. ［セキュリティ］を選択し、［アプリケーション・ロール］を選択
5. テキストボックスを空白にしたまま、検索の右矢印アイコンをクリック
6. soa-infraアプリケーションのためのアプリケーション・ロールの全リストが出てくる。先頭に'SOAAdmin'がある。
7. 'SOAAdmin'を選択し、［編集...］ボタンをクリック
8. ロールメンバーを確認できる。デフォルトではWebLogic Serverの'Administrators'グループのみが含まれている。

以下のような感じになっているはずです。

2つの認可スタックの間をつなぐのは、system-jazn-data.xmlファイルで、これは<domain_home>/config/fmwconfig にあります。デフォルトでは、このファイルにはアプリケーションデプロイメントや関連するEnterprise Managerのロールのすべてに対する参照が格納されています。以下はsoa-infraのエントリを抜粋したものです。

   soa-infra
      
         
            SOAAdmin
            SOA Admin Role
            SOA application admin role, has full privilege for performing any
            operations including security related
            88293480FE7711E08F7531B0B4CEDB15
            oracle.security.jps.service.policystore.ApplicationRole
            
               
                  weblogic.security.principal.WLSGroupImpl
                  Administrators
               
         
       
   
 

ここでは、唯一のsoa-infraアプリケーションと関連づけられている最初のロール、'SOAAdmin'だけに着目します。また、WebLogicの'Administrators'グループが関連付けられていることを指定するmembers'要素も参照します。'class'エントリは、オブジェクト'Administrators'の一種であることを示しており、EMのロールにユーザーを追加した場合、Userクラスタイプを持つ追加の'member'エントリを参照します。
ご注意いただきたいのですが、クラスタ環境では、この情報をOIDを使い、データベースもしくはLDAPに永続化することを強く推奨します。設定された永続性のタイプの変更に関する詳細は以下のリンクからどうぞ。

Using the Oracle Database as a Policy Store for SOA11
http://blogs.oracle.com/soaproactive/resource/SOA_Authorization_Model/DB_as_Policy_Store.pdf.

これらは、デフォルトの認証プロバイダ（組み込みLDAP）を使っている標準の尾メインでは問題なく動作します。'Administrators'グループはすでに存在し、WebLogic Serverの'Admin'グローバル・ロールに関連付けられていて、Enterprise Managerの'SOAAdmin'アプリケーションロールに追加されています。しかし、別の認証プロバイダを使用している場合は、これらの接続を自分で設定する必要があります。一般的な例としてActive Directoryを使用した場合でより詳細にみていきましょう。

Active Directory認証プロバイダがWebLogic Serverで構成されていると仮定しましょう​​。認証プロバイダリストの最上位にあり、制御フラグは"REQUIRED"に設定されています。WebLogic Server管理コンソールでユーザーを参照できますが、誰もWebLogic Server管理コンソールやEnterprise Managerにログインすることはできません。これはWebLogic Serverのグローバル・ロールに関連付けられていないためで、関連付けるためには2方法あります。

1. ADにグループを作成し、これらのユーザーを追加して、このグループをWebLogic Server管理コンソールでWebLogic Serverの'Admin'グローバル・ロールに追加する。ADのグループを'Administrators'とした場合、すでにAdministratorsが条件に含まれているため、グローバル・ロールの条件に追加する必要はない。
2. ユーザーを個別のWebLogic Serverの'Admin'グローバル・ロールにWebLogic Server管理コンソールで追加する。

このやり方で、ADの'admin'ユーザーに対しWebLogic Server管理コンソールやEnterprise Manager Fusion Middleware Controlへのログイン権限を付与します。

それでは、こうしたユーザーがJDeveloperやEnterprise Managerからコンポジットをデプロイしようとした場合、'SOAAdmin'もしくは'SOAOperator'の権限が必要とのエラーを受け取ります。これは、Enterprise Managerのデフォルトロールもしくはカスタムのロールを通じて、ユーザーにsoa-infraアプリケーションの権限が付与されていないためです。'SOAAdmin'と'SOAOperator'はすぐに利用可能なデフォルトロールの例です。複数の方法があります。

1. Enterprise Managerの既存の'SOAAdmin'もしくは'SOAOperator'アプリケーション・ロールにADのグループを追加する。ADのグループを'Administrators'とした場合、サポートしている構成では標準で'Administrators'グループを使用しているため、エラーメッセージが現れることはない。
2. ADのユーザーを個別にSOAAdminやSOAOperatorといったEnterprise Managerのアプリケーション・ロールに追加する。

このアクションにより、2つの認可スタック間のギャップが埋まり、全範囲の期待される権限が許可されます。理解を助けるために2つの認可スタック間の関係を図示しました（下図）。
11.1.1.6より前のリリースでは、標準的な'Administrators'や'Operators'グループ（それぞれAdminロール、Operatorロール）と共に、WebLogic Serverのグローバル・ロールに関連づけられている限り、Enterprise Managerのアプリケーション・ロールにグループやユーザーを明示的に追加する必要はありません。11.1.1.6で挙動が変わっているため、その方法はおすすめしません。このエントリで記載したように、グループやユーザーを明示的にEnterprise Managerのロールに追加する必要があります。