https://blogs.oracle.com/soaproactive/entry/how_to_configure_policy_authorization
ユースケース
アクセス制限が必要なコンポジットに対し、HTTPベーシック認証と認可ポリシーを使ってアクセスを制限し、特定のグループに属するユーザに許可しようとしています。WebLogic Server管理コンソールを使ってユーザとグループを作成し、コンポジット用の認証・認可をEnterprise Managerで構成する手順をご紹介します（いくつかの設定はJDeveloperでも可能です）。
ユーザ・グループの設定
（このセクションにはスクリーンショットはありませんが、次のセクションで使います）
- WebLogic Server管理コンソールにログイン (http://<host>:<port>/console)
- 左側のメニューから「セキュリティレルム]をクリック
- ユーザとグループを作成したいレルムを選択。デフォルトは"myrealm"。
- [ユーザとグループ]タブをクリック
- [ユーザ]で[New]を選択し、新規ユーザのユーザ名とパスワードを指定。今回はBob1、Bill1、janeというユーザを使うことにする。
- [グループ]タブで新しいグループを作成する。名前はGroup1とする。
- [ユーザ]タブに戻り、Bob1を選択。
- [グループ]タブでGroup1を追加する。Bill1についても同様。意図的にjaneはこのグループに入れないでおく。
1. Enterprise Manager(EM)での設定
1.1) Enterprise Manager Fusion Middleware Controlにログイン。
1.2) [セキュリティ]＞[資格証明]をクリック。
1.3) ［マップの作成］をクリック
1.4) マップ名は'oracle.wsm.security'
1.5) 入力したら'OK'を押す。
1.6) マップを選択して、［キーの作成］を押す。
1.7) キーの名前は'basic.credentials'
1.8) ユーザ名とパスワードを入力。ここでは、管理者ユーザ（weblogic）を使用。
1.9) ［OK］を押すと、資格証明は以下のようになっているはず。
次はアプリケーション・ロールとアプリケーション・ポリシーを作成します。これらは認可ポリシーで使用します。
2. アプリケーション・ロールの作成
2.1) 左側のメニューでドメイン名を右クリック
2.2) ［セキュリティ］＞［アプリケーション・ルール］を選択
2.3) ［アプリケーション・ストライプ］のプルダウンから'soa-infra'を選択
2.4) ［追加...］を押して、新しいアプリケーション・ロール（GroupOneRole）を作成する。
2.5) ［メンバー］の下の［追加］をクリック。［タイプ］はグループにしておく。
2.6) 検索し、先ほど作成したGroup1を選択する。
2.7) ［OK］を押す。
メンバーにGroup1が追加されているはず。
3. アプリケーション・ポリシーの作成
3.1) 再度ドメイン名を右クリック。
3.2) ［セキュリティ］＞［アプリケーション・ポリシー］を選択
［アプリケーション・ストライプ］は 'soa-infra'、［プリンシパル・タイプ］は［アプリケーション・ロール］になっている。
3.3) 検索
3.4) ［作成...］をクリック
3.5) ［権限］の下の［追加］をクリック
3.6) ［続行］をクリックし、カスタムエントリフォームへ移動する（ぱっと見ではここでの選択が必要なように見えるが、実際のところ、この画面では何もできないのです）。
3.7) ［権限クラス］に 'oracle.wsm.security.WSFunctionPermission' を指定。
3.8) 今回はリソース名とアクセス権のアクションの両方に'*'を入力する。実際の実装では、おそらくWebサービスと関連するアクションを指定する。
3.9) ［選択］を押す。［権限］は以下のような表示になっているはず。
3,10) ［権限受領者］の下にある［追加］をクリック
3.11) デフォルト条件で検索して、 'GroupOneRole' を選択
3.12) 'OK' を押す。
［アプリケーション権限の作成］の画面は以下のようになっているはず。
3.13) 右上部の［OK］を押して、GroupOneRoleプリンシパルがリストに出てくることを確認。
これでプロジェクトにポリシーを追加する準備ができました。
4. WS-Policyをプロジェクトに追加
4.1) プロジェクト名を右クリック
4.2) ［ポリシー］を選択。現時点では、プロジェクトに関連づけられているポリシーはない。
4.3) [アタッチ先/デタッチ元]を選択
プロジェクトによっては、図よりも多くのコンポーネントがあるでしょうが、今回は 'bpelprocess2_client_ep' というコンポジットのエントリポイントを使うことにします。先ほどの操作で、以下の画面が開きます。
これから、3個のポリシーを追加します。
- 認証のための'oracle/wss_http_token_service_policy'
- ポリシーアクティビティのロギングのための'oracle/log_policy'
- 認可のための'oracle/binding_permission_authorization_policy'
[訳注]
JDeveloperの画面はこちら。
4.4) リストから設定するポリシーを選択し、「アタッチ］をクリック。上記3ポリシーの設定が完了すると、［直接アタッチされたポリシー］は以下のようになるはず。
4.5) ［検証］を押して、［OK］を押すと、ポリシーは以下のようになっているはず。
これで構成は完了です。
では、JMeterを使ってテストしてみましょう。HTTP認証ヘッダを付けたリクエストを送信してみます。JMeterの構成は扱いませんが、2個のリクエストに対するレスポンスをご紹介しましょう。まずは、"Bob1"で試してみましょう。
HTTP認可ヘッダの値は以下の通りです。
Basic Qm9iMTp3ZWJsb2dpYzE=サーバからのレスポンスは…
では、ドメインには属しているけれどもGroup1メンバーでないjaneで試してみましょう。
HTTP認可ヘッダの値は以下の通りで、'jane:weblogic1'がBase64でエンコードされています。
Basic amFuZTp3ZWJsb2dpYzE=
レスポンスコード403が確認できます。これは当該リクエスタによるリソースの利用が禁止されていることを意味します。標準出力には以下のようなエラーメッセージが出ています。
<Error> <oracle.wsm.resources.security> <WSM-00045> <HTTP authentication/authorization failure.>
0 件のコメント:
コメントを投稿