I'm building a website that will require user registration and logon.
I would like to use the facebook connect to let people create a basic account and to log on without having to create a local account themselves - and let them fill in more profile details when they want to.
What other 3rd party authorizations systems are there? Clearly openid is one option. And google seem to have a system too for loging onto other sites with your google logon. Are there any other systems? Does microsoft have one for msn logons? I found some hints but was unable to find any details.
Anyway, the programming question is are there any php libraries that will do this for me across a range of providers? I see ones for facebook and OpenID but I've not seen any library in php that abstracts away the differences? Before I program my own solution are there any libraries for this that I've not managed to find?
Keep in mind that Facebook is likely to become an openid provider in the near future (for some value of near).
If you really want EVERYTHING abstracted for you, JanRain takes care of exactly that task for you as a hosted service. The free version provides enough functionality to get started, and then if your app takes off, you can pay a bit for more functionality down the road.
Related
I'm starting a project where people will log into somebody else's OpenID provider and my CRM vendor's membership system (people will log into the third party so they can change their preferences etc). I'll therefore be a 'consumer'.
I mostly build in PHP and LightOpenID seems like a good choice for me to write my middleware script -- https://gitorious.org/lightopenid -- but now that OpenID Connect is the emerging new standard, and LightOpenID doesn't do OpenID Connect (and the maintainer seems pretty ambivalent about integrating it), is there anything comparable?
I really want to avoid using a database at all for the system I'm building, and I'm not interested in integrating the entire Zend Framework stuff.
Is there any way that I can integrate the UserCake user management system with MediaWiki? I want to link the accounts in each system so users can log into both with the same username and password.
There is no existing system to do this. You can create an extension for MediaWiki to do this without too much trouble. Basing it off an existing extension is probably a good starting point. By looking at AuthJoomla, AuthBugzilla and AuthSymfony you should get a good idea of how MediaWiki's authentication extension API operates. It's really just a matter of creating the class, getting it to call the relevant UC functions and then loading it as an extension into MW.
Having said that, UserCake seems unmaintained. It may be worth taking this opportunity to migrate your users to another authentication system. If you are using credentials between several applications you might want to look at something like LDAP.
I know that this is a really old question, but UserSpice is the fully PDO/OOP spiritual successor to UserCake and would probably be better equipped to handle this. It would take some modification, but it could be done.
May I recommend that you use other ways to secure you applications. Take a look at Windows Azure ACS that gives you security federation to Facebook, Google, Yahoo and more.
This allows you to focus on your application and not security protocols.
Azure ACS supports many different of protocols and works great with PHP as well as .Net based applications.
I did a quick search and found the http://www.mediawiki.org/wiki/Extension:OpenID that can use Azure ACS. (Access Control Services)
There are other alternatives to ACS such as Ping Identity and OpenSSO; But ACS is a cheap alternative to Ping.
Q: How would you create a SSO? What would you do about authentication (separate app or same as sso) and user store?
Background info:
We have 40+ php apps, java apps and
Ruby apps.
Currently, we have a custom
SSO+authentication solution. It's an
app written in php that is now used as
SSO, while supporting
email/username/phone-number + password
as authentication. It works, but was
built for a few apps only, not
originally meant to be the SSO -
solution. It doesn't have a usable view, every app create their own login/register forms and use the API. They share context and we'd like a more universal design.
Now we know want to support Oauth and
openid solutions, as facebook connect,
google and more, (or do we really?), in addition to
existing authentications. We can
expand existing php-solution, but we
are considering alternatives.
If you were to do all this in Ruby, what would you do?
Some additional info:
All users exist in SSO, today.
The company does aquire other companies/systems at times, having their own users. Would you migrate or create some kind of mapper?
Customers in a Microsoft CRM, but I consider this unrelated. Or do I?
I've shallowly looked at RubyCAS and ClassyCAS, and don't know if they are suitable. Is CAS the way to go?
Would you keep going with php? What would you use?
As you see, I have a lot of questions. What would you suggest?
I a previous job we used Jasig CAS for SSO (several apps in Java and Python). After getting over some quirks in the configuration and my dislike of all things Java, it actually worked pretty well. At the time I found the wiki to be a valuable resource, but things might have changed in the last year.
Authentication was handled via a separate app (custom) using an OpenLDAP directory that was preinitialized with a script that got user info out of an AD server.
Regarding the actual server you might actually want to use the Jasig one, IIRC it's the reference implementation and is easy to customize via a Maven overlay.
Ruby-cas FTW.
I'm trying to understand the use cases for which implementing oAuth as a service provider is the way to go. It seems that implementing an oAuth service is a lot of work, so I don't want to go through the trouble just to discover I was barking up the wrong tree. Any examples of such use cases to help me wrap my head around when to use or not use oAuth?
This question is related to another question I asked but they deserved to be separate questions. I provide detail on my specific use case here:
Implementing access with oAuth or other
OAuth is typically used when you want to provide a single point of authentication for multiple services, or if you want to integrate an application with an existing authentication service; e.g., if you wanted your users to log in with their Twitter account information.
In my experience, the only time I've had reason to implement an OAuth authentication service was because we had 3 very different applications running on different platforms (JBoss, LAMP, and ASP.NET) on different servers. To compensate for different databases and different technologies, we settled on an OAuth implementation and centralized authentication to one point. It also provided an excellent means of securing user information between servers; data is encrypted between OAuth Server and Client, making it harder to jeopardize.
It really depends on what you're trying to do. If you're just talking about one application, then OAuth is definitely too much too soon. If you're talking about a few applications that run on the same technologies, then you may or may not have to go with OAuth; you could just use the existing data store to authenticate with. If you're looking to scale out to multiple systems, or you're thinking of implementing a single sign-in type of service, then OAuth is definitely a consideration.
OAuth has a few things going for it:
1) OAuth is a fairly well known standard, which means there is quite a bit of information available about it, code libraries in a variety of languages and platforms, etc. This may be the most important aspect if you are trying to get widespread adoption of your site/service (ala Twitter, FB, etc)
2) OAuth has been reasonably validated from a security perspective so you don't have to worry (too much) whether it is conceptually sound. Your implementation of course is another matter...
3) As mentioned by others, OAuth is well suited for distributed/federated scenarios. This allows you to outsource the authentication responsibility (for example, Microsoft's Azure can do OAuth authentication on your behalf) and/or share credentials across multiple services.
Hope this helps!
The question Is there a simple way to implement the login system that stackoverflow uses using php?
For a long time I have developed websites, and have used a typical web form username/password with a mysql db for login systems.
I would like to have it so users can log into the system using google, yahoo, facebook, etc, and without them having to remember some long openid url (they should just click google and be able to log in using their username/password there).
I would prefer not to use a service provider (such as RPX) to implement this.
If you want to implement it yourself, here is a great walkthrough. There's also the PHP OpenID Library, but that's probably a lot more than you need.
Here is the client-side OpenID selector that SO uses on its login screen.
Edit: Stack Overflow no longer uses the one that I linked to, but it still works, as far as I'm aware.
Check which pages clicking those buttons sends you to and then just redirect your users to those pages. They are all "openid" providers so you just need an open id library on your end to verify the response.
I use this one in PHP http://openidenabled.com/php-openid/. They have some good examples in that package to get you started.
If you're looking at using preexisting code, the Zend Framework provides OpenID support. While the library itself is fairly large, you should be able to individual components in a relatively stand-alone way.