Feature roadmap/Single sign-on from Browse

From OLPC
< Feature roadmap
Revision as of 12:08, 9 December 2008 by Skierpage (talk | contribs) (Automated import of articles)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
Feature subcategory Is part of::Category:Activity-related work
Requesters {{#arraymap:Reuben|,|x|Requested by::x}}
Requirements Overview - The primary driver for this requirement is that the XO be able to recover its backed up files from the XS HTTP restore interafce without needing to enter a user name or serial number.
  • Must allow XOs to pass their identity to the XS so that the XS recognizes them without the need for them to login.
  • Must allow passing the identity to the XS with which the XO is registered. Should allow passing it to any XS. Should allow passing it to any Web server with the right server side code implemented.
  • Does not require passing XO identity to more than one server at a time (not taking in to consideration and "load balancing like downstream replicating of data which is transparent to the XO).
  • Does not require passing the XO identity to other XOs.
  • Must pass that info in Browse in such a way that the XS HTTP server can recognize and extract the info for use in CGI scripting.
  • Must work with the back and restore feature so an XO and only the relevant XO "automatically" see and restore their own backed up files.
  • Does not need to support passing identity via any activities aside from Browse.
  • May allow passing of XO identity to other web server or services aside from the XS but the XS is the primary must have server. If identity is passed to other non-XS server the XO identity must be encrypted and unique so that other browsers or devices can't "spoof" and appear to be the XO.
  • Must allow the user to turn off or turn on this feature. When off the XO will not pass its identity.
  • Must maintain its identity after upgrade or downgrade.

Server side requirements:

  • Must allow an override on the XS which allows it to see a new XO and associate it with a previously seen XO (covers the case where an XO breaks and the user wants to restore the data to a new XO).
  • Must allow the XS to move the identity DB and any associations (e.g. which files where back up from which XOs) to a new XS or to share it with another secure XS.
Specification
Owners {{#arraymap:Greg|,|x|Contact person::User:x}}
Priority not indicated
Helps deployability? not indicated
Target for 9.1? not indicated