Adding LDAP Authentication to a Play! 2 Application

As of Play! 1 is not really supported anymore, i will describe the steps for accessing Data from your LDAP Directory with your Play! 2 with this Post.

Prerequisites

As also mentioned in my last Post, for this example we are using the Vagrant vagrant-rundeck-ldap VM, I already mentioned here.

Setup

After you setup a basic Play! 2 Application with

play new ldap-test

We need to update our Applications Dependencies. To achieve this, we need to change project/Build.scala:


import sbt._
import Keys._
import play.Project._

object ApplicationBuild extends Build {

  val appName         = "play2-ldap-example"
  val appVersion      = "1.0-SNAPSHOT"

  val appDependencies = Seq(
    // Add your project dependencies here,
    javaCore,
    javaJdbc,
    javaEbean,
    "com.innoq.liqid" % "ldap-connector" % "1.3"
  )

  val main = play.Project(appName, appVersion, appDependencies).settings(
    // Add your own project settings here      
  )
}

The Command:


play compile

Should download all necessary Project Depedencies and will do an initial Compilation of all your Project Files (currently not really many).

You also need to add the LDAP Settings to your Applications configuration. For this example we will use an external Properties File conf/ldap.properties:


# Settings for LiQID
# ~~~~~
ldap.user.objectClasses=person
ldap.group.objectClasses=groupOfUniqueNames

default.ldap=ldap1
# LDAP Listsing, divided by ","
ldap.listing=ldap1

ldap1.ou_people=ou=users
ldap1.ou_group=ou=roles
ldap1.url=ldap://localhost:3890
ldap1.principal=dc=Manager,dc=example,dc=com
ldap1.credentials=password

ldap1.base_dn=dc=example,dc=com
ldap1.admin.group.id=admin

ldap1.user.id.attribute=cn
ldap1.user.object.class=person

ldap1.group.id.attribute=cn
ldap1.group.object.class=groupOfUniqueNames
ldap1.group.member.attribute=uniqueMember

Implementation

Since Play1 2 does not really support the use of Before Filters, we will use Custom Actions for making our Login Authentication work.
We will create a new Package app/actions with two new files: an annotation interface BasicAuth and the implementation itself BasicAuthAction.
Annotations will be used to Set a specific Controller to use Basic Auth.
So lets start with BasicAuth:


package actions;

import play.mvc.With;

import java.lang.annotation.Documented;
import java.lang.annotation.ElementType;
import java.lang.annotation.Inherited;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@With(BasicAuthAction.class)
@Retention(RetentionPolicy.RUNTIME)
@Target({ ElementType.METHOD, ElementType.TYPE })
@Inherited
@Documented
public @interface BasicAuth {
}

After that you can annotate Controllers with @BasicAuth (but this won’t work, since the Implementation is still missing).
Here then the BasicAuthAction:



package actions;

import com.ning.http.util.Base64;

import models.User;
import play.mvc.Action;
import play.mvc.Http.Context;
import play.mvc.Result;

public class BasicAuthAction extends Action {

	private static final String AUTHORIZATION = "authorization";
	private static final String WWW_AUTHENTICATE = "WWW-Authenticate";
	private static final String REALM = "Basic realm=\"play2-ldap-example\"";

	@Override
	public Result call(Context context) throws Throwable {

		String authHeader = context.request().getHeader(AUTHORIZATION);
		if (authHeader == null) {
			return sendAuthRequest(context);
		}

		String auth = authHeader.substring(6);

		byte[] decodedAuth = Base64.decode(auth);
		String[] credString = new String(decodedAuth, "UTF-8").split(":");

		if (credString == null || credString.length != 2) {
			return sendAuthRequest(context);
		}

		String username = credString[0];
		String password = credString[1];
		User authUser = User.authenticate(username, password);
		if (authUser == null) {
			return sendAuthRequest(context);
		}
		context.request().setUsername(username);
		return delegate.call(context);
	}

	private Result sendAuthRequest(Context context) {
		context.response().setHeader(WWW_AUTHENTICATE, REALM);
		return unauthorized();
	}
}

