OpenID Consumer Support

[ghost]

I have recently become acquainted with TYPOlight and have been very pleased with the system - it is an excellent CMS. My only hesitation (keeping me from widely implementing TYPOlight) is it's lack of OpenID support, something which I believe would thoroughly future-proof this fantastic CMS and would make it a leader in it's field.

I believe that if TYPOlight is going to go forward as a CMS then it is going to have to support authentication via. OpenID for FE-users/members. Many other popular CMSs already support OpenID, such as Drupal and Wordpress, and so unless TYPOlight begins to support it then it will likely soon fall behind.

h2. About OpenID

From [[openid.net]]: "OpenID is a safe, faster, and easier way to log in to web sites." How OpenID works is that the user has an account with a provider website (eg: Google, Facebook, myOpenID.com). When they want to log onto a consumer website (eg: stackoverflow.com, many blogs and over 50,000 other websites, and proposedly any TYPOlight website) they simply type in the URL given to them by their OpenID provider. The user is then directed to their provider's website where they must prove their identity to the provider (eg: password, digital certificates, etc.) and then the provider informs the consumer that the login was successful. The user then proceeds as usual to use the consumer website.

Some key advantages of this system are that:

• the first time login (sign-up) to each consumer website is MUCH quicker (no long signup forms, email verification, etc.), so you have a happy user
• the user needs only remember ONE password, not dozens for all the websites they use
• no email verification is necessary for the consumer site (because it has already been done by the provider)
• the consumer website is able to pull a large variety of data about the user from the provider (preventing long sign-up forms)
• the consumer website can potentially be configured/designed to accept both local accounts (as currently used by TYPOlight) and OpenID accounts
• the consumer website can store user accounts & associated data in a table (as currently done by TYPOlight), simply having some different or additional columns For more information see [http://openid.net/add-openid/]

h2. Implementation

I propose that OpenID be implemented into the TYPOlight core for the FE (members) as an alternative method for FE-user/member authentication. TYPOlight could be made an OpenID consumer, allowing users/members to log into the FE using their existing OpenID. The user could be given the choice of either using an OpenID, or using a normal user account and password (as TYPOlight currently uses). This would aid backward-compatibility and would give site administrators the choice of whether to allow OpenID, locally stored passwords, or both methods of authentication on their TYPOlight installation.

Many PHP libraries for implementing OpenID are available: [http://openid.net/developers/libraries/#php]

I would recommend the PHP OpenID Library: [http://www.openidenabled.com/php-openid/] This library is ideal because it's licensing is permissive enough for it to be included in TYPOlight, and because it allows implementation of both the provider and consumer sides of OpenID authentication, which would be useful should it be later desired to enable TYPOlight as an OpenID provider also.

Using this library, implementing OpenID would simply require adding some additional columns to the TYPOlight members table to store the OpenIDs associated with accounts, and extending the existing member signup pages (in both the FE and BE). All other member associated features can remain unchanged, because the members table will also remain otherwise unchanged because OpenID implementation would only affect authentication aspects.

h3. Licensing

The PHP OpenID Library is freely distributed under the Apache v2 license, which does permit redistribution within other/derivative works of a different license, provided that the Apache v2 license is distributed with the library itself. Ie: we could integrate the libraries into TYPOlight and maintain all current licensing conditions, provided that we include the Apache v2 license with the PHP OpenID Library itself.

Download the attachments

--- Originally created by samjetski on January 8th, 2010, at 08:03am (ID 1375)

[ghost]

"Using this library, implementing OpenID would simply require adding some additional columns to the TYPOlight members table to store the OpenIDs associated with accounts, and extending the existing member signup pages (in both the FE and BE)."

Edit: sorry, should have been "and extending the existing member sign-up, login and management pages (in both the FE and BE)."

--- Originally created by samjetski on January 8th, 2010, at 11:29am

[ghost]

Hi

I would also like to point out facebook connect and google connect. Backend module to administer these api's would make TL a social networking capable cms.

-S

--- Originally created by werty37 on January 8th, 2010, at 02:22pm

[leofeyer]

There is an OpenID extension somewhere out there, which you should check out.

--- Originally created on January 8th, 2010, at 03:03pm

[ghost]

"I would also like to point out facebook connect and google connect."

I understand that these can be done through OAuth, and I'm not 100% certain, but I think that same PHP OpenID Library does OAuth.

"There is an OpenID extension somewhere out there, which you should check out."

Yes, but it's hackish (to log in it actually changes the user's password, then changes it back :-S), unreliable and no longer under development. To do this properly, reliably and well it needs to be integrated into the core to some degree.

Another thought I had: You could perhaps even leave the members table structure unmodified, and simply add an OpenID table which would contain openids and their corresponding username/membername. This would mean that users who already have passwords could add (or remove) an OpenID to their account (or multiple if they wished). And if they didn't wish to have a password (the typical OpenID scenario) then the password hash field in the members table could simply be left blank/null. And of course, yo probably don't even have to modify the existing login module - you can simply just add an OpenID login module (giving site admins the choice of either or both).

All of this could probably be done easily in an extension. The problem is that the core doesn't really accommodate for alternative means of initiating sessions, which is where the existing extension ran into trouble. This is why some kind of core modification is necessary.

--- Originally created by samjetski on January 9th, 2010, at 12:27am

[ghost]

Core Modification is not necessary, I have successfully been able to provide two authentication logins from a module point of view.

My method involves over-riding the FrontendUser class and using __get($var) to redirect the call of username.

--- Originally created by pbrooks on January 10th, 2010, at 05:10pm

[leofeyer]

Even if a core modification was necessary, it would not be a big deal to add a new hook or whatever it takes.

--- Originally created on January 10th, 2010, at 07:53pm

[ghost]

Even if a core modification was necessary, it would not be a big deal to add a new hook or whatever it takes.

Hi Leo, If you add a hook I'd assume it'll be generic? Ie I could advance our current custom login method over over-riding the class and use the hook?

I'll dig out the relevant code and email it to you Leo if that's ok? I can't attach it here sadly.

--- Originally created by pbrooks on January 12th, 2010, at 05:54pm

[leofeyer]

Please do not send the code via e-mail but attach it to this ticket (diff format preferred).

--- Originally created on January 12th, 2010, at 08:20pm

[ghost]

This ticket has gone stale, I'll take on the task of adding OpenID support and giving support to other authentication methods.

--- Originally created by pbrooks on August 3rd, 2010, at 07:46pm

[ghost]

I've now completed a preliminary alpha implementation of modifying the Contao core to accept other authentication schemes. This patch should NOT be used in production, a lot still needs checking.

I am submitting at this stage so that the Contao team can check through my addition of Authentication.php and changes to User.php and ModuleLogin.php .

I have included an AuthenticationUsername.php for the traditional login as well as a new AuthenticationFacebook.php , currently credentials for Facebook are hard coded in AuthenticationFacebook.php , this will change upon the next iteration to have them stored within the site root DCA. This has already been implemented, it just needs merging in.

AuthenticationOpenID.php has been included but it is still heavily in development, a lot of issues persist with the use of php-openid and I might suggest a change to LightOpenID.

--- Originally created by pbrooks on August 22nd, 2010, at 04:02pm

[ghost]

I have now produced a beta for the Authentication modifications to the core. It has been attached to the ticket, AuthenticationOpenID hasn't been added to this release because it's still being worked on. I will attach the file separately and others are welcome to help me complete it. The following auth methods are supported:

AuthenticationUsername AuthenticationEmail AuthenticationFacebook

--- Originally created by pbrooks on September 10th, 2010, at 09:59pm

[ghost]

I've converted this 'Patch' solution into a Module solution, the only remaining issue is adding custom code to User as it's a core file. Code needs adding to User since User is very much dependent on Username POST data, this ideally needs to be altered or add the ability to let other modules specify where the data comes from. OpenID is NOT implemented as of yet, will be completed soon.

--- Originally created by pbrooks on January 7th, 2011, at 03:46pm

[ghost]

Forgot to attach.

--- Originally created by pbrooks on January 7th, 2011, at 03:46pm