Add-on [PAID] Multiple XF Single Sign-on Solution

[Anthony Parsons]

However, will it be possible to use the SSO only with xenFORO sites or can I also use other CMSes like Drupal or Wordpress?

If you, or another, gets a slave developed by Nathan for another software, then it will integrate. If not... then it is just XF for now.

 

[Anthony Parsons]

Spam issues ... hmmmmmm ... might get tricky !!!

That is one issue you could open yourself up to if you don't have adequate spam prevention, however; I am not experiencing this issue as all my sites use:

• Splendidpoint anti-spam link posting
• Jaxels XenUtiles mod, using stopforumspam database
• Delete zero posters (removes dormant spammer accounts)

 

[Anthony Parsons]

Hopefully the "sister sites" will let users know (in the Login area) they can use the login and password from the first site.

Made a quick version to achieve this today... so it can be done. No, I don't plan on releasing a supported add-on to do this, but I will list it in the SSO thread when Nathan releases his mod, as an unsupported addition for those to enable the eAuth bar when FB or such is not enabled....

The below is a basic list version, though you could do it anyway you wanted... phrase it, image, etc.

 

[Anthony Parsons]

What if someone tries to register at a second site with the login name of someone else that already exists the first site?

Then they get an error upon registration like the below:



If you register on a slave, it also gets registered to the master. If you register at the master, then you are registered at the master only, so... regardless where you register, everything calls back to the master to see if that username or email is in use or not, thus resulting in the above error for you to choose again / supply a unique email address.

Will that name be rejected unless they know the corresponding password ?

That name cannot be registered, period, on any SSO site.

If you had that name, then you just use it with your password on any site within your SSO network to login.

Whilst I cannot say every foreseeable option has been catered, I have tried to break the system every way near possible that I could think of, and I came up with some creative ways, and every time a way was found, Nathan has built in an error redundancy or solution to cater the issue.

Adding another good example, I register on a slave as xen01 with email address. That also registers at the master account.

Now I try and register a different username, xen02 at another slave, using the same email address as I used with xen01, and the same resulting error:



I will say, this has been thoroughly tested using default Xenforo registration fields.

Things may become more complicated with people using custom fields that are required, as SSO is not designed, nor could ever be possibly catered to authenticate every custom field option. How it will handle custom fields has not been tested, as they are not default Xenforo registration requirements.

 

[The Dark Wizard]

If I delete a user on the master, it will delete it on all the slaves?

What if I delete it on the slave first?

Is total member count shared on all sites?

 

[SchmitzIT]

It would be great hearing more about the custom fields. That might be something we really could put to use for our purposes.

What if I clombine several sites that are already running, each with their own database? Users might exist in one or more of the existing databases, using different names and mail addresses, and yet prefer to switch to SSO. Is that possible at all? If not, we would be willing to pay to get that done.

 

[The Dark Wizard]

It would be great hearing more about the custom fields. That might be something we really could put to use for our purposes.

What if I clombine several sites that are already running, each with their own database? Users might exist in one or more of the existing databases, using different names and mail addresses, and yet prefer to switch to SSO. Is that possible at all? If not, we would be willing to pay to get that done.

I agree with this.

I have a master with 172 users and my slave would have as of now 4,484.

When I install this I would like for both boards to have 4656 users.

 

[SchmitzIT]

I think our situation is different than that. We have several forums, all of which have several thousand users, some of whom might exist only in one location, or in some locations, or all of them.

We'd settle for a way to close the old account, and then transfer their settings (post count, likes, and what not) from the individual slaves to the new accounts on the same slaves.

(i.e. old account: SchmitzIT on slave 1 will be renamed to SchmitzIT_closed, all likes, user options, etc, will be copied to new SchmitzIT account once the nrew account is pushed in from the master).

That way, those users who want to switch can do so, and the ones that wish to stick to their individual account would also be able to do so.

Even better would be synchronizing the banlist from all slaves to create a master-ban list. Anyone found in there will not be able to get a new SSO login. That's what they get for being naughty!

 

[Anthony Parsons]

If I delete a user on the master, it will delete it on all the slaves?

No. Each site manages a user uniquely, permissions, etc. If you deleted them from the master, they would only need login at the slave again for a new master account to be created, as every slave works to the master. Once you use an account at a slave, it is created at the master.

There is no account at other slaves until the person logs into that slave, however; their username is reserved once registered for them, and them alone, at every slave already once registered.

What if I delete it on the slave first?

Then it just sits at the master.

If you want to get rid of an account completely, then you delete it from every site in the network.

Is total member count shared on all sites?

No... again, everything must go back to the master if either registered or an existing user at a slave logs into the slave and does not have a matching account at the master. Other slaves are not affected until a user physically logs into the slave, thus creating the account.

If you wanted to stop someone using a site with that username, you would ban them on that site, not delete them. That would not affect that user from then still accessing other sites, as the account still exists at the master.

 

[Anthony Parsons]

It would be great hearing more about the custom fields. That might be something we really could put to use for our purposes.

Ok... surprisingly, it actually worked without issue using custom fields, both required and non-required, within registration. So that proves that aspect works without issue, as it only pulls and argues with default XF fields, not custom fields.

What if I clombine several sites that are already running, each with their own database? Users might exist in one or more of the existing databases, using different names and mail addresses, and yet prefer to switch to SSO. Is that possible at all? If not, we would be willing to pay to get that done.

Slaves have a sync ability to the master already, which allows you to find conflicts with existing users.

All you need to do is tell existing users to change their email address so that it's the same on each site. They will keep their existing username on each site, as the SSO will link them up when they login to each site with their existing username.

