See for the official Zabbix site.


Jump to: navigation, search


Single Signon (SSO) is critical for sites using a multitude of applications. This allows for a user to use one username and password across all sites. Aside from having a common username and password it also simplifies administration as it becomes easier to disable or remove accounts if necessary.

Authentication methods

There are many different services available to accomplish SSO. Some of the most common are LDAP, Kerberos or a simple database store.


Lightweight Directory Access Protocol does not define how authentication data is stored but rather how it is accessed. Because it is a derivative of the X.500 protocol is uses a very structured language to access and manipulate the data stored in the directory.

LDAP can be used as a single sign on solution, but we have to research and install web application for user registration. --Kodai 23:00, 22 June 2011 (SAST)
Extension:LDAP_Authentication can be used user registration via MediaWiki --Kodai 01:20, 23 June 2011 (EEST)


Kerberos was designed by MIT as part of the Athena project and is named for the three headed dog Cerberos. The main objective of Kerberos was to provide authentication services with a high level of assurance that each party is who they say they are. Kerberos, like LDAP, does not define how the authentication data is stored, but rather how it is accessed. The design of Kerberos makes it a good choice for SSO integrations, however it's complexity hinders the advantages the protocol may have over other systems such as LDAP. The biggest advantage of Kerberos is the ability to log into a system once and then have the same authentication information propagate to other systems transparently. It is possible for Kerberos to use LDAP as it's authentication store.

if this would require kerberos support in the browser, it's pretty much out --Richlv 23:21, 13 January 2011 (EET)
It appears that there is a way around this using the mod_auth_krb5 plugin for Apache. This would present a standard webauth login box and the Apache server itself would then be responsible for the AS and TGT steps. More research is required in this arena to determine suitability and feasibility. --Nelsonab 01:20, 14 January 2011 (EET)


OpenID is an Open Source SSO solution designed to allow people to use a single username/password on multiple different sites. One of the biggest advantages of OpenID is that it would streamline the signup process for most users coming to the site. However it is unknown how easily OpenID can be tied into Subversion. More research is required.

note that openid on itself isn't sso, just a single auth source provider --Richlv 23:22, 13 January 2011 (SAST)
MediaWIki can become OpenID Provider Extension:OpenID, mod_auth_openid for Subversion, OpenID tools for Django or django-openid-auth for OSQA, OpenID infomation for Pootle --Kodai 22:59, 22 June 2011 (SAST)
mod_auth_openid can't support subversion. because it show login page and manage session using cookie. --Kodai 23:18, 22 June 2011 (SAST)

Simple Database

Using a simple database such as MySQL or a flat file is by far the simplest means of providing SSO. However this simplicity is quickly lost as system complexity and the size of the userbase grow. Many of these issues can be mitigated through the creation of helper scripts however the question must be asked at which point would moving to something like LDAP make things easier overall.


I think CAS is an option as well. Looking at you can find that they have basic support for php/java/.net/apache. Some of the applications listed already have a plugin for this CAS server and others could be made i think. PHP auth for MW (, apache auth for SVN (, REMOTE_USER for the Django apps (, Forums need to be checked as i think its an old invision (IP board) install and i need versions first and future plans for it.

Just throwing this in here. I think the main used source e.g. forums, should be connected to a LDAP server so that information can be easily used for other purposes in future. --Bennie 10:53, 24 June 2011 (SAST) (J nx)


Have you looked at Crowd as a solution? It is a commercial grade system that is free for non-profis like Zabbix. In fact their whole product line from what I can see is free for non-profits. --User:Phamti

for this community platform fully opensource solutions are preferred to reduce dependency on any single vendor as much as possible --Richlv 15:07, 21 August 2011 (SAST)

Notes about authentication consumers

An authentication consumer is any application which requires authentication information.


It is possible to include the servers themselves into the SSO system. Overall this may not be the best idea from a security standpoint as anyone able to gain access to an admin account in the authentication system is then able to create an account for system login. However with that in mind it is still worth noting as an option. If it is decided not to go this route it would be useful for posterity to note why this was not done.

probably not needed. more complexity and lots of security implications. also the need for such access would be limited anyway. only services that are expected to be interesting for most participants should be important, at least in the first step --Richlv 23:25, 13 January 2011 (SAST)


MediaWiki has a lot of plugins available. Overall it's SSO options are very flexible. Kerberos or LDAP should not be an issue


Pootle is written in python and is best used inside Apache by using either mod_python or mod_wsgi. Pootle also require the Django framework and uses this framework for all of it's authentication information (


Subversion by it's self has a very simplistic authentication system which is file based. It is possible however to tie Subversion into an SSO system using Apache and WebDAV. This is also considered a standard practice for setting up a Subversion server. Subversion however still uses an internal permissions file to prevent access to specific branches of a subversion tree. This permissions information cannot be stored externally.

How many commiter we will have? I think most of user will only checkout, so authentication will be needed for only commiter. --Kodai 23:24, 22 June 2011 (SAST)
while we indeed expect to have most users only need co permissions, it would still be nice for the convenience for committers to have single password for all services - and that should also be fairly trivial to do using apache auth --Richlv 22:23, 25 June 2011 (EEST)


It appears that OSQA may share many of the same SSO issues with Pootle as it too is written in python on top of Django.

Zabbix Test Server

Zabbix can integrate with LDAP very easilly and can even use authentication information passed to it from Apache which means it would be possible for Zabbix to tie into Kerberos. The only caveat is the user must still have an account int the Zabbix database as Zabbix stores all of it's permissions information in it's database. Zabbix cannot use an external system for permissions, only authentication. User creation can be worked around using the API, however it will need to be tied into the user registration process.

imho not really necessary. guest user would have read access to most/all resources anyway, and there's no need for every participant to have authorised zabbix access. for simplicity, this can be currently skipped --Richlv 23:23, 13 January 2011 (SAST)
I think it would be good to Add the Zabbix server to the SSO system should there be a need to escallate the access level for someone in the community to administer the Zabbix server. However by and large this is not as needed as the others. --Nelsonab 01:18, 14 January 2011 (EET)


User Registration

At this moment it is uncertain how users will be able to register for an account. If possible it would be best to use an existing user registration mechanism. Also as pointed out above is a user is to be given access to the Zabbix test server they need to have a user account in the system.

Impementation plan

Task Person Completion Details
Design nelsonab started Need to finalize requirements before setting forth an implementation plan