You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Francois Orsini (JIRA)" <de...@db.apache.org> on 2006/08/07 21:10:17 UTC
[jira] Updated: (DERBY-528) Support for DRDA Strong User ID and
Password Substitute Authentication (USRSSBPWD) scheme
[ 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