Java 8 has a new date API.
Deprecate calendar in favor of the new API.

The AuthenticationResponse does not include the DN that was resolved for authentication.
This DN may or may not be the same as the DN returned on the LdapEntry.

Update the AuthenticationResponse to include the resolved DN.

Is it possible to use Transactions aka LDAPTXN?

Regards, Tomaz

Currently, when requesting Kerberos ticket to the LDAP service, the JAAS login module (such as LdapDnAuthorizationModule) builds SPN by prepending "ldap/" to hostname specified in the ldapUrl. So if in the login module parameters appears:
ldapUrl="ldap://dc1.mydomain.local:389"
then the SPN will be "ldap/dc1.mydomain.local".

This actually forces me to list specific DC or DCs in the ldapUrl, which, of course, isn't very flexible and can lead to problems, if these DCs are decomissioned and replaced by new ones.

In Active Directory, such discovery problems are solved by so-called SRV records in DNS. For example, SRV record
_ldap._tcp.mydomain.local
contains regular A (host) records for all DCs of mydomain.local. Other examples may include:

_ldap._tcp.London._sites.mydomain.local
means "all DCs in the London site",

_gc._tcp.mydomain.local
means "all Global Catalogs in the domain",
and so on.

It would be great, if ldaptive login modules could make use of this mechanism.
For instance, if they could to do this:

• Get the URL in the format like ldapUrl="ldap://_gc._tcp.mydomain.local:3268,SRV" or something similar,
• Understand that it's SRV record, not a hostname,
• Resolve the record to specific hostname or hostnames (such as dc1.mydomain.local),
• Pick up one of these hostnames, build an SPN out of it and then get a service ticket for this SPN, as usual.

Thanks!
Cat Mucius.

Both the BindAuthenticationHandler and the PooledBindAuthenticationHandler will propagate an exception if the result code is not 49.
Since many password policy implementations use various other result codes, update that logic to only throw if a result code is not available in the exception.

According to guide:

http://www.ldaptive.org/docs/guide/operations/search

it should be possible to change default sort behavior with JVM switch:

-Dorg.ldaptive.sortBehavior=org.ldaptive.SortBehavior.ORDERED

This, however, will cause following error:

ERROR [org.ldaptive.SortBehavior] - <Error instantiating org.ldaptive.SortBehavior.ORDERED> java.lang.ClassNotFoundException: org.ldaptive.SortBehavior.ORDERED

Found on version: ldaptive-1.0.3, master

Code: https://github.com/vt-middleware/ldaptive/blob/master/core/src/main/java/org/ldaptive/SortBehavior.java#L41

Adding ldap entries that do not explicitly set/add the objectclass "top" causes warnings/errors. Discussed the issue with @dfish3r on this thread https://groups.google.com/forum/#!topic/ldaptive/nU67qJFfRkY

The use case for this functionality was testing of the DefaultHostnameVerifier.
It is not used by any of the project internals and it does not work for #createSocket() since the socket is not yet opened when getSession() is invoked.
Since the behavior of SSLSocket#getPeerHost has become unreliable in the most recent Java update. [1], remove this functionality.

[1] http://shibboleth.1660669.n2.nabble.com/Shib-IdP-Metadata-Download-and-Java-1-7-0-85-td7617478.html

Java 8 does support JSON natively. (I thought it did...)
And it appears neither will Java 9:
https://jaxenter.com/json-api-dropped-java-9-113028.html

There has been an explosion of JSON libraries, evaluate the popular candidates.

version: 1.1.0-SNAPSHOT

Snippets of code:

final static String[] OBJECT_CLASSES = {"top","person","inetOrgPerson","organizationalPerson","posixAccount","shadowAccount","eduPerson","schacContactLocation","schacEmployeeInfo","schacEntryConfidentiality","schacEntryMetadata","schacLinkageIdentifiers","schacLinkageIdentifiers","schacPersonalCharacteristics","schacUserEntitlements"};
....
generator.setPackageName("morez.schema.beans");
generator.setUseOperationalAttributes(true);
generator.setUseOptionalAttributes(true);
generator.setIncludeSuperiorClasses(true);
generator.write("target/generated-test-sources/ldaptive");

Exception:

java.lang.IllegalArgumentException: Class already exists: morez.schema.beans.SchacLinkageIdentifiers
at org.ldaptive.beans.generate.BeanGenerator.createClass(BeanGenerator.java:544)
at org.ldaptive.beans.generate.BeanGenerator.generate(BeanGenerator.java:369)
at ldap.ldaptive.LdaptiveBeanGenerator.main(LdaptiveBeanGenerator.java:60)
Caused by: com.sun.codemodel.JClassAlreadyExistsException

