Apache JDO Project - jdo security revamped proposal

Author

jdo security revamped proposal

Erik Bengtson

2007-11-05, 7:11 pm

Hi,

After negative feedback, I have a different proposal for securing JDO
resources.
Different from my initial proposal using declarative security (XML), here I
propose using the standard Java security.
The example is self-explaining:

--- Persistent Class sample:
package com.petstore;

class Pet
{
String name;
}

--- Security policy sample:

grant principal "bart"
{
permission javax.jdo.spi.JDODataPermission "/com/petstore/Pet[@name='dog']",
"read,write";
}

grant
{
permission javax.jdo.spi.JDODataPermission "/com/package", "read";
permission javax.jdo.spi.JDODataPermission "/com/petstore/Pet", "read";
};

--- javax.jdo.spi.JDODataPermission:

javax.jdo.spi.JDODataPermission(String name, String actions);

--- PMF/System property that will enable/disable security checks by the JDO
implementation
javax.jdo.security.manager=false|true

The only particularity of my proposal is the name argument for
JDODataPermission that uses Xpath.

Regards,

Matthew Adams

2007-11-05, 7:11 pm

Hi Erik,

While I think this is an ingenious use of Java platform security, I
can't see it in the 2.1 timeframe.

Even if we consider it for a later release, I am not convinced that
this should be **the** way to secure PC instances. This proposal
doesn't clearly address, IMHO, the case where you may want to support
a use case wherein a domain object itself represents a principal, so
that you can dynamically assign permissions at runtime. For example,
I don't see how you can use this proposal to enforce that the User
instance associated with Person "Bob" represents a principal, and
when the principal of the security context of the current thread is
Bob's User instance, he can access all salary and wage fields of all
Employment instances.

Further, is there a way to explicitly **deny** access to a particular
PC? For example, I don't see how you can use this proposal to
enforce that the User instance associated with Person "Bob"
represents a principal, and when the principal of the security
context of the current thread is Bob's User instance, he can access
all salary and wage fields of all Employment instances except those
associated with Employee instances associated with Person instances
"Sally" and "Joe".

As a bit of positive feedback, I would suggest ditching XPath for
some kind of "OPath" (JDOPath?) that supports indexing collections
and maps (dots instead of slashes, square bracket operators for list/
map indexing).

-matthew

On Nov 5, 2007, at 12:14 PM, Erik Bengtson wrote:

> Hi,
>
> After negative feedback, I have a different proposal for securing JDO
> resources.
> Different from my initial proposal using declarative security
> (XML), here I
> propose using the standard Java security.
> The example is self-explaining:
>
> --- Persistent Class sample:
> package com.petstore;
>
> class Pet
> {
> String name;
> }
>
> --- Security policy sample:
>
> grant principal "bart"
> {
> permission javax.jdo.spi.JDODataPermission "/com/petstore/Pet
> [@name='dog']",
> "read,write";
> }
>
> grant
> {
> permission javax.jdo.spi.JDODataPermission "/com/package", "read";
> permission javax.jdo.spi.JDODataPermission "/com/petstore/Pet",
> "read";
> };
>
> --- javax.jdo.spi.JDODataPermission:
>
> javax.jdo.spi.JDODataPermission(String name, String actions);
>
> --- PMF/System property that will enable/disable security checks by
> the JDO
> implementation
> javax.jdo.security.manager=false|true
>
> The only particularity of my proposal is the name argument for
> JDODataPermission that uses Xpath.
>
> Regards,
>
>
>
>
>
>
>
>

Erik Bengtson

2007-11-06, 7:11 am

