Re: [jira] Updated: (DERBY-928) Add ability to network server to accept connections with a certain security mechanism.

[Sunitha Kambhampati]

Hi Bryan, Thanks for looking into this and your questions.  Bryan Pendleton wrote: 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? The server property is static, so it will take effect only when the server is restarted.  Thus if you unset the property when server is running, it will have no effect on the server. This property is read when server is started and the value is stored in the variable 'allowOnlySecurityMechanism'. The only place this variable is set is when reading the system properties ( getPropertyInfo which is called when initializing the NetworkServerControlImpl). E.g.  if server is started with -Dderby.drda.securityMechanism=ENCRYPTED_USER_AND_PASSWORD_SECURITY and unset when server is running by removing it in derby.properties or any other way, the change of unset will have no effect on the running server. Only clients sending a security mechanism of value 9 which is equal to the ENCRYPTED_USER_AND_PASSWORD_SECURITY will be accepted by server. 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? Good question. Please note, this  patch does not make any changes to the client behavior.  Currently this is how derby client behaves: -- the default security mechanism on the client is USER_ONLY_SECURITY (0x4). If client url does not have a userid, client defaults to user 'APP'. -- but there is an automatic upgrade happening on the client side ( code in ClientBaseDataSource# getUpgradedSecurityMechanism() )  and the condition for upgrade is as follows:  if connection url has both userid and password  and if security mechanism is USER_ONLY_SECURITY(0x4) then upgrade security mechanism to CLEAR_TEXT_PASSWORD_SECURITY ( 0x3). Actually even if a security mechanism is explicitly specified in the connection url, the upgrade happens.  I posted this question as part of DERBY-962 . http://issues.apache.org/jira/browse/DERBY-962?page=comments#action_12366173   3) Is it possible for the server to support multiple security mechanisms simultaneously (presumably with different clients)? This patch does not support multiple security mechanism to be specified as part of the derby.drda.securityMechanism.  But I think it is a good thing to support and have listed this as a future enhancement in my proposal. I'm trying to prepare a decision table in my head for all the various combinations of server-specified mechanism and client-requested mechanism. I should have posted this along with the description to help make it more clear. sorry.  Here is the table. #Nos Client connection url (only some relevant attributes shown) Client sends secmec value Not set Server started with derby.drda.securityMechanism= USER_ONLY_SECURITY (0x4) Server started with derby.drda.securityMechanism= CLEAR_TEXT_PASSWORD_SECURITY (0x3) Server started with derby.drda.securityMechanism= ENCRYPTED_USER_AND_PASSWORD_SECURITY (0x9) A db;user=a 0x04 Server says OK Server says OK Server rejects this. Server rejects this B Db;user=a;password=p 0x03 Server says OK Server rejects this. Server says OK Server rejects this. C Db;user=a;securityMechanism=4 0x04 Server says OK Server says OK Server rejects this. Server rejects this D Db;user=a;password=p;securityMechanism=4 0x03 Server says OK Server rejects this Server says OK Server rejects this. E Db;user=a;password=p;securityMechanism=3 0x03 Server says OK Server rejects this Server says OK Server rejects this. F Db;user=a;password=p;securityMechanism=9 0x09 Server says OK Server rejects this Server rejects this Server says OK. G Db;user=a;password=p;securityMechanism=12 0x12 Protocol error, DERBY926 Server rejects this Server rejects this Server rejects this H Db; 0x04 Server says OK Server says OK Server rejects this.  Server rejects this The network server supports currently the following security mechanisms: <>USER_ONLY_SECURITY CLEAR_TEXT_PASSWORD_SECURITY ENCRYPTED_USER_AND_PASSWORD_SECURITY <> But note, that the encrypted userid password case will not work with sun jce because the prime that the DH algorithm needs per the DRDA spec is not supported in sun jce. <> When working on this jira, I had a couple ideas of maybe if server is running with sun jce, we should not say we support the encrypted userid & password case, and another thing would be it seems like if server rejects the secmec value but instead sends a list of supported secmec values the client can decide if it wants to use one of those server supported secmec values to connect.  We currently don’t have this  support in the client. Some more security mechanism related jira entries  DERBY-962,963 Thanks again for reviewing this. Sunitha.