Deploying Java EE and Oracle ADF Applications with Fusion Middleware Control

Deploying Secure Applications 6-7 ■ When deploying an application to multiple managed servers, be sure to include the administration server so that data is migrated as expected. ■ The reassociation of domain stores is an infrequent operation and, typically, takes place when the domain is set up before applications are deployed. For procedure details, see Section 8.5.1, Reassociating with Fusion Middleware Control.

6.3.1.1 Typical Administrative Tasks after Deployment in a Test Environment

At any time after an application is deployed in a test environment, an administrator can perform the following tasks using Fusion Middleware Control or the Administration Console: ■ Map application roles to enterprise groups. Until this mapping is accomplished, security does not work as expected. For procedure details, see Section 9.2.2, Managing Application Roles. ■ Create additional application roles or customize existing ones. For details, see Section 9.2.2, Managing Application Roles. ■ Manage system policies. For procedure details, see Section 9.2.3, Managing System Policies. ■ Manage credentials. For procedure details, see Section 10.2, Managing the Credential Store.

6.4 Deploying Standard Java EE Applications

There are two ways to secure Java EE applications that do not use OPSS but that use standard Java authorization: administratively, with the Administration Console or a OPSS script; or programmatically, with deployment descriptors. A Java EE application deployed to the Oracle WebLogic Server is a WebLogic resource. Therefore, an administrator would set security for the deployed application the same way that he would for any other resource. For details about deployment procedures, see section 8.3, Deploying and Undeploying Java EE Applications, in Oracle Fusion Middleware Administrators Guide. For details about deploying applications with WLST commands, see section Deployment Commands in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference. For an overview of WebLogic Server deployment features, see chapter Understanding WebLogic Server Deployment in Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Server. Notes: If the application is undeployed with Fusion Middleware Control from a server running in production mode, then the application-specific policies are automatically removed from the policy store. Otherwise, if you use any other tool to undeploy the application, then the removal of application-specific policies must be performed manually. Credentials are not deleted upon an application undeployment. A credential may have started it life as being packaged with an application, but when the application is undeployed credentials are not removed. 6-8 Oracle Fusion Middleware Application Security Guide Related Documentation Further information about securing application resources, can be found in the following documents: In Oracle Fusion Middleware Securing Resources Using Roles and Policies for Oracle WebLogic Server ■ Section Application Resources ■ Section Options for Securing Web Application and EJB Resources In Oracle Fusion Middleware Oracle WebLogic Server Administration Console Help: ■ Section Use Roles and Policies to Secure Resources In Oracle Fusion Middleware Securing WebLogic Web Services for Oracle WebLogic Server: ■ Section Overview of Web Services Security In Oracle Fusion Middleware Programming Security for Oracle WebLogic Server: ■ Section Securing Web Applications. Particularly relevant is the subsection Using Declarative Security with Web Applications ■ Section Securing Enterprise JavaBeans EJBs ■ Section Using Java Security to Protect WebLogic Resources

6.5 Migrating from a Test to a Production Environment

The recommendations that follow apply only to Java EE applications using JAAS authorization, such as Oracle Application Development Framework, Oracle SOA, and Oracle WebCenter applications, and they do not apply to Java EE applications using standard authorization. For deploying the latter, see Deploying Standard Java EE Applications . The recommended tool to deploy applications is Fusion Middleware Control, and the user performing the operations described in the following sections must have the appropriate privileges, including the privilege to seed a schema in an LDAP repository. It is assumed that a production has been set up as explained in Section 5.2.1, Setting Up a Brand New Production Environment. The migration to a new production environment is divided into three major portions: migrating providers other than policy or credential providers, migrating policy and credential providers, and migrating audit policies, as explained in the following sections: ■ Migrating Providers other than Policy and Credential Providers ■ Migrating Policies and Credentials at Deployment ■ Migrating Audit Policies

6.5.1 Migrating Providers other than Policy and Credential Providers

The configuration of providers other than policy and credential providers in the production environment must be repeated as it was done in the test environment. This task may include: ■ The identity store configuration, including the provisioning of required users and groups using the WebLogic Administrator Console or the OPSS script Deploying Secure Applications 6-9 configureIdentityStore. For details about this last command, see Migrating Identities Manually . ■ Any particular provider configuration that you have performed in the test environment.

6.5.1.1 Migrating Identities Manually

Identity data can be migrated manually from a source repository to a target repository using the OPSS script migrateSecurityStore. This migration is needed, for example, when transitioning from a test environment that uses a file-based identity store to a production environment that uses an LDAP-based identity store. This script is offline, that is, it does not require a connection to a running server to operate; therefore, the configuration file passed to the argument configFile need not be an actual domain configuration file, but it can be assembled just to specify the source and destination repositories of the migration. This script can be run in interactive mode or in script mode. In interactive mode, you enter the script at a command-line prompt and view the response immediately after. In script mode, you write scripts in a text file with a py file name extension and run it without requiring input, much like the directives in a shell script. For platform-specific requirements to run an OPSS script, see Important Note . Script and Interactive Modes Syntaxes To migrate identities on WebLogic, use the script first or interactive second syntaxes arguments are written in separate lines for clarity: migrateSecurityStore -type idStore -configFile jpsConfigFileLocation -src srcJpsContext -dst dstJpsContext [-dstLdifFile LdifFileLocation] migrateSecurityStoretype=idStore, configFile=jpsConfigFileLocation, src=srcJpsContext, dst=dstJpsContext, [dstLdifFile=LdifFileLocation] The migration of identities on WebSphere is accomplished with a similar script. For details, see Oracle Fusion Middleware Third-Party Application Server Guide. The meaning of the arguments all required except dstLdifFile is as follows: ■ configFile specifies the location of a configuration file jps-config.xml relative to the directory where the script is run. ■ src specifies the name of a jps-context in the configuration file passed to the argument configFile, where the source store is specified. ■ dst specifies the name of another jps-context in the configuration file passed to the argument configFile, where the destination store is specified. The destination store must be an LDAP-based identity store. For list of supported types, see Section 3.1.1, Supported LDAP Identity Store Types. Note: Oracle WebLogic Server provides several tools to facilitate the creation of domains, such as the pack and unpack commands. For details, see Oracle Fusion Middleware Creating Templates and Domains Using the Pack and Unpack Commands.