Hi,
On Tuesday, March 24, 2015, David Blevins <dblevins_at_tomitribe.com> wrote:
> Thanks soooo much for the leg up, Arjan. I'm seriously glad I asked. It
> helped me and I hope it helps others.
You're welcome ;)
>
> 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
Looks absolutely perfect to me. Extracting the data from the header that
way is exactly how it's normally done,
> What CDI scope would best describe the lifecycle of the ServerAuthModule?
> (JAAS is effectively @RequestScoped for example)
For the Servlet Profile the SAM itself is effectively stateless. Normally
the ServerAuthConfig that's provided by Servlet implementations to register
a SAM at the container side would create a new instance of the SAM each
time its needed. To use a SAM from within the application archive you use
your own ServerAuthConfig, so then this does not necessarily happen.
In my prototype for the simplified SAM registration there's only ever one
instance of the SAM, which was a quick test/prototype thing, but is of
course not suitable for real life usage (I'm going to change that now in
the prototype though to avoid confusion).
The SAM logically operates per request and strongly resembles a Servlet
Filter; the SAM is called before and after every request, and for both
protected and unprotected resources.
The result that the SAM produces (the authenticated identity, ie a Subject)
is request scoped.
This stateless / request scoped mode is different from some other (native)
Servlet authentication mechanism APIs. There a module is often only called
for protected resources and the result is frequently session scoped. With
those APIs, as long as there's an authenticated identity in the session the
authentication module is not called again.
> 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.
That's not entirely correct ;) HttpServerAuthModule is completely vendor
neutral. I've tested it on almost every JASPIC implementation I could get
my hands on.
> 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. :)
>
Absolutely!
Even though the base class is really vendor neutral, it's just a prototype
to demonstrate how just a relatively thin layer of helper code can have a
big effect on usability. I was looking at delegation for the next step, and
Les suggested this as well. Now that you mention this too, I think it's
pretty clear that it's the way forward. Incidentally, in the JSF EG we're
now looking at doing things in this way as well (getting rid of native
registration systems and possibly base classes and delegate to things
pulled from the BeanManager).
By pulling in a bean from the BeanManager, the simplified HTTP specific SAM
can have a very explicit scope (most likely @RequestScoped makes the most
sense, maybe @SessionScoped in some cases).
We'd then have
Bare low-level SAM ---- delegates to ----> CDI based HTTPSam ----
optionally delegates to ----> CDI based AuthenticationStore
One practical issue at the moment is that not all servers initialize CDI
early enough. JBoss does, but in GlassFish, WebLogic and Geronimo this is
not the case.
I think (not 100% sure) that CDI is almost always initialized via a
ServletRequestListener. The problem then is that JBoss invokes
ServletRequestListeners BEFORE authentication modules are called, and
GlassFish, etc AFTER. I didn't try TomEE yet, but would be interesting to
see what I does there.
Kind regards,
Arjan Tijms
>
> Think I saw a hint of that in code Alex posted in the CDI Events jira.
>
>
> -David
>
>