I have been trying to encrypt soap message and send to the server, so that the server can decrypt, process the message, encrypt the response again and send back to the client...
I short i want to implement security in ASMX web services....
Please help me
Thanks
Sandeep
What's wrong with using HTTPS?
https and soap extensions are good solutions; you can always 'roll your own' by encryting the inputs and outputs directly
[WebMethod]
public string SecureMethodX(string secureInput)
{
string plainText = decrypt(secureInput);
//do something...
string encryptedResult = encrypt(someResult);
return encryptedResult;
}
this becomes a pain if you have several methods, but if you have a specific one-off need (such as passing hardware fingerprints and/or license keys between client and server) then this solution is probably the simplest to implement
Take a look at SOAP extensions. They allow you to monkey with the SOAP stream on both the client and server. They're nice because you can leave your service code alone - manipulation occurs before a webmethod begins and after it ends. They work a lot like an HttpModule but can be included on the client/request side as well.
http://msdn.microsoft.com/en-us/library/system.web.services.protocols.soapextension.aspx
http://msdn.microsoft.com/en-us/magazine/cc164007.aspx
http://www.theserverside.net/tt/articles/showarticle.tss?id=SOAPExtensions
HTTPS is a standard for encrypting web services. I use this for encrypting a web service.
Related
I will be happy to get advice from more experienced developers about adding Web Sockets into my HTTP-based project.
That’s the thing. I have developed the REST API based service. Everything works well enough, but… In some special cases my server needs a long time to serve client requests. It may be from 1 minute to several hours (and even days)! I implement some not-so-good algorithm to address this issue:
Client sends HTTP request
Server replies about registering request
Client starts sending HTTP requests to get necessary data (if response does not have needed information the client sends another request and so on)
That is all in a nutshell.
And it seems to be a bad scenario and I am trying to integrate web sockets for adding duplex-channels in this architecture. I hope that my API will be able to send info about updated data as soon as possible without the necessity of many requests from the client.
But I am a bit confused in choosing one of two ways to use web socket (WS).
Variant A.
The server only tells the client via WS that data is ready. And the client gets data by standard request-response HTTP method from REST API.
Variant B.
The server sends all data to the client via WS without HTTP at all.
What variant is more suitable? Or maybe some other variants?
I do not want to remove HTTP at all. I just try to implement WS for a particular kind of end-points.
Variant A would be more suitable and easy to implement. You can send message to the client after the data is ready, and he can then send request for the data. It will be like a simple chat websocket, and will serve your purpose.
I have a SOAP webserver developed in Delphi XE2 that exposes some methods and it uses SSL. I built my client also in Delphi XE2, and I use THTTPRIO to connect to webserver. My question is related to the use of SSL certificatest with THTTPRIO. If I call my webservice it works without having a certificate installed, but I think that it shouldn't.
Second scenario :I have a self signed certificate which I installed it and after I made a call to my webservice it works also.
When I inspected my events: HTTPRIOAfterExecute and HTTPRIOBeforeExecute, I converted SoapRequest and SOAPResponse to string from TStream and seems that it isn't encrypted in both cases. I also found on another forum the same question but with no response.
I searched for info about SOAP SSL Clients with Delphi but couldn't find any new info. Could any of you guys give me some advices regarding this issue?
If I call my webservice it works without having a certificate
installed, but I think that it shouldn't.
Not many web services require client certificates (with exceptions like banking and other high risk environments). It is more common that clients want to verify the server identity, and this is done with server certificates.
So I would say this web service does work in a normal, expected way.
HTTPRIOAfterExecute and HTTPRIOBeforeExecute, I converted SoapRequest
and SOAPResponse to string from TStream and seems that it isn't
encrypted in both cases
This is correct, the message payload will appear unencrypted because SSL / TLS does encryption on the transport layer. Your application will not see the encrypted data, which actually makes things easier.
You can add encryption for the message payload, there are generic libraries for this (however I have no experience with using encryption HTTPRio).
So, i have made a thrift based program with a client and a server and client can communicate well with server. Now, since the data transfer will be quite crucial, I wanted some kind of security in it.
So, I thought of login system, but the problem is I am not storing any kind of session data on server side(I don't even know, what should i store, after all the client request come and go and there is no way to differentiate them). So after much thinking, this is what i came up with
Using random numbers, i would generate some kind of random string when the server starts
Client side will enter the username and password which will be verified at the server end using PAM authentiation(just read something about it).
If verified, server will just send that random generated string to the client side
Client will send that string to server every time it tries to execute a RPC
If verified, server will do the work, else return some error code
Possible problem that i can think of
Currently, when server goes down, and client was in midst of some RPC, it would give some error message and when server restarts, we can do the task without any problem
Now, if the server goes down, then the string generated will be different. So i will again have to do the authentication part
So, what do you think of this entire schema for authentication? Are there any better or simpler way?
P.S : I am not using any kind of database. I am using C++ on both sides. My Client side uses QT
Disclaimer - I do not have much idea as to how PAM works, so I only have some high-level questions about this approach. I apologize in advance if I misunderstood any part of your approach.
When you say you want to secure the data transfer, I feel like you want to have authentication and secrecy, you only have an approach for authentication now.
For instance, if client C1 is authenticating to server(assuming credentials are not sent in cleartext), the server sends the random string in step 3. What happens when someone else is sniffing on the network? Can a rogue client not send the random string and perform RPC calls to the server, posing as C1? If username and password are sent to server in cleartext, can someone on the network get access to the credentials also? Also, what about data that is subsequently sent? It is just encoded in thrift format and can be decoded by anyone on the network, correct? Is the data sensitive?
If so, I want to suggest the use of PKI/certificates. Using a self-signed certificate must be fine. If you only want the client to authenticate to the server and prove it is legitimate, you can make all the clients present their certificate. Certificate is basically a public key for that client signed by an authority that vouches for that client.The client has the private key stored locally, that will never leave the client. Now, when client presents the certificate to server, server looks at who signed the certificate(CA). If it is a CA the server trusts, it can send the random string or just the thrift data directly, encrypted using the client's public key. The client will be able to decrypt with its private key and it looks like random bytes to anyone else who is sniffing. The server will do this for every single client and only needs to store the name of the certifying authority it trusts. This could be your name and address. You can generate the self-signed certificate on every client using openssl. But this means you have additional setup work on each client. Generate a key-pair and certificate. You can explore this approach if this constraint works for you.
I want to send an XML file to a Web Service.
The Web Service is a java application.
I know the endpoint of the Web Service.
Typically I know I have to create the request and send it as an http/https request.
What I want to know is what would I have to make to send the request - as in what development tool could I use e.g. Visual Web Developer (preffered as I am familiar with this) or Visual Studio? And what sends the request - e.g. another Web Service, a Website etc?
Where do I even begin with this?
Any comments are much appreciated.
Where do I even begin with this?
One purpose of a Webservice is loose coupling. So it depends on what you want to do. You can write a simple program in what ever language which constructs a request and sends it. You can write a Webservice on its own which uses the other Webservice to handle it's own requests.
You can handle this in a very simple or complex way. You only need to be able to generate a request (per xml) and send it.
I'm looking to add a web services interface to an existing server application. The set of services to expose is not known at compile time and can change over the runtime life of the server.
From a tech standpoint all the server/web services endpoints will be on Windows.
In our server app a user will have the option to register workflows as 'web services callable'. This will create the WSDL defining this particular workflow service.
For the calling endpoint I'm thinking of an HttpModule that accepts the inbound web service request, unpacks the request and converts the XML data types into our server applications "domain", calls the server and finally converts the server outputs back into XML for return down the http connection.
Does that make sense?
Critical comments welcomed.
In effect writing your own WS engine. Clearly doable, but quite a bit of work to get right from scratch. I guess if you find some open source implementation, then adapting it should be possible.
A rather dirtier alternative, but one I've seen applied in another context, is to go for a simgle WS interface
String call( String workkFlowName, String payload)
The payload and response are both Strings containing any XML. So the caller needs to undestand the schemas for those XMLs. From the client's perspective the amount of coding effort is not much different. Your coding effort would I think be significantly redcued.
an HttpModule that accepts the inbound
web service request, unpacks the
request and converts the XML data
types into our server applications
"domain", calls the server and finally
converts the server outputs back into
XML for return down the http
connection.
That is what all web service frameworks do (e.g. Metro, Axis). So I can't see your problem. What's your concern with this approach?
The downside for the client is that, as far as I understand it, availability of your services may change over time. So you should consider a way to inform the client if the service is available (other than getting a time out error because it is not there), e.g. WS-ResourceLifetime or UUDI.
I ended up creating a C# class that implements the IHttpHandler interface. The implementation serves up the WSDL of the services exposed from our app and accepts SOAP posts to invoke the services. In the end most of the work went on converting SOAP types to our types and vice versa.