ヘッダーをスキップ
Oracle® Fusion Middlewareアプリケーション・セキュリティ・ガイド
11gリリース1(11.1.1)
B56235-07
  目次へ移動
目次
索引へ移動
索引

前
 
次
 

20 OPSSポリシー・モデル

この章では、OPSSポリシーおよび認可モデルについて説明します。内容は次のとおりです。

20.1 セキュリティ・ポリシー・モデル

OPSSポリシー・モデルおよび使用されるセキュリティ・アーティファクトの詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドを参照してください。

20.2 認可の概要

この項では、Java EEとJAASのモデルで使用可能な認可を比較検討しています。この項の内容は次のとおりです。

20.2.1 認可について

Java 2ポリシーは、特定の場所からロードされた署名付きコードに付与されるパーミッションを指定します。JAASポリシーは、オプションのプリンシパル・リストを指定できるようにすることで、Java 2の権限を拡張します。これにより、特定の場所からロードされた(多くの場合は署名付きの)コードにのみパーミッションが付与され、このリストにあるプリンシパルで表されるユーザーによって実行されます。

ポリシー・ストアは、システムおよびアプリケーションに固有のポリシーとロールを格納するリポジトリです。アプリケーション・ロールは、アプリケーション固有のエンタープライズ・ユーザーおよびグループ(管理ロールなど)に付与(マップ)できます。ポリシーでは、これらのロール、グループまたはユーザーにプリンシパルとしてパーミッションを付与できます。

ポリシー関連のセキュリティ・アーティファクトの詳細は、第3章「ポリシー・ストアの基本」を参照してください。

アプリケーションでは、認可の適用をコンテナに委任できるほか、checkPermissioncheckBulkAuthorizationgetGrantedResourcesなどのメソッドのコールによってポリシー確認を自身で適用する実装も可能です。

APIコールを使用したポリシー確認の詳細は、「ポリシーの確認」を参照してください。

20.2.2 Java EE認可モデル

Java EE認可モデルでは、ロール・メンバーシップを使用して、EJBメソッドおよびURLで参照するWebリソースへのアクセスを制御します。ポリシーによってユーザーとロールにパーミッションが割り当てられ、ポリシーがコンテナで適用されてリソースが保護されます。

Java EEモデルでは、次のいずれかの方法で認可が実装されます。

  • 宣言的。この方法では、認可ポリシーがデプロイメント・ディスクリプタで指定されます。コンテナはデプロイメント・ディスクリプタから認可ポリシーを読み取って実施します。認可を実施するための特別なアプリケーション・コードは必要ありません。

  • プログラム的。この方法では、アプリケーション・コードで認可ポリシーを確認します。このコードによって、特定のコード・セクションの実行に適したパーミッションがサブジェクトにあるかどうかを確認します。サブジェクトに適切なパーミッションが与えられていない場合、コードは例外をスローします。

表20-1は、各方法の長所と短所を示しています。

表20-1 Java EEモデルの認可の比較

認可のタイプ 長所 短所

宣言

コーディングが不要。デプロイメント・ディスクリプタのみを変更すればよいため、更新が簡単。

認可のレベルが大まかであり、URLレベルまたはメソッド・レベル(EJBの場合)で指定されます。

プログラム

アプリケーション・コードで指定され、よりきめ細かいレベルでコードを保護できます。

コード変更や再コンパイルを伴うため、更新は容易ではありません。


コンテナは、その内部で稼働中のアプリケーションに対して、宣言的およびプログラム的という2つの方法で認可を提供できます。次の各項ではこれらの方法を説明して例を示します。

20.2.2.1 宣言による認可

宣言的な認可では、URLベースのリソース(サーブレットやページなど)やEJBのメソッドに対するアクセスを制御できます。

宣言的な認可を構成する基本手順は、次のとおりです。

  1. 標準のデプロイメント・ディスクリプタで、保護するリソース(Web URL、EJBメソッドなど)と、そのリソースへのアクセス権を持つ論理ロールを指定します。

    または、Java EE 1.5は注釈をサポートしているため、デプロイメント・ディスクリプタではなくコード注釈を使用します。

  2. 固有デプロイメント・ディスクリプタ(web.xmlなど)では、ステップ1で定義した論理ロールをエンタープライズ・グループにマップします。

