Configuring WebLogic GridLink DataSource with secure SCAN URL and secure ONS

Configuring SCAN and ONS on WLS GridLink datasource is already covered in Oracle whitepaper here

In this discussion today, I will list high level steps that are needed to configure secure SCAN and secure ONS on WLS GridLink Datasource instead of using their plain counterparts.

Here are the high level steps:

1) TCPS based listener configuration needs to be implemented on DB server side. Once it is done, we would get a secure SCAN URL. Based on this scan URL, we would get jdbc URL for use with our GridLink datasource, something like:

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCPS)(HOST=sup.oracle.vm)(PORT=1523)))(CONNECT_DATA=(SERVICE_NAME=racdb.oracle.vm)))


2) ONS daemons running on RAC nodes need to be secured as well with user certificate (using wallet). Note that it is essential to have ditto wallet configuration in following(or equivalent) files to secure ONS daemon successfully:

node1:
ons.config
ons.config.node1

node2:
ons.config
ons.config.node2

Here is sample output of ons.config and ons.config.node1 from node1

[grid@sup1 conf]$ cat ons.config
localport=6100 # line added by Agent
allowgroup=true
usesharedinstall=true
remoteport=6200 # line added by Agent
nodes=node1:6200,node2:6200 # line added by Agent
debugcomp=ons[all]
walletfile=/u01/app/11.2.0/grid2/network/admin/cost
walletpassword=welcome1


[grid@sup1 conf]$ cat ons.config.node1
localport=6100 # line added by Agent
allowgroup=true
usesharedinstall=true
remoteport=6200 # line added by Agent
nodes=node1:6200,node2:6200 # line added by Agent
debugcomp=ons[all]
walletfile=/u01/app/11.2.0/grid2/network/admin/cost
walletpassword=welcome1


3) With above things in place, just follow the steps in doc:
http://www.oracle.com/technetwork/middleware/weblogic/wls-jdbc-gridlink-howto-333331.html


Now some security specific highlights are:
4) Following needs to added to DOMAIN_HOME/setDomainEnv.sh:


set WEBLOGIC_CLASSPATH=D:\oracle\wls1034\modules\com.oracle.osdt_cert_1.0.0.0.jar;D:\oracle\wls1034\modules\com.oracle.osdt_core_1.0.0.0.jar;D:\oracle\wls1034\modules\com.oracle.oraclepki_1.0.0.0.jar;%WEBLOGIC_CLASSPATH%

What this does is it pulls these jar files into classpath so that WebLogic can play with Oracle wallets.

5) GridLink datasource security related configuration is:

keystore Driver Properties:
---------------------------------------
javax.net.ssl.keyStore=D:\\apps\\rac_db_repro\\identity_against_db.jks
javax.net.ssl.keyStorePassword=welcome1
javax.net.ssl.keyStoreType=JKS
javax.net.ssl.trustStore=D:\\apps\\rac_db_repro\\db_trust.jks
javax.net.ssl.trustStorePassword=welcome1
javax.net.ssl.trustStoreType=JKS

Note:
a) "identity_against_db.jks" is nothing but Java Keystore that has user certificate (used as client identity)
b) "db_trust.jks" contains root certificate(s) of CA(s) who signed user certificate(s) used by DB process


6) ONS nodes in GridLink datasource used:
node1.oracle.vm:6200
node2.oracle.vm:6200

7) wallet in ONS configuration on GridLink datasource used:
ons-wallet-file --> D:\apps\rac_db_repro
ons-wallet-password --> welcome1

Note
a) the wallet file is "ewallet.p12", and is located at "D:\apps\rac_db_repro"
b) "ewallet.p12" contains root certificate(s) of CA(s) who signed user certificate(s) used by ONS process

Comments

Post a Comment

Popular posts from this blog

Replacing expired certificates on SSL Server that uses JKS based keystore

Replacing an expired identity certificate in a JKS based keystore is pretty easy stuff, unless you have forgot to keep a backup of your private key. This post discusses the use-case where we don't have a backup copy of the private key outside the JKS keystore, and we wish to replace the expired/going-to-expire identity certificate There are two ways that I know of: Portecle (easy) - this is a tool available out on internet OpenSSL-Keytool combination (lengthy one) I will discuss 2nd one, and would only provide commands (and not discuss each switch as you can always refer relevant product docs for it) 1. Backup the JKS keystore, suppose original is  "keystore.jks" 2. JKS -> PKCS12 conversion (pkcs12 obtained in this step would be run through OpenSSL in next step, to separate the private key from the expired certificates)          keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.p12 -srcstoretype JKS -deststoretype PKCS
Read more

Giving non-admin users the permission to access MBeans

Sometimes it might be a requirement that a JEE application, deployed on WebLogic, needs an access to MBeans (Server, domain  or custom MBeans). With WebLogic default administrator user and other users who belong to default administrator group “Administrators” such a thing is possible quite easily. However it is not a good practice as the admin credentials would unnecessarily get exposed to application (and it may in-turn have security consequences). So, the question comes up - can we avoid using these admin credentials and instead use appropriate credentials, in our application, based on role access? The answer is yes - this requirement involves working with JMX policies. WebLogic provides a way for creating new as well as modifying existing (default) JMX policies. So what you can do is use the JMX policy editor to grant non-admin user/group a write access to the required MBean. JMX policy editor is described here . Also refer this to enable the JMX policy editor if it i
Read more

Modifying the "supported" attributes of embedded ldap users/groups

Image
WLS Admin console provides limited access to modify the attributes of users and groups that are located in its embedded ldap. This is primarily because embedded ldap is not supposed to hold any application users/groups on a large scale and probably this is one of the reasons why WLS does not provide any dedicated GUI to to modify the user/group attributes inside embedded ldlap. Neverthless, we can store these users/groups and we can modify the attributes as well. There are two approaches: 1) Using an external LDAP browser utility . My favorite as of today is jxplorer . I use such a utility against WLS embedded ldap for various purposes - testing the connectivity, the bind operation, search queries, etc Using such ldap browser utilities against WLS embedded ldap requires one to explicitly open embedded ldap for "outside WLS" access.This involves resetting the password of embedded ldap's super user "Admin" to a known value. Note that when WLS domain is creat
Read more