This chapter describes how you can develop, deploy, and administer secure Java EE applications in Oracle JDeveloper.
This chapter includes the following sections:
Section 18.3, "About Web Application Security and JDeveloper Support"
Section 18.4, "Handling User Authentication in Web Applications"
Section 18.5, "Securing Application Resources in Web Applications"
Section 18.6, "Configuring an Application-Level Policy Store"
The Fusion Middleware Suite lets you develop, deploy, and administer secure applications. You can secure Java EE applications using only container-managed security or, for Fusion web applications, you can use Oracle ADF Security. Fusion web applications are Java EE applications that you develop using the Oracle Application Development Framework (Oracle ADF).
A Java EE application can be enhanced to use OPSS. In this scenario, you work with JDeveloper's declarative editors to configure users and roles. You secure application resources using Java EE container-managed security.
This scenario is a fully declarative implementation that adds ADF Security to enable fine-grained security policies for Oracle ADF resources. You work with JDeveloper's declarative editors to configure a file-based identity store, policy store, and credential store; and, because your application utilizes Oracle ADF, you also run a wizard to configure security for web pages associated with ADF resources (such as ADF task flows and ADF page definitions) and then use the jazn-data.xml policy editor to define security policies.
The Java EE security model is a role-based, declarative model based on container-managed security, where resources are protected by roles that are assigned to users. This model allows decoupling an application from its underlying security infrastructure since security can be specified separately from the application logic in an application deployment descriptor. The container, where an application runs, provides security for the application according to a specifications in the deployment descriptor. This model also allows embedding security data (annotations) in the application code that can be referenced in deployment descriptors.
For more information about container-managed security, see the Oracle Fusion Middleware Security Guide.
The Oracle ADF Security framework is the preferred technology to provide authentication and authorization services to the Fusion web application. A prime reason is that 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.
For more information about Oracle ADF security, see the ”Enabling ADF Security in a Fusion Web Application” chapter of the Oracle Fusion Middleware Developer's Guide for ADF.
For more information on OPSS, see the Oracle Fusion Middleware Application Security Guide.
When developing secure applications in JDeveloper it is often useful to think of development and deployment (to the production environment) as different phases, each with different needs. This is because during development and testing, JDeveloper supports easy to manage file-based security through integration with Oracle Platform Security Services (OPSS).
JDeveloper simplifies the application development life-cycle for security, and allows you to store the data in a flat file, for easy development. The jazn-data.xml file is JDeveloper's default file-based security provider for integration with OPSS. The jazn-data.xml file stores the users, groups, roles, and policies that you define the Fusion web application built using the Oracle Application Development Framework (Oracle ADF) and Oracle ADF Security. JDeveloper provides a dedicated editor for this file that simplifies creating the security data stores.
A feature of OPSS is the abstraction of users defined by the production environment's enterprise roles into application roles that are specific to the functions of your application. During development the application developer adds application roles and security policies that use application roles to the policy store of the jazn-data.xml file. Then, to simplify testing, the developer may add a few users to the identity store and directly assign these test users to application roles. Therefore, for testing the application, the jazn-data.xml can also be used as the identity store.
During development, your application does not ned to be aware of the enterprise roles defined in the production environment. After deployment an administrator will use Oracle Enterprise Manager Fusion Middleware Control to map the production-level enterprise roles to the application roles of your application's policy store. This mapping will allow a user who is a member of a given enterprise role to have access to the resources that are accessible from the associated application role.
After you complete the application, you migrate the policy store to the production environment provider on Oracle WebLogic Server. At that point, you will replace your test user identity store with enterprise users configured in the Oracle WebLogic Server embedded LDAP server. In contrast to the jazn-data.xml file, the LDAP server supports a distributed application server configuration that may be employed in a production environment. For details about the LDAP server, see Administering Security for Oracle WebLogic Server.
Therefore, working with the file-based provider and OPSS in JDeveloper helps separate the demands of the production environment through:
Declaratively defining test users and application roles
Declaratively defining security policies for Oracle ADF resources
Easily migrating from application-level security provider to system-jazn-data.xml security provider during deployment
Delaying the mapping of enterprise roles until deployment
Java EE declarative security in Oracle WebLogic Server is implemented with Oracle Platform Security Services (OPSS), Oracle's implementation of the JAAS standard. OPSS extends Java EE security to provide application developers, system integrators, security administrators, and independent software vendors with a portable, integrated, and comprehensive security platform framework for Java SE and Java EE applications.
To learn more about OPSS and its features, see Oracle Fusion Middleware Security Guide.
JDeveloper provides tools to support configuring Java EE security for web applications and for deploying secure web applications to an application server instance. A developer, while developing an application, can configure OPSS services from JDeveloper through wizards and editors.
JDeveloper provides specific editors to create and edit Oracle Platform Security configurations (jps-config.xml), JAAS configurations (jazn-data.xml), and Web application deployment descriptors (web.xml). JDeveloper also supports direct deployment of web applications to application servers. For more information, see Section 18.2, "Securing Applications in Phases."
When you develop web applications you may choose to use Oracle Application Development Framework (Oracle ADF) to work with data-aware components in the user interface. When your user interface contains ADF resources, such as ADF task flows and ADF page definitions, then you have the option to secure the web pages that rely on those resources through the ADF Security framework. JDeveloper tools support iterative development of security so you can easily create, test, and edit security policies that you create for ADF resources. You can proceed to create test users in JDeveloper and run the application in Integrated WebLogic Server to simulate how end users will access the secured resources. For more information, see. Section 18.5.2, "How to Secure ADF Resources Using ADF Security in Fusion Web Applications."
For more information on web application security, see Oracle Fusion Middleware Programming Security for Oracle WebLogic Server.
Authentication in declarative security is enforced when a user requests a protected web application area.
Authentication in declarative security is enforced when a user requests a protected web application area. If the user has not been authenticated before, the container will retrieve credentials from the user. Users stay authenticated throughout the server session.
The supported types of authentication are: FORM based authentication, BASIC authentication, and CLIENT-CERT authentication. The type of authentication is specified in the web.xml deployment descriptor using the <login-config> element.
BASIC authentication uses the browser login dialog for the user to enter his user name and password. This dialog form cannot be customized and thus varies in its look and feel depending on the type of browser used. The user credentials are stored in the browser session for the authenticated realm. A realm is a repository that contains a set of permissions for the authenticated user. The default realm in Oracle Platform Security Services is jazn.com.
The code snippet in Example 18-1 demonstrates how BASIC authentication is specified in the web.xml file:
FORM based authentication allows the application developer to specify a custom login dialog. The username parameter must have a name of j_username, the password field must be named j_password. The login form action must have a value of j_security_check for the Java EE container to authenticate the request.
The code snippet in Example 18-2 demonstrates how FORM authentication is specified in the web.xml file:
CLIENT-CERT authentication uses the X.509 certificate to authenticate users. This type of authentication is also known as public key encryption.
For more information about authentication type choices, see the Oracle Fusion Middleware Security Guide.
For more information about authentication type using Oracle WebLogic Server, see Oracle Fusion Middleware Programming Security for Oracle WebLogic Server.
As password encryption is specific to a WebLogic Server domain, you must manually add the password handling to the weblogic-jdbc.xml file. To encrypt a password, use the encrypt utility (weblogic.security.Encrypt) for the domain to which you want to deploy.
Note:
Passwords are domain-specific, so each time you want to deploy to a different domain you must re-encrypt the password for the target domainThe XML code you need to add to the weblogic-jdbc.xml should look something like this:
<password-encrypted>toystore</password-encrypted>
You can either put the clear text password or the encrypted password string in between the tags. This element goes inside of the <jdbc-driver-params> element, which will already be present in the weblogic-jdbc.xml if it has been edited using the Overview Editor.
The weblogic.security.Encrypt utility encrypts cleartext strings for use with WebLogic Server. The utility uses the encryption service of the current directory, or the encryption service for a specified WebLogic Server domain root directory.
Note:
An encrypted string must have been encrypted by the encryption service in the WebLogic Server domain where it will be used. If not, the server will not be able to decrypt the string.You can only run the weblogic.security.Encrypt utility on a machine that has at least one server instance in a WebLogic Server domain; it cannot be run from a client. Table 18-1 defines the arguments for the weblogic.security.Encrypt utility.
Note:
It is recommended that you run the utility from the Administration Server domain directory or on the machine hosting the Administration Server and specifying a domain root directory.java [ -Dweblogic.RootDirectory= dirname ] [ -Dweblogic.management.allowPasswordEcho=true ] weblogic.security.Encrypt [ password ]
Table 18-1 Arguments for the weblogic.security.Encrypt utility
| Argument | Definition |
|---|---|
|
|
Optional. WebLogic Server domain directory in which the encrypted string will be used. If not specified, the default domain root directory is the current directory (the directory in which the utility is being run). |
|
|
Optional. Allows echoing characters entered on the command line. weblogic.security. Encrypt expects that no-echo is available; if no-echo is not available, set this property to true. |
|
|
Optional. Cleartext string to be encrypted. If omitted from the command line, you will be prompted to enter a password. |
The utility returns an encrypted string using the encryption service of the domain located in the current directory:
java weblogic.security.Encrypt xxxxxx {3DES}Rd39isn4LLuF884Ns
The utility returns an encrypted string using the encryption service of the specified domain location:
java -Dweblogic.RootDirectory=./mydomain weblogic.security.Encrypt xxxxxx {3DES}hsikci118SKFnnw
The utility returns an encrypted string in the current directory, without echoing the password:
java weblogic.security.Encrypt Password: {3DES}12hsIIn56KKKs3
An identity store is a data store of users, enterprise roles (user groups), and login credentials. The credentials are verified during authentication and used to authorize the user's access to application functions.
Understanding Users, Roles, and Realms
A user is an end user accessing a service; it could be an individual or a software component. A enterprise role is a collection of users that you group with the purpose of conferring the same set of permissions. A realm is a collection of authenticated users and enterprise roles.
For more information about users, enterprise roles, and realms, see the Oracle Fusion Middleware Security Guide.
Understanding Identity Stores in JDeveloper
When you develop secure applications in JDeveloper, you work with a file-based data store to define the users you wish to allow to log on. The advantage of defining a file-based identity store through the jazn-data.xml file is that it supports easy testing yet remains compatible with deployment to your production environment through migration to the system-jazn-data.xml file. It also avoids the complexity of setting up and maintaining an Oracle Internet Directory service for the LDAP-based identity store.
When you create a Fusion web application with Oracle ADF, the identity store will be created automatically when you run the Configure ADF Security wizard.
Note:
The LDAP-based identity store is a design time feature in JDeveloper, and is not available at runtime. JDeveloper's Integrated WebLogic Server overrides any LDAP identity store configuration.For more information about identity stores, see the Oracle Fusion Middleware Security Guide.
Double-click the jps-config.xml file in the Descriptors > META-INF folder in the Application Resources panel of the Applications window.
Select the Identity Store tab in the jps-config.xml Overview Editor.
Click the Add a New Identity Store icon at the top of the page. The Create Identity Store dialog opens.
Choose the desired type of identity store option:
To create a file based identity store, choose XML-Based Identity Store, and enter the name for the store. By default, the file name is idstore.xml.
To create an LDAP based identity store, choose LDAP-Based Identity Store, and enter the name for the store. By default, the file name is idstore.oid.
Note: The LDAP-based identity store is a design time feature in JDeveloper, and is not available at runtime. The Integrated WebLogic Server in JDeveloper overrides any LDAP identity store configuration.
When you are done, click OK to close the dialog.
The identity store is an XML file and is used while authenticating users. There can be an identity store at either the domain or application level.
To add users to the identity store:
Open the application in the Applications window.
Choose Application > Secure > Users to open the overview editor for the jazn-data.xml file.
On the Users page, click the New User icon.
Enter the new user name and password.
Select the user from the Users list and enter further details, such as display name and description.
Save your changes to the jazn-data.xml file.
An enterprise role is a set of users that you group with the intention of conferring the same permission grants. You add enterprise roles to the identity store. You add application roles to the policy store.
Note:
Before adding a user to an enterprise role, ensure that you have created users in the identity storeYou can add roles to the identity store using the overview editor for the jazn-data.xml file.
To add roles to the identity store:
Open your application in the Applications window.
Choose Application > Secure > Groups to open the Enterprise Roles page of the overview editor for the jazn-data.xml file.
Under Enterprise Roles, click the New Role icon. The new role appears in the Enterprise Roles list.
Select the role from the Enterprise Roles list and enter further details, such as display name and description.
You can manage roles in the identity store using the overview editor for the jazn-data.xml file.
To manage users assigned to enterprise roles:
Open the Enterprise Roles page of the overview editor for jazn-data.xml file.
Select the role from the Enterprise Roles list, and then click the Members tab.
In the Members section, add or remove other members or roles.
You can view assigned roles in the identity store using the overview editor for the jazn-data.xml file.
To view assigned enterprise roles:
Open the Enterprise Roles page of the overview editor for the jazn-data.xml file.
Select the role from the Roles list, and then click the Assigned Roles tab.
A credential store is a wallet-based file for storage of system credentials required by Oracle Platform Security Services (OPSS) in connecting to external systems such as databases. In JDeveloper, the credential store is the cwallet.sso file. The file contains all your OPSS-based credentials, and will be used in JDeveloper to store credentials that you define for Oracle ADF security. This file is normally not edited directly.
JDeveloper checks for the existence of a credential store service instance and creates the store the first time the you create a connection, for example, a database connection, in the Application Resources panel of the Applications window.
For more information about credential stores, see the Oracle Fusion Middleware Security Guide.
Double-click the jps-config.xml file in the Descriptors > META-INF folder in the Application Resources panel of the Applications window.
Select the Credential Store tab in the jps-config.xml Overview Editor.
Click the Add the Credential Store icon at the top of the page. The Create Credential Store dialog opens.
Enter the name of credential store file, and click OK.
Note:
You can create only one credential store in an application.A login module is a component that authenticates users and populates a subject with principals. Login modules can be plugged in and used by applications without changing application code. An application can use more than one login module.
The login authentication process occurs in two distinct phases:
The login module attempts to authenticate a user requesting, as necessary, a name and a password or some other credential data; only if this phase succeeds, the second phase is invoked.
The login module assigns relevant principals to a subject, which is eventually used to perform some privileged action.
All login modules in a domain are configured in the file jps-config.xml using the following elements:
serviceProvider — to define a service provider for the login module.
serviceInstance — to define one or more instances of the service provider
jpsContext — to specify which instances to use
In JDeveloper, you can choose a pre-defined login module for your application, or create a new custom login module. Table 18-2 contains the pre-defined login modules that are available in JDeveloper:
Table 18-2 Predefined Login Modules
| Module | Description |
|---|---|
|
|
Used for SAML token assertion and implements the |
|
|
Used for Kerberos token assertion and implements |
|
wss.digest.loginmodule |
Used to authenticate the digest based user name token based on WSS Digest specification and implements |
|
certificate.authenticator. |
Used to assert the X509 certificates and implements |
|
|
Used to authenticate the user based on valid user name and password, and implements |
|
user.assertion.loginmodule |
Used to authenticate the user based on valid user name and password, and implements |
|
|
Used to authenticate JSE bases use cases and implements |
For more information about login modules, see the Oracle Fusion Middleware Security Guide.
Double-click the jps-config.xml file in the Descriptors > META-INF folder in the Application Resources panel of the Applications window.
Select the Login Modules tab in the jps-config.xml Overview Editor.
Click the Choose from a list of pre-defined Login Modules icon at the top of the page. The Add Login Modules dialog appears.
Select the checkbox of login modules you want to add. You can add more than one login module in an application.
Click OK when you are done.
A key Oracle Platform Security component is the login service. Conceptually, the login service is an adapter that ties the JAAS login module SPI (javax.security.auth.spi.LoginModule) to the Oracle Platform Security for Java framework (OPSS).
The primary role of the login service is to enable JAAS login module implementations to be configured and used in OPSS.
Double-click the jps-config.xml file in the Descriptors > META-INF folder in the Application Resources panel of the Applications window.
Select the Login Modules tab in the jps-config.xml Overview Editor.
Click the Create New Login Module button at the top of the page.
Enter the Login Module Name then click OK.
Enter the classname for the login module. To search for an existing classname available to the project, click the Search button.
Select the Login Control Flag. This can be: REQUISITE, REQUIRED, SUFFICIENT, or OPTIONAL.
Select the Log Level. This can be: FINE, FINER, FINEST, CONFIG, INFO, WARNING, SEVERE.
Click Debug to define whether the login module will output debug messages.
Select Add All Roles to define whether all directly or indirectly granted roles of the user are added to the subject after authentication using the login module.
Enter the names and values for any other properties required by the login modules.
A keystore is a repository of private keys and digital certificates.
If you have keys and certificates and wish to use them for secure services in your application, JDeveloper allows you to import a Java Key Store, Oracle Wallet (from a *.sso or *.p12 file), or PCKS12 file (from a *.p12 file). You cannot create a keystore in JDeveloper.
For more information about key stores and key store providers, see the Understanding Security for Oracle WebLogic Server guide.
Double-click the jps-config.xml file in the Descriptors > META-INF folder in the Application Resources panel of the Applications window.
Select the Key Stores tab in the jps-config.xml Overview Editor.
Click the Add a Key Store icon at the top of the page.
The Add Key Store dialog appears.
Import the keystore file and complete the required fields.
You can import a Java Key Store (from a *.jks file), Oracle Wallet (from a *.sso or *.p12 file), or PCKS12 (from a *.p12 file) file as a key store.
Click OK when you are done.
The anonymous provider is an alternative to public pages in that unauthenticated user access can have permissions assigned that are more fine grained than allowing access to the whole (public) page.
Enabling the anonymous provider creates an anonymous JpsContext, which contains the anonymous service instance and the anonymous login module. Anonymous credentials will be used at runtime when the application user has not been authenticated and the application allows some resources to be accessible without authentication.
For more information about the anonymous provider, see the Oracle Fusion Middleware Security Guide.
To enable an anonymous provider for a web application:
Double-click the jps-config.xml file in the Descriptors > META-INF folder in the Application Resources panel of the Applications window.
Select the Anonymous Provider tab in the jps-config.xml Overview Editor.
Select Enable Anonymous Provider.
Select the Security Contexts tab and ensure that anonymous is automatically chosen as the Anonymous Provider.
Credentials contain the authentication password for a user. The credentials appear in obfuscated form by default. Before adding credentials in the identity store, the member users must first be defined for the identity store.
To add credentials to users in the identity store:
Open the application in the Applications window.
Choose Application > Secure > Users to open the Users page of the overview editor for jazn-data.xml.
Select a user in the Users list, and add credentials to the Password field.
Authentication in declarative security is enforced when a user requests a protected web application area. If the user has not been authenticated before, the container will retrieve credentials from the user. Users stay authenticated throughout the server session.
The supported types of authentication are: FORM based authentication, BASIC authentication, and CLIENT-CERT authentication. The type of authentication is specified in the web.xml deployment descriptor using the <login-config> element.
For more information on authentication types, see Section 18.4.1, "About Authentication Type Choices".
To select the authentication type for the web application:
Double-click the web.xml for the application in the Applications window.
Click the Security tab of the web.xml Overview Editor.
Expand the Login Authentication section and select the desired authentication type.
Web pages and other resources of the web application should be secured. Depending on the type of application, you can secure your application in one of the two following ways:
For a Java EE web application, use Oracle Platform Security Services (OPSS) to secure your web application.
For an application developed using Oracle Application Development Framework (ADF), use Oracle ADF Security to secure your application.
The following tasks outline the process of securing an application using Java EE security:
Specifying an authentication mechanism for users.
Managing users and groups in the realm.
Creating security roles for the application.
Mapping roles to users and groups.
You can use the Oracle ADF Security framework to provide authentication and authorization services to the Fusion web application.
For more information about Oracle ADF security, see the ”Enabling ADF Security in a Fusion Web Application” chapter of the Oracle Fusion Developer's Guide for ADF.
JDeveloper enables you to secure your application resource types. The resource types can be known, that is, recognized by JDeveloper, or you can create your own resource type.
A resource type represents the type of a secured artifact, such as a flow, a job, or a web service, and, essentially, it is a template for creating resources of a particular type. All resources have an associated type and are filtered or grouped according to type.
To secure an application resource:
Open the application in the Applications window.
In the main menu, choose Application > Secure > Resource Grants to open the Resource Grants page in the overview editor for the jazn-data.xml file.
In the Resource Type dropdown list, select the resource type you want to secure, for example, Task Flow. The list will display all the resource types available in the selected projects. You can also create a new resource type.
Click the Select Source Project icon to select the source project. Instances of the selected resource type from the selected source projects will be displayed in the Resources list.
Add the grantees (application roles, enterprise roles, or code sources) that will be granted the resource permissions. You can grant resource permissions to users, application roles, enterprise roles, and code sources. Click the Add Grantee icon in the Granted To list to add grantees.
In the Actions list, select the actions that will be allowed on the resource.
Save your changes to the jazn-data.xml file.
Security policies that you define in a Fusion web application support fine-grained access control for ADF security-aware resources, including ADF task flows and ADF page definitions. To enable ADF security policies, you begin by running the Configure ADF Security wizard on the user interface project.
After you enable ADF Security you must grant users access rights so that they may view the web pages of the Fusion web application. Access rights that you grant users are known as a security policy that you specify for the page's corresponding ADF security-aware resource. Ultimately, it is the security policy on the ADF resource that controls the user's ability to enter a task flow or view a web page:
Do not define security policies for the individual web pages of a bounded task flow. When the user accesses the bounded task flow, security for all pages will be managed by the permissions you grant to the task flow. And, because the individual web pages (with associated page definitions) will be inaccessible by default, ADF Security prevents users from directly accessing the pages of the task flow. This supports a well-defined security model for task flows that enforces a single entry point for all users.
Do define security policies for the individual web page only when the page is not a constituent of a bounded task flow. Page-level security is checked for pages that have an associated page definition binding file only if the page is directly accessed or if it is accessed in an unbounded task flow.
ADF security policies are maintained in the file-based jazn-data.xml policy store. Defining and updating ADF security policies in JDeveloper is supported by the overview editor for this file. The resulting declarative ADF security policies are easy to read.
The detailed steps for securing Oracle ADF resources are in the ”Enabling ADF Security in a Fusion Web Application” chapter of the Oracle Fusion Developer's Guide for ADF.
To define security policies for ADF resources:
Enforce ADF Security for the application by running the Configure ADF Security wizard.
Add application role names to the policy store.
Grant permission on the entire set of web pages contained in an ADF bounded task flows.
Grant permission on top-level web pages that are associated with an ADF page definition file and that are not associated with a bounded task flow.
If your application contains top-level web pages that are not associated with an ADF resource because they do not contain data-aware components, you can optionally secure these pages too.
If necessary, grant permission on rows of data that are defined by an ADF entity object.
Provision the identity store by adding the users who will login to test security.
Associate the test users you created with one or more application roles.
A Policy Store is the repository of application and enterprise policies. A policy specifies the permissions granted to code running from a specific location.
An Application Policy Store is a repository of application policies together with application roles, application policies, principals, and permissions. Application roles can include application users and roles, and roles specific to the application (such as administrative roles). A policy can use any of these roles or users as principals. Similarly, a System Policy store is a repository of system policies, principals, and permissions. A system policy store does not contain roles.
When you create a Fusion web application with Oracle ADF, the policy store will be created automatically when you run the Configure ADF Security wizard.
The difference between an application policy store and a system policy store is in their scope. An application policy store is constrained within an application limiting it's accessibility, where as a system policy store can be accessed openly.
For more information on policy stores, see the Oracle Fusion Middleware Security Guide.
A Principal is an identity assigned to an entity; the entity could be a user or a role. A Permission is a set of operations allowed for a group of entities; the entity could be a principal too. A Grant, or a custom policy, includes permissions and principals. In JDeveloper, you cannot create a principal or a permission without creating a grant.
Application roles are specific to an application and defined in the application policy store. They are used by the application directly (either a Java SE or Java EE application) and are not necessarily known to the Java EE container. In the file-based policy store in a jazn-data.xml file, these application roles are defined in <app-role> elements under <policy-store>, and then written to system-jazn-data.xml at the domain level during deployment.
To add application roles to the application policy store:
Open the application in the Applications window.
Choose Application > Secure > Application Roles to open the Application Roles page of the overview editor for the jazn-data.xml file.
Click the Add icon to create a new application role as a peer or child of the currently selected role, or to create a new role category. The new application role or category is listed in the Roles list.
Enter details of the role or role category in the Name, Display Name, and Description fields.
Save your changes to the jazn-data.xml file.
For more information, see the Oracle Fusion Middleware Securing Resources Using Roles and Policies for Oracle WebLogic Server guide.
Deployment users and roles are defined in the security provider that you use. For the file-based provider, deployment users and roles are defined in the jazn-data.xml file.
Note:
Before adding member users or member roles to an application role, the member users and member roles must first be defined for the identity store.To add users or enterprise roles to an application role:
Open the application in the Applications window.
Choose Application > Secure > Application Roles to open the Application Roles page in the overview editor for the jazn-data.xml file.
From the Application Roles list, select the application role, and then click the Members tab.
To add a user, under Member Users and Roles, click the Add User or Role icon, and select Add User.
To add an enterprise role, under Member Users and Roles, click the Add User or Role icon, and select Add Enterprise Role.
Save your changes to the jazn-data.xml file.
You can create custom resource types and specify them in the jazn-data.xml file.
A resource type represents the type of a secured artifact, such as a flow, a job, or a web service, and, essentially, it is a template for creating resources of a particular type. All resources have an associated type and are filtered or grouped according to type.
To create a custom resource type:
Open your application in the Applications window.
Choose Application > Secure > Resource Grants to open the Resource Grants page of the overview editor for the jazn-data.xml file.
In the Resource Grants page, click the New Resource Type icon next to the Resource Type field.
In the Create Resource Type dialog, specify the properties of the resource, such as name, display name, and associated actions. The Actions list in the Create Resource Type dialog is used to populate the checkable items list in the Resource Grants page for resources of this type.
Save the jazn-data.xml file.
You can add application resource grants to an application policy store by updating the Resource Grants page of the overview editor for jazn-data.xml.
A resource is an instance of a resource type that represents a concrete resource; it defines an application resource that can be secured by a policy, such as software components managed by a container (for example, URLs, EJBs, JSPs) or an application business (for example, Reports, Transactions, Revenue Charts).
To add a resource grant for the application policy store:
Open your application in the Applications window.
Choose Application > Secure > Resource Grants to open the Resource Grants page of the overview editor for the jazn-data.xml file.
To define the security policy, select an item in the Security Policy field. The application security policy is selected by default. To define global resource grants, select Global.
Select the resource type from the Resource Type dropdown menu, or click the New Resource Type icon to create one.
For the resource types that are filtered by project, the Source Project selector is enabled. You may need to change the source project selection to find the desired resources.
The resources that belong to the selected resource type are listed in the Resources list.
Manage the entities that the resource permissions have been granted to, by clicking the Add Grantee icon in the Granted To list. You can grant to an application role, a user, an enterprise role, or a code source.
View and select the actions allowed on the resource in the Actions list.
Using the Entitlement Grants page of the overview editor for jazn-data.xml, you can define a set of resource permissions and grant those permissions to multiple application roles without having to grant each permission to each application role individually.
An entitlement is a collection of permissions. Typically, it encapsulates the list of permissions needed to perform a given business function or task.
To add entitlement grants to an application policy store:
Open your application in the Applications window.
In the main menu, choose Application > Secure > Entitlement Grants to open the Entitlement Grants page in the overview editor for the jazn-data.xml file.
To add an entitlement, click the Add Entitlement icon in the Entitlements list.
To add a member resource, click Resources, and in the Member Resources list, click the Add Member Resource icon.
To select the application role to grant the entitlement to, select Grants and then click the Add Role Grant icon. In the Select Application Roles dialog, you can select an application role or create a new one.
Save the jazn-data.xml file.
Tips:
You can view grants to resources that are members of an entitlement group in the Resource Grants page by clicking the Show Grants from Entitlements icon in the Granted To column. This option is selected by default.
You can also add member resources to new or existing entitlements from the context menu in the Resource Grants page.
A new permission class is useful when you want to create your own JAAS permission for a logical artifact type to secure. For example, although Oracle ADF already provides built-in permission classes for the artifacts on which it enforces security (including task flows, page definitions, entity objects, and entity attributes), you might create a custom permission class for a set of UI components that you want to secure in the user interface. Once this class is created, you can add enforcement checks using Java, Expression Language (EL), or embedded Groovy expressions, and then you can grant the new custom permission class to application roles by editing the jazn-data.xml file directly. For example, you could define a security policy to limit access to a menu that your application displays and then associate the rendering of the menu with the user's granted custom permission using the EL value userGrantedPermission on the component's rendered property.
To create a custom JAAS-compliant permission class:
Open your application in the Applications window.
From the main menu, select File > New to open the New Gallery.
In the New Gallery, under Categories, select Business Tier > Security.
Under Items, select JAAS Permission.
In the Create JAAS Permission dialog, enter the details of the custom permission class. For any help from within the dialog, click Help or press F1.
Currently, this release does not provide an editor to add system permission grants to a system policy store; you will need to manually add grants in the source code for jazn-data.xml.
To add a grant to the system policy:
Open your application in the Applications window.
In the Applications window, double-click the jazn-data.xml to open the overview editor.
Click Source to open the source editor.
In the source code, inside the <jazn-data> element, create a <jazn-policy> element.
Inside the <jazn-policy> element create a <grant> element that defines the <grantee> with the desired application role and the <permission> with the fully qualified class name of the permission class, the name that you want to use as the target for the grant, and the action that you want to grant to the application role principal.
Save changes to the jazn-data.xml file.
JDeveloper is configured by default to deploy the security objects from your application repositories to Integrated WebLogic Server each time you run the application. You can change this behavior by selecting security deployment options in the Application Properties dialog to:
Decide whether to overwrite the domain-level policies with those from the application jazn-data.xml file.
Decide whether to overwrite the system credentials from the application's cwallet.sso file.
Decide whether to migrate the identity store portion of the jazn-data.xml file to the domain-level identity store.
If you make no changes to the deployment settings, each time you run the application, JDeveloper will overwrite the domain-level security policies and system credentials. Additionally, JDeveloper will migrate new user identities you create for test purposes and update existing user passwords in the embedded LDAP server that Integrated WebLogic Server uses for its identity store. However, if you prefer to run the application without updating the existing security objects in Integrated WebLogic Server, you have this option.
When you are ready to deploy the application to standalone Oracle WebLogic Server, you can use the same configuration settings to control how JDeveloper handles migration of the security objects.
To configure deployment of security objects:
Choose Application > Secure > Configure Security Deployment to open the Application Properties dialog.
In the Application Properties dialog, under Security Deployment Options, select the security objects that you want to deploy with the application.
By default, each time your run the application, JDeveloper will overwrite the application policies and credentials at the domain level with those from the application. If you prefer not to overwrite either of these repositories, deselect Application Policies or Credentials. When deselected, JDeveloper will merge only new policies or credentials into the domain-level stores. For further details, see the sections below.
By default, each time you run the application, JDeveloper will migrate new user identities you create for test purposes and update existing user passwords in the embedded LDAP server that Integrated WebLogic Server uses for its identity store. You can disable migration of the application identity store by deselecting Users and Groups. For further details, see the sections below.
Click OK.
Application policies, specified in jazn-data.xml, can be migrated to a domain policy store when the application is deployed to a server in the Oracle WebLogic Server environment. If desired, the policies can also be removed from the domain policy store when the application is undeployed, or updated when the application is redeployed.
If Application Policies is selected in the Application Properties dialog, a jps.policystore.migration property is set to OVERWRITE in the packaged weblogic-application.xml when you deploy the application using JDeveloper. If Application Policies is unselected, the jps.policystore.migration setting will not be added to the packaged weblogic-application.xml, and will be removed if it is already present. This causes the default operation MERGE to be used by Oracle WebLogic Server. Merge will only migrate policies the first time the application is deployed if they do not already exist. If the policies for the application already exist, they will not be remigrated.
To find out more about automatic and manual migration of application policies, see the Oracle Fusion Middleware Security Guide.
When you migrate your application policies, you might also want to migrate your credentials. Application credentials, specified in cwallet.sso, can be migrated to a domain credential store when the application is deployed or redeployed to a managed server in the WebLogic environment. Thus, credential migration includes the passwords for all connections created within JDeveloper, including those created for web services. (This is not related to user credentials specified in the identity store of the jazn-data.xml file. See Section 18.7.4, "Migrating Users and Groups" below for details about identity store migration.)
If Credentials is selected in the Application Properties dialog, a jps.policystore.migration property is set to OVERWRITE in the packaged weblogic-application.xml when you deploy the application in JDeveloper. If Credentials is unselected, the jps.policystore.migration setting will not be added to the packaged weblogic-application.xml, and will be removed if it is already present. This causes the default operation MERGE to be used by Oracle WebLogic Server. Merge will only migrate credentials the first time the application is deployed if they do not already exist. If the credentials for the application already exist, they will not be remigrated.
The credential migration is possible only when the server is running in development mode only. In production mode, credential overwrite is prohibited. Application credentials must be manually migrated when you deploy using tools outside of JDeveloper.
Users and roles, specified in jazn-data.xml, can be migrated to a domain identity store when the application is deployed to a server in the WebLogic environment.
If Users and Groups is selected in the Application Properties dialog, JDeveloper will make calls when you deploy the application to create Oracle WebLogic Server users and groups corresponding to the application's jazn-data.xml users and role. If the user already exists in the domain store, only the description and password will be remigrated during deployment. If a group exists in the domain store with the same name as the roles in the jazn-data.xml file, it will be replaced entirely. If Users and Groups is unselected, JDeveloper will not try to migrate the identity store from the application jazn-data.xml.
Note:
Before migrating users and groups ensure that administrator roles (admin) and users (weblogic) are not used in the application jazn-data.xml file so that the domain identity store is not overwritten. When your application is ready for deployment to a production environment, you should remove the identities from the jazn-data.xml file or disable the migration of identities by deselecting Users and Groups from the Application Properties dialog.A JDBC database connection created in JDeveloper derives its encryption properties from the database client install on your machine. To create a secure connection using JDBC:
Configure encryption support using the OCI driver by setting parameters in the sqlnet.ora file on your client machine.
Use the thin JDBC driver to create a secure JDBC connection in JDeveloper. To do this, select Enter Custom JDBC URL in step 3 (Connection page) of the Create Database Connection Wizard, then enter your encryption parameters as part of a custom JDBC URL, as shown in Example 18-3.
Example 18-3 Encryption Parameters
jdbc:oracle:thin:@(description =(address=(protocol=tcp)(host=myhost)(port=1521))(connect_data= (sid=ORCL)(SQLNET.ENCRYPTION_CLIENT=REQUIRED)(SQLNET.ENCRYPTION_TYPES_ CLIENT=DES40)(SQLNET.CRYPTO_CHECKSUM_CLIENT=REQUESTED) (SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENTMD5=MD5) ))