You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org> on 2006/02/07 01:42:57 UTC
[jira] Created: (DERBY-928) Add ability to network server to accept
connections with a certain security mechanism.
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
Fix For: 10.2.0.0
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
Re: [jira] Commented: (DERBY-928) Add ability to network server to accept connections with a certain security mechanism.
Posted by Deepa Remesh <dr...@gmail.com>.
Hi Sunitha,
I went through the patch and it looks good. However, the patch
(testSecMec.java file) does not apply cleanly to the latest trunk
revision. Please upload a new version of the patch and I'll take a
relook.
Minor comments:
1. In testSecMec.java, it would be good to update the comment for
runTest method to say something like pass/fail depends on the value of
securityMechanism specified for the server. It would be nice to have
your table in the html file
http://issues.apache.org/jira/secure/attachment/12322971/Derby928_Table_SecurityMechanisms..htm
or a pointer to it somewhere in here to show the different
combinations of url/security mechanisms and expected results.
2. Since the masters in DerbyNet and DerbyNetClient for the new test
sysinfo_withproperties are identical, it would be good to have just
one master file in the main master folder.
I have been trying to put this comment in JIRA but I am getting some
problem in rendering. So sending the mail to derby-dev.
Thanks,
Deepa
On 2/14/06, Sunitha Kambhampati (JIRA) <de...@db.apache.org> wrote:
> [ http://issues.apache.org/jira/browse/DERBY-928?page=comments#action_12366439 ]
>
> Sunitha Kambhampati commented on DERBY-928:
> -------------------------------------------
>
> I was looking at the sysinfo information that we print from the server and this also prints information about the properties related to the server. I will update the patch to ensure information about this new property derby.drda.securityMechanism also gets reflected when calling sysinfo from server.
>
> > 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
> >
> > 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
>
>
[jira] Commented: (DERBY-928) Add ability to network server to
accept connections with a certain security mechanism.
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-928?page=comments#action_12368184 ]
Kathey Marsden commented on DERBY-928:
--------------------------------------
I will review and look at committing this patch
> 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.3.diff.txt, Derby928.3.stat.txt, 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
[jira] Commented: (DERBY-928) Add ability to network server to
accept connections with a certain security mechanism.
Posted by "Deepa Remesh (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-928?page=comments#action_12368135 ]
Deepa Remesh commented on DERBY-928:
------------------------------------
Thanks Sunitha for uploading the new patch. It applies cleanly. One small comment: testSecMec.java has many white space diffs not seen in previous patch. It would be good if you can take care of these unwanted diffs. Everything else looks fine.
> 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.3.diff.txt, Derby928.3.stat.txt, 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
[jira] Commented: (DERBY-928) Add ability to network server to
accept connections with a certain security mechanism.
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-928?page=comments#action_12366439 ]
Sunitha Kambhampati commented on DERBY-928:
-------------------------------------------
I was looking at the sysinfo information that we print from the server and this also prints information about the properties related to the server. I will update the patch to ensure information about this new property derby.drda.securityMechanism also gets reflected when calling sysinfo from server.
> 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
>
> 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
[jira] Commented: (DERBY-928) Add ability to network server to
accept connections with a certain security mechanism.
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-928?page=comments#action_12365369 ]
Sunitha Kambhampati commented on DERBY-928:
-------------------------------------------
Proposal as follows:
Property name: derby.drda.securityMechanism
Use this property to set the security mechanism accepted by the server. If this property is set, then client connections with the security mechanism equal to this property value will only be able to connect to the server.
This property will be static. Server must be restarted for the property to take effect.
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).
Syntax:
derby.drda.securityMechanism=securitymechanism
where securityMechanism can be one of the following values - USRIDONL, USRIDPWD,EUSRIDPWD.
E.g.
derby.drda.securityMechanism=USRIDONL // to accept connections at USRIDONL security mechanism
derby.drda.securityMechanism=EUSRIDPWD // to accept connections at EUSRIDPWD security mechanism
derby.drda.securityMechanism=USRIDPWD // to accept connections at USRIDPWD security mechanism
Question: Whats the best way to specify the values.
DRDA spec specifies the following secmec (securitymechanism) values.
USRIDONL = 4
USRIDPWD = 3
EUSRIDPWD = 9
>From client perspective:
Currently in the client url, one would have to pass in the integer value for securityMechanism.
ij>connect 'testdb;securityMechanism=9;user=sa;password=p1';
when using the datasource, the setSecurityMechanism(int) on the ClientDataSource can be used.
Constants are
ClientDataSource.CLEAR_TEXT_PASSWORD_SECURITY (0x03)
ClientDataSource.USER_ONLY_SECURITY (0x04)
ClientDataSource.ENCRYPTED_USER_AND_PASSWORD_SECURITY (0x09)
Given that there is different ways that the same value is represented, some possible ways to address this:
1) Go with integer values for the property.
e.g derby.drda.securityMechanism=9
This will mean the encrypted userid and password.
pros: consistent with what the client uses to set security mechanism in url when using drivermanager.
cons: It might be easy to make a mistake with setting number and the number by itself doesnt tell anything unless one looks up the spec/or the code.
2) Go with names used by ClientDataSource constants.
e.g. derby.drda.securityMechanism=ENCRYPTED_USER_AND_PASSWORD_SECURITY
so.
CLEAR_TEXT_PASSWORD_SECURITY would be same as drda's USRIDPWD
USER_ONLY_SECURITY would be same as drda's USRIDONL
ENCRYPTED_USER_AND_PASSWORD_SECURITY would be same as drda's EUSRIDPWD
pros: Use these names as it is consistent with the client datasource constants.
cons: names are too long
3) Use the drda secmec values itself.
USRIDONL, USRIDPWD,EUSRIDPWD.
pros: names are short and are the secmec values used in drda spec.
cons: names are somewhat cryptic.
4) A combination of #1 & #2. Support both integer values as well as string values.
requires more code for validity checking, otherwise ok.
I lean towards #2 to be consistent with names used to represent the same security mechanism in derby. Does this seem reasonable ?
I welcome any suggestions/comments on this. Thanks.
Future possible enhancements:
1) This property could be used to have a list of security mechanisms to allow instead of just one.
2) Allow a way to set the security mechanism value in client connection url as a string instead of integer.
==============================
Behavior:
- If the property is set to a value that is invalid/unsupported , it will be rejected and an error will be thrown when starting the server.
- if this property is not set, then the server will accept connections from client with security mechanisms that are currently supported by the server.
-Client sends ACCSEC with secmec (security mechanism) to use.
Server sees ACCSEC, reads the SECMEC value. It the server does not support the requested security mechanism, it returns a list of supported security mechanism otherwise the apprpriate reply data is generated for the requested security mechanism.
(Reference: Security flows are in DRDA manual, pg 96. Section 4.4.2.)
When server sees ACCSEC, 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.
I'd appreciate comments and suggestions. Thanks much for reading this.
> 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
> Fix For: 10.2.0.0
>
> 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
[jira] Updated: (DERBY-928) Add ability to network server to accept
connections with a certain security mechanism.
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-928?page=all ]
Sunitha Kambhampati updated DERBY-928:
--------------------------------------
Derby Info: [Release Note Needed]
Adding the release note needed flag. Information is in wiki http://wiki.apache.org/db-derby/SecurityMechanism I'll try to post the info in release note format.
> 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
> Issue Type: New Feature
> Components: Network Server
> Reporter: Sunitha Kambhampati
> Assigned To: Sunitha Kambhampati
> Fix For: 10.2.0.0
>
> Attachments: Derby928.3.diff.txt, Derby928.3.stat.txt, Derby928.diff.txt, Derby928.stat.txt, Derby928_canons.diff.txt, Derby928_canons.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
[jira] Assigned: (DERBY-928) Add ability to network server to
accept connections with a certain security mechanism.
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-928?page=all ]
Sunitha Kambhampati reassigned DERBY-928:
-----------------------------------------
Assign To: Sunitha Kambhampati
> 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
>
> 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
[jira] Resolved: (DERBY-928) Add ability to network server to
accept connections with a certain security mechanism.
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-928?page=all ]
Kathey Marsden resolved DERBY-928:
----------------------------------
Resolution: Fixed
Checked this into the trunk
Date: Wed Mar 1 05:55:05 2006
New Revision: 382019
URL: http://svn.apache.org/viewcvs?rev=382019&view=rev
The patch description was pretty big and cut over two comments so instead of cutting and pasting the description into the checkin comment I just referred to the comments in the bug.
> 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.3.diff.txt, Derby928.3.stat.txt, 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
[jira] Commented: (DERBY-928) Add ability to network server to
accept connections with a certain security mechanism.
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-928?page=comments#action_12365466 ]
Sunitha Kambhampati commented on DERBY-928:
-------------------------------------------
Thanks Bryan for your comments. Yes option #2 - USER_ONLY_SECURITY makes sense to me too.
In this jira I plan to add this server side property and take can take in values as USER_ONLY_SECURITY, etc. These will internally map to integer constants - the correct SECMEC values.
I agree the client connection url can be enhanced to take security mechanism as friendly string names and this should be possible with changes to the client side. I think the client connection url should allow even an integer value for the securityMechanism to allow for backward compatibility with older clients. I'll open a jira for this. 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
> Fix For: 10.2.0.0
>
> 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
[jira] Updated: (DERBY-928) Add ability to network server to accept
connections with a certain security mechanism.
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-928?page=all ]
Sunitha Kambhampati updated DERBY-928:
--------------------------------------
Attachment: (was: Derby928.3.diff.txt)
> 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.3.stat.txt, 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
[jira] Updated: (DERBY-928) Add ability to network server to accept
connections with a certain security mechanism.
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-928?page=all ]
Sunitha Kambhampati updated DERBY-928:
--------------------------------------
Attachment: Derby928_Table_SecurityMechanisms..htm
Table with the different possible server /client security mechanism interactions.
> 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
>
> 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
[jira] Commented: (DERBY-928) Add ability to network server to
accept connections with a certain security mechanism.
Posted by "Satheesh Bandaram (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-928?page=comments#action_12368788 ]
Satheesh Bandaram commented on DERBY-928:
-----------------------------------------
Sunitha, since this seems to add new functionality, should this entry be listed in DerbyDevActivities Wiki page? I think keeping that page accurate, while optional, will help ensure documentation and/or release note additions are done correctly for 10.2. Let me know if you need the Wiki URL, I am sure you know it. :)
> 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.3.diff.txt, Derby928.3.stat.txt, 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
[jira] Commented: (DERBY-928) Add ability to network server to
accept connections with a certain security mechanism.
Posted by "Andrew McIntyre (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-928?page=comments#action_12368818 ]
Andrew McIntyre commented on DERBY-928:
---------------------------------------
Committed new masters in patch Derby928_canons.diff.txt with revision 382975.
> 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.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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-928) Add ability to network server to accept
connections with a certain security mechanism.
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-928?page=all ]
Sunitha Kambhampati updated DERBY-928:
--------------------------------------
Other Info: [Patch available]
> 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
[jira] Commented: (DERBY-928) Add ability to network server to
accept connections with a certain security mechanism.
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-928?page=comments#action_12368780 ]
Kathey Marsden commented on DERBY-928:
--------------------------------------
I spoke with Sunitha briefly about the behaviour of old clients with this property and think there might be at least a release note needed. Sunitha could you summarize the behaviour of older clients, JCC and ODBC when derby.drda.securityMechanism is set?
Thanks
Kathey
> 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.3.diff.txt, Derby928.3.stat.txt, 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
Re: [jira] Updated: (DERBY-928) Add ability to network server to
accept connections with a certain security mechanism.
Posted by Sunitha Kambhampati <ks...@gmail.com>.
Bryan Pendleton wrote:
> I applied your patch to the current trunk successfully, and spot-checked
> a few of the various possibilities, and all seemed to be as you
> described, so I am able to confirm that your patch works for me.
>
Thanks Bryan for reviewing this patch.
> I had two follow-on questions, though:
>
> 1) On the client side, I was slightly surprised that this didn't
> give me an error or a warning:
>
> ij> connect
> 'jdbc:derby://localhost:1527/testdb;create=true;securityMechanism=4;user=bryan;password=bryan';
>
>
> Is it actually passing the password to the server? Or simply ignoring
> it on the client side?
So what is happening here is the client is doing the automatic upgrade
of the security mechanism. Even though you explicitly specified that the
securityMechanism=4, the client goes ahead and changes it to
securitymechanism 3 and then flows across the userid and password to the
server. The server sees a secmec value of 3 (which is clear text userid
and password).
Personally I dont like the override of the securityMechanism here. I
think if the user sets a particular securitymechanism we should be using
that or maybe at the very least give a warning that the security
mechanism was upgraded to so and so. Please share your thoughts. I
asked this question as part of DERBY-962.
Here is the client upgrade logic for security mechanisms ( this is also
in the html file in jira entry)
<>1) Default secmec value is 4.
2) If no user name is specified, default user is APP
3) If username and password specified, and secmec value specified
is 4(user_only_security), then upgrade security mechanism to
3(clear_text_password_security) Code in ClientBaseDataSource#
getUpgradedSecurityMechanism ()
4) In other cases, that don't satisfy case 1-3 and for security
mechanisms that the client thinks it supports, then the security
mechanism is just passed to the server.
(Just a note- the client accepts security mechanism for SECMEC_EUSRIDDTA
and SECMEC_EUSRPWDDTA that are not supported by server, but these will
still flow to the server and the server will reject them)
>
> 2) I was slightly surprised by the behavior of the 'not-set' column
> of your table. It seems like, if the property is not set on the server,
> then the server accepts any valid connection, regardless of security
> mechanism. That is, if I don't set the property, then the following
> script establishes 2 connections to the database:
>
> ij> connect
> 'jdbc:derby://localhost:1527/testdb;create=true;securityMechanism=4;user=bryan';
>
> ij> connect
> 'jdbc:derby://localhost:1527/testdb;create=true;securityMechanism=3;user=bryan;password=bryan';
>
>
In both these urls, since the property is not set, the server will
behave as it is today.. will accept the valid supported security mechanisms.
In the first case, Client will send a secmec value of 4 to the server
and server supports this mechanism so it will accept the connection
In the second case, Client will send a secmec value of 3 to the server,
and server supports this mechanism so it will accept the connection.
(Note security mechanisms of userid/password here are only for passing
the userid and password across the wire, they dont really do any
authentication checking at this point. Per the spec, it is assumed that
local services are available at the application server to accept the
userid/password and authenticate the user based on this information. )
> But if I set the derby.drda.securityMechanism property to a valid value,
> then the script establishes only the connection where the security
> mechanism matches, and the other(s) fail.
>
> So it seems like the behavior of the server with your patch is:
>
> - if derby.drda.securityMechanism is set to a valid mechanism, then
> the Network Server accepts *only* connections which use that
> security mechanism. No other types of connections are accepted
> - the derby.drda.securityMechanism is not set at all, then the
> Network Server accepts any connection which uses a valid
> security mechanism.
>
> Is that in fact the behavior that you expected and intended?
>
Thats right. That is the intended behavior of this patch. If this
property is not set, then the behavior of the server is the same as it
is today, accept valid connections for security mechanisms that it
supports.
In my patch, I had this comment in Property.java
+ * Use this property to set the security mechanism accepted by the server.
+ * If this property is set, then client connections with the security
+ * mechanism equal to this property value will only be able to connect
to the server.
....
+ * Default value for this property is as though it is not set - in
which case
+ * the server will allow clients with supported security mechanisms to
connect
But you put it so well, I think I will update my comments to reflect this.
Thanks.
Sunitha.
Re: [jira] Updated: (DERBY-928) Add ability to network server to
accept connections with a certain security mechanism.
Posted by Bryan Pendleton <bp...@amberpoint.com>.
Hi Sunitha,
Thanks very much for preparing the table of possibilities; that
makes things much clearer.
I applied your patch to the current trunk successfully, and spot-checked
a few of the various possibilities, and all seemed to be as you
described, so I am able to confirm that your patch works for me.
I had two follow-on questions, though:
1) On the client side, I was slightly surprised that this didn't
give me an error or a warning:
ij> connect 'jdbc:derby://localhost:1527/testdb;create=true;securityMechanism=4;user=bryan;password=bryan';
Is it actually passing the password to the server? Or simply ignoring
it on the client side?
2) I was slightly surprised by the behavior of the 'not-set' column
of your table. It seems like, if the property is not set on the server,
then the server accepts any valid connection, regardless of security
mechanism. That is, if I don't set the property, then the following
script establishes 2 connections to the database:
ij> connect 'jdbc:derby://localhost:1527/testdb;create=true;securityMechanism=4;user=bryan';
ij> connect 'jdbc:derby://localhost:1527/testdb;create=true;securityMechanism=3;user=bryan;password=bryan';
But if I set the derby.drda.securityMechanism property to a valid value,
then the script establishes only the connection where the security
mechanism matches, and the other(s) fail.
So it seems like the behavior of the server with your patch is:
- if derby.drda.securityMechanism is set to a valid mechanism, then
the Network Server accepts *only* connections which use that
security mechanism. No other types of connections are accepted
- the derby.drda.securityMechanism is not set at all, then the
Network Server accepts any connection which uses a valid
security mechanism.
Is that in fact the behavior that you expected and intended?
thanks,
bryan
Re: [jira] Updated: (DERBY-928) Add ability to network server to
accept connections with a certain security mechanism.
Posted by Sunitha Kambhampati <ks...@gmail.com>.
In the earlier mail in this thread, I had a table to explain the various
server/client security mechanism combinations. I hope the table got
rendered ok for people to read.
I will try to attach a html file with this information to jira. . I
tried to copy paste this mail to the jira entry but jira doesnt like the
table format.
Thanks,
Sunitha.
Sunitha Kambhampati wrote:
> Hi Bryan,
>
> Thanks for looking into this and your questions.
<snip - questions and responses and table>
Re: [jira] Updated: (DERBY-928) Add ability to network server to
accept connections with a certain security mechanism.
Posted by Bryan Pendleton <bp...@amberpoint.com>.
Hi Sunitha,
I haven't read the code yet; I was just reading your change notes. But
I had three questions:
1) If the server property is unset, and the client requests a valid
security mechanism, what is the expected behavior?
2) If the server property is set to a valid mechanism, and the client does
not specify a security mechanism, what is the expected behavior?
3) Is it possible for the server to support multiple security mechanisms
simultaneously (presumably with different clients)?
I'm trying to prepare a decision table in my head for all the various
combinations of server-specified mechanism and client-requested mechanism.
thanks,
bryan
[jira] Updated: (DERBY-928) Add ability to network server to accept
connections with a certain security mechanism.
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ 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
[jira] Commented: (DERBY-928) Add ability to network server to
accept connections with a certain security mechanism.
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-928?page=comments#action_12368229 ]
Kathey Marsden commented on DERBY-928:
--------------------------------------
I reviewed this patch and it looks good to me.
My only tiny point is that I kept having to look at the instances of this condition over and over to try to understand
what it meant, something about the double negative.
if ( (server.getSecurityMechanism() !=
NetworkServerControlImpl.INVALID_OR_NOTSET_SECURITYMECHANISM) ...
Maybe a boolean method: server.restrictsSecurityMechanism() or some such would be clearer.
I am running tests and will check in in the morning.
Thanks
Kathey
> 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.3.diff.txt, Derby928.3.stat.txt, 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
[jira] Updated: (DERBY-928) Add ability to network server to accept
connections with a certain security mechanism.
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-928?page=all ]
Sunitha Kambhampati updated DERBY-928:
--------------------------------------
Comment: was deleted
> 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
> Fix For: 10.2.0.0
>
> 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
[jira] Commented: (DERBY-928) Add ability to network server to
accept connections with a certain security mechanism.
Posted by "Deepa Remesh (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-928?page=comments#action_12368183 ]
Deepa Remesh commented on DERBY-928:
------------------------------------
I have reviewed and run tests with the latest version 'Derby928.3.diff.txt'. I ran derbynetmats and derbynetclientmats with Sun JDK1.4.2 on Windows XP. All tests passed. The patch looks good to me.
My +1 to commit this patch.
> 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.3.diff.txt, Derby928.3.stat.txt, 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
[jira] Updated: (DERBY-928) Add ability to network server to accept
connections with a certain security mechanism.
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-928?page=all ]
Sunitha Kambhampati updated DERBY-928:
--------------------------------------
Attachment: Derby928.3.stat.txt
Derby928.3.diff.txt
http://www.nabble.com/-jira-Created%3A-%28DERBY-928%29-Add-ability-to-network-server-to-accept-connections-with-a-certain-security-mechanism.-t1073183.html
Thanks very much Deepa for reviewing this issue.
Some changes went into testSecMec.java which is why this file wouldnt apply cleanly with the earlier patch. I merged my changes and am attaching a new patch (Derby928.3.diff.txt). Please take a look.
The only changes in Derby928.3.diff.txt compared to the earlier Derby928.v2.diff.txt is
-- Added comment to link to DERBY-928 html table and also comments to runtest. Also enhanced test to avoid case of DERBY-300.
-- made one master file for both DerbyNet and DerbyNetClient for sysinfo_withproperties.out
Ran derbynet/testSecMec.java with classes on ibm131/ibm141/ibm142/ibm15/jdk131/jdk141/jdk15/jdk142 OK.
Ran derbynetclientmats and derbynetmats on linux/ibm142 ok (with known failures)
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.3.diff.txt, Derby928.3.stat.txt, 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
[jira] Commented: (DERBY-928) Add ability to network server to
accept connections with a certain security mechanism.
Posted by "Bryan Pendleton (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-928?page=comments#action_12365456 ]
Bryan Pendleton commented on DERBY-928:
---------------------------------------
I'd prefer the friendly string names (USER_ONLY_SECURITY, etc.).
Actually, I'd prefer to use the friendly string names for *both* the server property and the client URL, but you didn't mention whether that was an option or not. I find "connect 'testdb;securityMechanism=9'" to be unappealing.
> 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
> Fix For: 10.2.0.0
>
> 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
[jira] Commented: (DERBY-928) Add ability to network server to
accept connections with a certain security mechanism.
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-928?page=comments#action_12365465 ]
Sunitha Kambhampati commented on DERBY-928:
-------------------------------------------
Thanks Byran for your comments. Yes option #2 - USER_ONLY_SECURITY makes sense to me too.
In this jira I plan to add this server side property and take can take in values as USER_ONLY_SECURITY, etc. These will internally map to integer constants - the correct SECMEC values.
I agree the client connection url can be enhanced to take security mechanism as friendly string names and this should be possible with changes to the client side. I think the client connection url should allow even an integer value for the securityMechanism to allow for backward compatibility with older clients. I'll open a jira for this. 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
> Fix For: 10.2.0.0
>
> 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
[jira] Updated: (DERBY-928) Add ability to network server to accept
connections with a certain security mechanism.
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-928?page=all ]
Sunitha Kambhampati updated DERBY-928:
--------------------------------------
Attachment: Derby928_canons.diff.txt
Derby928_canons.stat.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: 10.2.0.0
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-928) Add ability to network server to accept
connections with a certain security mechanism.
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-928?page=all ]
Sunitha Kambhampati updated DERBY-928:
--------------------------------------
Attachment: Derby928.3.diff.txt
Removed the unwanted space diffs. Ran test derbynet/testSecMec.java with ibm131/ibm141/ibm142/ibm15 as well as the sun jvms. Please look at this patch. 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.3.diff.txt, Derby928.3.stat.txt, 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
[jira] Commented: (DERBY-928) Add ability to network server to
accept connections with a certain security mechanism.
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-928?page=comments#action_12434846 ]
Sunitha Kambhampati commented on DERBY-928:
-------------------------------------------
Not quite sure if we want a release note for this new property that is being added in 10.2, as this is documented in the server guide. Kathey had suggested in one of her comments that we should probably mention the impact on older clients.
I started to write the release note in the release note format and it didnt seem appropriate for this case. So I just took a shot at adding some info for the release note.
I'd appreciate comments/suggestions on what other info we would want to include in the release note for this issue.
First draft at release note info.
=========================
With 10.2 release, Derby provides a server property derby.drda.securityMechanism to restrict securityMechanisms accepted from the client. This property is not set by default and thus will not have any impact on existing older clients (JCC, 10.1 derby client, odbc client).
If the 10.2 server is started with derby.drda.securityMechanism property set to a valid security mechanism, the Network Server will accept only connections from clients which use that security mechanism. No other types of connections are accepted. For e.g. If the client sends a securityMechanism that is not accepted by the server, the error message at the JCC client will look similar to this "Connection authorization failure occurred. Reason: security mechanism not supported" and with Derby client, it will look like this "Connection authentication failure occurred. Reason: security mechanism not supported."
==========================
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
> Issue Type: New Feature
> Components: Network Server
> Reporter: Sunitha Kambhampati
> Assigned To: Sunitha Kambhampati
> Fix For: 10.2.1.0
>
> Attachments: Derby928.3.diff.txt, Derby928.3.stat.txt, Derby928.diff.txt, Derby928.stat.txt, Derby928_canons.diff.txt, Derby928_canons.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
[jira] Updated: (DERBY-928) Add ability to network server to accept
connections with a certain security mechanism.
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-928?page=all ]
Rick Hillegas updated DERBY-928:
--------------------------------
Derby Info: (was: [Release Note Needed])
Toggling off the "release note needed flag" since I'm already tracking this issue on the 10.2 snapshot wiki page.
> 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
> Issue Type: New Feature
> Components: Network Server
> Reporter: Sunitha Kambhampati
> Assigned To: Sunitha Kambhampati
> Fix For: 10.2.1.0
>
> Attachments: Derby928.3.diff.txt, Derby928.3.stat.txt, Derby928.diff.txt, Derby928.stat.txt, Derby928_canons.diff.txt, Derby928_canons.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
[jira] Updated: (DERBY-928) Add ability to network server to accept
connections with a certain security mechanism.
Posted by "Sunitha Kambhampati (JIRA)" <de...@db.apache.org>.
[ 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