Good bye DCOM
A friend of mine who works in the Indigo team sent me a link to the latest documentation on Indigo: https://winfx.msdn.microsoft.com/library/
The how-to section on self-hosted services caught my attention. Now, it is possible to expose a secure Web service hosted in your own process. Yes, I said secure - in the sense that it is now possible to perform true Windows authentication. For example it is really easy to expose a Web service in your process that allows incoming Web service calls only from other processes running as certain users.
This has far reaching implications on using Indigo for regular Windows applications or services. Until now, exposing a secure interface in managed code was a pain. As we all know, .NET Remoting (the native remoting method in .NET 1.0 and 1.1) was not truly secure if you hosted it in a regular process or service. It was not secure simply because there was no authentication and authorization model built in. The only way to get some security was to use an ASP.NET based hosting, but this would require an additional dependency on IIS 6 and ASP.NET. (Actually, to be fair, there is a way to add Windows-based authentication and authorization, but it's pretty complicated. See this and this link for more details). And DCOM was the only option left.
Indigo changes all that. Even more, opposed to writing a classical DCOM, the Indigo programming model is pretty straightforward. Things like defining and implementing a contract, creating endpoints can be done in a few lines of code.
Here is a sample C# console application that exposes a simple interface as a Web service:
using System.ServiceModel;
using System.IO;
using System;
// Define the MathService by creating an interface and applying the
// ServiceContractAttribute and OperationContractAttribute attributes.
[ServiceContract]
public interface IMathService
{
[OperationContract]
[PrincipalPermission(SecurityAction.Demand, Role="Administrators")]
int Add(int x, int y);
}
// Implement the interface to create the service.
public class MathService: IMathService
{
public int Add(int x, int y)
{
return x + y;
}
}
// Host the service.
static class MathApp
{
static void Main(string[] args)
{
// Create a generic ServiceHost object of type MathService.
// Specify a base address for the endpoints.
// Combined with the base address, the endpoint's
// address becomes: https://localhost/MathService/Ep1.
// Use configuration to set up the relative address.
Uri baseUri = new Uri("https://localhost/MathService");
ServiceHost<MathService> host = new ServiceHost<MathService>(baseUri);
// Opening the host sets up the communications infrastructure.
host.Open();
// Exiting the application would bring down the Service.
Console.WriteLine("Press enter to exit");
Console.ReadLine();
host.Close();
}
}
This needs to be coupled with a special configuration file, located in the same directory as your assembly (remember your web.config file?)
<!--Define the endpoint for MathService in configuration.-->
<configuration>
<system.ServiceModel>
<services>
<service serviceType="MathService" >
<endpoint>
<endpoint address="Ep1"
bindingSectionName="basicProfileBinding"/>
</endpoint>
</service>
</services>
</system.ServiceModel>
</configuration>
Security is also nicely designed. The Windows integrated authentication is now the default option. This makes sense since, after all, if you are writing a service which lives (potentially) in the Local SYSTEM logon session, then you must control in a precise manner what users are able to call in. As you can see, the PrincipalPermission attribute above will allow incoming calls from clients running as Local Administrator.
To play with these samples, you need to download first the Indigo Community Technology Preview, but you must be a MSDN Universal Subscriber to download it. See this link for more details. Soon, a freely downloadable drop will be made available.