On 2002.02.22 14:50:00 -0500 [EMAIL PROTECTED] wrote: > 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).
Can you be more specific about what the problem is here? I'd like to look at your adapter. I've been working (very slowly) on how to hook up the ConnectionManager to JAAS. > > 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). > I think this is what I am working on. I've written a new implementation of ConnectionManager that implements quite a bit more of the required functionality and does pooling in (IMHO) a simpler, more pluggable, and more bug-free way. Hooking up to security is the largest incomplete part. david jencks > > > >> 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 > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
