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:[EMAIL PROTECTED] Envoyé : vendredi 26 octobre 2007 18:04 À : [email protected]; [EMAIL PROTECTED] 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 objects. - JDO implementations raise exceptions if the authenticated user does not fit into the role specified in the metadata e.g. <jdo> <package> <class name="Person"> <security principal="adminuser"/> </class> </package> </jdo> Or <jdo> <package> <class name="Person"> <field name="controlCode"> <security principal="superuser"/> </field> </class> </package> </jdo> The user code: Person.getControlCode(); //If the principal is not valid, a JDOSecurityException is raised. A JDOQL: SELECT controlCode FROM Person //If the principal is not valid when evaluating the query (not when compiling), a JDOSecurityException is raised.