Even without logging in on each site, because they have an account with matching email, all they need do is login on one site in a browser session then visit any other network site and they will automatically be logged in based on their email.

So yes, they may have different usernames on each site, as long as they're unique still... and passwords can be unique to each site, as long as the email address is the same on each account, SSO will take over and manage their login.

If they have an account on 3 of the four sites in the network, obviously one is the master, then when they go to login to the site they have no account with, it will use the masters username on newly created accounts across other sites within the network.

 

[Anthony Parsons]

I think our situation is different than that. We have several forums, all of which have several thousand users, some of whom might exist only in one location, or in some locations, or all of them.

We'd settle for a way to close the old account, and then transfer their settings (post count, likes, and what not) from the individual slaves to the new accounts on the same slaves.

You don't need to close any account, you just need to change their username in the ACP to remove any clashes between a slave and master. That is why each slave has a sync function to the master, allowing you to see a list of those users who will have clashes and not be able to use SSO without a username change / ensuring their email is the same on all sites.

When you have two sites, both with the same username and different email, belonging to two people, then there will be a clash. The slave will not be able to login to the master, nor the master login to the slave. One of them would have to change their username slightly... ie. add a number or letter to it in order to make it unique.

The initial version does not cater clashes at the user level, however; I can say that Nathan is already aware of this and is planning to build this in at user level in a future release. Basically, when a clash exists the user will get a notification with recommended selections as a one-time event to change their username to something unique, thus automatically fixing clashes with existing members on networks with large user bases on each site.

It has been factored. Again though, when Nathan chooses to add it is up to him obviously.

 

[SchmitzIT]

Ok, I'm sold. Count me in for buying this when it launches.

 

[The Dark Wizard]

Same! I hope this comes up soon, we desperately need it

 

[Anthony Parsons]

I could say, expect it this month, though that also depends on Nathan's obvious workload during the month. Whilst it is packaged and stable for use, I believe he has to write correct data sheets, etc, covering most of these exact questions... a user manual basically, along with some other fine tuning he may make to it, along with establishing a site to support the product correctly.

Obviously he wants to make money from this himself, but again... workloads dictate when.

 

[Naatan]

Hey guys, sorry for not responding more often, the notifications I get from XF seem awfully random (perhaps an idea for a next addon).

To give you a status update, the support site is almost done, I hope to have it live by the start of next week, at which point the addon will become available in the XF resources section.

I'm planning to sell the addon at 60 USD per license. Each license will cover one "network", a network being a collection of sites that share their login details through the addon. There is no limit for the amount of sites you want to cover under your network.

If you have any thoughts on the pricing and/or licensing, please let me know.

 

[akia]

Hey guys, sorry for not responding more often, the notifications I get from XF seem awfully random (perhaps an idea for a next addon).

To give you a status update, the support site is almost done, I hope to have it live by the start of next week, at which point the addon will become available in the XF resources section.

I'm planning to sell the addon at 60 USD per license. Each license will cover one "network", a network being a collection of sites that share their login details through the addon. There is no limit for the amount of sites you want to cover under your network.

If you have any thoughts on the pricing and/or licensing, please let me know.

Just a quick question, if we wanted to pay to extend this to other software, as a rough guestimate what would we be looking at.

 

[Naatan]

Just a quick question, if we wanted to pay to extend this to other software, as a rough guestimate what would we be looking at.

I'm already working on another addon which derives from XenSSO but is not part of XenSSO. It will basically allow you to run your own OpenID server and OpenID consumers, which can then be used in conjunction with third party applications that support OpenID. It won't support all the features XenSSO offers, but you will be able to sign on with one account across all sites that you connect to it. And you will be able to use it next to XenSSO.

 

[Anthony Parsons]

It will basically allow you to run your own OpenID server and OpenID consumers, which can then be used in conjunction with third party applications that support OpenID.

This is what I love about this entire project... its limits are near endless with integration possibilities with an OpenID suite.

If I understand this correctly Nathan, basically any existing module made for a software that caters OpenID login could then be integrated with XF and XenSSO, such as a Joomla authentication module: http://extensions.joomla.org/extens...7czo2OiJvcGVuaWQiO2k6MTtzOjc6Im9wZW5pZHMiO30= as an OpenID consumer, and WordPress lovers: http://wordpress.org/extend/plugins/openid/

Is this the right thinking based on your above?

 

[Naatan]

This is what I love about this entire project... its limits are near endless with integration possibilities with an OpenID suite.

If I understand this correctly Nathan, basically any existing module made for a software that caters OpenID login could then be integrated with XF and XenSSO, such as a Joomla authentication module: http://extensions.joomla.org/extensions/access-a-security/site-access/authentication-cloud-based/19293?qh=YToyOntpOjA7czo2OiJvcGVuaWQiO2k6MTtzOjc6Im9wZW5pZHMiO30= as an OpenID consumer, and WordPress lovers: http://wordpress.org/extend/plugins/openid/

Is this the right thinking based on your above?

Yes that's right, as long as both the provided and the consumer support the same version of OpenID (there's only 2 really "out there") it should work. Like I said though, it will not be XenSSO that will be providing the OpenID connectivity, rather I am developing an addon dedicated just for this purpose. XenSSO will be focussed entirely on XenForo SSO as I am adding specific features to it that will not work with the default OpenID standard.

 

[Andy.N]

If my master is www.site.com and I create several regional slaves at cn.site.com, ca.site.com, fr.site.com
I assume I have to create different database for those site with multiple XF licences.

And your addon should work without problem?