Re: svn commit: r923939 - /ofbiz/branches/multitenant201
Locked
Re: svn commit: r923939 - /ofbiz/branches/multitenant201
 
|
[hidden email] wrote:
> Author: jonesde > Date: Tue Mar 16 19:02:06 2010 > New Revision: 923939 > > URL: http://svn.apache.org/viewvc?rev=923939&view=rev > Log: > Removed encrypt=true for the jdbc password with a comment about why; encrypting this field can be reintroduced, preferably when that issue is resolved > > 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=923939&r1=923938&r2=923939&view=diff > ============================================================================== > --- ofbiz/branches/multitenant20100310/framework/entity/entitydef/entitymodel.xml (original) > +++ ofbiz/branches/multitenant20100310/framework/entity/entitydef/entitymodel.xml Tue Mar 16 19:02:06 2010 > @@ -80,7 +80,14 @@ under the License. > <field name="entityGroupName" type="name"/> > <field name="jdbcUri" type="long-varchar"/> > <field name="jdbcUsername" type="long-varchar"/> > - <field name="jdbcPassword" type="long-varchar" encrypt="true"/> > + <field name="jdbcPassword" type="long-varchar"> > + <!-- This field should probably be encrypted, but the encrypt=true attribute will not work in this case > + 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. --> > + </field> > <prim-key field="tenantId"/> > <prim-key field="entityGroupName"/> > <relation type="one" fk-name="TNTDTSRC_TNT" rel-entity-name="Tenant"> > If the username matches, then do a pre-emptive looking into the tenant database, to find the right key, then go back and do a decrypt? Of course, you may already be thinking that, but this code is not just as simple as snapping one's fingers. |
Re: svn commit: r923939 - /ofbiz/branches/multitenant201
|
|
On Mar 16, 2010, at 2:13 PM, Adam Heath wrote: > [hidden email] wrote: >> Author: jonesde >> Date: Tue Mar 16 19:02:06 2010 >> New Revision: 923939 >> >> URL: http://svn.apache.org/viewvc?rev=923939&view=rev >> Log: >> Removed encrypt=true for the jdbc password with a comment about why; encrypting this field can be reintroduced, preferably when that issue is resolved >> >> 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=923939&r1=923938&r2=923939&view=diff >> ============================================================================== >> --- ofbiz/branches/multitenant20100310/framework/entity/entitydef/entitymodel.xml (original) >> +++ ofbiz/branches/multitenant20100310/framework/entity/entitydef/entitymodel.xml Tue Mar 16 19:02:06 2010 >> @@ -80,7 +80,14 @@ under the License. >> <field name="entityGroupName" type="name"/> >> <field name="jdbcUri" type="long-varchar"/> >> <field name="jdbcUsername" type="long-varchar"/> >> - <field name="jdbcPassword" type="long-varchar" encrypt="true"/> >> + <field name="jdbcPassword" type="long-varchar"> >> + <!-- This field should probably be encrypted, but the encrypt=true attribute will not work in this case >> + 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. --> >> + </field> >> <prim-key field="tenantId"/> >> <prim-key field="entityGroupName"/> >> <relation type="one" fk-name="TNTDTSRC_TNT" rel-entity-name="Tenant"> >> > > If the username matches, then do a pre-emptive looking into the tenant > database, to find the right key, then go back and do a decrypt? > > Of course, you may already be thinking that, but this code is not just > as simple as snapping one's fingers. I'm not sure what you mean by this. 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. -David |
Re: svn commit: r923939 - /ofbiz/branches/multitenant201
|
|
David E Jones wrote:
> On Mar 16, 2010, at 2:13 PM, Adam Heath wrote: > >> [hidden email] wrote: >>> Author: jonesde >>> Date: Tue Mar 16 19:02:06 2010 >>> New Revision: 923939 >>> >>> URL: http://svn.apache.org/viewvc?rev=923939&view=rev >>> Log: >>> Removed encrypt=true for the jdbc password with a comment about why; encrypting this field can be reintroduced, preferably when that issue is resolved >>> >>> 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=923939&r1=923938&r2=923939&view=diff >>> ============================================================================== >>> --- ofbiz/branches/multitenant20100310/framework/entity/entitydef/entitymodel.xml (original) >>> +++ ofbiz/branches/multitenant20100310/framework/entity/entitydef/entitymodel.xml Tue Mar 16 19:02:06 2010 >>> @@ -80,7 +80,14 @@ under the License. >>> <field name="entityGroupName" type="name"/> >>> <field name="jdbcUri" type="long-varchar"/> >>> <field name="jdbcUsername" type="long-varchar"/> >>> - <field name="jdbcPassword" type="long-varchar" encrypt="true"/> >>> + <field name="jdbcPassword" type="long-varchar"> >>> + <!-- This field should probably be encrypted, but the encrypt=true attribute will not work in this case >>> + 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. --> >>> + </field> >>> <prim-key field="tenantId"/> >>> <prim-key field="entityGroupName"/> >>> <relation type="one" fk-name="TNTDTSRC_TNT" rel-entity-name="Tenant"> >>> >> If the username matches, then do a pre-emptive looking into the tenant >> database, to find the right key, then go back and do a decrypt? >> >> Of course, you may already be thinking that, but this code is not just >> as simple as snapping one's fingers. > > I'm not sure what you mean by this. You're right. I read it wrong. I thought this was the user login password field needed to be encrypted in the tenant database. Sorry about that. (I still haven't had time to look at the branch) |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |