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

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.

 


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