As you can see, there are no LDAP specific Dependencies at all, since all necessary Logic is the User Model, in User.authenticate(username, password).So let’s have a look into that Model:


package models;

import play.Play;

import com.innoq.ldap.connector.LdapHelper;
import com.innoq.ldap.connector.LdapUser;
import com.innoq.liqid.utils.Configuration;

public class User {

	private static LdapHelper HELPER = getHelper();

	public String sn;
	public String cn;
	public String dn;

	public User(String cn) {
		this.cn = cn;
	}

	public String toString() {
		StringBuilder sb = new StringBuilder();
		sb.append("cn: ").append(cn).append("\n");
		sb.append("sn: ").append(sn).append("\n");
		sb.append("dn: ").append(dn).append("\n");
		return sb.toString();
	}

	public static User authenticate(String username, String password) {
		if (HELPER.checkCredentials(username, password)) {
			return new User(username);
		}
		return null;
	}

	public static User getUser(String username) {
		LdapUser ldapUser = (LdapUser) LdapHelper.getInstance().getUser(
				username);
		User user = new User(username);
		user.cn = ldapUser.get("cn");
		user.sn = ldapUser.get("sn");
		user.dn = ldapUser.getDn();
		return user;
	}

	private static LdapHelper getHelper() {
		Configuration.setPropertiesLocation(Play.application().path()
				.getAbsolutePath()
				+ "/conf/ldap.properties");
		return LdapHelper.getInstance();
	}
}

You also have a static Instace of that LDAP Helper, but authenticate User Credentials and Login are in two different Methods.Last thing is to Load a User from the LDAP Directory:Here the Admin Controller:


package controllers;

import models.User;
import actions.BasicAuth;
import play.mvc.Controller;
import play.mvc.Result;
import views.html.Admin.index;

@BasicAuth
public class Admin extends Controller {
    public static Result index() {
    	User u = User.getUser(request().username());
        return ok(index.render("Hello Admin!", u));
    }
}

And here the used Template File:


@(message: String, user: User)

@main("Admin Index") {
@{message} 
<p>   
<pre>
@{user}
</pre>
</p>
}

Links

You can find the Sources of that Library here: https://github.com/innoq/LiQIDYou can find an example Project here: https://github.com/phaus/play-ldap/tree/master/play2-ldap-example

Adding LDAP Authentication to a Play! 1 Application

You will often find yourself in a situation where you need a public and a private (normally some Administration) Area in your application.

This Post is about how easy you can access User Data stored in you companies LDAP Directory with a public availible Library in a Play! 1 Application. I will also give you an example for Play! 2 in one of the upcoming Posts here.

Prerequisites

For this example we are using the Vagrant vagrant-rundeck-ldap VM, I already mentioned here.

Setup

After you setup a basic Play! 1 Application with

play new ldap-test

We need to add the necessary Dependencies to our Application. Since the Library is availible over the public Maven Repository the Changes in your conf/dependecies.yml are quite simple:


# Application dependencies
require:
    - play
    - com.innoq.liqid -> ldap-connector 1.3

You then need to update your Applications Dependencies with:

play deps --sync

We also need to add some Configration Settings to the conf/application.conf File:
(there are some more, since the Example Directory did not match to the Libraries default LDAP Layout)


...
# Settings for LiQID
# ~~~~~
# Basic LDAP objectClasses for Users and Groups
ldap.user.objectClasses=person
ldap.group.objectClasses=groupOfUniqueNames

# You can add several LDAP for Writing Changes, but you need one default LDAP for Access without a specifiy Instance String (e.g. ldap1, ldap2, etc).
default.ldap=ldap1
ldap.listing=ldap1

# Instance specific settings (e.g. credentials, layout, etc. )

ldap1.ou_people=ou=users
ldap1.ou_group=ou=roles
ldap1.url=ldap://localhost:3890
ldap1.principal=dc=Manager,dc=example,dc=com
ldap1.credentials=password

ldap1.base_dn=dc=example,dc=com
ldap1.admin.group.id=admin

ldap1.user.id.attribute=cn
ldap1.user.object.class=person

ldap1.group.id.attribute=cn
ldap1.group.object.class=groupOfUniqueNames
ldap1.group.member.attribute=uniqueMember

