test

Sun Java System Access Manager 7 2005Q4 管理ガイド

第 8 章 ポリシーの管理

この章では、Sun Java™ System Access Manager のポリシー管理機能について説明します。Access Manager のポリシー管理機能では、最上位レベル管理者または最上位レベルポリシー管理者が、すべてのレルムで使用できる特定サービスのポリシーの表示、作成、削除、修正を行うことができるようになります。レルムまたはサブレルムの管理者あるいはポリシー管理者が、レルムレベルでポリシーを表示、作成、削除、修正することもできます。

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

概要

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

注 –

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

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

ポリシー管理機能

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

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

Access Manager をインストールするときに、HTTP URL を保護するポリシーを定義するための URL ポリシーエージェントサービスが実装されます。このサービスにより、管理者はポリシーエンフォーサ、つまりポリシーエージェントにより、ポリシーの作成および管理を行えます。

ポリシーエージェント

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

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

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

ポリシーエージェントのインストールおよび管理の詳細については、『Sun Java System Access Manager Policy Agent 2.2 User’s Guide』を参照してください。

注 –

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

Access Manager ポリシーエージェントが決定を適用するのは Web URL (http://... 、または https//...) だけですが、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. ユーザーの資格が適切に認証されると、エージェントは Access Manager の内部サービスの接続に使う URL を定義するネーミングサービスに要求を出します。

  3. ポリシーを適用しないリソースリストがエージェントに設定されている場合、リソースがそのリストに一致する場合には、アクセスが許可されます。

  4. ネーミングサービスはポリシーサービス、セッションサービス、およびログサービスのロケータを返します。

  5. エージェントはユーザーに適用されるポリシー決定を取得するためにポリシーサービスに要求を送信します。

  6. アクセスされるリソースに関してのポリシー決定に基づいて、ユーザーのアクセスが許可または拒否されます。ポリシー決定へのアドバイスが異なる認証レベルまたは認証メカニズムを示している場合、エージェントはすべての基準が検証されるまで要求を認証サービスにリダイレクトします。

ポリシータイプ

Access Manager を使用して設定できるポリシーは、次の 2 種類です。

標準ポリシー

Access Manager では、アクセス権を定義するポリシーを標準ポリシーと呼びます。標準ポリシーは、ルール、対象、条件、および応答プロバイダから構成されます。

ルール

ルールは 1 つのリソース、1 つ以上のアクション、および 1 つの値からなります。各アクションには、1 つ以上の値を設定できます。

注 –

一部のサービスに対しては、リソースなしでアクションを定義することも可能です。

対象

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

AM アイデンティティー対象

レルムの「対象」タブで作成して管理しているアイデンティティーを対象の値として追加できます。

Access Manager ロール

この対象には、任意の LDAP ロールを値として追加できます。LDAP ロールは、Directory Server ロール機能を使用するロール定義です。LDAP ロールは、Directory Server ロール定義が規定するオブジェクトクラスを持ちます。ポリシー設定サービスで LDAP ロール検索フィルタを変更して、検索範囲を絞り込みパフォーマンスを向上させることができます。

認証済みユーザー

有効な SSOToken を持つ任意のユーザーがこの対象のメンバーです。すべての認証済みユーザーは、ポリシーが定義されている組織とは別の組織に認証しても、この対象のメンバーになります。リソース所有者が、別の組織のユーザー用に管理されているリソースにアクセスできるようにする場合は、これが便利です。

LDAP グループ

ある LDAP グループの任意のメンバーをこの対象の値として追加できます。

LDAP ロール

この対象には、任意の LDAP ロールを値として追加できます。LDAP ロールは、Directory Server ロール機能を使用するロール定義です。LDAP ロールは、Directory Server ロール定義が規定するオブジェクトクラスを持ちます。ポリシー設定サービスで LDAP ロール検索フィルタを変更して、検索範囲を絞り込みパフォーマンスを向上させることができます。

LDAP ユーザー

この対象には、任意の LDAP ユーザーを値として追加できます。

組織

ある組織の任意のメンバーがこの対象のメンバーです。

Web サービスクライアント

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

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

AccessManager-base /SUNWam/samples/saml/xmlsig/keytool.html

Access Manager ロールと LDAP ロールの比較

Access Manager ロールは Access Manager を使用して作成します。これらのロールは Access Manager が規定するオブジェクトクラスを持ちます。LDAP ロールは、Directory Server ロール機能を使用するロール定義です。LDAP ロールは、Directory Server ロール定義が規定するオブジェクトクラスを持ちます。すべての Access Manager ロールは Directory Server のロールとして使用できます。しかし、すべての Directory Server ロールが必ずしも Access Manager ロールというわけではありません。LDAP ロールは、「ポリシー設定サービス」を設定することにより、既存のディレクトリから利用できます。Access Manager のロールには、ホスティングする Access Manager のポリシーサービス経由でのみアクセスできます。ポリシー設定サービスで 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 の各要素に対応しています。

追加できるデフォルトの条件は、次のとおりです。

認証レベル

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

この属性は、認証の信頼レベルを示しています。

認証レベルの条件を使用して、そのレルムに登録された認証モジュールレベル以外のレベルを指定できます。これは、別のレルムから認証を受けたユーザーにポリシーを適用する場合に役立ちます。

「LE 認証レベル」の場合、ユーザーの認証レベルが条件に設定された認証レベル以下である場合にポリシーが適用されます。認証レベルの条件を使用して、そのレルムに登録された認証モジュールレベル以外のレベルを指定できます。これは、別のレルムから認証を受けたユーザーにポリシーを適用する場合に役立ちます。

認証方式

プルダウンメニューから条件の認証方式を選択します。これらの認証方式は、レルムのコア認証サービスで定義されている認証モジュールです。

IP アドレス

IP アドレスの範囲に基づいて条件を設定します。定義できるフィールドは、次のとおりです。

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

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

    domainname

    *.domainname

セッション

ユーザーセッションのデータに基づいて条件を設定します。変更できるフィールドは、次のとおりです。

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

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

    この条件を使用すれば、認証後の限られた期間だけリソースを使用可能にする方法で、機密リソースを保護できます。

セッションプロパティー

ユーザーの Access Manager セッションに設定されたプロパティーの値に基づいて要求にポリシーを適用できるかどうかを決定します。ポリシーの評価中に条件が「真」を返すのは、ユーザーのセッションに条件で定義されたすべてのプロパティー値が存在する場合だけです。条件の中で複数の値を使用して定義されたプロパティーについては、トークンのプロパティーの値が少なくとも 1 つあれば十分です。たとえば、この条件を使用すれば、外部リポジトリの属性に基づいてポリシーを適用することができます。認証後のプラグインは、外部属性に基づいてセッションプロパティーを設定できます。

時間

時間の制約に基づいて条件を設定します。フィールドは次のとおりです。

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

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

  • 「曜日」: 曜日を指定します。

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

応答プロバイダ

応答プロバイダは、ポリシーベースの応答属性を提供するプラグインです。応答プロバイダ属性は、ポリシー決定とともに PEP に送信されます。Access Manager に実装されているのは IDResponseProvider の 1 つだけです。このバージョンの Access Manager では、カスタム応答プロバイダはサポートされていません。エージェントの PEP は通常、これらの応答属性をヘッダーとしてアプリケーションに渡します。アプリケーションは通常、これらの属性を使用して、ポータルページなどのアプリケーションページをポリシーに基づいて設定します。

ポリシーアドバイス

条件で決定したようにポリシーを適用できない場合は、ポリシーを要求に適用できなかった理由を示すアドバイスメッセージを条件によって作成できます。このアドバイスメッセージは、ポリシー決定でポリシー適用ポイントに伝わります。ポリシー適用ポイントでは、このアドバイスを取得し、認証メカニズムにユーザーを戻してより高いレベルに認証するなど、適切なアクションを実行しようとします。アドバイスの適切なアクションを実行したあとでポリシーが適用可能になると、ユーザーはより高いレベルの認証を要求され、リソースにアクセスできるようになることがあります。

詳細は、次のクラスを参照してください。

com.sun.identity.policy.ConditionDecision.getAdvices()

条件が満たされない場合、アドバイスを提供するのは、AuthLevelCondiiton と AuthSchemeCondition のみです。

AuthLevelCondition アドバイスは、次のキーに関連します。

com.sun.identity.policy.plugin.AuthLevelCondition.AUTH_LEVEL_CONDITION_ADVICE

AuthSchemeCondition アドバイスは、次のキーに関連します。

com.sun.identity.policy.plugin.AuthLevelCondition.AUTH_SCHEME_CONDITION_ADVICE

カスタム条件でもアドバイスを作成できます。ただし、Access Manager ポリシーエージェントは、認証レベルアドバイスと認証方式アドバイスのみに応答します。カスタムエージェントを作成してより多くのアドバイスを理解させて応答させたり、既存の Access Manager エージェントを拡張してより多くのアドバイスを理解させて応答させたりすることができます。詳細は、『Sun Java System Access Manager Policy Agent 2.2 User’s Guide』を参照してください。

参照ポリシー

管理者は、あるレルムのポリシーの定義と決定を別のレルムに委任することが必要になる場合があります。または、あるリソースに対するポリシー決定を別のポリシー製品に委任することもできます。参照ポリシーは、ポリシーの作成と評価の両方に対するポリシーの委任を管理します。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 は次の場所にあります。

AccessManager-base/SUNWam/dtd (Solairs)
AccessManager-base/identity/dtd (Linux)
注 –

本章ではこれ以降、ディレクトリ情報は Solaris についてのみ記します。Linux のディレクトリ構造は異なっていることに注意してください。

Policy 要素

Policy はアクセス権、つまりポリシーのルールと、ルールの適用先、つまり対象を定義するルート要素です。また、ポリシーが参照 (委任) ポリシーかどうか、およびポリシーになんらかの制限 (または条件) があるかどうかも定義します。この要素には、Rule、Conditions、Subjects、Referrals、response providersというサブ要素のうち 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 属性を持つこともできます。

ポリシーを有効にしたサービスの追加

サービススキーマの <Policy> 要素が sms.dtd に設定されている場合にのみ、そのサービスのリソースにポリシーを定義することができます。

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

/etc/opt/SUNWam/config/xml/

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

Procedure新しいポリシーを有効にしたサービスを追加する

手順

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

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

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

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


    /config/xml/newPolicyService.xml

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


    AccessManager-base/SUNWam/bin/amadmin
    --runasdn “uid=amAdmin,ou=People,default_org,
root_suffix
    --password password
    --schema /config/xml/newPolicyService.xml

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

ポリシーの作成

Policy API と Access Manager コンソールを使用してポリシーを作成、変更、および削除でき、amadmin コマンド行ツールを使用してポリシーを作成および削除できます。また、amadmin ユーティリティーを使用して、ポリシーの一覧を XML 形式で取得して表示することもできます。この節では、amadmin コマンド行ユーティリティーと Access Manager コンソールを使用してポリシーを作成することを中心に説明します。Policy API の詳細は、『Sun Java System Access Manager 7 2005Q4 Developer’s Guide』を参照してください。

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

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

Procedureamadmin でポリシーを作成する

手順

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

    AccessManager-base /SUNWam/dtd

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


    AccessManager-base/SUNWam/bin/amadmin
--runasdn "uid=amAdmin,ou=People,default_org,
root_suffix"
--password password
--data policy.xml

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

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

    SubrealmReferral、PeerRealmReferral、Realm 対象、IdentityServerRoles 対象、LDAPGroups 対象、LDAPRoles 対象、および LDAPUsers 対象の Value 要素のテキストには、完全な DN を指定する必要があります。

ProcedureAccess Manager コンソールを使って標準ポリシーを作成する

手順

  1. ポリシーを作成するレルムを選択します。

  2. 「ポリシー」タブをクリックします。

  3. 「ポリシー」リストから「新規ポリシー」をクリックします。

  4. ポリシーの名前と説明を入力します。

  5. ポリシーをアクティブにする場合は、「アクティブ」属性で「はい」を選択します。

  6. この時点では、標準ポリシーのフィールドすべてを定義する必要はありません。ポリシーの作成後、ルール、対象、条件、および応答プロバイダを追加できます。詳細は、「ポリシーの管理」を参照してください。

  7. 「作成」をクリックします。

ProcedureAccess Manager コンソールを使って参照ポリシーを作成する

手順

  1. ポリシーを作成するレルムを選択します。

  2. 「ポリシー」タブから「新規参照」をクリックします。

  3. ポリシーの名前と説明を入力します。

  4. ポリシーをアクティブにする場合は、「アクティブ」属性で「はい」を選択します。

  5. この時点では、参照ポリシーのフィールドすべてを定義する必要はありません。ポリシーの作成後、ルールおよび参照を追加できます。詳細は、「ポリシーの管理」を参照してください。

  6. 「作成」をクリックします。

ピアレルムおよびサブレルムのポリシーの作成

ピアレルムまたはサブレルムのポリシーを作成するには、まず親レルムまたは別のピアレルムで参照ポリシーを作成する必要があります。参照ポリシーのルールの定義には、サブレルムが管理するリソースプレフィックスを含める必要があります。親レルムまたは別のピアレルムで参照ポリシーを作成すれば、サブレルムまたはピアレルムで標準ポリシーを作成できます。

次の例では、o=isp は親レルム、o=example.com は、http://www.example.com のリソースとサブリソースを管理するサブレルムです。

Procedureサブレルムのポリシーを作成する

手順

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

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

  2. example.com というサブレルムに移動します。

  3. これで isp によってリソースが example.com の管理に委ねられたので、http://www.example.com というリソース、または http://www.example.com から始まる任意のリソースに対して標準ポリシーを作成できます。

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

ポリシーの管理

標準または参照ポリシーを作成し、Access Manager に追加したあとは、ポリシーの管理は、Access Manager のコンソールを使用して、ルール、対象、条件と参照を変更することにより行えます。

標準ポリシーの修正

「ポリシー」タブを使用して、アクセス権を定義する標準ポリシーを変更することができます。複数のルール、対象、条件、およびリソースコンパレータを定義および設定できます。ここでは、標準ポリシーを変更する手順のいくつかについて説明します。

Procedure標準ポリシーのルールを追加または変更する

手順

  1. すでにポリシーを作成済みである場合は、ルールを追加するポリシーの名前をクリックします。ポリシーを作成済みでない場合は、「Access Manager コンソールを使って標準ポリシーを作成する」を参照してください。

  2. 「ルール」メニューから「新規」をクリックします。

  3. 次のデフォルトのサービスタイプから、ルール用に 1 つ選択します。ポリシーに複数のサービスが使用できる場合は、さらに多くのサービスが一覧表示されます。

    ディスカバリサービス

    ディスカバリサービスクエリー用の認証アクションを定義し、指定されたリソースについて、Web サービスクライアントによるプロトコル呼び出しを変更します。

    Liberty 個人プロファイルサービス

    Liberty 個人プロファイルサービスクエリー用の認証アクションを定義し、指定されたリソースについて、Web サービスクライアントによるプロトコル呼び出しを変更します。

    URL ポリシーエージェント

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

  4. 「次へ」をクリックします。

  5. ルールの名前とリソース名を入力します。

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

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


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

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

  6. ルールのアクションを選択します。URL ポリシーエージェントサービスを使用する場合は、次のアクションを選択できます。

    • GET

    • POST

  7. アクションの値を選択します。

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

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

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

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

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

  8. 「終了」をクリックします。

Procedure標準ポリシーの対象を追加および変更する

手順

  1. すでにポリシーを作成済みである場合は、対象を追加するポリシーの名前をクリックします。ポリシーを作成済みでない場合は、「Access Manager コンソールを使って標準ポリシーを作成する」を参照してください。

  2. 「対象」リストから、「新規」をクリックします。

  3. デフォルトの対象タイプを次の中から選択します。対象タイプの説明は、「対象」を参照してください。

  4. 「次へ」をクリックします。

  5. 対象の名前を入力します。

  6. 「排他的」フィールドを選択または選択解除します。

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

    ポリシーに複数の対象が存在する場合には、1 つ以上の対象のメンバーであるアイデンティティーにポリシーが適用されます。

  7. 検索を実行して、対象に追加するアイデンティティーを表示します。この手順は、「認証済みユーザー」対象や「Web サービスクライアント」対象には適用できません。

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

  8. 対象に追加する個々のアイデンティティーを選択するか、または「すべて追加」を選択して一度にすべてのアイデンティティーを追加します。「追加」をクリックしてアイデンティティーを選択リストに移動します。この手順は、「認証済みユーザー」対象には適用されません。

  9. 「終了」をクリックします。

  10. ポリシーから対象を削除するには、対象を選択して「 削除」をクリックします。対象の名前をクリックすると、対象の定義を編集できます。

Procedure標準ポリシーに条件を追加する

手順

  1. すでにポリシーを作成済みである場合は、条件を追加するポリシーの名前をクリックします。ポリシーを作成済みでない場合は、「Access Manager コンソールを使って標準ポリシーを作成する」を参照してください。

  2. 「条件」リストから、「新規」をクリックします。

  3. 条件タイプを選択して、「次へ」をクリックします。

  4. 条件タイプのフィールドを定義します。条件タイプの説明は、「条件」を参照してください。

  5. 「終了」をクリックします。

Procedure標準ポリシーに応答プロバイダを追加する

手順

  1. すでにポリシーを作成済みである場合は、応答プロバイダを追加するポリシーの名前をクリックします。ポリシーを作成済みでない場合は、「Access Manager コンソールを使って標準ポリシーを作成する」を参照してください。

  2. 「応答プロバイダ」リストから、「新規」をクリックします。

  3. 応答プロバイダの名前を入力します。

  4. 次の値を定義します。

    StaticAttribute

    その名前と値が IDResponseProvider インスタンスに定義され、ポリシーに保存されている応答属性。

    DynamicAttribute

    ここで選択する応答属性は、対応するレルムのポリシー設定サービス内で事前に定義されている必要があります。定義される属性名は、設定済みデータストア内に存在する属性名と同じになるようにしてください。属性の定義方法の詳細については、Access Manager のオンラインヘルプで、ポリシー設定属性定義の項目を参照してください。

  5. 「終了」をクリックします。

  6. ポリシーから応答プロバイダを削除する場合は、そのプロバイダを選択し、「 削除」をクリックします。名前をクリックすると、応答プロバイダの定義を編集できます。

参照ポリシーの修正

参照ポリシーを使用すると、あるレルムのポリシーの定義や判断を別のレルムに委任できます。カスタム参照を使用すると、任意のポリシー適用先からポリシー決定を取得できます。参照ポリシーを作成したら、関連付けられているルール、参照、および応答プロバイダを追加または変更できます。

Procedure参照ポリシーのルールを追加および変更する

手順

  1. すでにポリシーを作成済みである場合は、ルールを追加するポリシーの名前をクリックします。ポリシーを作成済みでない場合は、「Access Manager コンソールを使って参照ポリシーを作成する 」を参照してください。

  2. 「ルール」リストから「新規」をクリックします。

  3. 次のデフォルトのサービスタイプから、ルール用に 1 つ選択します。ポリシーに複数のサービスが使用できる場合は、さらに多くのサービスが一覧表示されます。

    ディスカバリサービス

    ディスカバリサービスクエリー用の認証アクションを定義し、指定されたリソースについて、Web サービスクライアントによるプロトコル呼び出しを変更します。

    Liberty 個人プロファイルサービス

    Liberty 個人プロファイルサービスクエリー用の認証アクションを定義し、指定されたリソースについて、Web サービスクライアントによるプロトコル呼び出しを変更します。

    URL ポリシーエージェント

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

  4. 「次へ」をクリックします。

  5. ルールの名前とリソース名を入力します。

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

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


    http://*:*/*.html

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

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


    http://*.subdomain.domain.topleveldomain

  6. 「終了」をクリックします。

Procedureポリシーの参照を追加または変更する

手順

  1. すでにポリシーを作成済みである場合は、応答プロバイダを追加するポリシーの名前をクリックします。ポリシーを作成済みでない場合は、「Access Manager コンソールを使って参照ポリシーを作成する 」を参照してください。

  2. 「ルール」リストから「新規」をクリックします。

  3. 「サービスタイプ」を選択します。

  4. 「ルール」フィールドにリソースを定義します。フィールドは次のとおりです。

    参照— 現在の参照タイプが表示されます。

    名前— 参照の名前を入力します。

    リソース名— リソースの名前を入力します。

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

    値 — 参照の組織名を選択します。

  5. 「終了」をクリックします。

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

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

Procedure参照ポリシーに応答プロバイダを追加する

手順

  1. すでにポリシーを作成済みである場合は、応答プロバイダを追加するポリシーの名前をクリックします。ポリシーを作成済みでない場合は、「Access Manager コンソールを使って標準ポリシーを作成する」を参照してください。

  2. 「応答プロバイダ」リストから、「新規」をクリックします。

  3. 応答プロバイダの名前を入力します。

  4. 次の値を定義します。

    StaticAttribute

    その名前と値が IDResponseProvider インスタンスに定義され、ポリシーに保存されている応答属性。

    DynamicAttribute

    その名前がポリシーの IDResponseProvider インスタンスで選択されただけの応答属性。値は、ポリシーが評価されるときに要求されたユーザーアイデンティティーに基づいて、 IDRepostitories から読み込まれます。

  5. 「終了」をクリックします。

  6. ポリシーから応答プロバイダを削除する場合は、そのプロバイダを選択し、「 削除」をクリックします。名前をクリックすると、応答プロバイダの定義を編集できます。

ポリシー設定サービス

各組織のポリシーに関連する属性の設定を Access Manager コンソールから行うにはポリシー設定サービスを使用します。Access Manager ポリシーフレームワークで使用するリソース名の実装および Directory Server データストアを定義することもできます。ポリシー設定サービスに指定した Directory Server は、LDAP ユーザー、LDAP グループ、LDAP ロール、および組織ポリシー対象のメンバーシップの評価に使用されます。

対象結果の有効時間

ポリシー評価のパフォーマンスを上げるため、ポリシー設定サービスの「対象結果の有効時間」属性で定義されるとおり、メンバーシップ評価を一定の時間キャッシュします。これらのキャッシュされたメンバーシップ決定は「対象結果の有効時間」属性で定義された時間が経つまで使用されます。この時間が経過したあとは、ディレクトリ内のユーザーの現在の状態を反映するために、メンバーシップ評価が使用されます。

動的属性

これらは使用可能な動的属性の名前であり、ポリシーの応答プロバイダの動的属性を定義する際に一覧表示され、選択されます。定義される名前は、データリポジトリ内に定義された属性名と同じである必要があります。

amldapuser の定義

amldapuser はインストール時に作成されたユーザーで、ポリシー設定サービスに指定した Directory Server でデフォルトで使用されます。amldapuser は、レルムの管理者またはポリシー管理者が必要に応じて変更できます。

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

レルムを作成すると、そのレルムのためにポリシー設定サービスの属性が自動的に設定されます。ただし、これらの属性は必要に応じて変更できます。

リソースベースの認証

組織によっては高度な認証シナリオが必要です。この場合、ユーザー認証は、アクセスしようとするリソースごとに特定のモジュールで行われます。リソースベースの認証は、Access Manager の機能で、ユーザーはデフォルトの認証モジュールではなく、そのリソースを保護している認証モジュールから認証される必要があります。この機能は、ユーザーが初めて認証される時にのみ適用可能です。

注 –

これは、「セッションのアップグレード」で説明しているリソースベースの認証とは別の機能です。その機能には何の制限もありません。

制限

リソースベースの認証には、次のような制限があります。

Procedureリソースベースの認証を設定する

Access Manager とポリシーエージェントをインストールしたら、リソースベースの認証を設定できます。そのためには、Access Manager が Gateway サーブレットを指す必要があります。

手順

  1. AMAgent.properties を開きます。

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

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

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

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

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

    注 –

    ゲートウェイサーブレットは Policy Evaluation API を使って開発します。このサーブレットを使えば、リソースベースの認証を実現するためのカスタムメカニズムを記述できます。『Sun Java System Access Manager 7 2005Q4 Developer’s Guide』の第 6 章「Using the Policy APIs」を参照してください。

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