SAC:Security Groups Policy

This document is under development, and has not yet been adopted.

It is planned that a central LDAP database be used for user authentication on all (or at least most) SAC administered services. This includes items like a web site/cms, svn, shell access, wiki and so forth. Userids in LDAP will belong to one or more group determining what level of access they have to various services.

This document describes the groups, and the types of access they imply.

1. EndUser: The lowest level of permissions. This is someone who can be identified and is allowed to do general public type stuff like edit in the wiki, subscribe to mailing lists, etc.
2. OSGeoMember: A properly registered member of OSGeo. Gets to vote in polls. Should have contact information (postal address etc) on file. Otherwise essentially the same as EndUser.
3. Committer_<project>: A distinct group will be required for each software project using OSGeo SVN services. Being a member of this group allows SVN commit access on that projects repository.
4. Shell: Someone allowed shell login access on low security systems. This would be given out on an as needed basis to software developers, committee folks, and so forth so people can do testing, setup cron jobs, etc.
5. Administrator: Someone allowed shell access, and sudo priviledges on all OSGeo systems. Some other priviledged functions, such as WikiSysop, Bugzilla admin and so forth might also be setup to use this group. This will only be provided to a tight cadre of trusted individuals. Perhaps 5-10 people.

Notes / Issues

• Do we want to even further limit direct access to our most secure system (used for LDAP server primarily) to a more limited set of people? SeniorAdministrator or perhaps KeyMaster? In fact, it might be better to *not* have the LDAP's systems authentication running against LDAP in case things break, just use conventional logins for a very short list of people allowed shell access.
• We might need a Member_<project> set of groups so that projects can limit access to some functions to folks considered to be members in their project without actually being full committers. Stuff like bug database update, etc. I'd prefer to avoid this if practical though.

CMS Groups

This is just to sketch out the required groups, so far, for effectively running the content management system. These overlap with the above roles, but use language that is specific to the CMS side of things:

1. Anonymous: Similar to EndUser above
2. Authenticated: Similar to OSGeoMember above
3. Committer_<project>: Allowed to contribute content to <project>'s portion of site
4. Manager_<project>: Has administrative control over a <project>'s portion of site
5. Shell: Similar to above, shell login access to CMS system area
6. Administrator: site-wide CMS management access

• Most of these are normal access rights: Anonymous, authenticated, administrator. The others are more complex, particularly anything to do with Project-specific content groups.
• Need more discussion on how CMS modules can interact/authenticate against LDAP