ネストされたレルムを持つポリシーに対するポリシー処理

目次
sm1252sp1jjp
目次
3
ポリシー サーバでは、ポリシーを使用して、リソースへのアクセスを許可したり、許可されたユーザに権限を付与したりします。ポリシーが保護するリソースは通常、セキュリティ、組織、およびビジネス要件を模倣し、階層型または「ネストされた」レルムを利用する階層に格納されます。
ネストされたレルムを持つ設定の例
このセクションで説明する設定の例は、このトピックの残りの部分でも使用します。
ユーザ ディレクトリ
ポリシーやその他の関連するポリシー サーバ オブジェクトを持つポリシー ドメインに、次の図のような LDAP ユーザ ディレクトリへの接続が含まれるものとします。
LDAP directory example
サンプル ユーザ ディレクトリには以下の要素が含まれます。
  • o=myorg.org
    組織。
  • ou=people
    すべての従業員の情報が含まれる組織単位。
  • employee<n>
    各従業員のディレクトリ エントリ。a_lvl は、アクセス レベルを示すユーザ属性です。このセクションの例では、employee1 と employee2 のアクセスレベルを 0 (a_lvl=0)とします。
  • cn=employees
    会社のすべての従業員がメンバとして格納されているグループ。
  • cn=managers
    マネージャの役職を持つすべての従業員がメンバとして格納されているグループ。このグループには employee3 と employee4 だけが所属します。従業員のアクセス レベルは 0 より大きくなっています。
ネストされたレルムとリソース
このセクションの例で使用されるネストされたレルムとリソースの構造を、次の図に示します。グレー表示されたレルムは、特定の認証方式で保護されているレルムです。
Nested realms and resources example
ネストされたレルムを構成しているディレクトリとリソースは、次のとおりです。
  • /home
    これは、サンプルのネストされたレルムの最上位ディレクトリです。このレルムの場合、リソース フィルタは /home/ であり、レルム内には index.html という保護されていないリソースが存在します。この index.html ファイルは、認証方式で保護されていません。
  • /employees
    このディレクトリは /home ディレクトリに含まれます。クレデンシャルとしてユーザ名とパスワードを必要とする基本認証方式で保護されています。このディレクトリに関連付けられたレルムの場合、リソース フィルタは employees/ であり、レルム内には employee.html ファイルが存在します。このレルムのリソース フィルタ全体は、/home/employees/ です。
  • /managers
    このディレクトリは /employees ディレクトリに含まれます。クレデンシャルとしてユーザ名、パスワード、および追加の個人情報を必要とする HTML フォーム認証方式によって保護されています。このディレクトリに関連付けられたレルムの場合、リソース フィルタは managers/ であり、レルム内には manager.html ファイルが存在します。このレルムのリソース フィルタは、全体として /home/employees/managers/ となります。
  • /restricted
    このディレクトリは /managers ディレクトリに含まれます。クレデンシャルとしてユーザ名、パスワード、および有効な X.509 証明書を必要とする、X.509 証明書と基本認証方式によって保護されています。このディレクトリに関連付けられたレルムの場合、リソース フィルタは restricted/ であり、レルム内には restricted.html ファイルが存在します。このレルムのリソース フィルタは、全体として /home/employees/managers/restricted/ となります。
これらの例では、/employees レルムの保護レベルが最も低く、/managers レルム、/restricted レルムの順に保護レベルが高くなります。
ポリシーとレスポンス
この章の後半の例で使用されるポリシーとレスポンスを、以下の図に示します。
 
Nested realms example policies and responses
それぞれのサンプル ポリシーと、各ポリシーに含まれているオブジェクトについて説明します。
  • Employee ポリシー
    Get ルールを含むポリシーです。employee.html リソースを保護します。このリソースは、/employees レルムにあります。このポリシーによって、ユーザグループの cn=employees がバインドされます。したがって、LDAP ディレクトリ内の全従業員は、正常に認証されればリソースにアクセスできます。認証されたユーザがこのポリシーによって許可されると、は、そのユーザの電子メール アドレスのレスポンスを返します。たとえば、employee1 が /home/employees/employee.html へのアクセスを試行して正常に認証された場合、ポリシー サーバは employee1 のリソースへのアクセスを許可し、電子メール アドレスを返します。
    [email protected] を返します。
    Web アプリケーションでは、他の社内リソースにアクセスする場合、このレスポンスを使って、そのリソースをカスタマイズできます。
  • Manager ポリシー
    Get ルールを含むポリシーです。manager.html リソースを保護します。このリソースは、/managers レルムにあります。このポリシーによって、ユーザグループの cn=managers がバインドされます。したがって、cn=managers グループ内の従業員だけが、正常に認証されればリソースにアクセスできます。認証されたマネージャがこのポリシーによって許可されると、はスタティック レスポンスを返します。この例では、employee3 が /home/employees/managers/manager.html にアクセスしようとして正常に認証された場合、employee3 はリソースへのアクセスを許可され、ポリシー サーバは次のレスポンスを返します。
    manager=YES
    アプリケーションでは、会社のマネージャだけが使用可能な機能を、このレスポンスを使用して有効にすることができます。
  • Restricted ポリシー
    Get ルールを含むポリシーです。restricted.html リソースを保護します。このリソースは、/restricted レルムにあります。このポリシーによってバインドされるディレクトリ内の従業員は、アクセスレベルを示すユーザ属性が 2 (a_lvl=2) の従業員だけです。正しいアクセスレベルを持つマネージャは、正常に認証されるとリソースにアクセスできます。ユーザが restricted.html リソースへのアクセスを試行すると、は a_lvl=<0-2> のレスポンスを返します。たとえば、employee4 が /home/employees/managers/restricted/restricted.html へのアクセスを試行して正常に認証された場合、ポリシー サーバは employee4 のリソースへのアクセスを許可し、以下のレスポンスを返します。
    a_lvl=2
    アプリケーションは、アクセスレベル 2 を持つ従業員だけが使用可能な機能を、このレスポンスを使用して有効にすることができます。
