Hi,
On Thursday, June 18, 2015, Alex Kosowski <alex.kosowski_at_oracle.com
<javascript:_e(%7B%7D,'cvml','alex.kosowski_at_oracle.com');>> wrote:
> Hi Experts,
>
> After reading Arjan's comments and spending many hours in a bar with David
> Blevins last night here at Devoxx UK, I would like to revise my proposal.
>
> I do not have a formal write up yet, but I updated some files in the
> GitHub proposals repo and would like your thoughts:
>
> Please see:
>
> https://github.com/javaee-security-spec/javaee-security-proposals/blob/master/identity-store/src/main/java/javax/security/idm/IdentityStore.java
>
> Some comments:
> 1. The IdentityStore is proposed now as read only, no CRUD for callers,
> groups, roles or credentials
> 2. Groups and Roles are just Strings, and are searchable by regular
> expression
> 3. As in the previous proposal, the Caller is a class, which has some meta
> data like locked and expiration date, maybe extendable with additional
> properties (or not?)
> 4. As in the previous proposal, the Credentials concrete class is
> understood by an associated CredentialHandler implementation, which knows
> how to validate the credentials
> 5. Standardized support for backend stores include: file, LDAP, database
> 6. SPI for extensible Credentials, CredentialHandler, Backend Store support
>
>
> Here is a usage case example:
>
> @Inject
> IdentityStore identityStore;
>
>
>
>
>
> * // Check credentials Credentials creds = new
> UsernamePasswordCredentials("john", ​ new Password("welcome1"));
> CredentialValidationResult result =
> identityStore.validateCredentials(creds); ​if
> (Status.VALID.equals(result.getStatus())) { ​ // authentication was
> successful List<String> roles =
> identityStore.getRolesForCaller(result.getValidatedCaller()); // TODO:
> SOMEHOW INFORM THE CONTAINER, VIA CALLBACK OR OTHERWISE, THE ASSIGNED ROLES
> ​ }*
>
> What do you think?
>
It looks good, much better!
Some comments after a brief look:
1
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);
2.
The term "caller" was the topic of issue 2, but we didn't had a vote for
that yet (I was about to start it, but something came between this week).
3.
"Somehow inform the container"
If the IdentityStore is called from an authentication mechanism then I
think it's clear that this should be the JASPIC CallbackHandler indeed.
After all, that's exactly the API that in Java EE a container has available.
As for the "otherwise", for what situation should that be?
One that I can think of is when a user calls HttpServletRequest#login. In
this case the current proprietary behavior is to call a proprietary
idententity store (eg a Realm in Tomcat). The standard behavior is to throw
an exception (#login is currently not supported in a standard way since we
never standardised identity stores before).
Now one way to support this would be to say to Servlet containers that if
#login is called and JSR 375 is available, they should call our Identity
Store and then use their own proprietary API as usual to set the
username/roles obtained from that.
An alternative way would be to have a special SAM that doesn't do user
interaction and only calls through to an identity store.
Any other use cases for when "otherwise" is needed?
Kind regards,
Arjan Tijms
>
>
> With regards,
> Alex
>
>
> On 6/12/15 4:19 AM, Alex Kosowski wrote:
>
> Hi Experts,
>
> I have been working on an Identity Store proposal for which I would like
> your comments. Basically, I am proposing we model the Identity Store after
> PicketLink IdM.
>
> The proposal is published as a Google doc here:
>
> https://drive.google.com/open?id=1D9awD7DjMTctRWXrNKUgSw_tEDlHISr69-U8L8rGyBo&authuser=0
>
> The proposal prototype is available here:
>
> https://github.com/javaee-security-spec/javaee-security-proposals/tree/master/identity-store
>
> The proposal Google doc should be open for comments by anyone on the
> jsr375-experts_at_googlegroups.com Google group. If you are having trouble
> commenting, please let me know. To comment, click the Comments button on
> the top right of the document.
>
> Note that I ran out of time, and Section 12 Attribute Management (and
> further) are currently marked "To Be Determined". I will get back to that.
>
> Regarding JSR 351 Identity API, I propose that JSR 351 would be integrated
> later (when available) as an IdentityStore implementation via the SPI.
> IdentityStore SPI could also be the integration point for server-specific
> identity stores. See the proposal to see what I mean by IdentityStore SPI.
>
> Please read the proposal and comment in the document.
>
> Thanks,
> Alex
>
>