db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Bengtson" <e...@jpox.org>
Subject Re: jdo security revamped proposal
Date Tue, 06 Nov 2007 09:19:56 GMT
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 <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='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,
>
>
>
>
>
>
>
>

Mime
View raw message