Explanation:

But there is no folder generated-test-sources so there is no class SchacLinkageIdentifiers

Regards, Tomaz

The EDirectoryAuthenticationResponseHandler will report an account state warning if passwordExpirationTime is set.
It is a common practice to always have this attribute set, but deployer may want to restrict when users begin to receive notifications that the expiration time is nearing.

The connection pool emits errors for each connection that fails on #initialize.
Given the nature of pools, it may be incorrect to consider that an error.

Review current log levels and adjust accordingly.

I have user in LDAP(389 Directory Server) whith attribute nsAccountLock, but when I perform find with manager I get all attributes except nsAccountLock from LDAP.

Bean:

@Attribute(name = "nsAccountLock", property = "lock")

If I use SearchRequest without naming attributes I don't get nsAccountLock attribute, but if I explicitly define in search result then I get it.

But in find dosen't get it, what I'm doing wrong?

Regards, Tomaz

Develop a prune strategy that leverages statistical data to measure latency in the pool and then prunes connections based on that strategy.

JndiConnection#readReferralUrls uses the wrong exception to iterate over referral info.

DefaultLdapEntryManager#find leverages LdapEntryMapper#map() but the parameters to that method are reversed.

In order to simplify the bean configuration, I think it'd be best if ldaptive started to define its own DSL. With a custom schema and perhaps via Spring namespace handlers, all the extra baggage that deals with bean declarations and setting props here and there can be perfectly replaced with syntactic sugar to help adopters and devs better understand what's going on under the hood.

Ref: http://docs.spring.io/spring/docs/current/spring-framework-reference/html/extensible-xml.html

As an example:

<bean id="authenticator" class="org.ldaptive.auth.Authenticator"
      c:resolver-ref="dnResolver"
      c:handler-ref="authHandler"
      p:entryResolver-ref="entryResolver">
      <property name="authenticationResponseHandlers">
          <list>
              <bean class="org.ldaptive.auth.ext.ActiveDirectoryAuthenticationResponseHandler" />
          </list>
      </property>
</bean>

<!-- Active Directory UPN format. -->
<bean id="dnResolver"
      class="org.ldaptive.auth.FormatDnResolver"
      c:format="%s@${ldap.domain}" />

Turns into:

<ldaptive:authenticator dnResolver="dnResolver" authHandler="xyz" entryResolvers="list" />
<ldaptive:dnResolver id="dnResolver" format-dn="%s@${ldap.domain}" />

...and so on and so forth.

Essentially, all the code samples that are defined here would be candidates for the custom schema, and whatever else that exists:
http://jasig.github.io/cas/development/installation/LDAP-Authentication.html#active-directory-authentication

By default the JNDI provider will inject a ThreadLocalTLSSocketFactory in order to perform hostname verification for LDAPS connections.
This functionality works in scenarios where a connection is created for every operation.
(i.e. JAAS)

However when using a pool of connections this will cause problems if any connection needs to reopen.
The thread local data will be gone and the connection will fail.

Shouldn't errors such as below be outputted at ERROR level, rather than DEBUG?

2014-11-18 00:52:10,935 DEBUG [org.ldaptive.provider.jndi.JndiConnectionFactory] - Error connecting to LDAP URL: ldaps://216.123.204.176:636
[org.ldaptive.provider.ConnectionException@656538726::resultCode=PROTOCOL_ERROR, matchedDn=null, responseControls=null, referralURLs=null, messageId=-1, providerException=javax.naming.CommunicationException: 216.123.204.176:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]]
    at org.ldaptive.provider.jndi.JndiConnectionFactory.createInternal(JndiConnectionFactory.java:86)
    at org.ldaptive.provider.jndi.JndiConnectionFactory.createInternal(JndiConnectionFactory.java:31)
    at org.ldaptive.provider.AbstractProviderConnectionFactory.create(AbstractProviderConnectionFactory.java:118)
    at org.ldaptive.DefaultConnectionFactory$DefaultConnection.open(DefaultConnectionFactory.java:295)
    at org.ldaptive.pool.AbstractConnectionPool.createConnection(AbstractConnectionPool.java:432)

The authorization identity control can be sent with a bind request to communicate the identity of the principal back to the user.
This identity could then be used for entry resolution.
See RFC 3829.

I'm working on glassfish application and when I'm trying to add attribute mobile I'm getting:

