Hi,
I am breaking up the thread "[jsr375-experts] Re: Read-Only Identity
Store Proposal" into topics for easier consumption.
Regards,
Alex
> One thing that we left out of the equation is that the end-user now
> typically matches an identity store to a authentication mechanism. So
> direct injection of a single instance is maybe unlikely anyway.
>
> E.g. in web.xml one now starts with:
>
> <login-config>
> <auth-method>FORM</auth-method>
> <form-login-config>
> ...
> </form-login-config>
> </login-config>
>
> Some servers then use the<realm> element here to denote the matching
> identity store, but as that one is a bit overloaded it may be worth
> looking into a new element here. E.g. perhaps identity-store-name?
[Alex] OK
> <login-config>
> <auth-method>FORM</auth-method>
> <identity-store-name>MyDataBaseStore</identity-store-name>
> <form-login-config>
> ...
> </form-login-config>
> </login-config>
>
> In CDI the @Named annotation can be used to give identity stores a name.
>
>
> Of course this also has to work in combination with the standard
> implementations. As such, I'm a bit puzzled how the following syntax
> from the document in section 11.2.1.2 would work:
>
> @EmbeddedIdentityStore(
> {_at_Credentials(username="reza", password="secret", roles="dad"),
> @Credentials(username="nicole", password="secret", roles="mom")})
> @Inject
> IdentityStore idStore;
>
> The above injects an identity store in the application, but how does
> this make the configured data available to an identity store that the
> authentication mechanism obtains?
>
>
> Maybe consider the following approach instead:
>
> @EmbeddedIdentityStore(
> name = "myStore"
> data = {
> @Credentials(username="reza", password="secret", roles="dad"),
> @Credentials(username="nicole", password="secret", roles="mom")})
> public class SomeClass {
> // no implementation code needed here
> }
>
> Then a CDI portable extension checks for @EmbeddedIdentityStore, and
> if encountered dynamically creates a Bean<T> with the given name and
> data.
>
> E.g. in partial pseudo code:
>
>
> Collect the data from the application:
>
> public<T extends EmbeddedIdentityStore> void processBean(@Observes
> ProcessBean<T> event, BeanManager beanManager) {
>
> Optional result = getAnnotation(beanManager,
> event.getAnnotated(), EmbeddedIdentityStore.class);
> if (result.isPresent()) {
> // extract name and data
> }
> }
>
>
> Register a Bean<T> for this:
>
> public void afterBean(final @Observes AfterBeanDiscovery afterBeanDiscovery) {
> afterBeanDiscovery.addBean(new EmbeddedIdentityStoreBean(name, data));
> }
>
>
> And finally, EmbeddedIdentityStoreBean as something like this:
>
> public class EmbeddedIdentityStoreBean extends CdiBean<IdentityStore> {
> public EmbeddedIdentityStoreBean(String name, Data data) {
> super.name(name)
> .scope(ApplicationScoped.class)
> .types(IdentityStore.class)
> .create(e -> new EmbeddedIdentityStoreImpl(data));
> }
[Alex] Makes sense, let's add name to @EmbeddedIdentityStore, since that
implementation is defined by annotation. Other extended IdentityStore
implementations could use @Named. If we define annotations to configure
DatabaseIdentityStore and LdapIdentityStore, we could add a name
attribute there as well. What do you think?
> Kind regards,
> Arjan Tijms