View source for 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. 

# '''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.
# '''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.
# '''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.
# '''ShellUser''': 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. 
# '''Administrator''': Someone allowed shell access, and sudo priveledges on all OSGeo systems.  Some other priveledged 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.