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 Mon, 29 Oct 2007 16:12:38 GMT
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