階層構造のポリシーに対する認証処理
ポリシーにはルールが必要です。ルールには、認証イベントと許可イベントを指定できます。ポリシー サーバがユーザの認証情報に基づいてユーザを識別する場合、ルールの設定内容に応じて、次の 4 つの認証イベントのいずれかが発生します。
  • OnAuthAccept
    正常に認証された場合。
  • OnAuthAttempt
    ポリシー ドメインの検索順序に指定されたディレクトリを検索してもユーザが見つからなかったため、認証に失敗した場合。
  • OnAuthReject
    ユーザが
    ディレクトリ内に見つかりました
    が、ユーザから提供された認証情報が正しくないため、認証に失敗した場合。このイベントが発生した場合、ポリシー サーバは、ポリシー ドメインのディレクトリ検索順序で指定された次のディレクトリを検索します。検索順序に指定されたディレクトリではユーザの証明を確認できない場合、ポリシー サーバは OnAuthReject イベントを処理します。
    OnAuthReject ルールが起動するには、ディレクトリでユーザが検出される必要があります。どのディレクトリからもユーザが見つからない場合には、OnAuthReject ルールは起動しません。
  • OnAuthUserNotFound
    認証サーバに有効なセッション チケットがあるにもかかわらず、ユーザ ディレクトリが見つからない場合。この状態は、シングル サインオン環境で複数ディレクトリを使用する場合にのみ発生します。ただし、アイドル状態が長いためにユーザがエージェントのキャッシュから削除され、さらにディレクトリからも削除された場合にも発生する可能性があります。このイベントが発生した場合、ポリシー サーバは、ユーザがディレクトリに存在するかどうかを評価し、セッションチケットには頼りません。
ポリシー サーバは、一致する最も長いレルムに基づいてユーザを認証しようとします。たとえば、ユーザが /home/employees/managers/manager.html にアクセスしようとすると、ポリシー サーバは、/managers レルムを使用して必要な認証報を決定します。前出の図の例では、ユーザは、ブラウザベースのフォームに必要な項目を入力する必要があります。このフォームは、レルムに関連付けられている HTML フォーム認証方式で要求されるものです。
注:
一致する最も長いレルムによって、ユーザのセッションのタイムアウトも決定されます。タイムアウトがレルムに関連付けられていて、そのレルム内でユーザが正常に認証された場合、そのタイムアウトが使用されます。レスポンスを使用して、特定のリソースまたはリソース グループのレルムのタイムアウト値を上書きすることができます。
成功した認証
OnAuthAccept ルールは、次のすべての条件が満たされたときに起動します。
  • ユーザが入力する証明情報が、一致する最も長いレルムの要件を満たす。
  • ポリシー サーバによって、ユーザディレクトリ内にユーザが認識される。
  • ポリシー サーバによって、ユーザのクレデンシャルが確認される。
この時点で、一致する最も長いレルムや、ネストされたレルムの階層構造の中でそのレルムより上位にあるすべてのレルムから、ポリシー サーバは OnAuthAccept 権限付与情報を収集します。前述の図の例では、リソース /home/employees/managers/manager.html に対するユーザの認証が成功すると、ポリシー サーバは、/managers レルム、/employees レルム、/home レルムの順に、すべての OnAuthAccept 資格を収集します。
拒否された認証
ポリシー ドメインは、ディレクトリの検索順序に従って設定されます。ポリシー サーバがユーザを認証しようとする場合、検索順序に従ってユーザディレクトリ内でユーザを検索し、入力された証明情報を確認します。ポリシー サーバがディレクトリ内にユーザを特定できても、ユーザが入力した証明と一致しない場合は、検索順序に指定された次のディレクトリを検索します。ポリシー サーバがどのディレクトリを検索しても一致するユーザが見つからないと、要求されたリソースが含まれているレルムのコンテキストで、ユーザの認証は失敗します。
たとえば、あるユーザが /home/employees/managers/manager.html へのアクセスを試行する際に、そのユーザがユーザ ディレクトリに格納されているのに、検索順序に指定されている任意のディレクトリに対して有効なクレデンシャルを入力しなかった場合、/managers レルムでの認証イベントは失敗します。次に、ポリシー サーバは、そのレルムで拒否された認証試行に対するイベント(OnAuthReject)をすべて処理します。
失敗した認証
ディレクトリ検索順序に指定されているディレクトリをポリシー サーバが検索しても、認証を試みているユーザが見つからない場合は、要求されたリソースが含まれるレルムのコンテキストにおいて、認証が失敗します。次に、ポリシー サーバは、失敗した認証試行に対するイベント(OnAuthAttempt)をすべて処理します。
階層構造のポリシーに対する許可処理
ポリシーにルールを指定して、リソースへのアクセスを許可することができます。また、イベントをトリガするルールを追加することもできます。可能な許可イベントは、次のとおりです。
  • OnAccessAccept
    ユーザが正常に許可されたときに発生するイベントです。
  • OnAccessReject
    認証されたユーザがリソースへのアクセスを拒否されたときに発生するイベントです。
