5 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 supported LDAP servers, 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:

5.1 Supported LDAP Servers

Oracle Platform Security Services supports the following LDAP servers and repositories:

  • iPlanet, WebLogic DefaultAuthenticator, Active Directory, Novell, and OpenLDAP.

  • Oracle Internet Directory (versions 10.1.4.3 or 11g only) and Oracle Internet Directory (version 11g only).

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

WebLogic authenticators store identities (users and groups) in a store using any of the above servers. For details about LDAP authenticators and tested LDAP servers, see section Configuring LDAP Authentication Providers in Oracle Fusion Middleware Securing Oracle WebLogic Server.

Policies and credentials can be stored in a store using only Oracle Internet Directory or Oracle Virtual Directory; moreover, when both the policy and credential stores are LDAP-based, they must use the kind of server. The only supported back-end for an Oracle Virtual Directory is LSA (local store adapter).

The DefaultAuthenticator is available out-of-the-box and its use is recommended only in developing environments and for no more than a thousand entries.

5.2 Management Tools

The tools available to an administrator are the following:

  • WebLogic Administration Console

  • Oracle Enterprise Manager Fusion Middleware Control

  • WLST commands and WLST scripting

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

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 4.1.3, "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- or LDAP-based), and if LDAP-based, the same kind of LDAP server (Oracle Internet Directory or Oracle Virtual Directory).

To manage policy and credential data, use either Fusion Middleware Control as explained in Managing Policies with Fusion Middleware Control and Managing Credentials with Fusion Middleware Control, or the command-line utility WLST, as explained in Managing Policies with WLST Commands and Managing Credentials with WLST Commands.

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 or WLST

Changes to policies or credentials do not require server restart; changes to the 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 sections Migrating Application Policies with Fusion Middleware Control and Migrating Application Credentials with Fusion Middleware Control.

5.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 15.3, "Packaging a JavaEE Application Manually."

For information about deployment, see Chapter 7, "Deploying Secure Applications."

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.

5.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 domain 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.

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

For details about using, configuring, and managing policies, see Chapter 8, "OPSS Authorization and the Policy Store."

For details about using, configuring, and managing credentials, see Chapter 9, "Configuring the Credential Store."

Common Scenario 1

This scenario describes a JavaEE 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 JavaEE 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 JavaEE 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 Virtual 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 3.3, "The Authenticated Role," and Section 3.4, "The Anonymous User and Role."

Common Scenario 3

This scenario describes a JavaEE 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 JavaEE 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 3.3, "The Authenticated Role," and Section 3.4, "The Anonymous User and Role."

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

5.5 Other Scenarios

The following scenarios differ from the common scenarios in that the application uses an authenticator othe then the DefaultAuthenticator (typically used in the application development phase) or some provided 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 19, "Developing with the User and Role API."

For details about CSF APIs, see Section 17.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.3.1, "Migrating Application Policies with Fusion Middleware Control," and Section 9.4.1, "Migrating Application Credentials with Fusion Middleware Control."

For details about reassociation, see Section 8.2.1, "Reassociating Domain Stores with Fusion Middleware Control."

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

Scenario 6

This scenario describes a JavaSE 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 domain credential store.