users@javaee-spec.java.net

[javaee-spec users] Re: CDI support in JASPIC

From: Ron Monzillo <ron.monzillo_at_oracle.com>
Date: Thu, 31 Jan 2013 15:50:19 -0500

On 1/31/13 6:23 AM, arjan tijms wrote:
> Hi Markus,
>
> On Thu, Jan 31, 2013 at 6:59 AM, Markus Eisele <myfear_at_web.de
> <mailto:myfear_at_web.de>> wrote:
>
>
> The idea of jsr-196 is to have "portable" security. Requiring an
> application component for a SAM is a no go!
> Whatever you have in mind, make sure it stays portable! If you have
> something closer to your application you are
> free to use one of the application centered approaches (e.g.
> @WebFilter).
>
>
Markus is correct that the core use case for which we developed auth
modules was
as a trusted adjunct to the container authentication subsystem.
Moreover, although we
fully allowed for and support per application configuration of
authentication modules,
we would expect common usage to be the configuration of an
authentication agent for
use by a group of applications perhaps all related to some common
enterprise.
>
> A SAM actually doesn't seem to be that far removed from a WebFilter.
> The problem with a WebFilter though is that there's no way to make the
> container aware of the login status.
>
> Meaning, if I totally ignore Java EE security (@RolesAllowed,
> request.isUserInRole) etc, then something based on a WebFilter and
> possibly custom interceptors would work (Adam Bien demonstrated such
> an approach in the Jan/Feb 2013 edition of Oracle's online Java Magazine).
>
Arjun is also correct that another core value proposition of the spi is
that it provides for the integration of authentication
agents within the servlet constraint processing and programming model;
in a fashion analogous to the native
required to be supported authentication mechanisms.
>
> However, when you'd want application specific authentication, but also
> integrate with the existing Java EE declarative security system, a web
> filter unfortunately is not the way to go.
>
> What I'm basically trying to do is to implement the idea I proposed
> here: http://java.net/jira/browse/JAVAEE_SPEC-9. This on its turn was
> inspired by work we wanted to do for the OmniFaces project; create an
> authentication mechanism that's closer and more native to JSF than the
> existing build-in form based one and which supports application
> specific authentication.
>
> The idea is that the SAM is basically still portable. It is bundled
> with the application (as opposed to being installed on the AS), but
> JASPIC supports this. Then the SAM reaches out to an application
> defined bean, which is capable of doing the actual authentication in
> an application specific way. For obtaining a reference to this
> application defined bean, CDI seems like the best approach.
>
As I wrote in a prior note, I think there are reasons why we should move
away from the pattern where users must exchange their passwords with
applications and application servers.
that said, you can certainly bundle a SAM in you application, in which
case, I think you would need to register an authconfigprovider for your
app, and configure it with the auth module
contained in your app, and I think you will need to do so, at the point
where you application embedded sam is available for loading, and your
application has not yet been initialized
to receive requests.

> After some more experimenting, I discovered that an
> HttpServletRequest#authenticate from e.g. a managed bean -will- call
> the SAM as well (for some reason HttpServletRequest#login doesn't, but
> that's another story), and when the SAM is reached in this way it
> fully operates in the scope of the calling bean. In other words, in
> that case, all contexts are active in the same way as they are in the
> calling bean.
>
correct
>
>
> All the relevant security APIs didn't had an overhaul in some years
> and naturally didn't catch up with the platform.
> Looking at them, I would highly appreciate a more convenient and
> developer friendly approach of implementing the required artifacts.
> That might include the fact that they could facilitate CDI and even
> JPA but in a space completely separated from the deployed
> applications.
>
>
I am open to the use of CDI, however, I think there are some apposing
objectives that we will need to sort through.
> Using CDI, JPA etc for implementing modules outside deployed
> applications would surely be interesting as well, although for the use
> case we're looking at the focus is on using the same JPA persistence
> contexts and CDI scopes as the application is using.
I see
>
> For (simple) applications that contain their own registration (many
> web apps) that they don't share with any other application, having to
> install and configure a login module at the AS level, even if this
> login module itself is portable (in the case of JASPIC) is often seen
> as a tedious and somewhat arcane task. At least, that's the signal
> we're getting at OmniFaces, and the reason for willing to accomodate
> this particular use case.
>
I think we should take a closer look at why the configuration has been
difficult. In the JAAS based auth config provider that I mentioned. All
one needs to do is
add a config entry to a jaas config file, a default can be defined to
cover all other apps. And jsr 196 also provides the ability to say that
for some apps, the jaas config
and its default do not apply.

> Of course we're not advocating that login modules should always be
> bundled with every application. For other use cases it's much better
> to have the login module configured at the AS level in combination
> with a credential store at a central location that can be shared
> between many different applications.
>
> As is often the case, it depends on the requirements, and we feel Java
> EE should support both use cases ;)
>
that seems reasonable.

Ron
> Kind regards,
> Arjan Tijms