Implementation

We will use two different techniques:

  • Controller inheritance
  • Before Filters

The goal is, that for a specific Count of Controllers, the Request should be checked for a valid Autorization Header.
So all Controllers that need to be “protected” will inherit from a Controller named SecureApplication.
This SecureApplication Controller will implement a Before Filter and some Utility Methods to perform all necessary Login Verification.

This is the basic Implementation of that Controller:


package controllers;

import com.innoq.ldap.connector.LdapHelper;
import com.innoq.liqid.utils.Configuration;

import play.Logger;
import play.Play;
import play.mvc.Before;
import play.mvc.Controller;

public class SecureApplication extends Controller {
	private final static LdapHelper HELPER = getLdapHelper();
	@Before
	public static void checkLogin() {
		if (request.user == null || request.password == null
				|| !HELPER.checkCredentials(request.user, request.password)) {
			unauthorized("You need to Login first!");
		}
	}
	private static LdapHelper getLdapHelper() {
		Configuration.setPropertiesLocation(Play.applicationPath
				+ "/conf/application.conf");
		return LdapHelper.getInstance();
	}	
}

In the getLdapHelper() Methods you also see, that the location of the Configuration is changed to ../conf/application.conf.
Otherwise the Default Location would be in ~/.liqid/ldap.properties.

The Before Action checkLogin is triggered on every Request to a Controller that inherits from SecureApplication.
All other Controllers (inheriting the normal Controller Class), won’t trigger that Application.

You also can access all Data stored in the LDAP Directory. So if you want to access Attributes like cn, dn and sn, you need to add some more Code:
First we will create a basic POJO that contains all User data:


package models;

public class User {
	public String cn;
	public String sn;
	public String dn;

	public User(String cn, String sn, String dn) {
		this.cn = cn;
		this.sn = sn;
		this.dn = dn;
	}

	public String toString() {
		StringBuilder sb = new StringBuilder();
		sb.append("cn: ").append(cn).append("\n");
		sb.append("sn: ").append(sn).append("\n");
		sb.append("dn: ").append(dn).append("\n");
		return sb.toString();
	}
}

We then will update our SecureApplication Class:


package controllers;

import models.User;

import com.innoq.ldap.connector.LdapHelper;
import com.innoq.ldap.connector.LdapNode;
import com.innoq.liqid.model.Node;
import com.innoq.liqid.utils.Configuration;

import play.Logger;
import play.Play;
import play.mvc.Before;
import play.mvc.Controller;

public class SecureApplication extends Controller {
	private final static LdapHelper HELPER = getLdapHelper();
	protected static User ActiveUser;
	@Before
	public static void checkLogin() {
		if (request.user == null || request.password == null
				|| !HELPER.checkCredentials(request.user, request.password)) {
			unauthorized("You need to Login first!");
		} else {
			ActiveUser = getUser(request.user);
		}
	}

	private static LdapHelper getLdapHelper() {
		Configuration.setPropertiesLocation(Play.applicationPath
				+ "/conf/application.conf");
		return LdapHelper.getInstance();
	}

	private static User getUser(String cn){
		LdapNode ldapNode = (LdapNode) HELPER.getUser(cn);
		return new User(cn, ldapNode.get("sn"), ldapNode.getDn());
	}
}

As you can see, there is a specific NodeType LdapNode that has some Convenience Methods for accessing the LDAP Data.
As Example you can invoke the toString() Method of an User Object in your template.

So first we will have to create our Admin Controller:


package controllers;

import models.User;

public class Admin extends SecureApplication {
	public static void index(){
		User u = ActiveUser;
		render(u);
	}
}

You have to use another Object u for that User, since Play! 1 has a specific Behavior of how to map Variables in Templates.
Our Template app/views/Admin/index.html might look like this:


#{extends 'main.html' /}
#{set title:'Admin Area' /}
Hello Admin!
<pre>
${u}
</pre>

If you login then with the Credendials build/build your output might look then like this:

 Index | Administration
Hello Admin!

cn: build
sn: The account to use to demonstrate managing builds only
dn: cn=build,ou=users,dc=example,dc=com

