As I’ve watched the uptake of Grouper grow within the computing officer community over the last year (with many new and interesting use cases), I’ve seen many people face the same problems and struggle with the same dilemmas. The more I’ve helped people tackle these challenges, the clearer the solutions have become in my mind and the more I’ve realised I should try to document some of it. So, here it is, my list of principles, tips and good practices for Grouper administrators …
- Use a ‘User Group’ to determine who has admin privileges on all of your groups and folders.
- Whenever possible, use ‘Corporate Data’ groups to control memberships of your groups.
- Where adequate source data doesn’t exist to define a ‘Corporate Data’ group, create a ‘User Group’ if you’re likely to use the same set of members in more than one place.
- Only create ‘Applications’ groups if you need them to be provisioned to AD or available as Shibboleth attributes.
- Adhere to the naming convention for ‘Applications’ groups.
- Make ‘Applications’ groups specific to a service or purpose.
- If you are delegating control of a group’s membership, give out the ‘update’ privilege, not the ‘admin’ privilege.
I realise it’d be useful to supplement this post with a higher-level overview of how Grouper works and what I mean by ‘Corporate Data’, ‘User Groups’ and ‘Applications’ groups. We’ll endeavour to get that written soon.