[cdi-dev] Thoughts on Phases and Events for the Security spec

Tue Dec 23 05:08:37 EST 2014

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.

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.