This section explores several example access policies and how they might be implemented using the strategies described in this guide. They are provided to help reinforce how the concepts in this guide can be used to translate natural language policy into Grouper digital policy. The TIER provisioning state change progression models also provide useful examples.
As a general strategy, each of these examples uses a single access policy group which is itself a composite group of an allow group and deny group. The allow and deny groups may only include reference groups as direct members. These may be centrally managed under the "ref:" folder, maintained by an organization under the "org:" folder, or be application specific reference groups under the "app:" folder. Grouper has many features to automatically manage membership in these groups.
While there are many possible naming strategies that can be used for groups, it is important to be as consistent as possible particularly with ref groups. While not required, these examples also endeavor to minimize embedded punctuation and use camelCase to simplify the reading of long names, using an underscore (i.e. “_”) is another common approach.
The examples below are illustrations of "policy groups and static application permissions," as defined in the Access Control Models section. |
An access policy group, app:computerLab:labLoginAuthorized is created in Grouper that maps to the lab computer access control mechanism. The ref:student:allStudents group is then added to app:computerLab:labLoginAllow. There is nothing in app:computerLab:labLoginDeny for this example. app:computerLab:labLoginAuthorized is composite group of labLoginAllow minus labLoginDeny.
Access Policy Group | Allow Groups |
---|---|
app:computerLab:labLoginAuthorized | ref:student:allStudents |
In this example, app:computerLab:labLoginAuthorized has some additional members in the app:computerLab:labLoginAllow group. An institutional reference group for teaching faculty, ref:faculty:teachingFaculty is maintained automatically by institutional data. Additionally, an application scoped reference group for lab administrators, app:computing:computingLabManagers, is maintained manually by the computing lab director. Thus three groups are combined by Grouper into the labLoginAuthorized policy group.
Access Policy Group | Allow Groups |
---|---|
ref:students:allStudents | |
app:computerLab:labLoginAuthorized | app:computing:computerLabManagers |
ref:faculty:teachingFaculty |
Implementation of this policy requires the addition of a deny group app:computerLab:labLogin_deny. Any subject with membership in the labLogin_deny group will be denied access regardless of membership in other groups. This policy requires three deny groups to represent the three cases:
Each deny group is added to labLogin_deny. Membership in any one of the three deny groups would effectively deny access. Membership added to aupViolationFirst would be set to expire within two week either manually or by a Grouper Rule. aupViolationSecond has a Grouper rule that clears all membership at the end of the current semester. aupViolationThird is manually managed by the CISO.
Access Policy Group | Allow Groups | Deny Groups |
---|---|---|
computingLabManagers | aupViolationSecond | |
labLogin_authorized | ref:student:all_students | aupViolationFirst |
ref:faculty:teachingFaculty | aupViolationThird |
This policy calls out two reference groups:
These two reference groups would be automatically kept in sync with institutional data via the Grouper loader.
The policy also calls out three resources that have different access rules, and these are represented by three access policy groups.
Access Policy Group | Allow Groups | Deny Groups |
---|---|---|
classicalBooks | majors:physics:students physics:101:students | |
physics_101_current | physics:101:students | majors:physics:students |
physics_101_new | 101_physics_majors |
Previous: Conclusion