From imperius-dev-return-219-apmail-incubator-imperius-dev-archive=incubator.apache.org@incubator.apache.org Thu Aug 28 15:43:57 2008 Return-Path: Delivered-To: apmail-incubator-imperius-dev-archive@locus.apache.org Received: (qmail 79517 invoked from network); 28 Aug 2008 15:43:57 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 28 Aug 2008 15:43:57 -0000 Received: (qmail 77312 invoked by uid 500); 28 Aug 2008 15:43:56 -0000 Delivered-To: apmail-incubator-imperius-dev-archive@incubator.apache.org Received: (qmail 77303 invoked by uid 500); 28 Aug 2008 15:43:56 -0000 Mailing-List: contact imperius-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: imperius-dev@incubator.apache.org Delivered-To: mailing list imperius-dev@incubator.apache.org Received: (qmail 77292 invoked by uid 99); 28 Aug 2008 15:43:56 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 28 Aug 2008 08:43:56 -0700 X-ASF-Spam-Status: No, hits=-2.0 required=10.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of jneeraj@us.ibm.com designates 32.97.182.141 as permitted sender) Received: from [32.97.182.141] (HELO e1.ny.us.ibm.com) (32.97.182.141) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 28 Aug 2008 15:42:56 +0000 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e1.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m7SFhPms007899 for ; Thu, 28 Aug 2008 11:43:25 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m7SFhOWO1822840 for ; Thu, 28 Aug 2008 11:43:24 -0400 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m7SFhNqP018339 for ; Thu, 28 Aug 2008 09:43:23 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m7SFhJKY017983 for ; Thu, 28 Aug 2008 09:43:19 -0600 In-Reply-To: To: imperius-dev@incubator.apache.org MIME-Version: 1.0 Subject: Re: ACL policies X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Neeraj Joshi Message-ID: Date: Thu, 28 Aug 2008 11:43:18 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Build V85_07222008NPHF42 | August 5, 2008) at 08/28/2008 09:43:19, Serialize complete at 08/28/2008 09:43:19 Content-Type: multipart/alternative; boundary="=_alternative 00565C2C852574B3_=" X-Virus-Checked: Checked by ClamAV on apache.org --=_alternative 00565C2C852574B3_= Content-Type: text/plain; charset="US-ASCII" Hey David, > evaluatePolicy() is unchanged. Great > Do you have any suggestions? No, I agree with you about the ability to use combining algorithms. I am ok with this. Just please ensure that you do a complete build during testing (make sure CIM-SPL gets built and unit tests run) Thanks Neeraj ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "The light at the end of the tunnel...may be you" Neeraj Joshi WebSphere XD - Compute Grid AIM, IBM Apache Imperius - http://incubator.apache.org/imperius ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ David Wood/Watson/IBM@IBMUS 08/28/2008 11:22 AM Please respond to imperius-dev@incubator.apache.org To imperius-dev@incubator.apache.org cc Subject Re: ACL policies evaluatePolicy() is unchanged. At a high level, what's been done is simply to add functionality (at least that is the intent). Currently there is no good way to distinguish between multiple PolicyStatementResults or EvaluationResults, other than that they are in the same order as they are evaluated. Not sure we can do better than that. Do you have any suggestions? To implement various combining algorithms, it may not be necessary to distinguish. For example, OR of all results can be used for loose allow or deny ACL, AND of all results can be used for strict allow or deny ACL voting could also be used to count trues vs. falses David Wood Network Server System Software Group IBM TJ Watson Research Center dawood@us.ibm.com 914-784-5123 (office), 914-396-6515 (mobile) From: Neeraj Joshi/Durham/IBM@IBMUS To: imperius-dev@incubator.apache.org Date: 08/28/2008 10:54 AM Subject: Re: ACL policies Hey David, Couple of questions: 1. Does the existing evaluatePolicy() continues to operate as usual ? 2. As the individual sub policies are not named how do you distinguish among the results stored in PolicyStatementResult ? Thanks Neeraj ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "The light at the end of the tunnel...may be you" Neeraj Joshi WebSphere XD - Compute Grid AIM, IBM Apache Imperius - http://incubator.apache.org/imperius ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ David Wood/Watson/IBM@IBMUS 08/28/2008 09:49 AM Please respond to imperius-dev@incubator.apache.org To imperius-dev@incubator.apache.org cc Subject Re: ACL policies All, Ok, I have an initial implementation as follows: Added PolicyStatementResult that captures the boolean condition and decision results and the status code (as was originally returned) Added EvaluationResult that captures 1 or more PolicyStatementResult instances. For PolicyGroups, it is also holds a list of EvaluationResult objects. Finally, it captures a top level status code that is a combination of all the included status codes. Added SPLPolicy.evaluatForResults(dc, ac) that returns an EvaluationResults object. With this in place, I can now evaluate a policy and get the condition value(s) that I'm interested in to implement ACL policies without implementation-specific anchor classes. Comments? If ok, I'd like to provide the patch for these changes. David Wood Network Server System Software Group IBM TJ Watson Research Center dawood@us.ibm.com 914-784-5123 (office), 914-396-6515 (mobile) From: David Wood/Watson/IBM@IBMUS To: imperius-dev@incubator.apache.org Date: 08/27/2008 10:36 AM Subject: Re: ACL policies Neeraj, Yes, on point 1 we will need to figure out how to allow the handling of multiple condition results, although I think we can probably pass all values back and allow the caller to implement their own mechanism for combining values (the combination may be implementation specific). On point 2, I think you're pointing out the fact that all we'd be using is the condition, and so the decision statement is irrelevant but still has to exist. Yes, the decision becomes pretty much irrelevant, but we could simply populate it with some valid but innocuous operation. David Wood Network Server System Software Group IBM TJ Watson Research Center dawood@us.ibm.com 914-784-5123 (office), 914-396-6515 (mobile) From: Neeraj Joshi/Durham/IBM@IBMUS To: imperius-dev@incubator.apache.org Date: 08/27/2008 10:12 AM Subject: Re: ACL policies Hi David, I agree with your idea conceptually but there are a few things to consider before doing this 1. A policy can have multiple subpolicies (each with their own conditions). I guess the trick would be to determine how to populate this EvaluationStatus object. 2. To keep things in sync with the CIM-SPL spec. Currently the spec expects a numeric return code (or an exception) as a result of policy execution. So we would have to figure out how this can be accomodated. Thanks Neeraj ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "The light at the end of the tunnel...may be you" Neeraj Joshi WebSphere XD - Compute Grid AIM, IBM Apache Imperius - http://incubator.apache.org/imperius ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ David Wood/Watson/IBM@IBMUS 08/27/2008 09:42 AM Please respond to imperius-dev@incubator.apache.org To imperius-dev@incubator.apache.org cc Subject ACL policies I sent something on this topic a couple of weeks ago and did not get a response, so I'll try again with perhaps a bit more motivation... We would like to be able to implement ACL policies in SPL that do not depend on implementation-dependent anchor classes to capture the results of the decision. My suggestion is to use the condition statement evaluation results to implement ACL policies. If people agree, then we need to be able to retrieve the result of the condition evaluation after policy evaluation. Currently all that is returned by SPLPolicy.evaluate() is a status code (error, success, not evaluated), but we could simply change this to return a new EvaluationStatus object that contains the condition results, current status value, and any other data that might be useful in the future. If I don't hear from anyone that this is a bad idea and would not be acceptable in Imperius, I guess I'll go ahead and try implementing this. David Wood Network Server System Software Group IBM TJ Watson Research Center dawood@us.ibm.com 914-784-5123 (office), 914-396-6515 (mobile) --=_alternative 00565C2C852574B3_=--