>
> It's via the highlander rule now (there can be only one).
I think we can allow easily multiple ones.
If the Status.NOT_VALIDATED or INVALID is returned, we can go to the next
one. We stop the looping when we encounter a Status.VALID.
We can add some kind of ordering, but it is generally not needed. (we could
foresee a method in the IdentityStore interface which returns an ordinal
number on which the sorting is performed)
This way we can allow for multiple sources to be used at the same time (for
example Database and LDAP)
Regards
Rudy
On 30 December 2015 at 16:44, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> 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
>>>
>>>
>>>
>>>
>>
>