Thanks soooo much for the leg up, Arjan. I'm seriously glad I asked. It helped me and I hope it helps others.
I've gone ahead and implemented a hardcoded Basic Auth in the first provider. Can you verify the thinking is along the right lines?
-
https://github.com/javaee-security-spec/bootstrap/blob/master/simple-jaspic-example/src/main/java/org/secured/jaspic/current/Provider.java#L56
What CDI scope would best describe the lifecycle of the ServerAuthModule? (JAAS is effectively @RequestScoped for example)
On the simplified version that references JASPIC_SPEC-17, do you possibly have an abstract class?
-
https://github.com/javaee-security-spec/bootstrap/blob/master/simple-jaspic-example/src/main/java/org/secured/jaspic/simple/Provider.java
I grabbed HttpServerAuthModule and just kept grabbing. Clearly, the HttpServerAuthModule class is meant to be a concrete and vendor-specific class like HttpServlet.
Personally not a fan of having vendor implementation classes ship in javax.* packages, but it's been done plenty of times. Would probably need a clearer view of which classes would go in javax.* and which would outside should we want to consider a "vendor-supplied standard superclass" approach.
My gut says even if we don't go the subclass approach, flushing it out could unlock some other concrete ideas.
First step might be delegation instead of subclassing. Second step might be delegating to something pulled from the BeanManager. Third step could involve some stronger types or qualifiers to keep flexibility yet maintain extensibility.
Could get interesting quickly. :)
Think I saw a hint of that in code Alex posted in the CDI Events jira.
-David