Package io.confluent.security.auth.provider.ldap

Class LdapGroupManager

java.lang.Object

io.confluent.security.auth.provider.ldap.LdapGroupManager

public class LdapGroupManager
extends Object

Constructor Summary

Constructors

Constructor	Description
LdapGroupManager(LdapConfig config, org.apache.kafka.common.utils.Time time)
LdapGroupManager(LdapConfig config, org.apache.kafka.common.utils.Time time, ExternalStoreListener<io.confluent.security.auth.store.data.UserKey,io.confluent.security.auth.store.data.UserValue> listener)

Method Summary

Modifier and Type	Method	Description
void	close()
boolean	failed()
Set<String>	groups(String userPrincipal)
void	start()	Starts the LDAP group manager and schedules either periodic or persistent search.

Methods inherited from class java.lang.Object

equals, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Details

LdapGroupManager

public LdapGroupManager(LdapConfig config,
 org.apache.kafka.common.utils.Time time)

LdapGroupManager

public LdapGroupManager(LdapConfig config,
 org.apache.kafka.common.utils.Time time,
 ExternalStoreListener<io.confluent.security.auth.store.data.UserKey,io.confluent.security.auth.store.data.UserValue> listener)

Method Details

start

public void start()

Starts the LDAP group manager and schedules either periodic or persistent search. In both cases an initial non-persistent search is performed to initialize the cache to ensure that the cache is populated before returning from `start()`.

For periodic search, a new search is scheduled every refresh interval to refresh the cache from LDAP.

Even when persistent search is enabled, a non-persistent search is used for initialization because we cannot detect when all the existing entries have been processed by a persistent search since `enumeration.next()` just blocks waiting for changes. Persistent search is performed using changesOnly=false. So all entries are read a second time when the persistent search is initiated. This is to avoid the timing window if entries are updated in between the first non-persistent search and the persistent search request. If the overhead of a second read during `start()` turns out to be an issue, we will need to initiate the async persistent search with `changesOnly=true` on the scheduler thread and invoke the synchrononous non-persistent search on the thread invoking `start()` after that. Note that we would need to make processing of search results thread-safe. We would also need to re-populate the cache using non-persistent search on connection failures in the same way.

close

public void close()

groups

public Set<String> groups(String userPrincipal)

failed

public boolean failed()