Links

You can find the Sources of that Library here: https://github.com/innoq/LiQID
You can find an example Project here: https://github.com/phaus/play-ldap/tree/master/play1-ldap-example

Feel free to add issues about bugs or missing features to this :-).

play-i18ned

This Module provides support for converting Play! i18n Files into an Excel Sheet and from an Excel Sheet to i18n Files.

Usage

You need to create the message files first (e.g. conf/messages, conf/messages.de, conf/messages.en)
You may enter some key/value entries to the Files.

The prefered format is:

# Description key=value 

Add the Module to your dependencies:


require: 
... - local -> i18ned 0.1 
... repositories: 
    - local: 
          type: local
          artifact: ${application.path}/../modules/[module]/dist/[module]-[revision].zip 
     contains: - local -> * 


Then install the Module

play deps --sync 

Export (creating Excel File)

play i18ned:export 

Your will find the Excel File in APP_DIR/tmp/i18n.xls

Import (Moving Changes from the Excel File into the Messages Files)

play i18ned:import 

TODO

  • Adding SQL-Export with SQL-Templates
  • Adding Support for selective Actions (Im/Export only specific files)
  • Import from other i18n Formats

Link

https://github.com/phaus/play-i18ned

Starting work on a new ZFS Web Admin

Hello there.

After the Stats showed me, that the ancient Post about a Web based ZFS Interfaces produces a lot attention, i decided to restart with that project from scratch.

You can find the current sources here. I am currently working with the FreeBSD ZFS Version (so basically FreeNAS), but there are already some Test-Cases for Nexenta.
The basic idea of the system is, to use remote SSH Sessions for accessing the different systems and parse the receiving data. There is already a quite stable, JNA based Java Binding for ZFS, but it seems to be broken for the latest Versions of ZFS. And to have a simple solution to manage ZFS on different system, seems to me a great idea.

I have some ideas how to do some things, but it still seems a lot of work :-).

Fixing Redirects of a Play! App behind an Apache2 SSL Proxy

So you just finished your first Play! App. You want to run that thing behind an Apache2 as a HTTPS Proxy, because you do not want, that your User-Credentials are read as clear text.

So a very basic Apache Configuration looks like this:

    <IfModule mod_ssl.c>

        Listen 443
        SSLRandomSeed startup builtin
        SSLRandomSeed connect builtin

        <VirtualHost _default_:443>

            SSLEngine on
            ServerName example.com
            ServerAdmin admin@example.com
            ErrorLog /var/log/apache2/ssl_error_log

            SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
            SSLCertificateFile /etc/apache2/ssl/example/newcert.pem
            SSLCertificateKeyFile /etc/apache2/ssl/example/webserver.nopass.key
            SSLCACertificateFile /etc/apache2/ssl/demoCA/cacert.pem
            SSLCARevocationPath /etc/apache2/ssl/certs/demoCA/crl

            ProxyPass               /play            http://127.0.0.1:9000/play
            ProxyPassReverse        /play            http://127.0.0.1:9000/play

        </VirtualHost>

    </IfModule>

I did already explained how to run a Play! Application within a Application Context. Here our Context is just “play”, but you can set it to something else. You can also change and add seperate instances with different ports (over 9000!!!).

You should alter two settings in your conf/application.conf

    # you need to add this
    context=/play

    # you need to uncomment this to prevent Play! from serving aside your Apache2 Proxy
    http.address=127.0.0.1

   # you may uncomment and change this port number for chaning it
   # http.port=9000

Time for a Test Run. At a first glance it seems to work pretty nice. But as soon as you want to use the nifty routing redirects from Play!, the whole system breaks, because Play! still things, it runs in plain http on port 9000. To solve this, you need to change to things:

  1. Make Apache2 to send a specific header, that the Request was send through a Proxy
  2. Make Play! to fix the redirect to the correct URL

The first part is pretty easy. Just add

    RequestHeader set X_FORWARDED_PROTO 'https'

within your VirtualHost Tag – you may need to enable the headers module first to make that work.

