anybody know is possible to use Persona for SSO purposes for cross site login, where each site is it's own domain? Very similar to 37signals and how they set up basecamp, Highrise and campfire.
Would like to have user create something similar to a 37 signals ID.
thanks.
If all of your sites share a common domain (e.g. foo.example.com and bar.example.com) then you could have a login server (say login.example.com) that sets an example.com-wide cookie that each subdomain can use.
For cross-domain sites, there has been a realm proposal but it's not currently being worked on.
Related
Can anyone think of a neat solution for this; we operate an website service and sell to large organisations. Rather than have a logon for everyone, we'd like to be able to provide a direct link to our website from the organisation's Intranet page. We'd then like to check the referrer and if it's in our listed of 'trusted referrers', i.e. the intranet url, then we grant logon without asking for credentials.
I'm aware you can do $_SERVER['HTTP_REFERER']; to get the referrer, but I'm also aware that can be spoofed. Can anyone think of how we could achieve what we want, but while also guaranteeing it won't be hackable?
Thanks in advance
It's not exectly what you want, but to make logging on easier and ensure you don't need to store all the passwords you could use, for example, OpenID.
I think that there is no perfect and safe solution for this.
One solution would be to append tokens to the urls. It will work and it will be save, but anyone who knows the link (including token) will be able to login as that organization
Another solution would be to check the source ip. This can be done in different ways *apache, load balancer, app, etc).
Also a combination of token + ip could work (this token for that organization but only if the request comes from allowed_ips for that organization)
A more elegant solution (which I implemented for several big companies) would be to integrate you website login with the active record domain login. It is possible to use the current user window login as login into a website, using domain authorization. If a user is logged in into a domain, when enters your site will automatically login to the website.
This solution is much more easy to implement than it sounds. But, requires Active directory and workstation that connects to a domain to be in the company (this shouldn't be a problem, most of corporations are using windows on workstations and active directory for domain controller). Also is working best on IE only (direct login to the website). On other browsers the domain login popup will appear and user will have to enter again the domain password.
Also, I am pretty sure that can be made to work on linux environments, but I have no idea how.
Background
I work at a SaaS company where you get a site when you signup.
If the company's url is saas.com this could be a list of clients:
abc.saas.com
mysite.saas.com
so.saas.com
Currently, each of our clients has to go to /admin to get to his admin panel.
abc.saas.com/admin
mysite.saas.com/admin
so.saas.com/admin
The thing is that services like Clicktale that track users by recording them, limit the amount of subdomains you can track. If you want more subdomains, you have to pay more.
Because of this we are analyzing the possibility of migrating to admin.saas.com as a single subdomain for all admin panels.
Which are the pros and cons of having several /admin subdomains VS a single admin subdomain?
Considerations
SSL is already solved, we have a wildcard certificate
We could keep a 301 redirect from /admin to the admin.saas.com
Thanks!
Pros to have a single domain (admin.saas.com):
Users having more subscriptions can manage subdomains much easier (they don't have to navigate to a different URL)
Your documentation and videos will be easier to understand with a specific address. Links with placeholders like {yourdomain}.saas.com/admin make clients think.
Firewall rules could be set up easier in a complex architecture
We had to make the same decision while developing our SaaS/PaaS product few months ago and we are happy with this implementations. According to your scenario, I cannot see any cons.
I have a requirement where I need to implement SSO between two different websites.
One of the website say www.abc.com is written using ASP.NET and is hosted on IIS 7.0. The second website say www.xyz.com is written using PHP and uses Apache web server. Both the websites uses different databases and uses different algorithms to authenticate the user.
I cannot use a third party SSO as that would mean changing the authentication for both the websites. Wanted to know if this is possible and if yes, what should be the approach?
Thanks in advance...
We could find an alternative approach. Basically, we were trying to address this issue by using two cookies (one each for www.abc.com and www.xyz.com created by each site), but since we were unable to find a way for reading cross-domain cookies, we were stuck up.
But then, I stumbled upon the way forums.asp.net and hotmail works. They use the live.microsoft.com to set the authentication cookie.
Now, we plan to create a third website for authenticating the user. The login forms in both the www.abc.com and www.xyz.com will call the third website to set the authentication cookie. Using this authentication cookie, we will be able to allow user to have seamless browsing across both the websites.
Also, found a very good article on this implementation.
http://www.codeproject.com/Articles/114484/Single-Sign-On-SSO-for-cross-domain-ASP-NET-applic
we are looking into implementing Facebook Connect on our wiki service, http://www.wikidot.com. User-created sites span the *.wikidot.com domain, but also custom domains (like mine http://michalf.me), all handled by our single service.
We have a centralized account system. Users always log in (and create accounts) at www.wikidot.com and they are automatically logged in in all subdomains (cookie domain set to .wikidot.com - easy) and custom domains (automatically, via a series of redirects).
We would like to add FC into our login flow. Now, it would be great to get some clarification about FC Terms, which suggests using one App ID for every domain. In our case however user-created sites are not separate applications.
So, is it OK to use FC on one centralized website where our users log in (on www.wikidot.com) and expand user status on other domains connected to our service? This is how it works right now, without FC.
It would be great if we could get clarification from someone from FB to make sure we will not be violating any terms or policies.
Thanks!
It isn't possible (as far as I know anyway) to use the same app ID on multiple domains. FB allows use across subdomains, but I have found some difficultly with this even at times with the cookies. When you set up an app, you are asked to provide the domain for it. The domain you put here is the only domain that your app will work for. If your users are only ever signing in on wikidot.com, then I suppose you can use what you have already to move those sessions onto the other domains, but once you are on the other domain, you won't be able to use any of the facebook api features; any requests you make will fail.
I think the 'one app id for every domain' condition is more to target people who are trying to use multiple app ids for one domain. I think so long as you aren't transferring any data about the user to different domains/adverts etc, you should be ok. Essentially what you are doing is adding FB connect to your wikidot site, then a separate feature of wikidot is to keep you logged in on other partner sites?
A requirement to use the RPXNow is to set your Facebook application's connect url to http://mydomain.rpxnow.com.
I was just trying to implement Facebook's Open Graph and I see that it tells you to set the Base Domain to the domain that will contain the app_id.
However, Facebook does not allow these two domains to look different. When I try to set the base url to mydomain.com, I get this error:
Validation failed.
Base Domain is not valid. Connect URL must be derived from your Base Domain.
Should I create two apps - one for use with RPXNow, and another for use with Open Graph? If not, what should I do?
Thanks
The Facebook page regarding Base Domains you linked to states the following:
Facebook Connect stores user credentials in cookies on your application's domain. By default, a cookie set on chicago.citysearch.com would not be readable on sanfrancisco.citysearch.com - the browser treats them as separate domains. If the base domain is set, then Facebook will intentionally set the cookies on the base domain, thus making the cookies readable across multiple subdomains. This allows you to share one authentication session across multiple subdomains.
Note: There is no way to share a cookie across multiple domains. So, for example, if you have a site cnet.com and news.com, then there is no way to make the browser send the same cookies to both those domains. Each of these would require separate API key and separate authentication.
Since your domain and rpxnow.com are different base domains, it seems like you'd need a custom realm (eg. login.yourdomain.com), which is offered from RPXNow at additional cost. You'd probably have to upgrade to "Pro" account (~$95/mo+ ?) or contact RPXNow / Janrain directly and ask them your options.