Friday Aug 15, 2014

Coming to OpenWorld? A must attend session…

NTT Docomo, Inc. is the predominant mobile phone operator in Japan. The name is officially an abbreviation of the phrase, "do communications over the mobile network", and is also from a compound word dokomo, meaning "everywhere" in Japanese. 


One of the most important of NTT Docomo’s systems is ALADIN, which is a nationwide operating system shared with its eight regional subsidiaries. ALADIN has five primary functions: customer management, phone number management, information processing and storage, sales information management, and credit investigation. To enhance cost efficiency and help ensure stable operation of ALADIN, NTT Docomo has employed Oracle WebLogic Server as a new application platform. Further information on this can be found here.

Last year at OpenWorld, NTT Docomo was honored as an Innovation Award Winner for:

· Implementing real time sales and contract management system enabling all services requested by customers for immediate activations before customer leaves the Docomo store

· A robust disaster recovery strategy, room to grow the business, and ability to move custom Java development to a platform with built in standards - WebLogic

· Better performance, better reliability, better stability, and smooth migration

Meet This Year's Most Impressive Innovators!

This year we continue to honor customers for their most innovative and cutting-edge solutions using Oracle Fusion Middleware. Join us in celebrating award recipients’ great achievements and commitment to innovation.  

Oracle Fusion Middleware: Meet This Year's Most Impressive Innovators

Session ID: CON7029

Tuesday September 30, 2014 @ 5-5:45 pm (PST)

Yerba Buena Center for the Arts 
YBCA Theater (next to Moscone North)

700 Howard St., San Francisco, CA, 94103


Sunday Aug 10, 2014

Data Source Encrypted Connection Properties and SSL

Encrypted properties are needed for information that needs to be secured instead of exposing it as clear text.  For data sources, that's generally for security credentials like passwords.  Since the first release, WLS data source has only supported a single encrypted property, the database password corresponding to the database user for all connections on the data source.  That was fine for simple security but adding features like SSL needed additional passwords for the key store and trust store.  We figured out a limited solution by using the Oracle auto-login wallet with store type SSO that did not require an additional password value.  That's documented at http://docs.oracle.com/middleware/1213/wls/JDBCA/ds_security.htm#CHDBBIJH .  

We explored options for supporting additional encrypted properties including encrypting all properties with the name "Password" but it didn't seem to be an elegant solution.  In 10.3.6, we made a simple extension to connection properties to support system properties.  In WLS 12.1.3, we made a similar extension to support encrypted properties.  A JDBC property now consists of a name and a choice of a value, a system property value, or an encrypted value.  Encrypted values would commonly be used for javax.net.ssl.trustStorePassword and/or javax.net.ssl.keyStorePassword when configuring SSL.

You can set the encrypted property in a WLST script using

setEncryptedValueEncrypted(encrypt('clear-text-value'))

The clear text value (literal or variable) is encrypted and then stored as an encrypted value in the descriptor.  This works for both on-line and off-line WLST.  If you have an on-line WLST script, you can also use

setEncryptedValue('clear-text-value')

In this case, the encryption is automatically done and the encrypted value is stored.

You can also use the WLS administration console to create encrypted properties.  It's not possible to specify the encrypted values when creating a data source.  That is, the creation assistant doesn't support encrypted properties.  When you create a data source, you might need to put in a clear-text password if you want to test the connection during the creation process. You can add encrypted values to the data source definition by editing the configuration. You need to go to the Configuration Connection Pool tab (the same tab as normal properties and system properties). If you used clear-text passwords during creation for testing, you will need to remove the clear text values first.   There are two approaches to add encrypted values.  One is to type the name and clear text value directly into the Encrypted Properties text box.  When you click on the Save button, the values are encrypted.  The advantage of this approach is that you can enter multiple values directly but the downside is that between the text entry and saving the values, the values are visible on the screen.  This approach is shown in the following figure.

There is a second approach that provides secure data entry.  Note in the picture above, there is an "Add Securely" button to the right of the Encrypted Properties text box.  Clicking on that button causes a new window to pop up as in the following figure. You can enter the property name and then the encrypted value twice.  The input for the encrypted values is obscured.  When done, click on the OK button to enter the name and encrypted value in the Encrypted Properties text box.  The advantage of this approach is that the clear text value is never displayed.