20.2.2.2 プログラムによる認可

プログラム的な認可では、宣言的な方法よりもきめ細かい認可を実現できます。プログラム的な認可では、メソッドisUserInRole(サーブレットおよびJSPの場合)またはメソッドisCallerInRole(EJBの場合)をアプリケーションのコードから呼び出す必要があります。これらはどちらも標準のJava APIに用意されています。

これらのメソッドは、認可の決定に関してロール・メンバーシップにある程度は依存しますが、これらの使用により、ユーザーは、リソース・レベル(EJBのメソッドまたはURL)のアクセス制御に限定されることがないため、よりきめ細かく認可の決定を制御できるようになります。

20.2.2.3 Java EEコードの例

次の例では、メソッドisUserInRoleをコールするサーブレットを示しています。サーブレットをパッケージ化しているEARファイルには構成ファイルweb.xmlおよびweblogic-application.xmlが含まれており、これらのファイルには次の構成の断片が含まれていることを前提とします。

web.xml

 <!-- security roles -->
 <security-role>
   <role-name>sr_developer</role-name>
 </security-role>

weblogic-application.xml

次のスニペットは、ユーザーweblogicとセキュリティ・ロールsr_developer間のマッピングを示しています。

<wls:security-role-assignment>
  <wls:role-name>sr_developer</wls:role-name>
  <wls:principal-name>weblogic</wls:principal-name>
</wls:security-role-assignment>

isUserInRoleを呼び出すコード例

import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletOutputStream;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.util.Date;

public class PolicyServlet extends HttpServlet {
 
 public PolicyServlet() {
        super();
    }

 public void init(ServletConfig config)
            throws ServletException {
        super.init(config);
    }

 public void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        final ServletOutputStream out = response.getOutputStream();
 
        response.setContentType("text/html");
        out.println("<HTML><BODY bgcolor=\"#FFFFFF\">");
        out.println("Time stamp: " + new Date().toString());
        out.println( "<br>request.getRemoteUser = " + request.getRemoteUser() + "<br>");
        out.println("request.isUserInRole('sr_developer') = " + request.isUserInRole("sr_developer") + "<br>");
        out.println("request.getUserPrincipal = " + request.getUserPrincipal() + "<br>");
        out.println("</BODY>");
        out.println("</HTML>");
    }
}

20.2.3 JAAS認可モデル

JAAS認可ではパーミッションを使用しますが、ロールの概念も使用できます。認可ポリシーによって、パーミッションがサブジェクト(ロール、グループまたはユーザー)にバインドされ、さらに必要に応じてソース・コードにもバインドされます。ロールの付与は、addPrincipalsToAppRoleのコールで実現します。

パーミッションは静的メソッドAccessController.checkPermissionのコールによって評価されます。このモデルでは、リソースをきめ細かく制御できます。

このモデルでは、認可ポリシーで次の情報が指定されます。

  • アプリケーション・ロールおよびエンタープライズ・グループ。

  • ユーザー、(アプリケーション・ポリシー内の)グループおよび(システム・ポリシー内の)コード・ソースに付与されるパーミッション。ユーザーおよびグループの場合は、これによってアクセスが許可されるユーザーまたはグループのメンバーが決定されます。コード・ソースの場合は、これによって、コードが実行できるアクションが決定されます。

このモデルを使用してプログラミングする場合、機密性の高いコード行の前に、現在のユーザーまたはロールがそのコードにアクセスするための適切なパーミッションを付与されているかどうかを確認するコールを記述します。ユーザーが適切なパーミッションを持っている場合は、コードが実行されます。適切なパーミッションが与えられていない場合、コードは例外をスローします。

複数のパーミッションによるコード・ソースの付与の例は、第21.5.6項「サポートされているパーミッション・クラス」を参照してください。

20.3 JAAS/OPSS認可モデル

JAASおよびOPSS認可では、クラスを環境にロードして実行するときに、そのクラスで実行できる操作を制御することが基本になっています。

この項の内容は次のとおりです。

20.3.1 リソース・カタログ

