Please note that giving someone access to Guvnor indicates a level of trust. Being able to editing and build rules is providing a great deal of power to a user. Thus you should not open up Guvnor to your entire organization - but instead to a select few. Use https (http with TLS/SSL) where ever possible, even internally in a company network this is a good idea. Use this power wisely - this not a "run of the mill" application that provides read/write access to a database, but something much more power. Just imagine you are spider man - with great power comes great responsibility (of course even more so for super man).

Security is configured by using the beans.xml file in the war file. To customize this, you will need to unzip the WAR file, and locate the beans.xml file which is in the WEB-INF directory.

The JAAS standard is used as the underlying authentication and authorization mechanism, the upshot of which means its very flexible and able to integrate into most existing environments.

Out of the box, Guvnor shows a login screen, but no security credentials are enforced - the user name is used, but no password check is performed. To enforce authentication, you need to configure it to use an appropriate user directory, you may have Active Directory or similar already.

In the beans.xml file, you should located a security configuration section like the following:

  <security:IdentityImpl>

    <s:modifies/>



    <!-- No real authentication: demo authentication for demo purposes -->

    <security:authenticatorClass>org.drools.guvnor.server.security.DemoAuthenticator</security:authenticatorClass>



    <!-- JAAS based authentication -->

    <!--<security:authenticatorName>jaasAuthenticator</security:authenticatorName>-->



    <!-- IDM based authentication (supports LDAP, see Seam 3 and PicketLink IDM documentation) -->

    <!--<security:authenticatorClass>org.jboss.seam.security.management.IdmAuthenticator</security:authenticator>-->

  </security:IdentityImpl>

As you can see from above, the 2 "out of the box" options are pass through - which means any user is allowed in, or bypassed, in which case there is no login screen (e.g. you may be securing access to the app via a web server anyway).

<security:identity authenticate-method="#{authenticator.authenticate}"

   jaas-config-name="other"/>

<application-policy name="brms">

   <authentication>

      <login-module code="org.jboss.security.auth.spi.LdapExtLoginModule" flag="required" >

         <!--

            Some AD configurations may require searching against

            the Global Catalog on port 3268 instead of the usual

            port 389.  This is most likely when the AD forest

            includes multiple domains.

         -->

         <module-option name="java.naming.provider.url">ldap://ldap.jboss.org:389</module-option>

         <module-option name="bindDN">JBOSS\someadmin</module-option>

         <module-option name="bindCredential">password</module-option>

         <module-option name="baseCtxDN">cn=Users,dc=jboss,dc=org</module-option>

         <module-option name="baseFilter">(sAMAccountName={0})</module-option>



         <module-option name="rolesCtxDN">cn=Users,dc=jboss,dc=org</module-option>

         <module-option name="roleFilter">(sAMAccountName={0})</module-option>

         <module-option name="roleAttributeID">memberOf</module-option>

         <module-option name="roleAttributeIsDN">true</module-option>

         <module-option name="roleNameAttributeID">cn</module-option>



         <module-option name="roleRecursion">-1</module-option>

         <module-option name="searchScope">ONELEVEL_SCOPE</module-option>

      </login-module>

   </authentication>

</application-policy>