marc fleury wrote:
>
> JBoss doesn't remember squat. Remeber that we have clients with some logic
> (dynamic proxy invocation handler is a real you can see in our tree) and
> there you have thread extraction of the propagation context. The thread
> doing the call in jboss is associated (actually only when doing the call)
> with the "context information" such as Tx and Principal.
>
> So the client passes on that information and the server uses only for the
> invocation. The bean that is in cache can know whatever you want and we do
> keep transaction association with a given instance (some of our rentrancy
> tests look at that)
>
Does this mean that the client has to supply its credentials for each
invocation and that they also have to be re-validated by the
authentication mechanism every time? If so, is this not a substantial
per-call overhead compared to the situation where the server maintains
some state to represent the security context?
I'm not very familiar with JAAS and so on and would like to get some
idea of how the security in Jboss is put together, if someone could
recommend where to begin. I have some previous experience of working
with CORBA style security. In the system we were developing the client
would logon using a single authentication server which would issue it
with identity and privilege credentials (x.509 certificates with
suitable extensions) which it would use to access other distributed
servers. The secure associations would be maintained using tokens, so
in this case each server had to maintain state for its clients - the
client-side interceptor would just supply the token each time in the
security context part of the iiop message and the corresponding server
side interceptor would check it against its cache.
Just curious,
Luke.
--
Luke Taylor.
PGP Key ID: 0x57E9523C