OPSSは、ファイルベース、LDAPベース、およびDBベースのポリシー・ストア内のリソース・カタログの仕様およびランタイム・サポートに対応します。

リソース・カタログの使用には次の利点があります。

  • 判読可能な用語でポリシーおよび保護アーティファクトが記述されます。

  • アプリケーション・ソース・コードに関係なく、またこれらのコードに関する知識を必要とせずに、ポリシーを定義し、変更できます。

  • 保護アーティファクトを参照および検索できます。

  • 後で認可ポリシーで使用できるビルディング・ブロック(権限またはパーミッションのセット)に保護アーティファクトをグループ化できます。

20.3.2 ポリシーの管理

リソース・カタログ・アーティファクトをポリシー管理APIで管理できます。具体的には、次のインタフェースがリソース・カタログのアーティファクトに直接関連しています。これらはすべてインタフェースoracle.security.jps.service.policystore.EntityManagerの下位インタフェースです。

  • GrantManager - このインタフェースに用意されているメソッドでは、検索条件を使用して権限を問い合せ、リソース・カタログ・アーティファクトの様々な組合せに適合する権限のリストを取得して、プリンシパルに対してパーミッションを付与または取り消すことができます。

  • PermissionSetManager - このインタフェースに用意されているメソッドでは、パーミッション・セット(権限)の作成、変更および問合せを実行できます。

  • ResourceManager - このインタフェースに用意されているメソッドでは、リソース(リソース・インスタンス)の作成、削除および変更を実行できます。

  • ResourceTypeManager - このインタフェースに用意されているメソッドでは、リソース・タイプの作成、削除、変更および問合せを実行できます。

これらのインタフェースの詳細は、JavadocドキュメントのOracle Fusion Middleware Oracle Platform Security Services Java APIリファレンスを参照してください。

次のコード・スニペットは、リソース・タイプ、リソース・インスタンス、アクションおよびパーミッション・セットの作成を示しています。

import oracle.security.jps.service.policystore.entitymanager.*;
import oracle.security.jps.service.policystore.search.*;
import oracle.security.jps.service.policystore.info.resource.*;
import oracle.security.jps.service.policystore.info.*;
import oracle.security.jps.service.policystore.*;
import java.util.*;
 
public class example {
  public static void main(String[] args) throws Exception {
     ApplicationPolicy ap;

     ResourceTypeManager rtm = ap.getEntityManager(ResourceTypeManager.class);
     ResourceTypeSearchQuery query = new ResourceTypeSearchQuery();
     query.setANDMatch();
     query.addQuery(ResourceTypeSearchQuery.SEARCH_PROPERTY.NAME, false,      ComparatorType.EQUALITY, "resourceType", BaseSearchQuery.MATCHER.EXACT);
     List<ResourceTypeEntry> allResourceTypes = rtm.getResourceTypes(query);

     ResourceManager rm = ap.getEntityManager(ResourceManager.class);
     ResourceSearchQuery ResourceQuery = new ResourceSearchQuery();
     ResourceQuery.setANDMatch();
     ResourceQuery.addQuery(ResourceSearchQuery.SEARCH_PROPERTY.NAME, false,      ComparatorType.EQUALITY, "R2", BaseSearchQuery.MATCHER.EXACT);
     List<ResourceEntry> allResources = rm.getResources("RT2", ResourceQuery);

     PermissionSetManager psm = ap.getEntityManager(PermissionSetManager.class);
     PermissionSetSearchQuery pssq = new PermissionSetSearchQuery();
     pssq.setANDMatch();
     pssq.addQuery(PermissionSetSearchQuery.SEARCH_PROPERTY.NAME, false,      ComparatorType.EQUALITY, "PS1", BaseSearchQuery.MATCHER.EXACT);
     List<PermissionSetEntry> allPermSets = psm.getPermissionSets(pssq);

     RoleCategoryManager rcm = ap.getEntityManager(RoleCategoryManager.class);
     RoleCategorySearchQuery rcsq = new RoleCategorySearchQuery();
     rcsq.setANDMatch();
     rcsq.addQuery(RoleCategorySearchQuery.SEARCH_PROPERTY.NAME, false,      ComparatorType.EQUALITY, "roleCategoryCartoon",      BaseSearchQuery.MATCHER.EXACT);

     List<RoleCategoryEntry> allRoleCategories = rcm.getRoleCategories(rcsq);
  }
}

