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:

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

Oracle Platform Security Services supports the following repositories:

  • For the OPSS security store:

    • File-based, XML for the policy store and cwallet for the credential store.

    • LDAP-based, Oracle Internet Directory (versions 10.1.4.3 or 11g).

    • 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.

  • For keystores:

    • File-based, XML file.

    • LDAP-based, Oracle Internet Directory (versions 10.1.4.3 or 11g).

    • 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).

Important:

If using Oracle Internet Directory 10.1.4.3 with OPSS, a mandatory one-off patch for bug number 8351672 is required on top of Oracle Internet Directory 10.1.4.3. For a list of patches to various versions of Oracle Internet Directory, see Chapter 8, "Using an LDAP-Based OPSS Security Store."

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 with no more than ten thousand users and with no more than twenty five hundred groups.

Policies, credentials, and keys 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 be accessed by the User and Role API to query user profile attributes or to insert additional attributes to users or groups.

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.

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, Credentials, Keys, and Certificates

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

To manage policies and credentials use Fusion Middleware Control as explained in Section 9.2, "Managing Policies with Fusion Middleware Control" and Section 10.4, "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.5, "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.

Keys and certificates are managed with Fusion Middleware Control and WLST. For details, see Chapter 11, "Managing Keys and Certificates with the Keystore Service".

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 OPSS scripts

    • LDAP-based: use Fusion Middleware Control, OPSS scripts, or Oracle Entitlements Server

  • Keys and Certificates

    • Use OPSS scripts

Changes to policies, credentials, or keys 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.4, "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 that the list of variations presented is not exhaustive.

Related Documentation

For details about configuring the Default Authenticator, see section Configure Authentication and Identity Assertion Providers in Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help.

For details about configuring the OPSS security store, see Chapter 8, "Configuring the OPSS Security Store."

For details about managing policies, see Chapter 9, "Managing the Policy Store."

For details about managing credentials, see Chapter 10, "Managing the Credential Store."

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

For details about managing the Keystore Service, see Chapter 11, "Managing Keys and Certificates with the Keystore Service."

Common Scenario 1

This scenario describes a Java EE application during development.

Authentication: The application uses the Default Authenticator, typical in development environments.

Authorization: The policy and credential stores are file-based.

Variation: The application uses the WebLogic support for SSO and Java EE security.

For details about WebLogic support for SSO, see section Configuring Single Sign-On with Web Browsers and HTTP Clients in Oracle Fusion Middleware Securing Oracle WebLogic Server.

Common Scenario 2

This scenario describes a Java EE application during development.

Authentication: The application uses the Default Authenticator, typical in development environments.

Authorization: The policy and credential stores are LDAP-based using the services of the same instance of an Oracle Internet Directory LDAP server.

Variation: JAAS is enabled and policies include permissions for the anonymous and the authenticated roles.

For details about configuring support for the anonymous and authenticated roles, see Section 2.3, "The Authenticated Role," and Section 2.4, "The Anonymous User and Role."

Common Scenario 3

This scenario describes a Java EE application during development.

Authentication: The application uses the Default Authenticator, typical in development environments.

Authorization: The policy and credential stores are LDAP-based using the services of the same instance of an Oracle Internet Directory LDAP server.

Variation: The application uses Java EE security, JAAS is enabled, and policies include permissions for the anonymous and the authenticated role. It also uses the Credential Store Framework (CSF) APIs to query, retrieve, and manage policies.

For details about configuring support for the anonymous and authenticated roles, see Section 2.3, "The Authenticated Role," and Section 2.4, "The Anonymous User and Role."

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

4.5 Other Scenarios

In the following scenarios 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: the application uses an 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:

Scenario 6

This scenario describes a Java SE application using OPPS APIs.

Authentication: The application uses 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.