Glassfish version 3.1.2: Secure Admin must be enabled to access the DAS remotely.

Overview

Firstly, I only install the new Glassfish 3.1.2 only in my laptop and access the administration module locally by using “localhost:4048”. When I install it on the development server and try to access it remotely, by using “http:/my_host:port”. It shows me an error as cannot login with the message as

Secure Admin must be enabled to access the DAS remotely.

The Investigation

I’ve found the nice solution form stack overflow here.

The solution

It’s simple by activate the secure admin by using the following command line: –

asadmin --host [host] --port [port] enable-secure-admin

The host is the host name or IP address for the Glassfish Server which we need to enable the secure admin.

The port is the target Glassfish Server port which wee need to enable the secure admin.

Caution

Please take a big note as the following: –

1. The target Glassfish Server which is the port owner is started before executing the above command.
2. After executing, the target Glassfish Server need to be restarted for taking effect.

Rollback

If we would like to disable the secure admin, it can be done easily as the following: –

asadmin --host [host] --port [port] disable-secure-admin

Java Development with NetBeans and Maven: Part 4

Overview

We have configured our environment so that we can declare our own information outside the “Project POM File” (pom.xml) such as the “Subversion” user id and password, the “Issue Tracker” user id and password. But it is only the “Maven” universe. We live in the bigger one, the integration universe. That means we need to know the other integrated system universe. Even we configure our credential / personal information with purpose to let “Maven” to use them when it connect to each sever. It is just our credential / personal information. Since “Maven” acts as a client, it should provide credential / personal information itself, too. Normally these communication is done via the “SSL”, especially via the “HTTPS”. There are some good practice to which I would like share.

The HTTPS Good Practice For The Client

Most of integration universe has been configured and deployed under the “Apache HTTP” umbrella. As I’ve mentioned before, the “HTTPS” is preferred. This means the “Maven” will connect to them via the “HTTPS”, too. The “Maven” acts as a client, they act as a server for sure. What is the issues? Well, It is a very well known issue.

The Certificate Management For The Client

Normally the server provides its “certificate” to the client for initiating the “SSL” connection. The client will determine if this “certificate” can be trusted. If yes, the conversation will be initiated.

If not the connection will be dropped. We may face a trouble like we cannot connect to server system shows me something about “no trusted certificate found” or other close to this.

The HTTPS Client Configuration Good Practice

I am informing you about the good practice for the client side who would like to connect to the server via “HTTPS”. If the client is a “Java” environment, the “Server Certificate” should be injected to the “truststore”.

The “Server Certificate” is not only limited to the server certificate itself, but also the “Signer Certificate”, too. Please note the “Signer Certificate” is a certificate of the trusted authority who sign the “Server Certificate”. The signer also not be limited at one level, it can be more. It is called “Certificate Chain”. During the checking & verifying If any of “Certificate” inside this “Certificate Chain” is trusted, It will be determined as trusted. This means if we have 3 levels “Certificate Chain”.

The checking step is as following: –

1. If the level 3^rd is trusted, it is determined as trusted. The checking stop here.
2. If the level 2^nd is trusted, it is determined as trusted. The checking stop here.
3. If the level 1^st is trusted, it is determined as trusted. If not the system may show us as “no trusted certificate found”.

For me, I have 2 levels which are created by the “openssl”. Anyhow it can be a 1 level as a self-signed as well.

By default the “truststore” is as following:-

Table 1: The default truststore for JRE

Default Trustsore for JRE

<JRE_HOME>/lib/security/cacerts

Example: C:/Java.Application/Sun/Java/jre1.6.0_21/lib/security/cacerts

Table 2: The default truststore for JDK

Default Trustsore for JDK

<JDK_HOME>/jre/lib/security/cacerts

Example: C:/Java.Application/Sun/Java/jdk1.6.0_21/jre/lib/security/cacerts

The injecting certificate command is as following: –

