I am creating a Silverlight 3 application for which i am designing the security block. I already have an existent ASP.NET authentication module that i will reuse in the WCF security service(which will be like a wrapper and this will be called from Silverlight). My goal is to use SSL for the transport security. Also i would want this to be scalable as i don't want to query the DBMS for each authentication service call.
Any pointers on best design approaches.
Thank you. Anjan
If you already have it done in ASP.Net then you might want to take a look at .NET RIA Services. RIA Services allows you to hook into the ASP.Net authentication right inside of Silverlight. Brada has written about this and has a post on RIA Services Authentication here.
Related
I have a WCF.
I have a silverlight application.
I do not want anyone to be able to call the WCF except the Silverlight application.
I do not want to install any certificates on the client.
I do not want to hit any databases.
What would typically be the best way to do something like this?
You can address this using a cross domain policy file. Silverlight cannot connect to WCF services hosted on secondary domains without the implementation of this policy file.
Here are two links to get you in the right direction
http://msdn.microsoft.com/en-us/library/cc197955%28v=vs.95%29.aspx
Tim Heuer has a good writeup on the implementation of this file as well.
http://timheuer.com/blog/archive/2008/04/06/silverlight-cross-domain-policy-file-snippet-intellisense.aspx
To prevent a WCF services from being accessed by other applications you will need to implement authentication of some sort Here is a related post
I am going to develop the 3 tier application using Silverlight + WCF + ORM
Now my question is if I use ORM at database layer then how can I expose the classes at Presentation, Business layer to do Client-Side validation ?
If you used WCF RIA services instead of plain Silverlight WCF, you can attribute the properties of your data objects (in the associated metadata classes RIA creates for you).
This allows you to add basic validation rules, or even custom ones, that runs on both the server and client.
Using WCF RIA Services via a library is the preferred way to organise projects so try this link:
Walkthrough: Creating a RIA Services Class Library
Also:
Using WCF RIA Services
Creating Rich Business Applications using Silverlight 4 and WCF RIA Services
Various Channel 9 Videos
Is is generally a bad idea to expose your business entities directly to the frontend. Not only is what fits your backend layer rarely a good fit for your frontend but you also run the risk of exposing security critical information to the client - which should never be trusted.
An approach that generally worked well for us is developing the Silverlight Frontend using the MVVM pattern and have your WCF Service Layer return DTOs that can be more or less directly mapped to the data requirements of a ViewModel. This also satifies one of the most important rules when developing intranet/internet client server applications and that is to keep roundtrips to a mimimum because a DTO tailored to the needs of a particular viewmodel can include all the relevant information at once.
At the moment it seems that a RIA Domain Services class can not return a sinlge custom type.
There are parts of my app that needs just that, so think the only way to get that is to call back to a simple silverlight-enabled WCF Service, which i beleive will not have a problem returning a custom type. I don't see where the Silverlight client app has any sort of reference to the Ria Services. How do I set up both a Ria services and WCF service on the silverlight client. Will the WCF service be "aware" of the authenication already in place with the RIA services?
This is one of my biggest bugbears of RIA Services :). The good thing is that they are in the process of enabling complex types to be returned from invoke methods (according to the user voice site for RIA Services). However, that won't help you now :).
The best way to implement your requirement to return complex objects is indeed to set up a standard WCF Service to return complex types when required. You do so in the normal way that you would expose a WCF in any web project. You then consume it in your Silverlight application in much the same way you would a WCF Service in any other type of project (by adding it as a service reference). The main difference when consuming it (compared to other types of projects) is that Silverlight only supports asynchronous calls. One difference to be aware of from RIA Services is that whereas RIA Services automatically determines the URI of the domain services (based upon where the XAP file originated from), you will need to handle that aspect yourself (very important when you try to deploy your application :). Do this either by setting the URI in the app.config file, or use the method I use in the code accompanying this article here: http://www.silverlightshow.net/items/Building-a-Framework-for-Silverlight-Line-Of-Business-Applications.aspx.
In regards to your final question, yes, RIA Services uses standard ASP.NET authentication, so the cookie that it uses to maintain your authentication status is also used by any WCF Services in the same project. I talk a bit about security with WCF Services in this article if you want more information: http://www.silverlightshow.net/items/Building-a-Silverlight-Line-Of-Business-Application-Part-3.aspx.
Hope this helps...
Chris
Before reading, please know I've read all the other posts about the differences between vanilla WCF, WCF Data Services and RIA Services. My question is specifically about why RIA Services is being considered as a special kind of data source specifically for Silverlight when it seems to make more sense to just have it do one job: serve as a business logic layer behind a REST interface.
It looks like with the release of VS2010, RIA Services has solidified its stance as a business logic layer that sits behind a REST data access service - this seems to be confirmed by the new "Expose OData Endpoint" option on the Domain Service Class template in Visual Studio, which as far as I can tell essentially does for your RIA Service exactly what WCFDS does for an arbitrary data source (you could do this before, I believe, but the addition of this checkbox makes it clear that a RIA Service can be viewed as a layer containing business logic used to enhance a REST data endpoint and/or constraint it to a given set of queries, and not necessarily an endpoint in and of itself).
So, if I've got a RIA service with business logic, exposed via OData, I can add a reference to the OData service from a WCF client app. On the client, I get a DataServiceContext derivative that lets me do unit-of-work style work on the client. I can do the same thing from a Silverlight app and get what appears to be the same thing - a DataServiceContext derivative.
If I instead use a "RIA Service Link" in my Silverlight app to directly tie the app to the RIA service instead of adding a service reference, I get code generated by Visual Studio that appears to support pretty much the same patterns of work, but using a different style of API.
That being the case:
What are the advantages of a "RIA Services link," where a Silverlight app is tied directly to a RIA Service, as opposed to just adding a service ref to an OData endpoint that can be consumed by any kind of client without incurring tight coupling? I'm told that the magic of RIA is in the code generation, so I guess I'm trying to understand how the RIA code generation differs so much from "add service reference" code generation.
If there are advantages, why are these advantages made available specifically to Silverlight and not WCF client apps? Selling RIA services purely as a layer behind an OData endpoint seems like it would help standardize and push OData even further in terms of becoming a universal type of endpoint for any sort of client – “consume from ASP, consume from Silverlight, consume from WCF… you get virtually the same experience and it’s a great one.” Instead, we have Silverlight tied directly to RIA with a special set of functionality, and all other clients using the open protocol.
RIA services is not intended as "Domain logic behind oData" to the contrary and quite the opposite. The intention of RIA services is to abstract away the mechanics of web based data access to enable Rapid Application Development in Silverlight. Think of RIA
Services as to WCF as VB is to C++.
The key benefits of RIA Services are:
Transparent Data Access - there's no fiddling with svc files etc. You create an entity framework model, wrap it in a domain service and you're done. More importantly changes are propagated automagically. The developer doesn't have recreate the Service reference every time the model or a query changes, code gen does it for you.
Authentication framework out the box - It's there when you create a business app, it's a template in VS, a way to integrate with existing ASP.NET auth without having to do any heavy lifting.
Data Source Templates and Validation = Probably one of the most overlooked features but yet one of the most important. Have you opened the "data sources" window? RIA services creates User configurable DataContext bound Master/detail controls that support server side validation annotations. A functional data bound app is a drag and drop away. Consider the value of that to someone who is more Design/Blend focused.
In short RIA services is built for a developer to be able to go from an edmx data model to a secure functional Silverlight up in a matter of hours. It's awesome stuff when used in context.
As a note, I've done quite a bit of research on RIA Services and Data Services and they fulfill different needs. We use RIA Services for all our desktop replacement apps, but we use Data Services for SaaS.
I don't think you're far off with the long term intention of RIA services though. I think we'll see oData and RIA services get a lot closer in future versions.
The OData endpoint exposed by WCF RIA Services does not support query operations and returns data as-is. That means no benefit from IQueryable, sorting, parameters, etc. It will simply expose your methods; end of story. There is rumor that this will change in the next release however. However, what RIA Services provides from the standpoint of IQueryable on service calls, automatic propagation of business rules from the middle tier to the UI, and INotifyDataErrorInfo for flowing validation errors to the Silverlight client is outstanding should you choose to leverage them.
I have a Silverlight application that needs to retrieve some data from my database. This data is sensitive. Because of this, I only want my Silverlight application to be able to access the data. How do I ensure that only my applications can access the services that expose this data? Is there a way that I can validate a client attempting to retrieve the data?
Thank you!
These might be of interest:
Using ASP.NET Secure Services and Applications Services
Build Line-Of-Business Enterprise Apps With Silverlight, Part 2
MS Whitepaper: Security Guidance for Writing and Deploying Silverlight Applications
Well, everything your SL application does could be spoofed. So direct answer is NO, you cannot ensure that only your application will access to the data.
But there are number of options. For example you can implement authorization and then authenticate your user. In this way you can ensure that only users you trust access to the data.
Another option is to make spoofing harder. For example you can include sort of "secrete" token to all your requests. So other application will need to steal this token. This harder to achieve.
I think this question is more pertaining into implementing a web service or wcf service with authentication and authorization. If your service takes care of it, then you can be ensured about your data. Your silvelight app is just calling the service.
Whoever download the xap can decompress and reverse engineer your code, so your best bet is to build a web service as others suggested. Silverlight Ria ships with a full blown authentication membership that you can leverage.