Monitoring and performance tuning are essential to the administration of the Oracle Entitlements Server components used by your applications. You monitor components to ensure they are running smoothly and tune the performance of Oracle Entitlements Server components to achieve optimal performance and throughput based on the current system resources and traffic load.
This chapter describes how to configure and deploy Oracle Entitlements Server to maximize performance and throughput and covers monitoring, analyzing, and tuning the components that are used by your applications. This chapter contains the following sections:
Section 16.2, "Oracle Entitlements Server Performance Planning"
Section 16.3, "Performance Tuning Considerations for Oracle Entitlements Server"
This chapter assumes that you are familiar with the key concepts and components in an Oracle Entitlements Server deployment. The following sections will provide the basis for some of the performance-related topics in this chapter:
Section 1.2, "Overview of Oracle Entitlements Server" introduction and Figure 1-1, "Components of Oracle Entitlements Server"
Section 1.3.1, "Understanding the Policy Administration Point"
Section 1.3.2, "Understanding the Policy Decision Point and the Policy Enforcement Point"
Section 1.4, "Understanding How Oracle Entitlements Server Processes Authorization Policies"
Performance tuning usually involves a series of trade-offs. If you experience bottlenecks and determine what the causes are, you may need to modify performance in some other areas to achieve the expected results. If you have a clearly defined plan for achieving your performance objectives, the decision on what to trade for higher performance is easier because you have identified the most important areas.
To maximize the performance capabilities of your applications, you must build performance and scalability into your design. The performance plan addresses the current performance requirements, the existing issues (such as bottlenecks or insufficient hardware resources), and any anticipated variances in load, users or processes. The performance plan also addresses how the components scale during peak usage without impacting performance.
The following sections of this chapter discuss the steps to create a plan to tune your application environment and optimize performance:
Step 1: Define Your Performance Objectives and Requirements
Step 2: Design Authorization for Applications
Before you can begin performance tuning your applications, you must first identify the performance objectives you want to achieve.
To understand what your performance objectives are, complete the following steps:
Understanding performance constraints and their impacts ensures that you set realistic performance objectives for your application environment, such as response times, throughput, and load on specific hardware. Performance objectives are limited by constraints, such as:
The configuration of hardware and software such as CPU type, disk size, disk speed, and sufficient memory.
The type of hardware and software configuration that is required to meet application needs adequately. The process of determining the needs is called capacity planning, and there is no single formula for determining your hardware requirements.
The system performance goals. Capacity planning requires an assessment of your system performance goals and an understanding of your application. Capacity planning for server hardware focuses on maximum performance requirements.
For more information on capacity planning, see the "Capacity Planning and Using Clusters and High Availability Features" chapter in Oracle Fusion Middleware Performance and Tuning Guide.
The configuration of high availability architecture to address peak usage and response times.
For more information on implementing high availability features in Oracle Entitlements Server see the "Configuring High Availability for Oracle Entitlements Server" chapter in High Availability Guide.
The ability to interoperate between domains, use legacy systems, support legacy data.
The development, implementation, and maintenance costs.
Before you begin to deploy and tune your application for high availability (HA) and disaster recovery (DR), it is important to clearly define the operational environment. The operational environment is determined by high-level constraints and requirements such as:
Deployment architecture
End-to-end deployment and operational security requirements
Hardware resources
High availability (HA) and disaster recovery (DR) requirements
Whether you are designing a new system or maintaining an existing system, set specific performance goals so that you know how and what to optimize. To determine your performance objectives, you must understand the application deployed and the environmental constraints placed on the system.
Gather information about the levels of authorization activity that application are expected to meet, such as:
Anticipated number of users per business application (total and concurrent)
Number of concurrent user authorization requests per application
Total number of applications being managed
Amount of authorization data (organized by application)
High availability and disaster recovery choices and possible impact on authorization system performance
Capacity planning based on target CPU utilization
With clearly defined performance goals and performance expectations and based on sizing guidelines and performance data, you can readily conduct and determine if performance tuning has been successful. Success depends on the functional objectives you have established with the user community, your ability to measure whether the criteria are being met, and your ability to take corrective action to overcome any exceptions.
This section contains the following topics:
Oracle Entitlements Server strives to provide a policy model which closely represents common business, application and service flows.
A simple one to one mapping of individual business roles and privileges often leads to policy bloat and more importantly does not capture the underlying process and object relationships. Oracle Entitlements Server uses hierarchy as basis for policy modeling. This facilitates grouping of objects based on their relationships. Furthermore it allows attribute and privilege inheritance. The Oracle Entitlements Server hierarchical resource, role, policy, and policy domain hierarchies structures allow for exponential reduction in size and complexity of policies. Oracle Entitlements Server supports Attribute-Based Access Control (ABAC), Role-based Access Control (NIST RBAC), and ERBAC (Enterprise RBAC) policy models. Based on business needs either of the policy models can be used or several of them can be used in combination.
Business process and objects often tend to be hierarchical. For example, a loan approval process consists of multiple subprocesses and some of these subprocess might constitute additional finer grained processes. In a similar way a web application can consist of multiple web pages, each page has different sections and each section has different pieces of information.
Role-based Access Control (RBAC) models use roles to model enterprise security. For RBAC, permission (or privilege) is a trivial extension of role. Roles can be divided into three categories:
Enterprise Wide Static Roles: Users are granted these roles irrespective of what they are trying to do. For example, an Employee role can be a static assignment because it is common across enterprise. These roles are best stored in an LDAP or some other enterprise wide identity store. These roles are normally assigned at the time of authentication and are generally valid until session expiration.
Application Specific Static Roles: These are static role assignments which are specific to a subset of enterprise applications. A user or an enterprise role is granted different roles based on the applications they are trying to access. Typically, it is recommended to grant the application role to the enterprise role as best practice. The user number normally is extremely large in the enterprise. It is hardly managed and might affect performance.
Application Specific Dynamic Roles: These are dynamically or conditionally assigned application roles. They are assigned on an as-needed basis depending on the action initiated by the user. For example, the Fund Manager role should be granted to a person only on certain funds. They come into existence when an authorization request is made and they are destroyed once a decision is computed. As discussed previously Oracle Entitlements Server provides sophisticated facilities to accurately control role assignments based on the context.
As seen above, enterprise wide static roles are easy to compute, but they are rigid. Dynamic roles need to be computed for every authorization request but they are very flexible and dynamic. However due to locality of reference, these roles can often be fetched from the cache and do not require full computation. The static/dynamic nature and scope of roles are deciding factors in choosing the correct role type. Depending on changing requirements, an enterprise wide role can be converted to an Application specific dynamic role or vice versa.
This type of interoperability is possible because Oracle Entitlements Server is based on the NIST RBAC and ABAC standards.
Attributes are the basis for the ABAC (Attribute Based Access Control) model. Oracle Entitlements Server supports a variety of attributes (for example user, enterprise role attributes are supported by OES via PIP; resource attributes are supported by OES directly; application role attributes are not supported); in addition, custom attributes can be defined for special needs. ABAC has heavy reliance of conditions, essentially all authorization decisions are made by evaluating expressions based on these attributes. As an authorization model ABAC offers more flexibility than RBAC because it heavily relies on dynamic computation. However, this comes at the cost of being able to perform audits based on static policy data. Also, the added complexity means that ABAC models are more computation-intensive than their RBAC counterparts.
Oracle Entitlements Server lays out a policy structure to help map business security requirements into raw ABAC models. Subjects (Users and Enterprise Role), Resources, and attributes are the most commonly used elements in ABAC polices. The Oracle Entitlements Server UI creates an easy to use abstraction around these objects to simplify the construction of policies. Oracle Entitlements Server also supports Resource, Attribute and Policy inheritance which allow policies to be placed strategically so that they will be able to control large number of Users and Resources.
For more information on the recommended design techniques for the different Oracle Entitlements Server components, see Developer's Guide for Oracle Entitlements Server.
The previous section presented various standard authorization models like RBAC, Java2 ABAC, and so on that are supported by Oracle Entitlements Server for designing the application authorization. The following are the key areas to consider to design a highly scalable authorization subsystem.
The first one is to choose the right authorization model that is inherently suited for the application usage pattern. For example, if you want to build a hospital information application where the application usage pattern is well defined through functional entities like nurse, doctor, and so on, then it is natural that this application can readily benefit by uptaking the RBAC based authorization design pattern.
The second one is that the aspect of the design is to decide the growth factor of the various elements of the authorization subsystem. Typically an authorization system can be thought of as a 3-dimensional space where the application consumer (identified as End User, Group or an application role), the application resources and the operations that are protected and the authorization policy that binds the application user & (allowed resource + operations) with additional rules become the 3 dimensions. In a good scalable and performant authorization subsystem, it is very important to keep effect of the growth in the dimensions of the authorization space as much constant as possible on authorization subsystem. For example:
If in an application the total number of protected resources is continuously growing like the growth in total number expense report database records along with the total number users for data security
If the total number of application roles are growing as there are new kinds, end-user groupings need to be handled for functional security
In these scenarios it is very important the design of the authorization subsystem be tolerant to handle the growth through some intelligent authorization patterns like inheritable policies on hierarchical resources, attribute based policies and the application roles policies with attribute based conditions to handle types of user populations. The important point is the growth in the authorization subsystem is based on the application business requirements for dealing with a new kind's authorization requirements rather than dealing with the growth of the dimension of the authorization scope.
The third item is dealing with the new challenges of the modern cloud based applications that needs to make authorization decisions not only on the conventional static information about the application user but also needs to use the user's dynamic contextual information. This requires adaptation of application authorization modeling and design to combine multiple authorization standards to deal with new requirements like using RBAC and ABAC together, and so on.
The fourth item is designing SAAS applications that are deployed on cloud and also need to provide services to multiple customers. This requires designing applications to support multitenancy and data isolation not only in the business data but also the security data. This will bring much more stringent requirements and restrictions on the authorization subsystem to be more compact, efficient and resilient with the growth number of tenants.
Once you have installed and configured Oracle Entitlement Server, you want the best possible performance. This section provides guidelines for Oracle Entitlement Server administrators on optimizing Oracle Entitlement Server performance. This section includes the following topics:
The tuning optimizations for these Oracle Entitlements Server components are described in the following sections.
The first component that needs to be tuned from the overall performance tuning is the OES policy store. Tuning the policy store involves the tuning of the underlying database and the TopLink Java Persistence API (JPA) provider. The Java Persistence API is a specification for persistence in Java EE and Java SE applications. The following sections provides information about specific tuning aspects as a part of policy store tuning.
Table 16-1 explains the various Oracle Database system parameters that need to be tuned with their optimal values and provides example values. You may adjust the values based on your application needs.
Table 16-1 Oracle Database System Parameters Tuning
| Parameter Name | Description | Default Value | Recommended Value |
|---|---|---|---|
|
processes |
PROCESSES specifies the maximum number of operating system the user processes that can simultaneously connect to Oracle |
40 |
1500 |
|
sga_target |
SGA_TARGET specifies the total size of all SGA components. |
0 (SGA autotuning is disabled for DEFERRED mode and autotuning requests, but allowed for IMMEDIATE mode autotuning requests) |
3221225472 (3GB) |
|
audit_trail |
AUDIT_TRAIL enables or disables database auditing. |
None |
None |
|
open_cursors |
OPEN_CURSORS specifies the maximum number of open cursors (handles to private SQL areas) a session can have at once |
50 |
500 |
|
pga_aggregate_target |
PGA_AGGREGATE_TARGET specifies the target aggregate PGA memory available to all server processes attached to the instance |
10 MB or 20% of the size of the SGA, whichever is greater |
1610612736 (1.5GB) |
|
nls_sort |
NLS_SORT specifies the collating sequence for ORDER BY queries. If the value is BINARY, then the collating sequence for ORDER BY queries is based on the numeric value of characters (a binary sort that requires less system overhead). If the value is a named linguistic sort, sorting is based on the order of the defined linguistic sort. Most (but not all) languages supported by the NLS_LANGUAGE parameter also support a linguistic sort with the same name. |
BINARY |
|
|
filesystemio_options |
FILESYSTEMIO_OPTIONS specifies I/O operations for file system files. |
SETALL |
|
|
fast_start_mttr_target |
FAST_START_MTTR_TARGET enables you to specify the number of seconds the database takes to perform crash recovery of a single instance |
0 |
3600 |
|
db_securefile |
DB_SECUREFILE specifies whether or not to treat LOB files as Secure Files. |
PERMITTED |
ALWAYS |
|
session_cached_cursors |
SESSION_CACHED_CURSORS specifies the number of session cursors to cache |
0 |
500 |
|
plsql_code_type |
PLSQL_CODE_TYPE specifies the compilation mode for PL/SQL library units. |
INTERPRETED |
NATIVE |
|
"_b_tree_bitmap_plans" |
False |
||
|
Memory_target |
MEMORY_TARGET is a database initialization parameter (introduced in Oracle 11g) that can be used for automatic PGA and SGA memory sizing. |
0 |
0 |
For more information about the Oracle Database redo logs, see Oracle Database Reference.
The following SQL script could be used for setting the system parameters. The SQL script needs to be run as a DB user with the SYSDBA role.
ALTER SYSTEM SET processes = 1500 SCOPE = spfile; ALTER SYSTEM SET sga_target = 3221225472 SCOPE = spfile; ALTER SYSTEM SET audit_trail = NONE SCOPE = spfile; ALTER SYSTEM SET open_cursors = 500 SCOPE = spfile; ALTER SYSTEM SET pga_aggregate_target = 1610612736 SCOPE = spfile; ALTER SYSTEM SET nls_sort = BINARY SCOPE = spfile; ALTER SYSTEM SET filesystemio_options = SETALL SCOPE = spfile; ALTER SYSTEM SET fast_start_mttr_target = 3600 SCOPE = spfile; ALTER SYSTEM SET db_securefile = ALWAYS SCOPE = spfile; ALTER SYSTEM SET session_cached_cursors = 500 SCOPE = spfile; ALTER SYSTEM SET plsql_code_type = NATIVE SCOPE = spfile; ALTER SYSTEM SET "_b_tree_bitmap_plans" = FALSE scope=spfile ALTER SYSTEM SET memory_target=0 SCOPE = SPFILE;
Also make sure the kernel.shmall, kernel.shmmax, kernel.sem, and fs.file-max are set at optimal values (all kernel level parameter can be tuned and obtained from /etc/sysctl.conf).
All of the following operations for managing REDO logs and UNDO change logs need to be performed as a DB user with the SYSDBA role.
Increase Allocated Disk Space for Redo Log Files
It is recommended that you use three redo log files where each file is at least 4 GB in size. After creating the new REDO log files, the existing or old REDO log files (groups) need to be removed.
Run the following SQL command to add new redo log groups. Make sure the proper file path is set according to your environment.
alter database add logfile ('<oradata directory>/orcl/redo04.log') SIZE 4G;
alter database add logfile ('<oradata directory>/orcl/redo05.log') SIZE 4G;
alter database add logfile ('<oradata directory>/orcl/redo06.log') SIZE 4G;
Run the following SQL command to drop old redo log files (groups). Please follow the instructions below.
Exec SQL: SELECT group#, member FROM V$LOGFILE;
For the group# not for the members you added, you could drop them by:
ALTER DATABASE DROP LOGFILE GROUP <group#>;
If you are dropping an active Log group, you need to force a log switch as below:
ALTER SYSTEM SWITCH LOGFILE;
For more information about the Oracle Database redo log, refer to the "Managing the Redo Log" chapter of the Oracle Database Administrator's Guide.
Increase Disk Space Allocated for UNDO Tablespace
It is recommended that the UNDO tablespace be 20 GB in size.
Run the following SQL command to resize UNDO tablespace. Make sure the proper file path is set according to your environment.
ALTER DATABASE DATAFILE '<oradata directory>/orcl/undotbs01.dbf' RESIZE 20G;
For more information about Oracle Database UNDO, refer to the "Managing Undo" chapter of the Oracle Database Administrator's Guide.
Tune Tablespaces During Repository Creation
The OES DB schema is created via RCU (Repository Creation Utility). While creating a database schema using RCU:
Allocate sufficient large initial disk spaces for OES tablespaces for optimal performances. Allocate 6 GB files for IAS_OPSS and IAS_TEMP tablespaces.
If many large applications will be managed in policy store, allocate a large tablespace size, 40 GB for IAS_OPSS tablespace, 15 GB for IAS_TEMP tablespace
If many large applications will be added to policy store, it is recommended that you mark the tablespace increment as 1 GB, instead of 100 MB, to avoid continuous extending tablespace when it is full.
Steps using RCU to tune tablespaces during schema creation are provided below.
In the Map Tablespaces screen of RCU, click the Manage Tablespaces button to modify existing tablespaces.
Select the IAS_OPSS or IAS_TEMP tablespace on the left-hand portion of the screen, and edit the fields as described in Table 16-2.
To modify or edit a datafile, select the icon next to the datafile you want to edit, then click the icon with the pencil.
The Edit Datafile screen appears.
Provide the information described in the following table:
Table 16-3 Specifying the Size of a Datafile
| Field | Description |
|---|---|
|
Size |
Allocate sufficient large initial disk spaces for OES tablespaces for optimal performances. Allocate 6 GB files for |
|
Automatically extend datafile when full (AUTOEXTEND) |
Select Automatically extend datafile when full (AUTOEXTEND) to automatically extend the size of your datafile when it becomes full. In the Increment field, specify 1 GB by which your datafile should be increased each time it becomes full. Use the drop-down list to specify gigabytes (GB). If many large applications will be added to the policy store, it is recommended that you mark the tablespace increment as 1 GB instead of 100 MB to avoid continuous extending tablespace when it is full. |
|
Maximum Size |
Unlimited |
Tune Tablespaces If DB Instance Already Exists
If the DB instance already exists, add more disk space by running the ALTER TABLESPACE command as a DB user with the SYSDBA role. For example:
alter tablespace R2_IAS_OPSS ADD DATAFILE '<oradata directory>/orcl/R2_ias_opss2.dbf' SIZE 20 G AUTOEXTEND ON; alter tablespace R2_IAS_TEMP ADD TEMPFILE ''<oradata directory>/orcl/R2_iastemp2.dbf' SIZE 10 G AUTOEXTEND ON;
The above steps take care of all of the required OES DB schema tuning. The only ongoing tuning that needs to be performed from time to time, as the policy data has been stored in the database, is gathering the database statistics as the OES DB scheme user.
The schema statistics should not be gathered for the column JPS_DN.PARENTDN. Gathering a histogram on this column will impact query performance. To disable histogram, run the following SQL script:
EXECUTE dbms_stats.delete_column_stats(ownname=>'<SCHEMA_NAME>', tabname=>'JPS_DN', colname=>'PARENTDN', col_stat_type=>'HISTOGRAM');
EXECUTE dbms_stats.set_table_prefs('<SCHEMA_NAME>', 'JPS_DN','METHOD_OPT', 'FOR ALL COLUMNS SIZE AUTO, FOR COLUMNS SIZE 1 PARENTDN');
Using your schema name, run the DBMS_STATS procedure to gather the latest statistics as follows:
Execute DBMS_STATS.gather_schema_stats('<SCHEMA_NAME>',DBMS_STATS.AUTO_SAMPLE_SIZE,no_invalidate=>FALSE)
You can automate this by defining a database job to run the procedure with required frequency. This collection needs to be performed after a large policy data migration into store.
The following SQL example creates a database job called OPSS_AUTO_STATISTICS, which will be executed at 0:00 every Sunday morning. The database job needs to be added by a user with SYSDBA privileges.
BEGIN
SYS.DBMS_SCHEDULER.CREATE_JOB (
job_name => '"SYS"."OPSS_AUTO_STATISTICS"',
job_type => 'PLSQL_BLOCK',
job_action => 'Execute
DBMS_STATS.gather_schema_stats(''<SCHEMA>'',DBMS_STATS.AUTO_SAMPLE_SIZE,no_invalidate=>FALSE);',
number_of_arguments => 0,
start_date => NULL,
repeat_interval => 'FREQ=WEEKLY;BYDAY=SUN;BYHOUR=0;BYMINUTE=0;BYSECOND=0',
end_date => NULL,
job_class => '"SYS"."DEFAULT_JOB_CLASS"',
enabled => FALSE,
auto_drop => FALSE,
comments => '',
credential_name => NULL,
destination_name => NULL);
SYS.DBMS_SCHEDULER.SET_ATTRIBUTE(
name => '"SYS"."OPSS_AUTO_STATISTICS"',
attribute => 'logging_level', value => DBMS_SCHEDULER.LOGGING_OFF);
SYS.DBMS_SCHEDULER.enable(
name => '"SYS"."OPSS_AUTO_STATISTICS"');
END;
/
Refer to Section 13.3.2 "When to Gather Statistics" in the Oracle Database Performance Tuning Guide.
Oracle Entitlements Server uses EclipseLink as the JPA (Java Persistence API) implementation for database operations. Some EclipseLink tuning parameters (Table 16-4) could be set into the jps-config.xml file.
| Property | Description | Default |
|---|---|---|
|
eclipselink.jdbc.connection_pool.default.max |
The maximum number of read connection in the internal connection pool |
32 |
|
eclipselink.jdbc.connection_pool.default.min |
The minimum number of read connection in the internal connection pool |
32 |
The properties could be overwritten by setting the DB policy store service instance for Oracle Entitlements Server Admin, or a PDP service in controlled-pull mode, as shown below.
<propertySet name="props.db.1">
<property name="jdbc.url"
value="jdbc:oracle:thin:@<HOST>:<PORT>/<SID>"/>
<property name="oracle.security.jps.farm.name" value="cn=my_domain"/>
<property name="server.type" value="DB_ORACLE"/>
… …
<property name=" eclipselink.jdbc.connection_pool.default.min" value="16"/>
<property name=" eclipselink.jdbc.connection_pool.default.min" value="64"/>
</propertySet>
… …
<serviceInstance name="policystore.db" provider="policystore.provider">
<property name="policystore.type" value="DB_ORACLE"/>
<propertySetRef ref="props.db.1"/>
</serviceInstance>
For more EclipseLink properties, see the PersistenceUnitProperties class in the EclipseLink API Reference.
To have better performance of large data operations, like migration and distribution, tune the JVM parameters as described in this section.
WLST (WebLogic Scripting Tool) is an Oracle Middleware command-line scripting interface. It is used for Oracle Entitlements Server for some management work, including migration of security store. For migrating large applications, you need to tune JVM parameters for the WLST tool for the Java memory size, as shown below:
Edit file MIDDLEWARE_HOME/wlserver_10.3/common/bin/wlst.sh.
Specify JAVA_HOME to JDK with version 1.6.0_31 or higher and add MEM_ARGS as below:
MEM_ARGS="-Xms6144m -Xmx6144m -Xmn1900m -XX:+UseParallelGC -XX:PermSize=128m -XX:MaxPermSize=1024m"
Note that the required heap size parameter (ms, mx, mn) could be based on the size of the application you will migrate.
The OES Admin Server needs to be tuned for optimized performance for the snapshot generation of application during policy distribution and also for all of the OES management UI CRUD operations as given below.
1. Use JDK version 1.6.0_31 or higher.
2. JDK memory size tuning. Large memory is required on the Admin Server to generate the application policy snapshot, especially for a large application policy. The JDK could be chosen while configuring the WebLogic domain for OES Administration. On the Configure Server Start Mode and JDK screen, choose from available JDKs if you have version is 1.6.0_31 or higher, or click "Other JDK" to choose one.
If you need to manually edit file the DOMAIN_HOME/bin/startWeblogic.sh script to set the JAVA_HOME property. Edit file the DOMAIN_HOME/bin/startWeblogic.sh script as shown below:
JAVA_HOME="/home/user/jdk1.6.0_31"
MEM_ARGS="-Xms6144m -Xmx6144m -Xmn1900m -XX:PermSize=128m -XX:MaxPermSize=1024m"
before the line "${JAVA_HOME}/bin/java ${JAVA_VM} -version"
When the OES Security Module is configured for controlled pull mode, it has two main functionalities
It acts as a PDP and/or PEP; it receives an authorization request, makes a decision and enforces the decision.
It calls the Policy Distribution component periodically to make configured policies and policy data available for evaluation.
So tuning the OES Security Module will focus on two parts, one is to ensure high throughput of authorization request processing and another is to distribute policy efficiently.
Policy data affects performance of the security module. The number of functions, attributes, roles, resources, and policies have a great influence on the authorization throughput, distribution time and memory size needed for Security Module.
In this section, the following policy data sample will be used in the examples. Your applications may vary in size and modeling.
Application Name: myapp oracle.security.jps.ldap.root.name: cn=jpsroot oracle.security.jps.farm.name: cn=base_domain
The policy data shown below is only an example. Policy artifacts numbers should be from your policy modeling.
The information shown below cannot be tuned on the SM side. The data could be used to estimate required memory on the SM.
Table 16-5 Security Module Tuning Attributes
| Item | Number | Comment | Query SQL |
|---|---|---|---|
|
Resource Type |
1 |
||
|
Attribute definition |
17 |
||
|
Function definition |
269 |
select count(*) from jps_dn where parentdn like 'cn=jpsroot,cn=jpscontext,cn=base_domain,cn=myapp,%cn=functions,'; |
|
|
Application Role |
0 |
No application role is created. WebLogic Server's roles and principals are used. |
|
|
Grantee |
5351 |
The principals of the policy are stored as grantee. It seems one policy for one principal for both 2 applications. |
select count(*) from jps_dn where parentdn like 'cn=jpsroot,cn=jpscontext,cn=base_domain,cn=myapp,cn=jaas policy,cn=grantees,'; |
|
Permission |
1772 |
The resource actions pairs used in policies |
select count(*) from jps_dn where parentdn like 'cn=jpsroot,cn=jpscontext,cn=base_domain,cn=myapp,cn=jaas policy,cn=permissions,'; |
|
Resource |
3173 |
select count(*) from jps_dn where parentdn like 'cn=jpsroot,cn=jpscontext,cn=base_domain,cn=myapp,%cn=resources,'; |
|
|
Entitlement |
1806 |
select count(*) from jps_dn where parentdn like 'cn=jpsroot,cn=jpscontext,cn=base_domain,cn=myapp,%cn=permission sets,'; |
|
|
Policy |
5351 |
select count(*) from jps_dn where parentdn like 'cn=jpsroot,cn=jpscontext,cn=base_domain,cn=myapp,%cn=policies,'; |
|
|
Rule |
5351 |
select count(*) from jps_dn where parentdn like 'cn=jpsroot,cn=jpscontext,cn=base_domain,cn=myapp,%cn=rules,'; |
|
|
Attributes |
1,484,356 |
Attributes of above entries |
select count(*) from jps_attrs where jps_dn_entryid in (select entryid from jps_dn where parentdn like 'cn=jpsroot,cn=jpscontext,cn=base_domain,cn=myapp,%'); |
|
assignee attributes |
1,220,877 |
Attribute for policy assignments |
select count(*) from ct_9_1 where jps_dn_entryid in (select entryid from jps_dn where parentdn like 'cn=jpsroot,cn=jpscontext,cn=base_domain,cn=myapp,cn=jaas policy,cn=permissions,'); |
Policy distribution is the process to obtain policy data from a database policy store, write policy data to a local encrypted XML policy file, and switch between two copies of the runtime policy cache.
OES Security Module uses memory in following aspects:
To hold policy data in memory as cache. Refer to "Final Formula" for more information. The policy cache data will always be in memory after Security Module startup. The size is statically predictable based on policy data. There could be multiple application policies bound to single Security Module, so the memory size need to multiply bound application number.
For authorization process memory usage. This part is dynamic, and affected by request frequency. The memory could be GCed after authorization process is done. There is no analysis on this part. The given buffer = 1.5 * runtime cache.
For policy distribution. Policy distribution is the process to get policy data from a database policy store, write policy data to a local encrypted XML policy file, and switch between two copies of the runtime policy cache.
Flush distribution will occur for the first time, or there will be too many changes that are not picked by the Security Module
Incremental distribution will occur when PDP already had the policy distributed, and small size changes occurred in the policy store
Regular authorization memory requirement is computed as (1) + (2) = 2.5* runtime cache.
Initialization time to get flush policy distribution is computed as [[Runtime Cache] * ( 2 + 3.67 * App Count) * 1.2 * 1.33] + 256 MB
As flush distribution requires more memory, use the [[Runtime Cache] * ( 2 + 3.67 * App Count) * 1.2 * 1.33] + 256 MB formula to calculate the recommended memory size for the PDP.
App Count is the applications count bound to the Security Module instance.
Runtime Policy Cache Memory Sizing Based on Policy Artifacts
Create OES authorization policy artifacts based on business security requirements. The policy artifacts will be stored in the database security store (1), migrated between different type of security stores (XML file-based or RDBMS based) (2), managed and distributed by you via an admin server (3), and loaded in memory as a policy cache consumed by an OES Security Module (4).
Policy artifacts are listed below.
| Policy Artifact | Description |
|---|---|
|
Resource Type |
A Resource Type represents the type of a secured object. Metadata in small size. |
|
Resource |
A Resource is a protected component or object to which access is granted or denied. The number could be large. |
|
Resource attributes |
Attribute values assigned to resource. |
|
Function Definition |
Metadata for built-in functions, and custom plugin function. Small size data. |
|
Attribute Definition |
Metadata for attribute declaration. Small size data. |
|
Application Role |
|
|
Application Role member |
|
|
Role Mapping Policy |
A policy to assign application role(s) to user, group, on given resource(s), and given condition |
|
Entitlement |
A small set of resources and the associated actions needed to perform a task. |
|
Principal |
User, group, or application role used in a policy. The number is large, and could vary from different customers application. It is subset of total user/group in ID store. |
|
Permission |
Resource and associated actions used in a policy. The number is large, and could vary from different applications. |
|
Assignment |
Total number of resource * principals of all of the policy. |
|
Authorization Policy |
Authorization policy The number is large. The size of each policy could vary, as it might have complex condition, and multiple obligations. For complex policy, a factor is needed for sizing. |
Runtime Policy Cache is a memory representation of OES authorization policy. The size is made based on policy artifacts numbers.
Final Formula:
0.54K * Assignment Number +
0.41K * Permission Number +
0.72K * Grantee Number +
0.044K * Resource Number * Resource Attribute Factor +
0.85K * Policy Number * Policy Factor
0.122K * Total application role memberships
Resource Attribute Factor defaults to 1 for the case without resource attribute.
Policy Factor defaults to 1 for the case policy without condition and obligations
Table 16-5 provides more information on the Security Module tuning attributes.
Edit the DOMAIN_HOME/bin/startWeblogic.sh script with all the JVM parameters as shown below. Note that the lines are before the line "${JAVA_HOME}/bin/java ${JAVA_VM} -version":
JAVA_HOME="/scratch/example_user/tools/jdk1.6.0_31" /home/user/jdk1.6.0_31 MEM_ARGS="-Xms6144m -Xmx6144m -Xmn1900m -XX:PermSize=128m -XX:MaxPermSize=1024m -XX:+UseParallelGC "
Where:
-Xms6144m -Xmx6144m: Selects the initial and maximum memory sizes available to the JVM, respectively. These values are used for the JVM heap, which reserves memory for the runtime cache and transient policy data during distribution.
Properly tuning this parameter reduces the overhead of garbage collection, improving authorization response time and throughput. If its value is too low, it may result in an OutOfMemory error or a lot of minor/full garbage collections.
-XX:PermSize: Selects the initial memory size available for the permanent generation data. Specifying 128 Mbytes eliminates the overhead of increasing this part of the heap for most of the scenarios.
-XX:MaxPermSize: Selects the maximum size of Permanent Generation. Specifying 1024 Mbytes eliminates possible OutOfMemoryError in case there are large custom permissions.
-XX :+UseParallelGC: Uses parallel garbage collection for scavenges. This collection algorithm is designed to maximize throughput while minimizing pauses and a suitable GC algorithm for the Security Module.
Edit the OES_CLIENT_HOME/oes_sm_instances/SM_NAME/run-j2se.sh script by adding all the JVM parameters shown below into the last line:
${JAVA_HOME}/bin/java -Xms6144m -Xmx6144m -Xmn1900m -XX:PermSize=128m -XX:MaxPermSize=1024m -XX:+UseParallelGC -Doracle.security.jps.config=./config/jps-config.xml
-classpath ./: ./sm-config-tool.jar oracle.security.oes.tools.OESJ2SESampleApp PD
Edit the OES_CLIENT_HOME/oes_sm_instances/SM_NAME/startWSServer.sh script, by adding all the JVM parameters as shown below. Note that the properties are added after the last JAVA_OPT line:
JAVA_OPT="$JAVA_OPT -Xms6144m -Xmx6144m -Xmn1900m -XX:PermSize=128m -XX:MaxPermSize=1024m -XX:+UseParallelGC"
For PDP service configurations, refer to Table 16-7 which lists available parameter for the Web Service Security Module.
Table 16-7 Web Service Security Module Parameters
| Web Service Security Module Parameters | Description |
|---|---|
|
oracle.security.jps.pdp.sm.IdentityCacheEnabled |
Flag to set if using identity cache. If not set, identity cache enabled by default |
|
oracle.security.jps.pdp.sm.IdentityMaxCacheSize |
Specify the maximum cache size. Its default value is 20000. Tuning this parameter according to number of all subjects. |
|
oracle.security.jps.pdp.sm.IdentityCacheEvictionPercentage |
Specifies percentage of identities that must be evicted when cache has reached the maximum size Its default value is 20 percentages. |
|
oracle.security.jps.pdp.sm.IdentityCachedEntryTTL |
Specifies time-to-live in seconds for a identity record in the cache. Its default value is 3600 seconds. |
|
oracle.security.jps.pdp.wssm.WSLoggingSoapHandlerEnabled |
Flag to set if enable EnvelopLoggingSOAPHandler of Web Service Security Module. Its default value is false. |
For PDP service configuration, add the following property
oracle.security.jps.pd.client.PollingTimerInterval:
This property specifies the PD periodic check interval. Its default value is 600 seconds. Depending on how often policy data is changed, it can be set to a smaller or larger value.
Out-of-the-box Attribute retrievers could be tuned for caching.
For information, refer to Section B.3, "Configuring the Predefined Attribute Retrievers Manually." For the instructions in Section B.3.2, "Configuring Individual Attribute Values", use the properties "ttl" (Time-to-live "ttl" in seconds of any cached attribute values when cached is enabled) and "cached" (enables the caching of attribute values).
Authorization decision caching allows Oracle Entitlements Server to cache the result of an authorization call and use that decision in the future, if an identical call is made.
For the Decision Cache in the Security Module, set the following properties in the jps-config.xml file of the PDP:
<property name="oracle.security.jps.pdp.AuthorizationDecisionCacheEnabled" value="true"/> <property name="oracle.security.jps.pdp.AuthorizationDecisionCacheEvictionCapacity" value="1500"/> <property name="oracle.security.jps.pdp.AuthorizationDecisionCacheEvictionPercentage" value="10"/> <property name="oracle.security.jps.pdp.AuthorizationPerUserDecisionCacheSize" value="1500"/> <property name="oracle.security.jps.pdp.AuthorizationDecisionCacheTTL" value="300"/>
Table 16-8 describes details of the above configurations.
Table 16-8 Tuning OES Cache Example Configuration
| Property | Description | Default | Recommended |
|---|---|---|---|
|
oracle.security.jps.pdp.AuthorizationDecisionCacheEvictionCapacity |
This is the number that is used to evict the decision cache if the decision cache size reaches this size. |
500 |
Tuning this parameter according to number of concurrent users making authorization requests. |
|
oracle.security.jps.pdp.AuthorizationDecisionCacheEvictionPercentage |
The percentage of authorization decisions to drop when the decision cache has reached the maximum capacity. |
10 |
|
|
oracle.security.jps.pdp.AuthorizationPerUserDecisionCacheSize |
This is the number that is used to evict the decision cache of each user (Subject) if the second level decision cache size reaches this size. Tuning this parameter according to number of all subjects. |
1000 |
How many authorization results to be cached for single user |
|
oracle.security.jps.pdp.AuthorizationDecisionCacheTTL |
This is the TTL for the Decision Cache in seconds. |
60 seconds |
Use PepRequestFactory.newQueryPepRequest().decide() to query access on extremely large number of child resources (for example, > 100) for Security Module instances in the controlled distribution mode.
This feature is disabled by default, but you can enable it for Security Module instances in the controlled distribution mode.
To enable it, update the jps-config.xml file of the Security Module instances to add the following property for the PDP service instance:
<serviceInstance name="pdp.service" provider="pdp.service.provider">
…. ….
<property name="oracle.security.jps.runtime.enableResourcePermissionCache" value="true"/>
This section contains the following topics:
Logs are required for performance measurement for some key operations, including migration, snapshot generation, and distribution.
There is a log at the INFO level for migration via WLST. You could see logs with the timestamp printed to the WLST console directly. Refer to the example below:
Apr 19, 2013 3:07:00 AM oracle.security.jps.internal.tools.utility.JpsUtilMigrationPolicyImpl migrateAppPolicyData INFO: Migration of Application Policies in progress..... … … Apr 19, 2013 3:07:39 AM oracle.security.jps.internal.tools.utility.util.JpsMigrateUtil cloneResourceType INFO: Migration of Resources started Apr 19, 2013 3:08:12 AM oracle.security.jps.internal.tools.utility.util.JpsMigrateUtil cloneResourceType INFO: Migration of Resources completed in 00:00:33 … … Apr 19, 2013 3:08:44 AM oracle.security.jps.internal.tools.utility.util.JpsMigrateUtil clonePermissionSet INFO: Migration of Permission Sets completed in 00:00:31 … … Apr 19, 2013 3:11:35 AM oracle.security.jps.internal.tools.utility.destination.apibased.JpsDstPolicy clone INFO: Completed Migrating 5,351 policies in [170,914] ms. … … Apr 19, 2013 3:20:57 AM oracle.security.jps.internal.tools.utility.destination.apibased.JpsDstPolicy clone INFO: Migration of Grants completed in 00:09:22 … … Apr 19, 2013 3:20:57 AM oracle.security.jps.internal.tools.utility.JpsUtilMigrationPolicyImpl migrateAppPolicyData INFO: Migration of Application Policies completed, Time taken for migration is 00:13:57
Create a Java logging.properties file and enable Java logging with the log level setting as shown below:
handlers= java.util.logging.FileHandler .level= INFO ############################################################ # Handler specific properties. # Describes specific configuration info for Handlers. ############################################################# default file output is in user's home directory. java.util.logging.FileHandler.pattern =<Log_home>/performance.log java.util.logging.FileHandler.limit = 10000000 java.util.logging.FileHandler.count = 200 java.util.logging.FileHandler.formatter =java.util.logging.SimpleFormatter java.util.logging.FileHandler.level = FINE java.util.logging.ConsoleHandler.level = INFO java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter ############################################################ # Facility specific properties. ############################################################ # Provides extra control for each logger. ############################################################ # For example, set the com.xyz.foo logger to only log SEVERE # messages: oracle.security.jps.internal.policystore.SnapshotWorker.level=FINEST
To enable the log, edit the DOMAIN_HOME/bin/startWeblogic.sh script as follows:
${JAVA_HOME}/bin/java ${JAVA_VM} ${MEM_ARGS} -Djava.util.logging.config.file=./logging.properties
-Dweblogic.Name=${SERVER_NAME}
-Djava.security.policy=${WL_HOME}/server/lib/weblogic.policy ${JAVA_OPTIONS} ${PROXY_SETTINGS} ${SERVER_CLASS}
From the log file, the following log message is shown when the snapshot is generated for the application policy:
Jan 31, 2013 1:07:49 AM oracle.security.jps.internal.policystore.SnapshotWorker run FINE: SnapshotWorker begin. ............... Jan 31, 2013 1:12:43 AM oracle.security.jps.internal.policystore.SnapshotWorker run FINE: SnapshotWorker end.
Create logging.properties file like above section, and add following line:
oracle.security.jps.az.internal.runtime.pd.receiver.UpdatePolicySet.level=FINEST
You will need to update a different script for different Security Module types.
Java Security Module
Edit the Java Security Module start scripts to add the log properties as follows. Refer to OES_CLIENT_HOME/oes_sm_instances/SM_NAME/run-j2se.sh as an example.
${JAVA_HOME}/bin/java -Doracle.security.jps.config=${OES_INSTANCE_HOME}/config/jps-config.xml
${MEM_ARGS} -Djava.util.logging.config.file=./config/logging.properties oracle.security.oes.tools.OESJ2SESampleApp PD
Then, add the following line in the log property file:
oracle.security.jps.az.internal.runtime.pd.receiver.UpdatePolicySet.level=FINEST
Web Service Security Module
In the OESCLIENT/oes_sm_instances/wssm/startWSServer.sh script, add the following line:
JAVA_OPT="$JAVA_OPT -Djava.util.logging.config.file=./config/logging.properties".
WebLogic Security Module
Edit the DOMAIN_HOME/bin/startWeblogic.sh script at the end with the following lines:
${JAVA_HOME}/bin/java ${JAVA_VM} ${MEM_ARGS} -Djava.util.logging.config.file=./config/logging.properties
Tomcat Security Module
Edit the TOMCAT_HOME/ bin/catalina.sh script by adding the following line after the last JAVA_OPTS line:
JAVA_OPTS="$JAVA_OPTS -Djava.util.logging.config.file=./config/logging.properties".
Log Messages
You can use the log messages with time stamp to obtain the time spent on policy distribution, from "starting" to "afterCommit finished". The following is an example message:
Jan 31, 2013 10:11:19 PM oracle.security.jps.az.internal.runtime.pd.receiver.UpdatePolicySet commit FINE: Starting ... .......... Jan 31, 2013 10:20:06 PM oracle.security.jps.az.internal.runtime.pd.receiver.UpdatePolicySet commit FINE: completed. Active Apps: [[]], Bounded Apps [[FinanceApp]] Jan 31, 2013 10:20:07 PM oracle.security.jps.az.internal.runtime.pd.receiver.UpdatePolicySet commit FINE: afterCommit is finished Jan 31, 2013 10:20:07 PM oracle.security.jps.az.internal.runtime.pd.receiver.UpdatePolicySet finishFirstDist