Communication Protocol: DataSnap supports three different communication protocols: TCP/IP, HTTP, HTTPS. Choosing the HTTPS protocol that is implemented using SSL (“Secure Sockets Layer”) adds encryption to the communication between client and server, making it a secure solution. Two other protocols – TCP/IP and HTTP – are inherently not safe and such a communication can be easily inspected using network analyzers. In order to use HTTPS you need to have X.509 certificates. For testing purposes you can generate SSL certificates yourself using OpenSSL library. Here are some useful SSL links:
I have also created a simple batch file to generate X509 certificates (pasted below for convenience).
@echo ON
setlocal
SET OPENSSL_PATH=c:\tools\openssl\bin\
SET CERT_OUTPUT_PATH=c:\keys\
SET OPENSSL_CONF=%OPENSSL_PATH%openssl.cnf
%OPENSSL_PATH%openssl req -new -newkey rsa:2048 -days 365 -nodes -x509 -keyout %CERT_OUTPUT_PATH%test.key -out %CERT_OUTPUT_PATH%test.pem
endlocal
pause
Connectivity: Clients can connect to servers through DBX (TCP/IP, HTTP, HTTPS) or REST (HTTP, HTTPS).
DataSnap Filters: DataSnap architecture contains the concept of “communication filters”, where it is possible to modify programmatically the raw stream of bytes sent between client and server over the network. DataSnap comes with three filters already pre-installed: two encryption filters (RSA and PC1) and one compression filters (ZLib). Using encryption filters it is possible to encrypt the communication between client and server. The two encryption filters are typically used together. It is relatively easy to create custom transport filters. A very nice collection of custom filters has been created by Daniele Teti and is available at google code.
Authentication and Authorization: DataSnap framework supports authentication of clients, where it is possible to programmatically determine on the server, using TDSAuthenticationManager component, based on protocol, context, user and password used by client to decide if a client is “authorized” to establish the connection with the server. At this stage client is added to one or more roles used for authorizing access to specific server methods and server method classes. Using authorization and authentication adds a level of security to the overall system.
Application Architecture: Beyond the support for security that is built into the DataSnap framework, it is possible to increase the overall security through custom application architecture. This may involve implementing “Login” and “Logout” server methods that would require application-level credentials. In a typical scenario, once successfully logged in, the client may receive a session key that needs to be used as a part of every server method call and also used to logout from the server. Additional possibilities include obscuring values and data structures passed as parameter and return values to server methods.
Server Deployment: Servers should be deployed with the security in mind, which involves applying proper security policies. My preferred deployment infrastructure for servers is Amazon Web Services EC2. More info about AWS:
Building Secure Mobile Client Apps: Delphi XE5 makes it possible to build DataSnap clients on all major platforms, including mobile, desktop and web. Depending on the actual target you may also need to deploy additional files related to SSL support. Olaf Monien has a very nice summary of files needed for each target including very useful code snippet to include in the project file of your mobile client app.
DataSnap is really a very powerful architecture for building secure and scalable multi-tier solutions with reusable components. To learn more about DataSnap visit my "Delphi Labs" tutorials.