Browse by Tags

• Answers
• Channel Extensibility
• HTTP
• Indigo
• Message Security
• Reliable Messaging
• Transport Security
• Transports

• The Pipe DACL

  When a named pipe channel listener creates a new named pipe it has to supply a discretionary ACL that describes who can connect to the pipe. Here is how that DACL is constructed: An access control entry is added to deny GENERIC_ALL access to the well-known network SID (S-1-5-2). Access control entries are added to allow GENERIC_READ and GENERIC_WRITE access to a list of SIDs that is defined on the binding element. The default is to allow the well-known world SID (S-1-1-0). Since this list is an internal setting, you will almost always be using the default. An access control entry is added to allow GENERIC_READ and GENERIC_WRITE access to the well-known creator owner SID (S-1-3-0). And that's how the DACL gets built. There are a few other settings as well required to create the pipe if you're interested in their values. The pipe is bidirectional (PIPE_ACCESS_DUPLEX), data is written to the pipe as messages (PIPE_TYPE_MESSAGE), data is read from the pipe as messages (PIPE_READMODE_MESSAGE), we use overlapped IO (FILE_FLAG_OVERLAPPED), and if this is the first pipe created by the listener, then we need to say that more pipes are coming (FILE_FLAG_FIRST_PIPE_INSTANCE). Next time: Writing Multiple Detail Elements in Faults Read More... Posted Tuesday, April 01, 2008 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Transports, Channels, Security

• No Session Before Sending

  When you create a sessionful channel, that implies the existence of some correlation factor for all of the messages that are associated with the session. For example, the correlation factor for a TCP session is that all of the messages travel over the same TCP connection and the correlation factor for a WS-RM session is that all of the messages belong to the same reliable sequence. There is no way to identify what the correlation factor is at runtime but the channel provides an ISession object so that one correlation factor is distinguishable from another. This is done just by having a unique identifier associated with the session. Since the session and session identifier are part of the channel interface for a sessionful channel, it's possible to try to access the session as soon as the channel is created. However, there's no guarantee that the session information is valid if the channel is not open at the time. Here is how some of the standard client-side sessions behave if accessed after the channel is created but before the channel is opened. TCP session: A unique identifier is generated on the fly, this identifier will continue to be used after the channel is opened. Reliable session: The session identifier is empty, an identifier will be created when the channel is opened. Security session: Trying to access the identifier produces a runtime exception, an identifier will be created when the channel is opened. In short, you can't rely on any meaningful behavior for the session until you're ready to start sending data. Next time: Substituting for TryAccept Read More... Posted Thursday, October 25, 2007 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Channels, Security, Reliable Messaging, Message Security

• Faking Channel Security

  I occasionally see people asking how they can fake the security capabilities of a binding. These questions often start off with "I'm getting an error message that a message's required protection level is not being met". Now, I'm not precisely sure why you'd want to fake the security capabilities in this case. After all, the application developer is in charge of both specifying the protection requirements of the messages and choosing what channels to use. If they're getting this error message, then it more than likely means that this helpful check has detected a problem somewhere in their design. There are a few rare reasons why you'd want to fake this, but they mainly involve transmitting over specially secured networks. However, it turns out that faking security capabilities is exactly the same as legitimately specifying the capabilities of a custom channel so I might as well explain that! Security capabilities are found by querying the channel stack with GetProperty for an instance of ISecurityCapabilities. This call should be supported on the binding element of channels that implement message or transport security. Transport channels should respond with something, even if it is to say that they don't support any kind of security. Everyone else can just delegate the call to their inner channel (which is typically what you do by default for any type you don't know about). public interface ISecurityCapabilities { ProtectionLevel SupportedRequestProtectionLevel { get; } ProtectionLevel SupportedResponseProtectionLevel { get; } bool SupportsClientAuthentication { get; } bool SupportsClientWindowsIdentity { get; } bool SupportsServerAuthentication { get; } } The fields here should be self-explanatory, you either support a particular feature or you don't, but let's look at examples from some of the existing channels. HTTP doesn't support any protection on requests and responses, neither encryption nor signing. HTTP supports client authentication when in any security mode but Anonymous. It only supports server authentication when using Negotiate security. Windows identities are supported whenever client authentication is. On the other hand, HTTPS provides both encryption and signing for both requests and responses. HTTPS always does server authentication. It supports client authentication and Windows identities whenever HTTP would plus whenever client certificates are turned on. You can quickly get a sense of the differences between HTTP and HTTPS by looking at Read More... Posted Wednesday, January 17, 2007 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Transports, Channels, Transport Security, HTTP, Answers, Channel Extensibility, Security