Feature Test Summary: Kerberos auth support using Datasources

[aguibert]

1) Describe the test strategy & approach for this feature, and describe how the approach verifies the functions delivered by this feature. The description should include the positive and negative testing done, whether all testing is automated, what manual tests exist (if any) and where the tests are stored (source control). Automated testing is expected for all features with manual testing considered an exception to the rule.

Summary of strategy

Overall to test this functionality we needed 3 processes to work together: A Liberty server with a JDBC app on it, a Kerberos KDC, and a relational database (DB2, Oracle, or MS SQLServer).
This setup was a bit more complex than what has been done in the past, but we were able to automate the testing thanks to Testcontainers, which allows us to easily spin up docker containers. For this feature I created a few custom docker containers:

• A KDC container pre-configured with the SPNs required by the tests
• A DB2 container pre-configured to talk to the KDC container, and configured to require Kerberos auth
• An Oracle container pre-configured to talk to the KDC container, and configured to use Kerberos auth

We are not (yet) able to automate testing of MS SQLServer + Kerberos, because the MS SQLServer container does not support Kerberos (see this issue for details). Instead, we are planning to do one-time manual testing of MS SQLServer, which is acceptable to us because the Liberty code handles Kerberos auth for Oracle and SQLServer in the exact same way (via Subject.doAs()), and we have coverage of the Oracle/SQLServer path from the Oracle testing.

New automated tests added

All new tests were added into a new FAT bucket: com.ibm.ws.jdbc_fat_krb5

DB2+Kerberos test scenarios (LITE mode):

• testBasicPassword: (FULL mode) Test that the 'password' attribute of an authData element can be used to supply a Kerberos password. Normally a keytab file takes precedence over this, so perform dynamic config for the test to temporarily set the keytab location to an invalid location to confirm that the supplied password actually gets used.
• testTicketCache: (FULL mode) Generate a ticket cache using the 'kinit' operating system command.
  Dynamically configure the server to use REMOVE the keyTab configuration (since a bad ticket cache would fallback
  to the keyTab) and SET the krb5TicketCache on the authData to be the file we just generated with 'kinit'.
  Wait for a config update, and expect the getConnection test to work since the credential should be found in the ccache
• testNonKerberosConnectionRejected: Attempt to get a connection from a datasource that has basic auth configured, which
  should fail because the backend DB2 database has been configured to require Kerberos
• testKerberosBasicConnection: Get a connection with a javax.sql.ConnectionPoolDataSource
• testKerberosXAConnection: Get a connection with a javax.sql.XADatasource
• testKerberosRegularConnection: Get a connection with a javax.sql.Datasource
• testReboundAuthAlias: Test getting a connection from a datasource that has no auth-data configured
  in server.xml, which would normally fail, but has a valid auth-data alias
  configured in ibm-web-bnd.xml and therefore should be able to get a connection
• testInvalidPrincipal: Test that attempting to get connection using a bogus principal (i.e. bogus username)
  is rejected. This is a negative test that will give us confidence that the positive
  tests are actually using kerberos.
• testConnectionReuse: Get two connection handles from the same datasource.
  Ensure that both connection handles share the same managed connection (i.e. phyiscal connection)
  to prove that Subject reuse is working
• testXARecovery: Cause an in-doubt transaction and verify that XA recovery resolves it.
  The recoveryAuthData should be used for recovery.

Note: there are less test scenarios for the Oracle+Kerberos variation because the JDBC-layer code is all common paths regardless of what backend DB we are using. So we do less testing w/ Oracle because we just need to verify a basic level of functionality. The more advanced/corner case tests only need to be tested with one DB.

Oracle+Kerberos test scenarios (FULL mode):

• testKerberosBasicConnection: Get a connection with a javax.sql.ConnectionPoolDataSource
• testKerberosXAConnection: Get a connection with a javax.sql.XADatasource
• testKerberosRegularConnection: Get a connection with a javax.sql.Datasource
• testInvalidPrincipal: Test that attempting to get connection using a bogus principal (i.e. bogus username)
  is rejected. This is a negative test that will give us confidence that the positive
  tests are actually using kerberos.
• testConnectionReuse: Get two connection handles from the same datasource.
  Ensure that both connection handles share the same managed connection (i.e. phyiscal connection)
  to prove that Subject reuse is working

2) Collectively as a team you need to assess your confidence in the testing delivered based on the values below. This should be done as a team and not an individual to ensure more eyes are on it and that pressures to deliver quickly are absorbed by the team as a whole.

Please indicate your confidence in the testing (up to and including FAT) delivered with this feature by selecting one of these values:

4