I have googled a bit for how I should handle security in a web service application when the application is basically the data repository for a Silverlight application, but have gotten inconclusive results.
The Silverlight application is not supposed to have its own user authentication, since it will be reachable only through a web application that the user have already authenticated to get into.
As such, I was thinking I could simply add a parameter to the SL application that is a cookie-type value, with a certain lifetime, linked to the user in the database. The SL application would then have to pass this value alongside other parameters to the web services. Since the web service is hopefully going to be a generic web service endpoint, few methods, adding an extra parameter at this level will not be a problem.
But, am I supposed to roll this system on my own? It sounds to me as this isn't exactly new features that nobody has considered before, so what are my options?
First of all use SSL for the service. Otherwise users will be able to capture all the parameters passed to the service. It's still possible to see it in case of https but it will be a little bit more difficult.
Also, consider using Message Inspector for adding custom headers to the messages which you will validate on the server. This way you will not need to add extra parameters.
Related
I am trying to develop a web application that can communicate with another web application. App1 is an app developed using Angular.js and Struts2. This apps sole purpose is to perform search queries on several databases and returning the information about the products for the user to view. App2, the current app I am developing, will be developed using Angular.js and Flask/Python. This app will be responsible for storing the products the user selects in a shopping cart and allowing the user to make a purchase.
I am stuck as to how to get the two applications to communicate(passing login information, selected items ids, etc.) with eachother.
I have tried passing information via a url redirect (http://www.example.com/?myVar=someData&...) but Angular is giving me a lot of trouble to try and get around that. Even if I can get this to work, I think it would be insecure as data the user shouldn't know will be exposed in the url.
My second thought would be to somehow access the session data from App1 in App2 but that could also lead to security issues.
My final thought would be to some how make a call to App1 that returns a json object that can be parsed in App2 but I am not entirely sure how to pass that information along.
How can I get the two applications to communicate with each other?
Thanks for your help
In my opinion this isn't really within the scope of AngularJS. However, I believe that the best, most accepted practice for communication between web applications in this day and age is RESTful Web Services.
It's not a small topic, but once you get the concept behind it you can use it in any programming language that supports web applications (Java which I'm assuming you're using because of struts has multiple REST libraries, I prefer Jersey but that's just me).
It's also an amazing way to use your Angular front end to talk with its own back end. The entire Angular $resource framework is built around the idea of using RESTful services.
Check out this link on Wikipedia for a brief synopsis of what makes a service RESTful: http://en.wikipedia.org/wiki/Representational_state_transfer#Applied_to_web_services
Now, that applies to most of what you asked. As far as login information is concerned, that's going to depend on your security implementation. A lot of times you can put information like that in the header of a web services request, and only accept requests that come from trusted servers, etc. but there's a good bit of stuff to understand there. It's an entirely separate topic.
Hopefully this helps you get started. Let me know if you'd like more information or pointers.
I got a problem when trying to call a remote rest webservice
https://stackoverflow.com/questions/5442175/error-on-httpwebrequest
It seems it's due to cross domain policy file missing on the remote server
http://forums.silverlight.net/forums/p/183993/419448.aspx
I don't understand the reason to have this file. It doesn't protect the user at all so for what purpose did they create this restriction ?
UPDATE: Reading the explanation from MS I still fail to see how this policy allows user to be more aware since it's all done on servers side WITHOUT EVER NOTIFYING THE USER OF ANYTHING.
UPDATE: Seems people don't agree so after all my question is not so stupid :) Answer would be Secure the service not the User ? Why on earth would twitter for example would like to protect its service without even wanting it ? If a website would want to protect itself it would just well put some login / password :) It is obvious that a site wants greatest access from browser it doesn't matter if browser uses plugin or not why would the site care ?
It's for security and making you actually OPT IN to allowing it.
MSDN explains it the best so there is no point in me re-wording it:
Using Silverlight version 4 for
cross-domain communication requires
guarding against several types of
security vulnerability that can be
used to exploit Web applications.
Cross-site forgery is a class of
exploits that becomes a threat when
allowing cross-domain calls. This
exploit involves a malicious
Silverlight control transmitting
unauthorized commands to a third-party
service, without the user's knowledge.
To prevent cross-site request forgery,
Silverlight allows only site-of-origin
communication by default for all
requests other than images and media.
For example, a Silverlight control
hosted at
http://contoso.com/mycontrol.aspx can
access only services on that same
domain by default – for example
http://contoso.com/service.svc, but
not a service at
http://fabrikam.com/service.svc. This
prevents a malicious Silverlight
control hosted on the
http://contoso.com domain from calling
unauthorized operations on a service
hosted on the http://fabrikam.com
domain.
To enable a Silverlight control to
access a service in another domain,
the service must explicitly opt-in to
allow cross-domain access. By
opting-in, a service states that the
operations it exposes can safely be
invoked by a Silverlight control,
without potentially damaging
consequences to the data that the
service stores.
Here is something to consider. Assume a world where Silverlight did not require a web service to opt into being used by a Silverlight client or a indeed a Flash client come to that.
Some malcontent manages to find a weakness in a popular web service API and writes an exploit in Silverlight or Flash. Harm is done and users of this web service are upset. Where might the finger of responsibility get pointed? What happens when it gets into the news that a Silverlight or Flash plugin was the "cause" of some breach? Whose reputation is harmed? Answer: Microsoft / Adobe even though in fact it has nothing to do with them.
Ultimately this is about public relations, about the risk of there being a perceived insecurity where none is really warranted.
By including this opt-in requirement these companies massively reduce the number of services that could possibly be exploited using their plugins. Significantly reducing the risk that their plugin would unfairly be tarnished with an uncalled for reputation. For those that do opt-in the policy files can be pointed at as the responsibility of the service provider who made an informed choice to include such a file.
Ultimately if there is a choice between risking your public perception with 100,000,000 potential users or risk some disgruntlement and bewilderment of some 100,000 potential developers I know which one I would pick.
Imagine you have a webservice, which is on your website, it displays live stocks and you want this website to be used by only your silverlight client.
Now I can write a silverlight client and put it on my website that will fetch data from your website, I can steal your data and users will feel it's my data. As there is no way o determine who is connecting it.
So silverlight loaded from my domain will not connect unless you allow from your domain. This is not for server client security but this is for cross domain security. Same as JavaScript cross domain security that you can not access any objects loaded from different domain.
I've got a Silverlight application that will be running out on the open internet, available to basically everyone who has ever lived.
The application makes use of RIA Services to manipulate data in a database on the server.
The application creates, reads, updates, and deletes data of different varieties, however I only want these operations to occur from within the application.
This brings about two questions:
Is there a particular recommendation for what type of Authentication to use? Forms or Windows?
Is there a way to prevent someone from "linking" to the application? That is to say, copying the HTML from the containing page, pasting it in their own HTML page on their local machine and running it? The end goal would be to only allow the application to be run when it is embedded in a page requested directly from my server and my server alone?
If your application is being used on an internal network, then Windows authentication is best. Otherwise (as is your case) use Forms authentication.
Silverlight automatically prevents applications (unless they're running with elevated trust) from accessing resources on the Internet (web services, HTML, etc) that are not from the domain that the application originated from, unless that domain has a cross-domain policy file in its root. The Silverlight runtime prevents this (not the server), so this a client based security feature - not server based. By not having a cross-domain policy file in place on your server, your application will only be able to communicate with your domain services when it is run from your server (as you are after). The application will run, but calls to those services will fail.
You could always do a check for what domain the application originated from in code, and match it to a hard-coded domain name if you want to prevent the application running at all from other domains.
Hope this helps...
Chris
I am going to be developing an application for work, and I am trying to decide whether to use Silverlight Business App or Asp.Net Web App. My manager is concerned about the performance and download time it would take if I created the entire application as a Silverlight app, with authentication. I have been playing around with some tutorials over the last week trying to get a perspective on my situation and have come up with a design question I need to ask those that are more experienced than me.
Is it possible to use a Asp.Net application and just embed a silverlight application in one of the pages that will be used inside a folder that is configured with the roles authorization? And if so, would it be possible to get user credentials from the client silverlight app without passing them through the initParams.
I understand that I can set the authentication to "useCookies", so I was thinking I would be able to get the cookie on the client and hopefully get a property verifying if the user is authenticated.
Also, would this be a risky practice? Thanks for any advice and direction.
There are a few approaches you could take. While I know you don't want to expose the credential in init params, you could generate a "ticket" (claims-based authentication) for the credential, and include the ticket (for example, a GUID) in the init params. When the Silverlight application launches, it would consume the ticket, possibly validating it via a secured web service call, and the ticket would no longer be valid so even if someone spoofed it or viewed the source, it couldn't be used.
Quite a bit depends on your architecture. For example, if you are using the roles-based authentication, and most of the business logic and/or decision making is based on web service calls, the web services can use HttpContext.Current.Identity to validate the user. Even if someone opens the Silverlight application, any service calls would fail unless they were appropriately authenticated. Otherwise, I would either go with passing a ticket so Silverlight trustst the user is valid (you can create a service that accepts the Guid and returns the role information) or have the user log in from Silverlight (you have a service facing in front of the authentication mechanism and then return a ticket and/or role information).
It gets even more interesting if you decide to use WCF RIA, check out these examples for baked-in authentication:
http://code.msdn.microsoft.com/RiaServices/Release/ProjectReleases.aspx?ReleaseId=2661
1.) It's absolutely possible to embed a Silverlight xap on an ASP.NET page.
2.) As far as credentials, using cookies could work, or you could pass in a token over initparams and validate that token via a web service to see if the user is valid
It's always a risk passing credentials around, especially when it's running on a clients computer. That said, Silverlight buys you a lot, so don't let the challenge of authentication hold you back.
We have a Silverlight app which we wrote which calls a Silverlight-enabled data service. The Silverlight app cannot require a login, as it is required to present data to the unauthenticated public.
We have some schmoe who took the time to examine our Silverlight app, one way or another figure out what service it is calling, and then wrote his own client to slurp off the data so he can post it on his site and pretend like it is his. We need to prevent this.
How can i limit my data service somehow to ONLY accept requests from my silverlight app? I tried using the allow-from domain uri setting in the clientaccesspolicy.xml file to limit access to the service only from the domain in which the silverlight app sits (say mydomain.com). This did absolutely nothing though, and the service is still serving up requests to clients from outside the domain. (I tested this by putting my SL app on a different domain under our control).
What is the proper/best/most effective way to limit the data service so only our app can use it? Thanks!!!
I'm using SL 3 and .NET 3.5.
The clientaccesspolicy.xml tells the Silverlight application which Webservice it can consume. Not preventing people accessing the Webservice.
You can try using a authentication login even though its not required. This prevents 'schmoes' accessing your webservice.
Also use Dotfuscator to prevent 'schoes' to disassemble your Silverlight application and acquire the login.
Silverlight webservice security follows the same patterns you'd use for ASP.NET security, especially services exposed to AJAX. The best way to do make use of ASP.NET's authentication.
RIA Services is an even better way to handle this. It rides on top of the ASP.NET authorization, but validates on both the client and server-side automatically to combat service spoofing. It let you take care of both client and server-side authorization by adding attributes to your methods indicating that the method requires authorized access, and by which groups or users if you need to be specific.
In addition to wire-side security and obfuscation, remember that clients can attach a debugger to Silverlight applications running in their browser. See this example from MSDN Magazine's Security IQ Test, November 2008.