The second part is a little bit more difficult. You have to add a before filter to your application controller:

    public class Application extends Controller {

        @Before
        private static void checkSSL() {
            if (request.headers.get("x_forwarded_proto") != null
                    && "https".equals(request.headers.get("x_forwarded_proto").value())) {
                request.secure = true;
                request.port = 443;
            }
            if (request.headers.get("x-forwarded-server") != null) {
                request.domain = request.headers.get("x-forwarded-server").value();
            }
        }
        ...
    }

You can find the sources on GitHub.
B.t.w. the same problem also might appears in Rails Apps, i might write about this later on.

Hacking just for Fun: using Bookmarklets

So there are a handful of webtools using Bookmarklets for their services. The first i know was del.icio.us for saving a Webpage to your del.icio.us bookmarks. Another famous service is Instapaper (it uses internally read it later pocket, but that is another Story). I have a special service in mind, i want to create using a Bookmarklets, before i start, i played around with the Bookmarklet from Instapaper.

The Magic is just a normale HTML A Tag, in whith some javascript is embedded:

javascript:function%20iprl5(){var%20d=document,z=d.createElement('scr'+'ipt'),b=d.body,l=d.location;try{if(!b)throw(0);d.title='(Saving...)%20'+d.title;z.setAttribute('src',l.protocol+'//www.instapaper.com/j/foobar?u='+encodeURIComponent(l.href)+'&t='+(new%20Date().getTime()));b.appendChild(z);}catch(e){alert('Please%20wait%20until%20the%20page%20has%20loaded.');}}iprl5();void(0)

If we unwrap that script we got

function iprl5(){
    var d=document,
    z=d.createElement('scr'+'ipt'),
    b=d.body,
    l=d.location;
    try{
        if(!b)
            throw(0);
        d.title='(Saving...) '+d.title;
        z.setAttribute('src',l.protocol+'//www.instapaper.com/j/foobar?u='+encodeURIComponent(l.href)+'&t='+(new Date().getTime()));
        b.appendChild(z);
    }catch(e){
        alert('Please wait until the page has loaded.');
    }
}
iprl5();
void(0)

The command basically just creates a script tag in the active DOM-Tree and preloads some Javascript-File. The File is then executed by the Browsers JS Runtime.
I started a litte Demo Project. You find it here on GitHub. It is based on Play! 1.2.4 (Installation Guide here).

ATM there are just two JS Templates. The first one (app/views/Application/bookmarklet.js) just contains the source for the Script-Tag itself. The second (app/views/Application/input.js) will be loaded then after the Javascript behinde that link is called.

Run local/remote terminal commands with java using ssh

Sometimes you need to use some CLI-Tools before you want to create or search for a native JNI Binding.
So there is a common way, using the Java Process-Class. But then you might meet two problems i had to face in the past during several problems:

  1. There are (a really small) number of CLI-Tools, that giving no constant output over the STD-OUT (the standard output the Process-Class uses for output)
  2. There is no “elegant” way to implement a process call into your project.

To solve this Problem I created a basic HelperClass, that calls the System over SSH (with the Convenience to work remote and the side-effect to always get STD-compatible output).
I am primarely using it for a fun project SAM i started some months ago to try to create a Management-Tool for Unices and Windows with a very low client-side footprint.

The first Class is used to capsulate the basic SSH Calls:

 
// some imports... 
 public class SystemHelper {
    private Runtime r;
    private String sshPrefix = "";

    // call with $user and 127.0.0.1 to run local command.     
    public SystemHelper(String user, String ip) {
        r = Runtime.getRuntime();
        sshPrefix = " ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no " + user + "@" + ip;
    }

    public void runCommand(String command, ProcessParser pp) {
        try {
            Logger.info("running: " + this.sshPrefix + " " + command);
            Process p = r.exec(this.sshPrefix + " " + command);
            InputStream in = p.getInputStream();
            BufferedInputStream buf = new BufferedInputStream(in);
            InputStreamReader inread = new InputStreamReader(buf);
            BufferedReader bufferedreader = new BufferedReader(inread);
            pp.parse(bufferedreader);
            try {
                if (p.waitFor() != 0) {
                    Logger.info("exit value = " + p.exitValue());
                }
            } catch (InterruptedException e) {
                System.err.println(e);
            } finally {
                // Close the InputStream                 
                bufferedreader.close();
                inread.close();
                buf.close();
                in.close();
            }
        } catch (IOException ex) {
            Logger.error(ex.getLocalizedMessage());
        }
    }
}

