(under asp.net enviro)
I will be sending data to a central server via a web service, and I want to hash the data to ensure that it didn't get corrupted during transfer.
Which hash method should I use?
Can I hash when the web service is passing objects?
I would recommend using WCF is you have a situation where you might actually have a heavier traffic while requiring reliable transmission. It supports standard SOAP, Binary, etc.
It got all the bells and whistle you will need.
Cheers
Preferably use SHA1. You can also use MD5.
You could also use Web Services Enhancements (WSE) 3.0 to sign your messages. The nice thing is that everything is built right in, so you won't have to do a whole ton of work.
There's a wide variety of turn-key security options, but it sounds like you would be the most interested in the AnonymousOverCertificate solution. For your implementation, you could define a couple of really simple policy files.
Bear in mind you'll need to use WSE 3.0 on both sides, though. (Client and server sides, that is.)
For more information, check out the link below. It gives a general overview of WSE 3.0.
What's New in Web Services Enhancements (WSE) 3.0
I'd recommend just calling GetHashcode() on the byte array of your data. Send this value as part of the webservice call and verify that they match on the other side.
Related
My case is that I want to make the data protected even from people who have access to the back-end (the keys store), so they couldn't read it without the user's (represented by the client app, in my case the browser) assistance.
One option is to have the decryption keys stored on the client and passed with each request which sounds pretty messy to me and i'm not sure I want my keys to wander around the net like this. What I imagine though is that the client will keep some token (it might be a password the user knows) and the decryption can't happen without it.
I thought about using the purpose string for this, I have the feeling it is not a good idea since its main purpose is isolation. On the other hand it is part of the additional authenticated data used for subkey derivation. (based on this article https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/implementation/subkeyderivation?view=aspnetcore-2.1#additional-authenticated-data-and-subkey-derivation).
I came across some examples that create their own symmetric encryption with a lower level classes. (like this post Encrypt and decrypt a string in C#?). Since I'm not an expert in this area I would like to use as much build in classes as possible.
What is the recommended way to achieve what I need with the classes from the Data Protection API? (I'm using .net core 1.1 on Ubuntu)
I have some internal-facing ASP.NET web services that have had numerous API additions over the years. Some of the original web methods, while still available for consumption, have recommended replacements available. I would like to steer consuming clients toward using these new methods so I can retire and eventually remove their elders.
If this were a client API rather than a web service API, I'd just mark the offending methods with the obsolete attribute. But .NET attributes do not get serialized and are not visible to consuming developers when they add or refresh web references.
What techniques are recomended for obsoleting ASP.NET web methods? Is there anything built into the tooling (VS2005-2010)? I don't want to break any of the existing clients, so I can't simply remove the web methods outright or change their internal behavior to reprot their usage as erroneous.
Tim, the short answer to this is unfortunately that you have to contact those clients and communicate the change with them and agree on timelines etc. There might be something that you can do to smooth the process over for them, particularly if they are not IT savvy clients and had to get their applications built by external contractors.
You can butter this up any way you like for them really, from the system is going to be replaced, to we are doing it bigger, better and faster.
Additionally you can build in code to slow them down, NOT RECOMMENDED, but then when they inquire you can give them the, we don't support that system any longer, it has been replaced by system 'X'.
If the new methods you are talking about are still just web-methods, you can just point the old ones to the new ones, and let the clients use the old one.
Another option is to identify the clients stuck on the old methods, get their IP addresses and lock it down so only they can use it, this way you ensure new clients will not attempt to connect to the old methods.
Other than that, I cannot think of anything that will not be a pain or difficult for both yo and the client.
I have a small RIA that I built as a learning/make-my-life-easier project that uses Flex and ASP.Net. Currently, my architecture utilizes straight HTTP posts and the server responds with xml. I posted another question about security in my web app and some people mentioned SOAP. SOAP is something I've never actually used and I was wondering what the pros/cons were to using SOAP over my current architecture and then subsequently, how much work is require to convert such an application to utilize SOAP.
Thanks,
Chris
Since you have already implemented your own message schemas for sending and receiving, then SOAP in of itself will not give you any added value. The added value comes from SOAP's support for the WS-* standards, covering security, transactions, and several other goodies. The recommended way to take advantage of all that is to use WCF rather than ASP.NET, because WCF supports the latest versions of those standards.
FYI when trying to use SOAP with FLEX - XMLDecoder in Flex does not currently decode some complex data types appropriately, making it appear that you are not receiving all data. I have tracked the error down to the XMLDecoder where I can see the correct data is received, but is not appropriately packaged in the ResultEvent requiring me to override the XMLDecoder, which, I am sure you can imagine, is not very fun. Just wanted to put in my 2 cents. If you are thinking of moving in that direction it would probably be nice to know it doesn't always work for very complicated data types (in my example a collection of objects containing 2 strings and 2 arrays - only returns a collection of 1 string). Granted, it does work 99% of the time, but not always.
I'm implementing a high traffic client web application that uses a lot of REST API's for its data access layer from the cloud database. I said client because it implements REST and not provides it.
REST APIs are implemented server side as well as client side and I need to figure out a good solution for caching. The application is running on a web farm so it I'm leaning toward a distributed caching like memcached. This caching solution will need to be like a proxy layer between my application and REST APIs and support both client side as well as server side.
For example if I make a call to update a record I would update through REST and I'd like to keep updated record in the cache so next calls to that record won't need extra call to the outside REST services.
I want to minimize REST calls as much as possible and would need to keep the data accurate as much as I can, but it doesn't need to be 100% accurate.
What is the best solution for this caching proxy? Is it a standalone application that runs on one of the servers with local cache, or built into current solution using distributed caching? what are you ideas, suggestion or concerns
Thank you,
You hit the nail on the head. You need a caching layer that acts as a proxy to your data.
I suggest that you create a layer that abstracts the concept of the cloud a way a bit. Your client shouldn't care where the data comes from. I would create a repository layer that communicates with the cloud and all other data. Then you can put a service layer on top of that that your client would actually call into. Inside this service layer is where you would implement things like your caching layer.
I used to always suggest using MemCached or MemCached Win32 depending on your environment. MemCached win32 works really well if you are in a windows world! Look to the Enyim client for MemCached win32...it is the least problematic of all the other ports.
If you are open to it though and you are in a .net world then you might try Velocity. MS finally got the clue that there was a hole in their caching framework in that they needed to support the farm concept. Velocity last time I checked is not out of beta yet...but still worth a look.
I generally suggest using the repository and service layer concepts from day one...even though you don't need it. The flexibility it provides for your application is worth having as you never know which direction your application will need to be pulled in. Needing to scale is usually the best reason to need this flexibility. But usually when you need to scale you need to scale now and refactoring in a repository layer and services layer while not impossible is usually semi-complex to do down the road.
When I talk to an developer from the Microsoft ASP.NET world and he uses the word "Webservice", does that word in every case imply a specific data format (XML? SOAP?)?
Or is it just anything you can call via http(s)?
In my view, it can be anything that's over http/https, and intended for calling by an application rather than a user's browser.
In particular, REST and SOAP are quite different about how they pass arguments in and get results back
The term Webservice itself is language-agnostic.
This is a decent overview.
If an Asp.Net developer says WebService, you can pretty much bet that they are talking about XML/SOAP.
However this is not universally true. I think it's just fine to call anything a WebService if 1) the data source is available via the web or 2) it is a web address that can provide back information given a set of inputs.
For example, StackOverflow.com allows for screen scraping of the User pages in order for 3rd party applications to be built. It's not specifically XML/SOAP but I would consider it a Web Service (format #1)
In my experience this completly depends upon who you are talking to. For some ASP.Net developers this is only SOAP for others it includes other things like REST. If you are planning on using the term in a specification it would be a good idea to be a bit more specific.
I can only agree with Paul, anything queried over the web, using the http(s) protocol and not browser oriented. But any web service should also have the functionality of being discovered (WDSL and so on).
Personally I mean any HTTPHandler!
That means under ASP.NET, a page is a webservice that returns HTML.
WCF extends that concept, because by default, WCF service requests in ASP.NET are processed by Modules not Handlers.
So really any web request is a service.
Typically though ASP.NET developers will be refering to SOAP unless they prefix i.e. WCF Webservices,