CoderCoderCoder

Federated security is interesting because it presents such a clear break between a service and the security (authentication and authorization) that protects it. Plus -- and this is the part I find even more intriguing -- federated security allows for trust . We'll look trust a little more in a moment but let's first consider that first point, the clear line between the service and its security. With federated security, a service requires clients to authenticate using a security token issued by a security token service. It's the security token service that is responsible for authentication and access decisions. Typically, a security token service is within a specific domain, such as an organization, and refers to policies set for that domain. Where federated security becomes really interesting is when a client in one organization accesses a service in another organization. In the example above, we have two organizations, Organization A and Organization B. Both orga

WSDualHttpBinding is similar to WSHttpBinding but provides for -- you guessed it -- duplex communications. As with most things, there's more than one approach you can take to achieve nearly the same results. For instance, you don't have to use duplex communications between a service and a client to provide near-real-time updates -- you could have the client poll the service. But, the big drawbacks to polling are: The client is only as up-to-date as its last poll. If something occurs on the service side of things between polls, then the client won't know about it until its next poll. Polling consumes resources -- even when the service has nothing new to report. Each request takes network resources and creates work for both the client and server. If you poll frequently, then you rack up a lot of expenses. And, if there are periods where nothing happens then you are expending resources for no reason. Long polling  is one workaround to these problems. Wikipedia provid

One of the most popular system-provided WCF bindings is WS-* binding, Commonly referred to as WSHttpBinding, this binding provides a secure and reliable approach.The binding is useful where: You suspect software, system, or network failures may hamper the communication between clients and your WCF service. You need basic security, such as encryption and authentication. The binding implements the following specifications: WS-Reliable Messaging for reliability WS-Security for message security and authentication. Messages are encoded as Text/XML and are transported via HTTP. Note that WSHttpBinding is only for non- duplex  suitable service contracts. Also, know that both service and client must use WSHttpBinding . One cannot use BasicHttpBinding while the other uses WSHttpBinding even if no security is used and the encoding is the same. The disagreement between the two bindings arise from different versions of SOAP being used. Updating the Service to Support WSHttpBin