SSO/Writing an SSO Plugin

From Authentication Tools for Joomla! (JAuthTools)

(Difference between revisions)
Jump to: navigation, search
Line 3: Line 3:
* Type B plugins are a step above which use callbacks to identify the user. These systems use links to gain access and doesn't require the user to do much more than click on it and let the system redirect them around and eventually authenticate them. Examples of this are the SOAP SSO and SimpleSSO systems. These systems should implement the 'getSPLink' and should expect to be passed params from the SSO Providers table (provided into the constructor). They should also implement the 'detectRemoteUser' call to help detect the remote user in either a directly identified situation (e.g. the SSO system knows that this plugin should be used) or in a more general sense (the plugin is called in plugin group). Additionally the plugin should also support the 'getOperations', 'ping' and 'refresh' calls.
* Type B plugins are a step above which use callbacks to identify the user. These systems use links to gain access and doesn't require the user to do much more than click on it and let the system redirect them around and eventually authenticate them. Examples of this are the SOAP SSO and SimpleSSO systems. These systems should implement the 'getSPLink' and should expect to be passed params from the SSO Providers table (provided into the constructor). They should also implement the 'detectRemoteUser' call to help detect the remote user in either a directly identified situation (e.g. the SSO system knows that this plugin should be used) or in a more general sense (the plugin is called in plugin group). Additionally the plugin should also support the 'getOperations', 'ping' and 'refresh' calls.
* Type C plugins determine how to authenticate the user from user provided information, such as a URI. These plugins should implement the 'getForm' function and return a HTML form to be used by the system. Like both Type A and B plugins, it should also implement the 'detectRemoteUser' call.
* Type C plugins determine how to authenticate the user from user provided information, such as a URI. These plugins should implement the 'getForm' function and return a HTML form to be used by the system. Like both Type A and B plugins, it should also implement the 'detectRemoteUser' call.
 +
 +
All plugins should expose what plugin type that they are via the 'getSSOPluginType' function in addition to specifying this in the install XML file.
Line 122: Line 124:
}
}
}
}
 +
 +
 +
= Sample Install XML file =
 +
This is a simple install XML file for the type B plugin, however many options can be modified to match the requirements of other types of SSO plugin.

Revision as of 06:17, 1 December 2008

Writing an SSO plugin for your favourite service is actually quite easily. You first have to however ask what sort of SSO plugin you want to write as there are three:

  • Type A plugins are the most basic and only need a 'detectRemoteUser' call to be activated. They're called and expected to use information in the session to determine the remote user. Examples of this are the HTTP SSO, IP SSO and eDirLDAP SSO plugins.
  • Type B plugins are a step above which use callbacks to identify the user. These systems use links to gain access and doesn't require the user to do much more than click on it and let the system redirect them around and eventually authenticate them. Examples of this are the SOAP SSO and SimpleSSO systems. These systems should implement the 'getSPLink' and should expect to be passed params from the SSO Providers table (provided into the constructor). They should also implement the 'detectRemoteUser' call to help detect the remote user in either a directly identified situation (e.g. the SSO system knows that this plugin should be used) or in a more general sense (the plugin is called in plugin group). Additionally the plugin should also support the 'getOperations', 'ping' and 'refresh' calls.
  • Type C plugins determine how to authenticate the user from user provided information, such as a URI. These plugins should implement the 'getForm' function and return a HTML form to be used by the system. Like both Type A and B plugins, it should also implement the 'detectRemoteUser' call.

All plugins should expose what plugin type that they are via the 'getSSOPluginType' function in addition to specifying this in the install XML file.


A simple Type A plugin

This type A plugin always identifies the user 'admin' and doesn't do any actual detection work itself. Instead of returning a fixed username, a type A plugin should attempt to detect the user or return false if it cannot detect a user.

<?php
jimport('joomla.plugin.plugin');

class plgSSOTypeA extends JPlugin {
	/**
	 * Constructor
	 *
	 * For php4 compatability we must not use the __constructor as a constructor for plugins
	 * because func_get_args ( void ) returns a copy of all passed arguments NOT references.
	 * This causes problems with cross-referencing necessary for the observer design pattern.
	 *
	 * @param object $subject The object to observe
	 * @since 1.5
	 */
	function plgSSOTypeA(& $subject, $params) {
		parent :: __construct($subject, $params);
	}

	function getSSOPluginType() {
		return 'A';
	}

	function detectRemoteUser() {
		return 'admin';
	}
}

A simple Type B plugin

This type B plugin hands off the to default JAuthTools Google App Engine SimpleSSO provider. A type B provider supplies two pieces of information, the 'detectRemoteUser' function and the 'getSPLink'. In this example the SP link is hard coded, however the params section of the plugin will be used by the SSO system for Type B plugins to create instance params as opposed to global params. Depending on a plugin's type, different params will be used. In this example no validation occurs and the token is simply accepted and validated as the administrator user.

<?php
jimport('joomla.plugin.plugin');

class plgSSOTypeB extends JPlugin {
	/**
	 * Constructor
	 *
	 * For php4 compatability we must not use the __constructor as a constructor for plugins
	 * because func_get_args ( void ) returns a copy of all passed arguments NOT references.
	 * This causes problems with cross-referencing necessary for the observer design pattern.
	 *
	 * @param object $subject The object to observe
	 * @since 1.5
	 */
	function plgSSOTypeB(& $subject, $params) {
		parent :: __construct($subject, $params);
	}

	function getSSOPluginType() {
		return 'B';
	}

	// Required for Type A and B plugins
	function detectRemoteUser() {
		$key = JRequest::getVar('authkey','');
		if($key) {
			return 'admin';
		} else {
			return false;
		}
	}

	// Required for Type B plugins
	function getSPLink() {
		return Array('title'=>'SimpleSSO JAuthTools GAE Test',
			'description'=>'This uses the SimpleSSO JAuthTools Google App Engine Test SimpleSSO provider',
			'link'=>'http://jauthtools.appspot.com/?landingpage='.JURI::base()
		);
	}
}

A simple Type C plugin

This simple Type C plugin redirects the user back to the Joomla! site itself and gets the system to login with the username that was provided by the user. This is a primitive example of how a Type C plugin could work, better examples would be an OpenID provider.

<?php
jimport('joomla.plugin.plugin');

class plgSSOTypeC extends JPlugin {
	/**
	 * Constructor
	 *
	 * For php4 compatability we must not use the __constructor as a constructor for plugins
	 * because func_get_args ( void ) returns a copy of all passed arguments NOT references.
	 * This causes problems with cross-referencing necessary for the observer design pattern.
	 *
	 * @param object $subject The object to observe
	 * @since 1.5
	 */
	function plgSSOTypeC(& $subject, $params) {
		parent :: __construct($subject, $params);
	}

	function getSSOPluginType() {
		return 'C';
	}

	function detectRemoteUser() {
		$remote_user = JRequest::getVar('remote_username','');
		if($remote_user) {
			return $remote_user;
		} else {
			return false;
		}
	}

	function getForm() {
		return '<form method="post" action="'. JURI::base() .'">Requested Username: <input type="text" name="remote_username" value="" /><input type="submit" value="Login" /></form>';
	}
}


= Sample Install XML file =
This is a simple install XML file for the type B plugin, however many options can be modified to match the requirements of other types of SSO plugin.
Personal tools