wcf-security

With almost all of the (secure) WCF service endpoints in my application, if the client's system clock is set too far in the future or past, I get an exception from WCFs Clock Skew mechanism (described here: http://www.danrigsby.com/blog/index.php/2008/08/26/changing-the-default-clock-skew-in-wcf/ ). However the one endpoint where my Login() method is implemented never throws this exception even though it has transport security enabled (naturally no credentials are required for it). Why isn't the "Clock Skew mechanism" working for this endpoint? Maybe it's because clientCredentialType is set to

I'm trying to make a self hosted WCF app that uses nettcpbinding but works in an environment without a domain. It's just two regular windows pc's, one is the server and the other one will be the client. The problem with this is that when I try to get the client to connect it's rejected because of the security settings. Can you please point me in the right direction as to how I can get this scenario to work? Should I (if possible) disable security? Is there another (hopefully simple) way to accomplish this? Regards, Daniel If you'd like to disable security for testing purposes, in the App

I have a WPF client that connects to a WCF service, and I want to lock down some of the functionality so that only certain users can perform certain actions. The WCF service impersonates the client user when executing service methods. The OS is Windows XP. I was reading this question as part of my investigation into the best way to apply user roles to features in my application (I want to assign users to AD security groups, and then check IsInRole), and am worried that cached permissions will allow users who have had their permissions reduced to access functionality they no longer have

I have a service that uses a custom "UserNamePasswordValidator" and need to save the validated user object to be able to retrieve it later in the service. How can I do this? Or how can I access the credentials of the user later in the service? /Viktor The short answer is that the most correct option is to create an IPrincipal instance that represents the authenticated user and put it on Thread.CurrentPrincipal . All code running on the same thread later in the service will be able to access the authenticated user through Thread.CurrentPrincipal. This is the standard way of dealing with

I have a WCF service I'm trying to host on our production web server (IIS6). I've set the web up and tied our cert to the web. When I try to browse to the service url, I receive the following error in the event log : The exception message is: It is likely that certificate 'CN= .mydomain, OU=Secure Link SSL Wildcard, OU=I.T., C=US' may not have a private key that is capable of key exchange or the process may not have access rights for the private key. Please see inner exception for detail.. ---> System.ArgumentException: It is likely that certificate 'CN= .mydomain.com, OU=Secure Link SSL

Good Day Everyone... Apparently, I'm not setting-up impersonation correctly for my WCF service. I do NOT want to set security on a method-by-method basis (in the actual code-behind). The service (at the moment) is open to be called by everyone on the intranet. So my questions are… Q: What web-config tags am I missing? Q: What do I need to change in the web-config to make impersonation work? The Service Web.config Looks Like... <configuration> <system.web> <authorization> <allow users="?"/> </authorization> <authentication mode="Windows"/> <identity impersonate="true" userName="MyDomain\MyUser"