Hi,
I don't think we need to be restrictive. We could have unnamed and only
one activated, or named and multiple activated.
What do you think of this?
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.
I am not sure if this will work, but....the @EmbeddedIdentityStore
annotation could dynamically create an EmbeddedIdentityStore
@Alternative bean? 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.
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.
Please see additional comments inline.
With regards,
Alex
On 10/11/15 7:35 PM, arjan tijms wrote:
> Hi,
>
> In order to select a specific identity store to be used in an
> application for a specific authentication mechanism, some kind of
> approach has to be thought of. Given that this approach should
> preferably be based on CDI, there are at least the following 2
> options:
>
> 1. Identity stores are named. Authentication mechanisms (e.g. FORM)
> are configured with such name and when they execute look up the
> identity store by this configured name. This is roughly equivalent to
> how some servers now use the<realm> element in web.xml.
[Alex] I think we should define the use of names as you state, for
reference from web.xml and name qualified injection points. 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.
> 2. Identity stores are always @Alternative. The alternative identity
> store to be used has to be selected in beans.xml. Authentication
> mechanisms (e.g. FORM) look up the one and only identity store
> implementation that's active for the application.
[Alex] I don't think all identity stores must be @Alternative. I think
at least the standard identity stores must be @Alternative, in case the
FORM does not specify a named identity store. Custom identity stores
could be @Alternative or @Named, depending on the preference of the
application developer.
> 3. Identity stores are NOT @Alternative. The standard identity stores
> are not added by the runtime (via a CDI extension) as beans by
> default, but only conditionally if a metadata annotation is present on
> a "random class" (e.g. just like @DataSourceDefinition works today).
> Applications can instead define one implementation directly.
> Authentication mechanisms again look up the one and only
> implementation.
[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. If the application wants to override use of the alternative,
the application could use additional qualifiers (including @Named) and a
corresponding producer. The "one and only implementation" alternative
would be selected if FORM did not have a named identity store specified.
If a named identity store was specified, then the named identity store
would be selected.
>
> Do note that:
>
> * The approach has to handle default identity store implementations
> shipped with Java EE as well as custom implementations provided by the
> user.
>
>
> Thoughts?
>
> Kind regards,
> Arjan Tijms