Re: XO identity shared via Browse
Hi Luke, If you're interested in Sugar on XO, I believe that Tomeu et al want you on devel... Anyway I'll try to copy you on this thread. It would be useful to have a generic solution which works with many types of server software and many network configurations. However, this is where I need to separate must have from nice to have. We must allow the XS to know which XO it is talking to when there is an XS and XO on the same protected network (AKA XS doing NAT and acting as gateway to Internet). I can't wait for the nice to have piece if there is no agreement on technical implementation. I want the must have piece by March, no matter what. I'll take both too but I wont settle for none of the above :-) Thanks, Greg S Luke Faraone wrote: On Thu, Dec 4, 2008 at 19:17, Greg Smith [EMAIL PROTECTED] wrote: I'm copying in Devel and will drop the sugar list on further replies (hope that's the right netiquette in this case...). (note: I'm not on devel, so please keep me CC'd) security) who are the principals? what are their goals? what attacks concern us? GS - In general I don't want any other devices to be able to appear to be the XO. We can assume that the XS - XO is a secure network not visible to the outside workd (whether that is true in practice is another story). So I moved the encryption and stringent security requirements to the optional case where the XO is talking to a non-XS server. I'd rather not make that assumption. Some schools may not have a _local_ school server (even dispite our best wishes) or a student may want to access the server from a non-local connection. The XS, IMHO, should support the road warrior use case (at least for post-registration) -lf ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO identity shared via Browse
On Fri, Dec 5, 2008 at 5:46 PM, Greg Smith [EMAIL PROTECTED] wrote: Hi Luke, If you're interested in Sugar on XO, I believe that Tomeu et al want you on devel... Anyway I'll try to copy you on this thread. Well, as long as there's a chance what is discussed here will interest Sugar on other platforms, I think you are welcome to cc sugar-devel. I personally don't see any problem with cc'ing both lists in case of doubt, olpc and sugar are very closely related as of today. Tomeu It would be useful to have a generic solution which works with many types of server software and many network configurations. However, this is where I need to separate must have from nice to have. We must allow the XS to know which XO it is talking to when there is an XS and XO on the same protected network (AKA XS doing NAT and acting as gateway to Internet). I can't wait for the nice to have piece if there is no agreement on technical implementation. I want the must have piece by March, no matter what. I'll take both too but I wont settle for none of the above :-) Thanks, Greg S Luke Faraone wrote: On Thu, Dec 4, 2008 at 19:17, Greg Smith [EMAIL PROTECTED] wrote: I'm copying in Devel and will drop the sugar list on further replies (hope that's the right netiquette in this case...). (note: I'm not on devel, so please keep me CC'd) security) who are the principals? what are their goals? what attacks concern us? GS - In general I don't want any other devices to be able to appear to be the XO. We can assume that the XS - XO is a secure network not visible to the outside workd (whether that is true in practice is another story). So I moved the encryption and stringent security requirements to the optional case where the XO is talking to a non-XS server. I'd rather not make that assumption. Some schools may not have a _local_ school server (even dispite our best wishes) or a student may want to access the server from a non-local connection. The XS, IMHO, should support the road warrior use case (at least for post-registration) -lf ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] XO identity shared via Browse
Hi All, I'm copying in Devel and will drop the sugar list on further replies (hope that's the right netiquette in this case...). Of all the e-mails I have sent this week I never would have guess that this one would generate the most responses! Maybe it was the use of the term SSO :( I updated the requirements to address Michael's comments below. The one which did not engender a requirement update are noted here: what software, on the XO, should be responsible for proving identity? GS - It says Browse and I mean only Browse (that's why I sent it to the sugar list initially) if Browse, how does Browse talk to the registration code? if Browse, what about Gmail, Help, WikiBrowse, ... GS - Not a requirement either way on registration code. Not a requirement to work with Gmail, Help or Wikibrowse, but I left in other server (Gmail case?) as nice to have. when should we make use of an ability to prove user identity? GS - Not sure what this is asking. Its purpose is to make it easier to work with XS. The identity should be tied to the XO hardware (except as noted below). I want the XS to know that its talking to the same XO as before without the user needing to enter anything. security) who are the principals? what are their goals? what attacks concern us? GS - In general I don't want any other devices to be able to appear to be the XO. We can assume that the XS - XO is a secure network not visible to the outside workd (whether that is true in practice is another story). So I moved the encryption and stringent security requirements to the optional case where the XO is talking to a non-XS server. users) what do we do if something looks wrong? fail silently? log an error somewhere? fail loudly? are there any user overrides? GS - Make sure it never fails! Just kidding. Give me some concrete examples for how it might fail and I'l think about it some more. can I turn this off? GS - Good suggestion. Added. can I have multiple identities? can I share my identity with someone else? GS - No for both. The XO is the indentity. what happens if the user loses their laptop and gets a new one? what happens if the server breaks and a new one is installed? what happens if I move from an old school to a new one? what happens when the XO's software is upgraded? downgraded? GS - I added two server side requirements to cover this. In general, I assume the XS is secure and that any identity data can be passed securely from one XS to another. HTHs. Good questions and let me know if the requirements are still not clear. BTW This came up because the current XS restore interafce requires that you type in the serial number of the XO to find its backed up files. There was also a request on the server list to make the backup and restore secure (hidden from devices other than the backed up XO). That is the must have requirement. The use of password less identity outside the secure environment of the school is nice but not critical. Just have the kids log in once then use cookies or HTTPS or OpenID for that, I'm not partial to the technology and if there's no consensus we can live without it. I'm OK with the debate but if we release 9.1.0 without making it easy to get your files off the XS and to automaticaly associate with the right Moodle identity, then we will miss an important user valuable feature. Thanks, Greg S Michael Stone wrote: On Tue, Dec 02, 2008 at 03:56:06PM -0500, Greg Smith wrote: We're mostly thinking of the school server as the server side but a more generic solution may be acceptable. I'm relatively comfortable with our vague identity plans for the XS but I'd like to know more about your idea for a more generic solution before going further in that direction. That's one example. I would also like any Web server to be able to extract the XO identity and use it in CGI (e.g. PHP) for processing. What could possibly go wrong? -- anonymous. I put a stub of a requirement for it on our roadmap here: http://wiki.laptop.org/go/Feature_roadmap#Single_Sign_on_from_Browse This seems decent so far. Do you have any ideas or designs for how we can achieve that? We discussed it at SugarCamp. The essential idea from that discussion was to have the XO and the XS exchange certs at registration time so that they can later prove their identities to one another on demand. The tricky bits involve scope, security, users, and maintenance: scope) what are we proving identity to? e.g.: one single XS, ever. one single XS, whichever we're currently registered with several servers at once other XOs what software, on the XO, should be responsible for proving identity? if Browse, how does Browse talk to the registration code? if Browse, what about Gmail, Help, WikiBrowse, ... if something else, how does the something else talk to
Re: [sugar] XO identity shared via Browse
On Thu, Dec 4, 2008 at 19:17, Greg Smith [EMAIL PROTECTED] wrote: I'm copying in Devel and will drop the sugar list on further replies (hope that's the right netiquette in this case...). (note: I'm not on devel, so please keep me CC'd) security) who are the principals? what are their goals? what attacks concern us? GS - In general I don't want any other devices to be able to appear to be the XO. We can assume that the XS - XO is a secure network not visible to the outside workd (whether that is true in practice is another story). So I moved the encryption and stringent security requirements to the optional case where the XO is talking to a non-XS server. I'd rather not make that assumption. Some schools may not have a _local_ school server (even dispite our best wishes) or a student may want to access the server from a non-local connection. The XS, IMHO, should support the road warrior use case (at least for post-registration) -lf ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] [sugar] XO identity shared via Browse
Hi, We are looking at the same problem. We would like the students to be automatically logged in to their Moodle courses. The approach I am looking at now is to have a Python script run at boot which creates a cookie with the nickname, serial number , and colors (in case there is more than one XO with the same nickname). Greasemonkey would then read the cookie and submit the username and password on the login page (which would be configured as the first page seen). I hope to have time to test it in the next few days. Tony Talking with Martin L recently he mentioned that you have some ideas on how the XO can communicate its identity (e.g. serial # and maybe user name) with a web server. We're mostly thinking of the school server as the server side but a more generic solution may be acceptable. The main idea is to eliminate the need for students to ever type in a user name and password. e.g. they should be able to just hit the Backup and Restore URL and see their files without having to login or find their serial number in a list. That's one example. I would also like any Web server to be able to extract the XO identity and use it in CGI (e.g. PHP) for processing. It should also be encrypted so that the XO cannot be spoofed. e.g. only the XO which backed up and can see or restore its own files (possibly with an admin override). I put a stub of a requirement for it on our roadmap here: http://wiki.laptop.org/go/Feature_roadmap#Single_Sign_on_from_Browse Do you have any ideas or designs for how we can achieve that? Comments and questions welcome. Thanks, Greg S ___ Sugar mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/sugar ___ Sugar-devel mailing list [EMAIL PROTECTED] http://lists.sugarlabs.org/listinfo/sugar-devel . ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] XO identity shared via Browse
Tomeu Vizoso wrote: Second, we may need to think a bit about how we are going to resource this task. Simon is the Browse maintainer and has a good knowledge of its internals, though Marco and me have hacked occasionally on it. AFAIK, none of us have a good knowledge of security issues and use to ask Michael for advice. And the third knowledge area involved is the school server, with Martin on the wheel. It looks like currently different custom solutions are being tried but nothing has been decided that is a Standard. Once we agree on that, stakeholders for it perhaps should own it and coordinate on it instead of each reinventing the wheel (or we making up some custom magic instead of a good standard). I know I'm a stakeholder for this, but can't lead it, I'd like to help as much as I can. So I propose that server and security experts discuss the different possibilities first and then ask the sugar people about how best to implement the client side of this. Mozilla gives us lots of hooks for altering the conversation between the browser and the server, so we have a good deal of flexibility there that we can take advantage of. Yes, one thing though: As Adam correctly pointed out to me, security is also about Usability. I'm not convinced laptop=user is a good policy and in our general educational mantra of not dumbing down the real world, my contention is that ONE user/pass combination is all a kid needs (if we use OpenID). Small kids are perfectly capable of understanding this concept (40% of kids in Uy already use GMail, btw that means they already have one openid - I'm suggesting the school should provide identity for its students and its teachers and NOT Google). So I'm cc'ing to [EMAIL PROTECTED] and [EMAIL PROTECTED] where OLPC and other Sugar deployers (I'm thinking specially on Brendan and Caroline) can discuss the different alternatives. Please lets not invent some magic voodoo way that only we can use to auth a laptop. We are solving one little problem by ignoring one much larger one. There is nothing to gain by saving kids from one password and forcing them to get new accounts for everything else. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] XO identity shared via Browse
Oh, also, I'd like to point to Gracie, http://trac.whitetree.org/gracie/ It is what looks to be quite a clean and lean python(!) OpenID identity provider meant to be used locally or on a server and authenticate you against your PAM (that is your system username/password). If you are already logged into your system, your system can be your openID provider, isnt it beautiful? It would be quite trivial to modify this to provide some proof of being the laptop (a certificate was mentioned?) or bug the user to confirm (and check for prior confirmations). If we have One Domain Per Laptop then this would suffice. Otherwise some DNS cleverness at the server side could be in order. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
