|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.
|
yes, ok. Let me be more precise.
(I have not worked with JAAS directly or in the implementation of the
current LoginModule done by Oleg)
I was talking about what JBoss does and propagate in the message generation.
The proxy code on the client can extract whatever it is that you use to
signify your authenticated status.
Now if your code requires to extract a Security Propagation Context that
wraps the token or whatever then you need to specify that code in the client
proxy.
The codebase is modular even in that way. In the sense that the invocation
layer can build a proxy based on whatever need (remember static compilation
of stubs is Baaaaad, mmmkey?).
I don't know that we have the code to externalize that information (tell the
stack to use an instance of this to wrap in the proxy by way of some
contextual XML information).
I recommend taking a peak at what we do in the "straight JRMP1.3" and how we
branch to 1.2.2 if needed. I believe it is done with extensions of the base
classes which.. blah... maybe we could fully parametrize this class, I don't
know.
Then take a look at the proxy classes sent to the client and that is where
you code your "own propagation". The way the default proxies are coded for
security ? I don't know I haven't taken a look at it. Oleg? any input?
marc
|Just curious,
|
|Luke.
|
|--
| Luke Taylor.
| PGP Key ID: 0x57E9523C
|
