db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Adams <matt...@matthewadams.org>
Subject Re: securing data in JDO
Date Tue, 30 Oct 2007 17:28:38 GMT
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.
>
>
>
>


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