Integrating LDAP with Coherence

Please read Securing a Coherence Cache as a precursor to this blog. The link talks about how to externalize the configuration of cache security provider that can be configured in coherence cache configuration. The security provider class that implements SecurityProvider interface has to implement a simple method checkAccess (Subject). Subject needs to be passed by the "cache client" and has to be authenticated/authorized in the security provider. Since I started Oracle coherence consulting it has come up time and again to integrate Coherence with an LDAP provider so that application/user accounts can be controlled on what access they can have to which cache with user accounts being managed in a Directory server. So lets think about it again and see if we can streamline this solution and something generic can be built.

Problem Statement: To setup Coherence cache in such a way that discrete cache access can be set up driven by Enterprise directory.

Lets, think about architectural decision points:

• LDAP Server is an external data source. Use CacheLoader.
• Avoid accessing LDAP for each Cache request. Cache user authentications (An admin cache).
• Protect the admin cache that manages the user-auth to not allow any access. Protect the protector.
• Protect the proxy from *Extend access. Cluster member has inherent trust. Use authorized-hosts for cluster members.
• Use JAAS
• Manage authorization locally but authentication centrally.

How about a quick activity diagram?

Authentication
User authentication has to happen only once (typically once in 24 hrs). This is not such a bad cost that can be incurred once in a day as user accounts do not change and if changes it changes very infrequently. Authentication information can be cached once an account is verified against a Directory server. We also need to make sure that the cache that manages account authentication information is inaccessible to any unauthorized user or applications. Now how to do it?

• Create an Admin cache.
• Plug a custom CacheLoader that interacts with an external Directory server.
• Build the cache key to include cache name and user credentials, the cache value be Boolean.TRUE or Boolean.FALSE.
• Using the <entitled> XmlElement configure a DisAllowSecurityProvider as it's security-provider.
• DisAllowSecurityProvider denies all requests to this cache other than made by a very "few chosen". Scroll down for its implementation.

So how would such an Admin cache configuration look like?
<distributed-scheme>
<scheme-name>admin-distributed-scheme</scheme-name>
<service-name>AdminDistributedService</service-name>
<backing-map-scheme>
<read-write-backing-map-scheme>
<internal-cache-scheme>
<local-scheme>
<high-units>200KB</high-units>
<unit-calculator>BINARY</unit-calculator>
<expiry-delay>86400000</expiry-delay>
</local-scheme>
</internal-cache-scheme>
<cachestore-scheme>
<class-scheme>
<class-name>LDAPCacheLoader</class-name>
<init-params>
<init-param>
<param-type>string</param-type>
<param-value>ldap.server.com</param-value>
</init-param>
<init-param>
<param-type>int</param-type>
<param-value>389</param-value>
</init-param>
</init-params>
</class-scheme>
</cachestore-scheme>
</read-write-backing-map-scheme>
</backing-map-scheme>
<autostart>true</autostart>
<entitled>
<security-provider>DisAllowSecurityProvider</security-provider>
</entitled></distributed-scheme>

So Admin cache is size limited and expires every 24 hrs of the first authentication and does not allow any access. How could that be? LDAPCacheLoader's load () method can be very simple. The cache key passed could be a "username$password" that can be parsed and authenticated against a Directory server using LDAP APIs. If authentication succeeds return a Boolean.TRUE otherwise false. So how is this load () invoked and from where?

Default Security Provider
Caching user authentication is a luxury that can be centralized. Applications deal with two aspects of cache security - Authentication and Authorization and these can be split in two classes. Combined with cached-authentication lets write an abstract Default security provider. Any security provider that extends it gets the "performance" for free.

