I'm looking for some suggestions to provide some sort of mechanism to provide medium security access control for a data portal that is visible on a public IP address. This would be on top of the user having to authenticate themselves in situations where an interactive application is connecting to the portal.
This isn't so much an issue of the connection itself being secure (as it is possible to encrypt the connection itself), but whether the *client* itself is considered trusted. Also, I'm not so much concerned about serious hackers as I am more "casual" abuse. So, it doesn't have to be fool-proof, just medium-proof.
I'm envisioning a basic setup where all clients are considered "untrusted" until they go through some sort of process that establishes that they are trusted. This process would require the user provide credentials that are valid in the back-end database, and then some sort of persistent data would be stored somewhere (perhaps on the client, but also possibly on the server) to provide a record that it was trusted. The data portal would reject any calls except those needed to authenticate the client until the trust is established, after which it would operate normally.
For example, I might keep a table in the database of the MAC addresses of the trusted clients. If your MAC address isn't in the table, the data portal would reject any calls other than "I want to be trusted here are my credentials call", at which point the MAC address would be added to the table. Alternatively, maybe a token could be generated and stored on the client, and passed over via the ApplicationContext on each request, and the data portal could inspect the token somehow for validity.
Does anyone have any suggestions on a good way to do something like this?
I have the same problem. I need to secure the data portal as much as possible with easy means.
I thought about:
Using the MAC address sounds like a viable solution as well.
I think I will use the token on login for extra security (I'm already using SSL to secure the communication).
There has been some discussing on the subject lately. I would be great to have a common easy-to-use way to solve the problem (which I think a lot of people have).
Any other ideas?
Certainly if someone has succeeded in using a client certificate with CSLA that has to be the list of trusted certificates on the server, then this would provide a high degree of trust (albeit requiring some plumbing to get in place), but I've searched the forum and don't see any obvious success stories.
I'd bet you aren't seeing much information because it's not likely to be a recommended technique. 
Typically what you'll see people recommend is that rather than trying to secure the DataPortal, you build a service interface in front of the DataPortal and secure that. I don't think the DataPortal was built to easily accommodate the kind of security you're looking for.
I realize that you're not really in a "service" scenario, but I'm not sure how you reconcile a trusted client with a public IP address for your DataPortal...
- Scott
Typically what you'll see people recommend is that rather than trying to secure the DataPortal, you build a service interface in front of the DataPortal and secure that. I don't think the DataPortal was built to easily accommodate the kind of security you're looking for.
Perhaps, but in CSLA 3.6, Rocky introduced the IAuthorizeDataPortal interface and thus the ability to specifically authorize access to the data portal. I'm basically looking for a good way to implement IAuthorizeDataPortal. There is already Principal based security in CSLA, so presumably this interface and authorization capbility was provided to enable an additional layer of security on top of user credentials, yes?
It isn't really a data portal limitation, as much as that this is an extremely challenging thing to do in general.
If I understand correctly, you don't want to secure the user (other than username/password), but you want to secure the client workstation.
There are companies that specialize in doing this. Sometimes they use hardware dongles, other times complex client-side keys, or services that monitor the system for changes. The best places to look for models around this is online gaming, where there are very extensive efforts to solve this problem. And even with those extensive efforts the games are continually hacked.
But the initial post specified that this wasn't to block hackers or advanced developers, just to block misuse by casual users.
In that case you can probably get away with having some sort of registration step in your installer, or in a separate registration app. Ensure that the user goes through registration, which of course would communicate with your server. The server can issue a security token that is then written into the registry on the client.
Your real app then, will always go get this security token from the registry and will put it into Csla.ApplicationContext.ClientContext. This ensures it flows from the client to the server on every data portal call.
Then implement an IAuthorizeDataPortal provider on the server, and check the token passed through ClientContext to make sure it is valid. Remember that this happens on every data portal call, so make sure your implementation doesn't become a performance bottleneck.
Will this stop hackers, developers or high-end power users? Almost certainly not. Will it stop a casual user from copying the app to another machine and running it there? Probably.
Thanks for the reply, Rocky. You understand the request perfectly. I was basically looking for some good suggestions for generating a security token (although the more I think about it, since I'm mainly concerned with a kiosk type connection registering MAC addresses is starting to seem more reasonable).
The main problem I'm trying to solve is making it more difficult to copy the application (or more specifically the assemblies that implement the CSLA-derived components) and have them "just work" when connected to any remote portal. I'll settle for making it "reasonably difficult".
(On a related note regarding hacking, it seems like the data portal pretty much depends on someone having a set of matching binaries on the other side. I'm sure it might be possible in theory try to talk the the portal by "spoofing "the object serialization somehow, but in reality how serious is the threat if someone doesn't have the actual assemblies themselves?)
Yeah, having the client send the server the MAC address, then having the server encrypt it using a simple symmetric encryption method (everything you need is build into .NET) is probably sufficient.
Keep in mind the concept of revocation - keep a record on the server of the MAC addresses so you can flag an address as invalid (or remove it from your table) to revoke the key.
It is true that the data portal requires matching binaries on both sides. If you sign your assemblies that'll make it more secure in this regard, as otherwise it is just the name of the assembly that must match, which is pretty meaningless.
Would it be possible to see the business object type and get access to Csla.ApplicationContext.ClientContext in IAuthorizeDataPortal? I need to let Login pass through without a token ...
Any code examples (I haven't checked BO2008 yet as it's in the office)?
I believe the AuthorizeRequest object that is passed to IAuthorizeDataPortal.Authorize() has the ObjectType of the business object (at least this is what it appears to be).
I'll have the exact same issue as I'll have to allow the registration command to come in without prior authorization, so I'll block access for all but that one object type (and perhaps whatever other types I need in order to verify the registration).
Yeah, having the client send the server the MAC address, then having the server encrypt it using a simple symmetric encryption method (everything you need is build into .NET) is probably sufficient.
So, (and here's the real trick) what would you suggest so that the security token generated by the server and stored in the client won't work (at least not trivially) if someone copies the token itself to another machine? The only thing that comes to mind is that the client would need to supply a second piece of information that is programmatically generated that can be cross-checked with the encrypted token.
Using MAC addresses for example, the client could also send the MAC address along it's client context (encrypted or not), and then the server could not only check that the token itself is valid, but also that the MAC address it contains matches the copy provided by the client.
Copyright (c) Marimer LLC