[haiku-web] Re: account.haiku-os.org update
- From: "Gavin James" <gavin.james@xxxxxxxxx>
- To: haiku-web@xxxxxxxxxxxxx
- Date: Fri, 9 May 2008 10:22:26 +0100
Hi Niels,
A centralised authentication system is definitely a worthwhile goal
IMHO, but I'm not convinced our own proprietary protocol is the best
route. Take a look at http://oauth.net and in particular
http://www.hueniverse.com/hueniverse/2007/10/beginners-gui-1.html for
a scenario of how OAuth would work. I haven't looked over it
extensively (and it would definitely be worth checking out the full
spec to see what can and can't be done outside of the example
scenario), but at first glance it seems a relatively good fit for what
you describe below.
As an aside, I'm aware that I've not been around much lately, the
simple answer is that as well as having to start a new job and move
halfway across the country, I've had major problems in getting my
apartment setup with an Internet connection. Hopefully, this should be
sorted within a month (although probably no sooner), and I'll be able
to get stuck in again.
- Gavin
On Thu, May 8, 2008 at 11:48 PM, Niels Reedijk <niels.reedijk@xxxxxxxxx> wrote:
> Hi gang,
>
> I've been happily working on our centralized account implementation.
> It is not yet working, but I am happy to report that some of the major
> design decisions have been made (by me). I want to share those with
> you.
>
> 1. Account.haiku-os.org is modeled on the Google account service. So
> to say, it is aware of the services (as opposed to OpenID, which just
> authenticates everything under the sun). This restricts access to the
> authentication procedures for services that are known to the server.
>
> 2. The account service is centralized. This means that all
> authentication is done within the realm of the account service. Client
> websites will not gather usernames and passwords themselves, but
> rather redirect login requests to the account.haiku-os.org service. I
> have designed an encrypted protocol for that. This is opposed to
> having the accounts registered and maintained centrally, and then push
> the accounts to the individual databases of the client services
> (various reasons, ask me if you are interested). It is also different
> from the client services asking for the password and then
> authenticating the users against the central service themselves (by
> transferring the account details over the internet).
>
> 3. As such, both Drupal and Trac need a customized plugin to
> communicate with our centralized server. For Trac, this isn't going to
> be a major issue, Drupal I don't know yet, but I think it should be
> doable, based on the fact that Drupal already has 'custom'
> authentication plugins (ldap and openid).
>
> Anyway, I will write up a more detailed document when I have the time,
> but for now I choose to spend my time on implementing the thing. I am
> currently implementing the service in Ruby on Rails, because it allows
> me to do some rapid application development. As soon as something is
> somewhat working, I will share the source, but for now I will still be
> fleshing out the internal details.
>
> I hope I can show you more next week.
>
> Niels
> -----------------------------------------------------------------------
> haiku-web@xxxxxxxxxxxxx - Haiku Web & Developer Support Discussion List
>
>
-----------------------------------------------------------------------
haiku-web@xxxxxxxxxxxxx - Haiku Web & Developer Support Discussion List
Other related posts:
