1 2 3 4 Previous Next 50 Replies Latest reply on May 14, 2008 8:49 AM by anil.saldhana Go to original post
      • 30. Re: Security Injection in AS5
        starksm64

        You will have to specify that jar and related in the deployment classpath:

        <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="urn:jboss:bean-deployer:2.0 bean-deployer_2_0.xsd"
         xmlns="urn:jboss:bean-deployer:2.0">
        
         <classloader><inject bean="JBossSXClassLoader"/></classloader>
        
         <bean name="JBossSXClassLoader" class="org.jboss.system.NoAnnotationURLClassLoader">
         <classloader><null/></classloader>
         <constructor factoryClass="org.jboss.system.NoAnnotationURLClassLoader" factoryMethod="createClassLoader">
         <parameter>
         <array elementClass="java.net.URL">
         <!-- Deployers -->
         <value>${jboss.server.lib.url}/jbosssx.jar</value>
         </array>
         </parameter>
         </constructor>
         </bean>
        ...
        


        This is a brute force configuration. There should be a way to specify the class loader system that includes all the server libs as well as just naming the packages you want to import. We need to get that syntax documented.


        • 31. Re: Security Injection in AS5
          starksm64

          I'll double check today, but deployments in deploy should be seeing a default class loader that sees all of the server/lib jars. Are you sure this class is in the jbosssx.jar?

          • 32. Re: Security Injection in AS5
            starksm64

            Ok, so you should not have to set the class loader on the deployment because this will have one that has access to the server classes, but the problem here is that the custom schema for the wildcard bindng of the policyConfig property value is essentially annotation processing, not simple xml parsing or binding to classes that are part of the deployers known types. In general these classes can be part of the deployment which requires establishment of the deployment class loader. This problem is covered by this issue:

            http://jira.jboss.com/jira/browse/JBDEPLOY-32

            • 33. Re: Security Injection in AS5

              I've closed JBDEPLOY-32.

              * Even if I hacked the deployers such that some parsing deployers ran before/after
              the construction of the classloader
              (assuming I know which those should be - which I don't)

              * I hacked those parsing deployers that ran after the classloader deployer
              to run with deployment classloader

              * We fixed JBossXB to support it

              Its simply not correct.

              You should NOT be mixing runtime and metadata models in this way.

              There are many reasons why you should not mix.

              The most obvious is programmatic deployment where I don't want to include
              random implementation jars in a client just to create some metadata to deploy
              a security domain.

              Seperate the deployment model from the runtime and place it in deployers.

              • 34. Re: Security Injection in AS5
                anil.saldhana

                Separating the deployment model from the runtime in the case of DynamicLoginConfig means that the xml config that is getting injected into the beans needs to be moved out in to the deployers (parsing deployer ?). This means for an user to inject one instance of a security domain configuration (eg: messaging or JBossWS) into the security system will need to add the bean configuration in -beans.xml in the deploy directory and add a parsing deployer for his xml driving the sec.domain in the deployers directory.

                Is my understanding correct?

                • 35. Re: Security Injection in AS5

                  No, you don't need a seperate parsing deployer in this case
                  (you could have one if you wanted say a META-INF/security-policy.xml in any
                  deployment that automatically creates a security policy for the deployment).

                  What you do need is the metadata model (in this case your BeanMetaDataFactory)
                  available before it starts deploying the runtime, i.e. before anything in deploy is processed.

                  If you don't do that, then somebody adding a jbsx:policy
                  to their config, (e.g. jboss messaging or jca could do this)
                  may or may not be parsable based on whether the classes have been deployed
                  and the jbossxb config done.

                  In practice the classes will never be deployed since the initial bootstrap
                  does a breadth first parse of all config in the deploy before proceeding to create
                  classloaders (in the future when we move over to more locked down classloading
                  dependencies we'll need to know whether a deployment wants the ejb classes
                  first, i.e. does it have an ejb component).

                  • 36. Re: Security Injection in AS5
                    anil.saldhana

                    Stefan, I want to try out what Adrian is saying but do not have cycles this week. I am wondering if you can make an attempt at what he has suggested.

                    • 37. Re: Security Injection in AS5
                      anil.saldhana

                      Stefan, can you please post in detail as to what approach you are taking to solve this - BeanMetaDataFactory etc such that Adrian can comment on the approach. It is better to get pre-brocked to get it right in the end......

                      • 38. Re: Security Injection in AS5
                        sguilhen

                        Yes, I can.

                        What I want to achieve is what Adrian suggested in his first post in this thread:


                        make security domains deployable inside the MC by writing a BeanMetaDataFactory


                        <bean name="Whatever" ...>
                         <property name="securityDomain><inject name="jbossmq" property="securityDomain"/></property>
                        </bean>
                        
                        <application-policy xmlns="urn:jboss-security-beans:1.0" name="jbossmq">
                         <authentication>
                         <login-module code = "org.jboss.security.auth.spi.DatabaseServerLoginModule"
                         flag = "required">
                         <module-option name = "unauthenticatedIdentity">guest</module-option>
                         <module-option name = "dsJndiName">java:/DefaultDS</module-option>
                         <module-option name = "principalsQuery">SELECT PASSWD FROM JMS_USERS WHERE USERID=?</module-option>
                         <module-option name = "rolesQuery">SELECT ROLEID, 'Roles' FROM JMS_ROLES WHERE USERID=?</module-option>
                         </login-module>
                         </authentication>
                        </application-policy>
                        


                        I've started by taking a look at the aop-mc integration, as AOP had to define their beans and metadata factories to make it possible to use the aop elements in the -beans.xml files.

                        So I've created a module, security-mc-int under the microcontainer project (not sure it should be there, just using the same approach AOP has taken), defined the beans, defined the security-beans.xsd, and started the implementation of the metadata factory.

                        This factory is responsible for providing the metadata that is used to create the beans from the information parsed. An example of the beans that would result from the factory follows:

                        <bean name="jbossmq" class="org.jboss.security.microcontainer.beans.ApplicationPolicyBean>
                         <property name="authenticationPolicy"><inject bean="jbossmq$AuthPolicy"/></property>
                        </bean>
                        
                        <bean name="jbossmq$AuthPolicy" class="org.jboss.security.microcontainer.beans.AuthenticationPolicyBean">
                         <property name="loginModules">
                         <list>
                         <inject bean="jbossmq$LoginModule1"/>
                         <inject bean="jbossmq$LoginModule2"/>
                         </list>
                         </property>
                        </bean>
                        
                        <bean name="jbossmq$LoginModule1" class="org.jboss.security.microcontainer.beans.LoginModuleBean">
                         <property name="flag">required</property>
                         <property name="code">org.jboss.security.auth.spi.UsersRolesLoginModule</property>
                         <property name="moduleOptions">
                         <map keyClass="java.lang.String" valueClass="java.lang.String">
                         <entry>
                         <key>usersProperties</key>
                         <value>jboss-users.properties</value>
                         </entry>
                         <entry>
                         <key>rolesProperties</key>
                         <value>jboss-roles.properties</value>
                         </entry>
                         </map>
                         <property>
                        </bean>
                        
                        <bean name="jbossmq$LoginModule2" class="org.jboss.security.microcontainer.beans.LoginModuleBean">
                         <property name="flag">optional</property>
                         <property name="code">org.jboss.security.auth.spi.DataBaseServerLoginModule</property>
                         <property name="moduleOptions">
                         <map keyClass="java.lang.String" valueClass="java.lang.String">
                         <entry>
                         <key>principalsQuery</key>
                         <value>SELECT PASSWD FROM USERS WHERE USER_ID=?</value>
                         </entry>
                         <entry>
                         <key>rolesQuery</key>
                         <value>SELECT ROLE_ID, 'Roles' FROM ROLES WHERE USER_ID=?</value>
                         </entry>
                         </map>
                         <property>
                        </bean>
                        


                        The top-level ApplicationPolicyBean would, after being initialized, push the ApplicationPolicy to the security layer to register the new policy (along with the login modules configuration).

                        I still have to figure out a couple of things. First, can I add post-installation behavior to my beans just by implementing the install and uninstall methods or is it necessary to configure an aop lifecycle for that? Second, I don't expect things to magically happen just by defining the metadata factory. Somehow I must bind it to the schema being parsed (that is, somehow the MC must know which factory to use when facing an application-policy element).

                        • 39. Re: Security Injection in AS5
                          starksm64

                           

                          "sguilhen@redhat.com" wrote:

                          I've started by taking a look at the aop-mc integration, as AOP had to define their beans and metadata factories to make it possible to use the aop elements in the -beans.xml files.

                          So I've created a module, security-mc-int under the microcontainer project (not sure it should be there, just using the same approach AOP has taken), defined the beans, defined the security-beans.xsd, and started the implementation of the metadata factory.

                          Definitely does not belong under the microcontainer project. It belongs under the security project.

                          "sguilhen@redhat.com" wrote:

                          I still have to figure out a couple of things. First, can I add post-installation behavior to my beans just by implementing the install and uninstall methods or is it necessary to configure an aop lifecycle for that?

                          Just define create/start/stop/destroy methods as desired on the bean that should perform the setup.

                          "sguilhen@redhat.com" wrote:

                          Second, I don't expect things to magically happen just by defining the metadata factory. Somehow I must bind it to the schema being parsed (that is, somehow the MC must know which factory to use when facing an application-policy element).


                          Use the XmlRootElement/JBossXmlSchema to define the element name appearing in under the beans.xml deployment element and its namespace:
                          @JBossXmlSchema(namespace="urn:jboss:aop-beans:1.0", elementFormDefault=XmlNsForm.QUALIFIED)
                          @XmlRootElement(name="annotation-introduction")
                          public class AnnotationIntroductionBeanMetaDataFactory extends AbstractAnnotationBeanMetaDataFactory
                          {
                          
                           private static final long serialVersionUID = 1L;
                          
                           @Override
                           protected String getBeanClassName()
                           {
                           return AnnotationIntroduction.class.getName();
                           }
                          
                          }
                          


                          • 40. Re: Security Injection in AS5
                            anil.saldhana

                            It should go in AS/trunk/security module.

                            • 41. Re: Security Injection in AS5
                              sguilhen

                              Thanks Scott, the start/stop methods worked just fine.

                              I'm facing a problem with the security deployment now. I've written a test case to test the metadata factory and it is failing when the deployment annotations are processed.

                              Relevant code snippets:

                              1- ApplicationPolicyFactoryTestCase:

                              public class ApplicationPolicyFactoryTestCase extends MicrocontainerTest
                              {
                              
                               /**
                               *
                               * @param name
                               */
                               public ApplicationPolicyFactoryTestCase(String name)
                               {
                               super(name);
                               }
                              
                               @Override
                               protected void setUp() throws Exception
                               {
                               SingletonSchemaResolverFactory.getInstance().addJaxbSchema(
                               "urn:jboss:security-beans:1.0", "org.jboss.security.microcontainer.beans.metadata.SecurityDeployment");
                               super.setUp();
                               }
                               ....
                              }
                              


                              It calls the addJaxbSchema before deploying the test configuration file (later when I get this working I'll add the namespace directly in the SingletonSchemaResolverFactory).

                              2-ApplicationPolicyFactoryTestCase.xml
                              ?xml version="1.0" encoding="UTF-8"?>
                              
                              <deployment xmlns="urn:jboss:bean-deployer:2.0">
                              
                               <application-policy xmlns="urn:jboss:security-beans:1.0" name="TestPolicy">
                               <authentication>
                               <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required"/>
                               </authentication>
                               </application-policy>
                              </deployment>
                              


                              3- The SecurityDeployment (Similar to the AOPDeployment):

                              @JBossXmlSchema(namespace = "urn:jboss:security-beans:1.0", elementFormDefault = XmlNsForm.QUALIFIED)
                              @XmlRootElement(name = "policy")
                              @XmlType(propOrder = {"annotations", "classLoader", "beanFactories", "create", "start", "stop", "destroy", "aliases"})
                              public class SecurityDeployment extends AbstractKernelDeployment
                              {
                              
                               private static final long serialVersionUID = 1L;
                              
                               @Override
                               @XmlAnyElement
                               @XmlElements({@XmlElement(name = "application-policy", type = ApplicationPolicyBeanMetaDataFactory.class)})
                               public void setBeanFactories(List<BeanMetaDataFactory> beanFactories)
                               {
                               super.setBeanFactories(beanFactories);
                               }
                              }
                              


                              When I try to run the ApplicationPolicyFactoryTestCase, the setup() method fails when deploying the ApplicationPolicyFactoryTestCase.xml with the following error:

                              org.jboss.xb.binding.JBossXBException: Failed to parse source: file:/opt/workspace/Security-JBossSX/security-mc-int/target/test-classes/org/jboss/test/security/microcontainer/beans/ApplicationPolicyFactoryTestCase.xml@5,79
                               at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:177)
                               at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:139)
                               at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:147)
                               at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.deploy(MicrocontainerTestDelegate.java:294)
                               at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.deploy(MicrocontainerTestDelegate.java:438)
                               at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.setUp(MicrocontainerTestDelegate.java:83)
                               at org.jboss.test.AbstractTestSetup.setUp(AbstractTestSetup.java:63)
                               at org.jboss.test.AbstractTestCaseWithSetup.setUp(AbstractTestCaseWithSetup.java:103)
                               at org.jboss.test.kernel.junit.MicrocontainerTest.setUp(MicrocontainerTest.java:82)
                               at org.jboss.test.security.microcontainer.beans.ApplicationPolicyBeansTestCase.setUp(ApplicationPolicyBeansTestCase.java:59)
                               at junit.framework.TestCase.runBare(TestCase.java:125)
                               at junit.framework.TestResult$1.protect(TestResult.java:106)
                               at junit.framework.TestResult.runProtected(TestResult.java:124)
                               at junit.framework.TestResult.run(TestResult.java:109)
                               .....
                              Caused by: java.lang.RuntimeException: The type of the attribute whenRequired must be simple or complex with a value adapter: org.jboss.xb.binding.sunday.unmarshalling.TypeBinding@19113f8[null]
                              at org.jboss.beans.metadata.plugins.AbstractDependencyValueMetaData.whenRequiredState
                              at org.jboss.beans.metadata.plugins.AbstractConstructorMetaData.factory
                              at org.jboss.beans.metadata.plugins.AbstractBeanMetaData.constructor
                              at org.jboss.beans.metadata.plugins.AbstractClassLoaderMetaData.classLoader
                              at org.jboss.security.microcontainer.beans.metadata.SecurityDeployment.classLoader
                              at org.jboss.security.microcontainer.beans.metadata.SecurityDeployment
                              


                              This happens during the @XmlType annotation processing and I really don't know what I should do to avoid this problem. Any thoughts/ideas?

                              • 42. Re: Security Injection in AS5
                                alesj

                                Why does SecurityDeployment extend AbstractKernelDeployment?
                                All you need is ApplicationPolicyBeanMetaDataFactory to be registered (and properly annotated) with SingletonSchemaResolverFactory.

                                See this discussion:
                                - http://www.jboss.com/index.html?module=bb&op=viewtopic&t=132413&start=0

                                Or follow this test:
                                - http://anonsvn.jboss.org/repos/jbossas/projects/jboss-deployers/trunk/deployers-vfs/src/tests/org/jboss/test/deployers/vfs/xb/test/SchemaResolverXBTestCase.java

                                btw: the problem there is this:
                                - http://jira.jboss.com/jira/browse/JBXB-125
                                ;-)
                                In other words, non-simple/primitive objects require adapters to know how to marshal them. You are missing those in SecurityDeployment package - see AbstractKernelDeployment package for annotations. ;-)

                                • 43. Re: Security Injection in AS5
                                  sguilhen

                                  Thanks for the pointers, Ales ;-) I'll follow them!

                                  • 44. Re: Security Injection in AS5
                                    sguilhen

                                    Update on the metadata work:

                                    Following Ales' pointers I was able to come up with a clean implementation of the metadata factory that generates the beans responsible for the definition of an application policy.

                                    There are still a few details to address but I am ready to commit the code and work on the details later. As of now, it is possible to declare complete application policies and have them registered with the security layer:

                                    <deployment xmlns="urn:jboss:bean-deployer:2.0">
                                    
                                     <application-policy xmlns="urn:jboss:security-beans:1.0" name="TestPolicy1">
                                     <authentication>
                                     <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required"/>
                                     </authentication>
                                     <authorization>
                                     <policy-module code="org.jboss.security.authz.AuthorizationModule" flag="required">
                                     <module-option name="authzOption">authz.value</module-option>
                                     </policy-module>
                                     </authorization>
                                     <identity-trust>
                                     <trust-module code="org.jboss.security.trust.IdentityTrustModule" flag="required">
                                     <module-option name="trustOption1">trust.value1</module-option>
                                     <module-option name="trustOption2">trust.value2</module-option>
                                     </trust-module>
                                     </identity-trust>
                                     <audit>
                                     <provider-module code="org.jboss.security.audit.AuditModule">
                                     <module-option name="auditOption">audit.value</module-option>
                                     </provider-module>
                                     </audit>
                                     <rolemapping>
                                     <mapping-module code="org.jboss.security.mapping.RoleMappingModule">
                                     <module-option name="mappingOption1">mapping.value1</module-option>
                                     <module-option name="mappingOption2">mapping.value2</module-option>
                                     </mapping-module>
                                     </rolemapping>
                                     </application-policy>
                                     ....
                                    </deployment>
                                    


                                    JASPI authentication policies can also be declared:

                                     <application-policy xmlns="urn:jboss:security-beans:1.0" name="TestPolicy1">
                                     <authentication-jaspi>
                                     <login-module-stack name="ModuleStack1">
                                     <login-module code="org.jboss.security.auth.StackModule1" flag="required">
                                     <module-option name="stackOption1">stack1.value1</module-option>
                                     </login-module>
                                     <login-module code="org.jboss.security.auth.StackModule2" flag="option"/>
                                     </login-module-stack>
                                     <login-module-stack name="ModuleStack2">
                                     <login-module code="org.jboss.security.auth.StackModule1" flag="required">
                                     <module-option name="stackOption1">stack2.value1</module-option>
                                     <module-option name="stackOption2">stack2.value2</module-option>
                                     </login-module>
                                     </login-module-stack>
                                     <auth-module code="org.jboss.security.auth.AuthModule" login-module-stack-ref="ModuleStack1">
                                     <module-option name="authOption1">auth.value1</module-option>
                                     <module-option name="authOption2">auth.value2</module-option>
                                     </auth-module>
                                     </authentication-jaspi>
                                     </application-policy>
                                    


                                    There are a few tests (I'll be working on improving the tests) that run in standalone mode and those tests add, at runtime, a binding for the security-policy schema into the SingletonSchemaResolverFactory in the setUp method. For this code to work in the AS we need add this binding permanently to XB and update the AS to use a new release of XB. I've opened a thread in the JBossXB forum to address this issue.