Everything which is needed is a standard quickstart project of maven. The folder structure has to be extended by the both directories:

src/main/scala
and
src/test/scala

After that you’ve got to add the following lines to the pom.xml of the maven project:

To use scala in the project you’ve got to add an additional repository:

...
<repository>
<id>scala-tools.org</id>
<name>Scala-tools Maven2 Repository</name>
<url>http://scala-tools.org/repo-releases</url>
</repository>
<repository>
<id>scala-tools.org</id>
<name>Scala-tools Maven2 Repository</name>
<url>http://scala-tools.org/repo-releases</url>
</repository>
...

Within the dependency-section you’ll need to add the needed library:

...
<dependencies>
<groupId>org.scala-lang</groupId>
<artifactId>scala-library</artifactId>
<version>2.9.0-1</version>
</dependencies>
...


After that I had to add the maven-scala-plugin to the build-lifecycle.

...

org.scala-tools
maven-scala-plugin

scala-compile-first
process-resources

add-source
compile

scala-test-compile
process-test-resources

testCompile

…

After that it was possible to use scala and java in one project (of course in diffrent directories).
Some other people put the maven-compiler-plugin below the maven-scala-plugin to define the order of execution.
If there are any Eclipse-Users outside: There is a m2e-scala connector which connects the lifecycle of the maven-scala-plugin to m2e. This makes the development on Eclipse much easier.

When planning to use this feature you’ll have to switch to the “Services” window in Netbeans. Within this you should choose a new GlassFish-Instance to be added to the servers.

Within the next page of the following dialogs you’ve got to choose a locally installed instance:

This is needed so Netbeans can use the libraries provided by GlassFish. It shoud be the same version of GlassFish as the one on the webserver to avoid any problems.

The next step is the one where the remote instance is choosen. By default the local instance is choosen, but we’ll choose the other now:

Now just hit finished. Nearly everything is done to use the remote GlassFish. After finishing the dialog you got another dialog which requests the credentials for the GlassFish:

After entering the informations everything should be fine, but there is still one step. Due to security restrictions the remote administration of the GlassFish isn’t enabled. So when you klick on Ok you will receive the following dialog:

This dialog gives you a hint on what to do next: You have to execute “asadmin enable-secure-admin” on the remote server:

[webserver]# asadmin enable-secure-admin
Enter admin user name>  [your admin-user, default: "admin"]
Enter admin password for user “admin”>  [the password of this user]
Command enable-secure-admin executed successfully.

Now you can try again, but you will still receive the same error. Due to the documentation Grizzly needs a reload to apply these setting.

After you’ve got enabled-secure-admin you will be asked to confirm a new certificate (on the console, which you should do). This command enables secure access to the admin functions. Which means that the admin-gui (on port 4848) is now running via https and is no longer avaliable using http. The communication between asadmin and GlassFish is now secured.

After stopping and starting GlassFish again, everything works fine. And you can work with the remote GlassFish.

In this small article I show you the diffrent types of connecting from a client to the deployed sessionbean from part 1. In the first part I had choosen a really simple way to authorize the client. But there are more ways to achieve this. All of them manage the same but differs in the complexity or in the use case where and when to use.

The standard way to access an secured sessionbean is using the LoginContext and the related CallbackHandler. I name it the ‘standard way’ because it’s the way which is explained by Sun/Oracle in their JAAS documentation.

LoginContext & CallbackHandler

At first we’re creating the CallbackHandler. This CallbackHandler is needed by the LoginContext to authenticate. Why it’s done this way? – It’s easy to explain: The login should be as flexible as possible. That means that you should be able to retrieve you’r username and password in a way that best suites your needs. In my projects I found it more usable to provide the credentials using the constructor or using setters and getters.

 import java.io.IOException;
import javax.security.auth.callback.Callback;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.callback.NameCallback;
import javax.security.auth.callback.PasswordCallback;
import javax.security.auth.callback.UnsupportedCallbackException;

