Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] ldappc-ng comparing provisioned identifiers ?

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] ldappc-ng comparing provisioned identifiers ?

Chronological Thread 
  • From: Tom Zeller <>
  • To: Tom Barton <>
  • Cc: Grouper Dev <>
  • Subject: Re: [grouper-dev] ldappc-ng comparing provisioned identifiers ?
  • Date: Tue, 23 Feb 2010 08:34:33 -0600
  • Domainkey-signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=Mc/SlBi8AqAkhSPPf0uhOGrR2wKt3tBKGWtTc+F2VssdXm9BteF4FqRdJ1Ai4cUtI+ j3US+Jpz/iCpWi546NFftHf4g8g52xj6gyPZ8JRHMYIUC2Yi0ZJq+fTVA949S7oLKxvs xitsE/Z6Mm8FTYi6jNmXp5o7/g8IFHfy0CpbU=

Perhaps my question should have been : how should we expose the need
to canonicalize identifiers to potential writers of custom connectors

I was hardcoding the spml-to-ldap connector, ala the original ldappc,
and thought better of it. Requiring compliance with a java interface
class would require java, which might not always be used. For example,
someone might write an spml-to-powershell connector.

I hadn't thought of re-using the attribute resolver, which seems like
a good idea, along with a supplied ldap canonicalizer as a working
example. This way, since jndi has limitations, folks can choose their
own (we'll probably use


On Sun, Feb 21, 2010 at 7:05 PM, Tom Barton
> Tom,
> LDAP DNs are a special kind of identifier for which you'll want to rely on
> an existing canonicalization algorithm. You're in the best position to judge
> whether ldappc-ng should rely on a JNDI method to do so or where exactly
> that should be done in the LDAP provisioning work flow overall.
> Does the shib attribute resolver provide reasonable capabilities to a
> deployer to massage locally-defined identifiers as may be needed in
> connection with ldappc-ng?
> Other Tom
> Tom Zeller wrote:
>> I'm looking for feedback regarding two styles of comparing provisioned
>> identifiers, what I'll call "exact-match" and "pluggable".
>> By exact-match I mean comparing identifiers as case-sensitive strings,
>> e.g. idA.equals(idB).
>> By pluggable I mean that identifiers might be massaged before
>> comparison, for example, making them case-insensitive
>> idA.toLowerCase.equals(idB.toLowerCase()).
>> For ldap DNs, a pluggable comparison might involve case-insensitivity,
>> escaping, and normalizing whitespace.
>> If ldappc-ng compares ldap DNs as exact-matches, then the (software)
>> connector to an ldap server would need to always normalize DNs upon
>> receiving requests and sending responses.
>> If ldappc-ng compares ldap DNs pluggably, then the (software)
>> connector to an ldap server could return whatever DN it receives from
>> the ldap server, and it would be up to ldappc-ng to normalize.
>> I'm leaning towards exact-match, which leaves the details of
>> identifier normalization to the connector. In other words, the
>> connector code contains all of the target specific details.
>> Feedback ? Does this make sense ?
>> Thanks,
>> TomZ

Archive powered by MHonArc 2.6.16.

Top of Page