Luke Taylor wrote:
>> I can't tell you in details how proxy works, better ask Rickard or
>> Dan, I just know that Principal and Credential set on client are
>> attached to each method invocation. The Credential is Object, in
>> particular it can contain x.509 certificates obtained from a single
>> authentication server, or whatever else you want, not necessarily a
>> user password.
> Presumably the proxy classes the ones in org.jboss.proxy - "Proxy",
> "Proxies", "ProxyProxy" etc. (eek!)? Where (in which classes) do the
> Proxies and security stuff converge, so to speak :-). Or "where does
> the proxy insert the security information into the message" ?
Okay, I'll try to guess :-)
Probably it is done in
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker
in the lines
// Set the security stuff
rmi.setPrincipal( SecurityAssociation.getPrincipal() );
rmi.setCredential( SecurityAssociation.getCredential() );
>> Yes, you can decrease the network traffic by making server stateful,
>> but for me such schemes are either much more complicated or less
>> secure.
> Why do you think they are less secure?
Oh, don't pay much attention to these words. I said this about
schemes that I thought out myself, and there were less secure ones
among them :-)
>> IMHO the best alternative, which is worth implementing in JBoss is
>> SSL RMI connections.
>> With JAAS the authenticated pairs (username, credential) are cached,
>> so the validation is performed on the first call only.
>>
> Is this not effectively making the server stateful anyway, since the
> info is cached by JAAS?
Yes, I think so.
> Also, is the validity on subsequent invocations just an equality check?
Yes, search in a HashMap by principal, then call equals() on
credentials.
> For larger objects, such as certificates,
> presumably it would be nice to be able to chuck these away after the
> initial authentication and substitute a token or nonce or something?
I think it's possible.
> Even for passwords, it is probably better that the client doesn't
> maintain a copy locally for longer than necessary, rather than caching
> and sending it on each request.
I wouldn't recommend to send or store passwords "as is".
E.g. one use MD5 digest instead, which should be calculated on client.
Oleg
