- LDAP Annotation and Database Hashing Proposal
Re: LDAP Annotation and Database Hashing Proposal
toggle quoted messageShow quoted text
Yes, why not. And indeed parameters are probably only dependent on the deployment and not on each request (the multi-tenancy use case you described)
I don't think that we have to define that it goes through the constructor or init method. We have only to specify that the parameters (defined at the databaseIdentityStoreDefinition) MUST be used by the methods generateHash() and verifyHash() if these parameters contain appropriate values for the hash algorithm in question.
The most important parameter is if the hashed byte array is stored as base64 or Hex encoded. This is very important.
I see that the current implementation of Pbkdf2PasswordHashImpl is always using base64.
On 24 July 2017 at 10:56, Will Hopkins <will.hopkins@...>
Well, let me ask this -- can we specify that the properties are
passed to a constructor or init method somehow? (i.e., not to each
One of my concerns is that we don't have control over the parameters
when generateHash() is called, so unless the properies are passed to
constructor or init, the generate() and verify() methods will have
different behavior. That would provide slightly less flexibility,
but the only case I can think of where it would really matter is
multi-tenancy, which we aren't really claiming to support, and even
then I suspect it would be rare.
On 07/24/2017 04:37 AM, Rudy De
- Implementations can provide
their own configuration mechanisms -- a standard config
object that's injected, decorators, annotations of their
own, abstract impls that developers extend to customize
and deploy, etc. Those won't be standard, but neither
would properties, because the actual property names and
values would be specific to the implementation in use.
And that is what I want to
avoid, that each vendor uses his own way of configuration.
The database access and
hashing algorithms are then may be standardized, but when
each vendor uses his own way of configuration, we are back
to square one. No compatibility between the different
servers8 So what is the point then of our effort?
Property names won't be
standardized, I agree. But we have the same situation for
JPA. There you have also properties (the hibernate.xxxx and
But at least you need to
specify them in the persistence.xml file and not within
other areas (like environment variables, server xml files,
JNDI, ... ) for each server differently.
Join email@example.com to automatically receive all group messages.