So, we are porting the keyauth module for Services 3 here http://drupal.org/node/1246396/
We need this at sony because of some legacy services we provide. I know there was a lot of discussion about why the module shouldn't get put into services core, so I don't want to rehash that, but I would like to know some of the reasons why it wasn't ported, especially security concerns so that we can make sure that we communicate that to users of this module.
I think the biggest issue was that it was much easier to leverage drupal's built in permissions system?
For our use case, the legacy service is a read only operation, but we don't want to make that endpoint available to anonymous users. We also don't want to have to create a special user and role for each site. It would be much easier to just share the same keys.
Thoughts?
Comments
So we're working on this now,
So we're working on this now, and ran across the fact that it looks like the resources are actually implementing their own permissions, not just the authentication mechanism. This came up for example when we tried to setup a simple user listing for an anonymous user. Because the permission "access user profiles" was not checked, the anonymous user was denied access to viewing users in the REST interface as well.
This means that if we use keyauth and want to enable listing users for those anon keyauth users, but not for regular anonymous users, then we're going to be blocked by drupal's user permissions because a distinction is not made between the two?
Frank Carey
Twelve Grove Inc. Drupal Development
Feedback from Services maintainers
There was a ticket open about this in the Services queue here http://drupal.org/node/1335112 and I'm posting that feedback so that the conversation can happen here instead.
Posted by marcingy on November 10, 2011 at 11:27pm
The reason was because the solution was a 'hack' and in the time since it was originally created (by myself) things have evolved in terms of available token based authenication systems. The decision was taken to remove keyauth and instead base token based authenication on Oauth because it is an open standard rather than something created specifically for this project.
Posted by kylebrowning on November 10, 2011 at 11:44pm
Why not use oAuth, theres currently a patch that supports two legged auth, which is the same as keyauth but like 10 times more secure.
Frank Carey
Twelve Grove Inc. Drupal Development
What is 2 legged auth?
I didn't know but google returned this which was a pretty clear description assuming that it's up to date.
https://sites.google.com/site/oauthgoog/2leggedoauth/2opensocialrestapi
Frank Carey
Twelve Grove Inc. Drupal Development
2 legged oauth is basically
2 legged oauth is basically key auth.
Three legged oath is the standard oath which requires the end user to allow access.
2 legged ouath only requires the API key to get a validated access to server.
Its what you need.
You don't need to port keyauth.
I don't know how many more times i have to explain this.
http://drupal.org/node/1336974
Thanks kyle, this type of
Thanks kyle, this type of feedback is much appreciated.
I was hoping something like this was possible based on my limited experiences with facebook and twitter oauth. I was asking heyrocker at DIWD about it, and he didn't mention the alternative. This certainly looks like the right direction over porting the module, with important caveats that we're going to need to update our API consumers to use OAuth instead of the old keyauth method as well as the keys it uses. Thats's not a big deal for us because we just have 1 consumer, but if you had a ton of people using your API or widgets with keyauth, then you'd have to work cut out for you to inform them that it's deprecated, etc. (not a complaint, just making that clear for those following at home, and correct me if I have this wrong)
The other main issue that I still see for users of keyauth moving to Oauth (2-legged) is described in that ticket: http://drupal.org/node/1336974 .. "loading the user that owns the API key". With keyauth, the keys are not associated with any particular user. Is there any thought going on about how that separation could be preserved in Services 3.x?
Frank Carey
Twelve Grove Inc. Drupal Development
[dupe]
[dupe]
Frank Carey
Twelve Grove Inc. Drupal Development
oAuth key = user
"With keyauth, the keys are not associated with any particular user. Is there any thought going on about how that separation could be preserved in Services 3.x?"
I didn't use Services before 3.x, but to me that separation is a bug, not a feature. In fact, I'd call it a security risk. API keys belong to users. If you're Flickr, and you give an API key to a particular user, it shouldn't give that user rights to do anything they couldn't already do through the UI. That's what two-legged oAuth is for. On the other hand, if you're Twitter, and you give a developer an API key, they shouldn't magically get rights to manipulate user accounts. The user should have to authorize it. That's what three-legged oAuth is for.
If your particular use case calls for giving out API keys that allow more operations than a user already has permissions for, the only options I can think of are 1) go ahead and grant those elevated permissions to the owner of the API key, or 2) associate the API key with an existing user or a dummy user that has the correct permissions. Anything else seems like it would be a security risk if it were released to the public, and therefore belongs in a custom authentication module. You could write one quite easily based on services_oauth, and just swap out the part that loads the consumer account into global $user with some code that loads an appropriate user with the right permissions.
Yeah, that's what I'm thinking...
The way I am understanding it... While the 3 legged user specific keys or "authorization tokens" should probably be tied to a user, the consumer keys don't necessarily NEED to be user specific. Example: If you look at the way facebook does it's consumer keys. The keys are per "application". That application can then be owned by one or more developer users. Leveraging drupal's permissions system to handle what a consumer can do or not seems smart to me especially if you want to allow consumer users to create or access one type of node, but not another. However, in our use case we just want to provide a simple way to expose readonly information about the site without the overhead of creating and maintaining a user and a new role to give this one permission to, but we also don't want to make it easily available to all anonymous users as well. It will be important to communicate that when using this module, that you may not be invoking drupal's permissions system, and that the only additional restrictions will be what the resource (service) provides.
While on that thought. Is the a way to override the access callback, like there was in services 2? Do you know how you would allow a keyauth (anon user w/ key auth credentials) to say... access the node->retrieve resource without giving the "access content" permission to anonymous users?
Frank Carey
Twelve Grove Inc. Drupal Development
Is it possible to get oauth working in services-7.x-3.x?
Any quick pointers on getting oauth working in Drupal 7?
At http://drupal.org/node/1336974#comment-5305810 marcingy says he committed the patch in #18. There have been releases of 7.x-3.x-dev since that comment and I don't see that patch in the latest releases...but maybe it's been reworked. What's really strange to me is that services/auth/services_oauth/services_oauth.info still depends on the defunct oauth_common.module. I figure that would have been removed since there was never a D7 release of oauth_common...?
The patch in #18 (http://drupal.org/node/1336974#comment-5283802) also doesn't seem to remove the oauth_common dependency.