TEIID-4561 TEIID-4560 updating security related docs

admin/Kerberos_with_REST_based_Services.adoc

@@ -24,6 +24,7 @@ With this configuration, REST service is configured with Kerberos JAAS domain, t
 
              <module-option name="doNotPrompt" value="true"/>
              <module-option name="debug" value="false"/>
+             <module-option name="addGSSCredential" value="true"/>
          </login-module>
      </authentication>
 </security-domain> 
@@ -87,13 +88,12 @@ To configure in "passthrough-security" security domain, the "security" subsystem
 ----
 <security-domain name="passthrough-security" cache-type="default">  
     <authentication>  
-        <login-module code="org.teiid.jboss.PassthroughIdentityLoginModule" flag="required" module="org.jboss.teiid">  
-            <module-option name="username" value="guest"/>  
-            <module-option name="password" value="guest"/>  
+        <login-module code="Kerberos" flag="required" module="org.jboss.security.negotiation">
+            <module-option name="delegationCredential" value="REQUIRED"/>
         </login-module>  
     </authentication>  
 </security-domain>  
 ----
 
-The username, password are optional, if in case there is no authenticated subject available in the context, these can help create a simple static user, but that user will not work with kerberos authentication as the subject will not have the kerberos token required.
+If in case there is no delegationCredential is available on the context, the access will fail. 
 

admin/Web_Service_Data_Sources.adoc

@@ -220,7 +220,7 @@ WS-Policy section is correctly interpreted and enforced on the endpoint. The sam
 </beans>
 ----
 
