You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Erik Bengtson <er...@jpox.org> on 2007/10/26 18:03:55 UTC

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.

Re: securing data in JDO

Posted by Matthew Adams <ma...@matthewadams.org>.
Two things:

1. Spring has never been an all-or-nothing proposition.  It goes to  
great lengths to ensure that only those portions of Spring that  
provide you value can be used.  See http://www.acegisecurity.org/ 
standalone.html.

2. I don't really think that domain object security is something that  
should be addressed by JDO.  This is a classic example of AOP and I  
don't think we need to do anything in JDO to explicitly address  
this.  Spring Security (formerly called "Acegi") provides facilities  
for domain object security (see http://www.acegisecurity.org/guide/ 
springsecurity.html#domain-acls).

If JDO, an SE spec, is to consider domain object security at all,  
which I don't think it should, it should wait to see what the JCP  
proposes for this kind of security.  Is it time for a new JSR on  
security?  Maybe.  Since I tend to favor lagging specs and the only  
mature domain object security implementation out there is Spring  
Security, I don't think that it's quite time for it.

My $0.02,
Matthew

On Oct 30, 2007, at 5:28 AM, Eric Samson wrote:

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

RE: securing data in JDO

Posted by Eric Samson <er...@xcalia.com>.
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

 

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.

RE: securing data in JDO

Posted by Erik Bengtson <er...@jpox.org>.
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.

RE: securing data in JDO

Posted by Eric Samson <er...@xcalia.com>.
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.