[ http://issues.apache.org/jira/browse/DERBY-928?page=all ]
Sunitha Kambhampati updated DERBY-928:
--------------------------------------
Attachment: Derby928.diff.txt
Derby928.stat.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
USER_ONLY_SECURITY,
CLEAR_TEXT_PASSWORD_SECURITY,ENCRYPTED_USER_AND_PASSWORD_SECURITY.
The secmec value mapping of these values is as follows:
USER_ONLY_SECURITY maps to USRIDONL
CLEAR_TEXT_PASSWORD_SECURITY mapts to USRIDPWD
ENCRYPTED_USER_AND_PASSWORD_SECURITY to EUSRIDPWD
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
parseACCSEC:
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)
writeACCSECRD
-- 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 client.
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",
+ "CLEAR_TEXT_PASSWORD_SECURITY",
+ "ENCRYPTED_USER_AND_PASSWORD_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 patch
-------------
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: 10.2.0.0
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