ProcessParser is an interface that defines the methode parse, accepting a BufferedReader for parsing the output of the Process. Unfortunately there is no timeout ATM to kill a hanging SSH-Call.

 public interface ProcessParser { 
     public void parse(BufferedReader bufferedreader); 
 } 

The most basic (Output-)Parser looks like this:

 
    public String getPublicSSHKey() {
        SimpeOutputPP so = new SimpeOutputPP();
        String command = "cat ~/.ssh/id_rsa.pub";
        runCommand(command, so);
        if (!so.getOutput().isEmpty()) {
            return so.getOutput().get(0);
        }
        return "";
    }

This returns just the public SSH-Key of the current user. I implemented some more parsers for the output of apt (dpkg), rpm and pacman. You can find them in the github project here.

Counter Update

I just finished my latest improvements to the legacy version of my counter script.
I just added the lookup for ISPs and added dynamic scaling for the axis legend.
I will now going forward to change the whole system to a more sophisticated software, e.g. using a Datawarehouse approach. The first version of the Data-Model is finished.

So from the old version (that was just some plain tables, flowing around)

 

 

 

 

 

 

 

 

 

 

I created a new Model with more Tables, connected to each other. Basically i devided the Model into a basic Fact (Count) and some Dimensions (for every Value):

 

 

 

 

 

 

 

 

 

 

With my current values (around 22k Facts), i have already to limit the facts that are queryed from the Datebase. I wrote a short script to migrate all old Datasets to the new Data-Model.

Testing Play! Applications with HTTP Basic Auth

Um eine Play!-Anwendung zu testen, welche HTTP-Basic-Auth verlangt ist es notwendig, die Standard-Datei ApplicationTest.java anzupassen:
Verändert werden muss die Test-Methode testThatIndexPageWorks():

Aus

    @Test
    public void testThatIndexPageWorks() {
        Response response = GET("/");
        assertIsOk(response);
        assertContentType("text/html", response);
        assertCharset(play.Play.defaultWebEncoding, response);
    }

Wird:

    @Test
    public void testThatIndexPageWorks() {
        Request request = FunctionalTest.newRequest();
        request.user = "test";
        request.password = "test";
        request.url = "/";
        Response response = GET(request, "/");
        assertIsOk(response);
        assertContentType("text/html", response);
        assertCharset("utf-8", response);
    }

Wobei User = test und Passwort = test.
Bei allen weiteren Test-Methoden verfährt man analog, oder erstellt sich eine Factory-Methode für den Request.

Play! Applications und der App-Context

Es ist möglich, eine Play!-Anwendung sehr einfach in eine WAR-Struktur zu übertragen und in einen Application-Server zu deployen.
Dies ist recht gut unter Deployment options in der Play!-Dokumentation recht gut erklärt. Was hier allerdings verschwiegen wird ist, wie man den notwendigen Context beim Routing konfiguriert. (Der Context ist der Pfad der Anwendung, welcher standardmäßig vom Namen des WAR-Archivs abgeleitet wird, oder per Descriptor konfiguriert wird) – heißt das Archiv testapp.war ist der Context /testapp.

Innerhalb einer Play!-App muss der Context sowohl in der Config Datei, als auch im Routing definiert werde:

application.conf

...
context=testapp
...

Danach lässt sich in der routes Datei der Context in die Routen konfigurieren:

# Routes
# This file defines all application routes (Higher priority routes first)
# ~~~~

%{ context = play.configuration.getProperty('context', '') }%

# Home page
GET     ${context}                                        Application.index
GET     ${context}/                                       Application.index

# Map static resources from the /app/public folder to the /public path
GET     ${context}/public/                                staticDir:public
GET     ${context}/Users/like/{uid}                       Users.like
GET     ${context}/Users/{uid}/show                       Users.show
...