|Oracle® Fusion Middleware Application Security Guide
11g Release 1 (11.1.1)
Part Number E10043-06
This chapter includes the following sections:
This section explains the benefits of securing applications with Oracle Platform Security Services and introduces the major components of the tool-set. It contains these topics:
JavaEE software development is based on a develop-deploy-manage cycle. The Oracle Platform Security Services security implementation plays an important part in all phases of the cycle.
The developer creates Web components, enterprise beans, servlets, and application clients based on business requirements.
While the developer has access to a declarative approach, additional value is obtained when using Oracle ADF, which makes use of OPSS APIs.
The developer defines JavaEE logical roles and assigns them privileges through security constraints, all through configuration in standard JavaEE deployment descriptors.
The components are assembled and combined into an Enterprise Archive (EAR) file.
As part of this process, the assembler specifies options appropriate to the environment.
The assembler defines application-level security constraints and resolves potential conflicts between module-level configurations.
The EAR file is deployed to Oracle WebLogic Server.
As part of the deployment process, the deployer may map JavaEE 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
Java developers face some challenges in developing secure applications:
The JavaEE 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 JavaEE applications often lack support for large enterprise security deployments.
Such key aspects as manageability, availability, scalability, and reliability are often missing from custom solutions.
Oracle Platform Security Services (OPSS) is a portable security services abstraction layer that provides a robust security framework and saves development time and effort. OPSS enhances traditional JavaEE development in many respects:
provides basic security services such as authentication, authorization, auditing, role management, and credential management.
allows developers to focus on the application logic
provides you the same services that Oracle Fusion Middleware products get:
OPSS is the security platform for Fusion applications and Oracle Fusion Middleware components, including Oracle WebLogic Server, Oracle Entitlement Server, Oracle SOA Suite, and Oracle WebCenter among others.
Note:This is just a sampling of the products that rely on OPSS.
is standards-based and enterprise-ready:
stress-tested to support enterprise deployments.
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 its use of 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.
Figure 13-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, for the most part, transparent to application developers and administrators.
The Oracle Platform Security architecture has the following characteristics:
A layered architecture that decouples the application layer from the underlying implementation.
An extensible architecture that provides 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.
This section describes the APIs available to developers working with Oracle Platform Security Services:
OPSS provides the LoginService authentication API to enable JavaSE applications to obtain information from an identity store and to manage the contents of the store.
Support for authentication is through the login module, a component that authenticates users and populates a subject with principals. This process occurs in two distinct phases:
In the first phase, the login module attempts to authenticate a user by means of credentials supplied by the user.
In the second phase, the login module assigns relevant principals to a subject, which is eventually used to perform a privileged action.
For details, see Chapter 15, "Developing Authentication".
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. The underlying identity store could be an LDAP directory server such as Oracle Internet Directory, or could be a database, flat file, or some other custom repository.
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
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 seamlessly against different repositories
switch between various identity repositories without any code changes to your application
For details, see Chapter 18, "Developing with the User and Role API".
The JavaEE 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 JavaEE 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.
Using OPSS APIs provides the following benefits beyond the traditional authorization models:
OPSS extends JAAS with the ability to use application roles that are assigned permissions.
OPSS provides policy management support, which is lacking in the standard JAAS model. See Section 17.2.2, "Managing Policies" for an example.
Using the JpsAuth.checkPermission OPSS API as opposed to the standard checkPermission API provides additional benefits such as more robust debugging and integrated audit support.
For details about authorization features of OPSS, see Chapter 17, "Developing Authorization".
A credential store a secure, central store for credentials and collections of credentials. Multiple applications can use the same credential store.
The Credential Store Framework (CSF) API provides the mechanism by which applications access the credential store.
The CSF API supports file-based (Oracle wallet) and LDAP-based credential stores.
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.
For details about the API, see Chapter 16, "Developing with the Credential Store Framework".
The same set of OPSS APIs can be used by both JavaEE and JavaSE developers. Topics in this section illustrate common applications for the APIs, and demonstrate differences between JavaEE and JavaSE implementations.
This example shows a traditional JavaEE application enhanced with OPSS security APIs.
Key features include:
Integration with Oracle WebLogic Server
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
Developers have these choices for implementing authentication:
declarative authentication, where you configure authentication in web.xml (this is standard JavaEE security)
programmatic security. Oracle Fusion Middleware provides several APIs, including:
Oracle WebLogic Server's authentication API,
oracle.security.jps.service.login.LoginService API for JavaSE applications. This API supports user/password authentication and username assertion. The assertion functionality is protected by
JpsPermission with the name
This example shows a JavaEE application that must assert an identity through a token or through user credentials.
Key features include:
username and password supplied by the application for programmatic authentication with the
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.
Key features include:
JpsAuth.checkPermission API calls
auditing of authorization decisions
Key features include:
credentials (username and password, symmetric keys, and so on) stored securely in credential store
support for LDAP-based credential stores in addition to Oracle Fusion Middleware's out-of-the-box, file-based credential store called Oracle wallet.
credentials can be managed with either Oracle Enterprise Manager Fusion Middleware Control or
WLST command-line tool
credential store operations can be audited
This example shows an application that needs to search for users in an identity store. Various queries are needed; for example, searching all users in "APAC" or locating all emails for users in a given role.
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.
same API regardless of where the attributes are stored
For an example of authorization using Oracle ADF, see Section 13.4.2, "How Oracle ADF Uses OPSS".
Note:In an LDAP-based store, like that shown in the figure, both policies and credentials are maintained in the same store, while file-based stores maintain separate files for each.
Key features include:
LoginService API for authentication
JpsAuth.CheckPermission for authorization
User and Role API to query attributes stored in LDAP or other back-end
use of credential store to secure credentials
When you use Oracle ADF to develop and deploy applications, you are able to directly leverage the security features of OPSS, since Oracle ADF is integrated with OPSS.
This section introduces Oracle ADF and provides an example of OPSS security in an Oracle ADF application.
The Oracle Application Development Framework (Oracle ADF) is an end-to-end application framework that builds on Java Platform, Enterprise Edition (Java EE) standards and open-source technologies to simplify and accelerate implementing service-oriented applications. For enterprise solutions that search, display, create, modify, and validate data using web, wireless, desktop, or web services interfaces, Oracle ADF can simplify the development effort.
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.
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.
This example shows an Oracle ADF application that needs to use both fine-grained authorization and JavaEE container-based authentication.
Key features include:
use of JDeveloper's security wizard to create required security configuration
calls by Oracle ADF filter to
Task flows and regions protected using custom Oracle ADF permissions
For more information, see:
This example show 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.
This Oracle WebLogic Server domain is likely to be located in a test or staging area.
Key features include:
Oracle ADF application developed with Oracle JDeveloper
uses Oracle ADF security wizard and Oracle ADF authorization policy editor
Oracle JDeveloper provides an integrated user experience, migrating artifacts to the run-time environment:
Users and groups defined at design-time are available in the default authenticator
authorization policy and credential data is migrated using the OPSS listener framework.
application developer creates EAR file containing policy and credentials
administrator deploys the EAR to a remote Oracle WebLogic Server using Fusion Middleware Control or
Note:For more information about deployment tools and options, see Chapter 6, "Deploying Secure Applications".
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.
For more information about the tools, see:
Oracle Security Developer Toolkit in the Oracle Fusion Middleware Security Overview
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.
For more information about this topic, see Chapter 14, "Manually Configuring JavaEE Applications to Use OPSS".