As part of the deployment process, the deployer may map Java EE roles to deployment users and roles.

The system administrator maintains and manages the deployed application.

This task includes creating and managing roles and users in the deployment environment as required by the application customers.

For finer-grained code-based or subject-based access control using Java 2 or JAAS features, the traditional steps include:

The developer identifies any resources that may be accessed and must be protected as appropriate.

The developer defines permissions to protect these resources.

The developer implements code for runtime authorization checks.

The system administrator maintains any necessary policy configuration to enforce the desired permissions. Policy provisioning should be completed prior to runtime.

Oracle ADF and OPSS provide these enhancements:

At Design Time - modeling of application roles, defining resources as permissions, and assigning permissions to roles. Application credential management is supported, for example, ADF connections can store credentials in the Credential Store Framework during design time.

At Deployment Time - policy and credential migration options are available

Post-deployment, the administrator performs essential tasks such as mapping application roles to enterprise users or groups which are reflected at run-time

19.1.2 Challenges of Securing Java Applications

The Java EE standard does not define any API for fine-grained authorization, credential mapping, role mapping, auditing, or integration with single-sign.

Developers need to acquire in-depth security knowledge at the expense of focusing on application business logic.

There is no consistent security experience across platforms. For example, custom security solutions often develop their own security framework, which is often not portable across platforms.

Custom solutions for securing Java EE applications often lack support for large enterprise security deployments.

Such key aspects as manageability, availability, scalability, and reliability are often missing from custom solutions.

19.1.3 Meeting the Challenges with Oracle Platform Security Services

Oracle Platform Security Services (OPSS) is a portable security services abstraction layer that provides a robust security framework that saves development time and effort. OPSS enhances traditional Java EE development in many respects:

Interoperable across different LDAP servers and single sign-on (SSO) systems.

Certified on Oracle WebLogic Server.

Provides the same set of APIs for all types of applications (in-house, third-party, Oracle Fusion).

Optimizes development time with by using abstraction layers.

Application maintenance is simplified since security rules can be changed without affecting application code.

Enables legacy and third-party security provider integration.

OPSS support for Identity Management (IdM) includes:

A lightweight infrastructure that allows customers to build and deploy small to mid-size applications

A plug-in interface to IDM systems:

Applications build against OPSS can be plugged to a centrally deployed Identity Management system

Customers can scale their applications to switch to a centrally deployed Identity Management system

No code changes are required in the application when switching between IdM systems.

19.1.4OPSS Architecture

Figure 19-1 shows the basic components of the OPSS architecture. There are specific APIs for most of the features discussed earlier in this manual that are available for use by application developers. Underlying SPIs (service provider interfaces), mentioned briefly in Section 1.2, "OPSS Architecture Overview," are mostly invisible to application developers and administrators.

Figure 19-1 OPSS Architecture

The Oracle Platform Security architecture provides:

A layered architecture that decouples the application layer from the underlying implementation.

An extensible framework that allows explicit extensibility points (through the SPI layer) where custom implementations (such as custom login modules) can be plugged into the framework to provide special functionality.

19.2 OPSS APIs

This section describes the APIs available to developers working with Oracle Platform Security Services:

19.2.2 The User and Role API

The user and role API framework allows applications to access identity information (users and roles) in a uniform and portable manner regardless of the particular underlying identity repository, since the type of the underlying identity store is transparent to the caller.

This API framework provides a convenient way to access repositories programmatically in a portable way, freeing the application developer from the potentially difficult task of accounting for the intricacies of particular identity sources. The framework allows an application to work against different repositories seamlessly. An application can switch between various identity repositories without any code changes being required.

Supported operations include creating, updating, or deleting users and roles, or searching users and roles for attributes or information of interest. For example, you may want to search for the e-mail addresses of all users in a certain role.

The API supports:

LDAP directory servers such as Oracle Internet Directory

Flat files

Other custom repositories such as databases, by implementing a custom provider for the repository

With the User and Role API, you can:

Access repositories programmatically in a portable way.

Eliminate the need to account for the intricacies of particular identity sources.

Enable your application to work against different repositories.

Switch between various identity repositories without any code changes to your application.

19.2.3 JAAS Authorization and the JpsAuth.checkPermission API

The Java EE authorization model uses role membership to control access to EJBs and web resources that are referenced by URLs; the Java 2 authorization model uses permissions (instead of role memberships) to control access decisions.

You can specify authorization policies in application code. Sensitive lines of code are preceded with calls to check whether a subject has the appropriate permission to execute specific sections of code. If the subject fails to have the proper permission, the code throws a security exception.

Java 2 authorization is based on permissions, rather than roles, and access control decisions are evaluated by calls to the SecurityManager or the AccessController. When used with JAAS, this model allows for a programmatic authorization capability, thus providing fine-grained control to resources.

