4 About Oracle Platform Security Services Scenarios

This chapter describes some typical security scenarios supported by Oracle Platform Security Services. It also includes the list of LDAP, DB, and XML servers supported, the management tools that an administrator would use to administer security data in each scenario, and the package requirements for policies and credentials.

These topics are explained in the following sections:

Supported LDAP-, DB-, and File-Based Services
Management Tools
Packaging Requirements
Example Scenarios
Other Scenarios

4.1 Supported LDAP-, DB-, and File-Based Services

Oracle Platform Security Services supports the following LDAP-, DB-, and file-based repositories:

For the OPSS security store:
- If file-based, XML for the policy store and cwallet for the credential store.
- If LDAP-based, Oracle Internet Directory (versions 10.1.4.3 or 11g) for the policy store and credential store.
- If DB-based, Oracle RDBMS (releases 10.2.0.4 or later; releases 11.1.0.7 or later; and releases 11.2.0.1 or later).
For the identity store, any of the LDAP authenticators supported by the Oracle WebLogic Server. An XML identity store is supported in only Java SE applications.

Important:

If using Oracle Internet Directory 10.1.4.3 with OPSS, a mandatory one-off patch for bug number 8351672 is recommended on top of Oracle Internet Directory 10.1.4.3. Download the patch for your platform from Oracle Support at http://myoraclesupport.oracle.com.

To ensure optimal performance, the following Oracle Internet Directory tuning is recommended:

ldapmodify -D cn=orcladmin -w <password> -v <<EOF 
dn: cn=dsaconfig,cn=configsets,cn=oracle internet directory
changetype: modify
add: orclinmemfiltprocess
orclinmemfiltprocess: (objectclass=orcljaznpermission)
orclinmemfiltprocess: (objectclass=orcljazngrantee)
EOF

For details about LDAP authenticators, see section Configuring LDAP Authentication Providers in Oracle Fusion Middleware Securing Oracle WebLogic Server. In particular, the DefaultAuthenticator is available out-of-the-box, but its use is recommended only in developing environments for no more than ten thousand entries, for users, and for no more than twenty five hundred entries, for groups.

Policies and credentials stored in an LDAP-based store must use the same physical persistent repository. For details, see the following chapters:

4.2 Management Tools

The tools available to a security administrator are the following:

WebLogic Administration Console
Oracle Enterprise Manager Fusion Middleware Control
Oracle Entitlements Server
OPSS scripts (available on all supported platforms)
LDAP server-specific utilities

The tool to manage security data depends on the type of data stored and the kind of store used to keep that data. For applications deployed on WebSphere Application Server, there is also the WebSphere Application Server Administration Console; for details, see WebSphere Application Server documentation. Note that OPSS scripts are available for both platforms: WebLogic and WebSphere.

Users and Groups

If a domain uses the DefaultAuthenticator to store identities, then use the Oracle WebLogic Server Administration Console to manage the stored data. The data stored in the DefaultAuthenticator can also be accessed by the User and Role API to query user profile attributes. To insert additional attributes to users or groups in the DefaultAuthenticator, an applications also uses the User and Role API.

Important:

If your domain uses the DefaultAuthenticator, then the domain administration server must be running for an application to operate on identity data using the User and Role API.

For details about configuring this authenticator, see Section 3.1.2.1, "Using an LDAP Authenticator."

Otherwise, if authentication uses any other LDAP server different from the default authenticator or a DB, then, to manage users and groups, use the services of that LDAP server.

Policies and Credentials

Policies and credentials must use the same kind of storage (file-, LDAP-, or DB-based), and if LDAP-based, the same LDAP server (Oracle Internet Directory only).

To manage policies and credentials use Fusion Middleware Control as explained in Section 9.2, "Managing Policies with Fusion Middleware Control" and Section 10.3, "Managing Credentials with Fusion Middleware Control," or the OPSS scripts, as explained in Section 9.3, "Managing Application Policies with OPSS Scripts" and Section 10.4, "Managing Credentials with OPSS Scripts."

Alternatively, to manage policy data, use Oracle Entitlements Server as explained in Oracle Fusion Middleware Administrator's Guide for Oracle Entitlements Server.

The following list summarizes the tools used to manage security data:

