We need to get away from usernames and passwords in the config files. I'm thinking the resource adapators should be associated with a security domain the same as ejbs and web content. A security domain is an MBean(org.jboss.security.plugins.JaasSecurityDomain in security) and an interface(org.jboss.security.SecurityDomain in server)
I would call impersonation propagation of the current caller as your relying on identity and credentials previously submitted. These can be obtained from the current authenticated Subject. Principal mapping would be the result of executing a JAAS login against the security domain for the resource adapator. This would execute the mapping login modules for that domain and augment the current authenticated Subject with the resource adaptor mapped credentials. I'll have to go over the JCA spec JAAS usage examples again to see what if any policy is recommended. ----- Original Message ----- From: "David Jencks" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, January 05, 2002 1:25 PM Subject: [JBoss-dev] Where to put Principal Mappings for resource adapters? > --RH 3.0 only-- > > I want to implement the other 2 principal mappings we need for resource adapters -- impersonation (using the j2e logon as the adapter login) and mapping (mapping the j2ee logons to more than one adapter login) (I think I got the names right ;-)) > > Scott mentioned a while back that he wanted to move these security aspects out of the connector code and into the security domain. > > So, I'm wondering how to proceed. The simplest solution I have thought of is to make the principal mapper an mbean separate from a ConnectionFactoryLoader, and include a (depends) reference in the ConnectionFactoryLoader to the PrincipalMapping mbean it needs. > > So the configuration would look like this: > > <mbean code="org.jboss.resource.ConnectionFactoryLoader"...> > ... > <depends optional-attribute-name="PrincipalMapping">jboss.security:name=myPrincipalMa pping</depends> > </mbean> > > and one of > > <mbean code="org.jboss.resource.security.ManyToOnePrincipalMapping" name="jboss.security:name=myPrincipalMapping"> > <attribute name="UserName">me</attribute> > <attribute name="Password">MySecret</attribute> > </mbean> > > or > > <mbean code="org.jboss.resource.security.ImpersonationPrincipalMapping" name="jboss.security:name=myPrincipalMapping"> > </mbean> > > or > <mbean code="org.jboss.resource.security.ExplicitPrincipalMapping" name="jboss.security:name=myPrincipalMapping"> > <attribute name="Mapping"><mapping> > <mapping-element j2ee-name="joe"> > <user-name>me</user-name> > <password>MySecret</password> > </mapping-element> > <mapping-element j2ee-name="fred"> > <user-name>me</user-name> > <password>MySecret</password> > </mapping-element> > <mapping-element j2ee-name="steve"> > <user-name>you</user-name> > <password>yourSecret</password> > </mapping-element> > </mapping> > </attribute> > </mbean> > > > Any comments? Is there a better way to do this? Is there any chance someone would use an explicit map like this with all the resource passwords in a plain text file? Where else could they come from? Does the jaas spec explain enough about Kerberos in java to make implementing that reasonably straightforward? > > Thanks > david jencks > > ______________________________________________________________________ > View this jboss-dev thread in the online forums: > http://jboss.org/forums/thread.jsp?forum=66&thread=6703 > > _______________________________________________ > 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
