Active Directory Authentication in Java

Doing Active Directory authentication in Java can be a nightmare. Documentation is scarse and Java APIs are usually counter-intuitive.

I’ve spent a good time to get it right (or what I guess is right), and I hope that this code sample can help others. Just use it, code is under WTFPL license.

Summary to validate if a user is in a group:

  1. Java requires the user full DN to authenticate;
  2. Authenticate to LDAP using a master user;
  3. Search user DN;
  4. Reauthenticate using user DN;
  5. Fetch all groups of user;
  6. Check if the required group is in it.
package com.tnegri.sample;

import java.util.*;

import javax.naming.*;

public final class ActiveDirectoryFacade {

    private static final MASTER_USER_DN;
    private static final MASTER_PASSWORD;

    static {
        // Sample configuration.
        MASTER_USER_DN = "CN=masteruser,OU=Users,DC=tnegri,DC=com";
        MASTER_PASSWORD = "m4sterP4ssw0rd";

    private final String ldapUrl;
    private final String searchBase;

     * @param ldapUrl LDAP URL, e.g. "ldap://"
     * @param searchBase Base for doing user search, 
     *                   e.g. "OU=Users,DC=tnegri,DC=com"
    public ActiveDirectoryFacade(String ldapUrl, String searchBase) {
        this.ldapUrl = ldapUrl;
        this.searchBase = searchBase;

    public boolean hasGroup(String username, String password, 
                            String groupObjectName) 
            throws NamingException {
        List<String> allGroups = getAllGroups(username, password);
        return allGroups.contains(groupObjectName);

    private List<String> getAllGroups(String username, String password)
            throws NamingException {
        List<String> result = new ArrayList<>();

        String attributeToLookup = "memberOf";

         * 1. Authenticate using master user.
        DirContext ctx = authenticate();

         * 2. Searches by "sAMAccountName" to recover the full
         *    DN of the username trying to login.
        SearchControls searchControls = new SearchControls();
                new String[] {"distinguishedName"});
        NamingEnumeration<SearchResult> searchResults =
                String.format("(sAMAccountName=%s)", username),
        if (!searchResults.hasMore()) {
             * If can't resolve DN, the user doesn't exists.
            throw new NamingException();
        SearchResult searchResult =;
        Attributes attributes = searchResult.getAttributes();
        Attribute attribute = attributes.get("distinguishedName");
        String userObject = (String) attribute.get();

         * 3. Authenticates to LDAP with the user, will throw if
         *    password is wrong.
        ctx = authenticate(userObject, password);

         * 4. Fetch all groups of user.
        attributes = ctx.getAttributes(userObject, 
                                       new String[] {attributeToLookup});

        NamingEnumeration<? extends Attribute> allAttributes =
        while (allAttributes.hasMoreElements()) {
            attribute = allAttributes.nextElement();
            int size = attribute.size();
            for (int i = 0; i < size; i++) {
                String attributeValue = (String) attribute.get(i);


        return result;

    private DirContext authenticate() throws NamingException {
        return authenticate(null, null);

    private DirContext authenticate(String username, String password)
            throws NamingException {
        String initialContextFactory = "com.sun.jndi.ldap.LdapCtxFactory";
        String securityAuthentication = "simple";

        Hashtable<String, String> env = new Hashtable<>();
        env.put(Context.INITIAL_CONTEXT_FACTORY, initialContextFactory);
        env.put(Context.SECURITY_AUTHENTICATION, securityAuthentication);
        env.put(Context.PROVIDER_URL, ldapUrl);
                username != null ? username : MASTER_USER_DN);
                password != null ? password : MASTER_PASSWORD);

        DirContext ctx = new InitialDirContext(env);

        return ctx;

JavaScript, Assumption Inversion Principle and modularity

On past posts (1, 2) I tried to described what I call Assumption Inversion Principle. Well, talk is cheap, show me the code!

I’m trying to apply AIP on a personal project without infecting (much) the global namespace and going only with raw JavaScript to avoid unnecessary dependencies on things like RequireJS.

That’s the template I have come up with so far (gist):

File...: foo.js
Exports: bar, baz
Depends: spam, eggs
;(function (namespace) {
 'use strict' = function (namespace) {
   /* Dependencies */
   var spam = namespace.spam
   var eggs = namespace.eggs

   function bar () {

   function baz () {

   /* Exports */ = bar
   namespace.baz = baz
}((function () {
  if (typeof window === 'undefined') {
    return module.exports
  } else {
    return window

The file can be used by the browser or as a NodeJS module. At the browser it will register an initialization function on “window” and as a NodeJS module it exports the initialization function.

How to use it? Just include every module and use each initialization function to populate your namespace:

 * Namespace of our app.
var myApp = {}

 * Initialize 'fooDeps' module
 * e.g. registers 'spam' and 'eggs' on namespace

 * Initialize 'foo' module
 * Uses 'spam' and 'eggs' and registers 'foo' and 'bar'

And what do I gain with it? Well, I can treat modules as first-class citizens. Instead of bloating the code with objects and pretty patterns as singletons and factories, each module code knows how to initialize itself, so they are pretty straight forward. As they only use assumptions about their dependencies, the module code easy adapts to other environments. Classic example on single project: production code uses the real dependencies and test code uses mocks or simples objects. On multiple projects, the implementation of each dependency can be selected on whatever reason.

The particular project I’m working on is a Word Finder style game. We use a word dictionary and a random letter generator to populate the board. The random letter generator uses the ratio of frequency of each letter at the dictionary to select the random letters with the same ratio (gist):

;(function (namespace) {
  'use strict'

  namespace.randomlettergenerator = function (namespace) {
    var total = 0
    var lettersArray = []

     * Populates "lettersArray" and computes "total".
    ;(function () {
      var letters = {}
      namespace.dictionaries.forEach(function (word) {
        var i, len, letter
        for (i = 0, len = word.length; i &lt; len; i++) {
          letter = word[i]
          if (typeof letters[letter] === 'undefined') {
            letters[letter] = { letter: letter, count: 1 }
          } else {
            letters[letter].count += 1
          total += 1

     * Sorts by descending letter frequency
    lettersArray.sort(function (a, b) {
      if (a.count > b.count) {
        return -1
      if (a.count < b.count) {
        return 1
      return 0

     * Random letter generator.
    function RandomLetterGenerator () {
      this.lastIx = -1

     * Returns a random letter.
     * @return Random letter.
     */ = function () {
      var i = this.lastIx
      var len = lettersArray.length
      var count = Math.random() * total

      while (count > 0) {
        if (i >= len) {
          i = 0
        count -= lettersArray[i].count

      this.lastIx = i
      return lettersArray[i].letter

    namespace.RandomLetterGenerator = RandomLetterGenerator
}((function () {
  if (typeof window === 'undefined') {
    return module.exports
  } else {
    return window

Notice the module initialization code, it is possible to mock out or use multiple dictionaries to initialize different namespaces with different versions of RandomLetterGenerator class. The same effect is possible using pure OO factory pattern.

Other modules are responsible for finding words and checking board properties. The dictionaries are always an assumption, so the code is easily testable, even without objectifying everything.

I’m currently feeling good with the code. Not sure how it will scale.

Impostor Syndrome

I like to know how to name psychological effects, and I just learned a new one: Impostor syndrome.

This one adds to two others I like: Dunning-Kruger effect and the Bystander effect.

The impostor syndrome is kind of funny, tough. If you recognize that you had passed by an episode of it, then you understand either that:

  1. You are a high-achiever, so you deserve it, so you are cured from the impostor syndrome; or
  2. You projected a false high-expectation from others towards yourself, so you are not a high-achiever, but noone was expecting that anyway; or
  3. You are a fraud.

The only way to figure it out is to really put you up the test. Too bad when you miss an opportunity to burn that feeling.

Follow-up: Why JavaScript and PHP rule the web

The Reddit discussion of my earlier post “Why JavaScript and PHP rule the web” had good comments and made me wonder a bit more about the subject.

There are two comments of mine that I think are worth enough to put up on the blog, even if it is for being bashed by the internet, as it adds more substance to my opinion.

“pinnr” reminded me that both languages has lot of flaws, and I agree. But why no substitute won so far? That’s my comment for it:

That’s a good point. PHP and JS are full of “gotchas”. It makes me wonder, why no other languages have replaced them already?

Maybe if a new language can be as permissive and flexible as JS and PHP are, use an easy to understand flow (both are basically an infinite interactive loop) and adds more “sanity” to it, then it could win. The problem could be that new languages tries to be saner and stricter at the same time, and the web doesn’t like the stricter part. Does it make sense?

From “aslate” comments, I believe some people thinks that WordPress plugin system is just an example of a well defined API, and has no relation to PHP itself, as it could be made in any other language. I do believe that almost any high level language can be used to build a plugin system, but not as flexible as PHP would (or other languages that uses the “Assumption Inversion Principle”). That’s my answer to it:

Types, imports and modules enforce too much for the web. That’s my point of view.

By using only assumptions in your code, you don’t care how those assumptions are met, you just believe they will be somehow. It is like Dependency Injection, but at a more granular level.

Writing a single piece of plugin code that works on multiple versions of WordPress, leveraging new functionality when available is as simple as checking if a function exists (inspecting the environment) and adapting.

Imagine that JS used modules from the very start. A lot of libraries would have require('jquery') to only ever use a minor subset of it. This is where “assumptions” shine, you only pay for the exact subset of assumptions you make, and your code believes they would be fulfilled somehow.

jQuery has alternatives, underscore.js has alternatives, Backbone.js has alternatives. If each module selected one that better fits its need and you end up using those modules, you would end up with a bunch of duplicated JS functionality in your final product.

That’s the main point: when you require/import/etc something. You are locking your code with a preset selection that you made for whatever reason, and you are forbidding others to change that. There are plenty of reasons that other developers would want to change that selections (e.g. add a cache layer, only use a subset for space constraint reasons, completely mock it out for testing, use a proxy pattern to delegate things for a remote service, …).

Coming up with an API that fits every need is completely impossible. IMHO it is better that each code use assumptions about its dependencies, the same way a JS or a PHP function use assumptions about its arguments.

So, what I’ve called as Assumption Inversion Principle may have a 1:1 relation with duck typing of variables, but taken to the module level.

I like how a single function in JavaScript can be used in any type of object, as long as it has some properties that are assumptions of the function itself. Don’t you?

If you are an advocate of duck typing, why not advocate a “duck typing of dependencies”? What is the fundamental differences that I am missing here?

Priority of Constituencies

An awesome paragraph from W3C’s HTML Design Principles:

3.2. Priority of Constituencies

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone. Of course, it is preferred to make things better for multiple constituencies at once.

Why JavaScript and PHP rule the web

JavaScript and PHP are excellent languages. It took some time for me to really understand their power, and I hope to clarify my point of view in this post.

I believe that those languages shine and survive for being permissive and by adopting an Assumption Inversion Principle (AIP) — I’ve made up that name, you may suggest a better one in the comments. 🙂

What is AIP?

Raw JavaScript does not have any module definition structure, no statements as “import” or “include”. Symbols available for a piece of code written in JavaScript are pure assumptions. Those assumptions must be satisfied by other pieces of code, and not by itself. It is incredibly easy to change behaviours by loading new script files before the one to be changed by changing the link of its assumptions. This “change by adding” relates directly with the “O” in the SOLID principles.

Old PHP code goes the same way, your piece of code has some assumptions that some symbols are available and you simply use it. It is not the responsibility of your piece of code to link those symbols, you normally end up putting all of your script loading in something like a bootstrap system.

Import statements are bad, because they hardwire the symbols in your piece of code. Then if you need to change something, you actually need to get into the file and change it. In my opinion, “change by changing” is more prone to errors than “change by adding”. Also, “change by changing” does not scale as well as “change by adding”.

JavaScript and PHP code can also inspect its environment and adapt. So it’s possible to keep adding files that keep changing stuff depending on what has already changed or what is currently available for the script. This is pure gold in software development.

Think about WordPress plugins, you don’t need touch a single line of the core code, you just drop a new file and you can get a whole new experience out of your web site. Some plugins add features, other plugins only change behaviours. So, it either “add by adding” or “change by adding.” It’s a win-win situation, core code is hardly changed to add a feature, so you won’t get any bug from features you don’t care. For the features that you care, you get the plugins, drop them in and live with the bugs, if you happen to find a scary security bug, just disable the plugin.

I know a lot of people who criticize this way of developing and would prefer that WordPress be more object-oriented than it currently is. For what? Then we would need a plethora of new abstractions to achieve the same stuff. As code is a liability, the less code we need to achieve something, the better.

I love Haskell and its type system, it’s phenomenal. But it suffers from the same problem as other languages like Java and C# suffer. Modules are hard-wired with their dependencies and code can’t inspect its environment. I’m not saying that those languages are bad and should not be used. They surely has their own good use cases.

For a fast and distributed development effort as the web is, we simply can’t afford anything that is unforgiving or strict. The code needs to be open for changes from the outside (change by adding).

So, for the web, I don’t like new PHP code that uses modules and neither the usage of ES6. They may feel faster for developers starting out new products, but my bet is that in the long run they end up killing productivity and/or quality.

Think about it for the current project you are working on, how much could you change of it by only adding new files? What could you deliver by adding a new file: a whole new story, a feature, a bug fix or nothing?

All this permissive environment with all these code based on assumptions can turn into a real mess. That’s the reason those languages are hated by some developers, then those developers try to fix it by creating new stricter languages for the web, the end of the story is always the same: JavaScript/PHP triumphs over all. Why? Is it because of AIP?

JavaScript and PHP has some hidden properties that newcomers tend to ignore. Those hidden properties make them a perfect fit for the web. What do you think?

Am I just an old-school guy talking bullshit? Please, be kind. 🙂