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