I am building a web application where development teams can install and use inside their companies. I am exploring the possibility of adding SSO support with Github since it is very convenient for developers.
In Github API, Auth0, Google etc. you need to specify Callback URLs.
The problem is that since everybody can deploy an instance of my application they can host it under any valid domain or just use a local ip address. So the Callback URLs cannot be predefined.
One option is to instruct people to deploy the app under certain local domains/subdomains. However, I don't think this is a good solution.
Do you know any other options that might solve my problem?
Is SSO only suitable for apps that run under global(already known) domains?
Related
I have just deployed my Grails app on public cloudfoundry(myApp.cloudfoundry.me) and i need my domain to point to it. How is this accomplished? or what are the alternatives?
Problem: deploy Grails app via cloudfoundry on cloud with my own domain name instead something.cloudfoundry.me
Resources: i have a virtual server Ubuntu with static public IP available.
Goal: have a way to deploy many of my apps each with their own domain names
If you don't mind sharing how you do it today and, perhaps, if you can reference tutorial that would be very helpful
Thank You,
Cloud Foundry does not currently support custom domain mapping. However, this feature is high on the priority list and development is currently under way. If you do a search at Cloud Foundry Support
you will find a series of posting regarding this issue and some short term workarounds that could be helpful for you and your particular situation.
Thank you eightyoctan! I accepted your replay as answer, however. i wanted share what i end up doing to have my domain point to cloud foundry hosted app
Option 1. i used GoDaddies Forward+Masking to push app on myapp.cloudfoundry.com and then forward+masking on godaddy to have mydomain.com point my app on cloudfoundry....i am sure i am penalized from SEO aspect to some extent but it works so far
Option 2. I also believe the same goal - have my custom domain point to cloud foundry app via Elastic Ip of EC2 as described in the following blog:
http://www.cloudsoftcorp.com/blog/first-steps-with-cloud-foundry-on-amazon-ec2/
Or use Stakato with EC2 that runs on top of cloud foundry from what i can tell. For more:
http://docs.stackato.com/server/ec2.html#vm-ec2
Either way, I hope cloud foundry does get this feature soon so we don't have to make extra steps to accomplish this
I have one main Asp.net MVC application, I also have a help site and quite a few internal apps (that I need to build - reporting, stats, support tickets).
Question: Can OAuth be used in this way? i.e. a user can be authenticated to use all apps (if they have access to that app)?
Ideally all or most of the other apps will be implemented in Ruby or Node.js - so I am hoping I can achieve this with OAuth.
As long as all of your apps run under the same top level domain, it should not be strictly neccessary to use OAuth or similar to obtain a shared session. Instead you could rely on a plain session cookie. You could run some kind of middleware in between your app and the user.
Only if the main app is providing a REST API that you may want to use on various client apps, where some of them run in external environments / domains, making use of OAuth may be relevant.
I am currently developing an MVC app using asp.net. My final aim is to deploy the saas on Azure.
But would it be feasible to do it at a later stage or should i incorporate it into my development?
When it comes to use Azure authentication etc i will require that due to the app being multi tenancy.
Just wanted to know peoples thoughts on this?
Cheers
It would be better if you can provide more information. Do you want to know if you ignore Azure at the moment, how much effort you need to take if you decide to deploy the application to Azure? In general it would not take too much effort, unless you want to use Azure services, such as storage, ACS, and so on. Deploying an ASP.NET application to Azure web site is just like deploy to a remote IIS. Deploy to web role requires you to create an additional cloud service project. Deploy to virtual machine usually does not require any modifications to the project, but requires you to setup all the environment.
In addition, please note there’re still some difference between Azure and local environment. For example, we usually use Azure SQL Service instead of connecting to the local SQL server.
Best Regards,
Ming Xu.
I'm doing something similar, but without developing on Azure right now. I have prepared for it though by making sure I use interfaces as much as possible. For instance, I don't write to a file system using File and Directory, but to interfaces IFile and IDirectory.
If you can avoid assuming anything based on your current localised, Windows Server environment then you can at least write implementations to satisfy requirements that do work in Azure. I'm planning to deploy to Azure and local Web servers and use Dependency Injection to satisfy the concrete implementation of the interfaces. I could just as easily use the same codebase entirely and have it detect the environment before injecting the implementations.
I'm working on an appengine app which uses OAuth. Naturally, I'm dealing with multiple versions of the app simultaneously - a local version for development, a staging version and a deployment version.
To work with these, I need three separate sets of OAuth consumer keys/secrets as the callback on authentication is defined on the provider's site.
I was wondering if there are ways for providers to provide multiple keys/secrets for a given app - this would seem to make more sense than setting up a new app each time. (Of course, it requires the provider to implement this, but it seems a natural thing to implement and I haven't seen it).
More generally, what standard approaches are used to deal with this - my guess is register multiple apps and have logic in the app to determine if it's in development mode, staging or deployment. Any thoughts welcome.
I find this to be one of the most annoying parts of being an OAuth API client developer. There is no reason why providers should not allow developers to register redirection (callback) URIs for testing.
The standard approach I've seen is to allow you to whitelist one or more domains for callback / redirection. Facebook has some crazy setup where they let you "register" multiple domains by using different domains for the various links in the application profile. I did not have much luck with that. Twitter is one of the better implementation for that, letting you register multiple domains.
In OAuth 2.0 (draft 18 or newer), this topic gets much better treatment. Registration of the full URI is recommended, with the ability to register multiple callbacks and select the one you want to you dynamically at request time.
The main aspect to consider is how you want to handle permissions with a staging setup? Do you want to be able to reuse existing approvals or want to keep those separate? Also, if the API provides special client-only calls (such as client storage or management tools), do you want the stage version to share it or keep its own (so that testing will not mess up production).
At the end, providers should provide a complete development environment and that includes testing facilities for API clients. Most don't.
From an API provider's perspective your app is simply an app using the APIs. Usually there is no such thing as a "staging" API, which does not deal with live production data. Whatever it is you are testing, you are testing it on live data right?
If you are able to register several different applications with for example different callbacks then I think your problem is pretty much solved. My view is that it should be the consumer's responsibility to keep these things separated.
I'm building some applications using rails.
All apps using restful auth plugin for User base and declarative authorization plugin for authorization rules.
But I need to merge all site's User accounts to one User base for providing login for all sites.
I.e like 37signals working on. Here is their work ;
http://37signals.com/accounts
How can I archieve this, any suggestions are welcome.
Thanks
A.Karr
From studying how 37signals was doing stuff - I think they're using RubyCAS http://github.com/gunark/rubycas-server
It's perfect for single sign-on, single sign-off and other related stuff - when you have multiple independent applications. Also, because CAS is a generic protocol, it exists for non-ruby/rails applications too. SO you can integrate legacy systems or client applications in Java etc.
I started building a set of how-tos on the subject here:
http://rubyglasses.blogspot.com/2009/12/rails-single-sign-on-with-rubycas.html
Have you thought about using open id?
If all your apps run on the same domain you shouldn't have any problems accessing the authentication cookie in all the apps, but you'll need to store the authentication state somewhere where all the applications can access it.