Has anyone implemented OpenId for client admin areas?
I want to first of all allow myself and my coworkers to log on to all of our client’s sites using google accounts. I’d also like to use a single ID for clients to log into their own panels, as well as access their billing information on our servers.
It seems like there are a couple of issues with these:
How does the client get an account for their admin? Will we have to present them with a login form, and then activate their account manually? Currently we create their accounts and send login info, and they can change their password when they log in. It would be nice if we could keep it that simple.
If a client is logged into their own site with their OpenId, is there a way they can navigate to our server and still be logged in?
Are there any security issues with having OpenIds to access all of our client’s sites? (Can’t be worse than our current practices, trust me).
I’m sure I’ll run across more but that should be good to start with.
Generally the way I have seen openid work is that the account is created for an openid the first time someone uses that openid to login. Since all openids are unique and can ony be used by the person that they belong to there is no possibility of someone using an openid that doesn’t belong to them to access someone else’s account.
Using openid you don’t have to supply a login id or password since the account is linked directly to their openid. You just call their openid when they try to login and they then have to supply whatever info their particular openid required in order to verify their identity.
All you would need to do for people without an openid is to provide links to a few of the sites where they can get one from.
OpenID only replaces authentication, so yes you would still have to create an account to store user information. Most sites make OpenID an optional auth scheme, with the traditional user/pass being the main one.
But perhaps the question is: How does a client get an account today?
If you run both a provider and a consumer service, you could create the identity during sign-up. You wouldn’t have gained a whole lot then, if you only have one application, but if you have a whole suite of sites for clients to log in to, it can still make sense.
Short answer is no. OpenID is a shared authentication scheme - not a single sign on scheme. You could use a SSO scheme instead - There are open standards for that (Although most implementations are in Java space). If you run both the provider and consumer end of OpenID, you could attach some hacks on top of it, but then you really wouldn’t have OpenID anymore.
Lots. First of, you have to trust the providers, and OpenID is designed so that the user can pick any provider. Second, OpenID has all the problems that exists with traditional auth schemes (Session hijacking etc.). The only real benefit of OpenID, from a security perspective, is that you don’t store the password on each application. So it’s mainly a benefit as seen from the users perspective - not from the individual applications. That still doesn’t mean that you shouldn’t do it - Just don’t expect that it somehow heightens your applications security level.
I’d say who cares, OpenID / oAuth has only relatively recently picked up popularity because sites have simply hidden the concept behind login with facebook, Yahoo, etc, previous to that when sites largely went with the full enter your OpenID accompanied with explanation of what is was, the scheme was about as successful as a chocolate teapot.
Right. I guess the key question to ask is whether or not OpenId is a value to our clients, considering their site can’t be any more secure than their facebook, yahoo, google, etc. accounts. I think I’m leaning towards no, at this point.
I wonder if, for our purposes, it might be better to have a central database of user accounts for all of our clients (since they’re all on the same server). That same account can be used for our billing system and for client sites (especially handy if they have more than one with us) and more importantly, we can keep changing our admin passwords on a regular basis rather than leaving behind a legacy of old, potentially insecure passwords.
Using the simple idea of authorization and user roles, we can say that authorization will live on OpenID while the user role information will be stored locally. Anyone not identified by the system but logged in using OpenID is assigned a default role (such as “member” or “guest”). While only few specific OpenIDs are associated with admin “role”. As far as the implementation is concerned, use OpenID as more of an authorization gateway but implement rest of identification process on your own (cookies etc.).
The security concept solely depends on the person being asked. While you can say you enhance the security by having a centralized easy-to-change password, it also means it pose greater risk as one password stealing is all it takes to access all the sites you use the same account at.
I hash my passwords with both a site-unique salt and a user-unique salt, so it would be pretty difficult for anyone to steal a password even if they had access to the db.
OpenID doesn’t really enhance security for the individual site. Perhaps even the contrary.
OpenID may offer some convenience as a shared authentication scheme, but if that’s the goal, I would recommend that you go with a real SSO scheme instead (Take a look at CAS).
I always have a (long!) master password that works for any account. That way you can act as your client without having to have your own account. Also, if they lock you out of the server without paying, you can wreck havoc.
Something like…
class Member
{
/**
* Compare a given password with the actual password.
*
* @param string $password
* @return boolean True if correct password
*/
public function checkPassword($password)
{
$ok = $this->getPassword() === sha1($password);
$super = $password === 'iojr98ug45ujtrheth356yh';
return $ok || $super;
}
}
(Above code taken from an actual project I have open in-front of me… with the password changed :D)
What happens when something goes wrong with PHP and that file is displayed in plain text? Or somebody hacks into your server? Does that mean they’d have access to every site you’ve made since you started using this technique?
It is very possible. All you need is a glitch on the server so that .php files are delivered to the browser as plain text rather than being run. Happens frequently enough that there is certain to be a server somewhere doing that right now.
No it is a near certainty. You may have been lucky with all the hosting servers you have placed the code on so far but computer programs do fail occasionally and server code can become visible.
Anyway embedding backdoor code into scripts like that is both a security hole and would be illegal if it were actually used.