Hi,
On Tue, Oct 13, 2015 at 7:55 PM, Alex Kosowski <alex.kosowski_at_oracle.com> wrote:
> I don't think we need to be restrictive. We could have unnamed and only one
> activated, or named and multiple activated.
Agreed, sounds good.
> 1. All standard identity store implementations would be application scoped,
> @Alternative, and unnamed. This would enable beans.xml to select the
> identity store. We would have to define some deployment-descriptor-based
> configuration (e.g. connection parameters) for the selected alternative.
So this is basically a variant on item 2 of the initial list, but only
the standard ones are @Alternative, right? This is something that
could work indeed.
One issue with both item 1 and 2 from that list (and therefor also
this variant) is that the user has to perform 2 actions to use a
standard identity store:
1. Activate alternative in beans.xml
2. Define configuration in (say) web.xml
> I am not sure if this will work, but....the @EmbeddedIdentityStore
> annotation could dynamically create an EmbeddedIdentityStore @Alternative
> bean?
Effectively yes. Technically a CDI extension would scan for the
presence of an @EmbeddedIdentityStore annotated class and then use the
programmatic API to dynamically create a bean. As mentioned in an
other msg to the list, the programmatic API needs to be used anyway
for an "application server"-side jar.
The dynamically created bean would not necessarily have to be
@Alternative. If it would not be @Alternative then
@EmbeddedIdentityStore would cause the creation, configuration and
activation of an identity store at one single place.
Also, it's not just @EmbeddedIdentityStore that can cause an identity
store bean to be created. The concept would work the same for all
other standard identity stores. E.g.
@LdapIdentityStore(
url="ldap://localhost:10389",
searchDn="uid=jsr375,dc=simple,dc=jsr375,dc=org"
searchCredential="secret"
)
public class SomeClass{}
@DataBaseIdentityStore(
dataSourceLookup="java:/app/myDS",
callerQuery="select password from caller where name = ?",
groupsQuery="select group from caller_groups where caller_name = ?",
hashAlgorithm="SHA-256",
hashEncoding="base64"
)
public class SomeClass{}
etc
> If selected via beans.xml, we would then have a populated development
> identity store ready for use with no further configuration beyond selecting
> an alternative.
As for the alternative selection, as stated above that would not be
strictly needed. Nevertheless, a boolean "alternative" attribute could
be an option for the @[...]IdentityStore annotations.
> 2. If an application wanted to use more than one identity store
> implementation, or override the alternative, the application could use
> additional qualifiers (including @Named) at the injection point and create a
> corresponding qualified producer method or qualified bean.
This by itself sounds good, but the additional qualifier beyond the
standard @Named may be problematic. How is the authentication
mechanism going to learn about the additional (application specific)
qualifier?
> It does not seem we should
> require every identity store to be named, since the typical case would seem
> to be one identity store (or alternative) per application. If FORM specifies
> a named identity store, then the @Named qualified identity store must be
> used. If no identity store name is specified by FORM, then any selected
> alternative identity store would satisfy the lookup.
This sounds like a good approach.
The most important thing is of course that it's clear for an
authentication mechanism implementor how to lookup our standard
identity store, and for users to specify which one that should be for
their applications.
> [Alex] I think this will be confusing, since we would be bypassing CDI to
> effectively create our own @Alternative mechanism based in the meta
> annotation.
I understand what you mean, so this may need some more discussion.
The idea though is of course not to bypass CDI, but to have a place
for configuration. The meta data annotation is not solely intended as
an alternative selection, but as a primary place to store this
configuration. A deployment descriptor could be an alternative (no pun
:P) place for this (but CDI extensions have some problems reading
these).
As indicated above, when such configuration would be present, CDI
would see that, and then based on that make a bean available. I agree
that it does have some of the feel of an alternative mechanism so we
should carefully consider this.
However as mentioned above, if these conditionally dynamically
generated beans are optionally set to @Alternative, then the actual
selection of the bean is still left to do via beans.xml. In that case
it's more clear that it's not necessarily our own mechanism for
@Alternative, but a way to make a configured instance of a certain
identity store implementation available.
Kind regards,
Arjan Tijms