Group and folder design ideas

Basic naming guidelines are in the glossary.

Here are examples and suggestions of how institutions have organized and delegated their folders and groups.

University of Chicago

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

UW Madison

Stem and Group Naming Standards

University of Washington

Group Naming Plan

Simon Fraser Univerisity

See page 18 of this presentation for group structure.

Newcastle

We also have a couple of documents on our research website for a project that completed last year, they discuss our grouper 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

With reference to the structuring of groups within Grouper, we at Newcastle
University, structure our groups into 3 main stems.

"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.

University of Pennsylvania

At Penn we have two root stems (note, some names aren't the actual names, just examples):

penn:

test:

underneath penn: we have “etc”, and every school and center who needs access. 

penn:etc

penn:engineering

penn:artsAndSciences

“etc” has groups like which users can get into the UI or WS or are admins etc. 

penn:etc:uiUsers

penn:etc:wsUsers

penn:etc:grouperAdmins

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. 

penn:engineering:etc:engineerReaders

Generally in the school/center folder we have an “apps” folder for that school/center’s apps. 

penn:engineering:apps:someEngineeringApp:someEngineeringAppUsers

penn:engineering:apps:someEngineeringApp:someEngineeringAppAdmins

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.

penn:community:pennAllStudents

Duke University

At Duke, we have a top level stem called "duke". Under that, we have:

duke:employees - institutionally managed groups based on employee data.

• affiliation based, managers, health system vs university, etc

duke:students - institutionally managed groups based on student data.

• academic careers, programs, and plans. undergraduates, graduates, medical, etc

duke:orgs - organizational hierarchy.

• Organizational hierarchy with institutionally managed groups (members of each org and various breakdowns of it for instance based on affiliation) as well as manually managed groups.

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”.

• may contain department specific dynamic groups
• may contain department specific user managed groups
• we may create sub-folders for specific applications or sub-departments

Group Structure for Delegation (from Duke University)

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.