I am trying with various SDK-based tools to interact with an on-premise instance of MS Dynamics CRM 2015. This instance is hosted by a third party provider, I have an admin account for it.
Login and normal admin operations on the web interface work as expected.
Whenever I try to access the CRM through the SDK, I get this cryptic error message: An unsecured or incorrectly secured fault was received from the other party. From this question ("An unsecured or incorrectly secured fault was received from the other party") I expect it to be a client-server time offset, but no better evidence of it. I'd like to get any relevant logging, including the WCF logs.
How can I retrieve thos WCF logs?
Related
I am accessing a third party web api from my WCF application. While development I was able to access those APIs but when I deployed my WCF to IIS, its not able to connect to the web API and throwing me the following error:
"System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it X.X.X.X:443"
Just to make sure that my server is fine where I deployed my WCF. I tried accessing those web api from a simple console application. It accessed those apis from my development machine and from the server machine as well. Now I feel the culprit is not the third party web api server, but something goes wrong when a WCF service access' a web-api hosted in IIS.
Please help!!!
Finally I found the issue. IIS runs my WCF under user 'network service' or 'application pool identity'. These are nothing but window built-in users which has limited access. When I tried accessing third party API from the console application it worked because it was running under my user credential which has admin credential. So I concluded that when an application making cross-domain call then it should be running under a user with enough credential to make such calls.
Solution was to change my application pool identity to a admin user identity (I changed it to my logged in user). It worked and making calls to third party API from WCF service
I'm having a hard time wrapping my head around some architectural elements to securing a core WCF service that is consumed by many different applications.
Internally, we have an application that allows HR folks to update a peron's details. This is contained in a WPF app. Externally, we have a website that would allow individual people to authenticate (throuh an AD Membership provider) and update their details.
We don't want users to be able to see other user's information (for obvious reasons). But we don't want to host this service inside the same web application that the users would log into. Here is how the architecture would look from a visual studio perspective:
ServiceApplication
WpfApplication
MVCWebApplication
They don't exist inside the same domains, for example, the service application would be hosted at http://www.service1.com/Service.svc and the mvc application would be hosted at http://www.updateyourprofile.com . So a user logs into http://www.updateyourprofile.com and we'd like to hit a Wcf service via JSON. Both the service application, wpf application, and mvc web application would use AD credentials to authenticate. But how do we secure the service so that users who log into the mvc web application can only see their information?
Most of the examples I see say to use the HttpContext.Current.User check inside the service. But since the user authenticated at a different site, how does the cookie transfer? Do you end up having to publish your service inside the same web application that you want to consume so that the cookies travel transparently?
Or is it just not possible to have a centrally located service with disparate applications that use the same authentication store to determine who has access to what on the service?
What you are looking for is some kind of federated authentication system which is used by all the entry points. That is what Windows Identity Foundation can help you to build.
Inside each application, access control would be claims-based, according to the claims embedded in each user's security token issued by the authentication system.
There's an entire book on the subject on MSDN.
I have a silverlight application which makes use of RIA Services to communicate with the server and I am using membership API with Forms Authentication. The problem I am facing now is that the app throws exception when it tries to access the server via RIA after the original login has expired (authentication timeout). This is expected but the error doesn't say exactly what the problem is so that I can handle it. Any help would be greatly appreciated.
A service I have in WCF occasionally goes down due a problem with a COM component. While I am troubleshooting I would like to setup another host to make regular calls to this service to monitor availability.
It is slightly more complicated that a simple HTTP call though as the service is secured by SSL and WCF authentication (username / password). I'd also like to be able to parse successful calls to see if they return warning / fail states from my code.
Would you recommend any monitoring providers for this or is it beyond the simple monitoring they normally provide?
Regards
Ryan
You could enable WCF logging and auditing facilities either on the server or the client to produce a log of all traffic. Then you can analyze the results using the WCF Service Trace Viewer Tool provided in .NET Framework 3.0 and 3.5 SDK.
In your situation I would probably enable logging only at the message level. This will reduce the amount of information that ends up in the log file and will help you focus on analyzing the data that's actually being sent back and forth from the services.
The environment is in-house service based applications running in a Windows environment with WCF.
There are several "middle-tier" ASP.NET Web Applications and Web Services that authenticate the final client using Windows authentication, and use ASP.NET Roles to set Thread.CurrentPrincipal to a suitable RolePrincipal. These applications each run under their own service account, which is a domain account, and are considered to be trusted subsystems.
Some back-end WCF web services that may only be accessed by these trusted "middle-tier" applications. They use Windows Authentication to limit access to the service accounts used by these applications.
We now have a requirement for the back-end services to audit the identity of the final client whose call to the middle-tier application resulted in the call to the back-end service.
To avoid making any application changes, I was thinking of writing an endpoint behavior which inserts a SOAP Header with the final client's identity into the request sent to the back-end service. Note that the middle-tier applications are trusted, so no authentication of this SOAP Header would be required.
It occurred to me that this requirement may not be unique, so before I invent my own SOAP Header for this purpose I thought I'd ask if there exist any standards in this area I could reuse?
It sounds like you're after WCF Impersonation, check out the MSDN Link or Google that search term for more info. I've never used it myself so can't fully advise, but hopefully it's what you're after. Good luck
Edit: Does the WCF OperationContext not carry through the identity to the second phase? (OperationContext.Current.ServiceSecurityContext.PrimaryIdentity.Name)