You are viewing a plain text version of this content. The canonical link for it is here.
Posted to imperius-dev@incubator.apache.org by David Wood <da...@us.ibm.com> on 2008/08/27 13:42:13 UTC
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)
Re: IDE support in the repository
Posted by David Wood <da...@us.ibm.com>.
Ok, it turns out it's fairly straightforward to create an Eclipse project
that links to the source in the Imperius trunk. It's very small, just a
.classpath and a .project file. My hope would be that after using SVN to
check out the trunk, one uses Eclipse SVN plugin to checkout this project
and low and behold you're up and running in Eclipse editing the linked
source. I've only done this for the core code (imperius-splcore and
imperius-javaspl), and we may want to have a separate project for the
Eclipse editor plugin.
Now, there is a maven plugin for Eclipse also, so perhaps there is an
alternative to this approach, but this is so simple and quick to get folks
up an running (i.e. no plugin install required).
What does everyone think?
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:
09/01/2008 07:08 PM
Subject:
Re: IDE support in the repository
I'm not sure why we need to put things in a separate place as long as they
don't disrupt the existing processes. However, all I'm really after is to
be able to 'import' or otherwise include the Imperius code into an Eclipse
workspace. If we can figure out a way to do that an have the files
elsewhere, that is fine with me, although I think these need to be
included in the SVN tree and not maintained separately. These IDE files
will likely need to evolve with the code, so keeping them separate outside
of SVN begs for trouble. If this is agreeable, then perhaps something
along the lines of trunk/ide/{eclipse,netbeans} with a parallel structure
to the source tree. These directories could then include (for example)
imperius-splcore/.project file that reference the source at
trunk/imperius-splcore. What do you think?
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:
09/01/2008 09:21 AM
Subject:
Re: IDE support in the repository
I suggest we upload the the eclipse specific files in a zip format and
make it available via the website (perhaps the development section) that
way
the SVN is still unbiased and the developers have easy access to the
project information. What do you guys think?
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/29/2008 10:37 AM
Please respond to
imperius-dev@incubator.apache.org
To
imperius-dev@incubator.apache.org
cc
Subject
IDE support in the repository
I suspect all of us are using some sort of IDE to develop. With this in
mind, I think it would help us all be more productive if we can find a way
to include support for the IDEs in the SVN repository? I'm using Eclipse,
but wouldn't want to push that on anyone and hope we could support
multiple IDEs. In the case of Eclipse, I think it may be as simple as
building a .project and .classpath file into the right directory. I've
had success in creating two projects for the imperius-splcore and
imperius-javaspl directories. I don't believe these files would otherwise
disrupt the existing build/development process, but correct me if I'm
wrong. Does this strategy work for other IDEs? Do people have another
suggestion for how we might accomplish IDE support? How to proceed?
David Wood
Network Server System Software Group
IBM TJ Watson Research Center
dawood@us.ibm.com
914-784-5123 (office), 914-396-6515 (mobile)
Re: IDE support in the repository
Posted by David Wood <da...@us.ibm.com>.
I'm not sure why we need to put things in a separate place as long as they
don't disrupt the existing processes. However, all I'm really after is to
be able to 'import' or otherwise include the Imperius code into an Eclipse
workspace. If we can figure out a way to do that an have the files
elsewhere, that is fine with me, although I think these need to be
included in the SVN tree and not maintained separately. These IDE files
will likely need to evolve with the code, so keeping them separate outside
of SVN begs for trouble. If this is agreeable, then perhaps something
along the lines of trunk/ide/{eclipse,netbeans} with a parallel structure
to the source tree. These directories could then include (for example)
imperius-splcore/.project file that reference the source at
trunk/imperius-splcore. What do you think?
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:
09/01/2008 09:21 AM
Subject:
Re: IDE support in the repository
I suggest we upload the the eclipse specific files in a zip format and
make it available via the website (perhaps the development section) that
way
the SVN is still unbiased and the developers have easy access to the
project information. What do you guys think?
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/29/2008 10:37 AM
Please respond to
imperius-dev@incubator.apache.org
To
imperius-dev@incubator.apache.org
cc
Subject
IDE support in the repository
I suspect all of us are using some sort of IDE to develop. With this in
mind, I think it would help us all be more productive if we can find a way
to include support for the IDEs in the SVN repository? I'm using Eclipse,
but wouldn't want to push that on anyone and hope we could support
multiple IDEs. In the case of Eclipse, I think it may be as simple as
building a .project and .classpath file into the right directory. I've
had success in creating two projects for the imperius-splcore and
imperius-javaspl directories. I don't believe these files would otherwise
disrupt the existing build/development process, but correct me if I'm
wrong. Does this strategy work for other IDEs? Do people have another
suggestion for how we might accomplish IDE support? How to proceed?
David Wood
Network Server System Software Group
IBM TJ Watson Research Center
dawood@us.ibm.com
914-784-5123 (office), 914-396-6515 (mobile)
Re: IDE support in the repository
Posted by Craig L Russell <Cr...@Sun.COM>.
I've been using Netbeans for other projects and don't use a
special .nbproject. The reason? The projects use maven. With maven,
you don't need anything special because the Netbeans Maven plugin
knows everything about the project.
Since Imperius has a pom.xml, does it really need a special Eclipse
descriptor?
Craig
On Aug 29, 2008, at 1:50 PM, Mark A. Carlson wrote:
> Sounds good. Maybe we can do one for NetBeans also ;-)
>
> -- mark
>
> Neeraj Joshi wrote:
>> I suggest we upload the the eclipse specific files in a zip format
>> and make it available via the website (perhaps the development
>> section) that way the SVN is still unbiased and the developers have
>> easy access to the project information. What do you guys think?
>>
>> 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/29/2008 10:37 AM
>> Please respond to
>> imperius-dev@incubator.apache.org
>>
>>
>> To
>> imperius-dev@incubator.apache.org
>> cc
>>
>> Subject
>> IDE support in the repository
>>
>>
>>
>>
>>
>>
>> I suspect all of us are using some sort of IDE to develop. With
>> this in mind, I think it would help us all be more productive if we
>> can find a way
>> to include support for the IDEs in the SVN repository? I'm using
>> Eclipse,
>> but wouldn't want to push that on anyone and hope we could support
>> multiple IDEs. In the case of Eclipse, I think it may be as simple
>> as building a .project and .classpath file into the right
>> directory. I've had success in creating two projects for the
>> imperius-splcore and imperius-javaspl directories. I don't believe
>> these files would otherwise
>> disrupt the existing build/development process, but correct me if
>> I'm wrong. Does this strategy work for other IDEs? Do people have
>> another suggestion for how we might accomplish IDE support? How to
>> proceed?
>>
>> David Wood Network Server System Software Group
>> IBM TJ Watson Research Center
>> dawood@us.ibm.com
>> 914-784-5123 (office), 914-396-6515 (mobile)
>>
>>
>>
>>
Craig L Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: IDE support in the repository
Posted by "Mark A. Carlson" <Ma...@Sun.COM>.
Sounds good. Maybe we can do one for NetBeans also ;-)
-- mark
Neeraj Joshi wrote:
> I suggest we upload the the eclipse specific files in a zip format and
> make it available via the website (perhaps the development section) that
> way
> the SVN is still unbiased and the developers have easy access to the
> project information. What do you guys think?
>
> 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/29/2008 10:37 AM
> Please respond to
> imperius-dev@incubator.apache.org
>
>
> To
> imperius-dev@incubator.apache.org
> cc
>
> Subject
> IDE support in the repository
>
>
>
>
>
>
> I suspect all of us are using some sort of IDE to develop. With this in
> mind, I think it would help us all be more productive if we can find a way
>
> to include support for the IDEs in the SVN repository? I'm using Eclipse,
>
> but wouldn't want to push that on anyone and hope we could support
> multiple IDEs. In the case of Eclipse, I think it may be as simple as
> building a .project and .classpath file into the right directory. I've
> had success in creating two projects for the imperius-splcore and
> imperius-javaspl directories. I don't believe these files would otherwise
>
> disrupt the existing build/development process, but correct me if I'm
> wrong. Does this strategy work for other IDEs? Do people have another
> suggestion for how we might accomplish IDE support? How to proceed?
>
> David Wood
> Network Server System Software Group
> IBM TJ Watson Research Center
> dawood@us.ibm.com
> 914-784-5123 (office), 914-396-6515 (mobile)
>
>
>
>
Re: IDE support in the repository
Posted by Neeraj Joshi <jn...@us.ibm.com>.
I suggest we upload the the eclipse specific files in a zip format and
make it available via the website (perhaps the development section) that
way
the SVN is still unbiased and the developers have easy access to the
project information. What do you guys think?
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/29/2008 10:37 AM
Please respond to
imperius-dev@incubator.apache.org
To
imperius-dev@incubator.apache.org
cc
Subject
IDE support in the repository
I suspect all of us are using some sort of IDE to develop. With this in
mind, I think it would help us all be more productive if we can find a way
to include support for the IDEs in the SVN repository? I'm using Eclipse,
but wouldn't want to push that on anyone and hope we could support
multiple IDEs. In the case of Eclipse, I think it may be as simple as
building a .project and .classpath file into the right directory. I've
had success in creating two projects for the imperius-splcore and
imperius-javaspl directories. I don't believe these files would otherwise
disrupt the existing build/development process, but correct me if I'm
wrong. Does this strategy work for other IDEs? Do people have another
suggestion for how we might accomplish IDE support? How to proceed?
David Wood
Network Server System Software Group
IBM TJ Watson Research Center
dawood@us.ibm.com
914-784-5123 (office), 914-396-6515 (mobile)
IDE support in the repository
Posted by David Wood <da...@us.ibm.com>.
I suspect all of us are using some sort of IDE to develop. With this in
mind, I think it would help us all be more productive if we can find a way
to include support for the IDEs in the SVN repository? I'm using Eclipse,
but wouldn't want to push that on anyone and hope we could support
multiple IDEs. In the case of Eclipse, I think it may be as simple as
building a .project and .classpath file into the right directory. I've
had success in creating two projects for the imperius-splcore and
imperius-javaspl directories. I don't believe these files would otherwise
disrupt the existing build/development process, but correct me if I'm
wrong. Does this strategy work for other IDEs? Do people have another
suggestion for how we might accomplish IDE support? How to proceed?
David Wood
Network Server System Software Group
IBM TJ Watson Research Center
dawood@us.ibm.com
914-784-5123 (office), 914-396-6515 (mobile)
Re: ACL policies
Posted by Neeraj Joshi <jn...@us.ibm.com>.
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)
Re: ACL policies
Posted by David Wood <da...@us.ibm.com>.
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)
Re: ACL policies
Posted by Neeraj Joshi <jn...@us.ibm.com>.
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)
Re: ACL policies
Posted by David Wood <da...@us.ibm.com>.
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)
Re: ACL policies
Posted by David Wood <da...@us.ibm.com>.
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)
Re: ACL policies
Posted by Neeraj Joshi <jn...@us.ibm.com>.
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)