Erik Jan de Wit
edewit at redhat.com
Thu May 2 04:06:06 EDT 2013
> 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.
More information about the errai-dev