Re: [Wikitech-l] OAuth, abstract implementation, and built-in unknown / internal / import applications.
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! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] OAuth, abstract implementation, and built-in unknown / internal / import applications.
On Fri, 27 Jul 2012 10:59:30 -0700, Chris Steipp cste...@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! -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] OAuth, abstract implementation, and built-in unknown / internal / import applications.
On Fri, Jul 27, 2012 at 3:05 PM, Daniel Friesen li...@nadir-seen-fire.comwrote: On Fri, 27 Jul 2012 10:59:30 -0700, Chris Steipp cste...@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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] OAuth, abstract implementation, and built-in unknown / internal / import applications.
On Fri, 27 Jul 2012 16:03:34 -0700, Rob Lanphier ro...@wikimedia.org wrote: On Fri, Jul 27, 2012 at 3:05 PM, Daniel Friesen li...@nadir-seen-fire.comwrote: On Fri, 27 Jul 2012 10:59:30 -0700, Chris Steipp cste...@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. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
