Hi Arjan, All,
I would use a Principal instead of the "String getCallerName()". It also
has the getName() method and has the benefit that an implementation can
return a subtype of java.security.Principal. (as you mention)
It also allows you to create a Principal for those cases where we use
external authentication (OAuth2/OpenID/SAML/...) since a Principal is used
a lot nowadays. (with a proper identityStore which adds for instance the
groups/roles to the mix for those authentication protocols which don't
supply this information)
Although I'm not a fan of returning 'authorisation' info (like groups and
roles) in the method where we do 'authentication'. Could be a separate
method but I realise that it is a common practice today (to return both)
For me, not everything needs to be an interface. Implementations can always
extend the class and add their additional methods.
Question:
There are 3 annotations defined for concrete implementations of the
IdentityStore. How is a custom definition found by the system?
Should we consider also CDI beans which implement the IdentityStore
interface?
Hope to see other people their comments or approval to your nice proposal.
regards
Rudy
On 29 December 2015 at 16:47, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> 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
>
>
>
>