canmove, Confirmed users
7,088
edits
Single Sign On: Difference between revisions
no edit summary
mNo edit summary |
No edit summary |
||
| (5 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
Mozilla has over 100 web properties. A reoccurring idea in the Mozilla community is to implement Single Sign-On (SSO). | Mozilla has [http://www.mozilla.org/community/directory.html over 100 web properties]. A reoccurring idea in the Mozilla community is to implement Single Sign-On (SSO). | ||
This has been discussed many times off and on over the last few years. The [[Webdev]] team is leading a Web based SSO solution, which will be rolled out onto [[MDN]]. | This has been discussed many times off and on over the last few years. The [[Webdev]] team is leading a Web based SSO solution, which will be rolled out onto [[MDN]]. | ||
| Line 7: | Line 7: | ||
== Technical Details == | == Technical Details == | ||
* The [https://github.com/mozilla/secret-squirrel Secret Squirrel] Project is a [http://en.wikipedia.org/wiki/Central_Authentication_Service CAS] 2.0 based SSO server | * The [https://github.com/mozilla/secret-squirrel Secret Squirrel] Project is a [http://en.wikipedia.org/wiki/Central_Authentication_Service CAS] 2.0 based SSO server | ||
* The [https://github.com/ozten/mod_auth_cas mod_auth_cas] Project is a CAS 2.0 based SSO client | |||
* New User Credentials (not bootstrapped from AMO, Firefox Sync, or any other source) | * New User Credentials (not bootstrapped from AMO, Firefox Sync, or any other source) | ||
* MDN is the first target app | * MDN is the first target app | ||
| Line 17: | Line 18: | ||
Reasoning: The SSO webapp will have a user page where you can see what apps you've integrated sign-on for. Client webapps still need to define and build out their profile pages. Some user metadata can be gleaned from the SSO server, but updating, storing extra metadata, etc is TBD and probably belongs in a different web service. | Reasoning: The SSO webapp will have a user page where you can see what apps you've integrated sign-on for. Client webapps still need to define and build out their profile pages. Some user metadata can be gleaned from the SSO server, but updating, storing extra metadata, etc is TBD and probably belongs in a different web service. | ||
* '''Q: Will SSO handle authorization''' | * '''Q: Will SSO handle authorization?''' | ||
* A: No, SSO is for authentication, each client application will implement Authorization | * A: No, SSO is for authentication, each client application will implement Authorization | ||
* '''Q: Why not just use OpenID?''' | |||
* A: OpenID alone prevents us from implementing such features as global logout and other future features that require a central authentication entity. However, we might at some point allow you to log into *SSO* using your OpenID. | |||
OpenID is an awesome solution for completely open federation. CAS is a good solution for a coordinated cluster of websites under one umbrella. | |||
* '''Q: Why not just use LDAP?''' | |||
* A: We wanted a simple solution for authentication which can be made available to the community. There are some operational concerns around running a public LDAP server. With CAS, we can whitelist a community app and it can be an un-trusted, but still be a first class user of SSO. LDAP can provide not only authentication, but also authorization and arbitrary attributes (profile). This confuses the purpose of SSO, which currently is *only* authentication. | |||
== Related == | == Related == | ||
* [[Mozilla_Contributor_Directory]] | |||
* [[MozillaID]] | * [[MozillaID]] | ||