directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <>
Subject Re: PasswordHashingInterceptor
Date Fri, 24 Jul 2015 13:50:55 GMT
On Fri, Jul 24, 2015 at 3:31 AM, Theisen, Lucas <> wrote:

>  I have need to hash more than just the userPassword attribute (I store
> the answers to security questions as well), and figured other people may
> need the same feature.  I would add it to the source branch, but my
> solution was to hard code the list of hashed OID’s in classes similar those
> in the interceptors-hash module.  In order to make it generic enough to add
> to the project, I would need a better way to feed in the list of OID’s
> (rather than compile).  I know that binary attributes are set on the client
> via, but
> since this would be server side, that approach would not work.  All server
> config seems to be ldif oriented, but this would require a custom attribute
> for this new option, perhaps something like:
> ads-interceptorconfig: any-config-string-here
> Or an even more generic:
> ads-customconfig: any-config-string-here
>  That would be allowed in any config (not just interceptors).  I could do
> it without the additional attribute using system properties, but that seems
> wonky…
> Anyway, my questions are:
> Is anybody else interested in this feature?
sounds like a reasonable addition

>  Do we have a common approach to adding new configuration attributes?
not really, but the general common sense prevails, like 'ads-' prefix in
the name

>  Is this a valid case for new attributes?
> Any other suggestions?
what I would do is to add support for configuring one or more attributes in
this interceptor
something like, 'ads-hashAttibute' a multi valued attributes

>  And if I do this, should we change the base class from
> PasswordHashingInterceptor to HashingInterceptor?
how about creating HashingInterceptor by extracting common functionality
out of
PasswordHashingIntereceptor and make later a subclass of former?

>  If we change the base class name, any idea what other
> classes/config/anything would be impacted?
Let us avoid renaming the classes, this makes migration much easier.
Except for a small change to the migration code to add the new schema
attributes to already
extracted schema, I do not see any issues.

> Thank You,
> Lucas Theisen

Kiran Ayyagari

View raw message