次のコード・スニペットは、リソース・カタログ要素を使用した複雑な問合せを示しています。

//ApplicationPolicy ap as in the preceeding example
ResourceTypeManager rtm = ap.getEntityManager(ResourceTypeManager.class);
ResourceTypeSearchQuery query = new ResourceTypeSearchQuery();
query.setANDMatch();
query.addQuery(ResourceTypeSearchQuery.SEARCH_PROPERTY.NAME, false, ComparatorType.EQUALITY, "resourceType", BaseSearchQuery.MATCHER.EXACT);
List<ResourceTypeEntry> enties = rtm.getResourceTypes(query);
 
ResourceManager rm = ap.getEntityManager(ResourceManager.class);
ResourceSearchQuery ResourceQuery = new ResourceSearchQuery();
ResourceQuery.setANDMatch();
ResourceQuery.addQuery(ResourceSearchQuery.SEARCH_PROPERTY.NAME, false, ComparatorType.EQUALITY, "R2", BaseSearchQuery.MATCHER.EXACT);
ArrayList<BaseSearchQuery> querries = ResourceQuery.getQueries();
List<ResourceEntry> resources = rm.getResources("RT2", ResourceQuery);
 
PermissionSetManager psm = ap.getEntityManager(PermissionSetManager.class);
PermissionSetSearchQuery pssq = new PermissionSetSearchQuery();
pssq.setANDMatch();
pssq.addQuery(PermissionSetSearchQuery.SEARCH_PROPERTY.NAME, false, ComparatorType.EQUALITY, "PS1", BaseSearchQuery.MATCHER.EXACT);
List<PermissionSetEntry> psets = psm.getPermissionSets(pssq);
 
RoleCategoryManager rcm = ap.getEntityManager(RoleCategoryManager.class);
RoleCategorySearchQuery rcsq = new RoleCategorySearchQuery();
rcsq.setANDMatch();
rcsq.addQuery(RoleCategorySearchQuery.SEARCH_PROPERTY.NAME, false, ComparatorType.EQUALITY, "roleCategoryCartoon", BaseSearchQuery.MATCHER.EXACT);
ArrayList<BaseSearchQuery> queries = rcsq.getQueries();
List<RoleCategoryEntry> rcs = rcm.getRoleCategories(rcsq);

次のコード・サンプルは、権限を作成する方法を示しています。

GrantManager gm = ap.getEntityManager(GrantManager.class);
Set<PrincipalEntry> pe = new HashSet<PrincipalEntry>();
List<AppRoleEntry> are = ap.searchAppRoles(appRoleName);
pe.addAll(are);
gm.grant(pe, null, permissionSetName);

20.3.3 ポリシーの確認

この項では、プログラム上でポリシーを確認する方法をいくつか示します。この項の内容は次のとおりです。


重要な注意:

1. デフォルトでは、認可の失敗がコンソールに表示されません。認可の失敗がコンソールに送信されるようにするには、システム変数jps.auth.debug-Djps.auth.debug=trueに設定する必要があります。

特に、JpsAuth.checkPermissionの失敗がコンソールに送信されるようにするには、この変数を前述のように設定する必要があります。

2. OPSSポリシー・プロバイダは、次の例に示すように、Java SEアプリケーションに明示的に設定する必要があります。

java.security.Policy.setPolicy(new oracle.security.jps.internal.policystore.JavaPolicyProvider()) 

Java SEアプリケーションにポリシー・プロバイダを明示的に設定しておかないと、ランタイム・メソッド(JpsAuth.checkPermissionなど)が不正確な値を返す場合があります。


20.3.3.1 メソッドcheckPermissionの使用方法

Oracle Fusion Middlewareは、クラスjava.security.AccessControllerおよびoracle.security.jps.util.JpsAuthのメソッドcheckPermissionの使用をサポートしています。

クラスJpsAuthcheckPermissionを使用することをお薦めします。これは、このクラスのほうがデバッグ・サポートとパフォーマンスにおいて優れており、監査もサポートされるためです。

