| Oracle® Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護 12c (12.2.1.1.0) E77301-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護 12c (12.2.1.1.0) E77301-01 |
|
前 |
次 |
この章では、OPSSの認可モデルおよびポリシー・モデルについて説明し、Java EEおよびJava Authorization and Authentication Services (JAAS)の認可モデルと比較します。
この章の内容は次のとおりです。
OPSSの認可モデルおよびポリシー・モデルの詳細は、『Oracle Fusion Middleware Oracle Entitlements Server管理者ガイド』を参照してください。
ポリシーは、特定の場所からロードされたコードに付与されるパーミッションを指定します。JAASモデルは、オプションのプリンシパル・リストを指定できるようにすることで、ポリシーを拡張します。このようなポリシーにより、そのプリンシパルのいずれかによって実行される特定の場所からのコードにパーミッションが付与されます。
OPSSモデルはJAASモデルに基づいており、さらに、アプリケーションのポリシーおよびロールとシステム・ポリシーを使用できます。アプリケーション・ロールは、エンタープライズ・ユーザーおよびグループ(管理ロールなど)にマップできます。ポリシーでは、これらのロール、グループまたはユーザーにプリンシパルのいずれかにパーミッションを付与できます。
Java EEアプリケーションでは、そのアプリケーションが実行されているコンテナに認可を委任できる他、checkPermission、checkBulkAuthorization、getGrantedResourcesなどのメソッドへのコールによって独自の認可を実装できます。
次の各項では、Java EEおよびJAASの認可モデルの要点を説明します。
Java EE認可モデルではロール・メンバーシップを使用して、Enterprise JavaBeans (EJB)と、URLで参照されるWebリソースへのアクセスを制御します。ポリシーによってユーザーおよびロールにパーミッションが割り当てられ、コンテナによってポリシーが施行されます。
Java EEモデルでは、次のいずれかの方法で認可が実装されます。
宣言: ポリシーはデプロイメント・ディスクリプタに指定されます。コンテナは、デプロイメント・ディスクリプタからそれらのポリシーを読み取って施行します。認可を実施するための特別なアプリケーション・コードは必要ありません。
プログラム: ポリシーはアプリケーション・コードで処理されます。コードにより、特定のコード・セクションの実行に適したパーミッションをサブジェクトが持っているかどうかチェックされます。サブジェクトに適切なパーミッションがない場合、コードは例外をスローします。
表17-1は、各方法の長所と短所を示しています。
表17-1 Java EEモデルの認可の比較
| 認可のタイプ | 長所 | 短所 |
|---|---|---|
|
宣言 |
コーディングが不要です。デプロイメント・ディスクリプタのみを変更すればよいため、更新が簡単です。 |
認可はURLレベルまたはEJBメソッド・レベルで指定されます。 |
|
プログラム |
アプリケーション・コードで指定されます。きめ細かい認可を提供します。 |
コード変更や再コンパイルを伴うため、更新が簡単ではありません。 |
コンテナでは、次の各項で説明しているように、その中で実行されているアプリケーションに対して、宣言とプログラムという2つの方法で認可を提供できます。
宣言による認可では、URLベースのリソース(Javaサーブレットやページなど)およびEJBのメソッドへのアクセスを制御できます。
宣言による認可を構成するには、次の手順を実行します。
保護するリソースとそのリソースへのアクセス権を持つロールを(標準のデプロイメント・ディスクリプタで)指定します。あるいは、コード注釈を使用します。
ロールを(web.xmlファイルなどの固有のデプロイメント・ディスクリプタで)エンタープライズ・グループにマップします。
プログラムによる認可では、宣言による方法ではできないきめ細かい認可を実現しますが、isUserInRoleメソッド(Javaサーブレットの場合)またはisCallerInRoleメソッド(EJBの場合)をアプリケーション・コードからコールする必要があります(どちらのメソッドも標準のJava APIから使用可能です)。
これらのメソッドは、認可の決定に関してロール・メンバーシップに引き続き依存していますが、アクセス制御がEJBにもURLにも限定されないため、よりきめ細かく認可の決定を制御できます。
次の例は、isUserInRoleメソッドをコールするアプリケーションを示しています。この例では、アプリケーションのエンタープライズ・アーカイブ(EAR)ファイルにweb.xmlファイルとweblogic-application.xmlファイルが含まれており、これらのファイルには次のような指定が含まれていることを前提とします。
<!-- security roles in web.xml --> <security-role> <role-name>sr_developer</role-name> </security-role>
<!-- maaping of user to role in weblogic.application.xml --> <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>");
}
}
JAAS認可モデルではパーミッションを採用していますが、ロールも使用します。このモデルでは、ポリシーによって、パーミッションとサブジェクト(ロール、グループまたはユーザー)がバインドされ、さらに必要に応じてコードともバインドされます。addPrincipalsToAppRoleメソッドをコールして、ロールにパーミッションを付与します。パーミッションは静的メソッドAccessController.checkPermissionのコールによって評価されます。このモデルでは、リソースをきめ細かく制御できます。
ポリシーで、次のデータを指定します。
パーミッションが許可されたアプリケーション・ロールおよびエンタープライズ・グループ。
パーミッション(アプリケーション・ポリシー内)およびコードソース(システム・ポリシー内)。アプリケーション・ポリシーでは、アクセスを許可されるユーザーまたはグループのメンバーを定義します。システム・ポリシーでは、コードで実行できるアクションを定義します。
このモデルを使用してプログラミングする場合、アプリケーションの機密性の高い部分の前に、現在のユーザーまたはロールがコードに対して適切なパーミッションを持っているかどうかを判別するチェックを記述すると、ユーザーが適切なパーミッションを持っている場合にコードが実行されます。例については、第23.6.6項「サポートされているパーミッション・クラスの使用」を参照してください。
JAASおよびOPSS認可では、クラスを環境にロードして実行するときに、そのクラスで実行できる操作を制御することが基本になっています。
次の各項では、OPSS認可モデルについて説明します。
OPSSでは、セキュリティ・ストアでのリソース・カタログの指定およびランタイム・サポートに対応しています。
リソース・カタログを使用すると、次の操作が可能になります。
判読可能な用語でのポリシーおよび保護アーティファクトの記述。
アプリケーション・ソース・コードとは無関係なポリシーの定義および変更。
ポリシー、ロールおよびロール階層の参照および検索。
権限でのパーミッションのグループ化。
次のインタフェースはすべてoracle.security.jps.service.policystore.EntityManagerの下位インタフェースですが、これらを使用してリソース・カタログを管理します。
GrantManager - このインタフェースは、検索基準を使用して権限付与を問い合せたり、リソース・カタログ・アーティファクトの様々な組合せに適合する権限付与のリストを取得したり、プリンシパルに対してパーミッションを付与または取り消す場合に使用します。
PermissionSetManager - このインタフェースは、パーミッション権限の作成、変更および問合せを実行する場合に使用します。
ResourceManager - このインタフェースは、リソース・インスタンスの作成、削除および変更を実行する場合に使用します。
ResourceTypeManager - このインタフェースは、リソース・タイプの作成、削除、変更および問合せを実行する場合に使用します。
リソース・タイプ、リソース・インスタンス、アクションまたはパーミッション・セットを作成するには、次のようなコードを使用します。
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);
プログラムでポリシーをチェックする際には、次の点に留意してください。
デフォルトでは、認可の失敗がコンソールに表示されません。認可の失敗がコンソールに送信されるようにするには、システム変数jps.auth.debugを-Djps.auth.debug=trueと設定します。
特に、JpsAuth.checkPermissionの失敗がコンソールに送信されるようにするには、この変数を設定する必要があります。
ポリシー・プロバイダは、Java SEアプリケーションで明示的に設定する必要があります。
java.security.Policy.setPolicy(new oracle.security.jps.internal.policystore.JavaPolicyProvider())
Java SEアプリケーションにポリシー・プロバイダを明示的に設定しておかないと、ランタイム・メソッド(JpsAuth.checkPermissionなど)が不正確な値を返す場合があります。
次の各項では、プログラムでポリシーをチェックするいくつかのメソッドの使用方法について説明します。
Oracle Fusion Middlewareでは、java.security.AccessControllerクラスとoracle.security.jps.util.JpsAuthクラスでcheckPermissionメソッドをサポートしています。
JpsAuthクラスのcheckPermissionはデバッグ・サポートとパフォーマンスにおいて優れており、監査もサポートされるため、このクラスの使用をお薦めします。
静的なAccessController.checkPermissionメソッドは、デフォルトのアクセス制御コンテキスト(スレッド作成時に継承されるコンテキスト)を使用します。その他のコンテキストでパーミッションを確認するには、特定のAccessControlContextインスタンスでcheckPermissionメソッドのインスタンスをコールします。
次の表では、JAASモードの値に応じたcheckPermissionの動作について説明します。
表17-2 JAASモードに応じたcheckPermissionの動作
| JAASモード | checkPermissionの動作 |
|---|---|
|
|
有効なセキュリティ・ポリシーに基づいたコードソース・セキュリティを実施し、サブジェクトベースのセキュリティに対するプロビジョニングはありません。 |
|
|
|
|
|
NULLアクセス制御コンテキストを使用してサブジェクトベースのセキュリティを適用します。 |
|
|
パーミッションの評価時に、プリンシパルにかかわる権限付与のみが考慮されます(コードソースにかかわる権限付与は無視されます)。 |
|
注意: checkPermissionをdoAsブロックの中でコールして、パーミッション・チェックのコールが失敗した場合、失敗した保護ドメインを表示するには、システム・プロパティ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 -->
<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.doAsPrivilegedがJpsSubject.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();
}
}
}
Oracle Fusion Middlewareでは、javax.security.auth.Subjectクラスとoracle.security.jps.util.JpsSubjectクラスでdoAsメソッドとdoAsPrivilegedメソッドをサポートしています。
oracle.security.jps.util.JpsSubjectクラスはパフォーマンスに優れており、監査も備えているため、このクラスの使用をお薦めします。
|
注意: checkPermissionをdoAsブロックの中でコールして、パーミッション・チェックのコールが失敗した場合、失敗した保護ドメインを表示するには、システム・プロパティjava.security.debug=access,failureを設定する必要があります。 |
checkBulkAuthorizationメソッドでは、サブジェクトが1つ以上のリソース・アクションにアクセスできるかどうかを判断します。このメソッドは、サブジェクトがリソースに対して認可されている一連のリソース・アクションを返します。リソースを使用する権限付与には、リソース・タイプを指定する必要があります。
このメソッドをコールする場合は、必ず次のようにします。
システム・プロパティjava.security.policyをOracle WebLogic Serverポリシー・ファイルの場所に設定しておきます。
アプリケーションでは、setPolicyの後にcheckBulkAuthorizationをコールします。
java.security.Policy.setPolicy(new oracle.security.jps.internal.policystore.JavaPolicyProvider())
checkBulkAuthorizationでは、次のことを前提としています。
コール元は、ユーザーおよびエンタープライズ・ロールのプリンシパルが指定されたサブジェクトと、各リソースが属するストライプが含まれるリソースのリストを提供できます。
アプリケーションは、そのアプリケーションが実行されているドメインで構成されたアプリケーション・ストライプにアクセスできます。
getGrantedResourcesメソッドは、指定のサブジェクトに付与されているリソース・アクションを返すことで、そのサブジェクトに付与されているリソースをすべてフェッチする実行時の認可問合せです。このメソッドは、リソース・タイプに関連付けられているパーミッションのみを返し、LDAPセキュリティ・ストアの場合のみ使用できます。
パーミッション・クラスでは、リソースに対して権限受領者が実行できるアクションを制御する手段が提供されます。カスタムのパーミッション・クラスを使用してアクション、ターゲット照合およびロジックを全面的に制御する場合でも、実行時に予期したとおりに機能するには、カスタムのパーミッション・クラスを使用可能にして必要に応じてロードできるようにサーバーのシステム・クラスパスに指定する必要があります。ただし、環境のシステム・クラス・パスの変更は困難で、環境によってはそのような変更ができないこともあります。
OPSSには、アプリケーションまたはシステム・リソースを保護するためにアプリケーション権限内でパーミッション・クラスとして使用するoracle.security.jps.ResourcePermissionクラスがあります。この方法では、カスタムのパーミッション・クラスを作成する必要がなくなるため、サポートされているポリシー・プロバイダに格納されているアプリケーション権限内のパーミッションでそのクラスをすぐに使用できます。このクラスはシステム・ポリシーで使用せず、アプリケーション・ポリシーでのみ使用してください。
リソース・パーミッションの構成
ResourcePermissionクラスを使用するパーミッションは、リソース・パーミッションと呼ばれ、リソース・タイプ、リソース名およびオプションのアクション・リストを指定します。
<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メソッドは、パーミッションで使用されるリソースの表示名を返します。
リソース・パーミッションでは、ワイルドカード文字がサポートされていません。
リソース・パーミッションの管理と確認
次の行は、リソース・パーミッションの作成方法とそのチェック方法を示しています。
ResourcePermission rp =
new ResourcePermission("oracle.bi.publisher.Reports","GLReps","develop");
JpsAuth.checkPermission(rp);
リソース・パーミッションによって次の条件が満たされると、パーミッション・チェックは成功です。
パーミッションがResourcePermisionクラスのインスタンスです。
リソース・タイプ名がリソース・タイプの名前に一致します(大文字小文字の区別はなし)。
リソース名がリソース・インスタンスの名前に完全に一致します。
アクション・リストが、リソース・タイプで指定されているアクションのカンマ区切りリストです。
リソース・タイプのクラスについて
リソース・タイプの作成時に、必要に応じてクラスを指定できます。指定しない場合は、oracle.security.jps.ResourcePermissionクラスにデフォルト設定されます。
2つ以上のリソース・タイプで1つのクラスを共有する場合は、そのクラスを次のいずれかにする必要があります。
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クラスを拡張するクラス。