Oracle Fusion Middleware supports authorization using Java EE DD/annotation based authorization and JAAS/Java2 permission based authorization. Both declarative and programmatic approaches for enforcing authorization policies are supported; the latter is implemented through the JpsAuth.checkPermission API, and AccessController.checkPermission can be used as well.

Critical functions provided by the CSF API include returning credentials for a given map name, assigning credentials to and deleting credentials from a given map name, and other operations related to credential maps and keys.

Operations on CredentialStore are secured by CredentialAccessPermission, which implements the fine-grained access control model utilized by CSF.

19.3 Common Uses of OPSS

The same set of OPSS APIs can be used by both Java EE and Java SE developers. Topics in this section illustrate common applications for the APIs, and demonstrate differences between Java EE and Java SE implementations.

19.3.1 Java EE Application using OPSS APIs

Credential Store Framework API to secure credentials in the LDAP directory or file-based credential store. Different types of credentials will be stored here - external database credentials, external Web Service credentials, and so on.

User and Role API to query attributes stored in the identity store

JpsAuth.checkPermission API for authorization

19.3.2 Authenticating with OPSS APIs

Developers have the following choices when implementing authentication:

Declarative authentication, where authentication is configured in the file web.xml (this is standard Java EE security)

OPSS' oracle.security.jps.service.login.LoginService API for Java SE applications. This API supports user/password authentication and username assertion. The assertion functionality is protected by JpsPermission with the name IdentityAssertion.

Figure 19-3 illustrates a Java EE application that must assert an identity through a token or through user credentials.

Figure 19-3 Programmatic Authentication

Key features include:

Username and password supplied by the application for programmatic authentication with the Authenticate API

Uses a WebLogic authenticator

Identity assertion through a token (authentication without a password)

Assertion protected by a code source permission. Only applications that have been granted the code source permission (codebase permission grant oracle.security.jps.JpsPermission with name IdentityAssertion" nd action execute) can use this API for identity assertion.

Credentials that can be managed with either Oracle Enterprise Manager Fusion Middleware Control or WLST scripts

Credential store operations that can be audited

19.3.5 User and Role

Figure 19-6 illustrates an application (deployed on WebLogic) that needs searching the identity store for users, such as searching all users in "APAC", or identifying all emails with users in a given role.

Figure 19-6 Searching the Identity Store with User and Role API

Key features include:

Calling the User and Role API to access user attributes

The same APIs work on user attributes in the default authenticator or an external LDAP store.

The User and Role API is automatically configured based on the configuration in the authentication provider, either default or any other LDAP based authentication.

Used in tandem, Oracle JDeveloper 11g and Oracle ADF give you an environment that covers the full development life cycle from design to deployment, with drag-and-drop data binding, visual UI design, and team development features built in.

19.4.2 How Oracle ADF Uses OPSS

The Oracle ADF Security framework is the preferred technology to provide authentication and authorization services to the Fusion web application. Among the advantages:

Oracle ADF Security is built on top of the Oracle Platform Security Services (OPSS) architecture, which provides a critical security framework and is itself well-integrated with Oracle WebLogic Server.

Oracle JDeveloper and Oracle ADF use the OPSS application life cycle listener framework to migrate credential and policy data when the application is deployed.

Oracle ADF's built-in support for security features including OPSS features helps reduce some of the effort that would be required to implement those features outside Oracle ADF; indeed, certain features are not available using only container-managed security.

19.4.3 The Oracle ADF Development Life Cycle

Figure 19-9 illustrates how an application is first deployed to integrated Oracle WebLogic Server (Oracle WebLogic Server embedded in Oracle JDeveloper). A developer then produces an EAR file that is deployed, through Oracle Enterprise Manager Fusion Middleware Control, to another Oracle WebLogic Server domain. In regards to grants with duplicate permissions, see note in Policy Management.

This Oracle WebLogic Server domain is likely to be located in a test or staging area.

19.5 Using the Oracle Security Developer Tools

Oracle Security Developer Tools provide you with the cryptographic building blocks necessary for developing robust security applications, ranging from basic tasks like secure messaging to more complex projects such as securely implementing a service-oriented architecture. The tools build upon the core foundations of cryptography, public key infrastructure, web services security, and federated identity management, and are widely used in building Oracle's own security offerings.

19.6 Using OPSS Outside Oracle JDeveloper/Oracle ADF

You can make use of OPSS APIs in your applications if you are using a development IDE other than Oracle JDeveloper and Oracle ADF.

However, in that case, you will need to perform manual configuration in OPSS configuration files and web.xml, so you do not get the benefits of automatic configuration and security migration that are available when using Oracle JDeveloper.