-and you would need to configure the security-domain in the standalone-teiid.xml file under `security' subsystem as
+and you would need to configure the security-domain in the standalone-teiid.xml file under the 'security' subsystem as
 
 [source,xml]
 ----

security/Data_Source_Security.adoc

@@ -42,7 +42,9 @@ In the datasource configuration, instead of supplying the username/password you
 <datasource jndi-name="java:/mysql-ds" pool-name="mysql-ds" enabled="true">
     <connection-url>jdbc:mysql://localhost:3306/txns</connection-url>
     <driver>mysql</driver>
-     <pool><allow-multiple-users/></pool>
+     <pool>
+          <allow-multiple-users>true</allow-multiple-users>
+     </pool>
      <security>
           <security-domain>my-security-domain</security-domain>
      </security>
@@ -84,7 +86,7 @@ Using this CallerIdentity module, the connection pool for data source is segment
 == Pass Through Identity
 
 This is similar to the CallerIdentity login module, where the calling user’s credentials and roles are passed as is. 
-This is especially useful when dealing with non-text based credentials where you want to pass down the payload as is. The example is when kerberos login is used the logged in subject contains GSSCredential object that contains the GSS token.
+This is especially useful when dealing with non-text based credentials where you want to pass down the payload as is.
 
 [source,xml]
 .standalone-teiid.xml
@@ -113,18 +115,15 @@ In the datasource configuration, instead of supplying the username/password you
 <datasource jndi-name="java:/mysql-ds" pool-name="mysql-ds" enabled="true">
     <connection-url>jdbc:mysql://localhost:3306/txns</connection-url>
     <driver>mysql</driver>
-     <pool><allow-multiple-users/></pool>
-     <security>
+    <pool>
+          <allow-multiple-users>true</allow-multiple-users>
+    </pool>
+    <security>
           <security-domain>passthrough-security</security-domain>
-     </security>
+    </security>
 </datasource>
 ----
 
-TIP: When working with Kerberos/GSS security token (GssCredential), some JDBC drivers (MS-SQLServer) upon close of the connection they invalidate the GssCredential security token, to avoid accidental invalidation, add an option to above security-domain's login-module configuration to wrap the passed in security token by adding below configuration
-----
-<module-option name="wrapGSSCredential" value="true"/>
-----
-
 == OAuth Authentication
 
 Secured Rest services with OAuth authentication can be used in Teiid, however the data sources need to be configured with OAuth Refresh Token or Json Web Token (JWT) based security domains.
@@ -231,15 +230,26 @@ The above command will generate resulting XML in the standalone.xml file or doma
          <module-option name="doNotPrompt" value="true"/>
          <module-option name="debug" value="false"/>
          <module-option name="refreshKrb5Config" value = "true"/>
+         <module-option name="addGSSCredential" value = "true"/>
       </login-module>
    </authentication>
 </security-domain>  
 ----
 
-=== Kerberos passthrough
+=== Kerberos Delegation
+
+For using the same kerberos token at Teiid and as well as at the data source level, the token negotiated at the Teiid engine can be passed into data source. The data source must be configured to support this. Major database 
+vendors like Oracle, MS-SQLServer, DB2, HIVE, Impala support kerberos. Some also support pass through mode. 
+To make delegation work, follow the directions here to setup the Kerberos at Teiid engine level [Kerberos support through GSSAPI] and use the module option delegationCredential:
 
-For using the same kerberos token at Teiid and as well as at the data source level, the token negotiated at the Teiid engine can be passed into data source. Data source explicitly needs to provide this support. Major database 
-vendors like Oracle, MS-SQLServer, DB2, HIVE, Impala support kerberos. Some also support pass through mode. To Make pass-through work, follow the directions here to setup the Kerberos at Teiid engine level [Kerberos support through GSSAPI] then for data source level create the [#Pass Through Identity]
+----
+<module-option name="delegationCredential" value="USE"/>
+----
+
+TIP: When working with Kerberos/GSS security token (GssCredential), some JDBC drivers (MS-SQLServer) upon close of the connection they invalidate the GssCredential security token, to avoid accidental invalidation, add an option to above security-domain's login-module configuration to wrap the passed in security token by adding below configuration
+----
+<module-option name="wrapGSSCredential" value="true"/>
+----
 
 == Translator Customization
 

security/JDBC_ODBC_SSL_SelfSigned.adoc

@@ -93,7 +93,6 @@ I also found a great reference here [1] & [2] for certificate generation. Note i
     </ssl>  
 </transport>  
 <transport name="odbc" socket-binding="teiid-odbc" protocol="pg">  
-    <authentication security-domain="teiid-security"/>  
     <ssl mode="enabled" authentication-mode="1-way">  
         <keystore name="/path/to/rootCA.keystore" password="changeme" type="JKS"/>  
       <!-- uncomment and configure for 2-way authentication  

security/Teiid_Server_Transport_Security.adoc

@@ -14,8 +14,9 @@ SSL configuration is part of the _transport_ configuration in the Teiid subsyste
 Teiid supports a couple different encryption modes based on the _mode_ attribute on _ssl_ element.
 
 * *logIn* - This is the default setting for the transports.
-** JDBC (non-data by default) messages between client and server are encrypted using 128 bit AES with a http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange[Diffie-Hellman] key that is negotiated per connection. When possible a 2048 bit key exchange will be used otherwise 1024 bit will be used. Oracle/Sun 1.7 JREs are known not to support key lengths over 1024 bits. The link:../client-dev/Driver_Connection.adoc[connection property] encryptRequest can be used to encrypt requests and results using the same 128 AES scheme.
-** For the pg transport authentication is expected to be secure - which currently is only GSS logins.
+** JDBC (non-data by default) messages between client and server are encrypted using 128 bit AES with a http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange[Diffie-Hellman] key that is negotiated per connection. When possible a 2048 bit key exchange will be used otherwise 1024 bit will be used. 
+Oracle/Sun 1.7 JREs are known not to support key lengths over 1024 bits. The link:../client-dev/Driver_Connection.adoc[connection property] encryptRequest can be used to encrypt requests and results using the same 128 AES scheme.
+** For the pg transport authentication is expected to be secure - which currently is only GSS logins.  Pre 9.x and unpatched client/server combinations will use a less secure ECB block mode, which is not recommended for large authentication payloads and the encryptRequest option.  
 
 * *enabled* - Mode to enable SSL. Clients are required to connect using SSL.