Right now resource adaptor security is being configured independent of the user. 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.
----- 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
