db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sunitha Kambhampati <ksunitha...@gmail.com>
Subject Re: [jira] Updated: (DERBY-928) Add ability to network server to accept connections with a certain security mechanism.
Date Wed, 15 Feb 2006 18:31:43 GMT
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 

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 

But you put it so well, I think I will update my comments to reflect this.


View raw message