users@javaee-security-spec.java.net

[javaee-security-spec users] [jsr375-experts] Identity store - handling a custom principal and interface only

From: arjan tijms <arjan.tijms_at_gmail.com>
Date: Tue, 29 Dec 2015 16:47:51 +0100

Hi,

I think we're quite close to a final proposal for the identity store
interface. The latest proposal is really quite workable. See
https://github.com/javaee-security-spec/javaee-security-proposals/tree/master/authentication/identity-store/identity-store-readonly-simplified


There are however a few things that I think could still be improved.

Currently not all types are fully interface based. E.g.
CredentialValidationResult is now a class and not an interface. For a spec
with a clear API/implementation split I think CredentialValidationResult
could better be an interface, with the implementation being provided by the
RI.

See
https://github.com/javaee-security-spec/javaee-security-proposals/blob/master/authentication/identity-store/identity-store-readonly-simplified/src/main/java/javax/security/identitystore/CredentialValidationResult.java

Another thing is that there's no support for a custom Principal now. This
again concerns CredentialValidationResult, which now only contains a
"String getCallerName()".

What we could do is add a "Principal getCallerPrincipal()" method, OR an
"Optional<Principal> getCallerPrincipal()" method.

Semantics would be that if Principal is not-null/present then the custom
principal is to be used, otherwise the getCallerName() has to be used.

Alternatively, we only define a getPrincipal() method. This could even
possibly return a subtype of java.security.Principal,
say javax.security.CallerPrincipal (an interface too). Default identity
stores would then return a direct implementation of
javax.security.CallerPrincipal, where custom identity stores can return a
more elaborate implementation with fields that only the application knows
about.

Thoughts?

Kind regards,
Arjan Tijms