静的メソッドAccessController.checkPermissionは、デフォルトのアクセス制御コンテキスト(スレッド作成時に継承されるコンテキスト)を使用します。その他のコンテキストでパーミッションを確認するには、特定のAccessControlContextインスタンスでインスタンス・メソッドcheckPermissionをコールします。

次の表に示すように、メソッドcheckPermissionはJAASモード(第21章「サーブレット・フィルタとEJBインターセプタの構成」を参照)の値に従って動作します。

表20-2 JAASモードに応じたcheckPermissionの動作

JAASモードの設定 checkPermission

オフまたは未定義

有効なセキュリティ・ポリシーに基づくコードベースのセキュリティを実施します。サブジェクトベースのセキュリティに対するプロビジョニングはありません。

doAs

doAsブロックを使用して作成されたアクセス制御コンテキストを使用して、コードベースおよびサブジェクトベースのセキュリティを組み合せて適用します。

doAsPrivileged

NULLアクセス制御コンテキストを使用してサブジェクトベースのセキュリティを適用します。

subjectOnly

パーミッションの評価時に、プリンシパルにかかわる権限付与のみが考慮されます(コードベースにかかわる権限付与は無視されます)。



注意:

doAsブロック内でcheckPermissionがコールされてパーミッション・チェックのコールが失敗した場合に、失敗した保護ドメインを表示するにはシステム・プロパティjava.security.debug=access,failureを設定する必要があります。


次の例は、パーミッションをチェックするサーブレットを示しています。サーブレットをパッケージ化しているEARファイルに構成ファイルjazn-data.xmlおよびweb.xmlが含まれていることが前提となります。

jazn-data.xml

アプリケーションのファイルベースのポリシー・ストアは次のとおりです。

<?xml version="1.0" ?>
<jazn-data>
  <policy-store>
    <applications>
      <application>
        <name>MyApp</name>
                
        <app-roles>
        <app-role>
          <name>AppRole</name>
          <display-name>AppRole display name</display-name>
          <description>AppRole description</description>
          <guid>F5494E409CFB11DEBFEBC11296284F58</guid>
          <class>oracle.security.jps.service.policystore.ApplicationRole</class>
        </app-role>
      </app-roles>
                
      <resource-types>
        <resource-type>
          <name>MyResourceType</name>
          <display-name>MyResourceType display name</display-name>
          <description>MyResourceType description</description>
          <provider-name>MyResourceType provider</provider-name>
          <matcher-class>oracle.security.jps.ResourcePermission</matcher-class>
          <actions-delimiter>,</actions-delimiter>
          <actions>write,read</actions>
        </resource-type>
      </resource-types>
                
      <resources>
        <resource>
          <name>MyResource</name>
          <display-name>MyResource display name</display-name>
          <description>MyResource description</description>
          <type-name-ref>MyResourceType</type-name-ref>
        </resource>
      </resources>
                
      <permission-sets>
        <permission-set>
          <name>MyEntitlement</name>
          <display-name>MyEntitlement display name</display-name>
          <description>MyEntitlement description</description>
          <member-resources>
            <member-resource>
              <type-name-ref>MyResourceType</type-name-ref>
              <resource-name>MyResource</resource-name>
              <actions>write</actions>
            </member-resource>
          </member-resources>
        </permission-set>
      </permission-sets>
                
      <jazn-policy>
        <grant>
          <grantee>
            <principals>
              <principal>
                <class>
              oracle.security.jps.service.policystore.ApplicationRole</class>
                <name>AppRole</name>
                <guid>F5494E409CFB11DEBFEBC11296284F58</guid>
              </principal>
            </principals>
          </grantee>
                        
          <!-- entitlement-based permissions -->
          <permission-set-refs>
            <permission-set-ref>
              <name>MyEntitlement</name>
            </permission-set-ref>
          </permission-set-refs>
        </grant>
      </jazn-policy>
    </application>      
  </applications>
 </policy-store>
 <jazn-policy></jazn-policy>
</jazn-data>

web.xml

フィルタJpsFilterは次のように構成されます。

