What is this?

These are my notes about an EDS install we did at Nike, in which the desired behavior was:

1) Control access to data / VDBs through the -users.properties and -roles.properties files.

2) Controll access to EDS administration through membership in a group (and of course the right password) in the corporate LDAP server.

It took a lot more work than I expected.

Step 1 - Configure access to data / VDBs through the -users.properties and -roles.properties files.

This part involves setting data access and passwords

vi conf/props/teiid-security-*

conf/props/teiid-security-users.properties

# A users.properties file for use with the UsersRolesLoginModule

# username=password

#user=password

data_user_1=password_1

data_user_2=password_2

# A roles.properties file for use with the UsersRolesLoginModule

# username=role1,role2

data_user_1=user,custom_app_1_user

data_user_2=user,custom_app_2_user

The user role grants access to unsecured VDBs.  Each application team can set their own security constraints on their VDBs, by using the custom_app_1_ user or custom_app_2_user roles in the VDB security settings.

Step 2 - Setting up LDAP auth/auth for administration

Step 2-A) Adding the Corporate CA Certificate to the List of Trusted Certificates

In this case, we needed to include a corporate certificate authority's certificate in the list of trusted certs, so that the LDAP client in EDS would trust the certificate being used by the corporate LDAP server.

• Get the new CA certificate. Check with LDAP administration team to ensure this process will fetch a new certificate (not an expiring one).
• Name it certnew.cer.

• Verify that the certificate will not expire soon. On the EDS server:
1. View the contents of the new CA certificate.

   > cd ${JAVA_HOME}/jdk160_amd64/jre/bin

   > ./keytool -printcert -file <path-to>/certnew.cer

   ...

   Valid from: Fri Sep 31 00:00:00 CDT 2007 until: Fri Sep 31 00:00:00 CDT 2022

   ...

2. Examine the “valid from…until” date and ensure it is accurate.
• Add the new CA certificate to the EDS JVM certificate chain.
• On the MetaMatrix server:

  > ./keytool –delete –keystore ../lib/security/cacerts –alias corporate.ca.cert

  Enter keystore password:

  [enter changeit - except you've changed this password, right?]

  > ./keytool -import -keystore ../lib/security/cacerts -alias corporate.ca.cert -file <path-to>/certnew.cer

  Enter keystore password:

  [enter changeit]

  Trust this certificate? [no]: yes

  Certificate was added to keystore

• Restart the EDS Server. The new certificate is now in use.

Step 2-B) Including LDAP Authentication in the JAAS Configuration

Now configure JBoss to use LDAP authentication, but editing conf/login-config.xml

Replace the default jmx-console entry - this is the one that controls not just the jmx-console, but also EDS administration. The default entry looks like this:

   <application-policy name="jmx-console">

      <authentication>

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

            <module-option name="usersProperties">props/soa-users.properties</module-option>

            <module-option name="rolesProperties">props/soa-roles.properties</module-option>

         </login-module>

      </authentication>

   </application-policy>

This new entry should look like this - replacing the bits in bold with approriate values. It does three things.

