[
https://issues.apache.org/jira/browse/GERONIMO-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jack Cai updated GERONIMO-3003:
-------------------------------
Attachment: GERONIMO-3003.patch
Creating a patch for the trunk. If it is accepted well, I'll create a patch for
2.1 branch too.
The current design is -
1. Developers can specify a String type attribute of a GBean as "encrypted",
either through API or annotation. Encrypted attributes are encrypted when
marshalled, e.g., serialized to config.ser. It will also get encrypted when
saved into the server's config.xml.
2. By default, GBean attributes are not encrypted except those whose name
contains the string "password" (ignore case) and whose type is java.lang.String.
Since the patch is pretty big and affects quite a few files, please help to
review and commit it soon. I hope it will make into G2.2 release. Thanks!
> Encrypt password strings in deployment plans
> --------------------------------------------
>
> Key: GERONIMO-3003
> URL: https://issues.apache.org/jira/browse/GERONIMO-3003
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: deployment
> Affects Versions: Wish List
> Reporter: Aman Nanner
> Assignee: Jack Cai
> Priority: Minor
> Fix For: Wish List
>
> Attachments: GERONIMO-3003.patch
>
>
> Geronimo currently has a feature where password strings in the config.xml get
> encrypted using the {{org.apache.geronimo.util.EncryptionManager}}. This
> encryption is performed in the
> {{org.apache.geronimo.system.configuration.GBeanOverride}} class.
> It would be desirable to have the same encryption applied to the password
> strings in deployment plans (e.g. datasource or JMS deployment plans within
> an EAR). Even though the plans are only used during the deployment process,
> and not at runtime, the plans are left with plaintext password strings
> sitting in them. It would be nice if the deployment process could internally
> encrypt the strings and then write back out the deployment plan to the file
> system. Also, this means that the deployment process will require the
> ability to decrypt strings that are already in encrypted format in the plan
> (in the case of redeployment, for example).
> More discussion of this feature can be found in the following mailing list
> thread:
> http://www.mail-archive.com/u...@geronimo.apache.org/msg05859.html
> I would suggest that an appropriate spot to perform the encryption is in the
> {{org.apache.geronimo.j2ee.deployment.EARConfigBuilder}} class, perhaps in
> the following code just before the file is written to a temporary file:
> ----
> if (gerModule.isSetAltDd()) {
> // the the url of the alt dd
> try {
> altVendorDDs.put(path,
> DeploymentUtil.toTempFile(earFile, gerModule.getAltDd().getStringValue()));
> } catch (IOException e) {
> throw new DeploymentException("Invalid alt vendor
> dd url: " + gerModule.getAltDd().getStringValue(), e);
> }
> ----
> However, somebody more familiar with the design might be able to suggest a
> better solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