public abstract class DefaultSecurityProvider implements SecurityProvider {
private NamedCache nCache = CacheFactory.getCache ("USER_CRED");
public boolean checkAccess (Subject subject) {
String user_pw = ((Principal) principals.iterator().next()).getName();
String userName = getUserName (user_pw);
Boolean isPresent = (Boolean) nCache.get (user_pw + "$$" + cacheName);
boolean isAuth = false;
if (isPresent.booleanValue()) {
isAuth = authorize (userName);
}
return isAuth;
}
public abstract boolean authorize(String userName);
}
Authorization
Like authentication authorization should be relatively inexpensive too. There could be two approaches. One, using Directory server to store authorization attributes too. Even though it is perfectly doable but authorization is owned by Coherence or application and should be "owned" by it. Central governance should only be applied to authentication and not to authorization. So lets find an inexpensive way... how about Java Permission object driven by a policy file? Lets write a Policy file:
grant Principal CustomPrincipal "Principal1" {
permission java.util.PropertyPermission "Cache1", "read, write";
.. More can be added here...
};
grant Principal CustomPrincipal "Principal2" {
permission java.util.PropertyPermission "Cache2", "read, write";
... More can be added here...
};

What about the custom security provider?

public class MyCustomSP extends DefaultSecurityProvider {

public MyCustomSP (String cacheName) {
super(cacheName);
this.cacheName = cacheName;
}

public boolean authorize(final String user) {
if (user == null) {
System.out.println("Auth not in USER_CRED cache");
return false;
}
try {
PropertyPermission fp =
new PropertyPermission(cacheName, "write");
new SecurityManager().checkPermission(fp);
return true;
} catch (SecurityException exp) {
...
}
return false;
}
}
Now in this implementation if a User Principal has "write" permission then it gets the access. But, out of NamedCache behaviors if each method can be classified into two - Either read or write then the method that was invoked can also be passed along with it's classification to checkAccess () method. Instead of hard-coded "write" for every access, NamedCache's each method can have a fine grained user authorization. Of course you reserve the right to create your own Permission object and a set of Actions and use that.

I am not done yet!
In the activity diagram there is a logical concept of Gatekeeper. Who is it? And how does it do it? This gatekeeper is a combination of a custom NamedCache (EntitledNamedCache) and a SecurityProvider called DisAllowSecurityProvider. EntitledNamedCache is auto-magically configured for caches that has &entitled> Element defined (Read Securing a Coherence Cache for more information). While, DisAllowSecurityProvider is configured on the Admin Cache (USER_CRED) that stores the authentication info.

What does DisAllowSecurityProvider do?
public class DisAllowSecurityProvider implements SecurityProvider {
public DisAllowSecurityProvider() {
}

public DisAllowSecurityProvider(String cacheName) {
}

public boolean checkAccess(Subject subject) {
StackTraceElement[] elements = new Throwable().getStackTrace();
StackTraceElement e3 = (StackTraceElement) elements[3];
StackTraceElement e0 = (StackTraceElement) elements[0];

try {
if (SecurityProvider.class.isAssignableFrom(Class.forName(e0.getClassName())) ||
SecurityProvider.class.isAssignableFrom(Class.forName(e3.getClassName()))) {
return true;
} else {
return false;
}
} catch (ClassNotFoundException f) {
Base.log (f);
return false;
}
}
}
So here you go, you get a decently flexible Coherence Cache security implementation. Enjoy!

**One of my colleagues Steve Brockman asked if it was possible to extend the security to other cluster nodes too besides the proxy nodes. The solution is a little different but easy to make. Following are the steps how to do it:

1. Copy coherence-cache-config.xml to say alt-cache-config.xml
2. Open alt-cache-config.xml in an editor and remove all the <entitled> section from the configuration.
3. Edit ExtendedCacheFactory and look for FILE_CFG_CACHE in the file. The next line is where the class sets the cache configuration name. Hardcode the param-value to alt-cache-config.xml (Or, be more creative but set it to alt-cache-config.xml).
4. Deploy the alt-cache-config.xml on all the cluster nodes.
5. Set -Dtangosol.coherence.override=proxy-override.xml on all cluster nodes.