Browse by Tags

• Bindings
• HTTP
• Indigo
• Messages
• Standard Bindings
• Transport Security

• Hosting Identity

  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... Posted Wednesday, April 16, 2008 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Answers, Security, Hosting

• Preventing Anonymous Access

  How do I prevent clients from accessing my service anonymously? I've changed the settings in IIS from Anonymous Access to Integrated Windows Authentication. However, now I'm getting the error message: "Security settings for this service require 'Anonymous' Authentication but it is not enabled for the IIS application that hosts this service." Disabling anonymous access requires coordinating the settings in IIS and in your service configuration. Those two sources must be in agreement about whether anonymous access is expected. IIS is already using Windows authentication in this case, so let's look at what needs to happen to the service configuration file. I'm assuming that this is IIS6 so the only network transport we're talking about here is HTTP. There are two cases depending on whether you want the protocol that gets exposed to be HTTP or HTTPS. The simplest is to keep using HTTP since that's probably what you were using if anonymous access was allowed in the past. To switch off anonymous access with HTTP, you need to set the security mode to TransportCredentialOnly. < basicHttpBinding > < binding > < security mode ="TransportCredentialOnly" > < transport clientCredentialType ="Windows" /> </ security > </ binding > </ basicHttpBinding > Note that TransportCredentialOnly is not supported for every binding (in this case we're using BasicHttp). For WSHttp, the only choice is going to be to use HTTPS. To switch off anonymous access with HTTPS, you need to set the security mode to Transport. < wsHttpBinding > < binding > < security mode ="Transport" > < transport clientCredentialType ="Windows" /> </ security > </ binding > </ wsHttpBinding > Other bindings can be made to work in this situation as well, including custom bindings. I'm just showing you the most common examples. The key in both cases though is that we're getting transport security with the right kind of credentials associated. Next time: Writing Binding Element Essentials Read More... Posted Friday, March 23, 2007 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Bindings, Transport Security, HTTP, Answers, Security, Hosting, Standard Bindings

• Securing Custom Headers, Version 2

  Last time we were looking at the problem of securing a dynamically generated message header . We saw one solution to that problem, which was to add a behavior that updated the protection level for the desired message part. That solution is quite simple but it isn't perfect. The execution of this behavior comes rather late. Anyone that inspects the service description in the meantime, such as for metadata generation, won't see the protection level that we want to use. How early can we make the update to the security settings? Well, potentially very early. We could subclass ServiceHost and override ApplyConfiguration to make the changes during creation of the host . That may even be too early as it prevents us from working with anything that is added to the service description through code rather than configuration. However, we could similarly make the changes some time after we get the service host object back but before it was opened. This would let us plug in before any behaviors started execution. The choice is yours. The downside of this method is that it is a more treacherous route to get to the message header. Starting from the service host we need to get the endpoint that we're going to modify (usually by contract or address). From the endpoint we can get the operation by action name. From the operation we can get the right message by name. The default names are canonically derived from the operation action and direction. Unlike before, separating incoming and outgoing messages here is a lot murkier. From the message though, we can refer to the message header in the same way and set its protection level. Here's all of that in code using some example values. ServiceEndpoint endpoint = host.Description.Endpoints.Find( typeof (IService)); OperationDescription operation = endpoint.Contract.Operations.Find( "Action" ); MessageDescription message = operation.Messages.Find( "http://tempuri.org/IService/ActionResponse" ); MessageHeaderDescription header = message.Headers[ new XmlQualifiedName( "aheader" , "http://tempuri.org/" )]; header.ProtectionLevel = ProtectionLevel.Sign; Next time: Keeping Traces Up to Date Read More... Posted Friday, January 19, 2007 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Answers, Security, Messages, Hosting