Table 3: The injecting certificate command

The injecting certificate command

keytool -importcert -trustcacerts -alias <MY_ALIAS> -file <Certificate> -keystore <Truststore>

Example: keytool -importcert -trustcacerts -alias myserver -file server.cer -keystore cacerts Please note: you may be prompted to enter the password, the default password is “changeit”.

Some of them are not default.

Some of them may have their own configuration environment instead, especially the “Subversion Client”. There are 2 types as global for whole client and per-user.

The server-wide

Unix:

/etc/subversion/servers

/etc/subversion/config

/etc/subversion/hairstyles

Windows:

%ALLUSERSPROFILE%\Application Data\Subversion\servers

%ALLUSERSPROFILE%\Application Data\Subversion\config

%ALLUSERSPROFILE%\Application Data\Subversion\hairstyles

REGISTRY:HKLM\Software\Tigris.org\Subversion\Servers

REGISTRY:HKLM\Software\Tigris.org\Subversion\Config

REGISTRY:HKLM\Software\Tigris.org\Subversion\Hairstyles

The per-user

Unix:

~/.subversion/servers

~/.subversion/config

~/.subversion/hairstyles

Windows:

%APPDATA%\Subversion\servers

%APPDATA%\Subversion\config

%APPDATA%\Subversion\hairstyles

REGISTRY:HKCU\Software\Tigris.org\Subversion\Servers

REGISTRY:HKCU\Software\Tigris.org\Subversion\Config

REGISTRY:HKCU\Software\Tigris.org\Subversion\Hairstyles

I prefer to use the per-user instead. Please note, I’m a “Windows Vista”, my configuration home for “Subversion Client” is “C:\Users\Charlee.Ch\AppData\Roaming\Subversion”. Normally the per-user configuration is created automatically by the “Subversion Client”. If the “Subversion Client” does not trust the “Server Certificate”, you may face the message like this, “Server certificate verification failed: issuer is not trusted”. It can be configured easily by using the “Subversion Client” command via a command line, for me it is a dos prompt, as the following:

Table 4: Configure subversion client to trust the server certificate

Configure subversion client to trust the server certificate

svn list https://<YOUR_DOMAIN/svn/path/to/repository

Example: svn list https://www.mydomain.com/svn/myproject/trunk

During executing this command, you will be prompted about the “Server Certificate”. Please press “p”, for accepting this certificate permanently. Anyhow the system may prompt you to provide the credential, please enter it properly. The top most certificate for the “Server Certificate Chain” will be stored at your local as the following: –

Table 5: The stored server certificate folder

The stored server certificate folder

<SVN_CLIENT_HOME>/auth/svn.ssl.server

Example: C:\Users\Charlee.Ch\AppData\Roaming\Subversion\auth\svn.ssl.server

Summary

At the moment, we understand that not only our credential / personal information should be configured, but also the “Maven” credential / personal information for itself should be configured, too. This will help us to achieve further integrating more simple and avoid the well know issues, such as the “HTTPS Client Configuration”. We are well prepared and ready for the next step, “Maven” integration with “Subversion” and “Issue Tracker”. I will post it soon, please stay tuned as always.

The EJB 3.1: IIOP/SSL

The Glassfish Application Server Configuration

I would like to give you an overview about my Glassfish Application Server setting for the EJB as the IIOP port is 3700, the IIOP port with SSL is 3820 and the IIOP port with mutual authentication is 3920. Please note it is a default configuration which is created when the Glassfish was installed. They can be changed via the web administration console. The default URL is http://localhost:4848

Create The EJB Application

It is just simple by implementing the HelloWorld EJB stateless session been by following the formal JavaEE Tutorial document. In our case, there are 3 HelloWorld EJB with the same coding, but different configured as following: –

1. The HelloWorld

2. The HelloWorldSSL

3. The HelloWorldSSLMutual

