Auth systems/OAuth/IRC log 2013-04-04

Apr 05 12:04:35 <csteipp> yay, all here...
Apr 05 12:05:20 <csteipp> Cool. So to start, Tim were you able to look at the design docs at all?
Apr 05 12:05:33 <TimStarling> I did look at them
Apr 05 12:06:01 <csteipp> Does that seem like the right direction so far, for the central auth pieces?
Apr 05 12:06:24 <TimStarling> yes, I think so
Apr 05 12:06:35 <TimStarling> is there any way to support non-CORS clients?
Apr 05 12:07:05 <csteipp> I think we could do a bunch of redirects to do it
Apr 05 12:07:19 <TimStarling> can the redirects be done in an iframe?
Apr 05 12:07:40 <anomie> What sort of non-CORS clients are we talking about?
Apr 05 12:07:47 <csteipp> Not unless they already have a cookie
Apr 05 12:08:01 <csteipp> So for the local wiki logging in, we could do that
Apr 05 12:08:10 <csteipp> But not for setting the central domain's cookie
Apr 05 12:08:30 <TimStarling> according to Wikipedia, IE 8 and 9 have "partial support"
Apr 05 12:08:31 <csteipp> But for that, it would be a redirect there, and a click to redirect back.
Apr 05 12:09:20 <csteipp> Actually, sorry. For setting the central cookie, I think we don't need CORS. It's just the check.
Apr 05 12:09:42 <csteipp> With the check, yeah, we could do an iframe. I need to update that design just a little bit
Apr 05 12:11:04 <TimStarling> according to the February squid stats, we have IE 9 = 8.45%, IE 8 = 6.21%, IE 7 = 2%
Apr 05 12:11:51 <csteipp> I'll make sure to test them
Apr 05 12:11:51 <TimStarling> so IE 8 & 9 support is probably essential
Apr 05 12:11:59 <csteipp> agree
Apr 05 12:13:18 <TimStarling> so you could have an iframe send a request to the central domain, and then the central domain could redirect back to the local wiki and set a local cookie, right?
Apr 05 12:13:57 <csteipp> If there's already a local cookie, it could
Apr 05 12:14:14 <csteipp> If there isn't one.. I'd have to test it
Apr 05 12:14:55 <csteipp> It should work since it's from the parent's domain'
Apr 05 12:15:39 <csteipp> Actually, if we use javascript to talk to the main domain, and then create the iframe, that would work
Apr 05 12:15:59 <TimStarling> when you set the central cookie, the whole window needs to visit the central domain, right?
Apr 05 12:16:06 <csteipp> Yes
Apr 05 12:16:20 <TimStarling> I'm not sure what this restriction is going to achieve
Apr 05 12:16:44 <TimStarling> we should just wait and see what solution the analytics companies use to track users across sites and then copy them ;)
Apr 05 12:17:27 <csteipp> Sadly, this was an issue that google hadn't figured out as of last year...
Apr 05 12:17:31 <James_F> TimStarling: :-)
Apr 05 12:17:40 <csteipp> But I may actually see if they have by now..
Apr 05 12:17:43 <TimStarling> I'm sure they're busy developing workarounds, it's not like they're going to say "oh well, browser security policy changed, I guess you all have no jobs anymore, see you later"
Apr 05 12:17:56 <Aaron|home> heh
Apr 05 12:17:59 <anomie> Too bad we can't just show the login form from the central domain instead of redirecting back and forth.
Apr 05 12:18:31 <James_F> TimStarling: Unfortunately all the friends I have in Google's ads departments are too scared to talk about their job.
Apr 05 12:18:35 <csteipp> anomie: I was hoping to do that too. But non-global accounts would be really difficult then
Apr 05 12:18:50 <James_F> csteipp: We could live without supporting local accounts...
Apr 05 12:19:07 <James_F> csteipp: Depends how quickly we can get them unified.
Apr 05 12:20:03 <csteipp> James_F: that's true, but I really don't see peter finishing until June at the earliest
Apr 05 12:20:22 <James_F> csteipp: If it /needs/ to be finished sooner, it will be.
Apr 05 12:20:32 <TimStarling> so the plan is to do the next version of CentralAuth first, and then OAuth afterwards?
Apr 05 12:20:33 <James_F> csteipp: We'll break some fingers in the process, but so be it.
Apr 05 12:20:45 <csteipp> TimStarling: yeah
Apr 05 12:21:31 <TimStarling> because CentralAuth is more urgent? or because OAuth needs some new feature from CentralAuth?
Apr 05 12:22:11 <csteipp> I think we're going to need the central domain for oauth
Apr 05 12:22:32 <csteipp> and I'd like to make sure we don't code up oauth, and then change how centralauth works
Apr 05 12:22:54 <csteipp> So not a hard dependancy, but it seems like it would make life easier
Apr 05 12:23:33 <TimStarling> the OAuth UI would be on the central domain? or some part of the API? or both?
Apr 05 12:24:31 <csteipp> Originally I was thinking all of the UI would be there
Apr 05 12:24:46 <csteipp> The API I think is going to be a lot easier to keep local
Apr 05 12:25:14 <csteipp> But the UI could live on a local page like Special:CentralAuth
Apr 05 12:26:28 * csteipp trying to find in notes what we said we needed it for
Apr 05 12:27:31 <csteipp> We could probably get away without it
Apr 05 12:27:38 <TimStarling> I think if the UI was local, then that would give a more consistent user experience
Apr 05 12:27:51 <TimStarling> or at least, it would be easier to provide a consistent user experience
Apr 05 12:28:04 <csteipp> agree
Apr 05 12:28:11 <TimStarling> i.e. easier to keep the same skin with the same navigation links
Apr 05 12:28:16 <anomie> I think we wanted the central domain for OpenID, and for being able to disable user scripting.
Apr 05 12:28:59 <TimStarling> you can disable user scripting locally, we do it for Special:Userlogin
Apr 05 12:31:00 <csteipp> Yeah we can. And if we need to support content on the central domain, we'll have to do that
Apr 05 12:31:49 <csteipp> I'd rather keep the attack surface as small as possible though for the central domain. So an xss in an extension can grab everyone's sessions.
Apr 05 12:32:14 <csteipp> And openid should be on its own domain too
Apr 05 12:32:39 <csteipp> But yeah, for oauth, not a hard dependancy.
Apr 05 12:33:00 <TimStarling> ok
Apr 05 12:33:30 <TimStarling> anything else you wanted to talk about?
Apr 05 12:34:08 <csteipp> That was the main stuff. Tim, if you want to add comments to any of the designs on wiki or in the google doc, that would be great.
Apr 05 12:34:22 <csteipp> Brad submitted a patch for the token handling I think?
Apr 05 12:34:28 <anomie> https://gerrit.wikimedia.org/r/#/c/57662/
Apr 05 12:34:34 <csteipp> Anyone want to review that?
Apr 05 12:35:10 <TimStarling> I'll add it to my list
Apr 05 12:35:26 <csteipp> Oh, Tim, I think the result from your looking into the libraries is that you think we should write our own, did I get that right?
Apr 05 12:35:46 <csteipp> Or did you think we could start with one of them in particular?
Apr 05 12:36:33 <TimStarling> for signature verification there is that 50 lines of code I pastebinned
Apr 05 12:37:24 <TimStarling> I'm not sure what else is needed that could be split out to a library, as opposed to whatever extension or core module we're already developing
Apr 05 12:37:59 <TimStarling> so I'm not exactly saying we should write our own library
Apr 05 12:38:27 <TimStarling> I'm saying that my research seems to suggest that we don't need a library
Apr 05 12:38:38 <csteipp> Ok, that makes sense
Apr 05 12:38:42 <TimStarling> the extension should just be slightly larger
Apr 05 12:39:14 <Aaron|home> sounds reasonable
Apr 05 12:39:20 <csteipp> Yeah. We probably want to use the signature bit you coppied, and some of the parameter formatting code from somewhere.
Apr 05 12:39:37 <csteipp> The rest should be interacting with the db and ui
Apr 05 12:39:49 <TimStarling> which we'd need to write anyway
Apr 05 12:42:53 <csteipp> Alright, and on the design of oauth
Apr 05 12:43:04 <csteipp> Did anyone have thoughts on the question I emailed out a while back..
Apr 05 12:43:47 <anomie> Which question was that?
Apr 05 12:43:47 <csteipp> "For OAuth, I had originally though it would be local to each wiki (so that other mediawiki users could install it as well), but James brought up in the meeting that a user probably doesn't want to approvean application on 900 wikis. Should we make this local, with hooks for CentralAuth to handle/inject applications? Or make it rely on CentralAuth for now? Or make it local wiki only, and users will have to approve them all if they want to use a
Apr 05 12:44:58 <TimStarling> client on all wikis?
Apr 05 12:45:09 <csteipp> A "Client" application
Apr 05 12:45:29 <TimStarling> yeah, your line was truncated, I was just finishing your sentence for you :)
Apr 05 12:45:30 <csteipp> (in the OAuth spec meaning)... an app/bot/whatever
Apr 05 12:45:37 <csteipp> Ah, sorry :)
Apr 05 12:47:09 <TimStarling> I think it would be good for the non-WMF community if we provided an OAuth extension that worked without CentralAuth
Apr 05 12:47:34 <csteipp> agree (again)
Apr 05 12:48:06 <anomie> Would it be good enough to somehow do local versus global? So they would have to do 899 authorizations if they want to exclude 1, but just 1 auth if they want to do all 900.
Apr 05 12:48:49 <TimStarling> there could be a wiki ID field in the permissions table
Apr 05 12:49:01 <TimStarling> maybe "*" or something to apply to all wikis
Apr 05 12:49:44 <TimStarling> then the provider code would either read from the central table or the local table, depending on how it is configured
Apr 05 12:50:37 <TimStarling> you would need a different foreign key link depending on whether it is local or global, but otherwise the code that reads that table would be the same
Apr 05 12:52:02 <csteipp> TimStarling: So you're thinking have the permission global, but the rest of the db local?
Apr 05 12:53:13 <TimStarling> would there be any other tables created by this extension?
Apr 05 12:53:33 <TimStarling> a log table maybe?
Apr 05 12:54:04 <TimStarling> maybe the log table would also be global
Apr 05 12:54:09 <csteipp> The apps / client registrations
Apr 05 12:54:21 <TimStarling> if you authorize globally then it makes sense to audit globally
Apr 05 12:54:22 <csteipp> Yeah, Aaron|home was already thinking have that.
Apr 05 12:54:55 <csteipp> So yeah, logging, user permissions, and app registrations... all global
Apr 05 12:55:00 <TimStarling> yeah
Apr 05 12:55:28 <csteipp> That works for me
Apr 05 12:56:06 <TimStarling> you could use a class hierarchy to factor out the processing that is common to the local (non-WMF) case and the global case
Apr 05 12:56:45 <TimStarling> maybe just two classes: a base store class which is local, and a derived class which is CentralAuth-aware
Apr 05 12:56:53 <csteipp> Right. I don't think there should be too much specific to the global case, but we may hit it.
Apr 05 12:57:07 <TimStarling> 6 classes if you're Aaron
Apr 05 12:57:14 <TimStarling> 18 if you're Jeroen
Apr 05 12:57:20 <TimStarling> see how you go ;)
Apr 05 12:57:37 <csteipp> I would be disappointed if Jeroen didn't make it 45
Apr 05 12:58:01 <anomie> Is that 45 including the dependency on his other extensions?