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 Thu, 16 Feb 2006 21:46:09 GMT
     [ http://issues.apache.org/jira/browse/DERBY-928?page=all ]

Sunitha Kambhampati updated DERBY-928:
--------------------------------------

    Attachment: Derby928_v2_diff.txt
                Derby928_v2_stat.txt

I have made changes so that information about this property is also picked up when server
sysinfo is called.
I am attaching the following patch 'Derby928_v2_diff.txt' and corresponding Derby928_v2_stat.txt

Changes compared to previous patch (Derby928.diff.txt)

--  server sysinfo also prints information about the drda properties. 
Changes were made to ensure that when derby.drda.securityMechanism is set, the sysinfo information
for server will reflect that. Added this property value to be picked up only if the property
was set. Change in NetworkServerControlImpl#getPropertyValues().  Internally we store the
value set by this property as an int. Added a new method getStringValueForSecMec to get mapping
from the integer secmec value to corresponding string. 
-- added test sysinfo_withproperties.java. This test sets the derby.drda.securityMechanism
property and will print out the sysinfo information of the server. 
-- case of when this property is not set, is tested with the sysinfo.java test, and when the
property is set, this case is covered by sysinfo_withproperties.java.
-- Added some more comments

I ran derbyall with these changes on jdk142 with classes and all passed except for wisconsin.
The wisconsin failure is not related to this change.  

I'd appreciate it if someone could review this patch.  Thanks. 

E.g.snippet from the master output (sysinfo_withproperties.out)
+Testing Sysinfo
+org.apache.derby.drda.NetworkServerControl sysinfo 
+----- Derby Network Server Information --------
+----- listing properties --
+derby.drda.securityMechanism=USER_ONLY_SECURITY
+derby.drda.maxThreads=0
+derby.drda.keepAlive=true
+derby.drda.minThreads=0
+derby.drda.portNumber=1527
+derby.drda.logConnections=false
+derby.drda.timeSlice=0
+derby.drda.startNetworkServer=false
+derby.drda.host=xxxFILTERED_HOSTNAMExxx
+derby.drda.traceAll=false
+----- Derby Information --------


> 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, Derby928_Table_SecurityMechanisms..htm,
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:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message