I am starting a new project and intend to select either LLBLGen Pro or XPO from DevExpress.

The project will use .Net 2.0, MS SQL Server 2005, 90% of business logic will run in a smart client application, the client & server will be connected over the internet at a minimum of 256k. DB connections cannot be accessed directly from the client .exe. I hope that LLBLGEN will allow me to execute CRUD type operations on entities in the client code and automatically tunnel commands to the server without further coding effort by me.

I need to intercept all select and update commands submitted from a remote client at the server and modify SQL WHERE clauses with an additional “AND Client ID = ‘secret value’ ” condition. The Client ID will not leave the server and will be kept in some sort of session level cache.

XPO supports a web service interceptor shim where application code can implement just two general functions in the low level SQL command stack to inspect all entity read and update requests for all known entities

Does LLBLGEN provide a means to implement such a server-side security interceptor?

The project will use .Net 2.0, MS SQL Server 2005, 90% of business logic will run in a smart client application, the client & server will be connected over the internet at a minimum of 256k.

Client/Server over a slow internet connection - MS best practices guide suggests that in situation like this, you should have the client 'talking' to a web service. Data is exchanged between the client and the server in XML over HTTP / SOAP.

Not sure how DevExpress implement this, but using LLBLGen Pro, I personally would have some logic in the web service which 'authenticates' the caller - functionality you are looking for.

I am sure this community can think of other 'better' way of implementing this.

sparmar2000 wrote:

Client/Server over a slow internet connection - MS best practices guide suggests that in situation like this, you should have the client 'talking' to a web service. Data is exchanged between the client and the server in XML over HTTP / SOAP.

I accept that a client/server relationship over an internet connection puts a greater responsibility on the application designer to get the layered coupling right in order not to overload the link, however I think I have a good instinct in this area. 50k-100k DHTML exchanges per UI button click are not unusual in modern web browser systems, so I believe that a client and server hosted O/RM should be able to perform well if entity data is shipped efficiently.

I do not hold strong opinions on whether .Net remoting or a web service should be used to tunnel communication between the client and server layers of the O/RM I am dreaming about.

sparmar2000 wrote:

Not sure how DevExpress implement this, but using LLBLGen Pro, I personally would have some logic in the web service which 'authenticates' the caller - functionality you are looking for.

I am sure this community can think of other 'better' way of implementing this.

My concern is not only authentication. I need to ensure that a customer is not an advanced hacker who is trying to escape from his data sandbox hosted on a communal database. I need to assume the client .exe has been compromised and the ORM remote protocol has been reverse engineered so that malicious Entity commands can be fed to my server.

I wish to avoid coding a web service method for each smart-client fetch and update entity request.

After my original post I have read many forum posts about LLBLGEN remoting and have to confess I am not sure of the mechanics. When remote code executes UnitOfWork.Commit() are complete object graphs serialized back to the server before Commit() is re-invoked or does the client O/RM code compute and prepare the SQL command batch?

The perfect O/RM for my remoting scenario would do most of its thinking client-side and then submit command batches to the server in an pre-SQL object representation. Sever-side the O/RM would provide some interception points where I could apply additional security checks on the command batches before these get parsed into SQL.

At this point XPO seems a better fit but given the ingenuity of Fancis and the community here there might be a pleasant surprise waiting.

Hi,

I need to ensure that a customer is not an advanced hacker who is trying to escape from his data sandbox hosted on a communal database. I need to assume the client .exe has been compromised and the ORM remote protocol has been reverse engineered so that malicious Entity commands can be fed to my server.

If you need to assume your client is compromised, then I'd say the more you leave on the server, the more secure you get. Message based webservice seems the solution to me.

I wish to avoid coding a web service method for each smart-client fetch and update entity request

you don't have to. Entities and other ORM object are inherently serializable/xmlserializable so you can keep working with the interfaces or base classes, and provide general webmethods that take the type enum of entities to fetch as an argument for instance.

50k-100k DHTML exchanges per UI button click are not unusual in modern web browser systems, so I believe that a client and server hosted O/RM should be able to perform well if entity data is shipped efficiently.

This is the point were you have to be careful, serialized enities are made of very heavy xml, which compresses easily up to around 90%, which gets back to say twice the volume of the raw datatables, so you shouldn't skip the compression step (which you can enable at the soap level).

I need to intercept all select and update commands submitted from a remote client at the server and modify SQL WHERE clauses with an additional “AND Client ID = ‘secret value’ ” condition.

I can't think of something that reliable coming from such a mechanism. If you work with webservices or anyother authentication system where you leave some logic on the server, you got many powerful encrypted mechanisms to hand. Have a look at wse 3 maybe. That give you the kind of mechanism where you don't even care if the client has been compromised.

The perfect O/RM for my remoting scenario would do most of its thinking client-side and then submit command batches to the server in an pre-SQL object representation

pre-SQL object representation is to my opinion what entities are. The dataadapter is responsible for transforming those into final sql. It is not serializable nor marshallable, and should not be remoted. Entities can pass accross the wire, filters and other parameters can come as simple parameters. Then you can easily add at the dataaccessadapter level some aditional authentication mechanism if you wish, or even use the validator system.

I would go for what .Net gives us natively for securing applications, which does not have to be made from scratch in your db.

Hope you understand my viewpoint.