From jdo-dev-return-6703-apmail-db-jdo-dev-archive=www.apache.org@db.apache.org Mon Oct 29 19:02:12 2007 Return-Path: Delivered-To: apmail-db-jdo-dev-archive@www.apache.org Received: (qmail 10460 invoked from network); 29 Oct 2007 19:02:12 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 29 Oct 2007 19:02:12 -0000 Received: (qmail 13738 invoked by uid 500); 29 Oct 2007 19:01:10 -0000 Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jdo-dev@db.apache.org Delivered-To: mailing list jdo-dev@db.apache.org Received: (qmail 13724 invoked by uid 99); 29 Oct 2007 19:01:10 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Oct 2007 12:01:10 -0700 X-ASF-Spam-Status: No, hits=3.2 required=10.0 tests=HTML_MESSAGE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [195.130.137.78] (HELO ananke.telenet-ops.be) (195.130.137.78) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Oct 2007 19:01:21 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by ananke.telenet-ops.be (Postfix) with SMTP id 2E7663923C3; Mon, 29 Oct 2007 20:00:49 +0100 (CET) Received: from alexia (user-85-201-81-103.tvcablenet.be [85.201.81.103]) by ananke.telenet-ops.be (Postfix) with ESMTP id BF1A23923F3; Mon, 29 Oct 2007 20:00:47 +0100 (CET) From: "Erik Bengtson" To: "'Eric Samson'" , , 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 849B221B217D34C3119730 5AF@intranet.xcalia.net> In-Reply-To: <345CC4DC7C636849B221B217D34C31197305AF@intranet.xcalia.net> Subject: RE: securing data in JDO Date: Mon, 29 Oct 2007 20:00:29 +0100 Message-ID: <002f01c81a5d$fabde9d0$f039bd70$@org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01C81A66.5C8251D0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgX6mfSCFvvG4ITQ4+RVzaU6GmKUgCV/WwQAAbcogA= Content-Language: fr-be X-Virus-Checked: Checked by ClamAV on apache.org ------=_NextPart_000_0030_01C81A66.5C8251D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 =96 = either the data is not retrieved from database, or discarded upon retrieval =96 implementation choice. =20 Detached: - detached objects also need security checks. It=92s 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=92t 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=92t know what=92s Sun=92s 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=85 =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=92s 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 =20 Or =20 =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_000_0030_01C81A66.5C8251D0--