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(a)gmail.com> wrote:
> Hi,
On Mon, Dec 22, 2014 at 8:54 PM, Mark Struberg <struberg(a)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(a)gmail.com> wrote:
>
>
>>
>>
>> Hi,
>>
>> On Monday, December 22, 2014, Antonio Goncalves
<antonio.goncalves(a)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(a)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.
>>
>>