db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sunitha Kambhampati (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-928) Add ability to network server to accept connections with a certain security mechanism.
Date Tue, 14 Feb 2006 04:45:10 GMT
     [ http://issues.apache.org/jira/browse/DERBY-928?page=all ]

Sunitha Kambhampati updated DERBY-928:

    Attachment: Derby928.diff.txt

This patch(Derby928.diff.txt) includes the following changes:

1. Adds a new property derby.drda.securityMechanism. This property can take in the following
valid values

The secmec value mapping of these values is as follows:

Changes for this in Property.java to add the property name. 
Added get and set methods to NetworkServerControlImpl, add a new variable allowOnlySecurityMechanism
to store the secmec (int value) that is mapped from the string value set by this property.
 This value is initialized to -1 to represent either an invalid value or a case where the
value is not set. 
An error is thrown when starting the server if this value is not set correctly. 

2.When server sees ACCSEC command,  and if this property is set, then the server will check
if the secmec value requested by client is the same security mechanism set by this property.
If yes, then an appropriate reply data is generated for the requested security mechanism,
else the server will return just the security mechanism set by this property to represent
the security mechanisms that the server supports/accepts. 
Modified code in following methods in DRDAConnThread

client sends ACCSEC with a SECMEC value indicating the security mechanism to use. Server parses
the ACCSEC command in parseACCSEC method and reads the SECMEC value

When server reads the SECMEC value from the client, the following check is added.
 -- check if the derby.drda.securityMechanism property has been set.
	A)if property is set,  then check if the client sent secmec value is the same as this property
value. If so, then continue with the processing of that security mechanism.
	B)if property is set and property value is not same as the client sent secmec value, then
set the security checkcode to CodePoint.SECCHKCD_NOTSUPPORTED. This will be sent across to
the client on a ACCSECRD.
 -- If the derby.drda.securityMechanism has not been set, in that case the server does the
processing as before.
(Note: since an if condition was added because of the check in #A, the previous code that
did the processing of various security mechanisms show up in the diff but that code has not
been changed
except for the increased indentation as a result of the code being put in an else clause)

--  in case B in parseACCSEC, if security check code is SECCHKCD_NOTSUPPORTED and if the derby.drda.securityMechanism
property has been set, then the secmec value that the server supports will be sent to the

Note: there is another jira entry 926 - protocol error when sending invalid security mechanism.
This is because per the DDM manual, the response in ACCSECRD should be of form SECMEC (value{value..}).
We currently send 3 secmec codepoints instead of sending a list with the secmec codepoint.

3. Added test case scenarios in  testSecMec.java and updated master files in both DerbyNet
and DerbyNetClient.
- Start server with different values for derby.drda.securityMechanism and test with the connection
urls using drivermanager and datasource. 
+    private static String[] derby_drda_securityMechanism = {
+            null, //not set
+            "USER_ONLY_SECURITY",
+            "INVALID_VALUE",
+            ""
+    };

Note: the code changes include putting the entire testSecMec test in a loop to test with the
different derby.drda.securityMechanism value.  Because of the addition of the loop, the indentation
of the original test in the main method changed and hence the diff shows up. 
Only change was to catch the exception on starting the server for invalid values of derby.drda.securityMechanism.

I ran derbyall on sun jdk142 with classes on win2k OK. wisconsin test failed but I think that
is not related to my changes. 
I have run the testSecMec.java test with ibm142, jdk142, jdk15 in both DerbyNet and DerbyNetClient
frameworks ok.

M      java\engine\org\apache\derby\iapi\reference\Property.java
M      java\drda\org\apache\derby\impl\drda\NetworkServerControlImpl.java
M      java\drda\org\apache\derby\impl\drda\DRDAConnThread.java
M      java\testing\org\apache\derbyTesting\functionTests\tests\derbynet\testSecMec.java
M      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\testSecMec.out
M      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\testSecMec.out

4. In case of the tests, the test wont be able to run in the remote host environment, because
it requires the server to be restarted with the different values, whereas in remote host testing
- the server is only started once separately from the test harness. I'll look more and see
if there is a way to restart the server on remote host and if so address it as a followup


Currently we are not testing valid encrypted userid and password security mechanisms in our
tests because the encryption algorithm needed by drda will not work with Sun JCE , will only
work with the IBM JCE. It would be nice to add valid cases for encrypted userid password for
atleast ibm jce, which I will try to address as a followon patch. I did test valid cases with
encrypted userid and password using sample program with the ibm jce and it works ok.

I'd appreciate it if someone can review these changes. Thanks.

> Add ability to network server to accept connections with a certain security mechanism.
> --------------------------------------------------------------------------------------
>          Key: DERBY-928
>          URL: http://issues.apache.org/jira/browse/DERBY-928
>      Project: Derby
>         Type: New Feature
>   Components: Network Server
>     Reporter: Sunitha Kambhampati
>     Assignee: Sunitha Kambhampati
>      Fix For:
>  Attachments: Derby928.diff.txt, Derby928.stat.txt
> Currently the network server has support for the following security mechanisms
> 1) USRIDONL (userid only),
> 2) USRIDPWD (clear text userid and password),
> 3) EUSRIDPWD (encrypted userid and password).
> Thus the #3 encrypted userid and password security mechanism is secure with respect to
the userid/password sent across the wire.  Currently there is no way to setup the network
server to ensure that it accepts connections coming in at a certain security mechanism.  
It seems reasonable & useful to have a server want to accept connections from clients
with a particular security mechanism (e.g  lets say encrypted userid/password and reject usridpwd
ie clear text userid and password)
> This jira will add support for this by adding a property to enable the server to be able
to accept connections from clients with a certain security mechanism.
> --------------------
> I actually couldnt find if a rank was given to the security mechanisms in the drda spec.
 If it were so, then maybe a property for setting the minimum security mechanism accepted
by the server would be appropriate.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message