I have a web app (ASP.NET MVC4) and I need to enable HTTPS/SSL to it.
I checked a lot of articles and tutorials on how to do it, but I didn't get one thing:
Some places talks only about the configuration of IIS :
RapidSSL:
https://knowledge.rapidssl.com/support/ssl-certificate-support/index?page=content&actp=CROSSLINK&id=SO22345
Nice blog:
http://weblogs.asp.net/scottgu/tip-trick-enabling-ssl-on-iis7-using-self-signed-certificates
And some places talks only about code (within the app):
TrailMax:
http://tech.trailmax.info/2014/02/implemnting-https-everywhere-in-asp-net-mvc-application/
So my question is how I need to approach this topic?
I want to enable the HTTPS with a temporary self-signed certificate and then buy a real certificate, what do I need to do? Configure IIS? Configure my code? Both?
If someone could guide me through this.
Thank you
The first article describes how to install a new rapidSSL certificate
The second describes how to install a self-signed certificate (not signed with any trusted certificate authority, mainly used for testing purposes) - you want to do this
The last article describes what to do if you want to restrict your mvc website only to https (http requests will ben not possible then). Steps 1 or 2 must be completed before you start to work on this. It depends on your requirements if you need to restrict your site only to https.
Related
My company is wanting to implement OpenID Connect via Oauth 2.0 across our client software, which comes in Windows, HTML5, Android, IOS, etc. Toward that end, we are trying to find a way of getting the login info back that will work across these platforms.
Our understanding was that a custom uri scheme (i.e., companyname://) was the recommended way of going forward, and we have verified on our end that that would work. However, we have yet to be able to find a provider that would support that configuration. So far OneLogin & Google are both locked to https:// (or http:// for dev), which leaves us something of a conundrum.
So essentially, my question is, were we misled about the custom uri scheme? If so, is there another method we can use that will allow our web & standalone apps to pick up the return info from whichever OpenID providers we go with? We want to keep it open as possible, so we're trying to avoid lock-in APIs and suchlike. Any advice would be appreciated. Thanks.
We do support the custom URI redirect. You'll need to select right type of client when creating a client id on Google developer console.
See the details here.
https://developers.google.com/identity/protocols/OAuth2InstalledApp
One way to support any provider is that you use a Web flow to redirect to a page on your site and then your website does a redirect to a custom scheme.
A project I am working on was once an internal intranet application, but now it is being ported over to a multi-tenant internet application. Usually, when deploying any web applications, we would use the format http://webapp.company.com which has existed long before I joined.
Since the project is now a multi tenant application, I am trying to decide between different architectures.
1) Using the client/tenant as part of the main host url
http://tenant.webapp.company.com
This approach requires additional ssl certificates and iis settings
2) Include the tenant as part of the routing and the tenant name will be included as a routing parameter
http://webapp.company.com/{tenant}/my/route/url/{param}
This approach, in my opinion, is 'messy' and I feel it is not the most-correct solution.
3) Keep the existing url of http://webapp.company.com and add specific bindings in IIS to point the requested url to the host location.
When the user enters the url http://tenant.company.com they will be served the application that resides at http://webapp.company.com The problem with this approach is that we may deploy additional applications and this is not scalable.
I am leaning towards approach number 1 as I have experience implementing it (without the extra domain). Is the 4th level domain ideal? Any ideas as to what approach is better than the other? Possibly a new approach? Any input is appreciated.
Using the client/tenant as part of the main host url
http://tenant.webapp.company.com
This approach requires additional ssl certificates and iis settings
Actually, you might be able to use a wildcard certificate for *.webapp.company.com, which would mean you can extend this scheme without additional IIS configuration.
In addition, this approach is the most elegant when it comes to routing. There is even a MVC-Subdomain-Routing project on GitHub that you can use for some direction (or as is if your requirements are met by the project).
Also see this question and this answer for some other approaches.
Since many website will calling service by Web API. In that case, those methods will be exposed for every one. How can I ensure only my web site can calling my Web API service?
One of the easiest way to secure it as a developer is to get the IT people to do it by limiting access down by IP address from site to site. You could also do this in the app by validating the incoming IP addreseses. Sometimes IP addresses change sometimes they don't. Whenever I have done this have used certificates as there is a trust on both sides of the data divide. Have a look at John Petersens article Making web api's secure it has a section on implementing IP security in your app as well as x509 certificates; complete with code examples that I wont reproduce here. You could try and secure it with SSL and create your own key / trust but its easier to maintain (imo) using x509. Perversely it was much easier in the web service world Microsoft had an API to do this much more simple in WSE extension..
I'm making a website that I'm planning on making readily deployable by users; they'll be able to take my source code and deploy it to their own server and run it as their own.
I was thinking of trying to incorporate SSL and OpenID and other features into the website. Would giving the users access to these files (such as my OpenID/Twitter/Facebook client key and secret, or the SSL certificate stuff, or whatever else..) be a potential security hazard or anything? Would they be able to do anything dangerous with this information?
SSL is not the app's concern
All client key and secret are your own responsibility... I wouldn't distribute them openly.
Normally what one does is to read this information from the environment
facebook_client_key = ENV["FACEBOOK_CLIENT_KEY"]
so the deployer has only to configure the environment, not the application.
I would steer clear of adding things like your clients keys and secrets to any files you distribute to your users. They're called secrets for a reason! I don't known the ins and outs of Facebook or Twitter's APIs but certainly with products such as Akismet, the anti-spam addon for Wordpress, the key is used to identify your particular Wordpress instance.
If you are using a Wordpress site for commerical purposes, you're supposed to pay for Akismet. The problem is that whilst you might not be using it yourself for commerical purposes, depending on what you're making and distributing that's not to say that other people won't use it for commerical purposes, and end up ruining it not just for you, but for everyone else using your software.
You should make the keys and secrets part of your application's configuration and, perhaps, provide instructions on how your users can obtain their own.
I have a Heroku e-commerce site I'm building, and have the Piggyback ssl installed by following the Heroku Piggyback tutorial. I'm planning to upgrade to SNI or host-name SSL after sales come in to support it.
I can't find any tutorials or examples of best way to handle where the SSL is integrated for the processing (just checkout I believe).
Are there any tutorials, or process workflows to setup a controller and view to abstract for handling the actual checkout experience, and redirecting confirmation or failure when using the piggyback ssl on Heroku? And keep in mind upgrading the system in the future for upgraded SSL (using SNI or Hostname SSL)?
The best explanation I found was from this question, but it wasn't a walk-through, tutorial, or real explanation explain how to solve the url creation for links on the Piggybacked url (appname.heroku.com). I was looking for more detail in implementation.
Piggyback SSL is identical to regular SSL, except for the fact that only heroku.com or herokuapp.com domains (dependant on your stack) are secured by the cert that you have setup for you.
In order to run a page securely, just run it over HTTPS.
However, with Rails you have the option of using the SSL_requirement plugin from DHH which lets you tell rails which controller actions MUST be handled securely, and which are fair game for HTTP. By using SSL requirement you can forget in your routing about SSL as SSL_requirement will take care of it for you.