|
|
Browse by Tags
All Tags » Message Security (RSS)
-
What does the InactivityTimeout on a secure channel do? The inactivity timeout on a message security channel controls how long the channel will allow pending security sessions to linger in its cache before giving up on them. This is completely different from the inactivity timeout on a reliable messaging channel, which controls how long the reliable session will live without an infrastructure message before being torn down, and the inactivity timeout in the application, which controls how long the service instance will live without an application message before being torn down. Next time: JSON Service Speed 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...
|
-
Continuing on with the theme of messaging additions in Orcas, today I'll look at some more of the protocols and community-driven features that were added. WS Atomic Transaction 1.1 . Transactions tie together multiple participants in a distributed application. The framework of transactions is built on various coordination protocols between parties. Transactions are a kind of coordination in which either all or none of the parties agree to perform an action. Validation for issued token certificates . We've added support for configuring the certificate validation policy for issued token authentication, similar to the configuration for other certificates that are used for service credentials. Flowing SAML tokens. We've added support to flow a SAML assertion without having to re-sign the token. This allows these assertions to be handled by proxies without special configuration. Using message contents for authorization . We've added support to ServiceAuthorizationManager for performing access checks that make use of the body of the message. WS Secure Conversation 1.3 . A secure conversation is an exchange of multiple, protected messages. Using a conversation mechanism allows a security context to be established across several messages, which performs better than having to exchange security keys with every message. WS Trust 1.3 . Building a secure conversation requires that the two parties exchange security credentials. In order to perform this exchange, the two parties need to establish a trust relationship where they can evaluate the assertions made by the other side. The protocols that I've talked about today and last time are available through the new WS2007HttpBinding and WS2007FederationHttpBinding as updates to the previous web service standard bindings. Next time: Messaging Additions in Orcas, Part 3 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...
|
-
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...
|
-
How can I add some additional information to the request when contacting a token server? Looking at the schema for a RequestSecurityToken message, there clearly is some extensibility space intended for providing additional information in the request. We'll ignore the fact that the actual schema says that the whole thing is an xs:any and only look at the annotated content model because WCF is a lot more likely to be designed with that content model in mind. < xs:element name ='RequestSecurityToken' type ='wst:RequestSecurityTokenType' /> < xs:complexType name ='RequestSecurityTokenType' > < xs:annotation > < xs:documentation > Actual content model is non-deterministic, hence wildcard. The following shows intended content model: < xs:element ref='wst:TokenType' minOccurs='0' /> < xs:element ref='wst:RequestType' /> < xs:element ref='wsp:AppliesTo' minOccurs='0' /> < xs:element ref='wst:Claims' minOccurs='0' /> < xs:element ref='wst:Entropy' minOccurs='0' /> < xs:element ref='wst:Lifetime' minOccurs='0' /> < xs:element ref='wst:AllowPostdating' minOccurs='0' /> < xs:element ref='wst:Renewing' minOccurs='0' /> < xs:element ref='wst:OnBehalfOf' minOccurs='0' /> < xs:element ref='wst:Issuer' minOccurs='0' /> < xs:element ref='wst:AuthenticationType' minOccurs='0' /> < xs:element ref='wst:KeyType' minOccurs='0' /> < xs:element ref='wst:KeySize' minOccurs='0' /> < xs:element ref='wst:SignatureAlgorithm' minOccurs='0' /> < xs:element ref='wst:Encryption' minOccurs='0' /> < xs:element ref='wst:EncryptionAlgorithm' minOccurs='0' /> < xs:element ref='wst:CanonicalizationAlgorithm' minOccurs='0' /> < xs:element ref='wst:ProofEncryption' minOccurs='0' /> < xs:element ref='wst:UseKey' minOccurs='0' /> < xs:element ref='wst:SignWith' minOccurs='0' /> < xs:element ref='wst:EncryptWith' minOccurs='0' /> < xs:element ref='wst:DelegateTo' minOccurs='0' /> < xs:element ref='wst:Forwardable' minOccurs='0' /> < xs:element ref='wst:Delegatable' minOccurs='0' /> < xs:element ref='wsp:Policy' minOccurs='0' /> < xs:element ref='wsp:PolicyReference' minOccurs='0' /> < xs:any namespace='##other' processContents='lax' minOccurs='0' maxOccurs='unbounded' /> </ xs:documentation > </ xs:annotation Read More...
|
-
Can I pass additional user data, such as identity information, in a message secured with a client certificate? This question looks like an earlier one about Windows credentials but has some subtle differences that make it come out with a different answer. The two key differences are: We're talking about securing messages rather than transport connections. Message security headers provide a means of tunneling additional information about the caller. We're talking about passing identity information together with a certificate rather than with Windows credentials. Independent of the particular security protocol, the certificate infrastructure is a way to sign and encrypt data streams so that additional client information can be safely included. With either approach, client information can be included as supporting tokens on the message (typically as either incoming supporting tokens with the message or with the transport token). The supporting tokens sample gives a rundown of supporting tokens for message security. Next time: Differences in Guid Serialization Read More...
|
-
How do I configure the validation process for certificates specified in the service credentials section? There are several configuration settings for controlling certificate validation although they appear in different places depending on what credentials you're talking about. I'll talk about the settings first and then talk about where they appear. The four configuration settings you'll see are: certificateValidationMode for controlling how certificates get validated (ChainTrust/None/PeerTrust/PeerOrChainTrust/Custom) customCertificateValidatorType for specifying the type used by the Custom validation mode ("namespace.typeName, [,AssemblyName] [,Version=version number] [,Culture=culture] [,PublicKeyToken=token]") revocationMode for controlling how the certificate revocation list is checked (NoCheck/Online/Offline) trustedStoreLocation for controlling which system store is checked for negotiated certificates (CurrentUser/LocalMachine) Here's where you'll find those settings. All of these XML paths are relative to the serviceCredentials section. When talking about a certificate for the client half of a duplex service, clientCertificate/authentication When talking about a certificate for a custom issued token, issuedTokenAuthentication. Controlling certificate validation through configuration for issued tokens is only available starting with the Orcas release. When talking about a certificate for a peer node, peer/peerAuthentication Next time: Throwing Exceptions from Service Authorization Manager Read More...
|
-
I want to provide some additional information about the user within the client credentials. Can I do this with Windows credentials? No. Although you can create custom claims and try attaching them to the credentials, the credentials on the wire only contain the information that's part of the standard Windows token. Any additional information gets lost. The same is true for many other types of credentials that weren't designed for extensibility in the wire format. SAML tokens were designed for extensibility and permit attaching additional data. If you've got a mechanism to attach SAML tokens to a message, such as with message security, then you can load the token up with claims and additional identity information and flow the token to the other party. The token helps support the client credentials and other security information. You can read about SAML tokens on MSDN to get started. Next time: Custom Cookie Handling 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...
|
-
How do I supply additional security tokens beyond those needed to sign and encrypt the message? How do I use those tokens on the service? The additional security tokens are configured through the binding. The client binding needs to be configured with the list of tokens that should be sent to the service. The service binding needs to be configured with the list of tokens that it should expect to receive and authenticate. The tokens are then scoped to either a single operation or all of the operations on an endpoint. This leads to multiple buckets of tokens on the security binding element. EndpointSupportingTokenParameters OptionalEndpointSupportingTokenParameters OperationSupportingTokenParameters OptionalOperationSupportingTokenParameters The tokens are authenticated at the service, and once in your service code you can enumerate them from OperationContext.Current.SupportingTokens. Next time: Request Queues Read More...
|
|
|
|