<web-app>
 <display-name>PolicyTest: PolicyServlet</display-name>
 <filter>
  <filter-name>JpsFilter</filter-name>
  <filter-class>oracle.security.jps.ee.http.JpsFilter</filter-class>
   <init-param>
    <param-name>application.name</param-name>
    <param-value>PolicyServlet</param-value>
   </init-param>
  </filter>
  <filter-mapping>
   <filter-name>JpsFilter</filter-name>
   <servlet-name>PolicyServlet</servlet-name>
   <dispatcher>REQUEST</dispatcher>
  </filter-mapping>...

コード例

次の例では、Subject.doAsPrivilegedJpsSubject.doAsPrivilegedによって置換される場合があります。

import javax.security.auth.Subject;
import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletOutputStream;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.io.PrintWriter;
import java.io.StringWriter;
import java.security.*;
import java.util.Date;
import java.util.PropertyPermission;
import java.io.FilePermission;

public class PolicyServlet extends HttpServlet {
 
 public PolicyServlet() {
        super();
    }

 public void init(ServletConfig config)
            throws ServletException {
        super.init(config);
    }

 public void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        final ServletOutputStream out = response.getOutputStream();
 
        response.setContentType("text/html");
        out.println("<HTML><BODY bgcolor=\"#FFFFFF\">");
        out.println("Time stamp: " + new Date().toString());
        out.println( "<br>request.getRemoteUser = " + request.getRemoteUser() + "<br>");
        out.println("request.isUserInRole('sr_developer') = " + request.isUserInRole("sr_developer") + "<br>");
        out.println("request.getUserPrincipal = " + request.getUserPrincipal() + "<br>");

 Subject s = null;
        s = Subject.getSubject(AccessController.getContext());
 
        out.println("Subject in servlet " + s);
        out.println("<br>");
        final RuntimePermission rtPerm = new RuntimePermission("getClassLoader");
 try {
 Subject.doAsPrivileged(s, new PrivilegedAction() {
                public Object run() {
                    try {
                        AccessController.checkPermission(rtPerm);
                        out.println("<br>");
                        out.println("CheckPermission passed for permission: " + rtPerm+ " seeded in application policy");
                        out.println("<br>");
                    } catch (IOException e) {
                        e.printStackTrace();
                        printException ("IOException", e, out);
                    } catch (AccessControlException ace) {
                        ace.printStackTrace();
                        printException ("Accesscontrol Exception", ace, out);
                    }
                    return null;
                }
            }, null);

} catch (Throwable e) {
            e.printStackTrace();
            printException("application policy check failed", e, out);
        }
        out.println("</BODY>");
        out.println("</HTML>");
    }

 void printException(String msg, Throwable e, ServletOutputStream out) {
        Throwable t;
        try {
            StringWriter sw = new StringWriter();
            PrintWriter pw = new PrintWriter(sw, true);
            e.printStackTrace(pw);
 
            out.println("<p>" + msg + "<p>");
            out.println("<code>");
            out.println(sw.getBuffer().toString());
            t = e;
            /* Print the root cause */
            while ((t = t.getCause()) != null) {
                sw = new StringWriter();
                pw = new PrintWriter(sw, true);
                t.printStackTrace(pw);
 
                out.println("<hr>");
                out.println("<p>  Caused By ... </p>");
                out.println(sw.getBuffer().toString());
            }
            out.println("</code><p>");
        } catch (IOException ioe) {
            ioe.printStackTrace();
        }
    }
}

20.3.3.2 メソッドdoAsおよびdoAsPrivilegedの使用方法

Oracle Fusion Middlewareは、標準クラスjavax.security.auth.Subjectで、doAsメソッドとdoAsPrivilegedメソッドをサポートします。

ただし、これらのメソッドは、パフォーマンスが高く、監査機能も備えているため、oracle.security.jps.util.JpsSubjectクラスで使用することをお薦めします。


注意:

checkPermissiondoAsブロックの中でコールして、パーミッション・チェックのコールが失敗した場合、失敗した保護ドメインを表示するには、システム・プロパティjava.security.debug=access,failureを設定する必要があります。


20.3.3.3 メソッドcheckBulkAuthorizationの使用方法

