[ http://issues.apache.org/jira/browse/DERBY-528?page=all ]
Francois Orsini updated DERBY-528:
----------------------------------
Attachment: 528_stat_v4.txt
528_diff_v4.txt
Sunitha, many thanks for this excellent and thorough review.
I've addressed all of the comments - I've run derbyall as well as
derbynet/testSecMec.java and derbynet/dataSourcePermissions_net.java under
different JVM's.
> Spurious diffs because of tabs/spaces etc
Took care of them.
> Additional testing with securityMechanism=8 and BUILTIN
When I had USRSSBPWD upgraded by default, it was exercised a lot more,
throughout testSecMec.java and dataSourcePermissions_net.java
I have added a new test as part of testSecMec.java - method is
testUSRSSBPWD_with_BUILTIN()
a) Actually, these are internal connection attributes, which are passed on the
connection URL. There really are connection attributes except that they are not
exposed - in a similar way as the DRDAID_ATTR attribute. Some attributes such
as CRYPTO_EXTERNAL_KEY_VERIFY_FILE and referenced in DERBY-1151 are not.
b) The 2 checks are necessary as support for USRSSBPWD SecMec only works if
Derby's authentication scheme is BUILTIN or NONE. It has to be done this way as
we cannot risk to go ahead and fail authenticating against the Derby engine
later during parseSECCHK() - As the password substitute cannot be decrypted, I
know for sure that I can regenerate it via the updated BUILTIN scheme which now
gets support for it - And as far as the NONE authentication scheme, we do not
care as we never check the password, so the password substitute will never get
checked...This has to be checked/verified early enough and hence why it is
being done during parseACCSEC().
c) Yes, dataSource_.getUser() can be different than
dataSource_.propertyDefault_user if a non-null user is specified as part of the
getConnection() in ClientDataSource or/and if some connectionAttributes are set
via setConnectionAttributes() - also, datasource values can
be updated when updateDataSourceValues() gets called in
ClientDataSource.getConnection() - I did not want to update user_ as the
processing of USRSSBPWD is pretty isolated - I think I could do it but I might
want to treat it as a separate JIRA for the simple reason that even with other
DRDA security mechanism such as EUSRIDPWD, we keep encrypting the original
userName and not the one that gets passed via connection attributes...I think
this needs to be addressed as a separate JIRA which I will enter to also fix
the current behavior with some other SecMec...This of course, will *not* have
any impact on the user authentication.
Issues:
1) I had noted that one as well- I have fixed both EncryptionManager.java and
AuthenticationServiceBase.java to use toHexByte() instead.
2) I removed it because it was duplicated and therefore set twice in the the
updateDataSourceValues() method
3) Took care of them all
4) Took care of them all - going to enter a JIRA for the toHexByte, toHexString
methods to be reconciled into one location when we have fully
addressed the code sharing aspect of things.
Ensured Javadoc was generated properly.
Thanks.
Am hoping Kathey can run testSecMec with JCC 2.6 and 2.8 and generate the 2
additional testSecMec.out master canon output files for DerbyNet...
> Support for DRDA Strong User ID and Password Substitute Authentication
> (USRSSBPWD) scheme
> -----------------------------------------------------------------------------------------
>
> Key: DERBY-528
> URL: http://issues.apache.org/jira/browse/DERBY-528
> Project: Derby
> Issue Type: New Feature
> Components: Security
> Affects Versions: 10.1.1.0
> Reporter: Francois Orsini
> Assigned To: Francois Orsini
> Fix For: 10.2.0.0
>
> Attachments: 528_diff_v1.txt, 528_diff_v2.txt, 528_diff_v3.txt,
> 528_diff_v4.txt, 528_SecMec_Testing_Table.txt, 528_stat_v1.txt,
> 528_stat_v2.txt, 528_stat_v3.txt, 528_stat_v4.txt
>
>
> This JIRA will add support for (DRDA) Strong User ID and Password Substitute
> Authentication (USRSSBPWD) scheme in the network client/server driver layers.
> Current Derby DRDA network client driver supports encrypted userid/password
> (EUSRIDPWD) via the use of DH key-agreement protocol - however current Open
> Group DRDA specifications imposes small prime and base generator values (256
> bits) that prevents other JCE's to be used as java cryptography providers -
> typical minimum security requirements is usually of 1024 bits (512-bit
> absolute minimum) when using DH key-agreement protocol to generate a session
> key.
> Strong User ID and Password Substitute Authentication (USRSSBPWD) is part of
> DRDA specifications as another alternative to provide ciphered passwords
> across the wire.
> Support of USRSSBPWD authentication scheme will enable additional JCE's to
> be used when encrypted passwords are required across the wire.
> USRSSBPWD authentication scheme will be specified by a Derby network client
> user via the securityMechanism property on the connection UR - A new property
> value such as ENCRYPTED_PASSWORD_SECURITY will be defined in order to support
> this new (DRDA) authentication scheme.
--
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
