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