Hi,
I am breaking up the thread "[jsr375-experts] Re: Read-Only Identity
Store Proposal" into topics for easier consumption.
Regards,
Alex
On 10/6/15 11:13 AM, arjan tijms wrote:
....
>> Regarding:
>>
>> With a qualified IdentityStore, a user
>> can have multiple stores available, one for each credential type.
>>
>> E.g.
>>
>> @Inject @CredentialCapable(UsernamePasswordCredential.class)
>> IdentityStore idStore;
>>
>> Isn't this a bit of an edge case?
> I'm not 100% sure. I originally had two cases in mind:
>
> 1.
>
> For a remember me solution.
>
> Main authentication mechanism uses a caller name/password based
> identity store, while a wrapper (or CDI interceptor) for this
> mechanism uses a "RememberMeToken" based identity store.
>
> In this case, it's not a single authentication mechanism being
> injected with two stores, but the main store being injected with one,
> and the interceptor with another.
[Alex] Or is it really the same persistence mechanism (e.g.
DatabaseIdentityStore) but two different credential types handled, one
injection handles "RememberMeToken" and the other handles caller
name/password?
>
> 2.
>
> For having multiple authentication mechanisms in the same application.
>
> Say a FORM based authentication mechanism for the UI part of an
> application and a BASIC based authentication mechanism for a web
> service (JAX-RS) part.
>
> In this case too, a single authentication mechanism would not be
> injected with two stores, but the FORM one may be injected with the
> caller name/password identity store again, while the BASIC one may ask
> for a token based identity store.
[Alex] Well, in this case, both FORM and BASIC are really caller
name/password, right? Again, aren't we really referring to the same
persistence mechanism (e.g. LdapIdentityStore), but different (actually,
the same) credential types?
>
>> The CredentialValidator approach would support this using a qualified
>> producer.
>>
>> @Produces
>> @CredentialCapable(UsernamePasswordCredential.class)
>> public IdentityStore getIdentityStore() {
>> ...
>> // Instantiate store
>> return new LdapIdentityStore(...);
>> }
>>
>> @Produces
>> @CredentialCapable(TokenCredential.class)
>> public IdentityStore getIdentityStore() {
>> ...
>> // Instantiate store
>> return new DatabaseIdentityStore(...);
>> }
> Indeed, this is essentially the same thing. For custom identity stores
> the bean definition would not matter. With that I mean that
>
> @CredentialCapable(TokenCredential.class)
> public class DatabaseIdentityStore {...}
>
> Is for the intended purpose here identical to:
>
> @Produces
> @CredentialCapable(TokenCredential.class)
> public IdentityStore getIdentityStore() {
> return new DatabaseIdentityStore(...);
> }
>
> In CDI there's even a third form, see
> http://jdevelopment.nl/dynamic-cdi-producers
>
> Those all end up as nearly identical Bean<T> instances internally in
> the CDI runtime.
>
> What would matter here most is the lookup by the authentication
> mechanism, which would or would not use "@CredentialCapable". An
> authentication mechanism itself always knows the credential type,
> since it's responsible for obtaining it from the caller. I don't think
> you can often if ever dynamically add a credential type to an existing
> authentication mechanism.
>
> So now we have two variants here:
>
> In the one case, the authentication mechanism asks for an identity
> store that's capable of handling the specific credential type it has
> obtained from the caller, and CDI will throw an error if that one is
> not available.
>
> In the second case, the authentication mechanism just asks for -the-
> identity store and passes it the credentials it obtained. If the
> identity store is not capable of handling it (as determined internally
> in the store), it will throw an exception.
>
> Which one is better? I have to admit I don't really know.
>
[Alex] Using the CredentialValidator approach and the producer, either
variant could be available. One or many credential types could be
supported by one IdentityStore instance.