Hi Arjan,
Thank you for being so active with this JSR! Please see inline.
Alex
On 6/18/15 7:38 PM, arjan tijms wrote:
> 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);
[Alex] What if we did not know the type of credential ahead of time? 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.
[Alex] How would we use CDI to configure different CredentialHandlers or
Backend Stores for different deployments?
>
> 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).
>
[Alex] I know, I just picked a term. I will change the proposal based on
the outcome of issue 2
> 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.
[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? We would then be able to provide the CallerPrincipal,
Groups, and Roles. Maybe such containers would apply additional roles to
defined groups?
>
> As for the "otherwise", for what situation should that be?
>
[Alex] That was an opening for other suggestions. I think the best way
would be to use JASPIC callbacks.
> 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?
[Alex] No, not off hand
> Kind regards,
> Arjan Tijms
>
[Alex] Unpublished in my local Git, I added a convenience overload for
validateCredentials for direct submission of username and password,
since this is the most common case.
>
>
>
> 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
>> <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
>>
>
>