Terminology Oracle Fusion Middleware Online Documentation Library

18-8 Oracle Fusion Middleware Application Security Guide For details about integration, see Integrating Authorization . For further information about programmatic authorization, see also Chapter 22, Authentication for Java SE Applicaitons.

18.6.4 User and Role Management

An application integrating with OPSS must use the User and Role API to manage users and external roles programmatically. This API facilitates the use of identity services without the developer having to know low-level details such as the location of a user account or the particular physical implementation of roles. The User and Role API supports the following operations: ■ Create, update, delete, modify, get attributes, and change password on a user profile. ■ Create, update, delete, modify, and get attributes on a role. For details about the User and Role API, see Chapter 25, Developing with the User and Role API.

18.7 Integrating Authentication

This section explains the most important points of the following topics: ■ Container-Based Authentication ■ Oracle WebLogic Server Authentication Providers ■ Programmatic Authentication ■ Single Sign-On through OPSS

18.7.1 Container-Based Authentication

To enable user authentication during the development phase, developers run the ADF security wizard that generates the necessary OPSS configuration and specify authentication methods in the application deployment descriptor web.xml. At run time, the container authenticates the end user of an application in one of the following ways: basic, form, or client cert. In most situations, form-based authentication is the appropriate choice. The container obtains the authentication data such as user name and password from the user, which is processed by the Oracle WebLogic Server to establish a user session. OPSS then queries Oracle WebLogic Server for the authenticated subject when a protected resource is to be accessed.

18.7.2 Oracle WebLogic Server Authentication Providers

OPSS uses authentication providers available in Oracle WebLogic Server. These providers validate user credentials or system processes based on a user name-password combination or a digital certificate. They also make user identity information available through subjects to other components in a domain when needed. Available authentication providers include the Default Authenticator and the external LDAP stores. For details, see section Authentication Providers in Oracle Fusion Middleware Developing Security Providers for Oracle WebLogic Server. Integrating Java EE Application Security with OPSS 18-9

18.7.3 Programmatic Authentication

In addition to container-managed authentication, OPSS allows programmatic authentication through the LoginService, an API that enable applications authenticating user credentials and establishing a principal. Once the principal has been established, the LoginService API creates a subject with principals corresponding to the authenticated user, the authenticated role, and the application roles of which the user is a member. This subject is then used to perform privileged actions. Additionally, OPSS also provides an API for identity and token assertion. Typically, Java SE applications require programmatic authentication; in contrast, Java EE applications do not have such a requirement.

18.7.4 Single Sign-On through OPSS

To enable applications to participate in an SSO environment, it is necessary to use an Identity Asserter built specifically for the SSO solution. The recommended solution, OAMOSSO, provides a dedicated Identity Asserter designed to work with the Oracle WebLogic Server. For details about configuring and managing SSO using the OAMOSSO solution, see Part IV, Single Sign-On Configuration

18.8 Integrating Authorization

Authorization protects access to application resources by enforcing policies, which determine what types of actions, tasks, or services a user can access. OPSS provides functional security for Java EE and ADF applications in the following authorization models: ■ Functional Security ■ Functional Security with ADF Both of these models provide fine-grained authorization capabilities to control access to application artifacts, such as the individual tasks one can perform in an application or the method one can invoke in a Java EE bean, according to the roles of which the user is a member.

18.8.1 Functional Security

Defining functional security starts at the early stages of the development phase. A product manager authors security functional data that is kept in a source code repository and that includes the definitions of application privileges, roles, the role hierarchy, and role categories. When using functional security, developers need not be concerned with users and roles; instead, they focus on wiring the application permissions usually defined by their respective product managers to application artifacts developed by them. Functional security supports the externalizing of users and enterprise roles, and enterprise administrators can use OIM to manage them.

18.8.1.1 The Functional Security Model

The functional security model is based on grants that use the resource catalog whose entities are described in Table 18–4 . 18-10 Oracle Fusion Middleware Application Security Guide Functional policies can be managed with Oracle Entitlements Server; for details, see Oracle Fusion Middleware Administrators Guide for Oracle Entitlements Server.

18.8.1.2 Checking Permissions with CheckPermission

In some cases, developers may need to check permissions programmatically. This check is carried out by calling the method checkPermission. For details on checking policies using checkPermision and other methods, see Section 20.3.3.1, Using the Method checkPermission.

18.8.2 Functional Security with ADF

Typically, developers implement application functional security with the declarative security model provided by ADF in Oracle JDeveloper; this model greatly simplifies security integration by hiding and separating most security details from the application-specific logic. In ADF, a functional security policy assigns permissions to secured artifacts, such as ADF task flows, pages, and regions; ADF facilitates this task by providing a user interface that lists the available permissions. To add a functional security grant to an applications using ADF, proceed as follows: 1. Check out jazn-data.xml, adf-config.xml, weblogic.xml, jps-config.xml, cwallet.sso, and web.xml; all these files must be writable. 2. Execute the ADF security wizard. 3. Enable anonymous access to all regions and task flows. This task creates the special role TEST-ALL with the anonymous user as a member. Permissions to all regions and task flows are then granted to the TEST-ALL role; this ensures that a non-authenticated user has access to all ADF artifacts in the application and that the application continues to work before security is defined for task flows and regions. 4. Grant permissions to privilege roles. Once the ADF security wizard has been run, the files listed in step 1 are created or updated. Then, a developer uses the authorization policy editor to grant privilege roles permission to task flows and regions. If a needed role is not available at that time, the developer must request that the product manager create the privilege role in the file jazn-data.xml. Then, the developer must be check out that file again to have the new role available. Table 18–4 Resource Catalog Entities Entity Description Comments and Examples Resource Type A type defined by a Java permission class which includes the set of actions allowed on an instance of the type. Examples: WebService, ADF TaskFlow, and Scheduled Jobs ESS Resource A instance of a resource type and a subset of the actions allowed by the resource type. Example: a Purchase Order TaskFlow with updating privileges. Purchase Order TaskFlow is a resource instance of the ADF TaskFlowresource type. Entitlement or permission set A set of resources and actions allowed on them.