8.3. Kerberos Support: Remote Connection

Procedure 8.2. Configure Kerberos for Remote Connection

1. Define the security domain

   Now we need to define a security domain for krb5-domain.
   Since Kerberos cannot define authorization roles, it relies on authorization provided by the teiid-security domain. The following example uses the UsersRolesLoginModule for this purpose.

   Note

   This configuration replaces the default JBoss Data Virtualization login configuration, and you should change the principal and keyTab locations accordingly.

     <security-domain name="krb5-domain">
       <authentication>
           <login-module code="Kerberos" flag="required">
               <module-option name="storeKey" value="true"/>
               <module-option name="useKeyTab" value="true"/>
               <module-option name="principal" value="dv/my.host.com@EXAMPLE.COM"/>
               <module-option name="keyTab" value="/path/to/krb5.keytab"/>
               <module-option name="doNotPrompt" value="true"/>
               <module-option name="debug" value="false"/>
           </login-module>
       </authentication>
   </security-domain>
   <security-domain name="EXAMPLE.COM">
      <authentication>
         <!-- Check the username and password -->
         <login-module code="SPNEGO"  flag="requisite">
            <module-option name="password-stacking" value="useFirstPass"/>
            <module-option name="serverSecurityDomain" value="krb5-domain"/>
         </login-module>
         <!-- Search for roles -->
         <login-module code="UserRoles" flag="required">
            <module-option name="password-stacking" value="useFirstPass"/>
            <module-option name="usersProperties" value="file://${jboss.server.config.dir}/spnego-users.properties"/>
            <module-option name="rolesProperties" value="file://${jboss.server.config.dir}/spnego-roles.properties"/>
         </login-module>
      </authentication>
   </security-domain>

   Copy to Clipboard Toggle word wrap
2. You can add following combination VDB properties in the vdb.xml file to select or force the security-domain and authentication type:

   <property name="security-domain" value="EXAMPLE.COM"/>
   <property name="gss-pattern" value="{regex}" />
   <property name="password-pattern" value="{regex}" />
   <property name="authentication-type" value="GSS or USERPASSWORD" />
   		

   Copy to Clipboard Toggle word wrap
   All the properties above are optional on a VDB. If you want to define VDB based security configuration "security-domain" property is required. If you want to enforce single authentication type use "authentication-type" property is required. If your security domain can support both GSS and USERPASSWORD, then you can define "gss-pattern" and "password-pattern" properties, and define a regular expression as the value. During the connection, these regular expressions are matched against the connecting user's name provided to select which authentication method user prefers. Here is a sample configuration:

   		
   <property name="security-domain" value="EXAMPLE.COM"/>
   <property name="gss-pattern" value="logasgss" />
   				

   Copy to Clipboard Toggle word wrap
   In this case, if you passed the "user=logasgss" in the connection string, then GSS authentication is selected as login authentication mechanism. If the user name does not match, then default transport's authentication method is selected. Alternatively, if you want choose USERPASSWORD like this:

   		
   <property name="security-domain" value="EXAMPLE.COM"/>
   <property name="password-pattern" value="*-simple" />
   

   Copy to Clipboard Toggle word wrap
   If the user name is "mike-simple", then that user will be subjected to authenticate against USERPASSWORD based authentication domain. You can configure different security-domains for different VDBS. VDB authentication will no longer be dependent upon underlying transport. If you wish to use "GSS" all the time then use this configuration:

   	
   <property name="security-domain" value="EXAMPLE.COM"/>
   <property name="authentication-type" value="GSS" />
   

   Copy to Clipboard Toggle word wrap

3. Edit JVM configuration

   Edit the EAP_HOME/bin/MODE.conf file and add the following JVM options (changing the realm and kdc settings according to your environment):

   JAVA_OPTS = "$JAVA_OPTS -Djava.security.krb5.realm=EXAMPLE.COM -Djava.security.krb5.kdc=kerberos.example.com -Djavax.security.auth.useSubjectCredsOnly=false"

   Copy to Clipboard Toggle word wrap
   You can also add these properties to the standalone.xml file, right after the {extensions} segment:

   	
   <system-properties>
       <property name="java.security.krb5.conf" value="/pth/to/krb5.conf"/>
       <property name="java.security.krb5.debug" value="false"/>
       <property name="javax.security.auth.useSubjectCredsOnly" value="false"/>
   </system-properties>
   

   Copy to Clipboard Toggle word wrap

4. Set the security domains

   There are two ways to do this. You first option is to define one default authentication per transport:

   <transport name="jdbc" protocol="teiid" socket-binding="teiid-jdbc"/>
   <authentication security-domain="EXAMPLE.COM" type="GSS"/>
   </transport>

   Copy to Clipboard Toggle word wrap
   Your second option is to secure only one virtual database:

   <property name="security-domain" value="EXAMPLE.COM"/>
   <property name="authentication-type" value="GSS" />
   

   Copy to Clipboard Toggle word wrap

5. Restart the server

   Restart the server, ensuring there are no errors as it launches.