db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Samson" <e...@xcalia.com>
Subject RE: securing data in JDO
Date Tue, 30 Oct 2007 12:28:16 GMT
Before we reinvent the wheel, is there any reasonably correct framework available out there
we can look at as a starting basis?

Some often mention ACEGI, but I'm not sure it is really usable outside Spring. Matthew: any
comment on this?


Best Regards,

....: Eric Samson, Founder & CTO, xcalia

Service your Data!

De : Erik Bengtson [mailto:erik@jpox.org] 
Envoyé : lundi 29 octobre 2007 20:00
À : Eric Samson; jdo-dev@db.apache.org; jdo-experts-ext@sun.com
Objet : RE: securing data in JDO




Thanks for your feedback. Perhaps I should put down my requirements to fuel the discussion.


The JDO implementation should be capable of performing security checks on data access based
on context credentials.


JDO needs authorization of data access. Authentication is done externally.


Security Credentials:

  - principals

  - roles

  - etc



  - read

  - write

  - delete

  - create


Data Permissions

  - defined sets of data with access denied/granted 


Decision points:

  - instance access

  - field access

  - data access


Configurable Actions:

  - java exceptions

  - no ops (so no state transitions)



- The access denied to data would make results invisible to user - either the data is not
retrieved from database, or discarded upon retrieval - implementation choice.



  - detached objects also need security checks. It's possible that security context changes
over time during the lifecycle of the detached objects.


I agree with the independent standard for general security, and the best would be a standard
meta framework to perform the decision of granting/denying access to data based on its policies.


However we need a framework to cope with data access and I don't see any light of that coming
from a std committee.





De : Eric Samson [mailto:eric@xcalia.com] 
Envoyé : lundi 29 octobre 2007 17:13
À : Erik Bengtson; jdo-dev@db.apache.org; jdo-experts-ext@sun.com
Objet : RE: securing data in JDO


Hello Erik,


You are starting a very important debate here.


My first opinion is that, ideally, security should not be defined as part of a persistence
standard, as it is a general need in the Java world.

IMHO, it should be specified as a complete and independent standard within the JCP, but I
don't know what's Sun's vision about that question.


That said, I fully agree a persistence layer needs a security mechanism.

Maybe it is even more important to be able to plug a security mechanism into JDO than defining
a new security model...


I don't really like having the security policies and ACLs defined in the mapping or JDO metadata.


About raising exceptions: I think users want to configure that. 

For instance, instead of raising Exceptions we could define a new state in the StateManager
indicating that a value has not be loaded due to active security policies.


Thank you Erik for having started the debate and let's see where it will go.


Best Regards,

....: Eric Samson, Founder & CTO, Xcalia

Service your Data!


-----Message d'origine-----
De : Erik Bengtson [mailto:erik@jpox.org] 
Envoyé : vendredi 26 octobre 2007 18:04
À : jdo-dev@db.apache.org; jdo-experts-ext@sun.com
Objet : securing data in JDO


I would like also to get some feedback about controlling access to data in a

standard JDO:


-     Users should be able to specify fine grained access control to persistent


-     JDO implementations raise exceptions if the authenticated user does not fit

into the role specified in the metadata






<class name="Person">

<security principal="adminuser"/>









<class name="Person">

<field name="controlCode">

<security principal="superuser"/>







The user code:


Person.getControlCode(); //If the principal is not valid, a JDOSecurityException

is raised.




SELECT controlCode FROM Person  //If the principal is not valid when evaluating

the query (not when compiling), a JDOSecurityException is raised.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message