well I'm not Scott, but I've been working on security for a client. This
probably belongs on one of the forums but here are a few answers.
Yes the password is sent clear text.
Yes you can use encryption or ssl to protect yourself.
Yes it is sent every Invocation.
For the rmi, look at the MethodInvocation class for jboss 2.4.x or
Invocation for jboss 3.
On this subject I would like to propose a few things:
For JBoss 2.4.x (I haven't tested on JBoss 3 yet), the logout doesn't do
anything (really).
Scenario:
A client connects, logs in, does a remote invocation, is validated, gets a
return, logs out, exits. The client again starts up, logs in, does a remote
invocation, OK... here it isn't really validated again it is pulled out of
the cache, no password validation, no new roles if they exist. Of course
this is because of the cache. And I want the cache as long as the client is
still logged in under the same "session". The consequence of this is that
after a person logs in, and until the cache times out, anyone can
impersonate that user all he has to know is the userid. (no special password
required)
I would like to see a token that is sent with the Invocation that is set
when the server actually authenticates a user. It is returned to the client
and is re-sent every time the client does a remote invocation. UNTIL... the
client logs out or exits of course.
Next Invocation after a logout or re-login, the Invocation is naked ;)
(doesn't have a token), without the token the server knows to invalidate his
cache and re-authenticate.
Scott, any thoughts?
Ken
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, February 22, 2002 12:26 PM
Subject: [JBoss-dev] JBossMQ and JAAS
> Hi all, but mostly Scott I guess ;-)
> I am experimentally adding JAAS support for JBossMQ to handle
> autentication and autorization. And I have some problem with how to
> propagate and keep the principall around for the rmi and jvm invokation
> layers (for OIL and OUL it seems easy beacuse you can use ThreadLocals
> on the server side). Both the rmi and jvm are however stateless and are
> represented by only one object each and no thread they personally own.
>
> I tried to look at the documentation for how to set up a JAAS aware
> client, and then looked somewhat into the proxy, jrmp and
> SecurityInterceptor code, and guess what, it looks to mee as we are
> sending both the principall and the credentials on every invokation, and
> also does an authentication (although mostly against the cache) on every
> invokation. Is this so?
>
> If it is so, is this really good?
>
> - Sending a possible clear text password on every invokation?
> - Having to digest the credentialls on every invokation?
>
> If I am wrong (I sort of hope I am), could anyone explain to me how the
> principal is propagated over rmi from the client.
>
> Hiram and I have sort of discussed saving a hashed key in the connection
> token for JMS which could represent a principal, but would that be good
> practice?
>
> For the JVM invoker (which is only ever used inside the same VM as
> JBoss9, do you think it would be a good aproximation to say that a
> connection and its child object will allways be accessed by the same
> context classloader that created it (in that case we could use
> ContextClassLocal - yes, same as for ThreadLocal, but with classloader
> as hashkey instead)?
>
> //Peter
> --
> ------------------------------------------------------------
> Peter Antman Technology in Media, Box 34105 100 26 Stockholm
> Systems Architect WWW: http://www.tim.se
> Email: [EMAIL PROTECTED] WWW: http://www.backsource.org
> Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942
> ------------------------------------------------------------
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
