|
|
Browse by Tags
All Tags » Answers » Security (RSS)
-
How do I force propagation of changes to information about a certificate revocation list after an update? A service is going to have several kinds of caching around the information that links the certificate to revocation information. The first kind of caching is based on the revocation mode of the certificate. A revocation mode of NoCheck disables checking on the certificate while a revocation mode of Offline directs checking to use a cached certificate revocation list. A revocation mode of Online gets the freshest data. The second kind of caching is at the service process. Information is stored in memory as long as the process continues to run to reduce the number of active checks required. This memory cache is cleared when the process restarts. The third kind of caching is at the machine. Information is cached by the machine for a limited time to again reduce the number of active checks required. The machine cache can be viewed by running "certutil -urlcache" and the same command is used to delete or force updating of specific cache entries. Next time: Getting Rid of Namespaces Read More...
|
-
How do I find the address of a client connection to make a trust decision? Don't base security decisions on the perceived client address. Any address that we have comes from the underlying socket implementation and could be spoofed. The data that the socket has is sourced by the client. You should be using a source of information that has a verification process that the server trusts, such as a certificate, to distinguish clients. Next time: Reader Trends Read More...
|
-
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...
|
-
Whenever my service receives a message the service operation fails because the user identity is not mapped to a Windows identity. How can I make this mapping? What's probably going wrong is that the user identity is specified by a certificate but there's no active mapping from the client certificate to a Windows account. By default, no mapping is performed. You can enable certificate mapping by setting mapClientCertificateToWindowsAccount on the service credentials to be true. < serviceCredentials > < clientCertificate > < authentication mapClientCertificateToWindowsAccount ="true" /> </ clientCertificate > </ serviceCredentials > The actual mappings are not provided by the service configuration. Mappings are typically defined using the certificate mapping features of either IIS or Active Directory. IIS mappings can be varied from web site to web site but it's difficult to manage more than a small number of mappings. Active Directory mappings are the same all across the directory but the centralized directory makes the mappings easier to manage. Next time: How WebServiceHost Works Read More...
|
-
How can I run a service operation hosted in IIS using a specific identity? There are two ways for your operation to be running using a specific identity: start off running under that identity; or, start off running under a different identity and change to the right identity later. You can make either approach work although having to change the identity every time a service operation is called will introduce a small performance hit. Let's look at the two options. Impersonation is a mechanism that you can use to change to the right identity when the service operation is invoked. I've talked about impersonation in the past, mostly for impersonating the caller rather than impersonating a specific identity. However, impersonating a specific identity works in much the same way in terms of the Windows calls involved and generally works simpler in terms of the service setup required. That simplicity partially comes from not having the client involved in the act of impersonation but also because impersonating a specific identity doesn't have the same level of configurable options for automatically applying impersonation rules. The application pool is a mechanism that you can use to start with the right identity. This approach assumes that your service always wants to be running under the same specific identity. That partially covers the case of those missing configuration options. By default your application pool runs under the Network Service account. You can change that application pool identity to be any specific identity you want. Configuring Application Pool Identity with IIS 6.0 (IIS 6.0) IIS 7.0: Specify an Identity for an Application Pool This may require reorganizing how applications map into pools because the identity is shared by everyone in that pool. Next time: Why Dual is Reliable 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...
|
-
I'm trying to connect to a service on the same machine using Windows credentials and getting an authentication error. I can connect to the service from other machines. I can also connect to the service if I set up an endpoint that listens on the loopback address. What's going on here? These symptoms suggest that the client on the local machine is being rejected by a security check in Windows on the loopback address. This check prevents you from connecting on a loopback address unless the service was specifically configured to listen on the loopback address. The reason for this check is to stop a security attack called a reflection attack. A reflection attack redirects a security challenge back to the same machine in hopes of getting the machine to answer its own challenge. Since the security check is in Windows rather than in WCF you shouldn't expect a simple knob on your service to fix this. However, you can try configuring the client with a user principal name for the service. Having a UPN helps you pass the check because in some cases it allows Windows to recognize that an attack is not taking place. For help configuring Windows, including some workarounds that I'm not sure I'd recommend, check out this KB article related to the loopback check . Next time: Why Ordering is Ignored 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...
|
-
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 do I restrict access to an operation to particular Windows users? There are three standard ways of doing something in WCF: through code, through attributes, and through configuration. Let's try to solve the problem using each of these methods. Restricting access through code is done by creating a custom ServiceAuthorizationManager. Restricting access to a service operation could be done this way by looking up the service operation during the access check and comparing the caller's SID to the list of approved users. This method seems pretty clunky because it brings in a lot of service machinery unrelated to the service operation we want to secure. However, this method also seems pretty flexible because we can be very creative about how the authorization is performed if we want to go beyond simply evaluating membership. Restricting access through attributes is done by making PrincipalPermission demands. Restricting access to a service operation could be done this way by decorating the service operation with role or user based demands. The best practice recommends using roles instead of specific users because it helps with administration, which is probably good advice for all of these approaches. Using principal permissions requires actually having the right principal for the current thread. Some extra code may end up being required anyways if the client invocation doesn't propagate the right kind of information. Restricting access through configuration is done by setting up an external authorization provider. When in compatibility mode, there is some handy functionality provided by the ASP.NET pipeline to provide authorization integrated with ASP.NET membership providers. Even without ASP.NET though, the generic Authorization Manager can be used to manage and provide roles. I like using the attributed-based method but that's because I don't like to type a lot of code and because I rarely need to worry about deploying services on multiple systems. Each of the methods has its own strengths and weaknesses so there isn't a universal choice that's best for everyone. Next time: Suppressing Transactions During an Operation Read More...
|
|
|
|