On 2002.05.02 15:31:18 -0400 Scott M Stark wrote: > Right now resource adaptor security is being configured > independent of the user. Just the examples are. There is also a CallerIdentityLoginModule that basically adds a PasswordCredential with the existing user/pw + the appropriate ManagedConnectionFactory. I haven't tried it... I think it is set up to look up the user/pw in another security domain, but now that you mention it it should probably get the user/pw from shared state...
In fact we should be able to put the ConfiguredIdentityLoginModule in an existing domain, it will just add the PasswordCredential. A more typical setup is one > security domain with a chain of login modules that associate > all of the user security information with the user's Subject. Why? > What if I want to encrypt the transport channel used by the > resource adaptor and I need the user's X509 cert to do this. I > think when we setup a secured resource adaptor we should be > configuring how to obtain the required security information from > the current caller's security context, not setting up independent > security > domains that duplicate security subsets. We need to think about > the problem from the perspective of administering a user's security > information and having that single viewpoint of possibly federated > security context propagate to the secured contexts that need it. Yes. Now I see why you are worried about calling flush on the cache;-) david jencks > > ----- Original Message ----- > From: "David Jencks" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, May 02, 2002 12:02 PM > Subject: Re: [JBoss-dev] Does JaasSecurityManager need flushCache method? > (jboss 3) > > > > On 2002.05.02 14:22:49 -0400 Scott M Stark wrote: > > > Then we may need to think about more loosely coupling authorization > > > information from the authenticated Subject through some indirection > > > mechanism. A PasswordCredential is really an attribute of the > > > authenticated > > > Subject that may not have any relation to the credentials used to > > > authenticate the Subject. Multiply this across all of the resources > the > > > Subject > > > interaces with and you get the restart of a single resource adaptor > > > flushing > > > the > > > entire state of the Subject and this is too coarse grained. > > > > I'm confused about this. I thought there was a Subject per security > > domain/ realm listed in auth-conf.xml. If so, I don't think the > current > > flushing behavior is inappropriate since with the current setup each > > ConnectionManager gets its own realm, so you will only be flushing the > > actually out of date subjects. Let me know if I am wrong about this, I > > don't understand much about Subject boundaries and haven't been fixing > bugs > > with jboss running secured. > > > > thanks > > david jencks > > > > > > > > > > > > Caching is not part of any of the manifest security manager > related > > > > > interfaces > > > > > so there is not a single reference you can obtain short of going > to > > > the > > > > > org.jboss.security.plugins.JaasSecurityManager object which is > not a > > > good > > > > > idea. > > > > > In what circumstances do you flush the cache? This should really > not > > > be > > > a > > > > > framework level event. > > > > > > > > The jca PasswordCredential includes an object reference to the > > > > ManagedConnectionFactory it is for. When a ConnectionManager is > > > stopped > > > > and restarted, you get a different ManagedConnectionFactory > instance. > > > The > > > > only way I have found to make sure that subsequent logins get the > new > > > > reference is to flush the cache. I'm using mbean notifications > from > > > the > > > > ConnectionManager mbean to the login module to tell the login > module > > > its > > > > ManagedConnectionFactory reference is outdated, but that doesn't do > > > > anything to the cached Subject. > > > > > > > > thanks > > > > david jencks > > > > > > > > > > > > _______________________________________________________________ > > > > > > Have big pipes? SourceForge.net is looking for download mirrors. We > > > supply > > > the hardware. You get the recognition. Email Us: > > > [EMAIL PROTECTED] > > > _______________________________________________ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > _______________________________________________________________ > > > > Have big pipes? SourceForge.net is looking for download mirrors. We > supply > > the hardware. You get the recognition. Email Us: > [EMAIL PROTECTED] > > _______________________________________________ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > _______________________________________________________________ > > Have big pipes? SourceForge.net is looking for download mirrors. We > supply > the hardware. You get the recognition. Email Us: > [EMAIL PROTECTED] > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
