Sun Java ロゴ     前へ      目次      索引      次へ     

Sun ロゴ
Sun Java System Identity Server 2004Q2 管理ガイド 

第 7 章
ポリシー管理

この章では、Sun JavaTM System Identity Server 2004Q2 のポリシー管理機能について説明します。Identity Sever のポリシー管理機能は、最上位レベル管理者または最上位レベルポリシー管理者が、すべての組織で使用できる特定のサービスに対するポリシーを表示、作成、削除、修正する手段を提供します。組織またはサブ組織管理者あるいはポリシー管理者が、その組織で特定の目的に使用するポリシーを表示、作成、削除、修正することもできます。

この章は、次の節で構成されています。

概要

ポリシーは、組織の保護されたリソースに対するアクセス権限を指定するルールを定義します。ビジネスには、保護、管理、監視しなければならない、リソース、アプリケーション、およびサービスがあります。ポリシーはこれらのリソースに対するアクセス権と使用を管理し、ユーザーがあるリソースに対して、いつ、どのようにアクションを実行できるかを定義します。ポリシーがオブジェクトに適用されると、特定のオブジェクトからアクセスできるリソースが定義されます。

注

オブジェクトとは主体です。主体とは、個人、企業、ロール、グループなど、アイデンティティを持つことができるすべてのものが該当します。詳細については『JavaTM 2 Platform Standard Edition Javadocs』を参照してください。

1 個のポリシーでは、二者択一または任意設定の決定を定義できます。二者択一の決定は、「はい」/「いいえ」、「真」/「偽」または「許可する」/「許可しない」の形式です。任意設定の決定では、属性の値を表します。たとえば、メールサービスは、ユーザーごとの最大保存容量の値セットを持つ mailboxQuota 属性を含んでいます。一般的に、ポリシーはオブジェクトが、どのような条件でどのリソースに何をできるかを定義するように設定されています。

ポリシー管理機能

ポリシー管理機能には、ポリシーの作成および管理を行うポリシーサービスが備わっています。ポリシーサービスにより、管理者は Identity Server 配備の中でリソースを保護するために、アクセス権を定義、変更、付与、無効化、および削除することができます。通常、ポリシーサービスには、データストアと、ポリシーの作成、管理、評価ができるインターフェースライブラリ、およびポリシーエンフォーサ (ポリシーエージェント) が含まれています。Identity Server は Sun Java System Directory Server をデータ保存に使い、ポリシーの評価とポリシーサービスのカスタマイズのために Java と C の API を提供します。詳細は『Identity Server Developer's Guide』を参照してください。また、管理者は Identity Server コンソールを使用してポリシー管理を行うこともできます。Identity Server は、ダウンロード可能なポリシーエージェントを使用してポリシーを適用する、URL ポリシーエージェントサービスを提供します。

URL ポリシーエージェントサービス

Identity Serverは初期状態で、ポリシーを適用するための URLポリシーエージェントサービスを提供します。このサービスにより、管理者はポリシーエンフォーサ、つまりポリシーエージェントにより、ポリシーの作成および管理を行えます。

ポリシーエージェント

ポリシーエージェントは企業のリソースが保存されているサーバーへのポリシー適用ポイント (Policy Enforcement Point、PEP) です。ポリシーエージェントは Identity Server とは別に Web サーバー上にインストールされており、ユーザーが保護された Web サーバー 上のリソースを要求すると、追加の認証ステップとして働きます。この認証は、リソースが実行するあらゆるユーザー認証要求に追加されます。ポリシーエージェントは Web サーバーを保護し、一方、認証プラグインはリソースを保護します。

たとえば、リモートインストールされたIdentity Serverで保護されている人事部の Web サーバーにエージェントがインストールされているとします。このエージェントにより、適切なポリシーを持っていない担当者には機密の給与情報またはその他の秘密情報は表示されません。このポリシーはIdentity Serverの管理者が定義し、Identity Serverの配備に保存され、リモート Web サーバーのコンテンツにユーザーがアクセスするのをポリシーエージェントが許可または拒否するのに使います。

最新の Sun Java System Identity Server ポリシーエージェントは Sun Microsystems Download Center からダウンロードできます。

ポリシーエージェントのインストールおよび管理についての詳細は『Sun Java System Identity Server J2EE Policy Agents Guide』または『Web Policy Agents Guide』を参照してください。

注

ポリシーの評価に特定の順序はありませんが、評価の途中であるアクションの値が「許可しない」となったときには、ポリシー設定サービスにより「拒否決定で評価を続行」属性が有効になっていないかぎり、以降のポリシーの評価は中止されます。詳細は、「ポリシー設定サービス属性」を参照してください。

