Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Behold WSE 2.0: Removing Another Layer of WS-Pain : Page 3

To keep up with the flurry of emerging, re-emerging, and otherwise evolving standards for Web services, we need tools—good ones—and we need them all to play nice across platforms.

Identifying Application Users
SOAP messages are generated by client applications but the initiation of the request usually stems from an individual user of that client application or partnering organization. Consequently, exchanges between applications involve the authentication of user credentials. Consider a bank teller client application that invokes Web services to access account information. The teller logs in to the client application and the application passes those credentials to identify the user to the Web services layer. Although the calling application may also require authorization to invoke the Web service, the application user is typically also identified for audit trail purposes and to authorize access to specific service features.

With two lines of code on the client, a single authentication method on the server, and some skillful pointing and clicking to configure policy and security, you have user authentication in place.
The code sample for this article simulates this situation through a bank teller client application (TellerApplication) and a set of Web services that interact with accounts (TellerServices). Throughout this article, I'll build a secure infrastructure around the Web services layer, beginning with the provision of username and password credentials from the client application user.

Authenticating Users
I've mentioned writing as little code as possible, but to authenticate against a custom application credential store, you do have to create a simple class to handle authorization. If credentials are provided with an incoming message, WSE 2.0 looks for a class that derives from UsernameTokenManager, part of the Microsoft.Web.Services.Security.Tokens namespace. The default implementation of this class invokes the Win32 LogonUser() method to authenticate against the configured Windows domain. My derived class overrides the AuthenticateToken() method to supply code for the custom credential store, handled by a pseudo-Membership utility shown here:

public class ApplicationUsernameTokenManager : UsernameTokenManager { protected override string AuthenticateToken (UsernameToken token) { Return Membership.Users.GetUserPassword( token.Username); } }

The WSE run time expects AuthenticateToken() to return the password for the user, in order to compare it to the password supplied in the SOAP request. If it's a match, authentication is successful. What it doesn't do is set the security principal for the request context, so this is something I coded into the sample as well.

To configure this custom UsernameTokenManager type, head to the WSE configuration tool's Security tab. By adding a valid UsernameTokenManager type to the Security Token Managers section (see Figure 2), a <securityTokenManager> element is added to the <Microsoft.web.services> section of the web.config, as shown here:

<security> <securityTokenManager type= "TellerServices.ApplicationUsernameTokenManager, TellerServices" xmlns:wsse= "http://schemas.xmlsoap.org/ws/2003/06/secext" qname="wsse:UsernameToken" /> </security>

The Security Token Manager dialog box shown in Figure 2 provides formatting hints for the Type, Namespace, and QName parts for <securityTokenManager> configuration. Supplying type information is fairly straightforward, but you should know that Namespace and QName describe the XML element that contains the token. In my example, and in most cases, you will use the WS-Security specification settings that expect username tokens to be passed within the <wsse:Security> header, as shown here:

<wsse:Security soap:mustUnderstand="1"> <wsse:UsernameToken xmlns:wsu ="http://schemas.xmlsoap.org/ws/2003/06/utility" wsu:Id="SecurityToken-1577266d-e7a9-4591-a4ad- a28864dd287c"> <wsse:Username>mlbteller</wsse:Username> <wsse:Password Type="wsse:PasswordDigest"> RZOCTvC0652aFHD7vW1uY/xfNE8=</wsse:Password> <wsse:Nonce> 9FIPxdApFcsD+GRrNdx8HQ==</wsse:Nonce> <wsu:Created>2004-02-23T00:21:09Z</wsu:Created> </wsse:UsernameToken> </wsse:Security>

The configured UsernameTokenManager type is automatically instantiated by the WSE run time if a username token is supplied with the request. A SecurityFault exception is issued to the calling client in the form of a SOAP fault if the WSE run time cannot successfully authenticate the user.

To require that the username and password be supplied for specific endpoints, you can write code or define a policy that automatically verifies its presence. To configure a policy that requires username and password credentials for service endpoints, use the policy configuration interface provided with the tool (see Figure 1).

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date