Alex/all,
Guess even if
Credentials creds = new UsernamePasswordCredentials("john",
new Password("welcome1"));
was just a quick example, it highlights, password aliasing or other ways of
avoiding password (and ideally usernames, too) are also a good thing to
offer ;-)
Good luck for your session tomorrow,
Werner
On Thu, Jun 18, 2015 at 8:38 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi,
>
>
> On Thursday, June 18, 2015, Alex Kosowski <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
>>
>>
>
>
>