This chapter includes the following sections:
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. s 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 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. 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 below demonstrates how BASIC authentication is specified in the web.xml
file:
<login-config> <auth-method>BASIC</auth-method> <realm-name>jazn.com</realm-name> </login-config>
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 below demonstrates how FORM authentication is specified in the web.xml
file:
<login-config> <auth-method>FORM</auth-method> <form-login-config> <form-login-page>loginform.jsp</form-login-page> <form-error-page>error.jsp</form-error-page> </form-login-config> </login-config>
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 domain
The 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 19-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.
Syntax
java [ -Dweblogic.RootDirectory= dirname ] [ -Dweblogic.management.allowPasswordEcho=true ] weblogic.security.Encrypt [ password ]
Table 19-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. |
Examples
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.
To create an identity store:
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:
jazn-data.xml
file.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 store
You can add roles to the identity store using the overview editor for the jazn-data.xml
file.
To add roles to the identity store:
jazn-data.xml
file.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:
jazn-data.xml
file.You can view assigned roles in the identity store using the overview editor for the jazn-data.xml
file.
To view assigned enterprise roles:
jazn-data.xml
file.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.
To create a credential store:
jps-config.xml
file in the Descriptors > META-INF folder in the Application Resources panel of the Applications window.jps-config.xml
Overview Editor.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 19-2 contains the pre-defined login modules that are available in JDeveloper:
Table 19-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. loginmodule |
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.
To add a login module:
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.
To add a custom login module:
jps-config.xml
file in the Descriptors > META-INF folder in the Application Resources panel of the Applications window.jps-config.xml
Overview Editor.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.
To add a key store:
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:
jps-config.xml
file in the Descriptors > META-INF folder in the Application Resources panel of the Applications window.jps-config.xml
Overview Editor.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:
jazn-data.xml
.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 About Authentication Type Choices.
To select the authentication type for the web application:
web.xml
for the application in the Applications window.web.xml
Overview Editor.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.
Using OPSS Security
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.
Using Oracle ADF Security
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:
jazn-data.xml
file.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:
jazn-data.xml
file.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:
jazn-data.xml
file.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:
jazn-data.xml
file.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:
jazn-data.xml
file.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:
jazn-data.xml
file.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:
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:
jazn-data.xml
to open the overview editor.<jazn-data>
element, create a <jazn-policy>
element.<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.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:
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 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.xm
l
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 below:
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) ))