ルールに許可イベントが指定されていない場合は、ルールが実施することは、リソースへのアクセスを許可または拒否することです。
許可されたユーザに対するポリシーの処理
ネストされたレルム内のリソースへのアクセスをポリシー サーバがユーザに許可するには、階層の最上位からリソースを含むレルムまでの各レルムで、ユーザが許可されている必要があります。ユーザが認証されると、ポリシー サーバは、リソースの上位レルムに適用されたポリシーをチェックし、ユーザが許可されていることを確認します。前述の例では、employee3 が /home/employees/managers/manager.html にアクセスしようとすると、ポリシー サーバは /home、/employees、および /managers の順にレルムをチェックして、employee3 が許可されているかどうかを確認します。
ポリシー サーバは、ユーザが許可されていると判断できる場合に、ネストされた各レルムからそのユーザの権限付与情報を収集します。次に、レルムの階層の最上位から順に、一致する最も長いレルムまで、OnAccessAccept イベントを処理します。前述の例では、ポリシー サーバから返されるレスポンスには、manager=YES というスタティック レスポンスと、employee3 の電子メール アドレスが含まれます。
無許可のユーザに対するポリシーの処理
無許可のユーザについては、そのユーザのアクセスをポリシーで明示的に拒否しているかどうか、アクセスを許可するポリシーから単にユーザが除外されているかどうかによって、ポリシーの処理が変わることはありません。無許可のユーザについて収集されてきた権限付与情報はすべて失われます。ポリシー サーバは、ユーザアクセスを拒否するレルム、つまり、要求されたリソースが存在するレルムのコンテキストにおいて、OnAccessReject イベントを処理します。
前述の例では、cn=managers グループのメンバではない employee1 が /home/employees/managers/manager.html へのアクセスを試みると、ポリシー サーバは、/managers レルムの OnAccessReject イベントのみを処理します。
OnAccessRejct ルール用の個別のポリシーを作成します。OnAccessReject ルールは、同じポリシー内の他のルール アクションと組み合わせないでください。
権限のないユーザに対するポリシー設定の例
OnAccessReject リダイレクトを実装するには、まず拒否ルールを起動するためのアクセス権限が必要です。
この例では、ユーザ JSmith のみがリソース
/static
にアクセスできるようにします。その他のすべてのユーザは、以下のリンクへリダイレクトされる必要があります。
以下のポリシー コンポーネントを設定します。
  1. リソース
    /static
    用のレルムと Web エージェントを作成します。
  2. レルムの下に 3 つのルールを作成します。
    • Rule1:
      [Web エージェント]アクション
      を選択し、リソース
      /static
      に対する GET/POST を許可します
    • Rule2:
      [認証イベント]
      を選択し、OnAuthReject を選択します。
    • Rule3:
      [許可イベント]
      を選択し、OnAccessReject を選択します
  3. 認証エラーおよび許可エラーに対して異なる、別々のリダイレクト URL を使用する 2 つのレスポンスを作成します。
  4. 2 つのポリシーを作成します。
    • ポリシー 1 は、アクセスを許可します。このポリシーで、
      • JSmith をユーザに追加します。
      • Rule1 をポリシーに追加します。
    • ポリシー 2 では、権限のない(拒否された)ユーザをリダイレクトします。このポリシーで、
      • [ALL]を追加します(ルールが起動するには、ユーザにアクセス権が必要)
      • Rule2 および Rule3 を追加します。
      • Response1 を Rule2 に追加します。
      • Response2 を Rule3 に追加します。
このポリシーによって、JSmith は保護されているリソースへのアクセス権を獲得し、他のすべてのユーザはアクセスを禁止され、他のページにリダイレクトされます。
階層構造のポリシーでのディレクトリ マッピング
Single Sign-On
の設定にネストされたレルムが含まれる場合、各レルムに認証ディレクトリとは異なる許可ディレクトリを指定するディレクトリ マッピングが含まれる可能性があります。ディレクトリ マッピングによって、企業内に複数の許可ディレクトリが配置された状態で、単一のディレクトリを使用してユーザを認証できます。ネストされたレルムのグループで資格情報を処理する場合、ポリシー サーバは階層内のレルムごとにディレクトリ マッピングを調べます。ディレクトリ マッピングがなければ、ポリシー サーバは認証ディレクトリを許可ディレクトリとして使用します。