SAC:Security Groups Policy - Revision history

Neteler: /* CMS Groups */

2007-08-27T10:58:41Z

CMS Groups

Tmitchell: Adding a section specific to roles in the Drupal CMS

2006-11-10T16:57:08Z

Adding a section specific to roles in the Drupal CMS

Arnulf: corrected typos

2006-06-25T13:46:51Z

corrected typos

Warmerdam at 03:09, 25 June 2006

2006-06-25T03:09:05Z

Warmerdam: first crack ...

2006-06-23T04:15:31Z

first crack ...

New page

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

← Older revision		Revision as of 10:58, 27 August 2007
Line 26:		Line 26:
	* Most of these are normal access rights: Anonymous, authenticated, administrator. The others are more complex, particularly anything to do with Project-specific content groups.		* 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		* Need more discussion on how CMS modules can interact/authenticate against LDAP
		+
		+	[[Category:Infrastructure]]

← Older revision		Revision as of 16:57, 10 November 2006
Line 15:		Line 15:
	* 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.		* 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.		* 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:
		+	# '''Anonymous''': Similar to EndUser above
		+	# '''Authenticated''': Similar to OSGeoMember above
		+	# '''Committer_<project>''': Allowed to contribute content to <project>'s portion of site
		+	# '''Manager_<project>''': Has administrative control over a <project>'s portion of site
		+	# '''Shell''': Similar to above, shell login access to CMS system area
		+	# '''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

@@ Line 9: / Line 9: @@
 # '''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.
 # '''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.
-# '''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.
+# '''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 =