Hi,
On Wed, Dec 30, 2015 at 12:08 PM, Rudy De Busscher <rdebusscher_at_gmail.com>
wrote:
> Question:
> There are 3 annotations defined for concrete implementations of the
> IdentityStore. How is a custom definition found by the system?
>
It's via the highlander rule now (there can be only one). The annotations
are scanned by the CDI extension and based on them they add 1 enabled
implementation of IdentityStore. Likewise, if a custom definition is used,
it's simply a class implementing IdentityStore.
The other code just asks CDI for an IdentityStore implementation, and
doesn't care how it was added; by an class on the class path implementing
that interface or by a CDI extension that programmatically added a Bean<T>.
> Should we consider also CDI beans which implement the IdentityStore
> interface?
>
That's in fact the one and only method now ;) The annotations just cause
such bean to be made programmatically available.
Kind regard,
Arjan
>
> 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
>>
>>
>>
>>
>