exception=[org.ldaptive.LdapException@1173492716::resultCode=ATTRIBUTE_OR_V
ALUE_EXISTS, matchedDn=null, responseControls=null, referralURLs=null, messageId=-1, providerException=javax.naming.directory.AttributeInUseException: [LDAP: error code 20 - Attribute Or Value Exists]
; remaining name 'eduPersonPrincipalName=[email protected],dc=guest,dc=arnes,dc=si']

but if I use the same code in command line it works fine, is there any issue with using same conection on glassfish application server.

I can not find issue.

Regards, Tomaz

RFC4512 requires that DESC contain at least 1 character, but many directories support empty descriptions.

Update schema parsing to allow empty DESC.

It would be helpful to add support for searching for attributes from arbitrary directory entries as part of the authentication pipeline. For example, these entries might contain configuration data to support the authentication process such as password policy/expiration configuration settings. Ideally there would be support for querying for this data on every authentication attempt as well as querying on creation/init and caching for the lifetime of the component.

Hi, how about a feature request for ldaptive to support Durations ?

"blockWaitTime in IdPv3 ldap.properties"
http://shibboleth.net/pipermail/users/2015-November/025164.html

"Incorrect idp.pool.LDAP.validatePeriod property format"
http://shibboleth.net/pipermail/users/2015-November/025528.html

ldaptive-beans:version = 1.0.6

Exception:
Exception in thread "main" java.lang.IllegalArgumentException: Could not transcode object class
at org.ldaptive.schema.io.ObjectClassValueTranscoder.decodeStringValue(ObjectClassValueTranscoder.java:37)
at org.ldaptive.schema.io.ObjectClassValueTranscoder.decodeStringValue(ObjectClassValueTranscoder.java:25)
at org.ldaptive.LdapAttribute.getValues(LdapAttribute.java:283)
at org.ldaptive.schema.SchemaFactory.createSchema(SchemaFactory.java:219)
at org.ldaptive.schema.SchemaFactory.createSchema(SchemaFactory.java:120)
at test.LdaptiveBeanGenerator.main(LdaptiveBeanGenerator.java:49)
Caused by: java.text.ParseException: Invalid object class definition: ( 2.16.840.1.113730.3.2.3 NAME 'mailRecipient' DESC '' SUP top AUXILIARY MAY ( cn $ mail $ mailAlternateAddress $ mailHost $ mailRoutingAddress $ mailAccessDomain $ mailAutoReplyMode $ mailAutoReplyText $ mailDeliveryOption $ mailForwardingAddress $ mailMessageStore $ mailProgramDeliveryInfo $ mailQuota $ multiLineDescription $ uid $ userPassword ) X-ORIGIN 'Netscape Messaging Server 4.x' )

The ObjectClass is part of https://github.com/leto/389-ds/blob/master/ldap/schema/50ns-mail.ldif

Regards, Tomaz

The AggregateDnResolver has an inner class which provides an AuthenticationHandler to be used with the resolver.
This inner class duplicates the AuthenticationHandler name and does not use the correct org.ldaptive.auth.AuthenticationHandler class where appropriate.

Add support for the subordinate search scope.
See http://tools.ietf.org/html/draft-sermersheim-ldap-subordinate-scope-02

I have the following configuration:

<bean id="ldapCertFetcher"
          class="org.jasig.cas.adaptors.x509.authentication.handler.support.ldap.LdaptiveResourceCRLFetcher"
          c:connectionConfig-ref="provisioningConnectionConfig"
          c:searchExecutor-ref="searchExecutor"  />

    <bean id="poolingLdapCertFetcher"
          class="org.jasig.cas.adaptors.x509.authentication.handler.support.ldap.PoolingLdaptiveResourceCRLFetcher"
          c:connectionConfig-ref="provisioningConnectionConfig"
          c:searchExecutor-ref="searchExecutor"
          c:connectionPool-ref="connectionPool"/>

Could there be a way for me to configure connection config and connection pools separately via ldaptive namespaces?

JndiConnection#formatDn concatenates the relative DN with the search base DN.
This code can be simplified by leveraging SearchResult#getNameInNamespace.

Providers do not leverage existing connection configuration when following referrals.
This can lead to security issues when following referrals as credentials may be replayed over an insecure connection.
In particular, JNDI will follow referrals without issuing a startTLS operation on referral connections.

When is plan to release version 1.1.0 ?

Regards, Tomaž

I'm creating a DefaultConnectionFactory, using a ConnectionConfig instance to whose setLdapUrl method I pass a URL string obtained from a eureka service registry lookup. The string ends with a slash, e.g.:

ldaps://123.45.67.890:636/

This results at connection time in a NumberFormatException in the LdapURL constructor.

