Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jdo-dev@db.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
In-Reply-To: 
 <1390046013-1194340798-cardhu_decombobulator_blackberry.rim.net-438347512-@bxe007.bisx.produk.on.blackberry>
References: <001b01c81fe8$87b46780$971d3680$@org>
 <D80D17EE-26EF-4228-B7A3-FC317B4804D3@matthewadams.org>
 <1390046013-1194340798-cardhu_decombobulator_blackberry.rim.net-438347512-@bxe007.bisx.produk.on.blackberry>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Message-Id: <EF120AD9-4324-4D25-B7CD-2CEF8DACC7BB@matthewadams.org>
Cc: jdo-dev@db.apache.org,
 jdo-experts-ext@sun.com
Content-Transfer-Encoding: quoted-printable
From: Matthew Adams <matthew@matthewadams.org>
Subject: Re: jdo security revamped proposal
Date: Tue, 6 Nov 2007 10:36:53 -0800
To: erik@jpox.org

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:
>
>> 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=3D'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=3Dfalse|true
>>
>> The only particularity of my proposal is the name argument for
>> JDODataPermission that uses Xpath.
>>
>> Regards,
>>
>>
>>
>>
>>
>>
>>
>>
>