Marcingy

A while ago I had the need of sending a users openid to authenticate the user.

As long as the user had already logged into their openid provider, then a drupal session would be returned.

I was not sure where to put it earlier, so had the code in cvs.

http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/openid_serv...

I am wondering, since openid is core, maybe this should be included into the services module, either in the users service or other?

Comments

aufumy’s picture

aufumy commented
Title: Simple openid service part of users service or separate » Openid service
marcingy’s picture

marcingy commented

Thanks for this i'll try and review it over weekend - but yes an open id service makes prefect sense for core.

aufumy’s picture

aufumy commented

ping...

aufumy’s picture

aufumy commented
Status: Active » Needs review
gdd’s picture

gdd
he/him
Primary language English
Location Portland, OR
commented

Audrey, I have this on my list of issues to review before I do an official release of 2.x (hopefully before year's end.)

aufumy’s picture

aufumy commented

thanks heyrocker. Happy coding Xmas!

gdd’s picture

gdd
he/him
Primary language English
Location Portland, OR
commented

So I finally got a chance to look at this. First off, I am pretty unfamiliar with OpenID, so please bear with me.

So by all appearances, as long as you know someone's OpenID, you can get their session with this service. Many Services sites use the session id as their primary form of authentication. If you have that you've got the keys to the barn. This seems like a security problem to me, especially as the service isn't even protected by a hook_perm(). My understanding is that a person's OpenID is not supposed to be particularly secret either.

So I'm concerned about this, although I may be misunderstanding some things. Can you offer some more insight?

Thanks

aufumy’s picture

aufumy commented

Good questions, but the session id is only supplied if the openid authentication is successful. Such that user jay@myopenid.com is actually logged into his myopenid.com account.

I am going to setup a bunch of test distributed search sites, for testing purposes.

gdd’s picture

gdd
he/him
Primary language English
Location Portland, OR
commented

The concern I have is that since this module has no permissions setting, then any site that runs services with only session-based security will have this service available to anonymous users.

This means that any anonymous user would be able to, without challenge, get the session id of any logged in Open ID in the system. These are often easily guessed, and once you have someone's session id then impersonating them is a very simple matter. I admin several sites, my openid is very easily guessed, and I am pretty much always logged into them. I don't use OpenID personally but you get the idea.

Adding a hook_perm() plus an access callback for this would resolve my issue, as then access can be controlled by role for those choosing to run with session-based security rather than api key security. Even so this makes me a little nervous since I'm not fully versed in the security implications. I may run it past someone on the security team for more insight.

aufumy’s picture

aufumy commented

This is not the case Greg.

It does not just willy nilly return the session id.

Only if you have access through your openid provider to login with that openid, then it will return that session id.

I will provide you more proof shortly.

voxpelli’s picture

voxpelli commented

This seems like a pretty weird service to me and I share heyrockers impression of it.

The OAuth standard was developed to solve the challenges of using an OpenID to authenticate users over an API and since there's already a Services implementation for that http://drupal.org/project/services_oauth I wonder if this new service is really needed?

I might have misunderstood what you're trying to achieve with this patch though.

gdd’s picture

gdd
he/him
Primary language English
Location Portland, OR
commented
Status: Needs review » Postponed

So I'm gonna postpone this and we can revisit the discussion in 3.x

aufumy’s picture

aufumy commented

Some of my rambling thoughts, which may or may not be true. Feel free to provide alternate points of view.

Oauth is not a replacement for openid. Oauth can be used to create the user credentials for an application, such as a photo printing service, that flickr users can access. Or mafia/mobster world access by facebook/twitter users.

However, it is probably better to use OpenID and Oauth in combination, as Google and other players are doing, using a hybrid openid/oauth implementation.
http://googlecode.blogspot.com/2009/05/google-openid-api-taking-next-ste...
http://www.slideshare.net/johnmccrea/what-an-rp-wants

Using drupal as an analogy, where each module is an application, such as book 'application', poll 'application', etc. OpenID is equivalent to the user module. Whereas Oauth is equivalent to the access control / permissions in drupal.

If it where just oauth providing access to each service/application/module, then what I would do in drupal, is create a role for book users, then a role for poll users. I would allow say fb/twitter users who were interested in my handbook, access using oauth, an applying the book role to them. In the same way other fb/twitter users that wanted to access my poll, results or vote, I would through oauth give them access to do so.

When they are on their fb/twitter site, the fb/twitter might know that they have access to my handbook and poll. However, when they are on my drupal site, using the handbook, that user is not necessarily related to the poll user. So they may likely not know anything about each other.

OpenID provides a uniform identifier so that the book user and poll user can be one user reducing duplication, and providing better usability.

voxpelli’s picture

voxpelli commented

OpenID does authentication. OAuth does authorization.

OpenID is a mechanism to authenticate that a user is who it claims to be.
OAuth handles whether an application is authorized to do certain stuff on behalf of a user.

The history of OAuth can be found here: http://oauth.net/about/

In a simple API the client can prove that it's authorized to do certain stuff on the server by having a user enter their username and password which the client can send to the server to authenticate that it's authorized by the user to do that stuff. If the user have an openid instead of a username and password that won't work since openid authentication is much more complex.

What OAuth does is that it removes the need to re-authenticate the user again and again. Instead the authentication is done once by the trusted server itself in a way that works with OpenID and when the user is authenticated it's given the possiblity to authorize the client to do certain stuff. The fact that a certain client has been authorized to do certain stuff on behalf of a certain user is saved for the future. The client don't need to authenticate the user to do the certain stuff - it just needs to reference the authorization that the user has already given it.

The google link in your post is about a new standard, http://step2.googlecode.com/svn/spec/openid_oauth_extension/latest/openi... , that combines the usual openid-log in to a site with the authorization of access to an api provided by the provider of the openid used to log in. So logging in with a google openid to a drupal site could result in authorization of access to the google api. Services is only about providing API:s not consuming them so it would only be the reverse that's interesting for us - giving oauth authorization as part of a user logging in to a third party site with an openid provided by a Drupal site. There's already some work going on creating an openid provider for Drupal, http://drupal.org/project/openid_provider , which the oauth authorization could be integrated with one way or another. The openid provider could probably also use services for some of it's API:s. Both those feature requests would be feature requests of the openid provider module though and not for this module.

aufumy’s picture

aufumy commented

Okay, this is very interesting feedback, thank you. I'm not clear at all yet, so I will rehash what I can understand so far.

currently the scenario I was working off from was
Case 1) Distributed search
Site A where user Joe can perform distributed search, is an IdP (OpenID provider), and thus site A gets login credentials for site B, C, D with OpenID authentication (assuming Joe can perform OpenID authentication, by being logged into his IdP site A). This is currently on a working implementation.

