Microsoft .NET Framework and Microsoft ASP.NET support a number of security features for your code. So wouldn't it be great if you could just use a construct similar to HttpContext.Current.User.IsInRole() to guard access to your WSE-based Web service methods as well? In this article I will show you how to combine the ability in WSE 2.0 to sign and authenticate messages with the role-based permission system in the .NET Framework.
In conventional Web applications or Web services, you can simply rely on the means of authentication and encryption in IIS (SSL). You can, in this case, configure a directory in a way that requires the user to send logon credentials via the HTTP protocol by either using HTTP basic or Windows integrated security.
Using HTTP to authenticate your Web services requests might seem like a great idea in the beginning, but as soon as WS-Routing enters the game, the situation changes substantially: There is no direct HTTP connection between the sender and the ultimate recipient of the message anymore, but a potentially larger number different protocols which could be used along the routing path. This renders any means of transport-level security as a purely optional add-on that cannot guarantee the end-to-end integrity and security of your messages.
One means of providing these end-to-end services for Web services at large is to sign an outgoing message using an X.509 certificate according to the WS-Security specification.
Previous Topic
