Basic naming guidelines are in the glossary.
|
Here are examples and suggestions of how institutions have organized and delegated their folders and groups.
Suggested standards for group and folder design and naming are available in the Grouper Deployment Guide. Starting with a Grouper 2.4 patch, you can use the template wizard to create folders and groups in accordance with the Deployment Guide's recommendations. |
U Chicago has a naming plan for groups described at https://wiki.uchicago.edu/display/idm/Group+Names.
"Just having a plan or standard has been quite helpful, as it allows implementers to get on with real work without having to stumble on how to name things or where to stick them. This plan has also been working out reasonably well - we haven't had to improvise in any large scale way yet." -Tom Barton
Stem and Group Naming Standards
University of California Santa Cruz
Stem Design to allow for federated grouper across the UC-Trust mini federation
Course Groups naming structure
See page 2 of this presentation for folder structure
See also University of Hawaii Groupings slides (PDF)
https://www.hawaii.edu/bwiki/display/UHIAM/The+UH+Grouper+hierarchy
See this community contribution
See page 18 of this presentation for group structure.
There are documents on the Newcastle research website that discuss group structure and naming convention.
http://research.ncl.ac.uk/grand/docs/Grouper%20Service.pdf
http://research.ncl.ac.uk/grand/docs/Organising%20Groups%20within%20Grouper.pdf
http://research.ncl.ac.uk/grand/resources/GrouperStructureJan12/GrouperStructureJan12.html
Newcastle University structures Grouper groups into 3 main stems (Corporate Data, User Groups, and Applications) :
"Corporate Data" - this is where we load in Corporate data. These structures
are non-editable and are loaded in with either the use of the Grouper Loader
or other data integration tools such as Talend. All users of Grouper have
read only access to these groups.
This stem allows us to represent key Institutional data from the University's
HR systems, for example
* Organisational Structure
* Mapping students to their modules
* Mapping module leaders/lecturers/contributors to their modules
We are always investigating which Institutional data to represent within
Grouper, and have came across scenarios where we did not believe it was
worthwhile. As part of a new room booking system, we decided against creating
a structure of mapping staff members to the buildings/rooms where they
reside, instead we have approached this differently with the use of user
created groups. By making this institutional data available we are able to
provide administrators of systems more flexibility to delegate access to
applications, whilst removing some administrative burden by providing
pre-populated groups.
"User Groups" - this area is for groups of users or departments to create
their own group structure. By default a new stem is set up for the user where
they are provided with privileges to create groups/stems within that working
area. They are able to then delegate privileges to other users to administer
their created groups. They are able to assign memberships on a individual
basis or more ideally make use of the groups within the Corporate Data stem.
This stem is particularly important for representing groups of users which
are not represented within our HR systems. For example we do not have a data
feed available which says who the members of a particular research group are,
and similarly with University societies. In these cases user managed groups
can be created with the members of these lists being manually administered,
and then subsequently used to provide access control to applications
represented within the "Applications" stem.
"Applications" - Groups within this stem make use of the groups created in
the preceding stems to delegate access to different systems. They provide
access lists for applications and resources such as our wiki service, site
manager etc. An example for this would be with wikis, we are able to provide
access to all of Computing Science by using source group from Org_Structure,
and also a research group created and managed within the user group stem.
The above structure has provided a good starting point for us to allow
delegation of access control with a combination of pre-loaded and user
managed groups, yet it is something we are always monitoring to see if we can
improve it. We are currently working on a project which is interested in the
structuring of groups to enable more effective delegation of access control.
As part of this we have made available a couple of use case documents which
discuss how we have approached some scenarios, with relevance to how we have
structured our access groups and made use of the above core stems. They can
be found on our project website at http://research.ncl.ac.uk/grand/, we'll be
adding more over the coming months as further use cases are indentified.
Regards to LDAP, we don't currently provision our groups into LDAP, but this
is something we are hoping to be able to do as part of the GRAND project.
At Penn we have two root stems (note, some names aren't the actual names, just examples):
underneath penn: we have “etc”, and every school and center who needs access.
Note, it is good to have group names that make sense without the parent stem. i.e. penn:etc:grouper:grouperAdmins is better than penn:etc:grouper:admins. Sometimes on the UI only the extension is show without the stem.
For each school and center we have a top level group in there called “etc”, which has their school/center wide readers, updaters, and admins.
Generally in the school/center folder we have an “apps” folder for that school/center’s apps.
Other schools put the “apps” folder at the top or under their top level folder (in our case “penn”.
Also under “penn” we have “community” which has employees, students, orgs, courses, etc. Stuff that is generally from the loader and which can be shared among people who need it.
See also Implementing Penn Organizational Hierarchy
See also Grouper Loader Class List Example from Penn (shows group names and shows use of include/exclude)
At Duke, we have a top level stem called "duke". Under that, we have:
duke:employees - institutionally managed groups based on employee data.
duke:students - institutionally managed groups based on student data.
duke:orgs - organizational hierarchy.
duke:resources - used to store resources in Grouper primarily to manage external resources.
duke:siss - course enrollments
duke:users - user specific groups
duke:<department> - separate folders for each department using Grouper, such as “OIT”, “Library”, and “Law”.
If there is part of your namespace is dedicated for application specific groups, then you may want to create a new application folder whenever a new application wants to use Grouper.
It is a good practice to have Admin groups associated with the folders that you delegate.
For instance if there is a new application, and you create a folder for that application called AppX, and there are 5 people who need access to that folder, then create a separate AppX-Admin group with those 5 people. Set the AppX-Admin group as having full access to the AppX folder. That way, groups and other folders created within the AppX folder can reuse the AppX-Admin group for privileges.
Move and Copy Groups and Folders
For Naming Best Practices, see pages 9-16 of these training slides
Include, Exclude and Require Group
Organizing Services in Grouper
Folder Structure Design Discussion from Advance CAMP 2015 in Cleveland
Example Access Policies (provides example group names)