Case 2) OpenID toolbar
Site A which is Joe's IdP, lists the RPs that Joe logs into as joe@A. On clicking the RP link on site A, joe@A is logged on to site B with a javascript login, similar to the original posts by Luke Shephard
http://www.sociallipstick.com/2009/02/?y%25/how-to-accept-openid-in-a-po...

Using Oauth instead:
Case 1) Distributed search
Site A, which is Joe's IdP and where Joe uses distributed search, is a oauth client, of sites B, C, D which are all oauth service providers. Not sure how oauth and openid would tie together here.

Case 2) OpenID toolbar
Site A, which is Joe's IdP, lists sites that Joe@A has logged onto, and uses oauth to authenticate the user to login automatically to sites B, C, D.

aufumy’s picture

aufumy commented

I guess, I seem to be leaning on the facebook way of doing things;
http://iiw.idcommons.net/Why_Facebook_doesn%27t_implement_OAuth_today
"It takes only two HTTP requests to get a user session in Javascript and start making API calls. With vanilla OAuth, it takes four HTTP requests - two on the server, and two on the client."

aufumy’s picture

aufumy commented

The openid service calls user_authenticate_finalize which invokes hook_login.

In openid.module function openid_login_validate() calls openid_begin() which will ask the user to login to their OpenID provider and ask to allow the drupal site access, etc.

If the user does not have login credentials to the OpenID provider, they will not gain login to the drupal site.

aufumy’s picture

aufumy commented

I have to say, I need clarification on this:

So logging in with a google openid to a drupal site could result in authorization of access to the google api. Services is only about providing API:s not consuming them so it would only be the reverse that's interesting for us - giving oauth authorization as part of a user logging in to a third party site with an openid provided by a Drupal site.

AFAIK, logging in with a google OpenID to a drupal site, would not result in authorization of access to the Google API, that requires OpenID and Oauth together. The user access to Google occurred when on the client side, the user logged in to Google, as a proviso to use Google as an OpenID provider.

Comparing to Google is a different ball game, because definitely Google would be the OpenID provider as well as the Oauth service provider. Because usually a single drupal site compared to Google is like David and Goliath, where the drupal site is dependent on Google for access to information, etc.

However in the case of distributed search, where each site is more or less equal to each other, and not one site more of a repository than the other, making each site to be an Oauth service provider for the other adds a layer of complexity that just doesn't make sense to me, as I'm dealing with a trusted network of sites, that are on the same playing field.

Hugo Wetterberg’s picture

