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: securing data in JDO
Date Mon, 29 Oct 2007 19:00:29 GMT
Eric, 

 

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

 

Permissions:

  - 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)

 

Queries:

- 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:

  - 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.

 

Regards

 

 

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

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