You can see the product documentation for encrypted properties at http://docs.oracle.com/middleware/1213/wls/JDBCA/ds_security.htm#CHDGCDIB,  including some code examples.

The timing was good for this feature because a lot of testing was done on setting up one-way and two-way SSL configurations in the Server for WLS 12.1.3.  See http://docs.oracle.com/middleware/1213/core/ASADM/sslconfig.htm#CBDFGCAF  for a discussion of using SSL with the data tier.  This release also introduced FIPS 140 support in Oracle Fusion Middleware.  See http://docs.oracle.com/middleware/1213/core/ASADM/fips.htm  for more details. 

WLS 12.1.3 has a complete SSL security solution that is well tested and well documented.  Support for encrypted data source connection properties is one important piece in the solution.

P.S. Earlier versions of the documentation said "You must enable the Oracle PKI provider. This can either be done statically by updating the java.security file under the JRE or dynamically by setting it in a WLS startup class ...".  Updating the JRE java.security file was removed from the documentation in WLS 12.1.3 because testing found that it didn't work for two-way SSL. A bug was fixed in the oraclepki.jar file late in 12.1.3 and this approach now works. It may be the easier of the two approaches.

Monday Aug 04, 2014

Setting V$SESSION for a WLS Datasource

Every Oracle database connection runs in the context of a database process called a session.  There is a v$session view that contains a lot of information about the database sessions that are active.. By default when you use the Oracle Thin Driver, the value v$session.program is set to "JDBC Thin Client".  That separates out the Java applications from sqlplus and the scores of database background programs but doesn't provide much additional information since all of the Java connections look the same.  It's easy to set this and some other values on v$session using connection properties on the Oracle Thin driver.  The following connection properties are supported:  v$session.osuser, v$session.process, v$session.machine, v$session.terminal, and v$session.program.  Setting these will set the corresponding value on the session on the database side.  These values are then available from the v$session view.

The simple approach is to hard-code a value into a normal connection Property.  That's fine if you want to associate a fixed value with a data source.  It's more interesting if you dynamically set the value at runtime. For example, if there are multiple servers running within a domain and the information needs to be server specific, a normal cluster deployment with one fixed value is not useful, and the option of deploying the DataSource to every server individually and then hand-editing each one's descriptor with unique values for these properties is not manageable. You can easily handle this using a System Property.  The value that is specified is taken to be a Java system property that you set on the command line of the application server.  It is retrieved using System.getProperty() and set as the value of the connection property.    There's a new Encrypted Property in WLS 12.1.3; I'll write another article about that.

If you use bin/startWebLogic.sh to start the server, it will put -Dweblogic.Name=${SERVER_NAME}on the command line.  If you set the v$session.program System Property connection property to "weblogic.Name", your session program value will match the WLS server that is making the connection. 

You can set connection properties by editing the data source configuration on the "Connection Pool" tab in the WebLogic administration console.  Properties are set in the Properties and System Properties text boxes.  Let's say that I set four of the values to test values and one to a system property, generating the descriptor fragment as follows.

<property>
  <name>v$session.osuser</name>
  <value>test1</value>
</property>
<property>
  <name>v$session.process</name>
  <value>test2</value>
</property>
<property>
  <name>v$session.machine</name>
  <value>test3</value>
</property>
<property>
  <name>v$session.terminal</name>
  <value>test4</value>
</property>
<property>
  <name>v$session.program</name>
  <sys-prop-value>weblogic.Name</sys-prop-value>
</property>

Alternatively, you could set these values using on-line or off-line WLST.

Here's a fragment of an off-line WLST script.

cd('/JDBCSystemResource/myds/JdbcResource/myds') cd('JDBCDriverParams/NO_NAME_0') cd('Properties/NO_NAME_0') create('v$session.program','Property') cd('Property') cd('v$session.program') set('SysPropValue', 'weblogic.Name')

If $SERVER_NAME is myserver and I then go to run a query, here is the resulting output.

SQL> select program, osuser, process, machine, terminal 
  from v$session where program = 'myserver';
