Hi,
On Wed, Dec 30, 2015 at 4:57 PM, Rudy De Busscher <rdebusscher_at_gmail.com>
wrote:
> It's via the highlander rule now (there can be only one).
>
>
> I think we can allow easily multiple ones.
>
Well, yes and no.
The problem is that with multiple stores people quickly want to have
something more than just iterating until one is valid. The default model to
take into account then is the PAM inspired one as used by JAAS and many
other security systems. This is the model with Required, Requisite, Sufficient
and Optional.
See
http://docs.oracle.com/javase/6/docs/api/javax/security/auth/login/Configuration.html
There's an existing issue for this, see
https://java.net/jira/browse/JASPIC_SPEC-15
Typically in these models ordering is critical though, as there's often a
primary store and a fallback one. It can also be a multi-dimensional
problem, as you can have both multiple authentication mechanisms (e.g.
primary certificate, fallback form), as well as multiple identity stores
(like you mention, primary LDAP, fallback (local) database).
Then to make it a little bit more complicated, there's another dimension
and that's letting the user choose an authentication mechanism. See
https://java.net/jira/browse/JASPIC_SPEC-16 This will likely be less of a
problem for the identity store part, as I think you'd normally not let the
user choose that directly.
I experimented a little with it all here:
https://github.com/omnifaces/omnisecurity/blob/master/src/main/java/org/omnifaces/security/jaspic/factory/OmniServerAuthContext.java#L101
That one shows how a stack of "modules" is retrieved, which depends on
which method the user choose (e.g. Facebook, Google, name/password), and
then each stack of modules is iterated over (in order) and the outcome
processed according to the PAM/JAAS rules of stacking.
The classes themselves including a builder API for creating stacks can be
found here:
https://github.com/omnifaces/omnisecurity/tree/master/src/main/java/org/omnifaces/security/jaspic/config
So it's quite a discussion perhaps how to best support this.
Kind regards,
Arjan Tijms
>
> 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
>>>>
>>>>
>>>>
>>>>
>>>
>>
>