Re: LDAP Annotation and Database Hashing Proposal

Guillermo González de Agüero

I see two options for the "one instance per identity store":
- Dynamically creating a qualifier for each instance. It is the more CDIish way and would make classes available for decoration, etc.
- Using the CDI Unmanaged class to make injection work on an arbitraty class. This is the way that most aligns with your "new Object()" proposal. Decoration and interception would work on those classes, and they would have no context (they'd be unmanaged for CDI) but that additional features might be provided as a vendor extension. A great article on the subject:

For this time, I think just saying that "injection should work" at spec level should be enough. Not sure what Arjan will think though. Soteria could definitely provide them as managed beans.

For deferred EL expressions, I too think they don't need to be mandated. I even doubt how that feature should work, as I'd expect two subsequent calls to generate and verify methods to use the same values, which could not be the case for deferred expressions.

Btw, I see in your PR that you finally used classes instead of names to specify the algorithm to use. Weren't you working on a String version?


Guillermo González de Agüero

El lun., 24 de julio de 2017 19:50, Will Hopkins <will.hopkins@...> escribió:
Not sure I care that much about the details of the implementation, although I'm starting to feel like CDI for this use case may be making things more complicated, not less, relative to simply newing up an instance of the type specified in the hashAlgorithm attribute and passing hashProperties to the constructor ...

What I think I'd like to see in terms of behavior is:
  • Hash algorithm and hash properties can be specified on the annotation.
  • Multiple instances of the annotation/idstore -- is that supported? -- could specify different hash algorithms, or, they could specify the same algorithm type, but different properties.
  • At runtime, each identity store instance gets its own instance of the hash algorithm type, even if other identity store instances are using the same hash algorithm.
  • The hash algorithm is initialized onced, up front, with the configured properties.
It's possible to make an argument for deferred evaluation of properties, etc., but that complicates things considerably and I think doing only the above provides plenty of flexibility. An implementation of HashAlgorithm could certainly do its own deferred evaluation internally.

My $0.02 (or maybe $2.00).


On 07/24/2017 08:41 AM, Arjan Tijms wrote:

On Mon, Jul 24, 2017 at 2:21 PM, Will Hopkins <will.hopkins@...> wrote:
>The one in the annotation is basically the base version of that. The
>producer could be dependent scoped indeed.

Not sure I follow what you mean.

Sorry, I meant the data that directly comes from the annotation instance and is converted into a Map here:

(ps, that's also an example showing the static import of unmodifiableMap)

I think the value of having it dependent scoped is that there could be more than one instance, each configured with different parameters. For any given instance, the parameters would never change, but if you had multiple identity stores, each one could have an instance of the algorithm that was configured differently, even if they all used the same algorithm. If it was application scoped, then every identity store in the app that wanted to use the same algorithm would have to use the same instance, and therefore the same parameters.

For the injection it would need an extra qualifier to get the right version of the parameters, which is indeed one of the extra complications. Since qualifier annotation attribute values can be binding, these qualifiers can be created more or less dynamically. I think it should be doable, but it's not super trivial.

Kind regards,
Arjan Tijms

Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803

Join to automatically receive all group messages.