Arjan,
I agree when you say that we should try to use CDI to select the
IdentityStrore.
But you need a Qualifier for this, and since the UsernamePasswordCredentials
for example is a concrete class, it is not usable as qualifier (=
annotation)
How are we going to link certain implementation classes with a Qualifier?
Or am I missing something?
*How I see this working using CDI:*
What we can do is to create an annotation (say @IdentityStoreVariant, not a
very good name) which has a value parameter which takes the class which
will have the credentials, like this
*_at_Inject*
*_at_IdentityStoreVariant(UsernamePasswordCredentials.class)*
*private IdentityStore identityStore;*
Now the CDI producer can look at the InjectionPoint info and find the
annotation and the requested Credentials class. And select the correct
identityStore out of all CDI beans implementing this interface.
(See this from the Weld documentation for those not familiar with Producers
and InjectionPoint,
https://docs.jboss.org/weld/reference/latest/en-US/html/injection.html#_the_literal_injectionpoint_literal_object
)
The IdentityStore interface (abstract class) must have a method which
returns the supported (or list of) Credentials classes. And we can select a
suitable one based on this info as explained above.
regards
Rudy
On 19 June 2015 at 16:04, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi,
>
> On Fri, Jun 19, 2015 at 2:42 PM, Alex Kosowski <alex.kosowski_at_oracle.com>
> wrote:
>
>> Hi Arjan,
>>
>> Thank you for being so active with this JSR!
>>
>
> No problem ;)
>
>
>
>> Is a credential handler really needed if CDI can already do the selection?
>>
>> Here a generic IdententityStore is injected, which in CDI terms
>> may look a bit unusual. Using a CDI qualifier you could inject the correct
>> type right away.
>>
>> Eg
>>
>> @Inject @UsernamePassword
>> IdentityStore identityStore
>>
>> Or if it's needed to choose at runtime:
>>
>> CDI.current().select(IdentityStore.class, UsernamePassword);
>>
>> [Alex] What if we did not know the type of credential ahead of time?
>>
>
> That's where the second form of CDI comes in, the
> CDI.current().select(...) (or alternatively, the bean manager based API).
>
> As soon as you can do:
>
> Credentials creds = new UsernamePasswordCredentials("john", new
> Password("welcome1"));
>
> you have the credentials type, namely "UsernamePasswordCredentials". You
> can then ask CDI at runtime (at that moment): "Give me an IdentityStore
> that can handle UsernamePasswordCredentials". JSF now leans very heavily at
> this as mentioned before instead of using it's own handlers and
> registration factories.
>
>
>
>> The registry approach enables multiple CredentialHandlers to be
>> preconfigured to accept varied Credential types. The Credential type itself
>> would be used to select the CredentialHandler.
>>
>
> That strongly sounds what CDI already provides. For this EG it would be
> much simpler to go with that (if indeed possible, which it sounds like it
> is), instead of having to design and implement our own APIs.
>
>
>
>> [Alex] How would we use CDI to configure different CredentialHandlers or
>> Backend Stores for different deployments?
>>
>
>
> That's a core value of CDI actually. In fact, much of the reason to use
> CDI in the first place is to have the ability to change dependencies based
> on deployment type. The classical example is for unit testing, but it holds
> for deployment stages as well. The key technology here is the @Alternative
> qualifier and stereotypes. Via beans.xml different alternatives can be
> activated for different deployments. There are quite a number of articles
> about this, but here's one from Antonio:
> http://antoniogoncalves.org/2014/05/25/switch-datasource-with-cdi-alternatives-and-stereotypes
>
> In addition to swapping out implementations for different deployments, the
> same mechanism can also be used to let the user provide an alternative
> implementation to a default one that's provided by the container or a
> library. I've written a small article that explains that usage here:
> http://jdevelopment.nl/providing-alternatives-jsf-23s-injected-artifacts
>
>
>
>> [Alex] I know, I just picked a term. I will change the proposal based on
>> the outcome of issue 2
>>
>>
> Okay, great ;) Hopefully it will remain caller, but let's see how the EG
> votes.
>
>
>
>> [Alex] That is what I was thinking. Would we need to request support from
>> JASPIC for a RoleCallbackHandler for containers which distinguish groups
>> and roles?
>>
>>
> I think probably not, at least not if we're standardizing how groups and
> roles currently work. The group to role mapper should be enough here. The
> identity store returns a collection of "names". Those names could be seen
> as either groups or roles. If they are logically seen as roles, then the
> application can configure a 1:1 group to role mapping. E.g. "admin" will be
> mapped to "admin", which "effectively" makes the GroupPrincipalCallback a
> RolePrincipalCallback.
>
> If however we want to introduce new APIs so we can say "isCallerInGroup"
> and "isCallerInRole" down the line, then such new RolePrincipalCallback
> *may* be needed (this will require more thinking though, especially to see
> how this will interact with group to role mapping).
>
> Kind regards,
> Arjan
>
>
>
>