[wp-hackers] Single sign-on with Wordpress & Mediawiki

Travis Snoozy ai2097 at users.sourceforge.net
Mon Oct 29 00:26:34 GMT 2007


On Sun, 28 Oct 2007 18:30:03 -0500, Jacob <wordpress at santosj.name>
wrote:

> > That's another issue altogether. OpenID is for a larger problem
> > space 
<snip>
> OpenID isn't a solution for username/password combinations.
<snip>

What I'm getting at is that OpenID, specifically, is irrelevant to this
conversation. It's just another way to do auth -- it doesn't matter
*how* it gets done, just that every service (wiki, forum, bug tracker,
etc.) uses the same method.

<snip>
> > Just abstract the auth logic out into a couple function calls, and
> > voila -- you have a unified (single-site) auth architecture.
<snip>
> This in theory makes sense, but no one is going to do it. Good luck
> anyway.
>
> The solution is not to revert to a standard where everyone uses the
> same library/function calls, but offers API, like WordPress does for
> cross web app authentication. Several major applications already do
> this by way of creating specific cookies or calling a web application
> specific function.

We're pretty much in violent agreement here ;). It's just a matter of
"how", and there are several reasons why a standard approach is better
vs. each product rolling their own API.

The "override my auth system" approach is useful, and I *vastly*
prefer it to having a hard-coded auth system in a product. However, it
places the burden on people who create single sign on systems to also
create plugins for each and every one of these products. By
standardizing on an API and conventions, it would allow people to write
an auth system once, and have it work *without* needing this extra
layer of product-to-product glue code (and the potential security flaws
that could be introduced by subtle semantic differences between
products). Likewise, for products without native support for the
standard, but with a pluggable interface, it would still allow an
integration plugin to be written once for each product, and work with
*all* auth providers conforming to the standard. People can work on
making one chunk of code really solid, instead of having a million
different chunks of code that do almost-but-not-quite the same thing.

> The problem is that web applications can know or don't care which 
> primary web application the user chooses.
<snip>

Yep. Shouldn't know or care. Authentication is authentication. I'm
saying that there should be no "primary" web application -- all the
auth logic should be centralized behind a common API so that logging in
in one place is *exactly the same* as logging in somewhere else
(within a single site).


-- 
Travis 

In Series maintainer
Random coder & quality guy
<http://remstate.com/>


More information about the wp-hackers mailing list