Identity data
- Default Authenticator: use Administration Console
- Other LDAP or DB stores: use utilities provided by the LDAP server or DB
Policy and Credential data
- File-based: use Fusion Middleware Control or WLST
- LDAP-based: use Fusion Middleware Control, WLST, or Oracle Entitlements Server to manage policies.

Changes to policies or credentials do not require server restart; changes to the file jps-config.xml do require server restart.

Note:

In general, domain configuration changes require the server to be restarted; however, changes to the domain data do not require the server to be restarted. An example of a domain configuration change is the reassociation of domain stores.

For details about the automatic migration of application policies and credentials to the domain stores when the application is deployed, see Section 8.6, "Migrating the OPSS Security Store."

For details about managing tools on WebSphere Application Server, see Oracle Fusion Middleware Third-Party Application Server Guide.

4.3 Packaging Requirements

File-based application policies are defined in the file jazn-data.xml. The only supported way to package this file with an application is to place it in the directory META-INF of an EAR file.

File-based application credentials are defined in a file that must be named cwallet.sso. The only supported way to package this file with an application is to place it in the directory META-INF of an EAR file. For details, see Section 21.3, "Packaging a Java EE Application Manually."

For information about deployment on WebLogic, see Chapter 6, "Deploying Secure Applications."

On WebSphere, the behavior at deployment is controlled by properties specified in the file META-INF/opss-application.xml. For details about policy migration, see Oracle Fusion Middleware Third-Party Application Server Guide. For details about credential migration, see Oracle Fusion Middleware Third-Party Application Server Guide.

Note:

Oracle JDeveloper automatically packages the EAR file for a secured Oracle ADF application with all the required files (and with the appropriate security configurations), when the EAR file is produced within that environment.

4.4 Example Scenarios

The scenarios explained in this section describe the security features adopted by most Oracle ADF applications, Oracle WebCenter, and Web Services Manager Control.

They assume that the application employs a security scheme that has the following characteristics:

Authentication: it uses the WebLogic Default Authenticator to store users and groups.
Authorization: it uses fine-grained JAAS authorization supported by file-based policies and credentials packaged with the application and by policy and credential stores (file- or LDAP-based).

One of these security schemes is typically employed by applications, such as Oracle ADF or Oracle SOA applications, that require fine-grained JAAS authorization. The various security components in these cases are managed with the appropriate tool.

Based on these assumptions, the following scenarios are typical variations on the basic theme; note, however, that the list of variations is not exhaustive.

4.5 Other Scenarios

The following scenarios differ from the common scenarios in that the application uses an authenticator other than the DefaultAuthenticator (typically used in the application development phase) or some API to access security data.

Scenario 4

Authentication: The application uses an LDAP authenticator (other than the DefaultAuthenticator).

Authorization: Both, the policy and credential use the same Oracle Internet Directory LDAP-based store.

Variation: The application uses the User and Role API to access user profiles in the DB and the Credential Store Framework (CSF) APIs to access credentials.

For details about User and Role API, see Chapter 25, "Developing with the User and Role API."

For details about CSF APIs, see Section 24.1, "About the Credential Store Framework API."

Scenario 5

Authentication: The application uses the Oracle Internet Directory LDAP authenticator, typical in test and production environments.

Authorization: The policy and credential stores are file-based and packaged with the application. These data is automatically mapped to domain security data at deployment.

Variation: Post-deployment, the policy and credential stores are reassociated to an LDAP-based store configured through one-way SSL transmission channel.

For details about automatic migration of application security data at deployment, see Section 8.6, "Migrating the OPSS Security Store."

For details about reassociation, see Section 8.5, "Reassociating the OPSS Security Store."

For details about SSL configuration and related topics, see the following:

Section Configuring SSL in Oracle Fusion Middleware Securing Oracle WebLogic Server.
Oracle Fusion Middleware Administrator's Guide.
Section Set up SSL in Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help.
Section Using SSL Authentication in Java Clients in Oracle Fusion Middleware Programming Security for Oracle WebLogic Server.

Scenario 6

This scenario describes a Java SE application using OPPS APIs.

Authentication: The application the LoginService API.

Authorization: The application uses the method CheckPermission.

In addition, the application uses the User and Role API to query attributes into the domain authenticator, and the Credential Store Framework API to query the credential store.