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:[EMAIL PROTECTED]
Envoyé : lundi 29 octobre 2007 20:00
À : Eric Samson; [email protected]; [EMAIL PROTECTED]
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:[EMAIL PROTECTED]
Envoyé : lundi 29 octobre 2007 17:13
À : Erik Bengtson; [email protected]; [EMAIL PROTECTED]
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:[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.
