Jump to content






Photo
* * * * - 5 votes

IP.Board 3.4 Dev Update: IPS Connect

Posted by Mark , in 3.4.x 09 August 2012 · 28,925 views

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:
  • 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.
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.

  • Jim, AndyF, Nick▓ and 35 others like this



I didn't quite fully understand the concept, but seems to be a good approach! Is it going to open doors for direct integration of 3rd party applications like WordPress?
Finally! Thanks!
    • ZackL likes this
This looks excellent! I'm working on a custom site that I want to integrate with one of my IP.Board communities, and it sounds like IPS Connect will make it much easier to do this than poring over the IP.Converge documentation. I look forward to snooping through the two example sites to see how it works. :)

I have a couple of questions:
  • Does IPS Connect require all "connected" applications to reside on the same domain, or can it handle cross-domain SSO as well?
  • Does the mentioned "updating of account information" on any site in the network apply only to the username, password, and email address, or can IPS Connect handle all kinds of account data like avatars/photos, profile fields, "about me" text, etc.?
Cross-domain SSO and a straightforward API for sharing account data will make IPS Connect a true ace in the hole.
    • dr. Jekyll, AlexJ, DeRealDeano and 6 others like this
Here's the one big question I have. Using two IPB's as an example, if you ban or ModQ a member on one, will it affect the other or is that still a limitation as was with IP.Converge?
    • dr. Jekyll, AndyF, AlexJ and 5 others like this
Would it be possible to migrate from IP.Converge and use your default SSO in 3.4?

Also what would happen if you delete one user from master forum? Would it be deleted from all slaves as well?
Oooh nice. I have a question...can the master be changed?
    • AlexJ and mrcikeprcike like this
NICE AT LAST

I didn't quite fully understand the concept, but seems to be a good approach! Is it going to open doors for direct integration of 3rd party applications like WordPress?


Yes - if someone wanted to write IPS Connect support for Wordpress, or any other 3rd party application, it would be relatively simple to do.


This looks excellent! I'm working on a custom site that I want to integrate with one of my IP.Board communities, and it sounds like IPS Connect will make it much easier to do this than poring over the IP.Converge documentation. I look forward to snooping through the two example sites to see how it works. :smile:

I have a couple of questions:

  • Does IPS Connect require all "connected" applications to reside on the same domain, or can it handle cross-domain SSO as well?
  • Does the mentioned "updating of account information" on any site in the network apply only to the username, password, and email address, or can IPS Connect handle all kinds of account data like avatars/photos, profile fields, "about me" text, etc.?
Cross-domain SSO and a straightforward API for sharing account data will make IPS Connect a true ace in the hole.


In order for SSO to work, applications must be on the same domain (there are a few ways around this which we might look into in a future release, but I'm not particularly keen on any solution I've seen - essentially it's a limitation of how cookies work).
However, if applications are on different domains, you can still log in with the same details, you just won't be logged in automatically.

Currently we only do account information (username, email, password) - we'll almost certainly add support for additional stuff down the line, but out of the door, we wanted it to be really easy for developers to write support for other apps, and this adds complexity.



Here's the one big question I have. Using two IPB's as an example, if you ban or ModQ a member on one, will it affect the other or is that still a limitation as was with IP.Converge?


It will not affect the other - just like with the pictures and stuff mentioned above, we'll almost certainly add stuff like this down the line, but we wanted it to be really simple to work with to start.


Would it be possible to migrate from IP.Converge and use your default SSO in 3.4?

Also what would happen if you delete one user from master forum? Would it be deleted from all slaves as well?


IP.Converge maintains local databases everywhere, so you just turn off Converge, no need to migrate anything.

If you delete a user from the master, it depends if the slave has a fallback mechanism in place (the IPS Community Suite allows you to turn fallback mode on or off) - if it's turned on, nothing will change on the slaves, if it's turned off, they won't be able to log into the slaves.


Oooh nice. I have a question...can the master be changed?



Yes.
    • AlexJ, Srinath, Marcher Technologies and 1 other like this
With five sites, you've just made me very happy indeed... well done guys...
WOOHOO! This is the news I've been waiting for!
Will allow us to make login methods without requiring to distribute a hook for displaying the image login image or button?
Liking this :)

Yes - if someone wanted to write IPS Connect support for Wordpress, or any other 3rd party application, it would be relatively simple to do.


Awesome! This is going to not only increase Marketplace apps, but also improve IPS revenue! :)
I CAN'T WAIT. I've used IP.Converge for years and it always had so many problems and support was minimal until the last year or so when it completely died off so I'm really glad this is here to replace it. It seems much more efficient and easier to use.

Most importantly, it's seamless for the users on the website. Great job, IPS! Can't wait for this to be released.
Revolution.
Revolution x 2 = When "IPS Connect can handle all kinds of account data like avatars/photos, profile fields, "about me" text, etc"...etc etc etc!!!!.

To come out of the dark shadows and make a comment on the board, YOU KNOW I'M FEELIN THE LOVE ON THIS MOVE BY IPS!!! Looking forward to it being implemented in 3.4 and EXPANDED as said above. Niceness.
    • CallieJo likes this
Great news!

I'd love to see the day when the profiles are condensed to one master. If you have 2 or more connections, they all link to one profile located on the master. Although, I can see the issue of users' content being a task to conquer with this unless links were provided to different connected content instead of content lists from current connection.
Still with the requirement for it to be a PHP script though. Many applications within my network are not PHP, but are actually mostly ASP.NET - certainly at least the ones I'd rather designate as a master are. The connector script should really be language agnostic - if it can talk "IPS Connect" it should be able to be pointed at and used.
Drupal+ip= love
So this is no Facebook Connect-like addition?

September 2014

S M T W T F S
 123456
78910111213
14151617 18 1920
21222324252627
282930    

Recent Entries

Latest Visitors

  • Photo
    Jaydennn
    24 minutes ago
  • Photo
    Carl M
    50 minutes ago
  • Photo
    chivitli
    50 minutes ago
  • Photo
    thehub
    56 minutes ago
  • Photo
    edgardo
    Today, 02:54 AM
  • Photo
    Thomas Riemann
    Today, 02:51 AM
  • Photo
    dmayo305
    Today, 02:12 AM
  • Photo
    Gravi5tar
    Today, 02:11 AM
  • Photo
    Edward Shephard
    Today, 01:57 AM
  • Photo
    Damian seijas
    Today, 01:18 AM

Recent Comments

Search My Blog