Hi guys,

I am curious how are you doing your security in n-tier scenario. I face this problem:

I am remoting entities to the server tier and use adapter to store them. Now, I have to assume client is hacked and I can get whatever entity over the wire. Thus, how do you check what is going to database (i.e. which fields) - are you looping through all fields and check IsChanged? Or are you sending messages instead of entities around?

mihies wrote:

Hi guys,

I am curious how are you doing your security in n-tier scenario. I face this problem:

I am remoting entities to the server tier and use adapter to store them. Now, I have to assume client is hacked and I can get whatever entity over the wire. Thus, how do you check what is going to database (i.e. which fields) - are you looping through all fields and check IsChanged? Or are you sending messages instead of entities around?

We raise events from the data access adapter when an update/insert is about to happen. A security object gets this event and makes sure everything is ok. It does this by looping through the fields and checking IsChanged, as you said.

Just curious, what are you checking with your security object actually?

We are using remoting also, and we use rolebased security, and do security assertions at server when something happens. We let windows and IIS to provide us with the identity of the user (so we support windows authentication and digest).

I see that here is a problem with a hacked client which provides tampered data with correct authentication. We do validate the data at serverside, using llblgen validation schema, but other than that, what can you do?

Also, another interesting issue regarding security is what should you do with returning data. Most security schemas only try to prevent something to be done, but if you would really like to be sure, you should also validate the data which is returned from the server - is the client authorized to get the data or not (despite the fact that client was authorized to call the method in the first place) . I have seen this kind of things implemented in some banking/insurance systems.

sami wrote:

Just curious, what are you checking with your security object actually?

We are using remoting also, and we use rolebased security, and do security assertions at server when something happens. We let windows and IIS to provide us with the identity of the user (so we support windows authentication and digest).

I see that here is a problem with a hacked client which provides tampered data with correct authentication. We do validate the data at serverside, using llblgen validation schema, but other than that, what can you do?

For example, client could send you a modified entity he isn't supposed to change. And you would validate it and save it (ouch). You have to assert that client is authorized to manipulate that entity or even its fields.

sami wrote:

Also, another interesting issue regarding security is what should you do with returning data. Most security schemas only try to prevent something to be done, but if you would really like to be sure, you should also validate the data which is returned from the server - is the client authorized to get the data or not (despite the fact that client was authorized to call the method in the first place) . I have seen this kind of things implemented in some banking/insurance systems.

No big problems there. Create a method on the server which accepts filter parameters for the query in question. At the beginning of method just check whether client is authorized to run the query (and perhaps its filter arguments).

mihies wrote:

For example, client could send you a modified entity he isn't supposed to change. And you would validate it and save it (ouch). You have to assert that client is authorized to manipulate that entity or even its fields.

Yes, we are using rolebased security asserts to do just that. That is done in manager class, not entity/field level.

But assuming the client is hacked, and you get correct identity and pricinpal there is not much you can do - if the user has permissions to modify the entity.

If the user has permission then you can't do anything. And yes, the authorization check is done in some arbitrary class residing on server.

sami wrote:

Also, another interesting issue regarding security is what should you do with returning data. Most security schemas only try to prevent something to be done, but if you would really like to be sure, you should also validate the data which is returned from the server - is the client authorized to get the data or not (despite the fact that client was authorized to call the method in the first place) . I have seen this kind of things implemented in some banking/insurance systems.

We pass filterbuckets to the server over remoting. When a graph is about to be fetched, an event it raised from the dataaccessadapter, sending the filterbucket with the eventargs. The security object gets this and manipulates the predicates and relations so that they conform to the user's security rights.