This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 200406 - Keyring implementation based on Oracle Wallet
Summary: Keyring implementation based on Oracle Wallet
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Options&Settings (show other bugs)
Version: 7.0
Hardware: All All
: P3 normal (vote)
Assignee: Jesse Glick
URL:
Keywords: PLAN
Depends on:
Blocks:
 
Reported: 2011-07-27 00:01 UTC by Jesse Glick
Modified: 2011-07-27 16:45 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2011-07-27 00:01:44 UTC

    
Comment 1 Jesse Glick 2011-07-27 00:04:05 UTC
Will create a module for it in main, but will just put it in the experimental cluster to start with.
Comment 2 Jesse Glick 2011-07-27 00:08:40 UTC
core-main #1f41569f0c53
Comment 3 Quality Engineering 2011-07-27 14:07:18 UTC
Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/1f41569f0c53
User: Jesse Glick <jglick@netbeans.org>
Log: #200406: Keyring implementation based on Oracle Wallet
Comment 4 Jesse Glick 2011-07-27 16:45:57 UTC
How to test:

1. Install JDeveloper 11g (11.1.1.5.0) Studio Edition and opt for a "complete" installation. Not sure if you need to include WebLogic, but I did. The relevant files are actually not in the JDev/ADF subdir but in "Common Infrastructure Engineering".

2. Run the IDE and install the "Oracle Wallet Integration" plugin from dev AU.

3. In Tools > Options > Miscellaneous > Oracle Wallet, enter the paths for "JPS Config File" and "JPS Implementation" according to the examples, to be found beneath the JDev root install dir.

4. Restart the IDE (in case you have accessed the standard OS keyring already).

5. Do something requiring keyring access, e.g. logging in to nb.org Bugzilla.

6. Shut down and start up again and verify that the password from the previous session was remembered.

I tried to at least view the resulting wallet using Oracle Wallet Manager (product/11.2.0/dbhome_1/bin/owm in an 11gR2 database installation), but it simply refused to open it, for no clear reason. It would only open the wallet in the default location (which I was unable to make JPS write to). 'sh oracle_common/bin/orapki wallet display -wallet oracle_common/modules/oracle.jps_11.1.1/domain_config/cwallet.sso' does however seem to work.

Regarding level of security: the cwallet.sso does not appear to contain any information in cleartext. However no password is required to read and write it using the JPS API (nor is there any apparent place in that API where a master password would be accepted). http://www.oracle.com/technetwork/database/focus-areas/security/tde-faq-093689.html#A13016 claims that "Oracle Database 11g Release 2 introduced the local auto-open wallet, which only opens automatically on the server it was created on"; a different kind of file "ewallet.p12" is apparently created when you do not use auto-login, but JPS appears to ignore these. When I ran 'chmod -R go+w oracle_common/modules/oracle.jps_11.1.1/domain_config' and ran the orapki display command using another user ID, it still succeeded; indeed that succeeded even without write permission, or from a Linux console with no environment variables from my regular login. While that command does not display actual passwords, it does display the keys, so apparently the wallet is merely obfuscated and can be opened just by using Unix read permissions, unlike OS keyrings which are tied to the login session. http://www.art2dec.com/documentation/docs/fmw11g1114documentation/core.1111/e10105/wallets.htm#CIHHAHHF backs up this assessment. Therefore I would not consider this keyring mode to provide an acceptable level of security for most users, unless some way can be found to access an encrypted wallet from JPS - unlocked either transparently from the login session, or via explicit password entry in the IDE (as with the existing fallback "master password encryption").