users@javaee-security-spec.java.net

[javaee-security-spec users] [jsr375-experts] Re: Identity Store Proposal 2.0

From: Pedro Igor Silva <psilva_at_redhat.com>
Date: Fri, 19 Jun 2015 09:15:24 -0400 (EDT)

Hey Alex,

   I looks good ! I've some questions:

      Why those callerExists(boolean), groupExists(boolean), roleExists(boolean) ? Why not just use those methods that expect a regEx and check things based on the result ?

Thanks !

----- Original Message -----
From: "Alex Kosowski" <alex.kosowski_at_oracle.com>
To: jsr375-experts_at_javaee-security-spec.java.net
Sent: Thursday, June 18, 2015 2:28:04 PM
Subject: [jsr375-experts] Identity Store Proposal 2.0

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?

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
>