TIP: Use Markdown or, <pre> for multi line code blocks / <code> for inline code.
These forums are read-only and for archival purposes only!
Please join our new forums at discourse.kohanaframework.org
OpenID integrated into Auth module or it's own module?
  • Hi,

    I've just finished writing an OpenID module for kohana and was going to take the time to integrate it into Auth as a driver but before I do that I was wondering whether people think that would be the best option or not?

    The choice is between making it possible to set the Auth driver to 'Openid' and then be able to use Auth to handle OpenID authentication as normal with the login, logout etc methods and the Openid classes handling things in the background or if it would make more sense for Openid to be an entirely separate module?

    The OpenID (v2.0) authentication protocol is fairly complex - I've had to write 7 main library classes for it (a few more for the new extensions) and a bunch of helpers.

    The ways it differs from the standard username + password authentication mean that OpenID is not really a perfect fit for Auth module integration.

    Firstly OpenID authentication requires that after the user submits their id they get redirected to an OpenID provider site and then returned back to a URL you specify.

    Secondly OpenID doesn't require a username and password and these args are required by the Auth driver interface.

    Thirdly it's often desirable to have OpenID authentication as an option alongside username and password authentication and I guess this would be more easily facilitated if OpenID were a separate module.

    Lastly OpenID would require an OpenID field be added to the user table or two extra db tables: 'openids' and an 'openids_users' (joining table).

    hmm, in the process of writing this post I think I've persuaded myself towards the separate module option but would still like to hear what you all think...
  • I would be inclined to think a module would be better.

    Secondly OpenID doesn't require a username and password and these args are required by the Auth driver interface. That and the fact that you say there are 7 libs +helpers.

  • I agree, it doesn't make sense to make it a driver, I wonder if it would even be possible. The purpose of Auth-Drivers is to allow different storage mechanisms within the scope of the Auth Module. It's purely about 'Am I gonna save all user/pw-data in files or using MySQL'. OpenID is not just about storage, it is a different form of Authentication: OpenID is not just a driver, it is a another module.

    That said, it is interesting to see what would be the best approach when different types of authentication are offered to the user. The Auth Module offers a logged_in() method to detect if a user is logged in. What will happen if I offer both the Auth module and the Open ID module on my website?! We need one standardized way to detect if a user has logged in.

    So, I personally think that one Auth module is best, this module should allow different Authentication methods, and should take care of all the fuzz. To the rest of the application, an Auth::logged_in() method is offered, no matter what type of Authentication the user decided upon using. This implies however a complete rewrite of the Auth Module, so that's gonna be some work :).
  • You're right Wouter - there would be some work to make OpenID just a configuration option within the Auth module to enable the developer to simply use Auth in the same manner regardless of whether it was set to be OpenID or not and I'm not sure it would be worth it either - but I'm not sure from your post if you're a +1 for integration or a +1 for keeping it in a separate module?
  • Personally, I vote for adding OpenID as a configuration option within the Auth module.

    Everything else, driver, module, seem less perfect to me.
  • atomless, I think I agree with your original conclusion: I think you should go with a separate module.
    While it would be nice to have all our security in one basket (auth), i think the flexibility offered by having OpenID be independent outweighs the advantage that would be gained by having it integrated.
    I think if one were to use both on one website, it would probably be to offer some heightened level of security, in which case IMHO it would make sense to have to query both regarding the logged-in status of a user, so no real reason to combine them.
    Plus it's easier. I always go for easier. :)
  • Why not provide both a module, and an Auth driver in the module? That way, the developer could choose which way to use it.

  • +1 Shadowhand's solution
  • agreed - I'll go for the easy (separate module) option for now and look at adding Openid driver functionality to Auth later.

    btw, while looking into the Auth module and how to integrate I've made some changes to it as well as making sure it all works right out of the box with ORM2 - patch uploaded to the tickets here. -edit : updated to work with revision 3253
  • 2c:

    Check out this module: OpenID @ googlecode. If you've got some time, i suppose it's better to finish this one than reinvent your own.
  • Thanks xobb,

    I did check the modules repository before starting work on a bespoke kohana openid module.

    The existing openid module in the googlecode repository wraps the janrain library in a vendor directory. And the thing with the janrain library, apart from being horribly obtuse and messy in the way it's coded (making it very tricky to ever delve in and fix a bug or to change anything for that matter), also doubles up on some of the existing kohana functionality like file storage and session handling.

    I really needed a bullet proof openid solution for a couple of projects I'm working on. And I needed it to be written as cleanly as possible so I can take it forward as the OpenID specs evolve, easily improve it and fix bugs over time, and also perhaps add some intergration with OAuth later on.

    Anyways, I'm just trying to finish it up and I'll upload it.
  • Do you who to get in contact with to upload a module?
  • No, to be honest I'm never sure what the prefered method of contribution is - should I find out how to upload it to the google code module repository - or should I just add a ticket for it in the kohana trac with a zip of the files attached?
  • Submit a .zip as a Feature Request ticket.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion