Over the last 6 years Penn has built and maintained our Framework for Administrative Systems and Technologies (FAST). One of the components is group management, and one of the components is privilege management. These components are local for each application, not central. We do have 60+ custom administrative applications using FAST and this security system. To integrate FAST and Grouper, we define the group locally in FAST, and define it in grouper, and when a user logs in, we can ask grouper if the user is in any of the app specific groups, if so, dynamically assign the user to the FAST group(s). Perhaps a similar setup would work to integrate FAST with Internet2 central privilege management. So this framework is not mutually exclusive with Internet2.
Im not saying Internet2 should adopt the this piece of the FAST framework (many reasons, e.g. it is oracle specific), but parts of it are interesting. Anyways, this is how it works:
The groups are hierarchical, and the privilege resources can be bundled in hierarchical groups.
This screenshot is an example of the group hierarchy. It is not hierarchical on a membership basis, but rather, for permissions. So in this case, a senior loan officer would inherit permissions from the loan office role, which inherits permissions from the staff role. But if you asked FAST if a senior loan officer user is a member of the "Staff" group, it would say "no" if there is not an explicit user/group membership assignment. 
This screenshot shows sets which are hierarchical bundles of privilege resources. In this case "caHostFind.jsp" is a resource which is a screen in the system, and it is in the "ca" set, which is in the "officeJSP" set. 
This screenshot shows the view/assignment screen where you can assign privileges to a group, or to a user in a group. 
In this case, some entries are red and green (if allowed or forbidden). Most resources inherit permissions from a parent set or a parent group. There is an explicit assignment on this screenshot for the Loan Inquiry group to have access to mainPageLoanOfficer.jsp.
Since permissions can have three states (allow, forbid, unassigned [inherit]), then the decision making process to see if someone is allowed to do something is as follows:
1. See if there is an explicit permission for the user/group combo for the resource.
2. If so, done, if not, walk up the hierarchy of parent Set's until you find answer.
3. If not found, then do the same thing for the group in general (not user/group), then the parent group, etc.
4. If no privileges assigned, default is forbid.
That decision making logic is inside the framework in one place (though copied for each app). It is complex logic, and not something that we would want apps to have to reinvent.
There is an API to ask the framework if the current user has access to a resource:
| Code Block |
|---|
if (Authorization.isAllowed(currentUser, FastPropertyType.CUSTOM_DATA, "org123")) {
... whatever ...
}
|
There are two "lists" (grouper term) for each privilege assignment, for access to the privilege resource, or to be able to admin (assign others) to the privilege resource. Anyone who has access to the admin screen (which is not a lot of people) can view all permissions (but perhaps not assign).
This screenshot shows the view of which groups or users have access to a specific resource. The last image shows ability to attach an expire date to the privilege. 
On the "resource report" screen, the framework will automatically parse all the JSPs to sync up the JSP/menu/buttons available for assignment, so these do not need to be manually entered.
This screen shows how expiration dates can be applied to assignments 
It does include hooks, auditing, web services, import/export xml, etc... generally we have used this authorization system for access to webapp resources (buttons, menus, jsps, etc), though we also use it for custom permissions (e.g. which data a user can see).