Skocz do zawartości
Zaloguj się, aby obserwować  
Invisionize.eu

[Dokumentacja IPS4] Single Sign On (SSO)

Polecane posty

SSO, or Single Sign On, is a technique where-by one (or more) applications can automatically recognize a user as logged in when that user has logged in elsewhere.  You can implement single sign on with IPS Community Suite by letting a remote application recognize a user who has already logged in to the Community Suite as being logged in within the remote application, or by using a plugin with the Community Suite to have it check for users logged in already through an external application.

 

IPS Community Suite as the "Master"

If you want to let external applications recognize users who are logged in to the Community Suite as being logged in on those external applications, there are 2 primary methods to accomplish this task, depending upon your configuration and specific needs.

 

1) Using IPS Connect

One method of implementing single sign on with third party applications is through IPS Connect.  IPS Connect is the only reliable cross-domain method of supporting SSO - this means that if your Community Suite and your external application are located on different top level domains (TLDs), for instance site.com and othersite.com, you should read more about IPS Connect and how to implement it in third party applications.  Be aware that IPS Connect is natively supported by all IPS Community Suite installations alerady.

 

2) Reading the Community Suite session

If your external application is on the same domain or subdomain as your Community Suite and you can easily include the Community Suite PHP files, you can easily include the Community Suite framework and use the objects and methods made available to validate a user as being logged in.  The smallest code example to verify a user as being logged in is

/* Require the init.php file from the Community Suite root directory */
require '/path/to/suite/init.php';

/* Initiate the session to verify who this user is */
\IPS\Session\Front::i();

/* Print the user's name */
print \IPS\Member::loggedIn()->name;

 

Here we load the init.php file located in the Community Suite root directory, then we initiate the session, and finally we print the member's name.  It is also possible to load the values stored in the user's cookies (if any) and validate them against the framework directly, however for the purposes of SSO it is simpler and more accurate to simply check the user's session as per the code snippet above.

 

Warning

Generally, when you are checking if a user is logged in through the Community Suite in an external application you should redirect registration, login, logout, change email and change password requests back to the Community Suite.  This means, if you wish to show users a link in order to perform any of these actions that link should direct the user back to the Community Suite in order to perform the action.  This allows you to centralize all account activities

 

IPS Community Suite as the "Slave"

If you want to allow users who have logged in to a third party application to be automatically logged in to the Community Suite, you will need to create a plugin.  The plugin should contain a code hook that extends the class \IPS\Session\Front, and then you will want to override the read() method.  TIP: You can also create a code hook to override \IPS\Session\Admin if you have a need to implement SSO for the ACP (this is NOT recommended in most cases, as it may allow for unforeseen access to your admin control panel through your own custom code if you are not careful).

	/**
	 * Read Session
	 *
	 * @param	string	$sessionId	Session ID
	 * @return	string
	 */
	public function read( $sessionId )

 

Within the read method, generally speaking you will want to first check if the user is logged in locally by calling the parent read method.  This saves you from processing checking your remote application on every page load once the user has been authenticated.  You will want to check against the local cache as the standard session handler does, and you will want to ensure you only check against a remote application if you have not already done so.  One way to accomplish this is to add a database column to your core_sessions table and then only check the remote application if the column has not been set yet.

Your hook will vary based upon your needs, but a general outline is as follows

 

	/**
	 * Read Session
	 *
	 * @param	string	$sessionId	Session ID
	 * @return	string
	 * @note	We will want to first add a TINYINT(1) column named `already_checked` for this example
	 */
	public function read( $sessionId )
	{
		/* Let normal class do its thing */
		$result = call_user_func_array( 'parent::read', func_get_args() );

		/* Fetch the session data again */
		$key		= "session_{$sessionId}";
		$session	= NULL;

		if ( isset( \IPS\Data\Cache::i()->$key ) )
		{
			$session = \IPS\Data\Cache::i()->$key;
		}
		else
		{
			try
			{
				$session = \IPS\Db::i()->select( '*', 'core_sessions', array( 'id=?', $sessionId ) )->first();
			}
			catch ( \UnderflowException $e ) { }
		}
		
		/* Only use sessions with matching IP address */
		if( \IPS\Settings::i()->match_ipaddress and $session['ip_address'] != \IPS\Request::i()->ipAddress() )
		{
			$session = NULL;
		}

		$this->member->language()->words['login_handler_ipscom']	= "Invisionpower.com";

		/* Only check the remote application if we are not logged in */
		if( !$this->member->member_id AND !$session['already_checked'] )
		{
			/* Check the remote application here - this may involve looking for custom cookies your application sets and then passing them
				to a callback script on the remote server, or including a custom PHP script you have written */

			/* If our check was successful, we create the member if he does not exist, otherwise we load the member.  We then set
				$this->member to the member object we've loaded */

			/* We then set the $this->save property to TRUE and we set our flag so that it will save */
			$this->save = TRUE;
			$this->data['already_checked']	= 1;
		}

		/* Finally, return our session result as normal */
		return $result;
	}

 

The above example should illustrate the basic principles of overloading our default session class, checking your remote application, and then handling the response.

 

Warning

As with running the Community Suite as a "Master", when the Community Suite is configured as the "Slave" you may wish to redirect registration, login, logout, change password and change email requests for the Community Suite to your remote application.  If so, you will need to either create hooks to redirect these requests to your remote application, or you will need to create a custom login handler that can propagate the requests to your remote application.

 

Every SSO implementation is different, so you will need to determine the best approach for your specific needs.

Wyświetl pełny artykuł

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Bądź aktywny! Zaloguj się lub utwórz konto

Tylko zarejestrowani użytkownicy mogą komentować zawartość tej strony

Zaloguj się, aby obserwować  

  • Kto przegląda   0 użytkowników

    Brak zalogowanych użytkowników przeglądających tę stronę.

×

Ważne informacje

Kontynuując przeglądanie strony, wyrażasz zgodę na używanie przez nas plików cookies.