メソッドcheckBulkAuthorizationでは、サブジェクトが1つ以上のリソース・アクションにアクセスできるかどうかを判断できます。具体的には、渡したリソースの中で、渡したサブジェクトに対してアクセスが許可されているリソース・アクションのセットを返します。

(Java SEアプリケーションで)このメソッドを呼び出す場合は次の点を確認してください。

  1. システム・プロパティjava.security.policyが、OPSSまたはOracle WebLogic Serverのポリシー・ファイルの場所に設定されています。

  2. ポリシー・プロバイダを明示的に設定するには、次に示すように、アプリケーションでまずメソッドsetPolicyからコールする必要があります

    java.security.Policy.setPolicy(new oracle.security.jps.internal.policystore.JavaPolicyProvider())
    
  3. アプリケーションでは、setPolicyをコールした後でcheckBulkAuthorization()がコールされます。

どのアプリケーションでも、checkBulkAuthorizationではコール元から次の情報が得られることが前提となっています。

  • ユーザーおよびエンタープライズ・ロールのプリンシパルが指定されたサブジェクト

  • 各リソースが属するストライプが含まれるリソースのリスト

リソース・パーミッションの使用の権限付与には、必須のリソース・タイプを含める必要があります。

checkBulkAuthorizationでも、アプリケーションを実行しているドメインに構成したポリシー・ストア・ストライプを、そのアプリケーションから認識できることが前提となっています。

checkBulkAuthorizationでは、ポリシー・ストアにリソースが存在している必要はありません。

20.3.3.4 メソッドgetGrantedResourcesの使用方法

メソッドgetGrantedResourcesには、実行時の認可問合せが用意されているので、特定のサブジェクトに付与されているリソース・アクションをこの問合せから得ることで、そのサブジェクトに付与されているすべてのリソースをフェッチできます。このメソッドでは、(直接またはパーミッション・セットから間接的に)リソース・タイプに関連付けられているパーミッションのみが返されます。また、このメソッドは、ポリシー・ストアがLDAPベースの場合にのみ使用できます。

20.3.4 クラスResourcePermission

パーミッション・クラスでは、リソースに対して権限受領者が実行できるアクションを制御する手段が提供されます。アプリケーションの設計段階では、アクション、ターゲット照合および暗黙の論理が実行時に想定どおりに機能するようにカスタムのパーミッション・クラスを使用して全面的に制御できます。その場合でも、サーバーのシステム・クラスパスでカスタムのパーミッション・クラスを指定し、必要に応じてそのパーミッション・クラスを使用可能にしてロードできるようにしておく必要があります。ただし、環境のシステム・クラス・パスの変更は困難で、環境によってはそのような変更ができないこともあります。

OPSSには、アプリケーションまたはシステム・リソースを保護するためにどのアプリケーション権限内でもパーミッション・クラスとして使用できるクラスoracle.security.jps.ResourcePermissionが用意されています。これにより、クラスResourcePermissionがそのままですぐに使用でき、サポート対象であればどのポリシー・プロバイダに格納されているアプリケーション権限でもパーミッションで容易に使用できるため、アプリケーション開発者がカスタムのパーミッション・クラスを作成する必要がなくなりました。このクラスはシステム・ポリシーでの使用を意図していません。アプリケーション・ポリシー専用として設計されています。

リソース・パーミッションの構成

ResourcePermissionクラスを使用するパーミッションは、リソース・パーミッションと呼ばれ、次のXMLサンプルで示している形式に基づいてリソース・タイプ、リソース名およびオプションのアクション・リストを指定します。

<permission>
  <class>oracle.security.jps.ResourcePermission</class>
  <name>resourceType=type,resourceName=name</name>
  <actions>character-separated-list-of-actions</actions>
</permission>

この指定では、タイプ名にエンコードしたリソース・タイプを定義する必要があります。リソース・タイプの情報は実行時には使用されませんが、リソース・パーミッションを正常に移行するにはリソース・タイプを定義しておく必要があります。また、リソース・タイプは、管理者によるリソースのモデル化とリソース使用の管理に役立ちます。

次のコードは、リソース・パーミッションの指定と対応する必須のリソース・タイプを示しています。

