Posts

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 -srcsto...

Dynamically enabling (or disabling) the JDBC driver level logging using debug version of Oracle JDBC thin driver (ie ojdbc6_g.jar) on app server

This post is about dynamically enabling (or disabling) the  JDBC driver level logging with debug version of Oracle JDBC thin driver "ojdbc6_g.jar" in place while app server is up and running. Typically, when this jar is put in place in application server environment, we enable the logging using JAVA system property "-Doracle.jdbc.Trace=true". This approach is static in the sense that application server restart is needed each time we want to enable or disable the logging. This static approach is not at all feasible in a production system where we want to trace the jdbc calls at some particular instance of time. A programmatic (dynamic) approach to enable/disable driver level logging is also discussed in doc "http://docs.oracle.com/cd/B28359_01/java.111/b31224/diagnose.htm". However this approach is suitable for enabling/disabling the logging from within the application. So this method would essentially only trace JDBC calls at places where application ...

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 sa...

Go HA

Image
WebLogic provides many ways to automate lifecycle of cluster members to achieve server/service high availability without affecting service quality. For instance, we can configure whole server migration to make sure that in an event of physical  machine failure cluster members hosted on that machine are started on another machine. There are alternative methods to manage server (or process migration, at OS level), or simply, to control the lifecycle activity of  a process. These alternative methods include inbuilt (or packaged) clustering software that comes with various flavors of Linux/Unix. This post discusses the possible way to make such clustering software control WebLogic instances. The central thing about this is the use of W eb L ogic S cripting T ool ( or WLST) script. This WLST script file would be invoked from service script (which is just a specific form of shell script used to execute lifecycle activities of a process) with appropriate argument, like start,...

Why JAVA 1.6 HTTP client can authenticate (using SPNEGO) only against certain WebLogic versions?

JAVA 1.6 HTTP client's inherits support for SPNEGO via Java GSS. This is listed at:     http://docs.oracle.com/javase/6/docs/technotes/guides/security/jgss/jgss-features.html From WebLogic side, the answer(to the question why JAVA HTTP client only works with certianin versions) lies in simple test that is carried out using "supported" browser and JAVA fat client against same version of WebLogic and then analyzing the network dumps. Network dumps show: For JAVA fat client(not working against WebLogic 10.3.3) GSS-API Generic Security Service Application Program Interface               OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation)               Simple Protected Negotiation                          ...

com.bea.security.saml2.service.SAML2Exception: [Security:096575]The URL for relay state too long

In IdP initiated SSO, you might have a jsp/html resource at IdP end where SP services are defined having  similar form snippet: <input type="hidden" name="SPName" value="<%=spname%>" <input type="hidden" name="RequestURL" value="<%=requestURL%>" <input type="hidden" name="param1" value="<%=value1%>" <input type="hidden" name="param2" value="<%=value2%>" <input type="hidden" name="param3" value="<%=value3%>" However you are getting following exception whenever SP service is invoked from above jsp/html: ####<Sep 29, 2011 2:01:14 PM IST> <Debug> <SecuritySAML2Service> <MyMac> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1311113162898> ...

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 ...