sso test on Generic Login

[xinchen]

By following the document, sso server and client are installed. Generic Login is installed and enabled, facebook and LDAP are disabled. When run test.php (source obtained from the document), it shows,

"This system does not have any active providers. Either no providers have been configured or your current location has been blocked."

The sso server index.php line 162 below unsets $sso_providers for each providers, even though Generic Login is enabled.

if (!$sso_providers[$sso_provider]->IsEnabled()) unset($sso_providers[$sso_provider]);

I then figured out I need to map both username and email in Generic Login Configure to make the login page shown.

[xinchen]

Now I'm able to login to a user that is created on sso server with sso_site_admin tag and will see the following after login. The URL shown on the browser is something like "https://www.myapp.com/test.php?from_sso_server=1&sso_id=tWzzyc14OUsblNra8BXWBLiRwFoeg0l4-14&sso_id2=v0qbZZZ8vSyLSbKKMSOwxCkb7FQnlXMf-18" (not publicly accessible)

======================
User ID: 1
Username:
First Name:

Test local access (link with url "https://www.myapp.com/test.php")
Logout (link with url "https://www.myapp.com/test.php?action=logout")
======================

My question is:

When I click "Test local access", do I get verified as an already logged in user and stay on the same page? Currently I am sent to the sso server for login again, which seems to me not an expected behavior.

[thruska]

I see you got the first issue worked out. Providers won't be active for users until the provider has the minimum number of fields required mapped to a SSO field.

As to your latest issue, the "Test local access" is supposed to make sure the cookies stuck in the browser. If you are being redirected back to the SSO server, then something isn't quite right with the cookies that were set or your browser refused to set them for some reason. The expected behavior is to stay on the same page as you suspected.

The SSO client takes the 'from_sso_server', 'sso_id', and 'sso_id2' parameters and sets a couple of browser cookies. If they don't get set, then the test local access fails. I call it "local access" because the encrypted cookie is sufficient enough validation to not contact the SSO server for every single request - once every 5 minutes is the default setting.

It also dawned on me that it could also be that the way the SSO client was setup on your system that one or more of the cookies are expiring and the session terminates as a result. The SSO server and client are quite flexible and do allow you to create broken installations as a direct result of that flexibility. It is going to take some digging on your part to figure out what happened. Do let me know so I can either document it or make it less likely to happen in the next release or both.

[xinchen]

I mush have done something wrong on sso client installation, probably at specifying cookie path, which was "/var/www/html/myapp/", which really should be "/" in my case. Like you said, the saved cookie values were not correctly retrieved. However, simply changing SSO_SERVER_PATH to "/" in client/config.php does not solve the problem. There could be other parameters I also assigned wrong.

But after re-install the sso client with "/" for cookie path, the sso now works as expected!

Now, what are the configuration / customization steps to make a user sso across two app servers? Say, I have http://www.myapp.com and http://www.myapp2.com, I only need to login to http://www.myapp.com through sso server and I will automatically login to http://www.myapp2.com, or vice versa?

http://www.myapp.com must construct a query string for http://www.myapp2.com so when redirect to http://www.myapp2.com it can use it to validate the login session with sso server.

[thruska]

Glad to hear it works now.

As to your question, what you describe is essentially a shared login token or namespace that multiple clients use. I'm not sure what the technical name is for it but it wasn't implemented for the first release because the first release was already complex enough. This feature will be available in the next release. From my perspective, it will be simpler to let the SSO server handle all namespace issues than to try to do some funky cross-domain stuff. The user will get redirected to the SSO server after accessing the other domain, logged in via namespace, and then redirected back - possibly right away. A lot of things have to change in order to support this feature - API keys, API endpoint, SSO server and client, possibly a new database table, encrypted cookies, etc. - because logging out has to also log out all locations.

[xinchen]

It was an interesting experience to test your version 1.0 sso. I will be interested in testing your next release and am looking forward to seeing the announcement.

FYI. This version of sso works on CentOS 5.x with httpd, mysql and php53 it carries, plus additional install of mcrypt for php53. However, it fails on a year-old xampp for Windows (which DOES support OpenSSL), which, after sso client installed and test.php run, shows unsupported "tls".

[thruska]

I wrote the whole system on a Windows box (portable WAMP setup) and tested everything pretty thoroughly on both Windows and Linux, including my live LNMP setup. Can you be more specific as to what the error is?

[xinchen]

The exact message is:

"Unable to obtain SSO server login access. Error: The desired transport protocol 'tls' is not installed."

The environment is:

Windows 7
xampp-win32-1.7.4-VC6-installer.exe, which has apache/2.2.17, mod_ssl/2.2.17 OpenSSL/0.9.8o PHP/5.3.4 and mysql 5.5.8

httpd-vhosts.conf includes, among many other virtual hosts:
...
<VirtualHost *:80>
DocumentRoot "C:/dev/sso_server"
ServerName dev.sso.com
</VirtualHost>

<VirtualHost *:80>
DocumentRoot "C:/dev/sso_app"
ServerName dev.app.com
</VirtualHost>
...

httpd-ssl.conf similar

c:\Windows\System32\drivers\etc\hosts includes:
...
127.0.0.1 dev.sso.com
127.0.0.1 dev.app.com

I use "https://dev.sso.com" and "https://dev.app.com" to perform the installation. All green Yes at configuration check.

Could be xampp version old (xampp-win32-1.7.4-VC6-installer.exe).

[xinchen]

In this xampp version, I need to add the following line in php.ini

extension=php_openssl.dll

and it works

[thruska]

Yup. SSL/TLS support is only available when the OpenSSL extension is enabled. PHP for Windows, by default, has all extensions disabled.