Implementing SSO with Vanilla forums

x00

AppStartup is too late. Session and authentication have already passed.

If you want to do as @hgtonight‌ says

copy library/core/authenticators/class.passwordauthenticator.php and name it something like library/core/authenticators/class.magentoauthenticator.php and rename the class
Gdn_MagentoAuthenticator

then modify it to do what you want

enable in conf/config.php

$Configuration['Garden']['Authenticator']['EnabledSchemes'] = array('magento');
$Configuration['Garden']['Authenticator']['DefaultScheme'] = 'magneto';

it will no longer be password authentication.

However this doesn't cover the user creation, you would have the incorporate it possibly in the authenticator.

You want to store the Vanilla UserID with the magento side or store the magento user is in the Vanilla User table's ForeignID. That is how you will link the accounts. Don't do it on name or email.

x00

I see some potential weakness is passing around authentication in $_SESSION, and the vanilla authentication is only as strong as your SSO login authentication. Any possible influence of that your authentication compromised.

Thing is it not happening at the time, nor is there any verification at the time like a connect method (in the case jsConnect a three step handshake).

You are logging in, then you waiting till they visit the forum, then relying on $_SESSION being correct and not compromised.

From what I understand is you are building a top level login that is both over Magento and Vanilla and of neither. What best practices are going to follow to secure both the initial authentication and the corresponding authentication of Vanilla and Magento?

This is quite an advanced topic. That is why existing framework have already put some thought and development into their authentication.

x00

So in short you need more direct verification. Either a connect method by use of curl which need to be secure such as with token based system, or to directly the run the primary authenticator.

I would really steer clear of global sessions.

Linc

I suggest using 2.2, the master branch to do this. There have been some significant strides made in this area since the 2.1 fork.

Then try using:

• EntryController_OverrideSignIn_Handler to displace the normal sign in
• EntryController_OverrideSignOut_Handler to displace the normal sign out
• EntryController_YOURMETHOD_Create to create a new SSO endpoint
• Base_ConnectData_Handler to implement your handshake

Generally, spend some time looking at the new Override ability in the EntryController.

You can likely cobble a much more elegant solution using this new approach available in 2.2. It sounds like it would be worth the risk of working ahead of the stable release for that benefit in this case.

hgtonight

I agree with @x00 that this is not a very secure system.

It would definitely be seamless to the end user though.

x00

@Linc those are interesting but in my experience most people aren't interested in overriding entry, they simply want block or redirect to the external service. This is entirely possible with 2.1, and you can override the linkage, which can include redirects.

There are two/three definitions SSO:

1. single authority single access point
2. single authority multiple access points
3. federated authentication provided by authorities with multiple access points

Then there is social connect which is not really SSO but a hybrid of multiple solutions.

In general where it is a single site solution overwhelmingly they want the first. They don't want a whole host of different interfaces.

slRobertS

From what I understand is you are building a top level login that is both over Magento and Vanilla and of neither. What best practices are going to follow to secure both the initial authentication and the corresponding authentication of Vanilla and Magento?

I've not finalised the details of the login system as of yet, except to say the entire site will be over https:\\ and a secure password algorithm will be used. - as for best practice, it would be negligent to move away from tried and tested methods in relation to user security. Rest assured - security is paramount.

I agree with @x00 that this is not a very secure system.

I suppose there are issues to consider with the use of the $_SESSION - a users session getting hacked would be a valid concern here - but I am not precious about the solution I have described - it's an abstract overview of how this *might* work. Before I think about making this entire system secure I have to have the right mix of technology. For me, the best fit for the project is a technology that allows me to extend it in a safe and sensible way - without hacks or changing the core code - or using JavaScript.

@Linc - Thank you for your advice - I will have a look and get back to you.

slRobertS

Just to pick up on this

(definition of sso..) single authority single access point

Is exactly what we are hoping to achieve. As we will be writing custom themes the idea was to remove or replace links to a single login page which would then redirect the user back to their target. I understand Vanilla allows you to configure these settings which is good. Because the entire site will be themed the same, the hope is most users do not realise they have been moved elsewhere. (It may also be progressively enhanced with JavaScript, like Vanilla does already with its' login mechanism)

Thinking in Vanilla terms has proven challenging so far - but this is down to a reluctance to hack - I will be giving this some further thought over the weekend as this is not the only Vanilla challenge I have been presented with. (I'm also investigating writing a plugin that will allow us to use Amazon S3 as a file storage layer as our systems are cloud based and distributed)

edit:

I should have picked up on this earlier - is the http://en.wikipedia.org/wiki/Hash-based_message_authentication_code you referred to earlier is because of a requirement for Vanilla to authenticate users over http:// ?