| java.lang.Object org.apache.derbyTesting.functionTests.tests.jdbcapi.dataSourcePermissions org.apache.derbyTesting.functionTests.tests.derbynet.dataSourcePermissions_net org.apache.derbyTesting.functionTests.tests.derbynet.testSecMec
testSecMec | public class testSecMec extends dataSourcePermissions_net (Code) | | This class tests the security mechanisms supported by Network Server
Network server supports SECMEC_EUSRIDPWD, SECMEC_USRIDPWD, SECMEC_USRIDONL
and SECMEC_USRSSBPWD.
-----------------------------------------------------------------
Security Mechanism | secmec codepoint value | User friendly name
-----------------------------------------------------------------
USRIDONL | 0x04 | USER_ONLY_SECURITY
USRIDPWD | 0x03 | CLEAR_TEXT_PASSWORD_SECURITY
EUSRIDPWD | 0x09 | ENCRYPTED_USER_AND_PASSWORD_SECURITY
USRSSBPWD | 0x08 | STRONG_PASSWORD_SUBSTITUTE_SECURITY
-----------------------------------------------------------------
Key points:
1)Server and client support encrypted userid/password (EUSRIDPWD) via the
use of Diffie Helman key-agreement protocol - however current Open Group DRDA
specifications imposes small prime and base generator values (256 bits) that
prevents other JCE's to be used as java cryptography providers - typical
minimum security requirements is usually of 1024 bits (512-bit absolute
minimum) when using DH key-agreement protocol to generate a session key.
(Reference: DDM manual, page 281 and 282. Section: Generating the shared
private key. DRDA's diffie helman agreed public values for prime are 256
bits. The spec gives the public values for the prime, generator and the size
of exponent required for DH . These values must be used as is to generate a
shared private key.)
Encryption is done using JCE. Hence JCE support of the necessary algorithm is
required for a particular security mechanism to work. Thus even though the
server and client have code to support EUSRIDPWD, this security mechanism
will not work in all JVMs.
JVMs where support for DH(32byte prime) is not available and thus EUSRIDPWD
wont work are Sun JVM (versions 1.3.1,1.4.1,1.4.2,1.5) and IBM JVM (versions
1.3.1 and some old versions of 1.4.2 (in 2004) )
JVMs where support for DH(32bytes prime) is available and thus EUSRIDPWD will
work are IBM JVM [versions 1.4.1, later versions of 1.4.2 (from 2005), 1.5]
#2) JCC 2.6 client does some automatic upgrade of security mechanism in one
case. Logic is as follows:
If client sends USRIDPWD to server and server rejects this
and says it accepts only EUSRIDPWD, in that case JCC 2.6 will upgrade the
security mechanism to EUSRIDPWD and retry the request with EUSRIDPWD.
This switching will also override the security mechanism specified by user.
Thus if JCC client is running with Sun JVM 1.4.2 and even though Sun JCE
does not have support for algorithms needed for EUSRIDPWD, the JCC client
will still try to switch to EUSRIDPWD and throw an exception with
ClassNotFoundException for the IBM JCE.
- Default security mechanism is USRIDPWD(0x03)
- If securityMechanism is not explicitly specified on connection request
and if no user specified, an exception is thrown - Null userid not supported
- If securityMechanism is not explicitly specified on connection request,
and if no password is specified, an exception is thrown - null password not supported
If securityMechanism is explicitly specified to be USRIDONL, then a password
is not required. But in other cases (EUSRIDPWD, USRIDPWD, USRSSBPWD) if
password is null, an exception with the message 'a null password not valid'
will be thrown.
- On datasource, setting a security mechanism works. It also allows a security
mechanism of USRIDONL to be set on datasource unlike jcc 2.4.
#3)JCC 2.4 client behavior
Default security mechanism used is USRIDPWD (0x03)
If securityMechanism is not explicitly specified on connection request,
and if no user is specified, an exception is thrown. - Null userid not supported.
If securityMechanism is not explicitly specified on connection request,
and if no password is specified, an exception is thrown - null password not supported
If security mechanism is specified, jcc client will not override the security mechanism.
If securityMechanism is explicitly specified to be USRIDONL, then a password
is not required. But in other cases (EUSRIDPWD,USRIDPWD) if password is null
- an exception with the message 'a null password not valid' will be thrown.
On datasource, setting a security mechanism does not work (bug). It defaults
to USRIDPWD. Setting a value of USRIDONL or EUSRIDPWD does not seem to have
an effect.
#4) Note, if server restricts the client connections based on security mechanism
by setting derby.drda.securityMechanism, in that case the clients will see an
error similar to this
"Connection authorization failure occurred. Reason: security mechanism not supported"
#5) USRSSBPWD - Strong password substitute is only supported starting from
Apache Derby 10.2.
NOTE: USRSSBPWD only works with the derby network client driver for now.
----
|
Method Summary | |
public static void | dumpSQLException(SQLException sqle) | public void | getConnectionUsingDataSource() | public void | getConnectionUsingDriverManager(String dbUrl, String msg) | public Connection | getConnectionWithSecMec(String user, String password, Short secMec) | public void | getDataSourceConnection(String user, String password, String msg) Helper method to get connection from datasource and to print
the exceptions if any when getting a connection. | public static void | main(String[] args) | protected void | runTest() Test cases for security mechanism
---------------------------------------------------------------
T1 - default , no user PASS (for derbyclient)
T2 - user only PASS (for derbyclient)
T3 - user,password PASS (only for derbynet)
T4 - user,password, security mechanism not set FAIL
T5 - user,password, security mechanism set to SECMEC_EUSRIDPWD PASS/FAIL
(Fails with Sun JVM as EUSRIDPWD secmec cannot be used)
T6 - user, security mechanism set to SECMEC_USRIDONL PASS
T7 - user,password, security mechanism set to SECMEC_USRENCPWD FAIL
Test with datasource as well as DriverManager
T8 - user,password security mechanism set to SECMEC_USRIDONL PASS
T9 - user,password security mechanism set to SECMEC_USRSSBPWD PASS
Test with datasource as well as DriverManager
Note, that with DERBY928, the pass/fail for the connections
will depend on the security mechanism specified at the server by property
derby.drda.securityMechanism. | public void | test(Connection conn) | public void | testAllCombinationsOfUserPasswordSecMecInput() Test different interesting combinations of user,password, security mechanism
for testing security mechanism upgrade logic. | public void | testDerby1080() This is a regression test for DERBY-1080 - where some variables required
only for the EUSRIDPWD security mechanism case were not getting reset on
connection re-use and resulting in protocol error. | public void | testSecMecWithConnPooling(String user, String password, Short secmec) Test a deferred connection reset. | public void | testSecurityMechanism(String user, String password, Short secmec, String msg) | public void | testUSRSSBPWD_with_BUILTIN() Test SECMEC_USRSSBPWD with derby BUILTIN authentication turned ON. |
SECMEC_EUSRIDPWD | final static short SECMEC_EUSRIDPWD(Code) | | |
SECMEC_USRENCPWD | final static short SECMEC_USRENCPWD(Code) | | |
SECMEC_USRIDNWPWD | final static short SECMEC_USRIDNWPWD(Code) | | |
SECMEC_USRIDONL | final static short SECMEC_USRIDONL(Code) | | |
SECMEC_USRIDPWD | final static short SECMEC_USRIDPWD(Code) | | |
SECMEC_USRSSBPWD | final static short SECMEC_USRSSBPWD(Code) | | |
dumpSQLException | public static void dumpSQLException(SQLException sqle)(Code) | | Dump SQLState and message for the complete nested chain of SQLException
Parameters: sqle - SQLException whose complete chain of exceptions istraversed and sqlstate and message is printed out |
getConnectionUsingDataSource | public void getConnectionUsingDataSource()(Code) | | Get connection from datasource and also set security mechanism
|
getConnectionUsingDriverManager | public void getConnectionUsingDriverManager(String dbUrl, String msg)(Code) | | |
getDataSourceConnection | public void getDataSourceConnection(String user, String password, String msg)(Code) | | Helper method to get connection from datasource and to print
the exceptions if any when getting a connection. This method
is used in testAllCombinationsOfUserPasswordSecMecInput.
For explanation of exceptions that might arise in this method,
please check testAllCombinationsOfUserPasswordSecMecInput
javadoc comment.
get connection from datasource
Parameters: user - username Parameters: password - password Parameters: msg - message to print for testcase |
runTest | protected void runTest()(Code) | | Test cases for security mechanism
---------------------------------------------------------------
T1 - default , no user PASS (for derbyclient)
T2 - user only PASS (for derbyclient)
T3 - user,password PASS (only for derbynet)
T4 - user,password, security mechanism not set FAIL
T5 - user,password, security mechanism set to SECMEC_EUSRIDPWD PASS/FAIL
(Fails with Sun JVM as EUSRIDPWD secmec cannot be used)
T6 - user, security mechanism set to SECMEC_USRIDONL PASS
T7 - user,password, security mechanism set to SECMEC_USRENCPWD FAIL
Test with datasource as well as DriverManager
T8 - user,password security mechanism set to SECMEC_USRIDONL PASS
T9 - user,password security mechanism set to SECMEC_USRSSBPWD PASS
Test with datasource as well as DriverManager
Note, that with DERBY928, the pass/fail for the connections
will depend on the security mechanism specified at the server by property
derby.drda.securityMechanism. Please check out the following html file
http://issues.apache.org/jira/secure/attachment/12322971/Derby928_Table_SecurityMechanisms..htm
for a combination of url/security mechanisms and the expected results
|
test | public void test(Connection conn) throws Exception(Code) | | Test a connection by executing a sample query
Parameters: conn - database connection throws: Exception - if there is any error |
testAllCombinationsOfUserPasswordSecMecInput | public void testAllCombinationsOfUserPasswordSecMecInput()(Code) | | Test different interesting combinations of user,password, security mechanism
for testing security mechanism upgrade logic. This test has been added
as part of DERBY-962. Two things have been fixed in DERBY-962, affects
only client behavior.
1)Upgrade logic should not override security mechanism if it has been
explicitly set in connection request (either via DriverManager or
using DataSource)
2)Upgrade security mechanism to a more secure one , ie preferably
to encrypted userid and password if the JVM in which the client is
running has support for it.
Details are:
If security mechanism is not specified as part of the connection request,
then client will do an automatic switching (upgrade) of
security mechanism to use. The logic is as follows :
if password is available, and if the JVM in which the client is running
supports EUSRIDPWD mechanism, in that case also, USRIDPWD security mechanism is
used.
if password is available, and if the JVM in which the client is running
does not support EUSRIDPWD mechanism, in that case the client will then
default to USRIDPWD.
Also see DERBY-962 http://issues.apache.org/jira/browse/DERBY-962
To understand which JVMs support EUSRIDPWD or not, please see class level
comments (#1)
The expected output from this test will depend on the following
-- the client behavior (JCC 2.4, JCC2.6 or derby client).For the derby client,
the table below represents what security mechanism the client will send
to server.
-- See class level comments (#2,#3) to understand the JCC2.6 and JCC2.4
behavior
-- Note: in case of derby client, if no user is specified, user defaults to APP.
-- Will depend on if the server has been started with derby.drda.securityMechanism
and to the value it is set to. See main method to check if server is using the
derby.drda.securityMechanism to restrict client connections based on
security mechanism.
TABLE with all different combinations of userid, password,
security mechanism of derby client that is covered by this testcase if test
is run against IBM15 and JDK15.
IBM15 supports eusridpwd, whereas SunJDK15 doesnt support EUSRIDPWD
Security Mechanisms supported by derby server and client
====================================================================
|SecMec |codepoint value| User friendly name |
====================================================================
|USRIDONL | 0x04 | USER_ONLY_SECURITY |
|USRIDPWD | 0x03 | CLEAR_TEXT_PASSWORD_SECURITY |
|EUSRIDPWD | 0x09 | ENCRYPTED_USER_AND_PASSWORD_SECURITY|
|USRSSBPWD | 0x08 | STRONG_PASSWORD_SUBSTITUTE_SECURITY |
=====================================================================
Explanation of columns in table.
a) Connection request specifies a user or not.
Note: if no user is specified, client defaults to APP
b) Connection request specifies a password or not
c) Connection request specifies securityMechanism or not. the valid
values are 4(USRIDONL), 3(USRIDPWD), 9(EUSRIDPWD) and 8(USRSSBPWD).
d) support eusridpwd means whether this client jvm supports encrypted userid/
password security mechanism or not. A value of Y means it supports
and N means no.
The next three columns specify what the client sends to the server
e) Does client send user information
f) Does client send password information
g) What security mechanism value (secmec value) is sent to server.
SecMec refers to securityMechanism.
Y means yes, N means No, - or blank means not specified.
Err stands for error.
Err(1) stands for null password not supported
Err(2) stands for case when the JCE does not support encrypted userid and
password security mechanism.
----------------------------------------------------------------
| url connection | support | Client sends to Server |
|User |Pwd |secmec |eusridpwd |User Pwd SecMec |
|#a |#b |#c |#d |#e #f #g |
|---------------------------------------------------------------|
=================================================================
|SecMec not specified on connection request
=================================================================
|Y |Y |- |Y |Y Y 3 |
|----------------------------------------------------------------
| |Y |- |Y |Y Y 3 |
-----------------------------------------------------------------
|Y | |- |Y |Y N 4 |
-----------------------------------------------------------------
| | |- |Y |Y N 4 |
=================================================================
|Y |Y |- |N |Y Y 3 |
|----------------------------------------------------------------
| |Y |- |N |Y Y 3 |
-----------------------------------------------------------------
|Y | |- |N |Y N 4 |
-----------------------------------------------------------------
| | |- |N |Y N 4 |
=================================================================
SecMec specified to 3 (clear text userid and password)
=================================================================
|Y |Y |3 |Y |Y Y 3 |
|----------------------------------------------------------------
| |Y |3 |Y |Y Y 3 |
-----------------------------------------------------------------
|Y | |3 |Y |- - Err1 |
-----------------------------------------------------------------
| | |3 |Y |- - Err1 |
=================================================================
|Y |Y |3 |N |Y Y 3 |
|----------------------------------------------------------------
| |Y |3 |N |Y Y 3 |
-----------------------------------------------------------------
|Y | |3 |N |- - Err1 |
-----------------------------------------------------------------
| | |3 |N |- - Err1 |
=================================================================
SecMec specified to 9 (encrypted userid/password)
=================================================================
|Y |Y |9 |Y |Y Y 9 |
|----------------------------------------------------------------
| |Y |9 |Y |Y Y 9 |
-----------------------------------------------------------------
|Y | |9 |Y | - - Err1 |
-----------------------------------------------------------------
| | |9 |Y | - - Err1 |
=================================================================
|Y |Y |9 |N | - - Err2 |
|----------------------------------------------------------------
| |Y |9 |N | - - Err2 |
-----------------------------------------------------------------
|Y | |9 |N | - - Err1 |
-----------------------------------------------------------------
| | |9 |N | - - Err1 |
=================================================================
SecMec specified to 4 (userid only security)
=================================================================
|Y |Y |4 |Y |Y N 4 |
|----------------------------------------------------------------
| |Y |4 |Y |Y N 4 |
-----------------------------------------------------------------
|Y | |4 |Y |Y N 4 |
-----------------------------------------------------------------
| | |4 |Y |Y N 4 |
=================================================================
|Y |Y |4 |N |Y N 4 |
|----------------------------------------------------------------
| |Y |4 |N |Y N 4 |
-----------------------------------------------------------------
|Y | |4 |N |Y N 4 |
-----------------------------------------------------------------
| | |4 |N |Y N 4 |
=================================================================
SecMec specified to 8 (strong password substitute)
=================================================================
|Y |Y |8 |Y |Y Y 8 |
|----------------------------------------------------------------
| |Y |8 |Y |Y Y 8 |
-----------------------------------------------------------------
|Y | |8 |Y | - - Err1 |
-----------------------------------------------------------------
| | |8 |Y | - - Err1 |
=================================================================
|Y |Y |8 |N | - Y 8 |
|----------------------------------------------------------------
| |Y |8 |N | - Y 8 |
-----------------------------------------------------------------
|Y | |8 |N | - - Err1 |
-----------------------------------------------------------------
| | |8 |N | - - Err1 |
=================================================================
|
testDerby1080 | public void testDerby1080()(Code) | | This is a regression test for DERBY-1080 - where some variables required
only for the EUSRIDPWD security mechanism case were not getting reset on
connection re-use and resulting in protocol error. This also applies to
USRSSBPWD security mechanism.
Read class level comments (#1) to understand what is specified by drda
spec for EUSRIDPWD.
Encryption is done using JCE. Hence JCE support of the necessary
algorithm is required for EUSRIDPWD security mechanism to work. Thus
even though the server and client have code to support EUSRIDPWD, this
security mechanism will not work in all JVMs.
JVMs where support for DH(32byte prime) is not available and thus EUSRIDPWD
wont work are Sun JVM (versions 1.3.1,1.4.1,1.4.2,1.5) and
IBM JVM (versions 1.3.1 and some old versions of 1.4.2 (in 2004) )
Expected behavior for this test:
If no regression has occurred, this test should work OK, given the
expected exception in following cases:
1) When EUSRIDPWD is not supported in JVM the test is running, a CNFE
with initializing EncryptionManager will happen. This will happen for
Sun JVM (versions 1.3.1,1.4.1,1.4.2,1.5) and
IBM JVM (versions 1.3.1 and some old versions of 1.4.2 (in 2004) )
For JCC clients, error message is
"java.lang.ClassNotFoundException is caught when initializing
EncryptionManager 'IBMJCE'"
For derby client, the error message is
"Security exception encountered, see next exception for details."
2)If server does not accept EUSRIDPWD security mechanism from clients,then
error message will be "Connection authorization failure
occurred. Reason: security mechanism not supported"
Note: #2 can happen if server is started with derby.drda.securityMechanism
and thus restricts what security mechanisms the client can connect with.
This will happen for the test run when derby.drda.securityMechanism is set and
to some valid value other than ENCRYPTED_USER_AND_PASSWORD_SECURITY.
See RunTest where this method is called to test for regression for DERBY-1080.
Also see main method to check if server is using the derby.drda.securityMechanism to
restrict client connections based on security mechanism.
|
testSecMecWithConnPooling | public void testSecMecWithConnPooling(String user, String password, Short secmec) throws Exception(Code) | | Test a deferred connection reset. When connection pooling is done
and connection is reset, the client sends EXCSAT,ACCSEC and followed
by SECCHK and ACCRDB. Test if the security mechanism related information
is correctly reset or not. This method was added to help simulate regression
test for DERBY-1080. It is called from testDerby1080
Parameters: user - username Parameters: password - password for connection Parameters: secmec - security mechanism for datasource throws: Exception - |
testUSRSSBPWD_with_BUILTIN | public void testUSRSSBPWD_with_BUILTIN()(Code) | | Test SECMEC_USRSSBPWD with derby BUILTIN authentication turned ON.
We want to test a combination of USRSSBPWD with BUILTIN as password
substitute is only supported with NONE or BUILTIN Derby authentication
scheme right now (DERBY-528).
throws: Exception - if there an unexpected error |
Methods inherited from org.apache.derbyTesting.functionTests.tests.derbynet.dataSourcePermissions_net | public void allUsernameAndPasswordTests()(Code)(Java Doc) public void checkMessageText(Connection conn, String retrieveMessageTextValue) throws SQLException(Code)(Java Doc) public javax.sql.ConnectionPoolDataSource getCPDS(String database, String user, String password)(Code)(Java Doc) public javax.sql.DataSource getDS(String database, String user, String password)(Code)(Java Doc) public javax.sql.DataSource getDS(String database, String user, String password, Properties attrs)(Code)(Java Doc) public String getJDBCUrl(String db, String attrs)(Code)(Java Doc) protected static boolean isServerStarted(NetworkServerControl server, int ntries)(Code)(Java Doc) public static void main(String[] args) throws Exception(Code)(Java Doc) public void setProperties()(Code)(Java Doc) public void shutdown()(Code)(Java Doc) public void start()(Code)(Java Doc) public boolean supportsPooling()(Code)(Java Doc) public boolean supportsUnicodeNames()(Code)(Java Doc) public boolean supportsXA()(Code)(Java Doc) public void testClientDataSourceProperties() throws SQLException(Code)(Java Doc) public void testConnectionAttributes()(Code)(Java Doc) public void testDataSourceConnection(String testType, String username, String password, String attributes) throws SQLException(Code)(Java Doc) public void testDescription() throws SQLException(Code)(Java Doc) public void testRetrieveMessageText() throws SQLException(Code)(Java Doc)
|
|
|