TWF0dGhldywgSSBkb24ndCB1bmRlcnN0YW5kIHlv
dXIgcXVlc3Rpb25zIHZlcnkgd2VsbC4gDQoN
CkxldCBtZSBleHBsYWluIHNvbWUgcG9pbnRzOg0K
DQpBcyBwZXIgSmF2YSBzZWN1cml0eSwgdW5s
ZXNzIHlvdSBncmFudCBwZXJtaXNzaW9ucyB5b3Ug
ZG9uJ3QgaGF2ZSBhY2Nlc3MgdG8gdGhlIGRh
dGEvZmllbGRzL2luc3RhbmNlcy4NCg0KQ2hlY2sg
cG9pbnRzIGFyZSBwbGFjZWQgaW4gc3RhdGUg
bWFuYWdlcnMvIHF1ZXJ5ICwgc28gdGhleSBhc3Nl
cnQgYmFzZWQgb24gY3VycmVudCBzZWN1cml0
eSBjb250ZXh0IHRoZSBhY3Rpb25zIHVwb24gaW5z
dGFuY2VzL2ZpZWxkcyBhcmUgYXV0aG9yaXpl
ZC4gIA0KDQpEeW5hbWljcywgaW4gSjJFRSB5b3Ug
Y2FuIGFsd2F5cyBkZXBsb3kgYSBzZWN1cml0
eSBwb2xpY3kgd2l0aGluIGRlcGxveW1lbnQgZGVz
Y3JpcHRvcnMsIGJ1dCB5b3UgbmVlZCB0byBy
ZWRlcGxveSB0aGUgYXBwbGljYXRpb24gLg0KSW4g
SjJFRSwgQWRkaW5nIHBlcm1pc3Npb25zIChl
amIsIHNlcnZsZXRzKWF0IHJ1bnRpbWUgaXMgZG9u
ZSB2aWEgSkFDQywgYnV0IGl0IEkgZG9uJ3Qg
a25vdyBhbnkgY29udGFpbmVyIHRoYXQgYWxsb3dz
IGNvbnNvbGUgYmFzZWQgcGVybWlzc2lvbnMg
bW9kaWZpY2F0aW9ucywgYnV0IHJlYWRpbmcgZGVw
bG95bWVudCBkZXNjcmlwdG9ycyBkdXJpbmcg
ZGVwbG95bWVudC4gVGhhdCBtZWFucyBJIGRvbid0
IHRoaW5rIHdlIGNhbiBoYXZlIGR5bmFtaWMg
c2VjdXJpdHkgcGVybWlzc2lvbnMsIGJ1dCB5b3Ug
Y2FuIGFsd2F5cyByZWRlcGxveSB5b3VyIGFw
cGxpY2F0aW9uLg0KDQoNCg0KDQotLSAgIEJsYWNr
QmVycnmuIGZyb20gTW9iaXN0YXIgICAgLS0t
DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQpGcm9tOiBNYXR0aGV3IEFkYW1zIDxtYXR0
aGV3QG1hdHRoZXdhZGFtcy5vcmc+DQoNCkRhdGU6
IE1vbiwgNSBOb3YgMjAwNyAxNjoxMjowNCAN
ClRvOkVyaWsgQmVuZ3Rzb24gPGVyaWtAanBveC5v
cmc+DQpDYzpqZG8tZGV2QGRiLmFwYWNoZS5v
cmcsamRvLWV4cGVydHMtZXh0QHN1bi5jb20NClN1
YmplY3Q6IFJlOiBqZG8gc2VjdXJpdHkgcmV2
YW1wZWQgcHJvcG9zYWwNCg0KDQpIaSBFcmlrLA0K
DQpXaGlsZSBJIHRoaW5rIHRoaXMgaXMgYW4g
aW5nZW5pb3VzIHVzZSBvZiBKYXZhIHBsYXRmb3Jt
IHNlY3VyaXR5LCBJICANCmNhbid0IHNlZSBp
dCBpbiB0aGUgMi4xIHRpbWVmcmFtZS4NCg0KRXZl
biBpZiB3ZSBjb25zaWRlciBpdCBmb3IgYSBs
YXRlciByZWxlYXNlLCBJIGFtIG5vdCBjb252aW5j
ZWQgdGhhdCAgDQp0aGlzIHNob3VsZCBiZSAq
KnRoZSoqIHdheSB0byBzZWN1cmUgUEMgaW5zdGFu
Y2VzLiAgVGhpcyBwcm9wb3NhbCAgDQpkb2Vz
bid0IGNsZWFybHkgYWRkcmVzcywgSU1ITywgdGhl
IGNhc2Ugd2hlcmUgeW91IG1heSB3YW50IHRv
IHN1cHBvcnQgIA0KYSB1c2UgY2FzZSB3aGVyZWlu
IGEgZG9tYWluIG9iamVjdCBpdHNlbGYgcmVw
cmVzZW50cyBhIHByaW5jaXBhbCwgc28gIA0KdGhh
dCB5b3UgY2FuIGR5bmFtaWNhbGx5IGFzc2ln
biBwZXJtaXNzaW9ucyBhdCBydW50aW1lLiAgRm9y
IGV4YW1wbGUsICANCkkgZG9uJ3Qgc2VlIGhv
dyB5b3UgY2FuIHVzZSB0aGlzIHByb3Bvc2FsIHRv
IGVuZm9yY2UgdGhhdCB0aGUgVXNlciAgDQpp
bnN0YW5jZSBhc3NvY2lhdGVkIHdpdGggUGVyc29u
ICJCb2IiIHJlcHJlc2VudHMgYSBwcmluY2lw
YWwsIGFuZCAgDQp3aGVuIHRoZSBwcmluY2lwYWwg
b2YgdGhlIHNlY3VyaXR5IGNvbnRleHQgb2Yg
dGhlIGN1cnJlbnQgdGhyZWFkIGlzICANCkJvYidz
IFVzZXIgaW5zdGFuY2UsIGhlIGNhbiBhY2Nl
c3MgYWxsIHNhbGFyeSBhbmQgd2FnZSBmaWVsZHMg
b2YgYWxsICANCkVtcGxveW1lbnQgaW5zdGFu
Y2VzLg0KDQpGdXJ0aGVyLCBpcyB0aGVyZSBhIHdh
eSB0byBleHBsaWNpdGx5ICoqZGVueSoqIGFj
Y2VzcyB0byBhIHBhcnRpY3VsYXIgIA0KUEM/ ICBGb3IgZXhhbXBsZSwgSSBkb24ndCBzZWUgaG93

