|
|
Browse by Tags
All Tags » Indigo » Transport Security (RSS)
-
If you've been following along, I have mentioned the WCF security guide project being worked on in the patterns and practices team a few times now. After months of drafts and betas, the complete guide is now ready for official release. The WCF security guide is available as a free download. Read More...
|
-
Host headers in IIS are a way to associate multiple names with a single address. The typical use of host headers is to be able to host more than one web site at a single IP address by giving each of the web sites a distinct DNS name. Host headers also play a role in WCF beyond the definition of a web site. Metadata for a web service, such as that appearing WSDL, uses host headers as a way to pick a preferred name when talking about the service. The user interface for setting host headers is relatively straightforward when the web site is hosted over HTTP but becomes a challenge when the web site is hosted over HTTPS. Here are the command line equivalents that you can use to set HTTPS host headers. On IIS 6, you need to know the id of the web site. Assuming that SSL is taking place on the default port, the command looks like this. cscript.exe adsutil.vbs set w3svc/<id>/SecureBindings ":443:<header>" On IIS 7, the command line looks very different due to the more flexible but complicated support for different web site bindings. You can also use a name that's meaningful for you to distinguish web sites. appcmd set site /site.name:<name> /+bindings.[protocol='https',bindingInformation='*:443:<header>'] To keep the example simple, I'm assuming that you're adding a new binding rather than modifying an existing binding. Next time: Transaction Header Magic Read More...
|
-
The WCF Security Guide content that I've mentioned a few times before is now done with early drafts and has been rolled up into a beta release of the full book. There's a ton of content in the real thing on top of what you've been seeing in the drafts. You can download the beta of the full security guide from CodePlex now. If you want to know what I think about the guide, here's the foreword I wrote for them: The computer industry has come to a realization – based on many years of slowly learning from painful experiences – that computer networks are hostile environments. Nevertheless, computer users demand as part of their basic expectations that applications take advantage of the ubiquitous and continuously available connectivity at their disposal to deliver a rich connected experience. It is now your task to design and assemble the loosely coupled service components that you have available in a way that blunts threats and thwarts attacks on the user’s precious assets. Your applications must withstand the hazards of living in a hostile networked environment. To make that possible, you must understand the risks that your applications face and you must be certain that the remedies you put in place properly mitigate the dangers of those risks. As someone who has been through several rounds of security and threat modeling for Windows Communication Foundation, I can say without hesitation that knowledge and experience are your greatest assets for designing secure Web service applications. The trick is to gain as much of that knowledge as possible from the painful experiences of other people rather than painful experiences of your own. J.D. Meier and team have done a fantastic job of assembling and digesting countless practical experiences into a convenient and centralized resource. Practitioners of service-oriented development with WCF will want to use this guide as both a means of learning about the fundamentals of Web service security and a reference for getting specific, step-by-step instructions for dozens of the most common security problems. I enjoy that this guide collects together several different approaches for learning about and implementing security solutions. By combining a variety of formats – scenarios, how-to articles, and guidelines are only a sample of the offered modes – solutions are both reinforced and made more easily discoverable through different entry points. The reason that I’m so excited to see Improving Web Services Security: Scenarios Read More...
|
-
After the first announcement for the WCF Security Guidance Project , the amount of content has grown tremendously. Here's a summary of what's new over the last month. Seven new application scenarios: Intranet - Web to Remote WCF Using Transport Security (Trusted Subsystem TCP) Intranet - Web to Remote WCF Using Transport Security (Trusted Subsystem, HTTP) Intranet - Web to Remote WCF Using Transport Security (Original Caller, TCP) Intranet - Windows Forms to Remote WCF Using Transport Security (TCP) Internet - Web to Remote WCF Using Transport Security (Trusted Subsystem) Internet - Windows Forms Client Calling WCF Using Message Security Internet - WCF and ASMX Client to Remote WCF Using Transport Security (HTTP) More than eighty annotated guidelines . Six new how-to guides: How To - Perform Input Validation in WCF How To - Perform Message Validation with Schemas in WCF How To - Use basicHttpBinding with Windows Authentication and TransportCredentialOnly in WCF from Windows Forms How To - Use Certificate Authentication and Message Security in WCF calling from Windows Forms How To - Use netTcpBinding with Windows Authentication and Message Security in WCF from Windows Forms How To - Use wsHttpBinding with Username Authentication and TransportWithMessageCredential in WCF calling from Windows Forms Answers to more than one hundred security questions . Read More...
|
-
The patterns & practices team at Microsoft has put together their first release of guidance for WCF security . They've included how-to guides and videos that walk you through a number of security tasks, such as working with certificates and configuring role providers. The overall guide is still under development so these represent individual modules that are being published as they're completed. Here's what's currently available: How To - Create and Install Temporary Certificates in WCF for Message Security During Development How To - Create and Install Temporary Certificates in WCF for Transport Security during Development How To - Impersonate the Original Caller in WCF calling from Web Application How To - Impersonate the Original Caller in WCF calling from Windows Forms How To - Use netTcpBinding with Windows Authentication and Transport Security in WCF from Windows Forms How To - Use SQL Role Provider with Username Authentication in WCF calling from Windows Forms How To - Use SQL Role Provider with Windows Authentication in WCF calling from Windows Forms How To - Use Username Authentication with the SQL Membership Provider and Message Security in WCF from Windows Forms How To - Use wsHttpBinding with Windows Authentication and Message Security in WCF from Windows Forms How To - Use wsHttpBinding with Windows Authentication and Transport Security in WCF calling from Windows Forms Video: How To - Host WCF in a Windows Service (Length: 2:45 - Size: 1.2MB) Video: How To - Impersonate the Original Caller in WCF calling from a Windows Form (Length: 2:15 - Size: 1MB) Video: How To - Use basicHttpBinding with Certificate Authentication from Windows Forms (Length: 2:38 - Size: 1.1MB) Video: How To - Use netTcpBinding with Windows Authentication and Message Security (Length: 1:55 - Size: 1.5 MB) Video: How To - Use SQL Role Provider with Username Authentication in WCF calling from Windows Forms (Length: 3:28 - Size: 1.8MB) Video: How To - Use WsHttpBinding with Certificate Authentication with Message Security (Length: 1:01 - Size: 757KB) Video: How To - Use WsHttpBinding with Windows Authentication with Message Security (Length: 1:41 - Size: 781kb) Video: How To - Create and Install temporary Certificates in WCF for Transport Security during Development (Length: 3:45 - Size: 2.3MB) Video: How To - Create and Install temporary Certificates in WCF for Message Security during Development (Length: 3:40 - Size: 2.3MB) Intranet - Web App to Remote WCF to SQL Server Read More...
|
-
How do I use username credentials with IPSec? I'm told that I need to turn on security but my connection is already secure. WCF only permits username tokens to be transmitted over a binding that's secure. If a username and password are transmitted without some way of obscuring their values, then that essentially allows anyone that can read the message to steal those credentials. There are many meanings that could be applied to the word secure, but in this case the definition of secure is only that the binding promises to protect the data that's transmitted by providing confidentiality. IPSec is a way to provide security that's external to service. It can be used together with a binding that doesn’t ordinarily provide security, but the binding has no way of knowing that its security has been upgraded. The mechanism for making security promises on a binding is ISecurityCapabilities. This interface defines the supported protection levels for transmitting messages as well as various other security properties. When security is externally provided, you can use this interface to pretend like the binding is more secure than it really is so that the security capabilities match the actual environment. When using IPSec, requests and responses can be confidential and tamper-proof. This corresponds to a protection level of EncryptAndSign. This is implemented by wrapping the channel to provide a custom set of security capabilities from GetProperty. You'll want to get the ISecurityCapabilities from the underlying channel and then take the maximum of those capabilities together with the capabilities of your external security. Next time: The Pipe DACL Read More...
|
-
Is it possible to configure the protection level for message parts at runtime? Only certain configurations make doing this particularly easy. When using transport security with Windows credentials, the WindowsStreamSecurityBindingElement allows you to directly set the protection level (changing the protection level when using SSL doesn't make as much sense due to the way SSL works). On the other hand, there's no equivalent facility for message security, which will always give you both encryption and signing if you haven't explicitly set the protection level on the contract. There are a few ways to attack this lack of configurability: configure a custom service host to override the contract description during ApplyConfiguration configure a behavior to modify the contract description when behaviors are applied configure a behavior to modify the channel protection requirements when the security channel is instantiated The first approach is a very indiscriminate way to get the job done. Modifying the entire service is almost certainly not what you want to do, so you'd need some way to describe the scope of specific message parts that you want to modify. Behaviors can be much more targeted. The second approach has the hidden downside that modifying the contract description at one endpoint can potentially (depending on order of execution) modify the contract description for other endpoints. This also is almost certainly not what you want to do. Finally, both the second and third approaches have downsides due to being implemented with behaviors. User behaviors are executed after the security validation behavior that is run as part of the service start up. This means that you're unable to declare a protection level on the contract and then later reduce it in the behavior unless the binding is capable of supporting the originally specified protection level. Also, the results of modifying a contract in a behavior don't get reflected in metadata, which makes a variety of tasks harder. In short, none of these options are particularly good. The third approach is probably the most workable although it does suffer a number of downsides. You can base this approach on the following bit of code. public class ProtectionLevelEndpointBehavior : IEndpointBehavior { public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters) { ChannelProtectionRequirements requirements = bindingParameters.Find<ChannelProtectionRequirements>(); // Read More...
|
-
How do I customize the exception text sent back from a custom password validator? If you've looked at the documentation for UserNamePasswordValidator, then the instructions tell you to implement the validator by overriding the Validate method and throwing a SecurityTokenValidationException if you don't like the username and password pair that was provided. A failed validation attempt results in an exception back on the client that is fairly generic. An error occurred when processing the security tokens in the message . Being generic is the correct thing to do most of the time because you don't want to volunteer unnecessary information in your security responses. Subtle differences in how the application behaves can give an attacker hints about the parts of their input that passed validation and the parts of their input that failed validation. However, if an attacker can't use the diagnostic information to their advantage, then you may want to provide more information to make debugging easier. Changing this exception message is relatively easy to do although hard to discover. In your Validate method, rather than throwing a security exception, you can instead throw a FaultException with a custom message. That custom message will be passed back to the client application although the details of the fault will not. public class MyUserNameValidator : UserNamePasswordValidator { public override void Validate( string userName, string password) { // validation logic if (validationFailed) { throw new FaultException( "Here's a description of why validation failed" ); } } } Next time: Configuring Protection Level Read More...
|
-
What are the rules for when a client needs to support Active Directory integration for sending to an MSMQ queue? The circumstances may seen mysterious for when you need the client to be joined to a domain to take advantage of Active Directory integration, but the rules turn out to actually be pretty simple. This should help you avoid seeing errors like the following: Binding validation failed because the binding's MsmqAuthenticationMode property is set to WindowsDomain but MSMQ is installed with Active Directory integration disabled. The channel factory or service host cannot be opened. The authentication mode of the MSMQ transport and the protection level of the message are interrelated, and these both are related to when you need to be using Active Directory. Rather than making you assemble the various combinations as a logic puzzle, I've digested the results into a table explaining when Active Directory is required to pass validation. Protection None Protection Sign Protection EncryptAndSign Authentication None Not required Not supported Not supported Authentication Certificate Not supported Not required Required Authentication WindowsDomain Not supported Required Required The same rules apply to both sides so you're covered for the explanation of the service as well. Next time: Customizing Exceptions for Validation Read More...
|
-
This article is primarily an introduction on protecting message data since the topic overall seems to cause some confusion. The source of confusion is what it means for a service to define a contract for protecting data. Data protection flows from two different directions and at a variety of different scopes. The service can define a minimum standard of protection at various contract scopes. Service contracts cover all of the application data exchanged by the service Operation contracts cover all of the application data exchanged for that particular operation Message and fault contracts cover all of the application data contained in those particular messages Message body and message header contracts cover those particular parts of the message This minimum standard appears as the ProtectionLevel on a contract and comes in three flavors: no protection, protected by digital signing, and protected by encryption (the use of encryption implies a signature as well). Signing prevents people from tampering with the messages while encryption prevents people from reading the messages. These contracts define the application messages that are exchanged. Depending on the protocols you make use of, any number of infrastructure headers or messages may need to be inserted into the data stream to facilitate the exchange of your application messages. This infrastructure data can have its own independent rules for protection. The ProtectionLevel truly is a minimum standard. It is ok for your application to receive messages that are protected better than the minimum standard defines. You may even send messages that are protected better than the minimum standard due to the other direction for flowing data protection. Data can be protected at the wire level by using security integrated with the network transport. For example, if you send data using HTTPS, then there is a level of protection that HTTPS must apply to your messages to transport them even if your contract specified a lower standard. The net protection level is the maximum of that provided by the service and provided by the transport. As long as for every piece of data at every scope that maximum is greater than your minimum standard, then everything works. If that maximum fails to meet your minimum standard, then the service will refuse to send or receive those messages. Next time: Embedding Arbitrary XML in Faults Read More...
|
-
Phil Henning has written about creating a custom username/password validator for HTTP , which is another new feature in Orcas. Like getting access to client IP addresses , creating a custom password validator is a feature added as a result of direct customer feedback. In fact, the two features were added during the same week and were among the last features we did in Orcas for messaging. Before Orcas you could only create a custom password validator if you were using message security. Read More...
|
-
You may have noticed that an HTTP binding is configured with an HttpClientCredentialType whereas an HTTP binding element is configured with an AuthenticationScheme. How are these two settings related? If you want to switch between a custom binding and a standard binding for HTTP, then you need to know how to do the translation. Here's how client credentials map to authentication schemes: HttpClientCredentialType.None becomes AuthenticationSchemes.Anonymous HttpClientCredentialType.Certificate also becomes AuthenticationSchemes.Anonymous. Certificates are used with HTTPS rather than as authentication credentials on top of HTTP. This will be caught in validation if you try to use certificates with the TransportCredentialOnly security mode. HttpClientCredentialType.Basic becomes AuthenticationSchemes.Basic HttpClientCredentialType.Digest becomes AuthenticationSchemes.Digest HttpClientCredentialType.Ntlm becomes AuthenticationSchemes.Ntlm HttpClientCredentialType.Windows becomes AuthenticationSchemes.Negotiate Translation works the same way with proxy credentials and the proxy authentication scheme except that proxies don't have to worry about the issue with certificates. Next time: Get a Real XML Parser Read More...
|
-
How often does authorization occur? Authorization is typically scoped to either messages or sessions. When authorization is scoped to messages, then an authorization request occurs each time a message is sent. When authorization is scoped to sessions, then an authorization request occurs at the start of the session and all of the messages that are transmitted on the session share the authorization outcome. The exact timing of the authorization request can vary depending on whether authorization happens when open is called on the channel or when send is called on the channel for the first time. You can only have authorization scoped to sessions if you have a sessionful channel that incorporates session-based security. TCP is an example of a transport channel that is sessionful and supports session-based security through SSL. Message security is an example of a layered channel that is sessionful and supports session-based security through conversation mechanisms. There are many other channels that are either secure or sessionful but don't have session-based security. Next time: Sharing Contracts Across Services Read More...
|
-
The documentation for configuring a port with an SSL certificate shows example commands using the httpcfg.exe program. Starting with Windows Vista, httpcfg.exe was replaced in function by the netsh program that comes with the operating system. This is more convenient than having to download a separate tool, but it means that the syntax that you need to use changes slightly. Let's assume that you've created a certificate and have already installed it using either the command line or the MMC certificate snap-in. Now, through the MMC snap-in, get the thumbprint of the certificate you want to install to a port if you don't already know what the thumbprint is. This process hasn't changed much so your existing directions should continue to work. The thumbprint for the test certificate I generated was 45d08a92798460d84e4ce157f31662b36c4edbff. When you copy the thumbprint from the snap-in, don't forget to remove all of the spaces. You'll need to run netsh from an elevated command prompt. This first command installs my generated test certificate to port 8000 for the wildcard IP address. netsh http add sslcert ipport=0.0.0.0:8000 certhash=45d08a92798460d84e4ce157f31662b36c4edbff appid={00112233-4455-6677-8899-AABBCCDDEEFF} The only new thing here is the appid, which is a guid that can be used to associate the certificate with a particular application. You can check the installed certificates with the following command. netsh http show sslcert That gives me the following certificate description. SSL Certificate bindings: ------------------------- IP:port : 0.0.0.0:8000 Certificate Hash : 45d08a92798460d84e4ce157f31662b36c4edbff Application ID : {00112233-4455-6677-8899-aabbccddeeff} Certificate Store Name : (null) Verify Client Certificate Revocation : Enabled Verify Revocation Using Cached Client Certificate Only : Disabled Usage Check : Enabled Revocation Freshness Time : 0 URL Retrieval Timeout : 0 Ctl Identifier : (null) Ctl Store Name : (null) DS Mapper Usage : Disabled Negotiate Client Certificate : Disabled Finally, you can remove the certificate associated with a particular address to undo the earlier changes. netsh http delete sslcert ipport=0.0.0.0:8000 Next time: Shutting Down a Channel Read More...
|
-
How do I write a service that gives clients the option to choose between different security mechanisms for protecting a service call? For example, how can I allow clients to choose between certificates and passwords? I think that if the example choice had been between message security and transport security, then many people would have immediately suggested having two bindings for the different security mechanisms hosted on two different endpoints of the same service. There's no reason why you couldn't use the same strategy in this case where the alternatives are two different kinds of message security. The binding configuration process involves a series of choices, including choosing from enumerations of security mechanisms. It's difficult to craft configurations that accept a wide range of valid formats at the same time. This choice of configurations can of course also be made less apparent by moving the choice farther away from the service endpoint. If you create an abstraction by defining an intermediate credential type, then the service endpoint is simplified by only accepting the intermediate credentials and the choice is offered by giving multiple mechanisms to obtain those intermediate credentials. Next time: Trace Transfer Read More...
|
|
|
|