They are for the non-SSL, SSL and SSL with mutual authentication respectively.

To configure the SSL, the vendor specific ejb-jar.xml is required, in our case the sun-ejb-jar.xml is required since it is a Glassfish Application Server.

Configure The EJB for SSL

SSL

<enterprise-beans>

<ejb>

<ejb-name>HelloWorldSSL</ejb-name>

<ior-security-config>

<transport-config>

<integrity>required</integrity>

<confidentiality>required</confidentiality>

<establish-trust-in-target>supported</establish-trust-in-target>

<establish-trust-in-client>supported</establish-trust-in-client>

</transport-config>

<sas-context>

<caller-propagation>supported</caller-propagation>

</sas-context>

</ior-security-config>

</ejb>

</enterprise-beans>

SSL with Mutual Authentication

<enterprise-beans>

<ejb>

<ejb-name>HelloWorldSSLMutual</ejb-name>

<ior-security-config>

<transport-config>

<integrity>required</integrity>

<confidentiality>required</confidentiality>

<establish-trust-in-target>supported</establish-trust-in-target>

<establish-trust-in-client>required</establish-trust-in-client>

</transport-config>

<sas-context>

<caller-propagation>supported</caller-propagation>

</sas-context>

</ior-security-config>

</ejb>

</enterprise-beans>

Create The Standalone Client, POJO Project

Next we will create a standalone client, POJO project for looking up the EJB stateless session bean remotely by using the Context. Firstly this project should be set all minimum required jar files as following.

The Required jar files

If the Glassfish version 2.x is preferred

1. [gf_home]/lib/appserv-rt.jar

2. [gf_home]/lib/javaee.jar

3. The EJB module jar file

If the Glassfish version 3.x is preferred

1. [gf_home]/glassfish/modules/gf-client.jar

Please note, this jar file is like a proxy jar file which mentions other required jar file via the MANIFEST.MF. If you would like to run this project out of the Netbeans, you should put all mentioned required jar file into your class path. Trust me, please should run inside the Netbeans environment.

2. The EJB module jar file

The reason for putting the EJB module jar file is for ensuring the looked up EJB can be cast to the standalone client environment. If not you may face the ClassNotFoundException  or ClassCastException or. For overview the looked up object will be serialized and transferred from remote to the client via the RMI/IIOP and then it will be deserialized to the original object/interface.

The Example coding for looking up

System.setProperty(“javax.net.ssl.keyStore”, [keyStoreFileName]);

System.setProperty(“javax.net.ssl.keyStorePassword”,[keyStorePassword]);

System.setProperty(“javax.net.ssl.trustStore”,[trustStoreFileName]);

System.setProperty(“javax.net.ssl.trustStorePassword”,[trustStorePassword]);

Properties prop = new Properties();

prop.setProperty(“org.omg.CORBA.ORBInitialPort”,[IIOP_Port]);

prop.setProperty(“org.omg.CORBA.ORBInitialHost”,[Host_Name]);

Context ctx  = new InitialContext(prop);

Object obj = ctx.lookup([EJB_JNDI_NAME]);

System.out.println(“The looked up is: ” + obj.getClass().getName());

The Variable Explanation and Description

The SSL configuration

1. keyStoreFileName: The JKS keystore file name

2. keyStorePassword: The keystore password

3. trustStoreFileName: The JKS truststore file name

4. trustStorePassword: The truststore password

These will be required when the EJB has been configured to use the SSL or SSL with mutual authentication.

The IIOP Configuration

1.  IIOP_Port: The IIOP port, by default is 3700.

2.   Host_Name: The remote host name or IP address, by default is localhost

The Looking Up JNDI

1.  EJB_JNDI_NAME: The deployed and looked up EJB JNDI Name

Please take a very very big note, the IIOP_PORT is only the default IIOP port without any SSL. The system will automatically redirect the client application to the suitable port, SSL or SSL with mutual authentication.