1:15 p.m.
Hi Guys,
What I like in a lot of security frameworks is that one can secure method calls with a
simple annotation. So my idea was that we could make something like @RequireAuthentication
on the remote interface and that would not allow the call if nobody is logged in. We could
develop something like this based on the InterceptedCall functionality, but because of the
way InterceptedCall is setup there is no way to make another annotation behave like
InterceptedCall. To make it a bit more clear i cannot define an annotation like this:
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD})
@InterceptedCall(SecurityInterceptor.class)
public @interface RequireAuthentication {
}
and have the SecurityInterceptor invoked the only way I can do it is by annotating the
methods with:
@InterceptedCall(SecurityInterceptor.class)
Why now have it more like the CDI interceptor api
http://docs.oracle.com/javaee/6/api/javax/interceptor/InterceptorBinding....
This gives me the ability to lousily couple the annotation with the interceptor are there
reasons for the model that is implemented now? Can we change it so that it will be more
flexible? Or shall we stick with how it's is now and extend the functionality to make
it work with my example annotation?
Cheers,
Erik Jan
1:57 p.m.
Hi,
We could come back to an idea we had a while ago: introducing annotation aliasing or
macros (as Mike called it). It would allow us to define an annotation say @UiProperty that
means the same as @Inject @Bound @DataField. We could extend that concept to also include
annotation values and then define @RequireAuthentication to mean
@InterceptedCall(SecurityInterceptor.class). This would mainly be an addition to
errai-codegen. The existing generators would stay the same.
The reason the current interceptor solution is not aligned with CDI is that it focuses on
remote calls (which are asynchronous and therefore require a more complex call context for
manipulating async results) and that it also needs to work without CDI (say in plain bus
apps).
Of course, nothing stops from extending this concept further….
Cheers,
Christian
On 2013-04-30, at 1:15 PM, Erik Jan de Wit <edewit(a)redhat.com> wrote:
Hi Guys,
What I like in a lot of security frameworks is that one can secure method calls with a
simple annotation. So my idea was that we could make something like @RequireAuthentication
on the remote interface and that would not allow the call if nobody is logged in. We could
develop something like this based on the InterceptedCall functionality, but because of the
way InterceptedCall is setup there is no way to make another annotation behave like
InterceptedCall. To make it a bit more clear i cannot define an annotation like this:
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD})
@InterceptedCall(SecurityInterceptor.class)
public @interface RequireAuthentication {
}
and have the SecurityInterceptor invoked the only way I can do it is by annotating the
methods with:
@InterceptedCall(SecurityInterceptor.class)
Why now have it more like the CDI interceptor api
http://docs.oracle.com/javaee/6/api/javax/interceptor/InterceptorBinding....
This gives me the ability to lousily couple the annotation with the interceptor are there
reasons for the model that is implemented now? Can we change it so that it will be more
flexible? Or shall we stick with how it's is now and extend the functionality to make
it work with my example annotation?
Cheers,
Erik Jan
_______________________________________________
errai-dev mailing list
errai-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/errai-dev
10:37 a.m.
As I understand it, the PicketLink Core library is an annotation driven
security model. Can it be applied here?
-Rodney
On Apr 30, 2013 11:57 AM, "Christian Sadilek" <csadilek(a)redhat.com>
wrote:
Hi,
We could come back to an idea we had a while ago: introducing annotation
aliasing or macros (as Mike called it). It would allow us to define an
annotation say @UiProperty that means the same as @Inject @Bound
@DataField. We could extend that concept to also include annotation values
and then define @RequireAuthentication to mean
@InterceptedCall(SecurityInterceptor.class). This would mainly be an
addition to errai-codegen. The existing generators would stay the same.
The reason the current interceptor solution is not aligned with CDI is
that it focuses on remote calls (which are asynchronous and therefore
require a more complex call context for manipulating async results) and
that it also needs to work without CDI (say in plain bus apps).
Of course, nothing stops from extending this concept further….
Cheers,
Christian
On 2013-04-30, at 1:15 PM, Erik Jan de Wit <edewit(a)redhat.com> wrote:
Hi Guys,
What I like in a lot of security frameworks is that one can secure method
calls with a simple annotation. So my idea was that we could make something
like @RequireAuthentication on the remote interface and that would not
allow the call if nobody is logged in. We could develop something like this
based on the InterceptedCall functionality, but because of the
way InterceptedCall is setup there is no way to make another annotation
behave like InterceptedCall. To make it a bit more clear i cannot define an
annotation like this:
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD})
@InterceptedCall(SecurityInterceptor.class)
public @interface RequireAuthentication {
}
and have the SecurityInterceptor invoked the only way I can do it is by
annotating the methods with:
@InterceptedCall(SecurityInterceptor.class)
Why now have it more like the CDI interceptor api
http://docs.oracle.com/javaee/6/api/javax/interceptor/InterceptorBinding....
This gives me the ability to lousily couple the annotation with the
interceptor are there reasons for the model that is implemented now? Can we
change it so that it will be more flexible? Or shall we stick with how it's
is now and extend the functionality to make it work with my example
annotation?
Cheers,
Erik Jan
_______________________________________________
errai-dev mailing list
errai-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/errai-dev
_______________________________________________
errai-dev mailing list
errai-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/errai-dev
2:23 a.m.
Hi,
if I understand right, @InterceptedCall is a _client_ side interceptor,
so I would not spend too much effort there :-)
Summarizing our experience concerning security w/ Errai-Bus:
- only server side security means _security_
- "logged in" is a conception, which is most critical server side,
the client may not know about current state - checking client side won't
really help
- Errai-Bus is to be regarded as "outside" of container security
context, because:
- communication shall _normally_ not be prohibited by security
- see Bus setup, Login-message
- once a message is received, it will be executed
- modern EE6/CDI interceptors are very easy to apply to service
beans (that's where they belong according EE), frameworks exist
(container based security, PicketLink), unconstrained by GWT JRE
emulation, Errai mapping..
- it would help to have some set of _RuntimeExceptions_ for typical
cross cutting concerns like security/validation.. handled naturally by
the bus - see "no boiler-plate" :)
Regards,
Thomas
Am 01.05.2013 16:37, schrieb Rodney Russ:
As I understand it, the PicketLink Core library is an annotation
driven security model. Can it be applied here?
-Rodney
On Apr 30, 2013 11:57 AM, "Christian Sadilek" <csadilek(a)redhat.com
<mailto:csadilek@redhat.com>> wrote:
Hi,
We could come back to an idea we had a while ago: introducing
annotation aliasing or macros (as Mike called it). It would allow
us to define an annotation say @UiProperty that means the same as
@Inject @Bound @DataField. We could extend that concept to also
include annotation values and then define @RequireAuthentication
to mean @InterceptedCall(SecurityInterceptor.class). This would
mainly be an addition to errai-codegen. The existing generators
would stay the same.
The reason the current interceptor solution is not aligned with
CDI is that it focuses on remote calls (which are asynchronous and
therefore require a more complex call context for manipulating
async results) and that it also needs to work without CDI (say in
plain bus apps).
Of course, nothing stops from extending this concept further….
Cheers,
Christian
On 2013-04-30, at 1:15 PM, Erik Jan de Wit <edewit(a)redhat.com
<mailto:edewit@redhat.com>> wrote:
> Hi Guys,
>
> What I like in a lot of security frameworks is that one can
> secure method calls with a simple annotation. So my idea was that
> we could make something like @RequireAuthentication on the remote
> interface and that would not allow the call if nobody is logged
> in. We could develop something like this based on
> the InterceptedCall functionality, but because of the
> way InterceptedCall is setup there is no way to make another
> annotation behave like InterceptedCall. To make it a bit more
> clear i cannot define an annotation like this:
>
> @Retention(RetentionPolicy.RUNTIME)
> @Target({ElementType.TYPE, ElementType.METHOD})
> @InterceptedCall(SecurityInterceptor.class)
> public @interface RequireAuthentication {
> }
>
> and have the SecurityInterceptor invoked the only way I can do it
> is by annotating the methods with:
>
> @InterceptedCall(SecurityInterceptor.class)
>
> Why now have it more like the CDI interceptor api
> http://docs.oracle.com/javaee/6/api/javax/interceptor/InterceptorBinding....
>
> This gives me the ability to lousily couple the annotation with
> the interceptor are there reasons for the model that is
> implemented now? Can we change it so that it will be more
> flexible? Or shall we stick with how it's is now and extend the
> functionality to make it work with my example annotation?
>
> Cheers,
> Erik Jan
> _______________________________________________
> errai-dev mailing list
> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/errai-dev
_______________________________________________
errai-dev mailing list
errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/errai-dev
_______________________________________________
errai-dev mailing list
errai-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/errai-dev
2:39 a.m.
Hi,
On May 2, 2013, at 8:23 AM, Thomas Frühbeck <fruehbeck(a)aon.at> wrote:
Hi,
if I understand right, @InterceptedCall is a _client_ side interceptor, so I would not
spend too much effort there :-)
From my perspective it's like validation of the model if we can
already do something on the client side we should do it there, but because this can be
bypassed we cannot rely on it and have to do this on the server as well. And like you
mention we can use CDI interceptors for this.
- "logged in" is a conception, which is most critical
server side, the client may not know about current state - checking client side won't
really help
Why is it not allowed for the client to know about the current state? Can't I have
something like hello #username on my page?
- Errai-Bus is to be regarded as "outside" of container
security context, because:
- communication shall _normally_ not be prohibited by security - see Bus setup,
Login-message
- once a message is received, it will be executed
Could you elaborate on this? What do you suggest that we do?
Cheers,
Erik Jan
3:55 a.m.
Am 02.05.2013 08:39, schrieb Erik Jan de Wit:
Hi,
On May 2, 2013, at 8:23 AM, Thomas Frühbeck <fruehbeck(a)aon.at> wrote:
> Hi,
> if I understand right, @InterceptedCall is a _client_ side interceptor, so I would
not spend too much effort there :-)
>From my perspective it's like validation of the model if we can already do
something on the client side we should do it there, but because this can be bypassed we
cannot rely on it and have to do this on the server as well. And like you mention we can
use CDI interceptors for this.
> - "logged in" is a conception, which is most critical server side, the
client may not know about current state - checking client side won't really help
Why is it not allowed for the client to know about the current state? Can't I have
something like hello #username on my page?
sure you are "allowed" :) -
cross cutting concerns (like security)
require IMHO a consistent/clear/stable handling, you would not clutter
_every_ RPC call with a "am I logged in".
The problem is, that the server may anytime decide to cancel the session:
- the client will not notice until trespassing - which could be any
call at any time, depending on server side business logic
- you do _definitely not_ want to have the password linger around
in your client app for later re-use
> - Errai-Bus is to be regarded as "outside" of
container security context, because:
> - communication shall _normally_ not be prohibited by security - see Bus
setup, Login-message
> - once a message is received, it will be executed
Could you elaborate on this? What do you suggest that we do?
short wrap-up of what
we tried:
- Errai Authentication: sorry, I evidently didn't understand how to
handle the async events and bridge that with e.g. EJB3 Security,
SeamSecurity, container based security, perhaps an unfortunate lack of
know how - hindlooking we just started on the wrong foot?
- Container Based Security: wont work, because it relies on
JSESSIONID cookie, the same being used by the bus (right?), so
Session.invalidate() means to interrupt the bus
- frameworks like PicketLink are versatile, tested, powerful,
annotation driven, easy to apply, best practice - that's what we settled
with and it _works_.
Personal conclusion: Errai is _more_ than a simple web client, forget
"security-constraint" in web.xml and blah.. (which is IMHO crap anyway)
We ended up with:
- a (simple) client side "ProgressInterceptor" handling cross
cutting concerns like: timeout, modality of UI, redirection on security
exception
- server side org.jboss.seam.security.SecurityInterceptor in
beans.xml and any relevant bean applied Seam @LoggedIn, etc.
- login/logout service - yes, nearly the same as Errai
Authentication, see above, hindlooking blah..
- authentication by SeamSecurity (brings PicketLink, JAAS, powerful
role/permission managent) - perhaps later exchange with DeltaSpike? No
problem!
Best Practice? I'm not sure :) But man, I am happy that it works
reliably, that's a stack you won't starve on easily.
Comments welcome!!!
Regards,
Thomas
4:06 a.m.
Hi,
sure you are "allowed" :) - cross cutting concerns (like
security)
require IMHO a consistent/clear/stable handling, you would not clutter
_every_ RPC call with a "am I logged in".
The problem is, that the server may anytime decide to cancel the session:
- the client will not notice until trespassing - which could be any
call at any time, depending on server side business logic
- you do _definitely not_ want to have the password linger around
in your client app for later re-use
No that would be very stupid...
>> - Errai-Bus is to be regarded as "outside" of
container security context, because:
>> - communication shall _normally_ not be prohibited by security - see Bus
setup, Login-message
>> - once a message is received, it will be executed
> Could you elaborate on this? What do you suggest that we do?
short wrap-up of what we tried:
- Errai Authentication: sorry, I evidently didn't understand how to
handle the async events and bridge that with e.g. EJB3 Security,
SeamSecurity, container based security, perhaps an unfortunate lack of
know how - hindlooking we just started on the wrong foot?
- Container Based Security: wont work, because it relies on
JSESSIONID cookie, the same being used by the bus (right?), so
Session.invalidate() means to interrupt the bus
- frameworks like PicketLink are versatile, tested, powerful,
annotation driven, easy to apply, best practice - that's what we settled
with and it _works_.
I wasn't suggesting not to use PicketLink why reinvent the wheel when we have
something that is tested and used by a lot of other projects. But I agree with you, to
make it work with Errai we have some integration work that we have to do. And have a long
hard look at how security is now handled by the bus.
Cheers,
Erik Jan
7:17 a.m.
First, I just want to point out that, while I agree that the real
security constraints *must* live server-side, there are also client-side
security concerns. You guys have already mentioned (and agreed on)
things like showing information about the current user. I wanted to add
for the record (is there a record?? :)) that it would also be extremely
helpful in Errai to be able to bring the roles/permissions across to the
client so that UI elements (menu items, buttons, entire pages) can be
included/excluded easily based on the user's permissions. That's not
security, but it would be great if it were a standard part of the framework.
More importantly, Thomas - is there any chance you have either some
documentation or can point at the actual code to show examples of the
role/permission management you are using?
On 05/02/2013 03:55 AM, Thomas Frühbeck wrote:
- authentication by SeamSecurity (brings PicketLink, JAAS,
powerful
role/permission managent) - perhaps later exchange with DeltaSpike? No
problem!
5:27 p.m.
Am 02.05.2013 13:17, schrieb Eric Wittmann:
First, I just want to point out that, while I agree that the real
security constraints *must* live server-side, there are also
client-side security concerns. You guys have already mentioned (and
agreed on) things like showing information about the current user. I
wanted to add for the record (is there a record?? :)) that it would
also be extremely helpful in Errai to be able to bring the
roles/permissions across to the client so that UI elements (menu
items, buttons, entire pages) can be included/excluded easily based on
the user's permissions. That's not security, but it would be great if
it were a standard part of the framework.
I absolutely agree, such functionality
would have to be handcrafted,
isn't it? No Principal/Credentials/Role etc in GWT...
More importantly, Thomas - is there any chance you have either some
documentation or can point at the actual code to show examples of the
role/permission management you are using?
Eric, I am really sorry, no. But then it is a young project, still plain
SeamSecurity in it's simplest form, really nothing spectacular. IMHO the
important point is: correctness, stability, extendability. It's an
inhouse project, authenticating via JAAS/Kerberos on central AD, so I
would not like my colleagues to mistrust my security impl (leaking
passwords or similar :-)
On 05/02/2013 03:55 AM, Thomas Frühbeck wrote:
> - authentication by SeamSecurity (brings PicketLink, JAAS,
> powerful
> role/permission managent) - perhaps later exchange with DeltaSpike? No
> problem!
4009
days inactive
4011
days old
8 comments
5 participants
participants (5)
-
Christian Sadilek -
Eric Wittmann -
Erik Jan de Wit -
Rodney Russ -
Thomas Frühbeck