Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jdo-dev@db.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C81AF0.59E621DE"
Subject: RE: securing data in JDO
Date: Tue, 30 Oct 2007 13:28:16 +0100
Message-ID: <345CC4DC7C636849B221B217D34C3119730601@intranet.xcalia.net>
In-Reply-To: <002f01c81a5d$fabde9d0$f039bd70$@org>
Thread-Topic: securing data in JDO
Thread-Index: AcgX6mfSCFvvG4ITQ4+RVzaU6GmKUgCV/WwQAAbcogAAJJDBoA==
References: <4463CFBC.2050403@sun.com> <45B95F3A.8090006@sun.com>
 <45CBC6A8.8030101@sun.com> <45D4E5E7.2050505@sun.com>
 <45DE3995.7070404@sun.com> <45E70D47.2040700@sun.com>
 <45F097C5.6020403@sun.com> <45F9D2EE.4070802@sun.com>
 <4603598C.8080205@sun.com> <460C4010.50209@sun.com> <46159A52.30506@sun.coom>
 <461EC15F.4070600@sun.ccom> <4627E706.6010105@sun.com>
 <463145A4.5080003@sun.com> <463A7B49.7000905@sun.com>
 <464CD0EB.5010101@sun.com> <46565157.4070804@sun.com>
 <465F4B00.9060906@sun.com> <4668D1DE.1080105@sun.com>
 <4671BA1B.7080600@sun.com> <467AFECA.6050104@sun.com>
 <468452A4.7080404@sun.com> <4696A846.1000707@sun.com>
 <469FFFEE.9030303@sun.com> <46AA0FE7.9060102@sun.com>
 <412A2419-D8FE-438F-A503-373D72DB3199@SUNN.com> <46C52BB6.5040305@sun.com>
 <46D76C3C.6020903@sun.com> <46E0C4C8.5050103@sun.com>
 <46E9CA09.1070408@sun.com> <46F33ED0.8050005@sun.com>
 <46FC1E63.2040605@sun.com> <4705534C.2040806@sun.com>
 <470EABD8.2010008@sun.com> <47180BB8.6030108@sun.com> <345CC4DC7C636
  849B221
	B217D34C3119
	7305AF@intranet.xcalia.net> <002f01c81a5d$fabde9d0$f039bd70$@org>
From: "Eric Samson" <eric@xcalia.com>
To: "Erik Bengtson" <erik@jpox.org>,
	<jdo-dev@db.apache.org>,
	<jdo-experts-ext@sun.com>

------_=_NextPart_001_01C81AF0.59E621DE
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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?

=20

Best Regards,

....: Eric Samson, Founder & CTO, xcalia

Service your Data!

De : Erik Bengtson [mailto:erik@jpox.org]=20
Envoy=E9 : lundi 29 octobre 2007 20:00
=C0 : Eric Samson; jdo-dev@db.apache.org; jdo-experts-ext@sun.com
Objet : RE: securing data in JDO

=20

Eric,=20

=20

Thanks for your feedback. Perhaps I should put down my requirements to =
fuel the discussion.

=20

The JDO implementation should be capable of performing security checks =
on data access based on context credentials.

=20

JDO needs authorization of data access. Authentication is done =
externally.

=20

Security Credentials:

  - principals

  - roles

  - etc

=20

Permissions:

  - read

  - write

  - delete

  - create

=20

Data Permissions

  - defined sets of data with access denied/granted=20

=20

Decision points:

  - instance access

  - field access

  - data access

=20

Configurable Actions:

  - java exceptions

  - no ops (so no state transitions)

=20

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.

=20

Detached:

  - detached objects also need security checks. It's possible that =
security context changes over time during the lifecycle of the detached =
objects.

 =20

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

=20

However we need a framework to cope with data access and I don't see any =
light of that coming from a std committee.

=20

Regards

=20

=20

De : Eric Samson [mailto:eric@xcalia.com]=20
Envoy=E9 : lundi 29 octobre 2007 17:13
=C0 : Erik Bengtson; jdo-dev@db.apache.org; jdo-experts-ext@sun.com
Objet : RE: securing data in JDO

=20

Hello Erik,

=20

You are starting a very important debate here.

=20

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.

=20

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

=20

I don't really like having the security policies and ACLs defined in the =
mapping or JDO metadata.

=20

About raising exceptions: I think users want to configure that.=20

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.

=20

Thank you Erik for having started the debate and let's see where it will =
go.

=20

Best Regards,

....: Eric Samson, Founder & CTO, Xcalia

Service your Data!

=20

-----Message d'origine-----
De : Erik Bengtson [mailto:erik@jpox.org]=20
Envoy=E9 : vendredi 26 octobre 2007 18:04
=C0 : jdo-dev@db.apache.org; jdo-experts-ext@sun.com
Objet : securing data in JDO

=20

I would like also to get some feedback about controlling access to data =
in a

standard JDO:

=20

-     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

=20

e.g.

=20

<jdo>

<package>

<class name=3D"Person">

<security principal=3D"adminuser"/>

</class>

</package>

</jdo>

=20

Or

=20

<jdo>

<package>

<class name=3D"Person">

<field name=3D"controlCode">

<security principal=3D"superuser"/>

</field>

</class>

</package>

</jdo>

=20

=20

The user code:

=20

Person.getControlCode(); //If the principal is not valid, a =
JDOSecurityException

is raised.

=20

A JDOQL:

=20

SELECT controlCode FROM Person  //If the principal is not valid when =
evaluating

the query (not when compiling), a JDOSecurityException is raised.

=20


------_=_NextPart_001_01C81AF0.59E621DE--