IHlvdSBjYW4gdXNlIHRoaXMgcHJvcG9zYWwgdG8g
IA0KZW5mb3JjZSB0aGF0IHRoZSBVc2VyIGlu
c3RhbmNlIGFzc29jaWF0ZWQgd2l0aCBQZXJzb24g
IkJvYiIgIA0KcmVwcmVzZW50cyBhIHByaW5j
aXBhbCwgYW5kIHdoZW4gdGhlIHByaW5jaXBhbCBv
ZiB0aGUgc2VjdXJpdHkgIA0KY29udGV4dCBv
ZiB0aGUgY3VycmVudCB0aHJlYWQgaXMgQm9iJ3Mg
VXNlciBpbnN0YW5jZSwgaGUgY2FuIGFjY2Vz
cyAgDQphbGwgc2FsYXJ5IGFuZCB3YWdlIGZpZWxk
cyBvZiBhbGwgRW1wbG95bWVudCBpbnN0YW5j
ZXMgZXhjZXB0IHRob3NlICANCmFzc29jaWF0ZWQg
d2l0aCBFbXBsb3llZSBpbnN0YW5jZXMgYXNz
b2NpYXRlZCB3aXRoIFBlcnNvbiBpbnN0YW5jZXMg
IA0KIlNhbGx5IiBhbmQgIkpvZSIuDQoNCkFz
IGEgYml0IG9mIHBvc2l0aXZlIGZlZWRiYWNrLCBJ
IHdvdWxkIHN1Z2dlc3QgZGl0Y2hpbmcgWFBh
dGggZm9yICANCnNvbWUga2luZCBvZiAiT1BhdGgi
IChKRE9QYXRoPykgdGhhdCBzdXBwb3J0cyBp
bmRleGluZyBjb2xsZWN0aW9ucyAgDQphbmQgbWFw
cyAoZG90cyBpbnN0ZWFkIG9mIHNsYXNoZXMs
IHNxdWFyZSBicmFja2V0IG9wZXJhdG9ycyBmb3Ig
bGlzdC8gDQptYXAgaW5kZXhpbmcpLg0KDQot
bWF0dGhldw0KDQpPbiBOb3YgNSwgMjAwNywgYXQg
MTI6MTQgUE0sIEVyaWsgQmVuZ3Rzb24gd3Jv
dGU6DQoNCj4gSGksDQo+DQo+IEFmdGVyIG5lZ2F0
aXZlIGZlZWRiYWNrLCBJIGhhdmUgYSBkaWZm
ZXJlbnQgcHJvcG9zYWwgZm9yIHNlY3VyaW5nIEpE
Tw0KPiByZXNvdXJjZXMuDQo+IERpZmZlcmVu
dCBmcm9tIG15IGluaXRpYWwgcHJvcG9zYWwgdXNp
bmcgZGVjbGFyYXRpdmUgc2VjdXJpdHkgIA0K
PiAoWE1MKSwgaGVyZSBJDQo+IHByb3Bvc2UgdXNp
bmcgdGhlIHN0YW5kYXJkIGphdmEgc2VjdXJp
dHkuDQo+IFRoZSBleGFtcGxlIGlzIHNlbGYtZXhw
bGFpbmluZzoNCj4NCj4gLS0tIFBlcnNpc3Rl
bnQgQ2xhc3Mgc2FtcGxlOg0KPiBwYWNrYWdlIGNv
bS5wZXRzdG9yZTsNCj4NCj4gY2xhc3MgUGV0
DQo+IHsNCj4gICAgU3RyaW5nIG5hbWU7DQo+IH0N
Cj4NCj4gLS0tIFNlY3VyaXR5IHBvbGljeSBz
YW1wbGU6DQo+DQo+IGdyYW50IHByaW5jaXBhbCAi
YmFydCINCj4gew0KPiBwZXJtaXNzaW9uIGph
dmF4Lmpkby5zcGkuSkRPRGF0YVBlcm1pc3Npb24g
Ii9jb20vcGV0c3RvcmUvUGV0IA0KPiBbQG5h
bWU9J2RvZyddIiwNCj4gInJlYWQsd3JpdGUiOw0K
PiB9DQo+DQo+IGdyYW50DQo+IHsNCj4gcGVy
bWlzc2lvbiBqYXZheC5qZG8uc3BpLkpET0RhdGFQ
ZXJtaXNzaW9uICIvY29tL3BhY2thZ2UiLCAi
cmVhZCI7DQo+IHBlcm1pc3Npb24gamF2YXguamRv
LnNwaS5KRE9EYXRhUGVybWlzc2lvbiAiL2Nv
bS9wZXRzdG9yZS9QZXQiLCAgDQo+ICJyZWFkIjsN
Cj4gfTsNCj4NCj4gLS0tIGphdmF4Lmpkby5z
cGkuSkRPRGF0YVBlcm1pc3Npb246DQo+DQo+IGph
dmF4Lmpkby5zcGkuSkRPRGF0YVBlcm1pc3Np
b24oU3RyaW5nIG5hbWUsIFN0cmluZyBhY3Rpb25z
KTsNCj4NCj4gLS0tIFBNRi9TeXN0ZW0gcHJv
cGVydHkgdGhhdCB3aWxsIGVuYWJsZS9kaXNhYmxl
IHNlY3VyaXR5IGNoZWNrcyBieSAgDQo+IHRo
ZSBKRE8NCj4gaW1wbGVtZW50YXRpb24NCj4gamF2
YXguamRvLnNlY3VyaXR5Lm1hbmFnZXI9ZmFs
c2V8dHJ1ZQ0KPg0KPiBUaGUgb25seSBwYXJ0aWN1
bGFyaXR5IG9mIG15IHByb3Bvc2FsIGlzIHRo
ZSBuYW1lIGFyZ3VtZW50IGZvcg0KPiBKRE9EYXRh
UGVybWlzc2lvbiB0aGF0IHVzZXMgWHBhdGgu
DQo+DQo+IFJlZ2FyZHMsDQo+DQo+DQo+DQo+DQo+
DQo+DQo+DQo+DQoNCg==

