views:

430

answers:

1

I currently have several websites which live on separate domains:

www.app1.com

www.app2.com

www.app3.com

Each has its own authentication mechanism - some query active directory via web service, others have their own user database.

The goal is to have Single Sign On through some technology or product that doesn't require users to re-enter passwords when they visit pages across domains.

Question: Reviewing SAML, it appears that a cross-domain SSO solution will always require a third party Identity Provider to authenticate users, e.g.:

www.my-master-login.com

Is this true?

If so, does it follow that each existing website will need to be updated so that its authentication is handled by the third-party site?

+3  A: 

I think it depends what you mean by third-party. I would look at how Wikimedia does it. They don't currently use OpenID or anything like that. Instead, their CentralAuth service (see also Help:Unified login just provides cookies for all the major sites (wikipedia.org, wiktionary.org, wikinews.org) when you log on to any given site. There is no master site so it doesn't matter which site you log on to first. The cookies are embedded in images on the logon page.

But yes, each website will need to be updated somehow.

Matthew Flaschen
Great... so in this solution, each wiki site (wikipedia, wikinews, etc) needs to know about the other sites that it needs to add embedded images for... So, if a new site is added to the wiki ecosystem, it would need to be included as well - right?Do you know if a web service is used internally to retrieve this list of sites or is it hard-coded into the login pages?
frankadelic
I think it's basically hard-coded in Wikimedia's production code. But since the list is set by a user-specified function (http://www.mediawiki.org/wiki/Extension:CentralAuth/CentralAuthWikiList), you could fairly easily make a function that consults the web service of your choice.
Matthew Flaschen