On 22 Feb, Scott M Stark wrote: >> 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? >> > Yes. > >> 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? >> > This is the stateless web model. ?
Not if you have a standalone client. The its should be the stateless RMI model, or what? > You either have to invoke transport > level encryption, use finer grained encryption on the sensitive info, > or use some opaque transient session key created using a public key > exchange algorithm. Transport encryption can be expensive, or it can > be free if you have a network that supports TLS at the ethernet card > level like Intel does. The more I think about it, we could start by using a simple session mechanism. I have to think about how to make this not to uncompatible with other auth mechanism then clear text passwords. > >> 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. >> > By infecting the smart proxy layer obtained from the JNDI home > lookup with the credential information established by the JAAS login. > >> 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? >> > David and I have discussed using the JCA facilities for this. Security > implementation has to move out of JBossMQ and into the security > manager layer. If you want to maintain a usable security model independent > of the JBoss server core, then we have to come up with a pluggable > model that will work with security through JCA. Let's start discussing > this. > This includes a lot of stuff. (Do you remember our discussions earlier about this. I did infact implement a DirContext impelementation and a DirContext JCA adapter wich plugged in both as a JAAS LoginModule and made it easy to access user data through current subject and the DirContext JCA adapter. However I never committed this, since the DirContext implementation was and it not based on JBoss naming. I also had to make changes to core JBoss classes to make this work, and still have problem with the pool implementation wich does not handle when a resource adapter fails because of autentication failoure (if configured to wait hard it hangs forever, if not it leaks connections). 1. I plan to implement the JMS security stuff much the same as the SecurityInterceptor works. I have made I a first version of an interceptor layer for JBossMQ where a security interceptor can be pluged in . No JCA stuff needed here actually. 2. JCA (perhaps) commes in if we raise the question: should current principal or subject be propagated when opening a JMS connection. I.e, you obtain a ConnectionFactory in an EJB (through JCA or not), if you do not use a userid/pwd should the principal/subject be propagated. Probably yes. 3. Coordinating JCA and LoginModule, so that they use the same configuration, or perhaps more correct: for a particular JCA we could JAAS to use it for autentication. As I said above, this does not work with the current JBoss code base, at least not in 2.4, but it is possible to fix (and really nice to use). >> 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)? > To do what? Well, a connection hold in vm may possibly be used by different threads, but the connection should, in case it was started with userid/pwd, hold ontoit itself, and it ought to be the "server" side that does this. Instead of relying on a thread local as in SecurityAssociation and the security manager (for subject), we could perhaps store the subject in ClassContextLocal storage. But I am reallt not shure about this now. //Peter > > > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development -- ------------------------------------------------------------ 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
