Author: jonesde
Date: Wed Mar 17 03:51:54 2010
New Revision: 924141
URL: http://svn.apache.org/viewvc?rev=924141&view=rev
Log:
Updated the comment to reflect more details in the jdbcPassword encryption
problem, based on mailing list comments and will hopefuly clarify this more
Modified:
ofbiz/branches/multitenant20100310/framework/entity/entitydef/entitymodel.xml
Modified:
ofbiz/branches/multitenant20100310/framework/entity/entitydef/entitymodel.xml
URL:
http://svn.apache.org/viewvc/ofbiz/branches/multitenant20100310/framework/entity/entitydef/entitymodel.xml?rev=924141&r1=924140&r2=924141&view=diff
==============================================================================
---
ofbiz/branches/multitenant20100310/framework/entity/entitydef/entitymodel.xml
(original)
+++
ofbiz/branches/multitenant20100310/framework/entity/entitydef/entitymodel.xml
Wed Mar 17 03:51:54 2010
@@ -85,8 +85,19 @@ under the License.
because different tenants will have different sets of encryption
keys because the EntityKeyStore table is
in the per-tenant database an not in the shared tenant control
database, which causes different keys to
be used for those logged in under different tenants, causing
decryption errors unless you do all
- TenantDataSource maintenance from only one tenant (or the
non-tenant master db). Removing that for now
- until this issue is resolved, possibly by moving the
EntityKeyStore entity into the tenant database. -->
+ TenantDataSource maintenance from only one tenant (or the
non-tenant master db).
+
+ The problem is that each tenant has their own encryption keys, and
that is they way it should be since
+ having easy access to the encryption keys that other tenants are
using would be bad, and not having access
+ to your own encryption keys would also be bad. Because of that we
can't move the EntityKeyStore entity
+ into the tenant control database. If we encrypt this with the keys
from one tenant then no one logged in
+ with another tenant database will be able to decrypt it, so we
can't use the keys in the per-tenant
+ databases for this.
+
+ Technically we don't have to encrypt the JDBC password, it often
isn't encrypted in the configuration
+ files anyway. But it would be nice to encrypt it to protect other
databases anyway, even if they are
+ probably on the same box and in the same database server instance.
+ -->
</field>
<prim-key field="tenantId"/>
<prim-key field="entityGroupName"/>
