Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <8754303.1158276263401.JavaMail.jira@brutus>
Date: Thu, 14 Sep 2006 16:24:23 -0700 (PDT)
From: "Sunitha Kambhampati (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-928) Add ability to network server to
 accept connections with a certain security mechanism.
In-Reply-To: <25830880.1139272977310.JavaMail.jira@ajax.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ 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