指定されたリソースについて Web サービスクライアントによりディスカバリサービスのクエリーおよび変更プロトコルが呼び出されたときの承認アクションを定義します。
指定されたリソースについて Web サービスクライアントにより Liberty 個人プロファイルサービスのクエリーおよび変更プロトコルが呼び出されたときの承認アクションを定義します。
URL ポリシーエージェントサービスの承認アクションを定義します。HTTP URL および HTTPS URL を保護するポリシーの定義に使用されます。これが、OpenSSO のポリシーのもっとも一般的な用途です。
現在、OpenSSO ポリシーエージェントでは、http:// と https:// のリソースのみをサポートしています。また、ホスト名の代わりに IP アドレスを使用することはできません。
プロトコル、ホスト、ポート、およびリソース名にはワイルドカードを使用できます。次に例を示します。
http*://*:*/*.html
URL ポリシーエージェントサービスでは、ポート番号が入力されていない場合のデフォルトのポート番号は、http:// では 80、https:// では 443 となります。
注 – 手順 6 と 7 は参照ポリシーには使用できません。
検索 (ディスカバリサービス)
更新 (ディスカバリサービス)
変更 (Liberty 個人プロファイルサービス)
クエリー (Liberty 個人プロファイルサービス)
GET (URL ポリシーエージェント)
POST (URL ポリシーエージェント)
同意のための対話 — リソースに関する同意を求める Liberty 対話プロトコルを呼び出します。これは、Liberty 個人プロファイルサービスタイプにのみ使用できます。
値のための対話 — リソースに関する値を求める Liberty 対話プロトコルを呼び出します。これは、Liberty 個人プロファイルサービスタイプにのみ使用できます。
許可 — ルールで定義されているリソースと一致するリソースへのアクセスを許可します。
拒否 — ルールで定義されているリソースと一致するリソースへのアクセスを拒否します。
ポリシーでは、常に拒否ルールが許可ルールより優先されます。たとえば、特定のリソースに関する 2 つのポリシーがあり、一方はアクセスを拒否し他方はアクセスを許可する場合、両方のポリシーとも条件が満たされているときは、結果としてアクセスは拒否されます。拒否ポリシーは、ポリシー間の競合を引き起こす可能性があるので、慎重に使用することをお勧めします。通常、ポリシー定義プロセスでは許可ルールだけを使用し、どのポリシーでも拒否のケースを実現できない場合にデフォルトの拒否を使用するようにしてください。
明示的な拒否ルールを使用すると、特定のユーザーにさまざまな対象 (ロールまたはグループのメンバーシップ、あるいはその両方など) を介して複数のポリシーが割り当てられている場合に、1 つ以上のポリシーでリソースへのアクセスが許可されても、結果としてアクセスが拒否されることがあります。たとえば、同一のリソースについて、Employee ロールに適用可能な拒否ポリシーと Manager ロールに適用可能な許可ポリシーがある場合、Employee ロールと Manager ロールの両方に割り当てられているユーザーに関するポリシー決定は拒否になります。
このような問題を解決する方法の 1 つは、条件プラグインを使用してポリシーを設計することです。上記の例では、Employee ロールに認証されたユーザーには拒否ポリシーを適用し、Manager ロールに認証されたユーザーには許可ポリシーを適用するという「ロール条件」を利用して、2 つのポリシーを区別できます。「認証レベル」条件を使用する別の方法も考えられます。この場合、「manager」ロールがより高い認証レベルで認証します。