Hi all,
I was wondering about support for implementation specific authentication
mechanisms and specially identity stores. When we have multiple JSR375
implementations, people will want to use specific identity stores without
hurting portability. Server vendors themselves will provide their own. We
need the ability to define a custom auth mechanism/identity store without
compile-time dependencies. The user would provide multiple
mechanisms/stores, one for each target implementation, and the system would
fallback between them depending on what it is on the classpath.
I propose something like:
@VendorSpecificIdentityStore(
className = "org.glassfish.soteria.FileIdentityStore",
properties = {
@Property(key = "", value = ""),
@Property(key = "", value = ""),
}
)
@VendorSpecificIdentityStore(
className = "org.jboss.wildfly.security.PropertiesFileIdentityStore",
properties = /* ... */
)
public class MyBean {
}
@VendorSpecificIdentityStore is a repeteable annotation. They all only
count as a single IdentityStore. If the first defined class is not on the
classpath, the next will be tried. Obviously, the application should fail
to deploy if none of them work. Note that this has nothing to do with the
Multiple Authentication Mechanism funcionality that it's already in the
making. The specified class would need to implement a new interface:
public interface VendorSpecificIdentityStore extends IdentityStore {
default void init(Map<String, String> properties) {
}
}
Something similar could be done for Authentication Mechanisms.
What do you think?
Regards,
Guillermo González de Agüero.