| DataObjects for .NET (Enterprise Edition) > Application Configurations > 3-Tier Application > Security Considerations |
By default, DataObjects for .NET client uses HTTP channels for its communications with the server. HTTP channels have built-in authentication and authorization support in .NET remoting. If you deploy your server data library in IIS, you can rely on IIS and .NET remoting security support. You can configure your server data library in IIS for whatever authentication methods you prefer, including Integrated Windows Authentication (recommended), Basic authentication, anonymous access, and so on. You can also use Secure Sockets Layer (SSL) to encrypt all messages by using the "https://" protocol in your DataLibraryUrl. Summarizing, you do not need to write special code for security authorization if you use default configuration, which is deploying server data library in IIS. There is only one programmatic feature you may need in this case; this is how to specify user credentials (domain, username, password):
By default, the DataObjects for .NET remoting channel uses the default user credentials (domain, username, password) when it calls the server. Sometimes you may need to make calls on behalf of a specific user. For example, you may use an authentication scheme on the server that is different from one used on the client, and your client application may ask the user for credentials to pass to the server. In this case you will need to tell DataObjects for .NET to use these credentials communicating with the server. This can be done using the Credentials property of a C1DataSet object, for example:
To write code in Visual Basic
| VB |
Copy Code
|
|---|---|
Dim Credentials As New System.Net.NetworkCredential("myusername", "mypassword", "mydomain")
C1DataSet1.Credentials = Credentials
|
|
To write code in C#
| C# |
Copy Code
|
|---|---|
System.Net.NetworkCredential credentials = new System.Net.NetworkCredential("myusername", "mypassword", "mydomain");
c1DataSet1.Credentials = credentials
|
|
If the Credentials property is set, every call from the C1DataSet component to the server, filling the component with data or sending its updates to the database, will use the supplied credentials.
Authentication with Custom Channels
If you have special security needs, such as a custom authorization mechanism or a custom transport encryption, you can customize the channels as described in Configuring the Data Library on the Server. You can use all the power and flexibility of .NET Remoting to add your own security support and other features to the remoting channel. If you use custom channels, take into account that only HTTP channels have built-in authorization support in .NET remoting, TCP/IP channels do not have such support out of the box.
Another aspect of application security with DataObjects for .NET is database access authorization. Security information, such as username and password for database access is included in ConnectionString in the schema, and the schema is included in the client application. There are two options of securing this information:
You may also need to change the ConnectionString on the server for purposes other than security. For example, you can route calls to different database servers. You can do that in the same way, using the CreateSchema event on the server to set the ConnectionString property of Connection objects in your schema. This method changes ConnectionString permanently, for all calls from all users.
If you need to set ConnectionString on a per-call basis, you can do it overriding virtual methods in the RemoteDataService-derived class implemented in your data library, see Configuring the Data Library on the Server. Override virtual methods GetData and Update, which are the methods that are called by the client, to set up connections for the duration of a call. The RemoteDataService class has a Connections property holding a ConnectionCollection which is empty by default. If you add a Connection object to this collection and set its Name to the name of a schema connection, that Connection object will be used instead of the schema connection. Since a new RemoteDataService object is created for each call, this connection substitution works on a per-call basis.