From the start of the OAuth idea I've been thinking we should handle the code in an abstract way.
ie: Applications and Authorizations should be something MediaWiki implements internally in an abstract way. And then we write an OAuth extension that extends this and lets you authorize OAuth 2 clients. Things like mass-reverts by application, authorization revocation, and displaying what application was responsible for an edit would be handled from within MediaWiki abstractly instead of being OAuth specific.
-- Skip for TL;DR version -- Originally I had some ideas like implementing some custom auth system for other wiki. Implementing OAuth 1.0 in addition to OAuth 2 (at the time it appeared signatures had disappeared and OAuth 2 was worse than OAuth 1 in some cases). And supporting something along the lines of Google's application passwords.
I'm not focused on that right now. But I still think it would be a good idea to do. We don't know what'll happen in the future. Someone could write an OAuth 3 that is also not backwards compatible and we want to implement. Or someone could come up with a different standard that does things in a more secure way or supports discovery in a very well thought out way. So doing things abstractly will let us add those as things go along without any trouble. Additionally doing this abstractly allows us to test just small components of the system in an isolated way without needing a whole OAuth stack. -- / continue reading from here --
I had an interesting thought when I was thinking about how we'd do this abstractly.
- I started thinking that every user instance should have some sort of ->getApplication()/->getAuthorization() connection. And this would be used when noting what was responsible for various edits/logs/etc... - To make things easy on code I thought that ->getApplication() should always return an Application instance so you don't have to null test it. Under that idea MediaWiki itself would have a dummy Application which would be tied to every standard edit. The database would probably even reflect this.
After this I started thinking of separating things a bit more. - By default every blandly created User instance would be tied to an "Unknown" application. - While when a user instance is setup using session data we assign the "Internal" application to it. - As a result of this all dummy edits made through internal code would end up associated with an "Unknown" application instead of the "Internal" one. In other words, we'd finally have a formal way to find system made edits like the initial Main Page edit populated by the installer. That would be an "Unknown" application. The same would go for various extensions that made dummy edits. - To top all this off we could potentially also make a special built-in "Import" application. This would result in all edits made by importing edits from another wiki being nicely annotated in the UI with information saying they were imported rather than actually made on the wiki by said person.
What does everyone think of this idea?
I wanted to get in a couple responses to Daniel, as well as try to make sure the conversation doesn't die. Obviously having a lead person in the OAuth2 process leave may effect what we want to implement. Or may spawn a new standard in the near future. But I hope we can still move ahead with laying the foundation for allowing other entities and applications to work with mediawiki and WMF sites, and specifically make sure that third parties can interact with WMF sites in a way that is more secure than currently possible.
From the start of the OAuth idea I've been thinking we should handle the code in an abstract way.
I definitely agree with you there, although deciding which functionality is common is obviously the tricky part. Where we draw that line can greatly effect the effort that is required to implement, so I want to make sure we draw it appropriately.
I think recognizing that a user's session may have a different set of permissions from the permissions that their group membership gives them definitely falls into that category. Keeping track of the concept of external entities (whether it's a university serving SAML, or an app developer using oauth) may also fall into this category. Thoughts from other developers?
- I started thinking that every user instance should have some sort of
->getApplication()/->getAuthorization() connection. And this would be used when noting what was responsible for various edits/logs/etc...
I think I understand what your saying about that, and that's one way it could be done. I had also given some thought to extending the user, so that an OAuth user would have limited permissions, and a SAML user may not even exist in the data store.... etc. But it would be good to hear from other developers if they have thoughts on it?
- To top all this off we could potentially also make a special built-in
"Import" application. This would result in all edits made by importing edits from another wiki being nicely annotated in the UI with information saying they were imported rather than actually made on the wiki by said person.
I hadn't heard other people mention tracking edits by Import or the Installer, but if there's support for that type of thing, then I agree, this might be a good place to include it.
What does everyone think of this idea?
Hopefully the lack of response was due to everyone recovering from wikimania instead of lack of enthusiasm for OAuth!
On Fri, 27 Jul 2012 10:59:30 -0700, Chris Steipp csteipp@wikimedia.org wrote:
I wanted to get in a couple responses to Daniel, as well as try to make sure the conversation doesn't die. Obviously having a lead person in the OAuth2 process leave may effect what we want to implement. Or may spawn a new standard in the near future. But I hope we can still move ahead with laying the foundation for allowing other entities and applications to work with mediawiki and WMF sites, and specifically make sure that third parties can interact with WMF sites in a way that is more secure than currently possible.
From the start of the OAuth idea I've been thinking we should handle the code in an abstract way.
I definitely agree with you there, although deciding which functionality is common is obviously the tricky part. Where we draw that line can greatly effect the effort that is required to implement, so I want to make sure we draw it appropriately.
I think recognizing that a user's session may have a different set of permissions from the permissions that their group membership gives them definitely falls into that category. Keeping track of the concept of external entities (whether it's a university serving SAML, or an app developer using oauth) may also fall into this category. Thoughts from other developers?
Yeah, I think my random OAuth brainstorming reflects this too: https://www.mediawiki.org/wiki/User:Dantman/OAuth/Brainstorm
Authorizations have an interface to return the rights that the user has in the authorization. While this interface is present in the code it doesn't show up anywhere inside the generic part of the database for authorizations. Instead it's handled at the plugin implementation level. In this case auth codes, access tokens, and refresh tokens have scope information and that is used by the OAuthAuthorization to return rights information.
- I started thinking that every user instance should have some sort of
->getApplication()/->getAuthorization() connection. And this would be used when noting what was responsible for various edits/logs/etc...
I think I understand what your saying about that, and that's one way it could be done. I had also given some thought to extending the user, so that an OAuth user would have limited permissions, and a SAML user may not even exist in the data store.... etc. But it would be good to hear from other developers if they have thoughts on it?
Separate user rows for OAuth?
- To top all this off we could potentially also make a special built-in
"Import" application. This would result in all edits made by importing edits from another wiki being nicely annotated in the UI with information saying they were imported rather than actually made on the wiki by said person.
I hadn't heard other people mention tracking edits by Import or the Installer, but if there's support for that type of thing, then I agree, this might be a good place to include it.
What does everyone think of this idea?
Hopefully the lack of response was due to everyone recovering from wikimania instead of lack of enthusiasm for OAuth!
On Fri, Jul 27, 2012 at 3:05 PM, Daniel Friesen lists@nadir-seen-fire.comwrote:
On Fri, 27 Jul 2012 10:59:30 -0700, Chris Steipp csteipp@wikimedia.org wrote:
I think I understand what your saying about that, and that's one way it could be done. I had also given some thought to extending the user, so that an OAuth user would have limited permissions, and a SAML user may not even exist in the data store.... etc. But it would be good to hear from other developers if they have thoughts on it?
Separate user rows for OAuth?
OAuth 2.0 has a "scope" field to let the client request an auth token with the scope of the permissions it is requesting, which is a space delimited list of scope strings, to which the server can respond with an auth token that includes that scope list, a different scope list, or an error.[1]
I think creation of an OAuth token should result in the creation of a MediaWiki session, and that scope should be added to the session data. In our initial implementation, I think each of scope strings should correspond to MediaWiki permissions (i.e. mCoreRights in User.php). However, we should think ahead to the day when we might want to have something more fine grained than that.
Rob
[1] http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-3.3
On Fri, 27 Jul 2012 16:03:34 -0700, Rob Lanphier robla@wikimedia.org wrote:
On Fri, Jul 27, 2012 at 3:05 PM, Daniel Friesen lists@nadir-seen-fire.comwrote:
On Fri, 27 Jul 2012 10:59:30 -0700, Chris Steipp csteipp@wikimedia.org wrote:
I think I understand what your saying about that, and that's one way it could be done. I had also given some thought to extending the user, so that an OAuth user would have limited permissions, and a SAML user may not even exist in the data store.... etc. But it would be good to hear from other developers if they have thoughts on it?
Separate user rows for OAuth?
OAuth 2.0 has a "scope" field to let the client request an auth token with the scope of the permissions it is requesting, which is a space delimited list of scope strings, to which the server can respond with an auth token that includes that scope list, a different scope list, or an error.[1]
I think creation of an OAuth token should result in the creation of a MediaWiki session, and that scope should be added to the session data. In our initial implementation, I think each of scope strings should correspond to MediaWiki permissions (i.e. mCoreRights in User.php). However, we should think ahead to the day when we might want to have something more fine grained than that.
Rob
[1] http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-3.3
No, I already know about scope. I was just confused what Chris was trying to describe when he grouped separate topics into one paragraph.
OAuth 2 scope can actually apply to the auth code, refresh token, and access token separately. The auth code's scope defines the refresh token's scope. And the refresh token's scope is used when defining the access token's scope. But it's possible to use a refresh token to request an auth code with less permissions than what the refresh token has.
I don't think 'session' will work in the context we currently use it in core. Authorizations, especially refresh tokens are persistent while session storage is ephemeral and can easily forget something we don't want it to forget. We also want to be careful about touching the session data at all. Besides the point that OAuth doesn't use cookies anywhere at all we want to be careful with the fact that we're probably going to need to support an OAuth + CORS environment where we want to erase all cookie and session data and pretend it doesn't exist even if the browser sends it.
wikitech-l@lists.wikimedia.org