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