Hi Rudy,
Did you give the concerns below some consideration already?
Would be cool to see how far we can get with the multiple stores story. I
think the options are:
1. No order at all (like you suggested), only consider success/fail
2. Ordered in some way (@Priority?), only consider success/fail
3. Ordered in some way (@Priority?), process according to PAM/JAAS rules
Kind regards,
Arjan Tijms
On Wed, Dec 30, 2015 at 7:49 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>