You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Erik Bengtson <er...@jpox.org> on 2007/11/05 21:14:43 UTC
jdo security revamped proposal
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,
Re: jdo security revamped proposal
Posted by Matthew Adams <ma...@matthewadams.org>.
Hi Erik,
I guess the main issues that I have are not with your proposal, but
more with JEE platform security itself; I don't want to see JDO
limited by JEE platform security. The need to redeploy your
applications in order to pick up changes in permissions and the need
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
about principals and denials. In my experience, JEE platform
security falls quite short of the kind of security needed in real
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,
Action... actions);
void ungrant(RolePrincipal rp, Securable s, String fieldNames,
Action... actions);
void deny(RolePrincipal rp, Securable s, String fieldNames,
Action... actions);
void undeny(RolePrincipal rp, Securable s, String fieldNames,
Action... actions);
void assertAccess(RolePrincipal rp, Securable s, String
fieldNames, Action... actions);
boolean queryAccess(RolePrincipal rp, Securable s, String
fieldNames, Action... actions);
Set<AccessControlEntry> getAccessControlListOf(Securable s);
public setThreadRolePrincipals(RolePrincipal... rps);
}
interface AccessControlEntry { // immutable; use SecurityManager to
change
boolean grants();
Securable getSecurable();
Set<String> getFieldNames(); // immutable; use SecurityManager to
change
Set<RolePrincipal> getRolePrincipals(); // immutable; use
SecurityManager to change
Set<Action> getActions(); // immutable; use SecurityManager to change
}
class SecurityContext {
public static SecurityContext get() { /* gets from thread or
wherever */ }
public SecurityManager getSecurityManager() { /* ... */ }
}
Now, consider the following use, at some time during the
application's life:
Corporation acme = new Corporation("1234567-890", "ACME, Inc.");
Employer acmeEmployer = new Employer(acme);
Person sally = new Person("Sally");
User sallyUser = new User(sally);
Employee sallyEmployee = new Employee(sally);
Employment sallyEmployment =
new Employment(acmeEmployer, sallyEmployee, new Date(), 30000);
Person bob = new Person("Bob");
User bobUser = new User(bob);
Employee bobEmployee = new Employee(bob);
Employment bobEmployment =
new Employment(acmeEmployer, bobEmployee, new Date(), 30000);
Person joe = new Person("Joe");
User joeUser = new User(joe);
Employee joeEmployee = new Employee(joe);
Employment joeEmployment =
new Employment(acmeEmployer, joeEmployee, new Date(), 30000);
Person fred = new Person("Fred");
User fredUser = new User(fred);
Employee fredEmployee = new Employee(fred);
Employment fredEmployment =
new Employment(acmeEmployer, fredEmployee, new Date(), 30000);
SecurityManager sm = SecurityContext.get().getSecurityManager();
sm.grant(joeEmployee, sallyEmployment, "annualBaseSalary",
Action.ALL); // explicit grant
sm.deny(bobEmployee, sallyEmployment, "annualBaseSalary",
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 = pm.getObjectById(Person.class, session.getAttribute
("personId"));
SecurityManager sm = SecurityContext.get().getSecurityManager();
setThreadRolePrincipals(p.getUser(), p.getEmployee());
// security principals are domain instances!
// now, in business code
Employment sallyEmployment =
pm.getObjectById(
Employment.class, request.getParameter("employmentId"));
int salary = sallyEmployment.getAnnualBaseSalary();
The last line should throw if the caller is Bob (explicit denial) or
Fred (no grants), but should return successfully if the caller is Joe
(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
> access to the data/fields/instances.
>
> Check points are placed in state managers/ query , so they assert
> based on current security context the actions upon instances/fields
> are authorized.
>
> Dynamics, in J2EE you can always deploy a security policy within
> deployment descriptors, but you need to redeploy the application .
> In J2EE, Adding permissions (ejb, servlets)at runtime is done via
> JACC, but it I don't know any container that allows console based
> permissions modifications, but reading deployment descriptors
> during deployment. That means I don't think we can have dynamic
> security permissions, but you can always redeploy your application.
>
>
>
>
> -- BlackBerry® from Mobistar ---
>
> -----Original Message-----
> From: Matthew Adams <ma...@matthewadams.org>
>
> Date: Mon, 5 Nov 2007 16:12:04
> To:Erik Bengtson <er...@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:
>
>> 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,
>>
>>
>>
>>
>>
>>
>>
>>
>
Re: jdo security revamped proposal
Posted by Erik Bengtson <er...@jpox.org>.
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 access to the data/fields/instances.
Check points are placed in state managers/ query , so they assert based on current security context the actions upon instances/fields are authorized.
Dynamics, in J2EE you can always deploy a security policy within deployment descriptors, but you need to redeploy the application .
In J2EE, Adding permissions (ejb, servlets)at runtime is done via JACC, but it I don't know any container that allows console based permissions modifications, but reading deployment descriptors during deployment. That means I don't think we can have dynamic security permissions, but you can always redeploy your application.
-- BlackBerry® from Mobistar ---
-----Original Message-----
From: Matthew Adams <ma...@matthewadams.org>
Date: Mon, 5 Nov 2007 16:12:04
To:Erik Bengtson <er...@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:
> 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,
>
>
>
>
>
>
>
>
Re: jdo security revamped proposal
Posted by Matthew Adams <ma...@matthewadams.org>.
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,
>
>
>
>
>
>
>
>