14 Overview of Developing Secure Applications with Oracle Platform Security Services

This chapter explains the features and benefits of using Oracle Platform Security Services to develop and deploy secure applications to work with Oracle Fusion Middleware.

This chapter includes the following sections:

• About Oracle Platform Security Services for Developers

• The Oracle Platform Security Services APIs

• Common Uses for Oracle Platform Security Services

• Using OPSS with Oracle Application Development Framework

• Using the Oracle Security Developer Tools

• Using OPSS Outside Oracle JDeveloper/Oracle ADF

14.1 About Oracle Platform Security Services for Developers

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:

• The Development Cycle

• Challenges of Securing Java Applications

• Meeting the Challenges with Oracle Platform Security Services

• OPSS Architecture

14.1.1 The Development Cycle

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 following list summarizes the JavaEE development cycle, emphasizes the tasks specific to developing secure applications, and highlights the security enhancements that OPSS provides.

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

2. The developer defines JavaEE logical roles and assigns them privileges through security constraints, all through configuration in standard JavaEE deployment descriptors.

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

4. The assembler defines application-level security constraints and resolves potential conflicts between module-level configurations.

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

6. 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:

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

2. The developer defines permissions to protect these resources.

3. The developer implements code for runtime authorization checks.

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

14.1.2 Challenges of Securing Java Applications

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.

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

14.1.4 OPSS Architecture

Figure 14-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 2.2, "OPSS Architecture Overview," are mostly invisible to application developers and administrators.

Figure 14-1 OPSS Architecture

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.

14.2 The Oracle Platform Security Services APIs

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

• The LoginService API

• The User and Role API

• JAAS Authorization and the JpsAuth.checkPermission API

• The Credential Store Framework API

14.2.1 The LoginService API

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 16, "Developing Authentication".

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

• 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 seamlessly against different repositories

• switch between various identity repositories without any code changes to your application

For details, see Chapter 19, "Developing with the User and Role API".

14.2.3 JAAS Authorization and the JpsAuth.checkPermission 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 18.3.4.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 18, "Developing Authorization".

14.2.4 The Credential Store Framework API

A credential store a secure, central store for credentials and collections of credentials. Multiple applications can use the same credential stor.e

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 17, "Developing with the Credential Store Framework".

14.3 Common Uses for Oracle Platform Security Services

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.

14.3.1 A JavaEE Application using OPSS APIs

This example shows a traditional JavaEE application enhanced with OPSS security APIs.

Figure 14-2 JavaEE Application using Multiple OPSS 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

14.3.2 Authentication with OPSS APIs

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, weblogic.security.auth.Authenticate

  • OPSS' 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 IdentityAssertion.

This example shows a JavaEE application that must assert an identity through a token or through user credentials.

Figure 14-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.

See Also:

• Oracle Fusion Middleware Understanding Security for Oracle WebLogic Server

• Chapter 16, "Developing Authentication".

14.3.3 Programmatic Authorization

This example shows a JavaEE application that uses portable, fine-grained authorization.

Figure 14-4 Fine-grained Authorization

Key features include:

• authorization through JpsAuth.checkPermission API calls

• auditing of authorization decisions

14.3.4 Credential Store Framework

This example shows an application that needs to access and store credentials for an external system such as a database.

Figure 14-5 Storing External Passwords in Credential Store Framework

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

14.3.5 User and Role

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.

Figure 14-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.

• same API regardless of where the attributes are stored

14.3.6 Oracle ADF Authorization

For an example of authorization using Oracle ADF, see Section 14.4.2, "How Oracle ADF Uses OPSS".

14.3.7 JavaSE Application

This example shows a JavaSE Swing application using different OPSS APIs.

Figure 14-7 JavaSE Application using 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

14.4 Using OPSS with Oracle Application Development Framework

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.

14.4.1 About Oracle ADF

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.

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

See Also:

Chapter 7, "Deploying Secure Applications"

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.

Figure 14-8 Oracle ADF using JpsAuth.checkPermission

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:

• ADF Security in the Oracle Fusion Middleware Security Overview

• Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework

14.4.3 The Oracle ADF Development Life Cycle

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.

Figure 14-9 Oracle ADF Application Deployed to Oracle WebLogic Server

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 WLST

  Note:

  For more information about deployment tools and options, see Chapter 7, "Deploying Secure Applications".

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

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

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

For more information about this topic, see Chapter 15, "Manually Configuring JavaEE Applications to Use OPSS".