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 [EMAIL PROTECTED] 914-784-5123 (office), 914-396-6515 (mobile) From: Neeraj Joshi/Durham/[EMAIL PROTECTED] 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/[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 914-784-5123 (office), 914-396-6515 (mobile) From: David Wood/Watson/[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 914-784-5123 (office), 914-396-6515 (mobile) From: Neeraj Joshi/Durham/[EMAIL PROTECTED] 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/[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 914-784-5123 (office), 914-396-6515 (mobile)
