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

arjan tijms arjan.tijms at gmail.com
Tue Dec 23 08:01:48 EST 2014


Hi,

Since the discussion went away from throwing events and to general
security in Java EE I'm replying in this new thread here. Eventually I
think this discussion is better at home with the Security API, but
that one doesn't have its mailing list open yet.

Hi,

On Tue, Dec 23, 2014 at 11:08 AM, Romain Manni-Bucau
<rmannibucau at gmail.com> wrote:
> Agree,
>
> I'd like to see JAAS enhanced to be really portable and configurable
> by app + supporting roles in its principal API (not only getName but
> getRoles as well) + being integrated with CDI. Would also be great to
> be simplified when customized, ie writing a LoginModule could be just
> implementing Principal authenticate(user, password); like
> HttpServletRequest was enhanced.

I agree with that. There are various existing issues on the EE tracker
covering most of this:

https://java.net/jira/browse/JAVAEE_SPEC-42 (Standardise user/caller
and group/role principals in Subject)
https://java.net/jira/browse/JAVAEE_SPEC-28 (Standardize Simple
Security Providers)
https://java.net/jira/browse/JAVAEE_SPEC-25 (Deploy JAAS Artifacts in
Application)
https://java.net/jira/browse/JAVAEE_SPEC-9 (Simplify and standardize
authentication & role mapping)

The following is also related:

https://java.net/jira/browse/JAVAEE_SPEC-37 (Better integration
between Servlet's auth-method, JASPIC's auth modules and realms/JAAS
login modules/simple security providers)

In short, JAAS LoginModules represent a repository of users/roles, but
at some point they have to put the user name and roles into a Subject,
and the way this is done is not standardized.

It should be possible to easily declare JAAS LoginModules using an
annotation and portable XML, and we should have a small set of the
most common ones standardized (e.g. DB, LDAP, users.xml)

Finally we should not forget that JAAS LoginModules only define a
repository, not a method to interact with the user in a client/server
environment. E.g. you can't do FORM or OAuth http redirects from such
module.

Kind regards,
Arjan Tijms




