I'd like confirmation that my understanding of CSLA and security isn't entirely off base.
I'd like to better understand the security aspect using Client---AppServer---DB.
In this scenario, I'd like to say we don't trust the client. The client will call the appserver and the appserver will do the actually persistance calls to the db.
So, even if the client application is hacked, when the client tries to call the data portal to update this information it still shouldn't go through because there are checks on the appserver. Is this correct?
For example, if the client bypasses a event on the client ( and lets say that event checks authorization to view or change data) even though this person abused its client application the app server should still enforce the correct rules?
I apologize if this is completely elementary. Of course there are a couple of other things you must do, like use SSL between the client and application server and use strongly typed assemblies. But this is not the responsibility of CSLA. CSLA uses its own Authentication/Authorization and validation and thats what I want to make sure can be trusted.
Security is all about threat assessment. And budget.
The more threat vectors you consider important, the higher your cost to protect against them. At some point you hit the barrier where the cost of security outweighs the benefit of the system, so you either scrap the project or back off on the security requirements.
While that may sound trite, or self-evident, the reality is that people don't usually think through the threat assessment clearly (probability of vector being exploited, cost if it is exploited, cost of blocking vector, etc).
The question of whether a client is "trusted" is not black and white. Take Microsoft Money: they trust the client explicitly, since the valuable data is on the client. Or take your bank, who (one hopes) never trusts a client, not even a browser, even a little tiny bit. And yet they accept user input via the browser, and that input is used to make dramatic changes to where the user's money sits. So clearly they DO trust the client quite a lot after all don't they :)
Architecturally you have two basic models to consider: client/server and service-oriented. CSLA .NET supports both models, though in different ways.
I've written quite a number of blog posts on this general topic - just click the service oriented link in the tag cloud at www.lhotka.net/weblog to filter to them.
The basic deal is this: if you "trust" the client, then you can use client/server (n-tier) models, including the CSLA .NET data portal.
If you don't "trust" the client, then you should really use SOA, which means you are now writing (at least) TWO applications. One that runs on the client, and one that runs on the server. In a pure sense, they must share nothing except the contract for data messages, and the messages themselves. SOA is expensive, but it is also the only well-known way to deal with scenarios where the client is untrusted, and yet isn't a dumb terminal (like the pre-AJAX web).
You can also imagine a hybrid, depending on your definition of "trust". This model is enabled by CSLA .NET for Silverlight. In this model, you do share code on client and server, and use the data portal with its mobile object model. However, all objects are subject to a bit of pre-processing when they hit the server - and you'd typically re-run your business/validation rules at that point.
Why rerun them? They run on the client to give honest users (99.999% one supposes) a great experience that is interactive. But they are rerun on the server in case the 0.0001% manage to hack the Silverlight runtime, disassemble your code, modify the disassembled code, re-insert that code back into Silverlight and fool Silverlight into ignoring the obvious crypto signature violation. Even if all that happened, rerunning the rules/processing on the server will almost certainly block anything bad.
I say it like this, because I come back to threat assessment. Sure, an untrusted client is a problem. And there are people in the world capable of hacking Silverlight, or cracking the .NET runtime to bypass how the assembly loader validates signed assemblies. But these people are pretty rare, and are mostly concerned with figuring out how to crack Left 4 Dead so they can post it on a warez site before their hacker buddies do.
In other words, you need to determine how likely it is for someone to actually care about your app enough to crack it. And then you need to determine how likely that is to happen. And then you need to determine the cost of a scenario where that does happen. Then you need to determine if that scenario is likely enough, and costly enough, to warrant the pricetag of SOA.
If so, then you should absolutely be doing SOA. If it is fuzzy, then perhaps the hybrid scenario is better. If not, then go for the cheaper n-tier client/server model.
In the end, CSLA .NET supports all three of these scenarios. The data portal supports n-tier, and the Silverlight data portal supports the hybrid model (and the .NET data portal is extensible enough you could do the same in .NET). And Chapter 21 of the Expert 2008 Business Objects book is all about creating services for SOA, using CSLA .NET objects on the server. Also, CSLA .NET objects work great to create an edge application (the SOA term for an app that interacts with a user) that consumes services.
You can also imagine a hybrid, depending on your definition of "trust". This model is enabled by CSLA .NET for Silverlight. In this model, you do share code on client and server, and use the data portal with its mobile object model. However, all objects are subject to a bit of pre-processing when they hit the server - and you'd typically re-run your business/validation rules at that point.
I think this is what I'm looking for, for internal applications. Our tentative plan is to use winforms for the next 1.2 years and hopefuly migrate to silverlight at some point after that.
The data portal supports n-tier, and the Silverlight data portal supports the hybrid model (and the .NET data portal is extensible enough you could do the same in .NET).
Do you mean we can get this hybrid setup going for regular winform apps as well? If so, is there any material available to help us understand the approach and concepts.
One more question: How would you define a client you trust? What are the requirements a client must have to be considered in the boundary of trust? For example, can you use certificate based security to establish trust between the application server and the client using a n/tier architecture?
kyle.l.watson@gmail.com:One more question: How would you define a client you trust? What are the requirements a client must have to be considered in the boundary of trust?
At this point of the game it sounds to me like we must trust the client application otherwise we're stuck using SOA which defeats much of the ease of use of ntier client/server. The selling point of CSLA to us is not having to duplicate the business logic on the client.
I'm still interested in this hybrid approach.
I can definitely see your point ajj3085. I think in some cases yes, you can choose to trust the client. But, it is easier if you simply don't allow the scenario for abuse if possible. If it is too costly of course you can't implement it, but I still have to do my homework before I can make a reasonable conclusion.
On a complete side note, it seems to me if possible we should standardize or find a way to expose business rules to a client in a SOA architecture. I'll just dream about it.
kyle.l.watson@gmail.com:Do you mean we can get this hybrid setup going for regular winform apps as well? If so, is there any material available to help us understand the approach and concepts.
kyle.l.watson@gmail.com:One more question: How would you define a client you trust? What are the requirements a client must have to be considered in the boundary of trust? For example, can you use certificate based security to establish trust between the application server and the client using a n/tier architecture?
In addition to many other threads on the same topic on this forum, I think this thread just adds another layer of clarification for me. And you are certainly right - in many scenarios with the right logging in place you can at least verify who is being malecious etc.
Calling validate.CheckRules on the app server maybe that extra check that will make someone sleep better.
I understand more clearly now, the assessment that needs to take place and we will definitely drill into that more before we start coding out a solution. It seems likely that CSLA will work quite nicely for us - I do not get the final say, though I have some weight on the argument.
I have enjoyed working with the project tracker solution, so from that stand point CSLA looks very promising.
Thanks for the responses.
Copyright (c) Marimer LLC