• First, ensure that the admin userID and password used to start and stop the server (and ping the JMX console) is taken from the properties files (you can change this if you want, but we kept it here)
• Second, authenticate against the corporate LDAP for all users not found in soa-users.properties.
• Finally, map roles from the LDAP group names to role names meaningful in JBoss EDS.

   <application-policy name="jmx-console">

      <authentication>

         <!-- This allows the start and script and twiddle scripts to work.  Keep it here. YOU HAVE UPDATED THE PASSWORDS IN HERE RIGHT? -->

         <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="sufficient">

            <module-option name="usersProperties">props/soa-users.properties</module-option>

            <module-option name="rolesProperties">props/soa-roles.properties</module-option>

         </login-module>

         <!-- Use LDAP for most connections -->

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

            <!-- USE THIS FOR REAL <module-option name="java.naming.provider.url">ldaps://ldap.corporation.com:636</module-option> -->

            <module-option name="java.naming.provider.url">ldap://ldap.corporation.com</module-option>

            <module-option name="bindDN">LDAP_CLIENT_USER</module-option>

            <module-option name="jaasSecurityDomain">jboss.security:service=JaasSecurityDomain,domain=jmx-console</module-option>             

            <module-option name="bindCredential">OBSCURED-PASSWORD</module-option><!-- See 2-D Below -->

            <module-option name="baseCtxDN">OU=All Users,DC=ad,DC=corporation,DC=com</module-option>

            <module-option name="baseFilter">(sAMAccountName={0})</module-option><!-- Read up on LDAP if this dosn't make sense -->

            <module-option name="rolesCtxDN">OU=All Users,DC=ad,DC=corporation,DC=com</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="searchScope">ONELEVEL_SCOPE</module-option>

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

            <module-option name="allowEmptyPasswords">false</module-option><!-- Very important! If this is true, passwords are not checked if they are not provided! -->

            <module-option name="defaultRole">user</module-option>

         </login-module>

         <!-- Map the AD Groups/Roles to meaningful JBoss roles -->

         <login-module code="org.jboss.security.auth.spi.RoleMappingLoginModule" flag="optional">

            <module-option name="rolesProperties">props/ldap-eds-rolemapping.properties</module-option>

         </login-module>

      </authentication>

  </application-policy>

This allows either access through one of the userid/password combinations contained in soa-users.properties (with roles as defined in soa-roles.properties), or, if that fails, then control is passed on to the LDAP module. Finally, the RoleMappingModule allows conversion of LDAP roles into roles that are meaningfull to JBoss, as specified in the ldap-eds-rolemapping.properties file:

Step 2-C) Mapping LDAP Roles to JBoss Roles

cat conf/props/ldap-eds-rolemapping.properties

# Map the Corporate Active Directory Role to a meaningful JBoss role

Application.EDS.Admins=JBossAdmin

You will probbaly have a different group name than Application.EDS.Admins, so put your LDAP group name in. Members of this group will be able to administer the EDS server.

Step 2-D) Obscuring the LDAP Password

Finally, protect the password, following the instructions at

http://docs.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/5/html/Security_Guide/Using_LdapExtLoginModule_with_JaasSecurityDomain.html

with the note about adding a the depends element from

http://community.jboss.org/message/137756#137756

Note also, the salt must be 8 chars.

Specifically, added the following to conf/jboss-service.xml:

   <!-- Used to decrypt the ldap password -->

   <mbean code="org.jboss.security.plugins.JaasSecurityDomain"

          name="jboss.security:service=JaasSecurityDomain,domain=jmx-console">

      <constructor>

         <arg type="java.lang.String" value="jmx-console"></arg>

      </constructor>

      <attribute name="KeyStorePass">YourPAsswordGoesHere</attribute>

      <attribute name="Salt">8chrSALT</attribute><!-- put your own 8 character salt here - how about Snow White and the Seven Dwarfs -->

      <attribute name="IterationCount">63</attribute><!-- Some people like different numbers here. Vive la difference! -->

      <depends optional-attribute-name="ManagerServiceName">jboss.security:service=JaasSecurityManager</depends>

   </mbean>

Restart the server.

And then go to the jmx-console (using the admin userID and password defined in conf/props/soa-users.properties)

Go to "jboss.security" on the left, and then  select "domain=jmx-console,service=JaasSecurityDomain"

Go to the bottom of the screen, and enter the plantext password as the parameter to the encode64 method.  The resulting screen gives you the encrypted password to put in login-config.xml:

            <module-option name="jaasSecurityDomain">jboss.security:service=JaasSecurityDomain,domain=jmx-console</module-option>

            <module-option name="bindCredential">OBSCURED-PASSWORD-GOES-HERE</module-option>

Restart one last time, and everything should work.