Web Service Enhancements


Many Web Services provide simple sets of data, but the true value of them lies in tying together applications, a way of providing loosely coupled services for distributed processing. To take Web Services from the simple method call to integral parts of enterprise applications, they need additional features. For example, how do you secure Web Services so that only authorized users can access them? Or how can you ensure that data in messages is secure? Or how can you route messages through third-party gateways?

Some of these issues are solvable with the current framework; security and encryption, for example, can be done in a number of ways, often requiring custom code. Web Service Enhancements (WSE) provides standard solutions to these issues. Now in version 3, WSE is a collection of industry-standard specifications, including WS-Security, WS-Addressing, and WS-Policy. The design goals of WSE 3 are to:

  • Build secure Web Services easily, to provide secure end-to-end messaging, allowing messages to remain secure when routed through third parties.

  • Simplify development, providing easy construction of service-oriented applications.

  • Provide for future-proofing and interoperability, allowing existing Web Services to work with Microsoft's long-term vision of service-based architectures, Windows Communication Foundation (WCF), code-named Indigo.

With smaller Web sites, Web Services often don't require many WSE features, but the enterprise space is a different arena altogether. For example, consider a tiered system, where the client machine makes a Web Service call for a payment to a payment server. The message contains details of the payment, which are duly authorized, and the message is then forwarded to back-end services for processing and logging. There are two important points here, starting with message routing, with the message being routed through the payment server; WSE allows messages to pass through different servers on its route to its final destination. The back-end server receives the routed message, but how does it know that this is a valid message, or that the payment server hasn't been compromised? Because of WSE, the routing server can add signed headers to the message to guarantee the authenticity of the message. The second issue is security, where you may only want to have part of the message encryptedperhaps some of the client details that the routing server shouldn't have access to. Wire-based encryption, such as HTTPS, doesn't provide the capability for partial message encryption, so WSE performs this at the protocol level.

WSE provides five main security profiles:

  • Username over transport, where transport level security is used, such as HTTPS. Client authentication is performed against an authorization store such as Active Directory or SQL Server

  • Username for certificates, where an X.509 certificate is used for security, and client authentication is the same as for username over transport

  • Anonymous for certificate, where an X.509 certificate is used for security, and the client is anonymous

  • Mutual certificates, where the client and server exchange X.509 certificates used to secure the data

  • Kerberos, where the client and server are within a Windows domain

Which you use depends upon your scenario, but the ease and flexibility of WSE 3 makes writing secure Web Services far easier than in previous incarnations of WSE.

This book isn't the forum for an in depth discussion on WSE, so for more details visit the MSDN WSE page at http://msdn.microsoft.com/webservices/webservices/building/wse/, where you'll also be able to download the WSE 3.0 Toolkit.

The WSE 3.0 Toolkit

The WSE 3.0 Toolkit is a free download and add-on to the .NET 2.0 Framework, providing base functionality as well as tool support. Once installed, you can configure the application by using the WSE Settings 3.0 option from the application context menu, or manually with configuration files. Configuration and use of WSE 3.0 is based around policies that can be applied to Web Services, clients, and proxies. A policy defines the assertions required for each component of the Web Service.

You can set the policy using the configuration tool (see Figure 16.6). When you add a policy, the WSE Security Settings Wizard allows you to pick what you are securing and the security method (see Figure 16.7). The wizard also allows you to specify how the message is to be protected (see Figure 16.8). There are additional steps allowing you to explicitly declare users and roles authorized to access the Web Service.

Figure 16.6. WSE policy configuration


Figure 16.7. Selecting the application type and authentication method


Figure 16.8. Specifying the message protection


Once the policy is defined, you need to configure the service code, starting with an attribute on the class, as shown in Listing 16.18; the value of the parameter to the Policy attribute is the name of the policy (creating using the Add button on Figure 16.6).

Listing 16.18. Adding the Policy to the Web Service

[WebService(Namespace = "http://tempuri.org/")] [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)] [Policy("usernameTokenSecurity")] public class Service : System.Web.Services.WebService

By default, authentication is performed against Active Directory, and all you have to do in your code is to extract the security token and authorize the user, as shown in Listing 16.19. GetUsernameToken exTRacts the User nameToken (a WSE 3 object that identifies the user) from the security tokens of the SOAP request. This token is then used to check the username passed from the client, and if it doesn't match a valid user, an exception is thrown. This code could equally check for the user being in a valid role or have this check done declaratively. Since WSE authorizes the user against Active Directory, this is an authentication check.

Listing 16.19. Authorizing Users in a Web Service

[WebMethod] public string HelloWorld() {   UsernameToken token = GetUsernameToken();   if (token.Username != @"domain\user")     throw new UnauthorizedAccessException("no way Jose");     return "Hello World"; } private UsernameToken GetUsernameToken() {   if (RequestSoapContext.Current == null)     throw new Exception("Only SOAP requests are permitted.");   // Make sure there's a token   if (RequestSoapContext.Current.Security.Tokens.Count == 0)   {     throw new SoapException(        "Missing security token",        SoapException.ClientFaultCode);   }   else   {     foreach (UsernameToken tok in              RequestSoapContext.Current.Security.Tokens)       return tok;     throw new Exception("UsernameToken not supplied");   } }

If you wish to authorize against a different user store, such as the ASP.NET membership database, you can create your own class, inheriting from UsernameTokenManager, and overriding the Authenticate Token method, which returns the password for the given user (Listing 16.20).

Listing 16.20. Authorizing Against the ASP.NET Membership Store

public class AuthenticationManager : UsernameTokenManager {   protected override string AuthenticateToken(UsernameToken token)   {     MembershipUser user = Membership.GetUser(token.Username);     return u.GetPassword();   } }

On the client application, you perform a similar configuration process, running the WE Security Wizard to define the same rules as for the server. To call the secured Web Service, you create a UsernameToken with the credentials for the user, and use the SetClientCredential method to set the token on the proxy. You then define the policy and call the secured method (Listing 16.21).

Listing 16.21. Calling the Secured Web Service

localhost.ServiceWse proxy = new localhost.ServiceWse(); UsernameToken token =   new UsernameToken(TextBox1.Text, TextBox2.Text,   PasswordOption.SendPlainText); proxy.SetClientCredential(token); proxy.SetPolicy("usernameTokenSecurity"); Label1.Text = proxy.HelloWorld();

This is obviously only the simplest of cases, and WSE provides configuration and code for signing and encrypting messages that is just as easy. More detail is outside the scope of this chapter and would be enough content for a book in its own right. For more details, you should consult the WSE 3.0 Quick-Start Samples and documentation that is supplied with the toolkit, as well the GotDotNet Web Server Security Project (http://www.gotdotnet.com/codegallery/codegallery.aspx?id=67f659f6-9457-4860-80ff-0535dffed5e6), and the Microsoft Patterns and Practices Guide for patterns in secure Web Services, which is a free PDF download from the same site.



ASP. NET 2.0 Illustrated
ASP.NET 2.0 Illustrated
ISBN: 0321418344
EAN: 2147483647
Year: 2006
Pages: 147

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net