> I have a problem extending the AbstractLdapRealm class for
> authentication. It's my understanding based on reading the javadoc
> that a default implementation of LdapContextFactory
> (DefaultLdapContextFactory) is being used if I don't change the
> default behavior.
Default behavior of what? (I'm a little confused). JSecurity does not
enable a default LDAP realm by default - it expects you to configure
realms explicitly. Is this related to the Grails plugin perhaps?
However, when implementing a subclass of
> AbstractLdapRealm for authentication (implementing the
> queryForAuthenticationInfo method) the LdapContextFactory being passed
> in is null. Checking the source, it seems as DefaultLdapContextFactory
> is set when afterAuthorizationCacheSet() is called.
I'm still not sure what you mean by 'DefaultLdapContextFactory is set"
- JSecurity does not do this automatically. Again, is this possibly a
Grails plugin related issue?
> Who is responsible for calling afterAuthorizationCacheSet()? Should
> the application using JSecurity do that? Or should my subclass do
> that?
This method is called automatically when a CacheManager is set on any
Realm that extends CachingRealm (AbstractLdapRealm is one of these).
Here is the setCacheManager implementation:
public void setCacheManager(CacheManager cacheManager) {
this.cacheManager = cacheManager;
afterCacheManagerSet();
}
afterCacheManagerSet() is overridden in the AuthorizingRealm subclass
(which is also a parent of AbstractLdapRealm) to automatically
initialize a cache for AuthorizationInfo instances to reduce
round-trip lookups for better performance.
the setCacheManager() method is called when a CacheManager is set on
the SecurityManager or when a realm is added to the SecurityManager.
That is, if you call defaultSecurityManager.setCacheManager(
cacheManager ), this cache manager instance will propagate down to all
CachingRealm instances that exist, which in turn calls
afterCacheManagerSet() on each one of them, allowing each to use the
injected CacheManager to initialize their own cache.
Similarly, If you have an already-initialized SecurityManager - that
is, the securityManager already has an internal CacheManager injected
and ready-to-go - and you then call securityManager.setRealm( aRealm)
or securityManager.setRealms( Collection<Realm> ), then the realms
will still be injected with the SecurityManager's CacheManager so they
can use it to create caches.
So, in summary, if you call securityManager.setCacheManager _or_
securityManager.setRealm(s), you can rest assured any CachingRealm
subclass instances will receive that CacheManager so they can
initialize a cache if they need to.
Does that help?
