|Oracle® Cloud Using Oracle Java Cloud Service
Part Number E27039-02
|PDF · Mobi · ePub|
This section describes the types of applications Oracle Java Cloud Service (Java Cloud Service) supports. Think of each Java Cloud Service instance as a deployment target for applications using a set of Java Enterprise Edition (Java EE) 5, Java EE 6, and Oracle WebLogic Server capabilities.
See Also:Appendix A, "Java Cloud Service Features and Implementation Considerations" for information about supported and unsupported capabilities
Think of each Java Cloud Service instance as a deployment target for applications using a set of Java EE release 5, Java EE release 6, and Oracle WebLogic Server capabilities. Note that Java Cloud Service only supports the following Oracle WebLogic Server and Oracle Application Development Framework releases:
Oracle WebLogic Server (WebLogic Server) release 10.3.6
Oracle Application Development Framework (ADF) release 188.8.131.52
Note:All references in this document to WebLogic Server capabilities and ADF specific capabilities refer only to the releases specified in the previous list.
As a Platform as a Service (PaaS) solution, the focus of Java Cloud Service is to automate the back-end infrastructure (that is, the operating system, virtual machine, Java EE container, and Java Cloud Service settings) as well as the provisioning and configuration process. Therefore, the infrastructure of the Java Cloud Service runtime is not directly exposed to its service users. In other words, Java Cloud Service is not an Infrastructure As A Service (IaaS) solution. However, certain aspects of the infrastructure can be managed through the My Services interface of the Java Cloud Service as follows:
Type of Java Cloud Service instance (that is, basic, standard, enterprise). The type of Java Cloud Service determines the number of Java EE server processes, memory storage, and file system capacity for the service instance.
Identity domain to which the Java Cloud Service belongs. The identity domain determines the identity store and single-sign-on realm of the instance.
The association of a Java Cloud Service instance with a Database Cloud Service instance. This association makes the database instance available to deployed applications as a JDBC data source.
You upload and manage data for Oracle Database Cloud Service instance using the Oracle Cloud Data Loading utility, the Oracle Application Express Data Load utility or a SQL script in SQL Workshop. See "Developing Applications for the Oracle Database Cloud Service" in Using Oracle Database Cloud Service.
This section describes how to secure Java EE and ADF applications targeted for a Java Cloud Service instance.
"Securing Oracle Cloud" in Getting Started with Oracle Cloud
All Java EE and ADF web applications deployed to a Java Cloud Service instance are automatically secured. When users access an application deployed on Oracle Cloud the default authentication mechanism requests the following information:
User ID - The user name within the identity domain.
Password - A user password.
Identity Domain - The name of the identity domain to which the application being accessed has been deployed.
Data Center - The name of the data center associated with the user's identity domain.
Once logged in, users are authenticated for applications. By default (that is, if no specific configurations are defined), only users that have been authenticated through SSO can access a deployed application, but this includes users from any identity domain. A specific authentication method can be configured in the web.xml file, and it can vary from being publicly accessible to restricted to users within the same identity domain. (For more information about setting up proper access to applications, see "Updating web.xml" and Getting Started with Oracle Cloud.)
To learn more, see "Managing Service Users" in Getting Started with Oracle Cloud.
When securing a Java EE web application, you can specify application roles and security constraints within the application deployment descriptors or the application code. Application roles are mapped to enterprise roles defined within the Java Cloud Service's identity domain using the Identity Console. Implicit mapping is based on the role name. To learn more, see "Managing Service Users" in Getting Started with Oracle Cloud.
You map Java EE roles created using the Identity Console by updating the weblogic.xml file. In the weblogic.xml file, all identity role mapping elements must use the prefix
identity-domain-name>. Consider the following example:
... <wls:security-role-assignment> <wls:role-name>sales</wls:role-name> <wls:principal-name>myidentitygroupfoo.WestCoastSales</wls:principal-name> </wls:security-role-assignment> ...
In the previous example, the identity domain name is
myidentitygroupfoo. (However, note that when
WestCoastSales was created using the Identity Console, the identity domain name was not specified.)
Applications targeted to a Java Cloud Service instance can choose to participate in a Single Sign-On (SSO) with other applications deployed to services within the same identity domain. In order to enable SSO participation, applications must use a CLIENT-CERT authentication method as specified through their deployment descriptor's
<auth-method> element and illustrated through the following web.xml deployment descriptor snippet:
… <login-config> <auth-method>CLIENT-CERT</auth-method> </login-config> <security-role> <role-name>sales</role-name> </security-role>
Applications using a BASIC or FORMS based authentication can also be deployed to a Java Cloud Service instance. However, such applications will not participate in SSO. Instead, their authentication will be local to the application.
All deployed applications without any explicit security elements in web.xml are set with default protection that allows anonymous access to any Oracle Cloud user. To prevent undesired access to your applications, you must set a proper user authentication method in the web.xml file.
The following are supported authentication configurations:
Fully secured application. This method is highly recommended. This configuration allows choosing which portion of the application is protected by SSO.
In web.xml the
auth-method element must be set to the value
CLIENT-CERT as noted in the example below:
<login-config> <auth-method>CLIENT-CERT</auth-method> <realm-name>default</realm-name> </login-config>
You must also define the section of the application that needs to be protected by SSO. In the following configuration, all the URL patterns for the application are protected:
<security-constraint> <display-name>name</display-name> <web-resource-collection> <web-resource-name>name</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> </security-constraint>
Only the URL patterns covered by a security constraint in a
web-resource-collection element will prevent users from different identity domains, and external non-authenticated users. from accessing the application. All the directories that are not specified as a URL pattern will be accessible by SSO authenticated users (even if they are anonymous). Multiple
security-constraint elements are allowed in web.xml.
All applications participating in SSO must have a unique value specified for
cookie-path in weblogic.xml, as follows:
<session-descriptor> <cookie-path>myapp</cookie-path> </session-descriptor>
Note:Specific application security configuration for SSO is highly recommended to enhance the security of your applications and prevent unwanted user access.
Public application. An application that completely requires public access without an SSO challenge must just include an empty
<login-config/> element in web.xml.
Partially secured application. A partially secured application is one that has login-config and auth-method specified but the security collection elements do not cover all the sections of the application. This means the portions of the URL patterns that are not covered by any security-collection element are public. (This is a primary use case.)
When securing a Java ADF application, you can specify application roles and security permissions within ADF application's jazn-data.xml file. Application roles are mapped to enterprise roles defined within the Java Cloud Service's identity domain. Implicit mapping is based on the role name. To learn more, see "Managing Service Users" in Getting Started with Oracle Cloud.
For all ADF applications which use ADF security, you must modify the jazn-data.xml file to ensure that the application roles within it are prefixed with
> prior to deployment. Note that the names of all identity domains, users, and roles must be spelled in lowercase in the jazn-data.xml file. The following is an example jazn-data.xml file.
This example assumes that application roles have been defined through the Identity Console and mapped to the JavaUsers role.
<?xml version = '1.0' encoding = 'UTF-8' standalone = 'yes'?> <jazn-data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://xmlns.oracle.com/oracleas/schema/jazn-data-11_0.xsd"> <policy-store> <applications> <application> <name>SimpleSecureApplication</name> <app-roles> <app-role> <name>trialaagy.customer</name> <class>oracle.security.jps.service.policystore.ApplicationRole</class> <members> <member> <name>trialaagy.a</name> <class>weblogic.security.principal.WLSUserImpl</class> </member> </members> </app-role> <app-role> <name>trialaagy.staff</name> <class>oracle.security.jps.service.policystore.ApplicationRole</class> <members> <member> <name>trialaagy.a</name> <class>weblogic.security.principal.WLSUserImpl</class> </member> </members> </app-role> <app-role> <name>trialaagy.supplier</name> <class>oracle.security.jps.service.policystore.ApplicationRole</class> <members> <member> <name>trialaagy.b</name> <class>weblogic.security.principal.WLSUserImpl</class> </member> </members> </app-role> </app-roles> <jazn-policy> <grant> <grantee> <principals> <principal> <name>authenticated-role</name> <class>oracle.security.jps.internal.core.principals.JpsAuthenticatedRoleImpl</class> </principal> </principals> </grantee> <permissions> <permission> <class>oracle.adf.share.security.authorization.RegionPermission</class> <name>oracle.view.pageDefs.productsPageDef</name> <actions>view</actions> </permission> </permissions> </grant> <grant> <grantee> <principals> <principal> <name>trialaagy.supplier</name> <class>oracle.security.jps.service.policystore.ApplicationRole</class> </principal> </principals> </grantee> <permissions> <permission> <class>oracle.adf.share.security.authorization.RegionPermission</class> <name>oracle.view.pageDefs.stockPageDef</name> <actions>view</actions> </permission> </permissions> </grant> </jazn-policy> </application> </applications> </policy-store> </jazn-data>
Applications deployed on Java Cloud Service can invoke externally exposed web services that are either non-secured or secured (for example, using WS-Security). For deployed applications which invoke a secured external web service, Java Cloud Service supports the following Oracle Web Services Manager (OWSM) policy:
For more information on supported policies, see "Predefined Policies" in Oracle Fusion Middleware Security and Administrator's Guide for Web Services.
To use OWSM policies, you must attach them at design time:
For plain Java EE JAX-WS web services clients, see "Policy Configuration Overrides for the Web Service Client" in Oracle Fusion Middleware Securing WebLogic Web Services for Oracle WebLogic Server.
For ADF web services clients, see "How to Attach Oracle WSM Policies to Web Service Clients" in Oracle Fusion Middleware User's Guide for Oracle JDeveloper.
Oracle makes no specific claims about a definite list of third party libraries that should work within a Java Cloud Service environment. In general, an application's use of most third party frameworks should work within Java Cloud Service, so long as:
All dependencies can be embedded within the deployment archives.
All third party JARS and their dependencies pass the Java Cloud Service whitelist. See "About Java Cloud Service Whitelist".
Use the Resources page to access links to additional tools that enable you to directly interact with your Java Cloud Service instance, including JDeveloper, Eclipse, and NetBeans.
You can download these tools and the Oracle Java Cloud Service SDK from:
Oracle JDeveloper is a free integrated development environment that simplifies the development of Java-based SOA and Java EE applications. JDeveloper offers complete end-to-end development for Oracle Fusion Middleware and Oracle Fusion Applications with support for the full development life cycle.
Oracle JDeveloper 184.108.40.206.0
The documentation for using JDeveloper to develop for and deploy to Java Cloud Service is available in JDeveloper. Select Help > Table of Contents and search for
For product information, links to documentation, user community, and more, see:
NetBeans 7.2 + Update
The official NetBeans documentation will contain information on using the IDE's Java Cloud Service integration capabilities.
For information about NetBeans content and Oracle Cloud integration, see:
For product information, links to documentation, user community, and more, see:
Oracle Enterprise Pack for Eclipse (OEPE) provides tools that make it easier to develop applications using specific Oracle Fusion Middleware technologies and Oracle Database. For Oracle Cloud, OEPE provides direct deployment to Oracle Java Cloud Service, integrated whitelist scanning to check for errors before deployment, integration into the Java Service Console, and log viewers to check on the status of the application.
You can find the documentation for the Enterprise Pack for Eclipse integration with the Java Cloud Service at:
For product information, links to documentation, user community, and more, see:
To deploy a Java EE application to a Java Cloud Service instance, you must follow the guidelines described in this section.
If an application uses Java EE or ADF application security for securing part or all of its pages (either programmatically or through its deployment descriptors), you must modify the application to refer to the appropriate application roles as described in "About Java EE Application Security" and "About ADF Application Security".
If the application is using a JDBC data source for database access, then all references to the JDBC data source must be modified to use the Java Naming and Directory Interface (JNDI) name of the data source assigned within the Java Cloud Service instance. This JNDI name is equivalent to the name given to the Database Cloud Service instance at provisioning time.
For example, if the name of the Database Cloud Service service instance is
foo, then the JNDI name of the Database Cloud Service instance will also be
foo is the name that should be used in all references to the data source within the application.
If you are deploying an ADF application, you must modify its weblogic.xml deployment descriptor to use the
<exact-match> element as described in the following example.
<library-ref> <library-name>jsf</library-name> <specification-version>1.2</specification-version> <exact-match>true</exact-match> </library-ref>
Note:This library reference is added automatically if an ADF application is deployed from JDeveloper to a Cloud server.
If the application needs to be deployed to both on-premise environments as well as a Java Cloud Service instance, and if the on-premise environments use different role names and data source JNDI names, then use the WebLogic Server release 10.3.6 deployment plans feature when deploying the application to the on-premise environments. This approach will support the configuration differences between the on-premise environment and the Java Cloud Service instance.
To learn more, see "Using a Deployment Plan: Overview" in Oracle Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server.
To create an on-premise Java EE environment that is comparable to a Java Cloud Service instance, you must:
Install WebLogic Server 10.3.6. No other version of WebLogic Server is supported as an on-premise environment for Java Cloud Service.
Create a domain as follows:
If the application you are deploying is not an ADF application and does not use any web services security (using OWSM), use the plain wls.jar WebLogic Server domain configuration template.
If the application you are deploying is using ADF or web services (by either exposing or invoking them) which must be protected through OWSM security policies, use the plain wls.jar as well as the JRF and OWSM domain configuration templates.
Tip:You can apply the JRF and OWSM domain configuration templates through the WebLogic Server configuration wizard. To accomplish this, use the version of the configuration wizard packaged with Oracle JDeveloper release 220.127.116.11 or ADF download.
Deploy the deployment archives listed in Table 4-1 as shared libraries to the domain. Note that in Table 4-1,
MW_HOME refers to the Middleware Home directory you used when you installed WebLogic Server.
Tip:During deployment, you must use the exact deployment names specified in Table 4-1.
|Application Type||Deployment Archive Path||Deployment Name|
Uses JAX-RS 1.1 REST interfaces
Uses JSF 2.0 for web application components
Create a single XA enabled JDBC data source using the Oracle JDBC Thin driver connected to an on-premise Oracle Database 11g release 1 (11.1) data source. Give the data source the same name as the Database Cloud Service instance associated with your target Java Cloud Service.
To move an application (represented by a set of EAR/WAR files) between an on-premise environment and JCS instances (or vice-versa), you must ensure that their database and Identity Management user repository content is also moved appropriately.
To move database data from on-premise to Database Cloud Service instances associated with JCS instances:
Ensure that your schema tables are created within the target Database Cloud Service instance. To do this you can use either the database service's SQL Workshop interface (see the SQL Workshop section in Using Oracle Database Cloud Service) or SQL Developer (see the SQL Developer section in Using Oracle Database Cloud Service).
You can also have the schemas created upon application deployment if using EclipseLink JPA by using the following snippet within your application's persistence.xml descriptor:
<property name="eclipselink.ddl-generation" value="create-tables"/>
Follow the instructions for using the SQL Workshop Data Upload Utility (see Using Oracle Database Cloud Service) to import your bulk data from on-premise to the target Database Cloud Service instance.
To move database data from Database Cloud Service instances associated with JCS instances to on-premise schemas:
Follow the instructions in the section about exporting data in Using Oracle Database Cloud Service to import your bulk data from on-premise to the target Database Cloud Service instance.
To move user repository data from on-premise user repositories to the identity domain associated with a JCS instance:
Export data from your on-premise identity repository into a single file in CSV format (see Using Oracle Database Cloud Service).
For technical and security reasons, a small number of specific APIs are prevented from executing in Oracle Cloud. Applications using these APIs are not deployable because they will not pass the whitelist phase of the Java Cloud Service deployment process. Java Cloud Service SDK includes a whitelist tool that enables you to check whether an application is in violation of the Java Cloud Service whitelist. To learn more, see "About Installing the Java Cloud Service SDK".
Note:The Java Cloud Service "whitelist" is actually the result of what are sometimes called blacklist and whitelist checks. It may be helpful to think of Java Cloud Service whitelist validation as simply a compatibility check.
Whitelist violations result when applications use functionality from the following areas.
Java non-blocking IO
Executing a new Process
Direct SQL connection
Tip:Java Cloud Service supports database connections through an associated data source.
Java Native Interface (JNI)
Java Desktop accessibility
JDK Log Management
Tip:You can use JDK loggers to log the messages.
CORBA API (org.omg.**)
Overriding Java Security Manager
Java Messaging Service
Remote JMX Management
See also "Unsupported Features and APIs".
The following describes the deprecation policy for Java Cloud Service:
All APIs marked as deprecated in Javadoc for WebLogic Server release 10.3.6 and ADF release 18.104.22.168 are deprecated for the Java Cloud Service. See:
As a general rule, APIs that are marked as deprecated for Java Cloud Service in a specific version of the product, will be fully removed in the next major product update.