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 Fri, 03 Mar 2006 23:36:40 GMT
     [ http://issues.apache.org/jira/browse/DERBY-928?page=all ]

Sunitha Kambhampati updated DERBY-928:

    Attachment: Derby928_canons.diff.txt

JCC 2.6 behavior has changed from JCC2.4 with respect to how security mechanisms are handled.
 I am attaching a patch to fix some masters to run cleanly with jcc2.6.

This patch 'Derby928_canons.diff.txt' updates 
- master files for derbynet/testSecMec.java for difference in behavior in jcc2.6 from 2.4
- puts testSecMec.java and sysinfo_withproperties in exclude for remote server testing as
both these tests require the server to be restarted with the different properties set.

The JCC 2.6 client does the following: if the client sends a security mechanism of 3( clear
text userid and password) and if the server does not accept this security mechanism but supports
encrypted userid/password , in that case the client will then use security mechanism (9) -encrypted
userid and password and send it to the server.

This auto-switching is only in 2.6 client and not in 2.4 JCC.  I have verified this behavior
by seeing what the jcc 2.6 client is sending to the server in the debugger and have also verified
it with the JCC folks.

This is a test master update only. 
I have run derbynet/testSecMec.java with classes with jdk131/jdk141/jdk142/jdk15/ibm131/ibm141/ibm142/ibm15
with JCC 2.6 driver OK.

svn stat
A      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\ver2.6\testSecMec.out
A      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\ibm14\ver2.6
A      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\ibm14\ver2.6\testSecMec.out
M      java\testing\org\apache\derbyTesting\functionTests\suites\DerbyNetRemote.exclude
M      java\testing\org\apache\derbyTesting\functionTests\suites\DerbyNetClientRemote.exclude

Can someone please review and commit this change. 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.3.diff.txt, Derby928.3.stat.txt, Derby928.diff.txt, Derby928.stat.txt,
Derby928_Table_SecurityMechanisms..htm, Derby928_canons.diff.txt, Derby928_canons.stat.txt,
Derby928_v2_diff.txt, Derby928_v2_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