WSE 3.0 in MapDotNet Server
Note: This article only applies to MapDotNet Server version 6.1.2 and previous.
The MapDotNet Server Map, Feature, FeatureUpdate and Admin Web Services are secured by the Web Services Enhancements (WSE) 3.0 for Microsoft® .NET, an add-on to Microsoft Visual Studio® 2005 and the Microsoft .NET Framework 2.0 that enables developers to build secure web services based on the latest web services protocol specifications.
Note: The MapDotNet Server installers include a runtime redistributable version of WSE 3.0.
Note: By default MDNS is installed with WSE security turned off.
The entire WSE 3.0 package can be downloaded from MSDN at this location:
http://www.microsoft.com/downloads/details.aspx?familyid=018a09fd-3a74-43c5-8ec1-8d789091255d&displaylang=en
MapDotNet Server security out-of-the-box
By default MDNS is installed with security disabled on the web services to minimize any obstacles which might prevent the user from getting up and running quickly. Of course at some point you will want to lock down security on your web services - especially those services where data can be modified (Admin and FeatureUpdate.) You will need to refer to Microsoft's website for more information on the various options available to secure your web services using WSE3.
A simple username and password (UsernameOverTransportSecurity assertion) is already set up for you in the MDNS Web Services policy cache file. This is primarily an example standard assertion and it is expected you will need to implement your own assertions or use another standard one if it is insufficient for your needs. In the web.config of your MDNS Web Services you will find a configuration section:
<
microsoft.web.services3>
<security>
<securityTokenManager>
<add type="MDNSNoSecurity"
namespace=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
localName="UsernameToken" />
</securityTokenManager>
</security>
<policy fileName="wse3policyCache.config"/>
</microsoft.web.services3>
The MDNSNoSecurity token manager causes the UsernameOverTransportSecurity assertion to skip validation of the username and password against a valid account on your MDNS web services machine. Remove this section (securityTokenManager) to re-enable account authentication for this assertion. This was installed as part of your web.config to minimize requirements to get you up and running. If you are developing in your own environment and not concerned about securing your web services, you may want to leave this in place.
In the wse3policyCache.config of your MDNS Web Services you will note several policy assertions contained within <policy> tags - for example:
<policy name="MapDotNetServer FeatureUpdateService">
<authorization>
<allow user="*">
<authorization/>
<usernameOverTransportSecurity />
<requireActionHeader />
</policy>
In the wse3policyCache.config of your template web application you will note corresponding entries.
<
policy name="MapDotNetServer FeatureUpdateService">
<usernameOverTransportSecurity>
<clientToken>
<username username="MapDotNetServerUser" password="MapDotNetServerPwd" />
</clientToken>
</usernameOverTransportSecurity>
<requireActionHeader />
</policy>
If the MDNSNoSecurity token manager was removed, you must create a local account on your MDNS Web services machine according to the username and password in the username tag. You will want to do this for the particular web service you wish to lock down (the above example is for the FeatureUpdateService.)
Make sure you recycle your application pool or reset IIS if you make policy changes since they are cached.
Note: When setting the allowed user(s) in wse3policyCache.config, you may need to specify the machine name or domain to successfully authorize a user (i.e. "mymachine\myuser").
Application controlled security
Of course you will not likely want to store accounts in your policy cache unencrypted. The MapControlBridge provides an event-handling mechanism for you to create your own UsernameToken instances. These may be created as in the foillowing example code:
// event handler called right before a map web service proxy call is made
protected void SetMapCredentials(object sender, ISC.MapDotNetServer.Controls.MCBPreMapServiceCallEventArgs e)
{
// set credentials and policy to try username/pwd
UsernameToken token = new UsernameToken("MapDotNetServerUser", "MapDotNetServerPwd", PasswordOption.SendPlainText);
e.MapService.SetClientCredential<UsernameToken>(token);
// set policy
Policy policy = new Policy();
policy.Assertions.Add(new UsernameOverTransportAssertion());
e.MapService.SetPolicy(policy);
}
You might store encrypted passwords in a file or database and use a code block similar to the one above to create your UsernameToken instances on the fly. You'll note the authentication is plain-text over the wire in this case. You could lock down the network channel further using SSL. There are other WSE3 assertions to choose from and you may choose to create your own and manage your own security.
Microsoft's overview of WSE 3.0
About WSE 3.0
WSE 3.0 simplifies the development and deployment of secure Web services. It enables developers and administrators to apply security policies to Web services running on the .NET Framework 2.0. Using WSE 3.0, Web services communication can be signed and encrypted using Kerberos tickets, X.509 certificates and other custom binary and XML-based security tokens. In addition username/password credentials can be used for authentication purposes. An enhanced security model provides a policy-driven foundation for securing Web services. WSE also supports the ability to establish a trust-issuing service for retrieval and validation of security tokens, as well as the ability to establish more efficient long-running secure communication via secure conversations.
Simplified Security
WSE 3.0 has significantly simplified the securing of common SOAP message exchange patterns by providing built-in turnkey security profiles to easily secure SOAP messages between a client and a service. With WSE 3.0 the security policy format has been simplified to reflect these security scenarios. Like WSE 2.0, WSE 3.0 enables developers to use declarative files to specify behavior, including security requirements, when receiving and sending messages from a client or a service. These message level behaviors, defined through policy files, are called policy assertions. WSE 3.0 has aligned the declarative policy model with the imperative programming model; such that policies are always used to apply security and other assertions to a SOAP message either via files or in code. Policy files are associated with a client proxy or a service via a Policy attribute. E.g. in C# [Policy("ServerPolicy")]
Sending Large Amounts of Binary Data
In addition to providing easier security, WSE 3.0 provides the ability to send large amounts of binary data efficiently and securely via the W3C SOAP Message Transmission Optimization Mechanism (MTOM) specification. MTOM composes with WS-Security, reduces the size of messages on the wire helping in low bandwidth scenarios and in integrates seamlessly with existing Web services.
Additional Security Features
Additional security features include signature confirmation, opaque security tokens and the ability to explicitly create encrypted key tokens. Security session management has improved by enabling secure conversations that have been lost to automatically be re-established and the ability to explicitly cancel a current secure session. Secure conversations can now be used in web farm scenarios to improve the scalability whilst taking advantage of the performance optimizations gained through the use of secure conversation. Many of these security features are due to the support of the latest WS-Security, WS-SecureConversation and WS-Trust specifications.
Integrated with Visual Studio 2005
WSE 3.0 provides support for ASP.NET Web services to be hosted outside of IIS for example in Windows services, console applications or even COM+ applications and called with TCP protocol. WSE 3.0 has an extensible architecture that easily allows alternative protocols to be supported e.g. UDP or SMTP.