Matthew Adams

2007-11-06, 1:11 pm

Hi Erik,

I guess the main issues that I have are not with your proposal, but =20
more with JEE platform security itself; I don't want to see JDO =20
limited by JEE platform security. The need to redeploy your =20
applications in order to pick up changes in permissions and the need =20
for a container are enough to kill it for me.

Let me try to restate what I was trying to say in my prior email =20
about principals and denials. In my experience, JEE platform =20
security falls quite short of the kind of security needed in real =20
applications.

Consider the following domain model (in minimized form):

/** Actor **/
class Person implements Principal {
String name; // id
User user;
Employee employee; // bidi: Employee.person
}

/** Role **/
class User implements RolePrincipal {
long id; // id
Person person; // bidi: Person.user
String username;
String passwordHash;
}

/** Role **/
class Employee implements RolePrincipal {
long id; // id
Person person; // bidi: Person.employee
List<Employment> employments;
}

/** Business Transaction/Event **/
class Employment implements Securable {
long id;
Employer employer;
Date startDate;
Date terminationDate;
int annualBaseSalary;
}

/** Role **/
class Employer implements RolePrincipal {
long id; // id
Corporation corporation; // bidi: Corporation.employer
List<Employment> employments;
}

/** Actor **/
class Corporation implements Principal {
String taxId; // id
String name;
Employer employer; // bidi: Employer.corporation
}