>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-23 10:03 GMT+01:00 Mark Struberg <struberg at yahoo.de>:
>> Switching languages is a business concern in some companies.
>>
>> And the example with the role switching was just ONE example. There are dozen others. Now you could go on and add all those things into a next spec adding another 450++ classes. But no one gonna use that!
>>
>> 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.
>>
>>
>> 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).
>>
>>
>>
>> I think JASPIC & Co has to be ditched and a totally new approach needs to be made.
>>
>>
>> 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
>>
>> thus it's really way easier to simply hack a ServletFilter and an own Principal system to guard your secured resources. You then also have the ability to use the same mechanism in e.g. batches, standalone SE programs etc.
>>
>>
>> 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
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>>
>>> On Monday, 22 December 2014, 22:55, arjan tijms <arjan.tijms at gmail.com> wrote:
>>> > Hi,
>>>
>>> On Mon, Dec 22, 2014 at 8:54 PM, Mark Struberg <struberg at yahoo.de> wrote:
>>>>  To be honest I'm not sure if I'd do any of this. All this should
>>> imo not belong to the EE spec at all. It is probably just far too business
>>> specific.
>>>
>>> What exactly should not be done? Authentication events, or the
>>> enumeration Antonio mentioned?
>>>
>>>
>>>>  What if the application needs some kind of role change. E.g. you
>>> temporarily switch roles, change the preferred language, etc? All these things
>>> are heavily depending on the application and are not technical at all.
>>>
>>> I'm not sure what the preferred language has to do with this. This is
>>> not an authentication concern, but simply a user preference and indeed
>>> an application concern.
>>>
>>> Switching roles however is an authentication concern. It's IMHO not
>>> business specific. There are two variations, a temporarily one as you
>>> mention, and a "permanent" one (permanent within a session, or as
>>> authentication in Java EE is by default per request, even do this for
>>> just the remainder of the request).
>>>
>>> The temporary one can be implemented via authentication stacks, and
>>> this can definitely be implemented in a completely non business
>>> specific way. In a declarative way @RunAs already does this in a way.
>>> A programmatic API could look like the following:
>>>
>>> request.authenticateStacked(); // Starts new authentication dialog, if
>>> authenticated previous identity is stored on stack
>>> request.authenticateStackedAs(String username); // Programmatic
>>> equivalent of @RunAs
>>> request.authenticateStacked(Callback... callbacks); // Generic
>>> variant, supporting extendible options such as adding/removing roles
>>> request.logoutCurrent(); // logs out current user, goes back one level
>>> on the stack
>>> request.logout(); // existing API, totally logs user out
>>>
>>> A "permanent" change is typical when for instance a username is linked
>>> to a user email, and the user changes his email. The act of changing
>>> this email is application specific, but just signaling this change to
>>> the container is a general action (see
>>> https://java.net/jira/browse/JASPIC_SPEC-22).
>>>
>>> Events can be largely orthogonal to all of this, although perhaps some
>>> properties of the event could give information about the authenticate
>>> type (new one, or stacked one).
>>>
>>> Kind regards,
>>> Arjan Tijms
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>>  LieGrue,
>>>>  strub
>>>>
>>>>
>>>>
>>>>  On Monday, 22 December 2014, 20:12, arjan tijms
>>> <arjan.tijms at gmail.com> wrote:
>>>>
>>>>
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> On Monday, December 22, 2014, Antonio Goncalves
>>> <antonio.goncalves at gmail.com> wrote:
>>>>>
>>>>> Hi all,
>>>>>>
>>>>>>
>>>>>>
>>>>>> The CDI spec defines the "Transactional observer methods"
>>> (§10.4.5) with a TransactionPhase :
>>>>>>
>>>>>>
>>>>>> public enum TransactionPhase {
>>>>>>   IN_PROGRESS,
>>>>>>   BEFORE_COMPLETION,
>>>>>>   AFTER_COMPLETION,
>>>>>>   AFTER_FAILURE,
>>>>>>   AFTER_SUCCESS
>>>>>> }
>>>>>>
>>>>>>
>>>>>> void onDocumentUpdate(@Observes(during=AFTER_SUCCESS) @Updated
>>> Document doc) { ... }
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Now that there is a new Security specification coming along, it
>>> would be helpful to be able to observe before/after the user logs-in or
>>> logs-out, for example. First I thought "well, the Security spec defines a
>>> set of events, fires them, and we just have to observe them". But what
>>> about the "during" phase ? What would make more sense in such use case
>>> ? Using the same "during" mechanism or events ?
>>>>>
>>>>>
>>>>> I think separate events may be better.
>>>>>
>>>>>
>>>>> Maybe I'm mistaken but the way I think the transactional events are
>>> used is that during a transactional method an event is fired. The event is then
>>> not delivered right away to all observers, but for those using
>>> during=after_success only when the TX commits. This is kinda like what JMS does;
>>> a message is only send when the TX commits, or send right away. CDI offers 3
>>> other cases, but I feel that those first two are the main ones.
>>>>>
>>>>>
>>>>> For authentication events I don't think we can really speak of a
>>> "logging-in" method. Even if we would appoint one (e.g.
>>> validateRequest() in a SAM) then I'm not sure whether any random event
>>> published during that method would have any need to be queued until just before
>>> or after authentication actually happens.
>>>>>
>>>>>
>>>>> Instead, we would merely be interested in the actual events; the moment
>>> the container is about to authenticate (so we can potentially veto) and the
>>> moment right after that (so we can take an action such as loading data related
>>> to the user into the current session).
>>>>>
>>>>>
>>>>> Just my 2 cents. Hope I understood the case correctly.
>>>>>
>>>>>
>>>>> Kind regards,
>>>>> Arjan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> public enum LoginPhase {
>>>>>>   BEFORE_LOGIN,
>>>>>>   AFTER_LOGIN,
>>>>>>   BEFORE_LOGOUT,
>>>>>>   AFTER_LOGOUT,
>>>>>> }
>>>>>>
>>>>>>
>>>>>> void onLogout(@Observes(during=BEFORE_LOGOUT) User user) { ...
>>> }
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Any thoughts ?
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Antonio Goncalves
>>>>>> Software architect, Java Champion and Pluralsight author
>>>>>>
>>>>>> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx
>>> France
>>>>>
>>>>> _______________________________________________
>>>>> cdi-dev mailing list
>>>>> cdi-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>
>>>>> Note that for all code provided on this list, the provider licenses the
>>> code under the Apache License, Version 2
>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided
>>> on this list, the provider waives all patent and other intellectual property
>>> rights inherent in such information.
>>>>>
>>>>>
>>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.



More information about the cdi-dev mailing list