Red Hat Training

A Red Hat training course is available for Red Hat JBoss Data Virtualization

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>
  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" />
    		
    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" />
    				
    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" />
    
    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" />
    
  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"
    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>
    
  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>
    Your second option is to secure only one virtual database:
    <property name="security-domain" value="EXAMPLE.COM"/>
    <property name="authentication-type" value="GSS" />
    
  5. Restart the server

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