myserver test1 test2 test3 test4

If the server names aren't obvious enough, you could set the program to "WebLogic Server $SERVER_NAME".  You could set -Djdbc.process=<PID> to tie connections to a specific WLS server process. You might want to add the WLS data source name to the program value.  You could set osuser to the Java value "user.name".

 Using system properties can make this a powerful feature for tracking information about the source of the connections, especially for large configurations.


Friday Aug 01, 2014

Using 3rd party JDBC Jar Files

If you look at the documentation for adding a 3rd party JDBC jar file, it recommends adding it to the system classpath by updating comEnv.sh.  See http://docs.oracle.com/middleware/1212/wls/JDBCA/third_party_drivers.htm#JDBCA233.  However, there more options with some advantages and disadvantages.  To use some of these options, you need to know something about application archive files.

The general precedence of jar files in the classpath is the following:

system classpath >> DOMAIN_HOME/lib >> APP-INF/lib >> WEB-INF/lib

The highest priority is given to jar files on the system classpath.  The advantage of using the system classpath is that it works for all environment including standalone applications. 

The rest of the options only work for applications deployed in the application server.  That includes the WLS administration console and WLST but not an application like 'java utils.Schema'.  These approaches work on WLS 10.3.6 and later.

The simplest way to add a jar file when you don't need it accessed in a standalone application is to drop it in DOMAIN_HOME/lib.  This is an easy way to access a driver for a data source in the application server. It won't work for jar files that are shipped with WLS and already part of the system classpath because the system classpath takes precedence.  That's why this article focuses on "3rd party" jar files.  More information and recommendations about using DOMAIN_HOME/lib can be found at http://docs.oracle.com/middleware/1212/wls/WLPRG/classloading.htm#i1096881 .

APP-INF/lib will only work in an EAR file and applies to all applications in the EAR file.  APP-INF is located at the root directory in the EAR file at the same level as META-INF.  This approach and the next have the advantage of packaging the driver with the application archive.  However, it's not efficient if the driver is needed by more than one archive and you probably should use DOMAIN_HOME/lib.

WEB-INF/lib only works in a WAR file and must be located at the root directory in the WAR file.  It only applies to the corresponding web application.  By using a WEB-INF/weblogic.xml file that has "<prefer-web-inf-classes>true</prefer-web-inf-classes>", the jar files in WEB-INF/lib take precedence over others (that is, the default precedence defined above is overridden).  This is useful if you want different versions of the driver for different applications in various WAR files.   Note that starting in WLS 12.1.1 with Java EE 6 support, it's possible to have a standalone WAR file that is not embedded in an EAR file.

Here's an indented list that attempts to capture the hierarchy of the files and directories described above in EAR and WAR files.

Application (ear)

  • Web module (war)
    • WEB-INF/lib
    • WEB-INF/web.xml
    • WEB-INF/weblogic.xml
  • EJB module
  • META-INF
  • APP-INF/lib

There is sample code for a WAR file at this link.  The data source definition can appear either as a descriptor in web.xml or as an annotation in the java file.  weblogic.xml can be used to set prefer-web-inf-classes appropriately.  The @Resource annotation is used to reference the data source in the application code.  This program prints the version of the driver.  You can play with two versions of the Derby driver to see how the precedence works.

Note:  You can't have two versions of the same jar in both domain/lib or the system classpath and  WEB-INF/lib or APP-INF/lib with prefer-web-inf-classes or prefer-application-packages set.  That is, either you use domain/lib or system classpath to get it into all applications in the domain or you use it embedded in the application but not both.  If you don't follow this restriction, it's possible (depending on the jar, the version changes, and the order in which the jars are referenced) that a ClassCastException will occur in the application.

The choice of where you locate the JDBC jar file depends on your application.  For standalone application access, use the system classpath.  For simple access in all or most applications, use DOMAIN_HOME/lib.  For access across an EAR file, use APP-INF/lib.  For access within a single WAR file, use WEB-INF/lib.



About

The official blog for Oracle WebLogic Server fans and followers!

Stay Connected

Search

Archives
« August 2014 »
SunMonTueWedThuFriSat
     
2
3
5
6
7
8
9
11
12
13
14
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
      
Today