Caused by: java.lang.NumberFormatException: For input string: "636/"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:580)
at java.lang.Integer.parseInt(Integer.java:615)
at org.ldaptive.LdapURL.(LdapURL.java:78)
at org.ldaptive.LdapURL.(LdapURL.java:51)
at org.ldaptive.provider.jndi.JndiProvider.getJndiConnectionFactory(JndiProvider.java:199)
at org.ldaptive.provider.jndi.JndiProvider.getConnectionFactory(JndiProvider.java:108)
at org.ldaptive.DefaultConnectionFactory.getConnection(DefaultConnectionFactory.java:142)

In the UnboundIDProvider.getConnectionFactory(final ConnectionConfig cc) there is the following code:

if (cc.getSslConfig() != null &&
    cc.getSslConfig().getEnabledCipherSuites() != null) {
  throw new UnsupportedOperationException(
    "UnboundID provider does not support the cipher suites property");
}
if (cc.getSslConfig() != null &&
    cc.getSslConfig().getEnabledProtocols() != null) {
  throw new UnsupportedOperationException(
    "UnboundID provider does not support the protocols property");
}

Which is not true. UnboundID (at least in version 2.3.8) fully supports EnabledCipherSuites and Protocols (and with some effort random number generators as well).

The Connection interface should extend AutoCloseable to facilitate the following pattern:

try (Connection conn = connectionFactory.getInstance()) {
    // do something with connection
}

I have the following:

final Map<String, List<Object>> attributeMap = new LinkedHashMap<>(entry.size());
for (final LdapAttribute attr : entry.getAttributes()) {
        attributeMap.put(attr.getName(), new ArrayList<Object>(attr.getStringValues()));
}
logger.debug("Converted ldap DN entry [{}] to attribute map {}", entry.getDn(), attributeMap.toString());
return attributeMap;

In the logs I see:

Converted ldap DN entry [uid=1121133,ou=People,dc=somewhere,dc=edu] to attribute map {uid=[1121133], givenname=[John], displayname=[Bonjovi]}

Why is "givenName` or "displayName" turned into "givenname" or"displayname" ?!

The webapp component leverage jquery to render JSON from an LDAP.
HTML is built and then passed to the .html( ... ) function.
Add javascript escape function and pass attribute values through it before rendering.

http://www.ldaptive.org/docs/guide/providers

The comparison graphs are locked down and not accessible. I'm seeing the iframes where they should be, but the contents are all saying I don't have permission to view the document.

Add an LdapEntryHandler that aggregates an attribute with all it's subtypes using the ;lang- option.

cn: Daniel Fisher
cn;lang-ru: Даниэль Фишер

would result in

cn: Daniel Fisher
cn: Даниэль Фишер

with the lang attached to the ldap attribute value at metadata.

See:
http://www.ietf.org/rfc/rfc2596.txt
http://www.openldap.org/lists/openldap-devel/199904/msg00038.html
http://www.ietf.org/rfc/rfc2251.txt section 4.1.5

For objects that expose a byte[] property, the SpelAttributeValueMutator converts that into a Collection<byte[]> where the collection contains an entry for each byte in the array.
The collection should contain a single entry.

It is possible to receive an error on a successful bind.
Specifically when "Password expired with grace logins remaining".
Change the logic to prefer errors over warnings.

By default, the provider implementations try to determine whether an attribute is binary.
Typically this is done by inspecting the first value to see if it needs to be base64 encoded per the LDIF spec.
This can create an asymmetry when a string value is persisted that is not LDIF safe, because when it is retrieved it will be returned as a binary attribute.

If this functionality is removed, the opposite problem could occur.
A binary attribute persisted and retrieved will have to be requested as a binary attribute in order to be returned as binary.
While not elegant, at least there is symmetry in terms of what the user must declare as binary.

Java 8 provides a Base64 implementation.

Add support for the matched values request control.
See rfc 3876.

The LdapEntryManager requires an LdapEntryMapper that operates on the same type.
However, both the Default and Spring implementations do not declare a type.

This implementation supports an ignoreFilter regex but more flexibility is needed to restrict queries.
The minimumQueryTermLength property will require that at least one query term is >= a certain length.

Authentication could be enhanced by supporting an arbitrary context that could inform both DN resolution and binding.

The specific use case for this feature is supporting velocity templates for creating the search filter in DN resolution.

Active Directory schema includes an attribute called primaryGroupID which references the entry of the user's primary group.
Add an entry handler which dereferences the primary group data and includes it in the user's entry.

See http://support2.microsoft.com/kb/297951

handle will set the account state warning if both a warning and an error are provided.

Change the logic to prefer errors over warnings.

Title says all.