public class MyCallbackHandler implements CallbackHandler {

public MyCallbackHandler(String username, char[] password) {
this.username = username;
this.password = password;
}

public MyCallbackHandler(String username, String password) {
this.username = username;
this.password = password.toCharArray();
}

String username;

char[] password;

public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException {
for (Callback callback : callbacks) {
System.out.println("Handling callbacks");
if (callback instanceof NameCallback) {
System.out.println("Handling NameCallback");
NameCallback nc = (NameCallback) callback;
nc.setName(username);
} else if (callback instanceof PasswordCallback) {
System.out.println("Handling PasswordCallback");
PasswordCallback pc = (PasswordCallback) callback;
pc.setPassword(password);
}
}
}

To use the CallbackHandler you have to modify the client as shown below.

 import java.util.Properties;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.security.auth.login.LoginContext;
import myea.beans.SayHello;

public class Main {
public static void main(String[] args) throws Exception {

Properties env = new Properties();
env.setProperty(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
env.setProperty(Context.URL_PKG_PREFIXES, "org.jnp.interfaces.NamingContextFactory");
env.setProperty(Context.PROVIDER_URL, "jnp://localhost:1099/");
MyCallbackHandler myCbHandler = new MyCallbackHandler("myuser", "123456");
System.out.println("Preparing LoginContext.");
LoginContext lctx = new LoginContext("my-security-client", myCbHandler);
System.out.println("Logging in...");
lctx.login();
System.out.println("Calling sessionbean...");
InitialContext ctx = new InitialContext(env);
SayHello h = (SayHello) ctx.lookup("SayHelloBean/remote");
System.out.println(h.sayHello("Marc"));
}
}
}

Now you can execute the client. But there is an exception:

Exception in thread "main" java.lang.SecurityException: Unable to locate a login configuration.
... (some more stacktrace) ...

This exception tells us that there is an login configuration missing. This login configuration defines the used LoginModule for authenticating the client. We’ve to provide this configuration. There are two ways to provide the configuration. The mostly used way to handle it is using a file:

my-security-client {
org.jboss.security.ClientLoginModule  required;
};

The format of this file is explained in depth in the LoginConfigFile-section of the JAAS-Tutorial. I’ll only explain the parts of the  login config file which we’re using:

my-security-client is the name for the following configuration. If the LoginContext is initialized it reads the file and uses the configuration which is named like the first parameter of the LoginContext-constructor. Within the configuration there is a classname followed by required. The classname (the first in the row) is the name of the LoginModule. This one is a provided by JBoss. This LoginModule is followed by ‘required’. In login config files which contains entries with only one LoginModule it’s usually the required one. If you’ve got more than one LoginModule it can have other values, such as: “requisite“, “sufficient“, “optional” and of course “required“.  There are some more configuration options such as ‘debug=true’ which you can append to the line, they’ re explained on the JAAS-Tutorial.

After creating this file we’ve got to specify that we’re using this file. Therefore we’ve got to specify this paramter when starting the application:

-Djava.security.auth.login.config=./conf/auth.conf

I’ve put my auth.conf file (you can name it as you want, as I mentioned before) in a directory named conf. Of course you can choose another location.

After that modification your client should connect successfully. But there is one thing to note when you’re looking at the output of the client:

Preparing LoginContext.
Logging in...
Handling callbacks
Handling NameCallback
Handling callbacks
Handling PasswordCallback
Calling sessionbean...
Hello Marc

As you can see the Callback is called when the login() method of the LoginContext is called.  If you try to execute the client you’ll notice that the login procedures will run without connecting to the AS (the exception occures after “Calling sessionbean…”. That means that you’ll see that the login is correct or incorrect on the first call to a secured sessionbean. So you’ve got to check the success or failure of a login on a first call to the server.

Above there is shown the login configuration file. But there is another way to handle the login configuration. You can avoid writing this file if you write the configuration in your class:

import java.util.Properties;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.security.auth.login.AppConfigurationEntry;
import javax.security.auth.login.Configuration;
import javax.security.auth.login.LoginContext;
import myea.beans.SayHello;

public class Main {

public static void main(String[] args) throws Exception {

Properties env = new Properties();
env.setProperty(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
env.setProperty(Context.URL_PKG_PREFIXES, "org.jnp.interfaces.NamingContextFactory");
env.setProperty(Context.PROVIDER_URL, "jnp://localhost:1099/");
MyCallbackHandler myCbHandler = new MyCallbackHandler("myuser", "123456");
System.out.println("Preparing LoginContext.");
Configuration conf = new Configuration() {

@Override
public AppConfigurationEntry[] getAppConfigurationEntry(String name) {
AppConfigurationEntry entry = new AppConfigurationEntry("org.jboss.security.ClientLoginModule",AppConfigurationEntry.LoginModuleControlFlag.REQUIRED, new java.util.HashMap());
return new AppConfigurationEntry[] {entry};
}

};
LoginContext lctx = new LoginContext("my-security-client",null , myCbHandler, conf);
System.out.println("Logging in...");
lctx.login();
System.out.println("Calling sessionbean...");
InitialContext ctx = new InitialContext(env);
SayHello h = (SayHello) ctx.lookup("SayHelloBean/remote");
System.out.println(h.sayHello("Marc"));

}
}

The important part is the Configuration and the initialization of the LoginContext. The Configuration shows in the method getAppConfigurationEntry the representation of the contents of the file. Normally this method is called with the configuration name (in our case “my-security-client”). But we’ll ignore it here and provide the same login configuration for all callers.

If you’d like to avoid creating these both classes you can choose one of the following. You can use the SimpleClient which is provided by the JBossAS client libraries or you can use the JndiLoginInitialContext as the Context.INITIAL_CONTEXT_FACTORY.

SecurityClient

The SecurityClient (org.jboss.security.client.SecurityClient) is the simplest way to connect to session bean.  Under the hood the SecurityClient should handle three diffrent types: JAAS Authentication, SASL and SimpleAuthentication. In fact currently only JAAS and SimpleAuthentication is provided. The SASLAuthentication throws currently a RuntimeException “Not implemented”. The default behaviour for the SecurityClient is the SimpleAuthentication. The SecurityClient uses the SecurityContext directly to set the credentials.

For convenience I’ll show you the sourcecode from part 1 again:

import java.util.Properties;
import javax.naming.Context;
import javax.naming.InitialContext;
import myea.beans.SayHello;
import org.jboss.security.client.SecurityClient;
import org.jboss.security.client.SecurityClientFactory;

public class Main {

public static void main(String[] args) throws Exception {
Properties env = new Properties();
env.setProperty(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
env.setProperty(Context.URL_PKG_PREFIXES, "org.jnp.interfaces.NamingContextFactory");
env.setProperty(Context.PROVIDER_URL, "jnp://localhost:1099/");

SecurityClient client = SecurityClientFactory.getSecurityClient();
client.setSimple("myuser", "123456");
client.login();

InitialContext ctx = new InitialContext(env);
SayHello h = (SayHello) ctx.lookup("SayHelloBean/remote");
System.out.println(h.sayHello("Marc"));
}
}

The important part is this one:

SecurityClient client = SecurityClientFactory.getSecurityClient();
client.setSimple("myuser", "123456");
client.login();

This authenticates the client. Or better: it prepares the client to authenticate on the next call to an secured bean on the AS. As mentioned above it’s possible to change the behavior of SimpleAuthentication to JAAS-authentication. For this kind of authentication you’ll have to change from setSimple to setJAAS. In this case you’ll need again the Callback and the login configuration from the first example.

It would look like that:

SecurityClient client = SecurityClientFactory.getSecurityClient();
client.setJAAS("my-security-client", myCbHandler);
client.login();

JndiLoginInitialContextFactory

JBoss also provides an InitialContextFactory which should combine both worlds: The creation of the initial context and the authentication. It’s mentioned on the JBoss wiki.

On the wiki there is this example:

Properties env = new Properties();
env.setProperty(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.security.jndi.JndiLoginInitialContextFactory");
env.setProperty(Context.PROVIDER_URL, "jnp://localhost:1099/");
env.setProperty(Context.SECURITY_PRINCIPAL, "username");
env.setProperty(Context.SECURITY_CREDENTIALS, "password");
InitialContext ctx = new InitialContext(env);

I’ve tried that but that doesn’t work. This JndiLoginContextFactory is meant for authentication of remote clients on the LoginInitialContextFactory page of the JBoss Wiki.

After using this InitialContextFactory I’ve received the following exception:

Exception in thread "main" javax.ejb.EJBAccessException: Caller unauthorized

This issue (JBAS-7010) is known and is already fixed in JBoss 6.0.0.M1.

When using JBoss security you’re typically confronted with JAAS: The Java Authentication and Authorization Service. This service is the standard mechanism to secure JavaEE applications in an applicationserver. Of course you can try to use spring-security to achieve this goal too but a) this can’t be used to secure the whole process in the applicationserver (for example: webapp->slsb->queue->mdb) and b) this is out of scope.

At first you’ll need an JBossAS 5.1.0. You can download it here. I’m currently using the 5.1 in my project so my experiences (especially the issues/pitfalls) base on this version. The issues which I’m reporting about might be in other versions as well or might already be fixed in following versions. The most explanations are more general so I expect that they’ll be correct for other versions of the JBoss as well.

After downloading the archive you’ll find a file called login-conf.xml in the [jboss_home]/server/default/conf/ directory. This file contains the security-domains which are available on the AS, such as: web-console, jmx-console and many others.

my-users.properties
my-roles.properties

This example entry is an application-policy. This policy contains the login-module UsersRolesLoginModule. This module is responsible for authenticating a user based on the provided password. It also provides the roles based on the authenticated principle. A principal is the provided username in the terminology of jaas, it is also named identity. There are some login-modules provided by JBoss, for example a DatabaseLoginModule, which authenticates/authorizes against a database. Some other allows a ldap-server as a backend or the authentication using certificates.

This UserRolesLoginModule uses files to authenticate and authorize the user. One is the my-users.properties and the other the my-roles.properties. Both are standard properties files with the format key = value. The first of them, the my-users.properties expects that the entries look like username = password:

myuser = 123456

The second one expects the following format: username = role1,role2,role3,…,rolen

myuser = testrole1, testrole2

These both files have to be located in the [jboss_home]/server/default/conf/. The entries for the files in the login-conf.xml can be changed, but keep in mind that they’re relative to the …/conf/ directory.

If you put this entry in login-conf.xml and the files in place you can start the JBossAS. If everything is okay you shouldn’t see any stacktraces. If there are errors have a look into the login-conf.xml. When the exception occures when starting the AS it’s only the login-conf.xml which could be wrong. The other both files are only accessed when an secured resource is accessed and related credentials are provided.

Now we have a JBossAS with a configured security domain. But we’ve got nothing to protect. The simplest way is to deploy a simple session bean with the needed annotations. At first we’ll create a standard and not secured sessionbean to see that everything works as expected:

Our sessionbean will just take one argument (your name) and will return a string “Hello [your_name]“.

The sessionbean:

import javax.ejb.Remote;
import javax.ejb.Stateless;

@Stateless
@Remote(SayHello.class)
public class SayHelloBean {
public String sayHello(String name) {
return "Hello " + name;
}
}

The related remote interface:

public interface SayHello {
public String sayHello(String name);
}

After deploying the bean and the interface in a jar to the deploy directory of the AS, it should show no exceptions.

The log or the console of the AS should show something similar to this:

23:52:06,370 INFO  [JndiSessionRegistrarBase] Binding the following Entries in Global JNDI:

SayHelloBean/remote - EJB3.x Default Remote Business Interface
SayHelloBean/remote-myea.beans.SayHello - EJB3.x Remote Business Interface

Now that your Bean is deployed successful we’ll switch to the client.

...
public static void main(String[] args) throws Exception {
Properties env = new Properties();
env.setProperty(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
env.setProperty(Context.URL_PKG_PREFIXES, "org.jnp.interfaces.NamingContextFactory");
env.setProperty(Context.PROVIDER_URL, "jnp://localhost:1099/");
InitialContext ctx = new InitialContext(env);
SayHello h = (SayHello) ctx.lookup("SayHelloBean/remote");
System.out.println(h.sayHello("Marc"));
}
...

This code should produce “Hello Marc”. If there are any failures please check if all the needed libraries are in the classpath or the settings are correct. Especially have a look on the PROVIDER_URL the wrong address is often a problem. Most people bind JBossAS to another IP-address to avoid binding errors for the 1099 port on windows systems which are connected to a domain.

If that’s successful we’ll try it ‘with security’. The sessionbean have to be changed:

The sessionbean with security:

import javax.annotation.security.RolesAllowed;
import javax.ejb.Remote;
import javax.ejb.Stateless;
import org.jboss.ejb3.annotation.SecurityDomain;

@Stateless
@Remote(SayHello.class)
@SecurityDomain("my-security")
@RolesAllowed({"testrole2"})
public class SayHelloBean {
public String sayHello(String name) {
return "Hello " + name;
}
}

The only changes are the both annotations: @SecurityDomain(“my-security”) and @RolesAllowed({“testrole2″}). The first activates security for this bean and connects to the “my-security” authentication-module. The next annotation define which roles have access to this class. It’s written in {} because it can contain several roles comma-seperated: {“testrole1″,”testrole2″}

If you’re using an IDE it might be the case that the IDE can’t find the annotation SecurityDomain. This is an extension aside the ejb3-spec made by JBoss. To use it you have to add the jboss-ejb3-ext-api.jar from the [jboss_home]/commons/lib/ folder. This jar contains several other very useful extensions to the ejb3-spec. But be warned, since this point you’re leaving the compliance to the ee-spec and you’ll tie yourself/your project to the JBossAS.

When you now try to connect using the client above it will result in this:

Exception in thread "main" javax.ejb.EJBAccessException: Caller unauthorized
... (some more stacktrace) ...

Now we’ve got to modify the client as well:

public static void main(String[] args) throws Exception {
Properties env = new Properties();
env.setProperty(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
env.setProperty(Context.URL_PKG_PREFIXES, "org.jnp.interfaces.NamingContextFactory");
env.setProperty(Context.PROVIDER_URL, "jnp://localhost:1099/");

SecurityClient client = SecurityClientFactory.getSecurityClient();
client.setSimple("myuser", "123456");
client.login();

InitialContext ctx = new InitialContext(env);
SayHello h = (SayHello) ctx.lookup("SayHelloBean/remote");
System.out.println(h.sayHello("Marc"));
}

This client should produce the same output like the client without authorization. In this case I’ve used a very simple way to manage the authentication. Within one of the next parts of this article series I’ll show you the different ways to connect to a secured JBossAS.

Now you’ve made the first step in JBoss & Security.

At first you’ll need the portal. You can obtain it for free from the liferay-website. There you’ll find two versions on the download page: The Enterprise Edition and the Community Edition. For this tutorial I’ll use the community edition.

After downloading the edition you’ll extract it to your favorite place.

When extracted you’ll find a liferay folder and within this folder you’ll find a tomcat folder. Within the webapps folder of the tomcat directory are two webapps: sevencogs-hook and sevencogs-theme. These both should be deleted. They belong to the demo-data which we didn’t want to install.

After removing these webapps you’ll change to the WEB-INF/classes of the ROOT webapp. Which is also located in the webapps folder of the tomcat. Within this folder you should create an portal-ext.properties. And fill it with these settings:

jdbc.default.driverClassName=com.mysql.jdbc.Driver
jdbc.default.url=jdbc:mysql://localhost/liferay?useUnicode=true&characterEncoding=UTF-8&useFastDateParsing=false
jdbc.default.username=liferay
jdbc.default.password=<password>
schema.run.enabled=true
schema.run.minimal=true

The first four lines define the database connection. The mentioned database and (of course) the user have to be created before starting the portal. Please adjust the database-settings for your needs. That means change databasename, host, username, password, etc. to the values you’ve got on your platform.

The last two lines are settings for the portal. The first activates the schema generation (tables etc. should be created) and the second is the setting which tells the portal only to insert only the minimal data for the portal. This setting set to true avoids that the demo-data is inserted in the database.

Now, that everything is done, you can start the portal using the startup script in the tomcat-<version>/bin/ directory.

After starting you can sign in using the default user/pass of liferay. Now you’ve got a clean installation of the “Liferay Portal Community Edition”.