Agreed.
Before we added JAAS adapter, they were all identity stores associated
with persistence mechanisms and it made more sense. But now that is not
exactly correct. Also, I wanted to emphasize the two parts of an
identity store: the credential validation (i.e. CredentialValidators)
and the persistence store. But based on the latest comments,
CredentialValidators are being viewed as too heavy weight, and perhaps
this distinction is too confusing.
Regarding packaging...
So maybe instead of the package "
javax.security.identitystore.persistence", we put standard
implementations in " javax.security.identitystore.impl"?
Regards,
Alex
On 10/11/15 5:24 PM, arjan tijms wrote:
> One additional remark:
>
>> 6. Standardized support for persistence mechanisms, including file, LDAP, database, and a JAAS adapter
> Instead of calling it "persistence mechanism", shouldn't we just call
> it "identity store implementation"?
>
> This now introduces a new term, but say a DatabaseIdentityStore is
> obviously an implementation of the IdentityStore interface and even
> has "IdentityStore" in its name. Talking about "persistence mechanism"
> instead may be confusing.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
> On Tue, Sep 29, 2015 at 7:42 AM, Alex Kosowski<alex.kosowski_at_oracle.com> wrote:
>> Hi Volunteers,
>>
>> I would like to submit for your review a third iteration of the JSR 375
>> Identity Store. I think this version is simpler than the previous
>> iterations, and incorporates the latest comments.
>>
>> Features:
>> 1. Follows the simple model: Credentials in -> Caller, groups, roles out
>> 2. The IdentityStore is read only, no create/update/delete for callers,
>> groups, roles or credentials
>> 3. Caller, Groups and Roles are just Strings, and are searchable by regular
>> expression
>> 4. Credential support is extendable by using CDI Qualifiers to annotate a
>> CredentialValidator implementation
>> 5. Standardized support for credentials, including Username/Password, Basic
>> Authentication, Token
>> 6. Standardized support for persistence mechanisms, including file, LDAP,
>> database, and a JAAS adapter
>>
>> Here is a usage case example:
>>
>> @Inject
>> IdentityStore idStore;
>>
>> // For example, in a JASPIC SAM...
>> String caller = null;
>> List<String> groups = null;
>> List<String> roles = null;
>> CredentialValidationResult result;
>> Credential cred;
>>
>> cred = new UsernamePasswordCredential("john",new Password("secret"));
>> result = idStore.validate(cred);
>> if (Status.VALID == result.getStatus()) {
>> // authentication was successful
>> caller = result.getCallerName();
>> groups = result.getCallerGroups();
>> roles = result.getCallerRoles();
>>
>> // Callback JASPIC
>> } else {
>> // Invalid or not validated
>> }
>>
>> I completely rewrote the Proof of Concept (POC) from the previous iteration
>> and updated the proposal design doc. Let's discuss any issues you may have
>> with this design.
>>
>> Please comment on this proposal Google doc:
>> https://docs.google.com/document/d/1xMa32W73gPYYo53wRX60WasDDTuC7YFlI0XBm3dRym8/edit?usp=sharing
>>
>> 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.
>>
>> Here is the POC in the GitHub Proposal Repo:
>> https://github.com/javaee-security-spec/javaee-security-proposals/tree/master/identity-store-readonly
>>
>> Note that the DatabaseIdentityStore in the POC is without an implementation
>> because I ran out of time.
>>
>> Here is the generated JavaDoc:
>> https://javaee-security-spec.java.net/
>>
>> What do you think? Once we come to a consensus for an acceptable Identity
>> Store API design, the proposal will become the basis for the Identity Store
>> section of the spec.
>>
>> With regards,
>> Alex
>>