enum Action {
READ, WRITE, ALL;
}

interface SecurityManager {

void grant(RolePrincipal rp, Securable s, String fieldNames, =20
Action... actions);
void ungrant(RolePrincipal rp, Securable s, String fieldNames, =20
Action... actions);

void deny(RolePrincipal rp, Securable s, String fieldNames, =20
Action... actions);
void undeny(RolePrincipal rp, Securable s, String fieldNames, =20
Action... actions);

void assertAccess(RolePrincipal rp, Securable s, String =20
fieldNames, Action... actions);
boolean queryAccess(RolePrincipal rp, Securable s, String =20
fieldNames, Action... actions);

Set<AccessControlEntry> getAccessControlListOf(Securable s);

public setThreadRolePrincipals(RolePrincipal... rps);
}

interface AccessControlEntry { // immutable; use SecurityManager to =20
change
boolean grants();
Securable getSecurable();
Set<String> getFieldNames(); // immutable; use SecurityManager to =20
change
Set<RolePrincipal> getRolePrincipals(); // immutable; use =20
SecurityManager to change
Set<Action> getActions(); // immutable; use SecurityManager to change
}

class SecurityContext {
public static SecurityContext get() { /* gets from thread or =20
wherever */ }
public SecurityManager getSecurityManager() { /* ... */ }
}

Now, consider the following use, at some time during the =20
application's life:

Corporation acme =3D new Corporation("1234567-890", "ACME, Inc.");
Employer acmeEmployer =3D new Employer(acme);

Person sally =3D new Person("Sally");
User sallyUser =3D new User(sally);
Employee sallyEmployee =3D new Employee(sally);
Employment sallyEmployment =3D
new Employment(acmeEmployer, sallyEmployee, new Date(), 30000);

Person bob =3D new Person("Bob");
User bobUser =3D new User(bob);
Employee bobEmployee =3D new Employee(bob);
Employment bobEmployment =3D
new Employment(acmeEmployer, bobEmployee, new Date(), 30000);

Person joe =3D new Person("Joe");
User joeUser =3D new User(joe);
Employee joeEmployee =3D new Employee(joe);
Employment joeEmployment =3D
new Employment(acmeEmployer, joeEmployee, new Date(), 30000);