<permission>
  <class>oracle.security.jps.ResourcePermission</class>
  <name>resourceType=epm.calcmgr.permission,resourceName=EPM_Calc_Manager</name>
</permission>

<resource-types>
  <resource-type>
    <name>epm.calcmgr.permission</name>
    <display-name>CalcManager ResourceType</display-name>
    <description>Resourcetype for managing CalcManager grants</description>
    <provider-name></provider-name>
    <matcher-class>oracle.security.jps.ResourcePermission</matcher-class>
    <actions-delimiter>,</actions-delimiter>
    <actions></actions>
  </resource-type>
</resource-types>

<permission>
  <class>oracle.security.jps.ResourcePermission</class>
  <name>resourceType=oracle.bi.publisher.Reports,resourceName=GLReports</name>
  <actions>develop;schedule</actions>
</permission>

<resource-types>
  <resource-type>
    <name>oracle.bi.publisher.Reports</name>
    <display-name>BI Publisher Reports</display-name>
    <provider-name></provider-name>
    <matcher-class>oracle.security.jps.ResourcePermission</matcher-class>
    <actions-delimiter>;</actions-delimiter>
    <actions>view;develop;schedule</actions>
  </resource-type>
</resource-types>

リソース・パーミッションに関連付けられているリソース・タイプには、空のアクション・リストを指定してもかまいません。次の重要点がリソース・パーミッションに適用されます。

  • 名前は、次の形式に従う必要があります。

    resourceType=aType,resourceName=aName
    

    リソース・パーミッションのリソース・タイプを定義する必要があります。このリソース・タイプはResourcePermission.getType()メソッドで返されます。

  • 区切り文字付きのアクション・リストはオプションです。指定する場合は、関連するリソース・タイプで指定されているアクションから選択する必要があります。このリストはResourcePermission.getActions()メソッドで返されます。

    このリストの項目の区切り文字には、関連するリソース・タイプの<actions-delimiter>で指定されている文字を使用する必要があります。

  • パーミッションで使用するリソースの表示名は、ResourcePermission.getResourceName()メソッドで返されます。

  • リソース・パーミッションでは、ワイルドカードの使用はサポートされていません。

リソース・パーミッションの管理と確認

次のコード・スニペットは、リソース・パーミッションのインスタンス化およびリソース・パーミッションをプログラム的に確認する方法を示しています。このコード・スニペットは、「リソース・パーミッションの構成」で説明している構成例の1つに基づいています。

ResourcePermission rp = 
   new ResourcePermission("oracle.bi.publisher.Reports","GLReports","develop");
JpsAuth.checkPermission(rp);
 

実行時にリソース・パーミッションで次の4つの条件が満たされると、そのパーミッションは適切であると判断されます。

  • パーミッションがResourcePermisionクラスのインスタンスです。

  • リソース・タイプ名(最初の引数)がリソース・タイプの名前に一致します(大文字小文字の区別はなし)。

  • リソース名(2つ目の引数)がリソース・インスタンスの名前に完全に一致します。

  • アクション・リスト(3つ目の引数)が、リソース・タイプで指定されているアクションのカンマ区切りリストです。

リソース・タイプのマッチャ・クラスについて

リソース・タイプの作成時にオプションでマッチャ・クラスを指定できます。指定しなかった場合は、デフォルトのoracle.security.jps.ResourcePermissionが使用されます。

ただし、2つ以上のリソース・タイプで同一のリソース・マッチャ・クラスが共有される場合は、次のクラスのいずれかにする必要があります。

  • クラスoracle.security.jps.ResourcePermission.

  • 抽象クラスoracle.security.jps.AbstractTypedPermissionを拡張する具体クラス。これは次のサンプルでクラスMyAbstractTypedPermissionとして示されています。

    public class MyAbstractTypedPermission extends AbstractTypedPermission {
       private static final long serialVersionUID = 8665318227676708586L;
       public MyAbstractTypedPermission(String resourceType, 
                                        String resourceName,                                     String actions) {super(resourceType, resourceName, actions);
        }
    }
    
  • クラスoracle.security.jps.TypePermissionを実装し、クラスjava.security.Permissionを拡張するクラス。