| Oracle® Fusion Middleware Application Security Guide 11g Release 1 (11.1.1) Part Number E10043-09 |
|
|
View PDF |
| Oracle® Fusion Middleware Application Security Guide 11g Release 1 (11.1.1) Part Number E10043-09 |
|
|
View PDF |
This chapter explains how applications developed using OPSS benefit and work with Oracle Fusion Middleware, and it includes the following sections:
This section explains the benefits of securing applications with Oracle Platform Security Services, in the following topics:
Java EE 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 that cycle.
The following list summarizes the Java EE development cycle, emphasizes the tasks specific to developing secure applications, and highlights the security enhancements that OPSS provides.
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 Java EE logical roles and assigns them privileges through security constraints, all through configuration in standard Java EE 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 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
Java developers face some challenges in developing secure 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.
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:
Provides basic security services such as authentication, authorization, auditing, role management, and credential management.
Allows developers to focus on the application logic.
Provides the same services that Oracle Fusion Middleware products get:
OPSS is the security platform for Oracle Fusion Middleware components, such as Oracle WebLogic Server, Oracle Entitlement Server, Oracle SOA Suite, and Oracle WebCenter.
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 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.
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.
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.
This section describes the APIs available to developers working with Oracle Platform Security Services:
OPSS provides the LoginService authentication API to enable Java SE applications to access and manage the identity 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 22, "Authentication for Java SE Applicaitons".
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.
For details, see Chapter 25, "Developing with the User and Role 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.
OPSS APIs provide the following benefits beyond the traditional authorization models:
They extend the JAAS model with the ability to use application roles that are assigned permissions.
They provide policy management support, which is lacking in the standard JAAS model. See Section 20.3.2, "Managing Policies" for an example.
Using the JpsAuth.checkPermission OPSS API as opposed to the standard checkPermission, they provide additional benefits such as more robust debugging and integrated audit support.
For details about authorization features of OPSS, see Chapter 23, "Authorization for Java SE Applications".
A credential store is a secure, central repository where credentials and collections of credentials are stored. 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 24, "Developing with the Credential Store Framework".
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.
Figure 19-2 illustrates a standard Java EE application using 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 the following choices when implementing authentication:
Declarative authentication, where authentication is configured in the file web.xml (this is standard Java EE security)
Programmatic security. Oracle Fusion Middleware provides several APIs, including:
Oracle WebLogic Server's authentication API, weblogic.security.auth.Authenticate
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.
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.
Figure 19-4 illustrates a Java EE application using portable, fine-grained authorization.
Key features include:
Authorization through JpsAuth.checkPermission API calls
Auditing of authorization decisions
Figure 19-5 illustrates an application needing to access and store credentials for an external system such as a database.
Key features include:
Credentials stored securely in a 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 that can be managed with either Oracle Enterprise Manager Fusion Middleware Control or WLST scripts
Credential store operations that can be audited
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.
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 19.4.2, "How Oracle ADF Uses OPSS".
Figure 19-7 illustrates a Java SE Swing application using different OPSS APIs.
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
Important:
The OPSS policy provider must be explicitly set in Java SE applications, as illustrated in the following snippet:java.security.Policy.setPolicy(new oracle.security.jps.internal.policystore.JavaProvider())
Not setting the policy provider explicitly in a Java SE application may cause runtime methods (such as JpsAuth.checkPermission) to return incorrect values.
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.
Figure 19-8 illustrates an Oracle ADF application using both fine-grained authorization and Java EE container-based authentication.
Key features include:
Use of JDeveloper's security wizard to create required security configuration
Calls by Oracle ADF filter to JpsAuth.checkPermission
Task flows and regions protected using custom Oracle ADF permissions
For more information, see:
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.
Key features include:
Oracle ADF application developed with Oracle JDeveloper
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 WLST scripts
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
Oracle Fusion Middleware Reference for Oracle Security Developer Tools
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 21, "Manually Configuring Java EE Applications to Use OPSS".
|
 Copyright © 2003, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
