Thoughts on Phases and Events for the Security spec
by Antonio Goncalves
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 ?
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 <http://www.antoniogoncalves.org> | Twitter
<http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> |
Pluralsight
<http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris
JUG <http://www.parisjug.org> | Devoxx France <http://www.devoxx.fr>
9 years, 4 months
Improving EE security (was: Thoughts on Phases and Events for the Security spec)
by arjan tijms
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(a)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(a)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(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.
>>>>>
>>>>>
>>>
>>
>> _______________________________________________
>> 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.
9 years, 4 months
TCK and spec question
by Mark Struberg
Hi!
I just came across this little sentence in the spec
11.5.6 "If any ProcessAnnotatedType method is called outside of the observer method invocation, an IllegalStateException is thrown."
I don't believe such a limitation helps much. What about extensions who do a setAnnotatedType and change this instance in a later phase? We have no whatever chance to prevent this anyway.
So why not just say that if a CDI System Event gets modified outside of the method it gets injected into then non portable behaviour results.
LieGrue,
strub
9 years, 4 months
Next meeting on wed 7 jan 2015
by Antoine Sabot-Durand
Hi all,
Most of us will be on holiday in the coming 2 weeks. So I propose we set the newt IRC meeting in 2015.
Wish you best for this end of year.
Antoine
9 years, 4 months
@Alternative without extends or implements?
by Mark Struberg
Hi!
Some TCK tests have @Alternative classes which neither extend nor implement a class.
Of course they explicitly extend Object.class, but that does not really make sense, doesn't it?
LieGrue,
strub
9 years, 4 months
[JBoss JIRA] (CDI-495) What happens if an illegal bean type is found in the set of bean types
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-495?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba updated CDI-495:
-----------------------------
Description: The spec clearly defines what the legal bean types are (2.2.1. Legal bean types). and also that an illegal injection point type results in definition error (5.2.3. Legal injection point types). However, it's not clear what should happen if an illegal bean type is found in the set of bean types and *is not used* in an injection point. I think that it would be reasonable to just ignore the type (and possibly log some warning). (was: The spec clearly defines what the legal bean types are (2.2.1. Legal bean types). and also that an illegal injection point type results in definition error (5.2.3. Legal injection point types). However, it's not clear what should happen if an illegal bean type is found in the set of bean types and is not used in an injection point. I think that it would be reasonable to just ignore the type (and possibly log some warning).)
> What happens if an illegal bean type is found in the set of bean types
> ----------------------------------------------------------------------
>
> Key: CDI-495
> URL: https://issues.jboss.org/browse/CDI-495
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 1.2.Final
> Reporter: Martin Kouba
>
> The spec clearly defines what the legal bean types are (2.2.1. Legal bean types). and also that an illegal injection point type results in definition error (5.2.3. Legal injection point types). However, it's not clear what should happen if an illegal bean type is found in the set of bean types and *is not used* in an injection point. I think that it would be reasonable to just ignore the type (and possibly log some warning).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
[JBoss JIRA] (CDI-495) What happens if an illegal bean type is found in the set of bean types
by Martin Kouba (JIRA)
Martin Kouba created CDI-495:
--------------------------------
Summary: What happens if an illegal bean type is found in the set of bean types
Key: CDI-495
URL: https://issues.jboss.org/browse/CDI-495
Project: CDI Specification Issues
Issue Type: Clarification
Affects Versions: 1.2.Final
Reporter: Martin Kouba
The spec clearly defines what the legal bean types are (2.2.1. Legal bean types). and also that an illegal injection point type results in definition error (5.2.3. Legal injection point types). However, it's not clear what should happen if an illegal bean type is found in the set of bean types and is not used in an injection point. I think that it would be reasonable to just ignore the type (and possibly log some warning).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
Do we already have a kind of CDI SE in 1.1+ ?
by Antoine Sabot-Durand
Hi guys,
As I said during last meeting I was puzzled by the non use of CDI and CDIProvider to address CDI boot in Java SE.
I just made a small test adding this class to weld-se :
public class WeldSEProvider extends WeldProvider {
private static boolean firstTime = true;
@Override
public CDI<Object> getCDI() {
if (firstTime) {
new Weld().initialize();
firstTime = false;
}
return super.getCDI();
}
}
and replaced the content of META-INF/services/javax.enterprise.inject.spi.CDIProvider by my provider
org.jboss.weld.environment.se.WeldSEProvider
Using this new version of Weld-se in my project Iw as able to boot CDI without implementation classes :
public class Main {
public static void main(String[] args) throws Exception {
CDI cdi = CDI.current();
BeanManager bm = cdi.getBeanManager();
}
}
Code is available in my weld fork : https://github.com/antoinesd/weld-core/blob/2.2-SE/environments/se/core/s... <https://github.com/antoinesd/weld-core/blob/2.2-SE/environments/se/core/s...>
Similar CDIProvider can be written for OWB as well.
I may have missed something, but I think we can figure out something like that to provide SE support in CDI today, even if it’s not as complete as the one we plan to push in CDI 2.0
Antoine
9 years, 4 months
Is the concept of mutable event payload specified
by Antoine Sabot-Durand
Hi guys,
Always working on Async event concept and discussion around mutable payloads. I was looking where in the spec we specified the fact that fired payload are mutable. I red-read chapter 10 (http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#events <http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#events>) twice and didn’t found. I also browsed JIRA and TCK to find any ref to this feature and found nothing. On the other hand it is not specified that payload should be immutable ;)
I’d be happy if some of you could have a look and see if I missed something.
If I’m not wrong, the mutable payload we (including myself) advertise in CDI is a non portable feature (I’m the firs surprised here). So I propose that :
1) We decide to write something in the specification about allowing or forbidding it (I know some people not happy with this mix between observer and visitor pattern)
1bis) Should we decide to forbid it by default, we should provide an alternative mode to allow people using this unspecified feature
2) Forbid it for fireAsync()
Thanks for your feedback and your correction if I missed the feature in the spec.
Antoine
9 years, 4 months
Re: [cdi-dev] Today's meeting will be shorter and about SE
by Werner Keil
Seems nobody else in the EG even has comment rights to the Google doc?
Werner
On Thu, Dec 18, 2014 at 7:07 PM, <cdi-dev-request(a)lists.jboss.org> wrote:
>
> Send cdi-dev mailing list submissions to
> cdi-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
> cdi-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Today's meeting will be shorter and about SE
> (Antoine Sabot-Durand)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 18 Dec 2014 19:07:15 +0100
> From: Antoine Sabot-Durand <antoine(a)sabot-durand.net>
> Subject: Re: [cdi-dev] Today's meeting will be shorter and about SE
> To: John Ament <john.d.ament(a)gmail.com>
> Cc: Jos? Paumard <jose.paumard(a)gmail.com>, cdi-dev
> <cdi-dev(a)lists.jboss.org>
> Message-ID: <A93BB3E4-1DCE-4A7C-B292-8243047B38F8(a)sabot-durand.net>
> Content-Type: text/plain; charset="utf-8"
>
> Sorry John I thought you had the permission. Just gave them to you
>
> Antoine
>
>
9 years, 4 months