Hugo Wetterberg commented
Status: Postponed » Closed (won't fix)

The proposed service is a security risk. To log a user in based on the caller knowing the openid url is about as secure as granting someone access because they know my email.

aufumy’s picture

aufumy commented
Status: Closed (won't fix) » Needs review

The statement

The proposed service is a security risk. To log a user in based on the caller knowing the openid url is about as secure as granting someone access because they know my email.

is simply and painfully not true, because as I mention above it will run through functions openid_login_validate() and openid_begin().

Think about if you type in my openid url into a drupal openid. Just because you know a person's openid, and type it into the login box, does that mean that you will automatically gain access to the drupal site? The answer is obviously not. Because, if it were the case, then there would not be openid module in core.

Please give me a chance to chat with you and other nay sayers, I am sorry I missed the irc chat a week ago. When are you meeting next?

I mean I am happy to close this patch and just maintain a separate project if there is so much fuss about it.

However, I don't think that decision should be made based on an incorrect assumption.

aufumy’s picture

aufumy commented

OpenID can be confusing, and it can be scary because of the seemingly lack of dependence on a password. However, the password stage is moved from each individual site, to the OpenID server. The authentication still exists, a password (or infocard) is still needed to login to the OpenID server.

Yes, it is true, that if your password to the OpenID server is compromised, then that person can access all your sites that you have authenticated with your OpenID url. This is part and parcel of the OpenID technology. The extent of damage is larger if a person knows your OpenID username and password to the OpenID server, because now they can login to all sites B, C, D that you used to login as joe.myopenid.com.

The choice to enable OpenID on sites, or for users to use OpenID is a personal and individual one, that 'Joe' has to consider as to balancing the convenience of OpenID with someone getting his OpenID server password. However if Joe uses the same password for logging into sites A,B,C,D when not using OpenID, then the same effect would follow anyway.

However, just knowing your OpenID username does not grant a person access to sites B,C,D, because the OpenID server will return to the drupal site, whether you have access or not. If Joe is not logged into their OpenID server, then the response to the drupal site will be false, and Joe will not be logged into the drupal site.

marcingy’s picture

marcingy commented

Looking at code though it doesn't require me to have authenicated via open id in this session, and works in a fundamentally different way from open id in core. In the open id module I enter my password and am handed off to a third party provider where I validate that I am who I say I am. Then if I go to a new PC or indeed a new browser on the same machine where I have not carried out the validation step I have to perform validation again.

As it stands the open ide servie simply says yeah this openid identity exists in the authmap table lets them in, the validation step does not occur to ensure that they own the id. So I agree with Hugo this can not go in as it is a huge security hole because of this fact.

aufumy’s picture

aufumy commented

Okay, maybe I missed something.

I was so sure that distributed search results are not returned when the user is not logged into their OpenID provider. However, I have to prove it to myself whether this is true or not.

The best thing for me to do is to test this again, and maybe setup some publicly available test sites.

Hugo Wetterberg’s picture

Hugo Wetterberg commented
Status: Needs review » Closed (won't fix)

Well, maybe I should explain myself better. First of all: I'm very happy that you want to contribute to services, I sincerely mean that and hope that this doesn't discourage you (or makes you think that I'm a evil bastard). The problem is that when a user logs in to a Drupal site using OpenID for the first time the identity url is added to the authmap table. This is done to associate the account with the OpenID identity so that the user gets logged into the same Drupal account on subsequent visits. This association isn't removed when the user logs out. Even if that was the case the user would still be wide open to attack while being logged in.

The service you propose has nothing to do with OpenID. Access should only be granted to someone that knows the url AFTER the following protocol has been followed: http://wiki.openid.net/Introduction. And that requires performing a lot of the operations in the browser, not during server to server communications. Giving access based on the url without following the OpenID protocol is not a good thing.

I stand fast with my statement that this module is a security risk, as anyone that knows the identity url of a user that previously has logged in to your site will be able to obtain a authenticated session and perform actions as the user. It will not be included and I would recommend that either you or the security team remove the project altogether.

aufumy’s picture

aufumy commented

Not at all. You are all very right, and I am very incredibly mistaken.

I must have been dreaming, to have thought I had properly tested this, and that it would go through the openid authentication IdP each time before returning the session id.

I apologize for all this misunderstanding, and taking your time.

aufumy’s picture

aufumy commented

I have created an issue to webmasters to remove openid_service.
http://drupal.org/node/699352

I am sorry for all this trouble.

marcingy’s picture

marcingy commented

@aufumy no problem at all, I think we all learned more about openid as the result of this issue. And it shows the benefits of peer review ;)