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.
