Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adjust SecurityContextImpl to use ServiceLoader discovery for CallerDetailsResolver and ResourceAccessResolver #327

Open
darranl opened this issue Aug 16, 2022 · 5 comments
Assignees

Comments

@darranl
Copy link
Contributor

darranl commented Aug 16, 2022

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.

@arjantijms
Copy link
Contributor

arjantijms commented Aug 17, 2022

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();
}

@darranl
Copy link
Contributor Author

darranl commented Aug 18, 2022

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
Copy link
Contributor Author

darranl commented Aug 18, 2022

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
Copy link
Contributor Author

darranl commented Aug 21, 2022

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/

@arjantijms
Copy link
Contributor

@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.

@darranl darranl changed the title Make it possible for a server specific implementation of SecurityContext to be used. Adjust SecurityContextImpl to use ServiceLoader discovery for CallerDetailsResolver and ResourceAccessResolver Jul 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants