Darran Lofthouse

I have been thinking a little further, most importantly the time the security "context" is captured causes us no issues at all so we can always create the ThreadContextSnapshot populated...

> But, inside your security implementation, where do you store the current security context? In a ThreadLocal I assume, right? So this would make it use two ThreadLocals, which doesn't...

Regarding the setting of the ThreadLocal we chose to follow the same pattern as is used by Subject and AccessControlContext to guarantee clean up. In prior security solutions we did...

Just finishing off some other tasks and will come and take a closer look - but +1 the actual Signature may not be re-usable but there may be some options...

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

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

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

Within WildFly at the time of deployment we scan the annotations used in the deployment and if we detect EE security annotations we activate the Soteria EE security extension. One...

@keilw Soteria is now Jakarta EE 10, the first WildFly release to be Jakarta EE 10 will be WildFly 27. The "jboss" code presently contained within Soteria is non functional...

I see from the spec that an integration of JASPIC could choose to use a single CallbackHandler what I don't see from the spec is anything requiring it to do...