I have a problem with a service I am writing.
We currently have a webapp that is hosted on an internal secure network.
There is now a requirement to provide a service which expose our web app business functionality for a client to consume in order to create a native tablet app.
The mobile device will use VPN to get onto the network. To access our webapp, the user would normally need to use a user name and password. ie. There is no SSL. The username and password is stored in our db in custom set up (no ASP membership, etc).
Now, I have raised the lack of SSL as an issue, but this has been shot down, and those in charge of such matters feel that the security needed to get into the internal network is enough.
I realise this means app is open to INTERNAL user malicious behaviour from those inside network but outside of app user group
SO, this now raises an issue when it comes to creating my service in WCF. Authentication without SSL appears to be quite fiddly. I did manage to find:
[Yaron Naveh's ClearUsernameBinding][1]
http://webservices20.blogspot.co.uk/2008/11/introducing-wcf-clearusernamebinding.html
I felt that this was about to solve all my problems until I realised that I would have to alter my plans to offer RESTful service with json, and I would now have to use SOAP.
Still, I was fine with this until I realised that SOAP had bandwidth issues due to the envelope that comes with the packet. This worries me, as it is a service which will be getting consumed by a mobile app over 3g, and there are bandwidth limits.
So, without SSL being an option (please don't say otherwise), do you think that using SOAP instead of REST here is the better option? Should I be concerned about the bandwidth? (rows counts returned will not be exceeding 200, and most will be MUCH smaller). Roughly how much of an overhead are we talking?
Is there an option with wcf REST config where I can authenticate without a certificate (using some form of custom authentication)? This would be preferable to me.
The performance comparison between REST and SOAP web services was discussed in detail in Rest vs. Soap. Has REST a better performance?.
You can certainly implement custom authentication in a WCF REST service, without certificates or a secure transport. One option is to use a binding similar to the following:
<bindings>
<webHttpBinding>
<binding name="default">
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Windows" proxyCredentialType="Windows"/>
</security>
</binding>
</webHttpBinding>
</bindings>
http://msdn.microsoft.com/en-us/library/bb924478(v=vs.110).aspx
Including the Microsoft caveat: “This mode does not provide message integrity and confidentiality. It provides HTTP-based client authentication. This mode should be used with caution. It should be used in environments where the transport security is being provided by other means (such as IPSec) and only client authentication is provided by the WCF infrastructure.”
The following link provide comprehensive overview of a custom WCF REST authentication solution:
http://www.codeproject.com/Articles/304877/WCF-REST-4-0-Authorization-with-Form-Based-Authent
The WSDL envelope is not in megabytes range. It needs a few kilobytes per request for normal configurations. Therefore, the possible bandwidth bottleneck depends heavily on the requests/time ratio.
You could always implement a custom authentication mechanism with tokens. The basic idea would be this...
When the user authenticates, he gets a token which expires after 20 minutes or so, if the user does not act in that time
The token is stored (encrypted) in a client side cookie
The cookie is used in each client's http request
The REST service examines the user's cookie, extracts the token and concludes if the user is authenticated or not
I would strongly suggest to follow the Membership API path. The logic that I describe is the one used by the Membership API. Implementing it on your own, would just be time overhead and a bug generator. I don't see why you have to reinvent the wheel...
Hope I helped!
Related
I built a wcf rest service with form authentication. All the settings are set in config file. This service needs to be consumed by android client. So can any body please tell me how to send the request with log in credential to the rest service which is implemented using forms authentication.
Note: I know by implementing custom login service method we can validate the client and pass the cookie for the wcf rest method to authenticate.
I am looking for different solution like in single request we pass the credentials it validates the user with membership and gives the response. Please let us know if u need any further information.
This is a very broad question, so it will be difficult to answer completely. For the WCF side, you can follow this: How to Consume WCF Service with Android. The idea is to return a token, or session, ID when the user successfully authenticates in the system, and each subsequent request uses this token to identify itself. That approach uses SOAP, but you can also use REST too, which REST may be easier to consume in an Android client (REST worked great for me).
See this post, Need advice on authentication for android client connecting to the WCF Rest setup, for more guidance on the setup too. When I setup my authentication mechanism, I did a lot of research online to figure out the best approach to take. A lot of people mentioned just use OAuth 2, and make sure you are using HTTPS communication. So if you can use OAuth or Facebook/Twitter/Google+ for authenticating, that would be a good approach and take a lot of the headaches away.
We have built a WCF service for an application and everything is working out well, using WSHttpBinding. We now have been asked to make sure the communication between the Web Application -> WCF -> Database is secure and have been asked to use SSL. Along with that they are requesting we make sure the WCF service can not be accessed by another application.
If we setup SSL, does that block others from trying to get in, or we do still need to setup the clientCredentialType setting on the service? Also the entire application (site, wcf, db) will be within a company's network, so if we setup the clientCredentialType="Windows" which account is used, how does WCF know to allow the website to talk to it, which Windows account are they using, or this an account we need to setup?
Thanks.
SSL has nothing to do with Authentication or Authorization.
It does 2 things:
prevents third parties from intercepting your traffic.
verifies that people are who they say they are.
The requirement "make sure the WCF service can not be accessed by another application" needs to be handled through some Authentication / Authorization mechanism. You could use Basic or Windows depending on your needs.
Since you're in the company's network, I'd attempt to use Windows Authentication. This will force clients to be authenticated through your domain, however it looks like you don't want just any domain user to have access. In this case, you need to set up either Role based authorization, or user based. Either war, you can drop a Web.config file into the same folder as the WCF service endpoint specifying what accounts are authorized. Other users will see a 401 Unauthorized.
This is the general approach I'd take.
I have a wcf service hosted in IIS. Currently this service is required to be accessed by only one internet facing application (Client A). Both client and server has proper production certificates installed. I have a feeling that I can use them identify each other as that's one of the purpose of certifcates but I am so confused with so many flair of configuration options available in WCF. What is the best and concise way of achieving it. A lot of solution seems to either rely on username/password way regardless of where the client appiication is or either just identify client by using
<message clientCredentialType="Certificate" />
However I am using clientCerdentialType = "UserName" in order to use username/password scheme of authentication and authorisation.
I looked at the similar question at How to configure a WCF service to only accept a single client identified by a x509 certificate but no luck.
I have Android app that talks to .net 2 webservice (IIS7) using http get and managed to make it run on https using self-signed server certificate (but not requiring client certificate).
I see all http traffic is encrypted and it looks secure.
Now what options would I have on how to authenticate client? For example, I like to block webservice access from internet explorer on PC.
Client-authenticated TLS handshake described here would be a way to go?
Then how can I accomplish that? Some advice or example will be appreciated.
Well, given that each user should authenticate anyhow, you probably want to setup some sort of per-user authentication strategy for a variety of reasons. First, given this might be a widely distributed app, having a single "gold master" authentication certificate or credentials will ultimately fail as someone will hack it -- either grabbing the cert or grabbing the account. And then what do you do? Second, its not particularly hard to handle. You can easily use ASP.NET membership to back it, and then take the credentials a number of ways depending on the nature of the service. Third, it is alot easier to manage than client certificates.
Something I can't wrap my head around is how secure web services are.
For example we're writing a desktop application that will interact with data on one of our websites as well as local data. This data is sensitive though and the last thing we want is anybody calling the web services.
I've not yet found anything that says web services has some kind of authentication methods and the only security I've seen people talk about is using certificates to encrypt the message.
I'm no guru on this and would appreciate anyone's input and perhaps a link to somewhere that will explain this in simple terms.
Thanks
Jacques
If you are using ASP.NET to create a response / request Service you have only 3 options
ASMX
WCF
Normal .NET pages (or handlers) to process requests
as you specify Services, you can choose between ASMX and WCF then (you can read the difference between ASMX and WCF in my answer here)
keep in mind this
ASMX is considered deprecated technology and replaced by WCF. So if you are going to start new development which requires exposing reusable services, WCF is the way to go.
This days, there is a common pattern when we need to secure Services, and that's using a session key.
The Service normally has a Method for Login where it gets a User and some kind of Password (normally hashed, salted, etc) and that returns a "ticket" that has a limit of time (slided or not - means per each call to a method the period get's reseted or not), and all calls need to have that ticket included in the message body.
Services API like Magento and others uses this.
Or having a pre generated key that is given to the user / application to be used with every call
Services API like Campaign Monitor and MailChimp and others uses this.
The other normal way is to have the user and other credential in the message header all the time.
Services API like SuperOffice CRM and others uses this.
None of this services uses SSL, as I would only use if I really needed to protected the data in the "wire" keeping in mind that SSL expands the response time on every call made.
I hope this helps
Authentication:
Consider securing your web services with SSL. Distribute client certificates to those who need to consume those web services. Configure IIS to "Require Client Certificates".
Authorization: Consider developing a scheme where the user is sending a username and password of some kind in the querystring. When you can determine that those credentials are permitted to perform the operation that they're requesting, you can allow them to proceed. Indeed, this is custom logic that the application developer needs to write. There are no built-in conventions in ASP.NET web service for this.
The SSL encryption occurs at a lower level from the application. It's the applications job to then determine who is allowed to perform what operations.
Our webservices are encrypted through SSL (the certificates part) which is https://www.yousite.com instead of http://www.yoursite.com. This just provides basic encryption for the data stream. See SSL.
They are also authenticated by the authentication method that is chosen for our website. If it's is windows auth, or forms auth. See the msdn page on ASP .NET authentication.
For XML Web-Services you should take into account the following best practices:
Secure the transport Layer: the infromation or data in XML cannot be interrupted and read in transit.
Mask internal resources: Use Network Addres Translation (NAT).
Implement XML filtering: With the heklp of XMLand SOAP, affective filtering policies can be set to a content level that requieres a fully parsed or processed XML document.
Validate, Transform, Sign and Timestamp al messages: Use XML Schemma Validation, use XSLT for transforming XML, sing all messages, use Network Time Protocool (NTP) for synchronizing all XML nodes to a single authoritative reference time source.
Encrypt message fields.
Implement secure auditing.
Use existing security methods such as HTTPS.
Perform XSL transformations on the server.
Source: EC-Council Secure Programmer.
To expound on previous answers: Web Services are as secure as you make them. In general, there are two types of security. Securing the Transmission, and securing the access. Use of SSL can make your transmission secure (). Using Authentication (demand a username and password) allows you to secure access.
Web Services accessed via public internet (that is: not a VPN or only internal resources) are, indeed, less secure than Windows applications, since anyone can have access to them and, potentially, attempt to break your security. By using both transmission and access security, you can mitigate that to acceptable levels (acceptable to the point that banks use them for financial transactions, and you don't know paranoid until you've talked to a banker who has to face an FDIC inspection).
All web applications are exposed to the attacker and are a great surface area for attack. The biggest problem with web services, such as SOAP(WCF) is that often times the programmer doesn't realize that its trivial for an attacker to gain full access to the service. Often times programmers expose nasty functionally like execute_sql_query().
You should read the entire OWASP top 10.
Here's a primer on Securing XML Web Services Created using ASP.NET.