I have been asked to implement a cross site login solution in Zend Framework.
I have thought about perhaps using OpenID, are there any other solutions to make a login persist across many sites?
In some ways a closed system hosted by us would suit better.
I would go with openid (see http://framework.zend.com/manual/en/zend.openid.provider.html) but you can also make the login action connect to common database...
I think you can't easily make user connected across different domains as long as the cookies are domain specific...
I think the login solution implemented right here at StackOverflow is pretty sweet. It offers a variety of authentication services. Personally, I feel like providing Google and/or Facebook as the auth provider will cover a large percentage of users.
As tomas.fejfar mentioned, it would be tough to use a non-OAuth solution due to browser security.
Related
I have two web apps running. One is a rails app which is the beef of the application, and the other is a wordpress app(for an online store).
My challenge is sharing login data/session data between the two apps. So If I log into the rails app, and then click the shopping tab, how do I transfer the user session over to the wordpress site?
Also Vice versa. If I am shopping on the wordpress site, and want to login to purchase items, how can I login via the rails app?
I believe there are single sign on plugins that can achieve this, but I have not found anything that is to specific on how to achieve this. For some reason wordpress is awfully terrible to develop around :(.
Are the 2 applications running on the same host? Same domain? Sharing database?
Sounds like your best option is some sort of authentication service, like one of the many OAuth authenticator services (Facebook, Twitter, etc.), or writing your own OAuth service.
Alternatively, if the 2 applications are small-scale and running on the same machine, it might be possible to modify the session handler for either the rails app or WordPress to use the other's session data. I suspect WordPress would be the easier of the two to modify, but I have bias toward PHP
Did a quick search and found this article about modifying Rails cookie sessions to use with PHP.
https://www.coffeepowered.net/2011/08/24/rails-cookie-sessions-and-php/
I also found this article which might be exactly what you're looking for?
http://code.tutsplus.com/tutorials/build-a-custom-api-to-connect-wordpress-with-ruby-on-rails--cms-21189
Unfortunately, I have never attempted this from either direction. But I am very familiar with WordPress, and believe it could be made to corporate with Rails sessions, given enough blood, sweat and tears.
Is there a Codeigniter authentication server that's available for use? Trying to get a multi-application service going similar to Basecamp and I don't want to reinvent the wheel. Alternatively, are there any respectable resources that deal with this kind of authentication?
Thanks!
You should be able to create a user db, and authentication library to do the job.
TankAuth maybe?
You can have 2 applications either seperately installed, or sharing a CI installation using the same library and authentication database. I'd keep everything else application specific, just share profile and login information.
Or, you can implement an OpenID service and have all of your CI applications connect via openid. This is the way StackOverflow does it. I'd google "codeigniter openid" to see what's available. here's a sampling:
http://thinkmoult.com/2009/02/22/use-codeigniter-openid-library-to-integrate-openid/
http://codeigniter.com/wiki/OpenID
Facebook connect offers good authentication possibilities. Also Google, Yahoo! and many other big sites offers similar posibilities.
If you mean that you want some form of 'register at one site get them all'-service, all you need to do is point the authentication to the same database on all sites.
Another posibility is making an authentication page then using cURL or AJAX to check authentication.
I've been looking at implementing OpenID authentication to one of my websites and want to find the best possible solution to make it as easy as possible for users to sign up / in.
Through my long searches on Google I found a few sites that have already covered this in quite a bit of detail; Usability Research on Federated Login written by Google, so feel that they are pretty trustworthy design patterns for a best use scenario.
Now in coming to implement this I have found very little PHP support for logins that are done in this manner; the user only has to type in an email address and all of the OpenID details are found automagically. It should also be compatible with Google Apps addresses.
Google provided a link to a great example of this in action http://www.puffypoodles.com/lso2 but although its source code is available to download, it's written in Java, which I'm far from familiar with!
So I was wondering if anyone had found a good PHP implementation that functioned in this manner. php-openid seems too bloated, lightopenid looks great, but doesn't support this functionality.
Thanks
I'd just like to point out that LightOpenID now comes with an example provider script you might use as a base.
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!