Hi,
I've updated the project[1] I was using for JAVAEE_SECURITY_SPEC-12 with my view of the Identity Store API.
I think it is pretty much aligned with what Alex did but with some minor changes. This project also provides two test cases to demonstrate how to use both `IdentityStore` and `SecurityContext` together to authenticate users when using CDI or just the Servlet API.
@Arjan, I think with this approach is pretty easy to provide an "Identity Store Selector" based on a specific credential type given that the `IdentityStore` also provides a `getCredentialSupport` method that you can use to check if it supports or not a credential type.
I've also considered a `getPermissions` method on the `IdentityStore` interface. That would be very useful for Permission Mapping, providing a very easy and clean way to obtain permissions (and even check them) from an Identity Store.
@Alex, as I told you, I think PL IDM API was very good for an initial version. However, I think there is room for simplifications and that is what I tried to achieve in this project.
Any feedback is welcome.
[1]
https://github.com/pedroigor/javaee-security-proposals/tree/identity-store-example/security-context-authentication
Thanks.
Pedro Igor
[1]
https://github.com/pedroigor/javaee-security-proposals/tree/identity-store-example/security-context-authentication
----- Original Message -----
From: "arjan tijms" <arjan.tijms_at_gmail.com>
To: "Alex Kosowski" <alex.kosowski_at_oracle.com>
Cc: jsr375-experts_at_javaee-security-spec.java.net
Sent: Friday, June 19, 2015 11:04:59 AM
Subject: [jsr375-experts] Re: Identity Store Proposal 2.0
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