grouper-dev - [grouper-dev] RE: grouper permissions allow/disallow
Subject: Grouper Developers Forum
List archive
- From: Chris Hyzer <>
- To: paccman <>, "" <>
- Subject: [grouper-dev] RE: grouper permissions allow/disallow
- Date: Fri, 17 Jun 2011 02:42:02 -0400
- Accept-language: en-US
- Acceptlanguage: en-US
This is done in the API/GSH. I made a unit test that is modeled after all the cases in the document https://spaces.internet2.edu/display/Grouper/Grouper+permissions+allow+and+deny2 Here is the code if you are interested… all the tests pass: Note, how it works is you can now retrieve all relevant permission assignments, or you can filter out the redundant assignments, or the redundant assignments among various roles. When it does this filtering (i.e. if you have a few relevant assignments which are immediate/inherited) it picks the best rule and uses that. It assigns a heuristic score to each assignment, and just orders by this number, and the bigger number wins. This part is very efficient. The UI will hint at this heuristic, though generally it is an internal thing. There is a method in PermissionFinder where you can just see if a subject has a permission, or has a permission in the context of a role(s) and it does call the filtering method and gets the result. Next is limits… In the interest of time, Im assuming for 2.0 we will just have something that is functional, and we can polish it going forward… J That said, what built in limits do we want for 2.0? I was thinking of an amount limit (greater than, less than, equal, etc), an IP address limit (from certain networks), and a time of day limit. Maybe a string compare limit. Anything else? Besides the built in limits, a Java interface could be implemented to write your own limit logic, so we aren’t boxed in too much… Thanks, Chris Ps. Note, if you don’t see a test for each use case, then the SVN sync to web isn’t quite up to date J From: Chris Hyzer Hey, We have some good discussions about this topic at Jasig and ACAMP, and there are two basic drivers here: 1. Good performance 2. Not have a weird API that people wont understand Well, we re-looked at the algorithm, and moved back to my original proposal, but if you look at it with a magnifying glass, it is still a little weird. It still have good performance though J. I think another thing that makes it more easily understood is a good UI. I will have a screen that shows why a certain decision was picked by the algorithm, which will help people understand how it works. However, if people: 1. Don’t use hierarchies 2. Have conflicting assignments 3. Deeply care about how the conflicts should work, and their ideas are different than the direction we are going Then there still could be confusion. Hopefully the UI will help J Well, all that said, I understand that it is not perfect, but I am starting to implement this, so hopefully we can get it done, start using it, and iterate going forward if need be. Here it is: https://spaces.internet2.edu/display/Grouper/Grouper+permissions+allow+and+deny2 Thanks, Chris |
- [grouper-dev] RE: grouper permissions allow/disallow, Chris Hyzer, 06/17/2011
Archive powered by MHonArc 2.6.16.