Hi,
On Tue, Oct 13, 2015 at 4:22 PM, Alex Kosowski <alex.kosowski_at_oracle.com> wrote:
> Also, I wanted to emphasize the two parts of an identity store: the
> credential validation (i.e. CredentialValidators) and the persistence store.
That's indeed understandable. It would be quite okay I think to use
this very term to explain what an identity store often is.
It's just that using the term in a way that may give the impression to
readers that it's an explicit artefact is likely to cause some
confusion.
E.g. Tomcat and GlassFish say:
"A [identity store] is a "database" of usernames and passwords that
identify valid users of a web application (or set of web
applications), plus an enumeration of the list of roles associated
with each valid user."
They don't use the term "database" afterwards, just in the explanation.
> So maybe instead of the package " javax.security.identitystore.persistence",
> we put standard implementations in " javax.security.identitystore.impl"?
"impl" would be very good.
Do note that due to a CDI technicality we can not directly just put
actual CDI annotated beans or producers there. The JSR375 jar would be
part of the AS and CDI doesn't scan those for beans. Instead as an
"application server"-side jar, you always have to add those beans
programmatically using a CDI extension (CDI extensions -are- picked
up).
This is what CDI itself does for what it calls its "default beans" and
what JSF 2.3 does as well. See e.g.
https://github.com/javaserverfaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/cdi/FacesContextProducer.java
Something to consider; we could alternatively not put the actual
implementations of the LdapIdenitityStore etc in the standard javax
package, but only annotations which cause an implementation specific
IdentityStore to be made available.
But this is probably best discussed post EDR. It has pros and cons.
Kind regards,
Arjan Tijms
>
> 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
>