The IPS Community Suite provides a fantastic community solution for all kinds of websites.
For many of our customers, the community is just one component of their site. Many of these customers utilise single sign-on systems for integrating the community with the other areas.
At IPS, we get requests for this on a regular basis, and over the years, I've worked on many of these solutions as part of my day-to-day workload.
Companies like Evernote and Roxio have created a single sign-on solution with the IPS Community Suite and their existing user databases.
Other companies which manage large numbers of communities like the NFL and the NHL have created a single sign-on solution allowing all their communities to share the same user database.
Creating these systems can be quite arduous though. Every setup has different ways of handling data and systems must be created bespoke to each situation.
6 years ago, we had an idea to simplify this. What if we could create a solution that would allow a network of web applications to share user information? We created a solution and called it IP.Converge.
Over these 6 years though, the internet has changed. IP.Converge was designed to be a "master" in a network of "Converge compatible" applications. This approach had two main shortcomings: firstly, it is often the case that our software needs to be the "slave" in a single sign-on network, secondly, the approach was too general which made both facilitating full single sign-on (where users are automatically logged into all applications after logging into one) was difficult, and making non-IPS software compatible with Converge was extremely difficult.
Fortunately, we think we've come up with a better solution. As of IP.Board 3.4, we are completely removing support for IP.Converge, and have developed a new system, which we're calling IPS Connect.
IPS Connect has no central application. In an IPS Connect network, one of the applications will serve as the master, and there will be any number of slaves working off it.
When writing IPS Connect, we had three main objectives:
So what does this mean?
As of IP.Board 3.4, it will be easy, and completely seamless to create a single sign-on network between 2 or more IP.Boards, and 3rd party developers will also be able to write support for any other web application to join in in the network.
How does it work?
For the simplicity of this example, let's say you're networking 2 IP.Board installations.
The "master" installation has a secret key which will be given the "slave" installation.
When a user visits the "slave" installation, IP.Board will check if they are logged into the "master" installation - if they are it will log them in automatically, creating the account if necessary.
If they're not logged in, but then choose to log in on the "slave" installation - they will automatically be logged into the "master" installation. This happens transparently, without the user leaving the "slave" installation.
When a user registers or updates their account, the "master" application will be pinged and updated. Again, this happens transparently.
How simple is it to write support for my custom web application?
Really simple!
If you want your application to be the "master", all you need to do is create a single php file which "slave" applications will send requests to. This needs to do things like facilitate log ins, account registrations, etc.
If you want your application to be the "slave", you simply ping that file on the "master" application when stuff happens.
We've created 2 completely functional example websites which demonstrate exactly how to do this, which will be available to download when 3.4 is released.
[*]Single Sign-On must be completely automatic and effortless. After logging into any application in the network, the user should be automatically logged into all others. And similarly, after logging out, the same. [*]The process should be completely transparent to the user. The user should be able to register an account, or update account information on any application in the network, and these changes should be pushed transparently to the other applications. [*]It should be easy for developers to make their web applications compatible with IPS Connect - and they should be able to make their web applications serve as either the master or the slave.