incubator-imperius-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neeraj Joshi <jnee...@us.ibm.com>
Subject Re: ACL policies
Date Thu, 28 Aug 2008 15:43:18 GMT
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)










Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message