Axiomatics Featured in KuppingerCole Market Compass for Policy-Based Access Management (PBAM) Learn more  

Why Does Retrieving Attribute Values from a Secure LDAP Slow Performance?

This week’s question gets into a very specific XACML implementation detail but it is one that I encounter often so I thought this might be a good place to raise awareness. You are probably already aware that one of the key features of an Attribute Based Access Control system (ABAC) is the ability to use many attributes to make fine-grained authorization decisions.  The XACML reference architecture makes getting these attributes easier by defining Policy Information Points (PIP’s) but what happens when the underlying datasource requires a secure LDAP connection? 

Myself and a few of our customers have learned the hard way that an out of the box Java Virtual Machine does not implement connection pooling for secure LDAP by default.  This means that a java based XACML system will need to authenticate to the underlying secure LDAP attribute source each and every time it needs to retrieve an attribute value. The overhead of this authentication will cause the overall performance of the XACML system to suffer. The good news here is that connection pooling for non-secure LDAP is enabled by default and it can be enabled for secure LDAP connections.  To do that simply add the following java system property:

com.sun.jndi.ldap.connect.pool.protocol=plain ssl

More details on all available settings can be found here:

In the above example both secure and nonsecure connections will be pooled.


When implementing an ABAC system with XACML it is important to understand all of the details of how the underlying system works.  In this case we understood how XACML uses PIP’s to retrieve attribute values but not how the underlying Java Virtual Machine implemented those connections.  

Archived under:
About the author