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] Commented: (DERBY-928) Add ability to network server to accept connections with a certain security mechanism.
Date Thu, 14 Sep 2006 23:24:23 GMT
    [ 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."



> 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:
>         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


View raw message