Team,
I'd like to start moving the current spring-ldap based classes over to
support ldaptive in the "feature-new-authn-api" branch. Before I progress
any further, I'd like to go over the task list and see if the plan is
agreeable. 

Planning to drop the following classes:

- BindLdapAuthenticationHandler.java
- DigestMd5DirContextAuthenticationStrategy.java
- FastBindLdapAuthenticationHandler.java
- RemoteIpLookupCredentialsToPrincipalResolver.java
- SpringLdapUtils.java
- CredentialsToLDAPAttributePrincipalResolver.java
- BindLdapAuthenticationHandlerTests.java
- BindTestConfig.java
- FastBindLdapAuthenticationHandlerTests.java
- CredentialsToLDAPAttributePrincipalResolverTests.java
- LdapUtilTests.java

These are mostly dropped in favor of the new ldaptive-based ldap
authentication handler. The ability to configure a custom principal
resolver is also removed in the handler, which is why I am proposing that
we drop the other ldap principal resolver implementations. 

Converting the following classes:

- LdapConnectionMonitor.java (Renamed)
- PoolingLdapConnectionMonitor.java (Renamed)
- PoolingLdapConnectionMonitorTests.java
- AbstractLdapPersonDirectoryCredentialsToPrincipalResolver.java 
- AbstractLdapUsernamePasswordAuthenticationHandler.java

Not sure about the following:

- LdapServiceRegistryDao.java

Is the changeset reasonable? Not too sure what we should do with
LdapServiceRegistryDao and whether it should be kept and converted. With
the availability of the in-memory, rdbms and JSON service registries, do
we really need to keep the ldap-based one as well? 

Feedback is much appreciated. 

Misagh


-- 
You are currently subscribed to [email protected] as: 
[email protected]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-dev

Reply via email to