[cdi-dev] Improving EE security (was: Thoughts on Phases and Events for the Security spec)

[arjan tijms]

Hi,

On Tue, Dec 23, 2014 at 10:03 AM, Mark Struberg <struberg at yahoo.de> wrote:
> JASPIC and EE security is pretty much a disaster area right now because it did NOT step back a few meters and tried to just introduce APIs which are generic (or specific) enough to be very flexible.

Are we really talking about the same thing here? JASPIC is really
generic and flexible, almost to its fault. There are no specific use
cases coded into JASPIC.

It's essentially a Servlet filter, with the main difference that you
get a callback handler from the container. There are two callbacks
that you can pass in; the CallerPrincipalCallback and the
GroupPrincipalCallback, which you use to pass the two above mentioned
data items to the container.

And that's basically it.

Check http://arjan-tijms.omnifaces.org/2014/11/header-based-stateless-token.html
to see what a simple JASPIC SAM looks like.


> I can do 100% of what you can do with JavaEE security in a simple Servlet Filter, a CDI producer and an interceptor within 300 lines. And all this is really extensible and works perfectly for all my customers weirdest use cases (like integration into HOST security, etc).

Essentially JASPIC is closer to that than you might think. And there's
a little more to it than just a filter, producer and an interceptor.

You'd also want some method to determine if the resource you're
accessing is protected (secured) or not and a way to propagate the
caller principal and roles to another context (such as a remote EJB
call, or a container managed thread). And you need to be able to
trigger the mechanism programmatically (which
HttpServletRequest#authenticate does). You can't just cause a Filter
to be called again mid request.

Finally, and although I'm personally not a big fan of it for all
application types, there is a strong use case for having security
modules installed AS wide instead of embedded with an application
archive. A JASPIC SAM can be either installed AS wide (using
proprietary means) as well as embedded with an application archive
(using a standard API).


> I know this might be an extreme position and we might finally meet in the middle. But this is what I've seen in MANY companies. EE security is
>
> a.) to hard to understand and thus
>
> b.) not well understood
>
> c.) too complex
> d.) without giving you all the bits you need in practice

That's definitely true, hence the dire need to improve things in Java EE 8.

I just don't think any of the existing infrastructure needs to be
thrown away. In case of JASPIC it just needs a few convenience methods
and a base for the Servlet case (not entirely unlike HttpServlet vs
Servlet and GenericServlet) and always having CDI available when a SAM
is called.

Furthermore we need a clear distinction of the auth mechanism being
used (e.g. FORM) and the repository used to check credentials (e.g.
LDAP or DB) with users having a clear declarative and programmatic way
to specify either of those.

Servlet now lets you specify a fixed mechanism really easy, but the
custom option is missing and the repository
(domain/realm/provider/...) is left opaque.

JASPIC lets you specify a custom mechanism, but there's no declarative
option and the programmatic way is overly verbose.

Adding a convenience method to make the programmatic option in JASPIC
really easy is not that hard (I've already did this in OmniSecurity
and for the EE 7 samples project) and building a declarative option on
top of that is almost trivial.


> And the best thing: it is really portable, which most of the EE security stuff is NOT. There you always need to tweak container specific config, add LoginModule totally different each time, etc

JASPIC itself is portable, but some containers have mandatory role to
group mapping which makes it necessary to indeed tweak container
specific config. IMHO this *completely ruins* the experience of having
portable modules. The answer though is relatively simple; don't have
-mandatory- role to group mapping. A somewhat less simple answer (but
should still be doable); standardize role to group mapping.

But I get what you're saying and I fully agree as I've been pushing
the exact same point; it should be possible to configure security
without any container specific tweaks whatsoever.

Kind regards,
Arjan