Oleg Nitz wrote:
>
> > 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() );
>
Ah, OK thanks, I'll have a look. I seem to remember that Rickard has
written a book on rmi, so I might get hold of that too - I was
reasonably familiar with IIOP, but don't know squat about RMI.
> >> 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 :-)
>
OK. I'll pretend I never heard/saw them :-).
>
> > Is this not effectively making the server stateful anyway, since the
> > info is cached by JAAS?
> Yes, I think so.
>
OK, things are becoming a bit clearer (I think) - I was a bit confused
by the idea of a totally stateless server and the client apparently
re-authenticating on each request. So when Marc said "JBoss doesn't
remember squat" was he really saying "JBoss doesn't remember squat....
but it gets its pal JAAS to remember for it " :-)?
> > 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.
This is true for storage, but the problem is that if you use the hash
for authentiation as well, then you suffer from the classic "hash is as
good as the password" syndrome (or whatever it's called) - i.e. if you
send the hash in order to authenticate the user, then an attacker only
has to obtain the hash to be able to impersonate the real user. If you
have to authenticate with the password, but store the hashe (or a
salted variant) in your security database, then the server can
calculate the hash of the supplied password and compare, but the hash
by itself is useless to the attacker. Using a session token means that
you are only passing information that has a short term validity so is
less important if it is compromised.
I'll have a look at the code when I get a chance and see if I can
understand some of it - writing web applications for beer-selling** web
sites is getting to be pretty boring and I could use the distraction.
cheers,
Luke.
P.S. ** The site is at:
http://www.bestbuybeer.com/bestbuy/poweredBy.html. It's very quiet at
the moment, so I wouldn't tout it as a reference site for JBoss's
scalability, but it's running quite happily at the back and I've been
very pleased with it so far. There is a lot of scope for improvement in
the application design but it's my first attempt at using EJB in
practice so I was glad to find jboss was so easy to use (not having to
compile server-specific stubs is only one example) and that the mailing
lists were so full of useful in-depth advice.
--
Luke Taylor.
PGP Key ID: 0x57E9523C
