I have a silverlight application that uses wcf service. This application is shown from a link in an existing project of asp.net web application type. There is a userid session found in the project that i want to transfer it to the silverlight application. I thought of query string but its not a secure thing to do it. so is there a way to transfer the asp session object to the wcf application which the silverlight application communicate with?
You could write a web service that you could use in Silverlight and with which you could get and set single values from and to the current session.
If you want to transfer the whole session to Silverlight, this is of course also possible by a query parameter or the like.
Concerning security, it depends on your scenario. There is no way around that, you do have to send the data over the wire to the client in some way. You can encrypt it, but the Silverlight client will have to know how to decrypt it. Silverlight client code can of course always be inspected in reflector by anyone who has access to the application.
What you can do is set everything up to use SSL for communication, it might be sufficient for your scenario if you never send more information to a client than a client is allowed to know.
If you can run WCF services in ASP.Net compatibility mode then you would be able to share all of the ASP.Net Runtime Objects such as Session, Cache etc.
Related
I know this question can be too generic but for purposes of narrowing the question, here is a brief description:
I'm planning to forget about ASP.net UpdatePanel and move to use ajax via JQuery. I am afraid that because of the plain, client-side nature of JavaScript (and consequently JQuery code), any one looking to my web page's source can realize what is the URL of the web services I'm calling and also what are being passed to those web services.
When using UpdatePanel for these types of operations, I'm sure that calling web services is done on server-side and I have no concern regarding issues of information on calling sensitive web services being exposed publicly but now that I'm planning to use Ajax via JQuery, It worries me alot.
Are my concerns reasonable and if true, what are the best solutions for avoiding the threats of web-service-calling-info being exposed?
Clarification: when saying UpdatePanel, I mean utilizing a chain of techiques including ASP.net AJAX, code-behind and relying on server-side Dlls for performing async server-side operations instead of jquery Ajax which requires web services for intracting with server.
There is no way on the internet to protect your web services all the time by just hiding the URL. I am not sure when you say your updatepanel does the web service call from the server you are not taking the true power of AJAX.
One way to secure your web service is to use the authentication in the web service side. For example you need to send some authentication key every time you access the source, and this is very common, you have so many public web service who protects it self using auth key like OpenId implementation. In case you do not want to change the web service logic I think jquery way of AJAX is not a secure option.
Here's a thought, you can have two levels of web service, one which will open for all that you can use in the jquery. From the current web service, from the server side call the other secure web service. Even now you can configure your incoming request for some specific machine IP.
In this case other than your own server no body else can access to the web service securely kept behind the firewall. It is something similar we do while connecting to database server from application server.
Let me know if this helps.
I'm going to state the problems my answer is hoping to solve:
Assuming you host your services on a machine other than the web server, the problem is you give potential attackers the name/address of those machines.
Attackers can write scripts/bots to scrape your data.
Attackers can focus on your web services and try to hack them/gain access to your network.
Attackers can try to perform a DoS/DDoS on your web services.
The solution I've used in the past is to create a light weight proxy on the web server such that all AJAX calls simply point back to the current domain. Then when a call comes in, it is simply routed to the appropriate web service, which is hosted somewhere internally on the network.
It creates one additional hop on the network, but it also has these benefits:
It hides the actual IP of the machine hosting your services.
You can easily lock down that one web server and monitor unusual activity. If you see a spike in activity, you can potentially shut down the web services. (If you use a different machine, you'd have to monitor two boxes. Not a huge problem, but easier to monitor just one.)
You can easily put a distributed caching layer in the proxy. This protects you from load/denial of service (DoS) attacks and obviously supports normal web service traffic.
You can hide the authentication at the proxy level. The public calls won't betray your authentication scheme. Otherwise an attacker can see what tokens or keys or secrets or whatever that you use. Making a proxy on the web server hides that information. The data will still flow through, but again you can monitor it.
The real benefit in my opinion is that it reduces the surface area of your application which narrows what an attacker can do.
Since you refer to ASP.Net, know its viewstate can easily be decrypted. There's no failproof ways to protect your code (not to say urls called).
If you're web services are called with some parameters that could allow unrestricted and dangerous actions, then you'd better start using some users/roles/rights management.
If you're worried about "man in the middle" attacks, you best option is to use https.
Wondering about how to do the following efficiently, securely, and in a fashion that won't have us tearing our hair out because of overcomplication: we have an ASP.Net site that uses forms authentication and would like to implement some WCF restful web services that can be called from the first site, provided the user calling them has been authenticated.
We'd like to host the WCF RESTful service in a different web site from the ASP.Net site. Both sites will be in the same domain (my-domain.com for instance).
I've been reading up on the various bindings in WCF and am not sure if webHttpBindings are the way to go here (they being the most REST-friendly, but can they accommodate forms-authenticated users?)
I'm looking for suggestions and references as much as code, but I'd love to know where to start and what to look for, what's possible and what isn't.
Every time I read about WCF authentication it seems to inevitably sluice into discussions about WS-security and X509 certificates, and I don't know that I need all that for what I'm doing? What I'm really looking to build is a series of WCF restful services that only respond to forms-authenticated users. If that's not possible without diving deep into WS-Security and X509 then so be it, but I'd like to keep it as simple as possible.
Note: I asked a somewhat similar question about a month ago, but have decided to go with forms authentication.
If you are not calling your WCF services from the browser, then you don't even need to secure them. Just call them from your ASPX code to a non-public site that hosts WCF. Or use X509 certs in a server-to-server mode.
If you do plan to call them from the browser, then things get more complicated. In this case, you may want to ditch WCF and look at with Web API included in the MVC 4 beta release to build your REST services.
http://www.asp.net/web-api
Have your javascript generated from the code behind. If Page.User.IsAuthenticated, render the ajax script. If not, render javascript that alerts the user that they need to be logged in. If you don't want the user cutting the javascript out of the browser source and running it later, when they are not authenticated, you will need to generate a token based on the session ID, that can be passed between the site and the service.
I have an ASP.NET web service that I can access via a windows program but now I want to secure the web service. I can secure the web service using forms authentication. How do you access the secured web service from a windows forms application?
Although this is not the right approach, tt is theoretically possible to use forms authentication in the manner you describe. This could be accomplished by either:
Using a WebRequest to send your requests in raw form to the web service. This will involve inspecting the response, extracting the relevant forms-authentication fields, and sending a response back which logs the user in. This will generate a cookie which you must send along with each subsequent response to the service
Generate the FormsAuhentication authentication cookie yourself. This is complex as it involves synchronising the machine key on the calling application, and artificially manipulating the headers being sent to the machine hosting the service.
Display the forms-authentication form for the user to log in to at the beginning of a session requiring interaction with the web-service. You can then harvest the generated cookie and present it to the service in HTTP headers as in option (2).
As you can see, these methods are highly complex, and are fundamentally a hack to use forms-authentication where it was never intended.
Microsoft intended us to use either Windows authentication, or SSL certs to secure access to ASP.NET web services. See HTTP Security and ASP.NET Web Services on MSDN.
If you are able to use WCF, then a few more options present themselves, including the ability to build a custom authentication mechanism into the SOAP, with some support from WCF.
For the most part, securing web services is one of the trickiest parts of the job. Many live solutions which I have seen are compromises such as the ones above.
It seems the answer is no. Forms authentication is a cookie-based mechanism, and your WinForms app won't be able to hold and relay the cookies (without some serious workarounds, if at all).
A potential workaround that I wrote up when researching your question attempted to use a NetworkCredential object, but that didn't work. Also tried was the ClientCredentials in .NET 4.0.
var ss = new MySecureWebService.MyServiceSoapClient();
ss.ClientCredentials.UserName.UserName = "abc";
ss.ClientCredentials.UserName.Password = "123";
string asmxReturn = ss.HelloWorld(); //exception returned here
The console app was still presented with the login html page when calling the webmethod.
Other Suggestions
If you have the source to your web service, extract its logic out into an assembly of its own. Reference that assembly in your WinForms app, and it's just as if you're calling the web service.
I understand that your goal is to reuse the app that's deployed, but the next best thing would be to use the same logic/implementation via .dll reference.
This might help: http://dotnetslackers.com/articles/aspnet/Securing-ASP-Net-Web-Services-with-Forms-Authentication.aspx.
I am in the process of building an application where clients (WPF) will be calling a web service to send data.
These clients will have different roles: Employees, Managers, etc. and each client needs to send their username/password when calling the web service for authentication.
Can I use the ASP.NET membership provider for authentication/authorization in a class library that is wrapped by web services?
Or this API should be used "only" in Asp.NET applications?
what other options do I have?
I have written command line tools to do maintenance on ASP.NET membership databases without any problem, so at a basic level there's no problem with non-ASP.NET applications calling into the ASP.NET membership methods.
Since you'd be doing without the ASP.NET controls that automate most of the membership handling, you'd have to write your own code to check passwords and roles. The following methods will probably help do this:
SqlMembershipProvider.FindUsersByName
SqlMembershipProvider.GetPassword (for this to work you must configure the membership provider to store encrypted passwords instead of hashed password)
SqlRoleProvider.IsUserInRole
So I think it's possible to make it all work. BUT there's no promise that at some point there won't be an awkward obstacle that will stop this working outside of ASP.NET, so prototype it first before committing a big project!
We can successfully consume a .NET 2.0 web service from a Flex/AS3 application. Aside from SSL, how else can we make the security more robust (i.e., authentication)?
You can leverage ASP.Net's built in session management by decorating your webmethods with
<EnableSession()>
Then, inside your method, you can check that the user still has a valid session.
If you're talking about securing the information going over the wire, you can use Web Service Extensions (WSE) to encrypt the body of the soap message so that you don't have to secure the channel. This way the message can get passed around from more than one endpoint (ie. it can get forwarded) and you don't need multiple https certs.
If you're talking abut autentication then you could do forms auth with either a password in the body or in the soap headers (once again either encrypt the body or the channel). Or one of the easiest ways to secure a webservice (if it's an internal set of services) is have IIS do it, turn on NTLM and do authentication there. You can do authorization later on in the pipeline with an HTTPModule that checks peoples credential against the code they're trying to call.
Consider using WebOrb to communicate with your service. Here is some information on WebOrb's authentication mecahnism. There is also an article on Adobe's developer site on using WebOrb and .Net for authentication.
You should be able to use asp.net's authentication (such as forms authentication) without much extra effort. Securing an asmx file is just like securing an aspx file. There's a ton of information on forms authentication out there, just search for 'asp.net forms authentication'
If you are using Microsoft technologies you could build a little Asp.Net/C# application that would ask for credentials before redirecting to the correct swf.
That way you could restrict the access and have different swf file depending on the user.