On 22 Feb, David Jencks wrote:
> On 2002.02.22 14:50:00 -0500 [EMAIL PROTECTED] wrote:
[...]
>> (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.
I will try to pack it up and send it to you.
>>
>> 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.
It's been a while since I worked with it, but I basically did this
(following appendix c - i think - in the JCA spec):
- A JCA RA should provide its own LoginLodule.
- This has to be manually added to auth.conf (or perhaps mor preferably
the xml version of Scott's making.
- The JCA RA specific LoginLodule will save the data it needs to use
later to continue to autenticate the user in specific parts of the
Subject (private credentials).
- I wrote code for my DirCtx to use the same baseclasses to do
autentication both in the LoginLodule and in the ra.
- Next I nedded to get the currentActive subject to be sent to the ra
during connections. I did this by modifying the
ConnectionFactoryLoader and JBossResourceSubjectFactory and having a
SubjectResourceSubjectFactory, which uses the active subject:
public Subject getSubject(ManagedConnectionFactory mcf, String cmName)
{
// For now we go for the Subject directly
// How do we get at the security domain??
try {
return getActiveSubject();
}catch(NamingException ex) {
category.error("Could not get the active subject");
}
return null;
}
private Subject getActiveSubject() throws NamingException{
try {
String domain = null;
InitialContext iniCtx = new InitialContext();
Context securityCtx = (Context) iniCtx.lookup("java:comp/env/security");
JaasSecurityManager securityMgr = (JaasSecurityManager )
securityCtx.lookup("securityMgr");
domain = securityMgr.getSecurityDomain();
Subject s = (Subject) iniCtx.lookup("java:jaas/" + domain+"/subject");
category.debug("Returning active subject " + s);
return s;
}catch(Exception ex) {
NamingException ne = new NamingException("Could not get current security
domain: " + ex.toString());
ne.setRootCause(ex);
throw ne;
}
}
For the ldap/dirCtx stuff, this means that the credentiall will allways
be saved and ne available. At the time I though Scott considered this a
verry bad idea. But now I can see that it is much worse than the
password beeing sent in cleartext in every RMI invokation (if using JAAS
and clear text passwords that is).
I don't think I really solved having a unifyed configuration either,
partly because the auth.conf loading is (if I remember correct) verry
much static and hard to override.
I will send you the code, I we may continue the discussion if you want
to.
//Peter
>
> 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
--
------------------------------------------------------------
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
