OIM for User and Role Provisioning

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. Integrating Java EE Application Security with OPSS 18-11 For complete details about developing security in an ADF application, see chapter 29 in Oracle Fusion Middleware Fusion Developers Guide for Oracle Application Development Framework.

18.9 Integrating the Credential Store

Developers frequently are concerned with sensitive data necessary to operate the application or to access external services from it. The credential store, part of OPSS, is the repository of such data, and the CSF API allows an application accessing and operating on this data. Developers should not include clear text user names or passwords in applications; instead, this data should be stored in the credential store, and, when necessary, the application should access credentials programmatically using the CSF API. Administrators manage credentials using either the Fusion Middleware Control or OPSS scripts. Credentials are protected by code source permissions. Logically, credentials are grouped in maps or containers for a collection of credentials. Within a map, a credential is uniquely identified by its key. Thus, a credential is uniquely determined by a pair of map and key. It is recommended that the map name be the same as the application name to prevent name collision if multiple applications are deployed to the same domain and, therefore, use the same credential store. CSF is available for Java EE, Java SE, and C applications. For details about the credential store, see Chapter 24, Developing with the Credential Store Framework.

18.9.1 Guidelines for Using CSF

When working with CSF, a developer should follow the following guidelines: ■ Understand the CSF API. CSF is implemented by identifying the appropriate map and key names to use. This is particularly important in environments where multiple applications share the credential store. For details, see Section 24.6, Steps for Using the API. ■ Provision policies that allow access to credentials. These policies are kept in the policy store, which can be file-based system-jazn-data.xml or LDAP-based. Note the following important guidelines: – Application code that requires access to a credential must be packaged into the smallest possible jar. – That jar needs to be granted the CredentialAccessPermission on the specific map and key name with a specific set of actions. For details, see Section 24.3, Setting the Java Security Policy Permissions. – The grant must be specified in the application jazn-data.xml file, which is packaged with the application and migrated to the policy store when the application is deployed. Note: Developers should never change the security data kept in the source control. This recommendation includes not changing entitlements, application roles, the application role hierarchy, test enterprise roles, and test users.