Person fred =3D new Person("Fred");
User fredUser =3D new User(fred);
Employee fredEmployee =3D new Employee(fred);
Employment fredEmployment =3D
new Employment(acmeEmployer, fredEmployee, new Date(), 30000);

SecurityManager sm =3D SecurityContext.get().getSecurityManager();
sm.grant(joeEmployee, sallyEmployment, "annualBaseSalary", =20
Action.ALL); // explicit grant
sm.deny(bobEmployee, sallyEmployment, "annualBaseSalary", =20
Action.ALL); // explicit denial

In the above example, how can your proposal support this?

Now, consider this, later on in the application's lifecycle:

// probably done by a servlet filter or something similar
Person p =3D pm.getObjectById(Person.class, session.getAttribute=20
("personId"));

SecurityManager sm =3D SecurityContext.get().getSecurityManager();
setThreadRolePrincipals(p.getUser(), p.getEmployee());
// security principals are domain instances!

// now, in business code
Employment sallyEmployment =3D
pm.getObjectById(
Employment.class, request.getParameter("employmentId"));

int salary =3D sallyEmployment.getAnnualBaseSalary();

The last line should throw if the caller is Bob (explicit denial) or =20
Fred (no grants), but should return successfully if the caller is Joe =20=

(explicit grant). How would your proposal support this?

--matthew

On Nov 6, 2007, at 1:19 AM, Erik Bengtson wrote:

> Matthew, I don't understand your questions very well.
>
> Let me explain some points:
>
> As per Java security, unless you grant permissions you don't have =20
> access to the data/fields/instances.
>
> Check points are placed in state managers/ query , so they assert =20
> based on current security context the actions upon instances/fields =20=

> are authorized.
>
> Dynamics, in J2EE you can always deploy a security policy within =20
> deployment descriptors, but you need to redeploy the application .
> In J2EE, Adding permissions (ejb, servlets)at runtime is done via =20
> JACC, but it I don't know any container that allows console based =20
> permissions modifications, but reading deployment descriptors =20
> during deployment. That means I don't think we can have dynamic =20
> security permissions, but you can always redeploy your application.
>
>
>
>
> -- BlackBerry=AE from Mobistar ---
>
> -----Original Message-----
> From: Matthew Adams <matthew@matthewadams.org>
>
> Date: Mon, 5 Nov 2007 16:12:04
> To:Erik Bengtson <erik@jpox.org>
> Cc:jdo-dev@db.apache.org,jdo-experts-ext@sun.com
> Subject: Re: jdo security revamped proposal
>
>
> Hi Erik,
>
> While I think this is an ingenious use of Java platform security, I
> can't see it in the 2.1 timeframe.
>
> Even if we consider it for a later release, I am not convinced that
> this should be **the** way to secure PC instances. This proposal
> doesn't clearly address, IMHO, the case where you may want to support
> a use case wherein a domain object itself represents a principal, so
> that you can dynamically assign permissions at runtime. For example,
> I don't see how you can use this proposal to enforce that the User
> instance associated with Person "Bob" represents a principal, and
> when the principal of the security context of the current thread is
> Bob's User instance, he can access all salary and wage fields of all
> Employment instances.
>
> Further, is there a way to explicitly **deny** access to a particular
> PC? For example, I don't see how you can use this proposal to
> enforce that the User instance associated with Person "Bob"
> represents a principal, and when the principal of the security
> context of the current thread is Bob's User instance, he can access
> all salary and wage fields of all Employment instances except those
> associated with Employee instances associated with Person instances
> "Sally" and "Joe".
>
> As a bit of positive feedback, I would suggest ditching XPath for
> some kind of "OPath" (JDOPath?) that supports indexing collections
> and maps (dots instead of slashes, square bracket operators for list/
> map indexing).
>
> -matthew
>
> On Nov 5, 2007, at 12:14 PM, Erik Bengtson wrote:
>
>