ポリシーエージェントが決定を適用するのは Web URL (http://...) だけですが、 Java と C の Policy Evaluation API を使いエージェントをプログラミングすれば、ほかのリソースにもポリシーを適用可能です。

さらに、場合によってはポリシー設定サービスの「リソースコンパレータ」属性をデフォルト設定から次のように変更する必要があります。

serviceType=Name_of_LDAPService|class=com.sun.identity.policy.plugins.SuffixResourceName|wildcard=*|delimiter=,|caseSensitive=false

もしくは、LDAPResourceName などの実装により、 com.sun.identity.policy.interfaces.ResourceName を実装して、その上で「リソースコンパレータ」を適切に設定するという方法もあります。

注

「リソースコンパレータ」属性のフィールドについての説明は、「ポリシー設定サービス属性」を参照してください。

ポリシーエージェントプロセス

Web ブラウザがポリシーエージェントによって保護されたサーバー上の URL を要求すると、保護された Web リソースに対するプロセスが始まります。このサーバーにインストールされたポリシーエージェントはこの要求を傍受し、既存の認証資格情報をチェックします (セッショントークン)。

エージェントが要求を傍受し、既存のセッショントークンを検証したら、プロセスは以下のように続きます。

  1. セッショントークンが有効であれば、ユーザーのアクセスは許可または拒否される。ユーザーのトークンが無効であれば、以下の手順にあるようにユーザーを認証サービスにリダイレクトする
  2. 認証サービスは資格情報が有効かどうかを検証し、トークンを発行する
  3. ユーザーの資格情報が適切に認証されると、エージェントはIdentity Serverの内部サービスのアクセスに使う URL を定義するネーミングサービスに要求を出す
  4. ネーミングサービスはポリシーサービスのロケータを返し、エージェントはユーザーに適用されるポリシー決定を取得するためにポリシーサービスに問い合わせる
  5. アクセスされるリソースに関してのポリシー決定に基づいて、ユーザーのアクセスが許可または拒否される。ポリシー決定へのアドバイスが異なる認証レベルまたは認証メカニズムを示している場合、エージェントはすべての基準が検証されるまで要求を認証サービスにリダイレクトする

既存のセッショントークンが存在しない要求をエージェントが傍受した場合は、そのリソースが異なる認証方法で保護されているときでも、エージェントはユーザーをデフォルトのログインページにリダイレクトします。

注

ポリシーベースのリソース認証と、ユーザー認証は異なったタイプの認証です。これに関する詳細情報は「ポリシーベースのリソース管理」を参照してください。

ポリシータイプ

Identity Server を使用して設定可能なポリシーには、標準ポリシーと参照ポリシーの 2 タイプがあります。標準ポリシーは、複数のルール、サブジェクト、および条件から構成されます。参照ポリシーは、複数のルール、および組織への参照から構成されます。

標準ポリシー

Identity Server では、アクセス許可を定義するポリシーを標準ポリシーと呼びます。標準ポリシーは、複数のルール、サブジェクト、および条件から構成されます。

ルール

ルールは 1 つのリソース、1 つ以上のアクション、および 1 つの値から成ります。基本的に、ルールがポリシーを定義します。

サブジェクト

サブジェクトはポリシーが影響を与えるユーザーまたはユーザーの集合 (たとえば、グループ、または特定のロールを持つ複数のユーザー) を定義します。サブジェクトはポリシーに割り当てられます。サブジェクトの一般則は、ユーザーがポリシー中の少なくとも 1 つのサブジェクトのメンバーである場合にのみポリシーが適用される、というものです。デフォルトのサブジェクトは次のとおりです。

Identity Server ロールと LDAP ロールの比較

Identity Server ロールは Identity Server を使用して作成します。これらのロールは Identity Server が規定するオブジェクトクラスを持ちます。LDAP ロールは、 Directory Server ロール機能を使用するロール定義です。これらのロールは Directory Server のロール定義が規定するオブジェクトクラスを持ちます。すべての Identity Server ロールは Directory Server のロールとして使用できます。しかし、すべての Directory Server ロールが必ずしも Identity Server ロールというわけではありません。LDAP ロールは、ポリシー設定サービスを設定することにより、既存のディレクトリから利用できます。Identity Server ロールは、ホスティングする Identity Server ポリシーサービスを通してのみアクセスできます。Identity Server のSDKとキャッシュにアクセスするので、 Identity Server ロールのメンバーシップを評価する方が高速です。ポリシー設定サービスで LDAP ロール検索フィルタを変更して、検索範囲を絞り込みパフォーマンスを向上させることができます。

入れ子ロール

入れ子ロールはポリシー定義のサブジェクトのLDAP ロールとして正しく評価できます。

条件

条件によって、ポリシーに制約を定義できます。たとえば、給与アプリケーション用のポリシーを定義する場合、アプリケーションへのアクセスを特定の時間帯だけに制限するようにアクションに対して条件を定義することができます。また、所定の IP アドレスまたは企業のイントラネットからの要求に対してのみアクションを許可するように条件を定義することもできます。

条件は、同じドメインの別の URI で別のポリシーを設定するために、補助的に使用されます。たとえば、 http://org.example.com/hr/*jsp は org.example.net で午前 9 時〜午後 5 時だけアクセスできますが、http://org.example.com/finance/*.jsp は org.example2.net で午前 5 時〜午後 11 時にアクセスできます。これは IP 条件と時間条件を使用して実現します。またルールのリソースを http://org.example.com/hr/*.jsp に指定することで、ポリシーは http://org.example.com/hr 以下、サブディレクトリ内を含むすべての JSP に適用されるようになります。

注

参照、ルール、リソース、サブジェクト、条件、アクション、値の各用語は、policy.dtd 内の Referral、Rule、ResourceName、Subject、Condition、Attribute、Value の各要素に対応しています。

参照ポリシー

管理者は、ある組織のポリシーの定義と決定を別の組織に委任することが必要になる場合があります。または、あるリソースに対するポリシー決定を別のポリシー製品に委任することもできます。参照ポリシーは、ポリシーの作成と評価の両方に対するポリシーの委任を管理します。1 つ以上のルールと、1 つ以上の参照で構成されます。

ルール

ルールは、ポリシーの定義と評価が参照されるリソースを定義します。

参照

参照は、ポリシーの評価をどの組織に対して参照するかを定義します。デフォルトでは、2 種類の参照があります。ピア組織とサブ組織です。それぞれ、同じレベルの組織、下位レベルの組織を表します。詳細は、「ピア組織およびサブ組織のポリシーの作成」を参照してください。

注

参照先の組織では、その組織をすでに参照済みのリソース (またはサブリソース) のポリシーを定義または評価できます。ただし、この制約はルート組織には適用されません。

ポリシー DTD

作成して設定したポリシーは、Directory Server にXML形式で保存されます。Directory Server では、XMLでエンコードされたデータは 1 か所に保管されます。ポリシーはamadmin.dtd (またはコンソール) を使って定義され設定されますが、実際にはpolicy.dtd に基づくXMLとして、Directory Server に保存されます。policy.dtd は、amAdmin.dtd から抽出されたポリシー要素タグ (ポリシー作成タグを除く) を含んでいます。したがって、ポリシーサービスが Directory Server からポリシーをロードすると、policy.dtd に基づいてXMLをパースします。ポリシーをコマンド行から作成するときには、amAdmin.dtd のみが使われます。この節では、policy.dtd の構造について説明します。policy.dtd は次の場所にあります。

Policy 要素

Policyはアクセス権、つまりポリシーのルールとだれにどのルールを適用するか、またはサブジェクトを定義するルート要素です。また、ポリシーが参照 (委任) ポリシーかどうか、なんらかの制限 (または条件) があるかどうかも定義します。また Rule、Conditions、Subjects、あるいは Referrals といったサブ要素を 1 つ以上含む場合があります。必須の XML 属性は name で、これはポリシーの名前を指定します。referralPolicy 属性は、ポリシーが参照ポリシーであるかどうかを識別します。指定がなければ標準ポリシーとして扱われます。オプションの XML 属性には name と description があります。

注

ポリシーに referral タグを付けると、サブジェクトと条件はポリシー評価の際、無視されます。逆に、ポリシーに normal タグを付けると、Referrals は無視されます。

Rule 要素

Rule 要素はポリシーの細目を定義し、ServiceName、ResourceName、およびAttributeValuePair の 3 つのサブ要素を持ちます。この要素は、リソース名やそこで実行されるアクションだけではなく、ポリシーが作成されたサービスやアプリケーションのタイプを定義します。アクションを持たないルールも定義できます。たとえば、参照ポリシールールにはアクションはありません。

注

ResourceName 要素を含まないポリシーの定義も可能です。

ServiceName 要素

ServiceName 要素は、ポリシーを適用するサービスの名前を定義します。この要素は、サービスのタイプを表しています。ほかの要素は含みません。値は、そのサービスの XML ファイルで (sms.dtd に基づいて) 定義されているとおりです。ServiceName 要素の XML サービス属性はサービスの名前 (値は文字列) です。

ResourceName 要素

ResourceName 要素は対象となるオブジェクトを定義します。ポリシーは、このオブジェクトを保護するように設定されています。ほかの要素は含みません。ResourceName 要素の XML サービス属性は、オブジェクトの名前です。ResourceName の例としては、Web サーバー上の http://www.sunone.com:8080/images、またはディレクトリサーバー上の ldap://sunone.com:389/dc=example,dc=com があります。リソースの具体的な例としては、salary://uid=jsmith,ou=people,dc=example,dc=com で、対象となるオブジェクトは John Smith の給与情報です。

AttributeValuePair 要素

AttributeValuePair 要素はアクションとその値を定義します。この要素は Subject 要素、Referral 要素、および Condition 要素のサブ要素として扱われます。これは Attribute と Value 要素を含み、XML サービス属性は含んでいません。

Attribute 要素

Attribute 要素はアクションの名前を定義します。アクションとは処理、つまりリソースに対して行われるイベントのことです。POST や GET は Web サーバーリソースに対して行われるアクションであり、READ や SEARCH はディレクトリサーバーリソースに対して行われるアクションです。Attribute 要素は Value 要素とペアにする必要があります。Attribute 要素自体は、ほかの要素を含みません。Attribute 要素に対する XML サービス属性は、アクションの名前です。

Value 要素

Value 要素はアクションの値を定義します。Allow (許可する)/Deny (許可しない)、Yes (はい) /No (いいえ) はアクションの値の例です。ほかのアクションの値は、ブール型、数値型、または文字列型が可能です。値は、そのサービスの XML ファイルの中で (sms.dtd に基づいて) 定義されています。Value 要素はほかの要素を含まず、また XML サービス属性も含みません。

警告

許可しないルールは許可するルールより優先度が高くなります。たとえば、あるポリシーはアクセスを拒否し、別のポリシーが許可すると、(両方のポリシーのほかの条件がすべて一致する場合) 結果は拒否となります。許可しないポリシーを使用すると、ポリシー間で潜在的に衝突が生じるおそれがあるため、十分に注意して拒否ポリシーを使用することをお勧めします。明示的な許可しないルールを使用すると、さまざまなサブジェクト (ロールやグループメンバーシップなど) を通じてユーザーに割り当てられたポリシーが、アクセスを拒否する可能性があります。通常は、ポリシー定義プロセスでは、許可するルールのみを使うべきです。デフォルトで「許可しない」というのは、ほかに適用するポリシーがない場合に使用します。

Subjects 要素

Subjects サブ要素はポリシーが適用されるオブジェクトの集合を特定します。この包括的な集合はグループのメンバーシップ、ロールの所有権、または個別ユーザーを基に選択します。この要素は、Subject というサブ要素を持ちます。定義できる XML 属性は以下のとおりです。

name : 集合の名前を定義する

description : サブジェクトの説明を定義する

includeType : 現在使われてない

Subject 要素

Subjectサブ要素はポリシーを適用するオブジェクトの集合を特定します。この集合は、Subjects 要素が定義する集合をさらに絞り込んだものです。メンバーシップは、ロール、グループメンバーシップ、または単なる個別ユーザーのリストに基づきます。この要素は、 AttributeValuePair 要素というサブ要素を含みます。必須の XML 属性は type で、特定の定義済みサブジェクトを持つ、オブジェクトの一般的な集合を特定します。ほかの XLM 属性には、集合の名前を定義する name、サブジェクトのメンバーでないユーザーに対してポリシーを適用するかどうかに関して、集合が定義されたとおりになっているかどうかを定義するincludeTypeがあります。

注

複数のサブジェクトを定義した場合、ポリシーを適用するためには少なくとも 1 つのサブジェクトをユーザーに適用しなければなりません。includeType を false にしてサブジェクトを定義するときは、ユーザーがそのサブジェクトのメンバーではないことが必要です。

Referrals 要素

Referrals サブ要素はポリシー参照の集合を特定します。この要素は、Referral というサブ要素を持ちます。ともに定義できる XML 属性は、集合の名前を定義する name、説明を含む description があります。

Referral 要素

Referral サブ要素は個別のポリシー参照を特定します。それは、サブ要素として AttributeValuePair 要素を持ちます。必須の XML 属性は type で、特定の定義済み参照を持つ、割り当ての一般的な集合を特定します。また、集合の名前を定義する name 属性を持つこともできます。

Conditions 要素

Conditions サブ要素はポリシーの制限 (時間範囲、認証レベル、その他) の集合を特定します。この要素は複数の Condition サブ要素を含んでいなければなりません。ともに定義できる XML 属性には、集合の名前を定義する name、説明を含む description があります。

注

conditions 要素は、ポリシーの中ではオプションの要素です。

Condition 要素

Condition サブ要素は特定のポリシーの制限 (時間範囲、認証レベルなど) を特定します。この要素は、サブ要素として AttributeValuePair 要素を持ちます。必須の XML 属性は type で、特定の定義済みサブジェクトを持つ、オブジェクトの一般的な集合を特定します。また、集合の名前を定義する name 属性を持つこともできます。

ポリシーサービスの追加

デフォルトで、Identity Server はURL ポリシーエージェントサービス (iPlanetAMWebAgentService) を提供します。このサービスは、XML ファイル形式で定義され、次のディレクトリにあります。

Identity Sever にさらにポリシーサービスを追加することもできます。ポリシーサービスを作成したら、amadmin コマンド行ユーティリティを使って、これを Identity Server に追加します。

新しいポリシーサービスを追加する

  1. 新しいポリシーサービスをsms.dtd に基づいて XML ファイルで作成します。新しいポリシーサービスファイルの雛型にできるポリシーサービス XML ファイルが 2 つ、Identity Server から提供されます。

    2. amWebAgent.xml はデフォルトの URL ポリシーエージェントサービスのための XML ファイルです。これは/etc/opt/SUNWam/config/xml/ にあります。

    SampleWebService.xml はポリシーサービスファイルのサンプルで、/etc/opt/SUNWam/samples/policy にあります。

  2. 新しいポリシーサービスをロードするディレクトリに XML ファイルを保存します。次に例を示します。

    3. /etc/opt/SUNWam/config/xml/newPolicyService.xml

  3. 新しいポリシーサービスを amadmin コマンド行ユーティリティを使ってロードします。次に例を示します。

    4. IdentityServer_base/SUNWam/bin/amadmin

       --runasdn "uid=amAdmin,ou=People,default_org,root_suffix"

       --password パスワード

       --schema etc/opt/SUNWam/config/xml/newPolicyService.xml

  4. 新しいポリシーサービスをロードしたあと、Identity Server コンソールから作業を行うか、または、amadmin で新しいポリシーをロードすることにより、ポリシー定義のルールを定義できます。

ポリシーの作成

Policy API と Identity Server コンソールを使用してポリシーを作成、変更、および削除でき、amadmin コマンド行ツールを使用してポリシーを作成および削除できます。この節では、amadmin コマンド行ユーティリティとIdentitiy Server コンソールを使用してポリシーを作成することを中心に説明します。Policy API についての詳細は『Identity Server Developer's Guide』を参照してください。

通常ポリシーは XML ファイルで作成し、amadmin コマンド行ユーティリティを使って Identity Server に追加し、Identity Server のコンソールを使って管理します (ただし、ポリシーをコンソールで作成することもできる)。これは、ポリシーがamadminを使って直接変更できないからです。ポリシーを修正するには、そのポリシーを Identity Server から削除し、修正したポリシーを amadmin を使用して追加します。

一般に、ポリシーは組織ツリー全体で使用するために、組織またはサブ組織レベルで作成します。

amadmin でのポリシーの作成

  1. ポリシーの XML ファイルを policy.dtd に基づいて作成します。このファイルは次のディレクトリにあります。

    2. IdentityServer_base/SUNWam/dtd

  2. ポリシーの XML ファイルを作成したら、次のコマンドを使用してロードできます。

    3. IdentityServer_base/SUNWam/bin/amadmin

複数のポリシーを同時に追加するには、各 XML ファイルにポリシーを 1 つずつ置くのではなく、1 つの XML ファイルにすべてのポリシーを置きます。複数の XML ファイルでポリシーを次々とロードすると、内部ポリシーインデックスが破損したり、ポリシーの評価に参加できないポリシーが生じたりするおそれがあります。

ポリシーを amadmin で作成するときは、認証スキーム条件を作成中に組織に認証モジュールを登録することの確認、組織、LDAP グループ、LDAP ロール、および LDAP ユーザーのサブジェクトを作成中に、対応する LDAP オブジェクト (組織、グループ、ロール、およびユーザー) が存在することを確認、IdentityServerRoles サブジェクトを作成中に、 Identity Server ロールが存在することを確認、そしてサブ組織またはピア組織の参照を作成中に、関連がある組織が存在することを確認すること、以上確認を行ってください。

SubOrgReferral、PeerOrgReferral、Organization サブジェクト、IdentityServerRoles サブジェクト、LDAPGroups サブジェクト、LDAPRoles サブジェクト、および LDAPUsers サブジェクトの Value 要素のテキストには、完全な DN を指定する必要があります。

Identity Server コンソールでのポリシーの作成

  1. アイデンティティ管理インタフェースに移動します。
  2. ポリシーを作成する組織を選択します。

    3. 組織のポリシー管理ウィンドウの位置が正しいことを確認します。

  3. 「表示」メニューから「ポリシー」を選択します。

    4. デフォルトでは、組織は「表示」メニューに表示されます。サブ組織がある場合は、すべてその下に表示されます。サブ組織のポリシーを作成する場合は、サブ組織を選択して、「表示」メニューから「ポリシー」を選択します。

  4. ナビゲーションフレームで「新規」をクリックします。「ポリシーの作成」ウィンドウを開きます。
  5. 作成するポリシーのタイプを、標準ポリシーまたは参照ポリシーのどちらかから選択します。

    6. サブ組織を参照する参照ポリシーが存在しない場合、そのサブ組織のポリシーを作成することはできません。

    この時点では、標準または参照ポリシーのフィールドすべてを定義する必要はありません。ポリシー作成後、ルール、サブジェクト、参照などを追加できます。

  6. ポリシーの名前を入力して、「保存」をクリックします。
  7. デフォルトでは、「一般」表示となっています。

    8. 「一般」にはポリシー名が表示され、作成するポリシーの説明を入力できます。

  8. 「保存」をクリックして、ポリシーの設定を完了します。

ピア組織およびサブ組織のポリシーの作成

ピア組織またはサブ組織のポリシーを作成するには、まず親組織または別のピア組織で参照ポリシーを作成する必要があります。サブ組織でポリシー設定サービスを登録し、テンプレートを作成することも必要です。参照ポリシーのルールの定義には、サブ組織が管理するリソースプレフィックスを含める必要があります。親組織または別のピア組織で参照ポリシーを作成すれば、サブ組織またはピア組織で標準ポリシーを作成できます。

この例では、o=isp が親組織、o=example.com はサブ組織で http://www.example.com のリソースおよびサブリソースを管理します。

サブ組織のポリシーを作成する

  1. o=isp で参照ポリシーを作成します。参照ポリシーについては、「参照ポリシーの修正」の手順を参照してください。

    2. 参照ポリシーは、http://www.example.com をリソースとしてルールに定義し、参照内で example.com を SubOrgReferral の値として持つ必要があります。

  2. 「組織」表示で example.com というサブ組織に移動します。
  3. ポリシー設定サービスが example.com というサブ組織レベルに登録されていることを確認します。詳細は、「ポリシー設定サービスの追加」を参照してください。
  4. これで isp によってリソースが example.com の管理に委ねられたので、http://www.example.com というリソース、または http://www.example.com から始まる任意のリソースに対して標準ポリシーを作成できます。

    5. 標準ポリシーの作成については、「標準ポリシーの修正」の手順を参照してください。

    example.com で管理する別のリソースのポリシーを定義するには、追加の参照ポリシーを o=isp に作成する必要があります。

ポリシーを管理する

標準または参照ポリシーを作成し、Identity Server に追加したあとは、ポリシーの管理は、Identity Server のコンソールを使用して、ルール、サブジェクト、条件と参照を変更することにより行えます。

標準ポリシーの修正

アイデンティティ管理インタフェースでは、アクセス許可を定義するポリシーを作成できます。このようなポリシーを標準ポリシーと呼びます。標準ポリシーは、複数のルール、サブジェクト、および条件から構成できます。ここでは、標準ポリシー作成時に指定できるデフォルトのフィールドについて説明します。

ルールを変更する
  1. アイデンティティ管理インタフェースで、「表示」メニューから「ポリシー」を選択します。

    2. その組織用に作成されたポリシーが表示されます。

  2. 修正したいポリシーを選択し、「プロパティ」の矢印をクリックします。データフレームでポリシーの「編集」ウィンドウが開きます。

    3. デフォルトでは、「一般」表示となっています。「一般」表示内の属性については、「ポリシーの作成」で説明しています。

  3. 「表示」メニューから「ルール」を選び「新規」をクリックします。

    4. 複数のポリシーサービスが存在する場合は、データ区画に一覧表示されます。ポリシーを作成したいサービスを選択して、「次へ」をクリックします。「新規ルール」ウィンドウが表示されます。

  4. 「ルール」フィールドに、ポリシーのリソース、アクション、およびアクション値を定義します。フィールドは次のとおりです。

    5. 「タイプ」: ポリシーを作成するサービスが表示されます。デフォルトは URL ポリシーエージェントです。

    「ルール名」: ルールの名前を入力します。

    「リソース名」: リソースの名前を入力します。次に例を示します。

    http://www.example.com

    現在、ポリシーエージェントでサポートされているリソースは http:// と https:// だけです。また、ホスト名の代わりに IP アドレスを使用することはできません。

    リソース名、ポート番号、およびプロトコルにはワイルドカードを使用できます。次に例を示します。

    http*://*:*/*.html

    URL ポリシーエージェントサービスでは、ポート番号が入力されていない場合のデフォルトのポート番号は、http:// では 80、https:// では 443 となります。

    リソースを http://host*:* として定義して、特定のマシンにインストールされたすべてのサーバーに対してリソースの管理を許可できます。また、次のリソースを定義して、組織のすべてのサービスに対する特定の組織権限を管理者に与えることができます。

    http://*.subdomain.domain.topleveldomain

    「選択、アクション」: URL ポリシーエージェントサービスでは、デフォルトとして次のアクションの両方または一方を選択できます。

    • GET
    • POST

      • 「値」: URL ポリシーエージェントサービスでは、次のアクション値の 1 つを選択できます。

    • 許可 - ルールに定義されたリソースに一致するリソースへのアクセスを許可
    • 拒否 - ルールに定義されたリソースに一致するリソースへのアクセスを拒否

      • ポリシーでは、拒否ルールが許可ルールよりも優先されます。たとえばあるリソースに 2 つのポリシーがあり、1 つはアクセス拒否でもう 1 つはアクセス許可の場合、その結果はアクセスの拒否になります (両方のポリシーの条件が一致する場合)。拒否ポリシーを使用すると、ポリシー間で潜在的に衝突が生じるおそれがあるため、十分に注意して拒否ポリシーを使用することをお勧めします。通常は、ポリシー定義プロセスでは許可ルールだけを使用し、拒否の場合を実現するのに適用するポリシーがない場合にデフォルトの拒否を使用してください。

      拒否ルールを明示的に使用すると、1 つ以上のポリシーでアクセスが許可される場合でも、異なるサブジェクト (ロールやグループのメンバーシップ) を通じてユーザーに割り当てられたポリシーによって、リソースへのアクセスを拒否されるおそれがあります。たとえば、1 つのリソースについて、Employee ロールに適用される拒否ポリシーと、Manager ロールに適用される許可ポリシーがあるとします。この場合、Employee ロールと Manager ロールの両方を割り当てられているユーザーは、ポリシーの判断によってアクセスを拒否されます。

      このような問題を解決する 1 つの方法は、条件プラグインを使ってポリシーを設計することです。上記の例では、Employee ロールに認証されたユーザーには拒否ポリシーを適用し、Manager ロールに認証されたユーザーには許可ポリシーを適用するという "ロール条件" を利用することで、2 つのポリシーを区別できます。Manager ロールにはより高い認証レベルが与えられることから、認証レベル条件を使用する方法もあります。詳細は、「「条件」を追加または変更する」を参照してください。

      注

      アクションにリソース定義が不要となるようサービスが定義されている場合、リソースフィールドは表示されません。リソースを要求するアクションと要求しないアクションの両方がサービスに含まれている場合、選択肢が表示され、リソースを要求しないアクションを伴うルールまたはリソースを要求するアクションを伴うルールのどちらかを選択できます。

  5. 「終了」をクリックしてルールを保存します。これは、設定をメモリに保存するだけです。手順 7 に従ってプロセスを完了します。
  6. 手順 1 から 5 を繰り返して、追加のルールを作成します。
  7. ポリシーに対して作成されたすべてのルールが、「ルール」の表に表示されます。「保存」をクリックしてポリシーにルールを追加します。

    8. ポリシーからルールを削除するには、ルールを選択して「削除」をクリックします。

    ルール名の横にある「編集」リンクをクリックすれば、ルールの定義を編集できます。

サブジェクトを変更する
  1. ポリシーのサブジェクトを定義するには、「表示」メニューから「サブジェクト」を選択し「新規」をクリックします。
  2. デフォルトのサブジェクトタイプを次の中から選択します。

    3. 「認証済みユーザー」: このサブジェクトタイプは、有効な SSOToken を持つユーザーすべてがこのサブジェクトのメンバーであることを示します。

    「Identity Server ロール」: このサブジェクトタイプは、Identity Server ロールのメンバーすべてが、このサブジェクトのメンバーであることを示します。Identity Server ロールは、Identity Server を使用して作成します。Identity Server ロールは、Identity Server が規定するオブジェクトクラスを持ちます。Identity Server のロールには、ホスティングする Identity Server のポリシーサービス経由でのみアクセスできます。

    「LDAP グループ」: このサブジェクトタイプは、LDAP グループのメンバーすべてがこのサブジェクトのメンバーであることを示します。

    「LDAP ロール」: このサブジェクトタイプは、LDAP ロールのメンバーすべてがこのサブジェクトのメンバーであることを示します。LDAP ロールは、Directory Server ロール機能を使用するロール定義です。LDAP ロールは、Directory Server ロール定義が規定するオブジェクトクラスを持ちます。ポリシー設定サービスで LDAP ロール検索フィルタを変更して、検索範囲を絞り込みパフォーマンスを向上させることができます。

    「LDAP ユーザー」: このサブジェクトタイプは、LDAP ユーザーすべてがこのサブジェクトのメンバーであることを示します。

    「組織」: このサブジェクトタイプは、組織のメンバーすべてがサブジェクトのメンバーであることを示します。

    「Web サービスクライアント」: このサブジェクトタイプは、SSOToken に含まれる主体の DN がこのサブジェクトの選択された値のどれかに一致する場合、SSOToken が特定する Web サービスクライアント (WSC) がこのサブジェクトのメンバーであることを示します。有効な値は、信頼できる WSC の証明書に対応する、ローカル JKS 鍵ストア内の信頼できる証明書の DN です。このサブジェクトは、Liberty Web サービスフレームワークに依存し、Liberty サービスプロバイダが WSC を承認するためにのみ使用する必要があります。

    このサブジェクトをポリシーに追加する前に、鍵ストアが作成されていることを確認します。鍵ストアの設定に関する説明は、次の場所にあります。

    IdentityServer_base/SUNWam/samples/saml/xmlsig/keytool.html

    「次へ」をクリックして先に進みます。

  3. サブジェクトの名前を入力します。
  4. 「排他的」フィールドを選択または選択解除します。

    5. このフィールドが選択されていないと (デフォルト)、ポリシーは、サブジェクトのメンバーであるアイデンティティに適用されます。このフィールドが選択されていると、ポリシーは、サブジェクトのメンバーではないアイデンティティに適用されます。

    ポリシーに複数のサブジェクトが存在する場合は、指定されたアイデンティティにポリシーが適用されることが少なくとも 1 つのサブジェクトで示されている場合に、そのポリシーがアイデンティティに適用されます。

  5. 検索を実行して、サブジェクトに追加するアイデンティティを表示します。この手順は、「認証済みユーザー」サブジェクトには適用できません。

    6. デフォルト (*) の検索パターンでは、該当するすべてのエントリが表示されます。

  6. サブジェクトに追加する個々のアイデンティティを選択するか、または「すべて追加」を選択して一度にすべてのアイデンティティを追加します。「追加」をクリックしてアイデンティティを「「選択」リストボックス」に移動します。
  7. 「終了」をクリックします。
  8. サブジェクトの名前、タイプ、および排他の状況が、「サブジェクト」の表に表示されます。「保存」をクリックします。

    9. ポリシーからサブジェクトを削除するには、サブジェクトを選択して「削除」をクリックし、「保存」をクリックします。

    サブジェクト名の横にある「編集」リンクをクリックすれば、サブジェクトの定義を編集できます。

「条件」を追加または変更する
  1. 「表示」メニューから「条件」を選択します。「新規」をクリックして新しい条件を追加するか、または「編集」リンクをクリックして既存の条件を編集します。
  2. デフォルトの条件を次の中から選択します。
    • 認証レベル
    • 認証方式
    • IP アドレス
    • LE 認証レベル
    • セッション
    • 時間

      • 「認証レベル」の場合、ユーザーの認証レベルが、条件に設定された認証レベル以上である場合に、ポリシーが適用されます。「LE 認証レベル」の場合、ユーザーの認証レベルが、条件に設定された認証レベル以下である場合に、ポリシーが適用されます。

  3. 「次へ」をクリックします。
  4. 指定した条件に対する値を定義します。フィールドは次のとおりです。

    5. 「名前」: 条件の名前を入力します。

    認証レベル

    「認証レベル」: 認証の信頼レベルを指定します。利用可能な認証レベルの一覧は、認証レベルと認証モジュールの表に表示されます。

    認証方式

    「認証方式」: プルダウンメニューから条件の認証方式を選択します。これらの認証方式は、組織認証モジュールのコア認証サービステンプレートから取得されます。

    IP アドレス

    「IP アドレス 開始/終了」: IP アドレスの範囲を指定します。

    「DNS 名」: DNS 名を指定します。このフィールドには、完全修飾ホスト名または次の形式の文字列を指定できます。

    domainname

    *.domainname

    時間

    「日付 開始/終了」: 日付の範囲を指定します。

    「時間」: 1 日での時間の範囲を指定します。

    「日」: 日数を指定します。

    「タイムゾーン」: タイムゾーンを標準またはカスタムで指定します。カスタムのタイムゾーンとして指定できるのは、Java で認識されるタイムゾーン ID だけです (PST など)。値を指定しない場合は、デフォルト値は Identity Server JVM に設定されたタイムゾーンになります。

    セッション

    「最大セッション時間」: ポリシーを適用する間の最大ユーザーセッション時間を指定します。

    「セッションを終了」: 選択すると、「最大セッション時間」フィールドで定義した許可される最大値をセッション時間が超えた場合に、ユーザーセッションを終了します。

  5. 条件を定義したら、「終了」をクリックします。

    6. ポリシーに対して作成されたすべての条件が、「条件」の表に表示されます。

  6. 「保存」をクリックします。

    7. ポリシーから条件を削除するには、条件を選択して「削除」をクリックします。

    条件名の横にある「編集」リンクをクリックすれば、条件の定義を編集できます。

参照ポリシーの修正

アイデンティティ管理インタフェースでは、ある組織のポリシーの定義や判断を、別の組織に委任できます。また、あるリソースに対するポリシーの判断を、別のポリシー製品に委任することもできます。参照ポリシーは、ポリシーの作成と評価の両方に対するポリシーの委任を管理します。参照ポリシーは、ルールおよび参照自体から構成されます。

ルールを変更する
  1. 「表示」メニューから「ルール」を選択します。「新規」をクリックして新しいルールを追加するか、または「編集」リンクをクリックして既存のルールを編集します。
  2. 「サービスタイプ」を選択します。新しいルールを作成している場合は、「次へ」をクリックします。
  3. 「ルール」フィールドにリソースを定義します。フィールドは次のとおりです。

    4. 「タイプ」: 作成するポリシーのポリシーサービスが表示されます。

    「ルール名」: ルールの名前を入力します。

    「リソース名」: リソースの名前を入力します。次に例を示します。

    http://www.sunone.com

    現在、ポリシーエージェントでサポートされているリソースは http:// と https:// だけです。また、ホスト名の代わりに IP アドレスを使用することはできません。

    リソース名、ポート番号、およびプロトコルにはワイルドカードを使用できます。

    URL ポリシーエージェントサービスでは、ポート番号が入力されていない場合のデフォルトのポート番号は、http:// では 80、https:// では 443 となります。

    リソースを http://host*:* として定義して、特定のマシンにインストールされたすべてのサーバーに対してリソースの管理を許可できます。また、次のリソースを定義して、組織のすべてのサービスに対する特定の組織権限を管理者に与えることができます。

    http://*.subdomain.domain.topleveldomain

  4. 「終了」をクリックします。
  5. 手順 1 から 4 を繰り返して、追加のルールを作成します。

    6. ポリシーに対して作成されたすべてのルールが、「ルール」の表に表示されます。

  6. 「保存」をクリックします。

    7. ポリシーからルールを削除するには、ルールを選択して「削除」をクリックします。

    ルール名の横にある「編集」リンクをクリックすれば、ルールの定義を編集できます。

参照を追加する
  1. 「表示」メニューから「参照」を選択します。「新規」をクリックして新しい参照を追加するか、または「編集」リンクをクリックして既存の参照を編集します。
  2. 「ルール」フィールドにリソースを定義します。フィールドは次のとおりです。

    3. 「参照」: 現在の参照タイプが表示されます。

    「名前」: 参照の名前を入力します。

    「含む」: 「値」フィールドに表示する組織名を絞り込むためのフィルタを指定します。デフォルトでは、すべての組織名が表示されます。

    「値」: 参照の組織名を選択します。

  3. 「了解」をクリックし、「保存」をクリックします。

    4. ポリシーから参照を削除するには、参照を選択して「削除」をクリックします。

    参照名の横にある「編集」リンクをクリックすれば、参照の定義を編集できます。

ポリシー設定サービス

各組織のポリシーに関連する属性の設定をIdentity Serverコンソールから行うにはポリシー設定サービスを使用します。Identity Server 認証サービスで使用するリソース名の実装およびDirectory Server データストアを定義することもできます。

サブジェクト評価のキャッシュ

ポリシー評価のパフォーマンスを上げるため、ポリシー設定サービスの「サブオブジェクト結果の有効時間」属性で定義されるとおり、サブジェクト評価を何分間かキャッシュします。これらのキャッシュされたポリシー決定は「サブオブジェクト結果の有効時間」属性で定義された時間が経つまで参照されます。この時間が経過したあとは、次にポリシーが評価されると、その決定はユーザーの状態変化 (該当する場合。ユーザーがグループから削除されるなど) を反映したものになります。

amldapuser の定義

amldapuser はインストール時に作成されたユーザーで、LADP およびメンバーシップ認証の間、Directory Server のバインドと検索に使われます。また、これはポリシー設定サービスでも使用されます。LADP、メンバーシップ、またはポリシー設定サービスが組織に登録されると、このユーザーの (インストール時に設定された) パスワードを入力しなければなりません。詳細は、『Sun Java System Identity Server Migration Guide』を参照してください。

ポリシー設定サービスの追加

ポリシー設定サービスの追加はサービスのタイプの追加と同じで、アイデンティティ管理インタフェース内で行います。デフォルトでは、ポリシー設定サービスは自動的に最上位レベルの組織に追加されます。作成するポリシーサービスは、すべての組織に追加する必要があります。ポリシー設定サービスを追加するときは、LDAP バインドパスワードをテンプレートに入力する必要があります。

ポリシー設定サービスを追加する

  1. アイデンティティ管理インタフェースに移動します。

    2. コンソールが開くときのデフォルトのインタフェースはアイデンティティ管理です。

  2. ポリシーを作成する組織を選択します。

    3. 最上位レベル管理者としてログインした場合は、アイデンティティ管理モジュールがすべての設定済み組織が表示される最上位レベルの組織であることを確認します。デフォルトの最上位レベル組織は、インストール時に定義されます。

  3. 「表示」メニューから「サービス」を選択します。

    4. その組織にすでにサービスが登録されている場合は、ナビゲーションフレームにそのサービスが表示されます。

  4. ナビゲーションフレームで「追加」をクリックします。

    5. この組織にまだ登録されていないサービスのリストが、データフレームに表示されます。

  5. データフレームに表示された「サービスを追加」ウィンドウから、「ポリシー設定」を選択して「了解」をクリックします。

    6. ポリシー設定サービスがナビゲーションフレームのサービス一覧に追加されます。

  6. 「プロパティ」の矢印をクリックして、ポリシーサービスを設定します。
    1. ポリシーテンプレートが設定されていない場合、新しく登録されたポリシーサービス用にサービステンプレートを作成する必要があります。
    2. ポリシーサービスを設定するには、「はい」をクリックします。
    3. ポリシー設定属性を修正します。これらの属性については、「ポリシー設定サービス属性」を参照してください。
  7. 「保存」をクリックします。

    8. これで、選択した組織にポリシー設定サービスが追加されます。

    注

    サブ組織は、その親組織とは別にポリシーサービスを登録する必要があります。それは、サブ組織 o=suborg,dc=sun,dc=com は親の dc=sun,dc=com からポリシー設定サービスを継承しないためです。

ポリシーベースのリソース管理

組織によっては高度な認証シナリオが必要です。この場合、ユーザー認証は、アクセスしようとするリソースごとに 特定のモジュールで行われます。ポリシーベースのリソース管理は、Identity Server の機能であり、そこではユーザーは Web リソースにアクセスするのにデフォルトの認証モジュールを経る必要はありません。

制限

ポリシーベースのリソース管理には次のような制限があります。

  1. リソースに適用されるポリシーはすべて同じ認証方式か同じ認証レベルを持たなければなりません。たとえば、abc.html がLDAP 認証モジュールのポリシーで定義されていると、証明書に基づく認証モジュールのポリシーでは定義できません。
  2. このポリシーについて定義できる条件はレベルと方式だけです。
  3. この機能は、異なる DNS ドメイン間では働きません。

ポリシーベースのリソース管理の設定

Identity Serverとポリシーエージェントがインストールされたら、ポリシーベースのリソース管理を設定できます。そのためには、Identity Serverが Gateway サーブレットを指す必要があります。

  1. AMAgent.propertiesを開きます。

    2. AMAgent.properties は Solaris 環境では /etc/opt/SUNWam/agents/config/ にあります。

  2. 次の行をコメントアウトします。

    3. #com.sun.am.policy.am.loginURL = http://identity_server_host.domain_name:port/amserver/UI/Login.

  3. ファイルに次の行を追加します。

    4. com.sun.am.policy.am.loginURL = http://identity_server_host.domain_name:port/amserver/gateway.

  4. サーバーを再起動します。



前へ      目次      索引      次へ     

Copyright 2004 Sun Microsystems, Inc. All rights reserved.