How can I sign data with standard .net crypto providers on client side?
If it's on the client side it probably won't be ASP.NET, you'll be using JavaScript (unless you maybe do it in Silverlight).
So that's your answer; use Silverlight if you wish to use ASP.NET, or use JavaScript otherwise.
Related
There is a ready azure microservices that I need to build a client app against. There are 2 choices blazor server side and client side. Because the client side is not ready yet and has limited debugging capabilities I want to use blazor server side.
My question is if calling services from blazor server side is possible and if it is a good idea. To use it as a client app?
And also if it is possible to host blazor next to the microservices in azure?
I believe what you are asking is if it's acceptable to use the Blazor server side as a proxy to a microservice?
Technically, there's no reason that you couldn't. You would simply create an HttpClient to call your Microservice assuming that it exposes a REST API.
I'm not sure what you mean by, "..if it is possible to host blazor next to microservices in azure?" If you're using an Azure Web App to host your microservice, you would probably want to create a new Web App for your blazor server side app, otherwise you aren't really getting the benefit from the app service.
There are other options for configuring this type of architecture, but it all depends on your goals. Additionally, you might want to check out the following project:
https://github.com/Suchiman/BlazorDualMode
It will let you run blazor client and server side together. I've used it to help debug client side blazor apps.
I have been evaluating and working on a prototype where I have exposed couple of API using WCF web service. My service is working as expected with managed client in windows platform. My service client can be on any platform. I dont know how to approach for other platform (UNIX). Couple of options I have considered so far -
GSOAP
MONO dotnet
I could not use any one of these due to some constraints. Now the only option I left out to implement my own client which can send soap request and get soap response. My preferred technology is C/C++. I am using wsHttpBinding in my server and will be working on http protocol only.
I am not sure about the following points-
Do I need to implement my own WSDL parser?
Do I need my own serializer?
How could I make my client more flexible so that any changes in my WSDL make minimal code changes on client side?
I am looking for help from the experts who could guide me with a proper approach with a basic client sample.
My experience is in WCF interoperability with Java clients. You can use Java SOAP libraries like metro http://metro.java.net/ or axis http://axis.apache.org/axis2/java/core/index.html . There is even a C library for axis. http://axis.apache.org/axis2/c/core/
I am sure other languages like Ruby/Python etc has similar libraries as well.
The other option is to use a REST based interface and then you can use any language/platform that has HTTP support or even a tool like curl and libcurl http://curl.haxx.se/.
I have a web site that needs data to be pushed to it. Unfortunately, I'm not aware of any other methods besides using HTML 5 WebSockets (I can't garauntee my clients will have HTML5 browers) and Comet (I'm not using java/tomcat).
I am not a big fan of using server-side ASP.NET for this particular project, and would prefer to use ASP.NET MVC or something like it. Is it possible to tie JavaScript in with a duplex service?
Well actually you can leverage the pollingduplex binding used for silverlight clients in javascript. There is an interesting blog post on this by tomek over here: http://tomasz.janczuk.org/2009/07/pubsub-sample-using-http-polling-duplex.html
We currently have a half a dozen of project which originally have been built using .NET Framework 1.1 and WSE 2.0. But Microsoft's support for WSE is lacking and the latest version of it (3.0) only targets .NET Framework 2.0. Our new projects will use .NET Framework 3.5 and instead of hacking our self a WSE-support, we are currently looking for alternative approaches.
Our current projects use WSE to digitally sign the SOAP-messages with a X.509 certificate. This is what we require also for our future projects.
It seems that going with the WCF-route seems to be the smart choice but is there any alternatives? WCF seems to support X.509 certifications but we are little worried of its support for other platforms than .NET. Our clients need to be able to use Java-based software to connect to out services. And they've stated that it should be as easy as it has been before (when we were using Web Services). So WCF must be configured to use HTTP and SOAP.
Given the requirements of X.509, cross-platform interoperability and ease of use (HTTP & SOAP), is Windows Communication Foundation the right solution?
Yes WCF is the solution - it is API for building Web services and it is interoperable if you don't use MS/.NET specific features. But you should be aware that sometimes there are some problems with porting WSE services to WCF. I recommend to build very simple service in WSE (like Hello World) and secure it with certificates in the same way as real services. Then create Jave client to consume the service. After that replace WSE service with WCF. It will be your proof of concept. In a case of problems you can easily share this solution here or on MSDN to get some help.
I have an application that uses Silverlight and ASP.NET as a front-end. It retrieves data from the server by calling some RESTful WCF services that are hosted there. I'd like to prevent the curious user from opening up a new browser window and calling the web service themselves. Is there a way to restrict access to the web services to a specific application?
Thanks!
You can use HTTPS to secure the endpoint and require authentication. You can put an obnoxiously long secret key embedded in the code. Unfortunately, System.Security.Cryptography is not in the SL install, so no encrypt on server/decrypt on client capabilities. And there's no reason the user couldn't just use something like reflector to read the code anyway.
SL can be made "mostly securish", but definitely not secure.
Here's the guide of the Patterns & Practices team for WCF Security. There's a lot to be found there.
http://www.codeplex.com/WCFSecurityGuide
If you're truly interested in securing your web services, you should think about migrating from RESTful services to SOAP Based Web Services and implementing the WS-Security standard for Message based Encryption.
You can then secure your services so only clients that have the proper security information (be in username/password or X.509 certs) can call your web services.
Update
As you can see...I've removed X.509 as an option. I blanked for a moment and forgot the WS-Security limitations in Silverlight. The good news is that you can implement username tokens based on the WS-Security standard in Silverlight:
Implementing Username Password & WS-Security with Silverlight
No there's not.