Hi Markus,
On Thu, Jan 31, 2013 at 6:59 AM, Markus Eisele <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).
>
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).
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.
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.
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.
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.
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.
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 ;)
Kind regards,
Arjan Tijms