soteria icon indicating copy to clipboard operation
soteria copied to clipboard

Adjust SecurityContextImpl to use ServiceLoader discovery for CallerDetailsResolver and ResourceAccessResolver

Open darranl opened this issue 3 years ago • 5 comments

The server implementation may wish to be a complete implementation but at the very least it will be desirable to provide custom implementations of CallerDetailsResolver and ResourceAccessResolver.

darranl avatar Aug 16 '22 19:08 darranl

Absolutely. I vividly remember this as one of the open issues for Soteria 1.0. We didn't have an actual SPI/Service Locator yet, and just quickly seeded the security context implementation with default implementations:

@PostConstruct
public void init() {
   callerDetailsResolver = new ReflectionAndJaccCallerDetailsResolver();
   resourceAccessResolver = new JaccResourceAccessResolver();
}

arjantijms avatar Aug 17 '22 15:08 arjantijms

There are two different strategies I could consider for this one.

One option could be to adjust the CDI extension so servers can extend the extension and customise the behaviour, the instantiation of these implementations could be moved into a protected method allowing child classes to swap in their own instances.

Establishing a pattern of extending the CDI extension could be useful if other aspects of Soteria may way to be modifiable based on the server.

Or a simpler solution as both of these already have a defined interface may be to just use ServiceLoader discovery for the two classes with a rule that the first instance discovered will be used.

darranl avatar Aug 18 '22 09:08 darranl

Actually as the SecurityContextImpl is already a CDI bean maybe it will be better for both these instances to be application scoped beans then alternatives can be provided. That would also mean if Soteria is bundled in a web application and not managed by a server alternate implementations could also be provided in a similar way.

darranl avatar Aug 18 '22 09:08 darranl

Continuing the thoughts in this one, Soteria already contains a mechanism to use ServiceLoader discovery with Soteria providing a default implementation and prioritising the alternative if found - to keep this simple for now it feels easier to use this mechanism for the two interfaces used by SecurityContextImpl/

darranl avatar Aug 21 '22 17:08 darranl

@darranl Indeed, Soteria contains this: https://github.com/eclipse-ee4j/soteria/blob/master/impl/src/main/java/org/glassfish/soteria/SoteriaServiceProviders.java

Eventually it would be great to identify why such things are needed, and see if we can address it by introducing standard APIs in future versions of Jakarta EE.

arjantijms avatar Aug 25 '22 23:08 arjantijms