I have an application for managing user data. All the business logic is encapsulated within a separate web api service, which the user management web application (among others) calls into. At the moment all web api calls are exposed (they are anonymous). However the web api sits on a separate domain and is only accessible to the applications that call into it.
Is there any benefit to adding bearer tokens and enforce authentication for each API call?
If the web api service is on a separate domain and adequately protected from the internet, then you dont need to authenticate at the service level for external security (over and above any application logins you have).
However, that is not to say that your application is not internally exposed and could be intentionally or accidentally called by malicious intent or an incorrectly configured application, for example, someone accidentally points a load test at production. For this reason I would secure it, at least with a HMAC if you dont want to implement full blown authentication.
EDITED: To add that with any public facing web real estate you should classify your data and decide the appropriate level of security to apply. In some circumstances you may not want to secure GETs of low sensitivity data. On the flip side, exposing GETs allows someone access to try denial of service attacks (by calling your API in a loop from multiple servers / a botnet). When it comes to POSTs, the risk is higher, since consumers will be inserting in to your datastore.
It's also always good to keep the OWASP Top 10 in mind when dealing with security.
Related
I need to push data from applications made in VB.net, Java, C#, C++, Node.js and other modern languages to our server. These applications are running in retail stores and our service is 3-party service. I am planning to offer REST API to push the data but my concern is how do I authenticate a single store.
One of the ways I thought was using the AWS way : AccessKey and Secret Key approach outlined here :
http://docs.aws.amazon.com/AmazonS3/latest/dev/S3_Authentication2.html
Each store can have multiple billing machines/computers --> so what will be a better approach to authenticate because the AWS way requires to paste the Keys from our interface to their local machine setups (At this point I am assuming our services will be directly called from the front end application rather than Back-End Servers.
I am confused how to go about approaching this problem - if the REST API Calls should be made from front-end or back-end services and if its front-end how do I go about authenticating the store.
To first answer
I am confused how to go about approaching this problem - if the REST
API Calls should be made from front-end or back-end services and if
its front-end how do I go about authenticating the store.
Since you say
I need to push data from applications made in VB.net, Java, C#, C++,
Node.js and other modern languages to our server.
To me it sounds like you want server (your customers) -> server (your REST API) communication.
Before getting into security options, you need to think about security-ness and time/resources.
Starting with security, if you're dealing with HIPAA, PII or other sensitive data, then definitely do more research.
Next, time/resources. A SaaS service like AuthRocket or Okta will make life much easier, however, it is a monthly expense. You can roll an open source library into your API, you'll just need to spend the time to develop, test and maintain (and deal with stuff like user registration, lost pws, etc).
And so now, authentication. ID/Token auth like Amazon is the most common way. Every REST request a customer issues will include their ID and token (eg ID=customer-123, Token=laksdjflaksjdf). To handle a customer w/multiple machines, you can issue n tokens, one for each machine. The customer would be responsible for putting the credentials on each machine. Again, this is the most common way to do things.
You can also use OAuth, but this doesn't make as much sense for your use case since its companies and not individuals (usually OAuth is for developer-oriented APIs).
There are also other various token based authentication approaches, but these are usually better suited for client->API requests (websites->APIs).
I am writing asp.net generic web handlers to provide service to a web application, but I don't want a phony application to use the web handlers. The purpose of using the web handlers is to conceal logic and data. But even though the logic and data is protected, someone can still use the handlers from outside the web application because it does not require authentication. How do I resolve this?
Edit: The proper client is a JavaScript application using ajax.
You first have to define "phony application".
If you are unable/unwilling to add authentication, you can consider physically isolating the service so that only legitimate applications can use it.
One solid method is to place the web service behind a firewall and configure access only for applications that should be able to reach it.
If the list of applications you need to have access to the application is small and/or local, you could encrypt the data returned (and data taken as parameters?) with some symmetric algorithm, and disclose the key to the other applications' developers. You could also generate a new key per application to hide data between apps using your service, but at this point you may as well just use normal authentication methods.
First of all, I took a look to every related topic on her about this issue. However non of them was successful in answering my question fully.
Currently I am working on a desktop app, coded in C#/wpf, that requires MySQL connection both for authentication and storing user custom lists etc.
However, the problem is that apparently allowing everyone to remotely connect to MySQL db is not good practice. Also, my current host requires IPs to be whitelisted before they can connect to the db.
What are my options on this?
Thank you in advance
You should look into creating a web service (SOAP), http web-api (REST) or some other middleware to abstract your data storage.
This has the benefits of:
Allows you to move much of the business logic out of your desktop app and into middle ware
Allows you to keep business logic out of sql which might be a bottleneck
Allows you to update your business logic without redistributing your desktop app (easier if you don't have direct control of all the desktops).
Allowing you to control authentication (many web servers have their own modules, method of authentication). Your app would control access and access storage under it's own service account.
Allows you to complete change your data storage (let's say in the future you store some in sql, some in mongodb, some in cloud storage - once again, without having to update all your desktops.
Allows you to scale out your front ends and even possibly scale out your backend storage (for example, read/write DB replicas)
If you're already working with C#, then the new MVC4 web-api should be a good fit. Read more here:
http://www.asp.net/web-api
If you go that route you could control access in your service and have your service access the database either via credentials in a connection string or if you use IIS, credentials on the application pool mapped to your site.
If you're shipping your desktop app (you're not hosting the DB) then you can also self host web-api in it's own exe if your customers don't want to install/manage IIS.
Finally, if your mysql is online, your middleware could be in the cloud (azure etc...)
Create a web service, such as with WCF or MVC Web API where your app can pass through their credentials and authenticate. I'd recommend https for transport security.
I am doing a rebuild of a website and I'm trying to use an SOA approach. The current website is in .NET 2.0 and uses the out of the box SqlMembershipProvider.
We're trying to eliminate direct connections to the database and push everything through a WCF service layer. The approach we're using for this is to have everything separated - There's a library for models and interfaces, a library for the services, and then a library for the service proxies.
The biggest hurdle so far is figuring out how to manage user authentication and their session. What's the best way to do this with this approach.
Should we scrap the .NET membership model and go with something like OpenId, and just allow users to reconnect their data to the new account?
I've done some searching and can't find a lot on how to manage this, though I know it's been done before.
Here's what I ended up doing, in case anyone is interested. I started off using the WCF Authentication Services, but then realized it didn't give me everything I wanted. I could log on and off, but will still have to create my own methods for registration and getting the MembershipUser.
So I went in my ServiceContracts library and create an interface I called IMembership. At first, I created it as a class and inherited from MembershipProvider so that I could get all the method stubs generated for me. Once they were generated I modified the stubs and made it into an interface.
Then I went into my Services Library and created the implementation for the interface which was simple, because for the implementation I just used Membership.Provider....
Then in my Service Provider Clients library, I did the usual implementing of the IMembership interface, also inheriting from ClientBase<>. Right next to it I created a WCFMembershipProvider, which implemented MembershipProvider, and called the methods from the MembershipClient I just created.
In my WebApp that host the WCF Services I set up my SQL Membership provider in the web.config, and then created my svc file and endpoints for the service.
In the consuming web app, I just added the service client reference to the svc, and then set up the Membership Provider for my WCFMembershipProvider.
And viola - I'm in business.
A lot of repetitive code, but it works nice.
The principal problem you will run into when trying to create a WCF service and maintain the equivalent of session state is that there are no cookies (since there is no browser to maintain them), so the .NET membership providers are not going to be terribly helpful by default. I know how I have handled the equivalent issue is to have a generated token (for instance, a Guid) correspond with the state information I need to maintain.
Your question, however, is more about authentication. I don't know that you would be able to make an OpenId implementation work through WCF (though I understand it works great for plain old ASPX). You could use just a simple username/password authentication scheme (possibly using the MembershipProvider manually, if you need it for dealing with the password encryption in the database), and you can pass the username and password through the service using (most likely) Transport security (SSL).
I hope this helps somewhat. Maybe someone has come up with a more standard session-state replacement for WCF, but I'm not aware of it if so.
Hard to provide a specific answer without knowing a little bit more about your desired setup.
Do you plan to expose your WCF service as a public accessible independent of your website? Will your web pages access your WCF service directly via AJAX?
The easiest scenario is probably a strict layered deployment UI talks only to Website, only website talks to WCF Service.
http://msdn.microsoft.com/en-us/library/ms731049.aspx is a good read on using the ASP.NET membership model with WCF.
I built a site that used AJAX to talk to the WCF service layer. We used the forms authentication provider with WCF. It worked fine except that there wasn't a graceful way to handle the login through a web service. In our case that was fine as we wanted to the user to go to the website and login by entering credentials.
If you have already invested in collecting user's credentials to work with SQLMembership provider, you could surface it via ADFS+claims based model. This would work with all 3 of the above scenarios. There is a bit of learning to do though
I am going to be creating a web service that will be passing confidential information across the network.
What would be the best way to secure the web service?
how do I know if the application requesting the information is who it says it is, and it's not another application that is using another's user name and password?
Use WCF for your web service! It has tons of security capabilities:
You can
secure your clients via Certificates - only those that have the appropriate certificate will be allowed to get their calls processed
secure your clients by looking them up in your internal Active Directory domain - only those with AD accounts will be allowed to get their requests processed
secure your clients with custom username/passwords which you can look up against anything you want (this is the most flexible, but also the most complicated option, and offer the most potential for failure if you get something wrong)
Plus, with WCF, you also have loads of options to secure the transport between client and service, or encrypt and sign the messages going back and forth.
See the WCF Developer Center as a great starting point for all things WCF.
If you're serious about safely and securely programming WCF services, grab a copy of the Programming WCF Services book by Juval Lowy - it's the bible for WCF.
I've done this once or twice in the past:
Use SSL
Write the webservice to require a token which is retrieved from a method on the webservice.
Have the token returned from a method which requires a login and password.
After a certain number of webservice requests, or at random intervals, change the token required, thus forcing a re-authentication.
If you want to, encrypt the data in the ssl stream, by using an encryption method which both parties understand. (if you're paranoid.)
You don't write which implementation technology you intent to use, so let me start by recommending that you use Windows Communication Foundation (WCF) instead of asmx web services.
With WCF you can select between many different bindings, many of which offer data protection. Overall, there are two different styles of data protection for web services:
Transport protection, where the transport mechanism itself offers protection in form of encryption. The best known version of this is HTTPS/SSL. However, note that unless you employ client certificates, the service has no guarantee that the client is what it says it is.
Message protection, where the message itself is encrypted and signed. Such messages can travel over otherwise unprotected networks and still be protected.
The WsHttpBinding offers message protection according to open standards. That's where I would start.
Have a look at WIF (aka Geneva framework). Its purpose is to solve the exact problem you describe.
http://msdn.microsoft.com/en-us/security/aa570351.aspx