|
|
Browse by Tags
All Tags » Answers » 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...
|
-
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...
|
-
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...
|
-
When authorizing a client, how do I tell the difference between a connection with anonymous security and a connection with no security? Anonymous security turns out to offer a surprising amount of protection even though you have no idea who the caller is. With anonymous message security, it's still possible to authenticate the server using the server's credentials and it's possible to protect messages using signing and encrypting. For that reason, some people will want to behave differently if clients are anonymously authenticated than if no security was applied. Much of the information about client security is stored in the thread local ServiceSecurityContext. ServiceSecurityContext is actually about the remote endpoint, which is the client when running on the service and the service when running on the client. The simplest test is to look at whether a ServiceSecurityContext exists or not by checking ServiceSecurityContext.Current for null. If there's no ServiceSecurityContext, then you know that no security was applied. ServiceSecurityContext also has an IsAnonymous property that tells you whether information exists about the current client connection. However, there are some cases where a ServiceSecurityContext is created even if there was no security for the client connection. If you have customized authorization through an extensibility point, such as installing a ServiceAuthorizationManager, then WCF may have created a ServiceSecurityContext despite there not actually being any security because it usually makes the authorization logic simpler. In that case, you could look at the tokens associated with the request and determine that some form of security was applied if any kind of token exists. Next time: Ignoring Bad Requests Read More...
|
-
I'm trying to use a username and password with message security but I'm being told that I need to have a certificate on the client or the server depending on the configuration. Is it possible to send username credentials without issuing a certificate? The reason a certificate is being specified here is because without an additional security mechanism, the password for securing the message would be transmitted without protection. Anybody could intercept the password on its way to the server. There are several configurations that solve that problem by encrypting the password, for which nearly all of the practical methods make use of a certificate. The most common configuration is to use transport security to protect the exchange combined with the message level credentials. You don’t have to use a certificate here but it would rarely make sense to have username credentials if the other transport security mechanisms are available to you. In rare cases, you may have some external way to protect the messages such that WCF can't detect the presence of the protection. For example, you could transmit the messages over a secured network, such as a VPN. There is probably still a certificate in that case, but it is buried under other software. Although the messages are secure, WCF rejects the configuration. To work around that problem, you can add a layered channel above the transport that lies about the ISecurityCapabilities of the transport channel so that the level of protection for the message is properly reported. Next time: No Session Before Sending Read More...
|
-
Why does a service call require creating multiple connections when using message security? Several common uses of message security require sending multiple messages, particularly on the first call for a given proxy. For example, one way to establish a security context is by making use of a token service. The client first connects to a token server to request a security token. The token server responds with a security token. Then, the client connects to the original server and passes in the security context token. These requests may be accompanied by multiple rounds of challenges that require sending additional messages. HTTP is particularly susceptible to requiring multiple connections in a scenario like this but other transports can require multiple connections as well because more than one server may need to be contacted. The important point though is that the bulk of the work happens with the first call for a given proxy. If you open and close proxies frequently, then you'll pay this cost many times. If you reuse proxies appropriately, then you'll reduce the number of messages required and hopefully the number of connections required as well. Next time: Metadata is Locked 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...
|
-
Can I secure a message without having to buffer the message in memory? The answer to this question is yes and no, depending on what the word secure is supposed to mean. There are differences between the operation of transport-level security and message-level security, as well as potentially differences between particular security algorithms. Transport level security algorithms have historically composed very well with streaming. SSL does an initial handshake to exchange security information and then sets up a security session between the two parties. The security session doesn't place any significant requirements on having an available buffer of message content and the session lasts until one of the parties decides to disconnect or renegotiate the connection. Message level security algorithms generally don't attempt to optimize for transmission efficiency as compared to transport level security algorithms. The signing and encryption facilities of WS-Security require an examination of the complete message contents before the message can be secured. This obviously does not compose with streaming although it doesn't particularly impact pseudo-streaming approaches, such as chunking. Message level security provides capabilities not found in transport level security, such as protection over multiple hops, but these features do not come for free in terms of performance. Next time: Supporting Multiple Security Mechanisms Read More...
|
|
|
|