Implement Single Sign On (SSO) for Windows Enterprise Users

[deleolajide]

Use the Waffle library to implement SSO for Windows Active Directory Users
See https://github.com/Waffle/waffle

[deleolajide]

The plan is to make this be as simple as possible. Just 2 check box clicks

First check box click.

So far so good. This is now working with Waffle Servlet Single-SignOn Security Filter 1.9.1 and is way more easier than Kerberos with Spark.

It however does requires Openfire to be installed on a Windows server that belongs to the Active Directory domain we intend to authenticate against and also because Waffle uses Windows DLLs. This is the majority of use cases for AD integration.

The server-side logic to this is all in the Openfire Chat API plugin. It exposes a SASL mechanism called OFCHAT which has to be enabled.

Second check box click

Thats it!! Jetty does the heavy lifting and single sign on between Pade and Openfire. No password is required or exchanged between them. A session token is cached in browser and reused by Converse, Jitsi-Meet and Rest API authentication.

@guusdk : We discussed the in Montreal. What do you think?

[deleolajide]

This issue is re-opened in response to a request at the Ignite Realtime weekly meeting to support corporate deployment of Pàdé with Windows SSO to many employees in a single simple effort.

The issues identified are:

• Take advantage of the group policy deployment tools for Chrome Extensions provided by Google.
• Pre-configure Pàdé with connection settings
• Streamline Pàdé options and settings to corporate standards.

A possible solution with branding was identified in #89

However, this does not cover the majority use case of using the stock Pade@Work version available from the Chrome Web Store.

[deleolajide]

In order to perform a zero-config of Pade@Work with Windows SSO, implement the following strategy

• Create a branding file (pade.json) and copy to the root folder of your Openfire web server (OPENFIRE_HOME/resources/spank). . Make sure winSSO is enabled. See Extend Pàdé branding to cover Pàdé options and user preferences #89 for details
• Send out an email to all users involved informing them to keep the Openfire Meetings home page opened in their browsers. Include the actual link for them to click on.
• Perform a group policy deployment with the tools for Chrome Extensions provided by Google.
• If you include the link to Pade@Work in the email and ask them to self-install, then the group policy deployment step can be skipped.
• When Pade@Work gets installed, it will check for the opened Openfire Meetings web page in the browser. If found, it will then extract the server name and port to configure Pade@Work and then do a restart. If Windows SSO was enabled and user account correctly setup in Openfire, the user should be automatically logged in.

[deleolajide]

This is now implemented in version 0.8.0

You would need a file called pade.json in OPENFIRE_HOME/resources/spank. The minimum parameters are

{
    "useWebsocket"    : {"disable": false, "value": true},
    "useWinSSO"       : {"disable": false, "value": true}
} 

Make sure Openfire Meetings is already opened in any browser tab.

If not and you get the Pàdé options/login page, simply re-install Pàdé after opening the page. If all goes well, Pàdé should be auto-configured with the same openfire server as Openfire Meetings and the user configured as the Windows desktop user.