I'm sure there's an elegant solution to the problem but I just can't get my head around it. I am trying to call a web service from within a Windows service. The web service is secured (using Windows authentication). The account that the windows service runs under does have the rights to call the web service but I can't figure out how to get those credentials and send them off to the web service. The web service is WCF and is hosted on the same machine (in IIS) as the windows service.
You should be able to use something like this:
var myService = new myThing.Service();
myService.Credentials = System.Net.CredentialCache.DefaultCredentials;
Have you tried enabling integrated authentication (NTLM) for IIS? In my view that should allow you to call web service if the windows service user account has rights to invoke the service. you need not explicitly extract credentials.
Related
I have a simple azure web app that I'd like to be accessible only to another azure web app. Is there a way to achieve this very simple thing without having to pay arm and leg for Azure Service Environment
If you want to deploy your Azure App service on a virtual machine , there is no way to do that. But if you deploy your web application on an Azure VM your requirement can be implemented easily : just using this feature , your web app service can access your web application hosted on virtual machine in Azure VENT and your web application is 100% secure as there is no route to access it for public accesses.
If Azure web app service is necessary for your web application,you can adding your first web app service outbound IP into IP whitelist of the web app service that you want to limit accesses by others . For how to find outbound IP of web app service, pls refer to this doc
However, you know for common Azure app services ,outbound IPs are shared with other common Azure web apps , so this way is available but not so perfect.
Using managed Identity to protect your web app service will be a better and easy way I think: Requests that have passed Azure AD auth will be able to access your web app service.
What's more , in previous link , all ways to protect your web app service have been listed under "Secure app" section , which will be helpful for you too.
I have a WCF self-hosted web service (hosted in my Windows service under Local System account). Web methods have [OperationBehaviorAttribute(Impersonation = ImpersonationOption.Required)] attached. NTLM authentication is used.
In my web method's implementation I impersonate the caller and do some stuff. For this I use ServiceSecurityContext.Current.WindowsIdentity. If I don't give proper credentials when calling the web method then web service would return "401 Unauthorized".
When I call the method from Chrome then the windows identity and impersonation work great. I can create a new process under impersonated user, which will spawn in Windows session of that user (different from 0). Firefox also works when I add "localhost" string to network.automatic-ntlm-auth.trusted-uris preference. But when SoapUI calls the method then this windows identity is not set up properly. Web method is called, so NTLM works to a degree, but it just doesn't work properly. A call to ServiceSecurityContext.Current.WindowsIdentity.Owner.IsAccountSid() returns false (Owner is not a user account, but built-in "Administrators" group). Creating a new process while impersonated would create it in Windows session 0.
I've looked into HTTP communication with Wireshark, and NTLM handshake looks different between Chrome and SoapUI. No idea what to do with that information though.
How to make SoapUI to work properly with my web service and NTLM?
While I don't know how to fix the problem with WCF I switched to Web API and OWIN, and now I have a working solution.
_ Azure newbie alert _ I have a WCF web service (deployed on prem) that uses windows authentication. I just built an App Service on Azure that among other things it needs to retrieve data from this web service. I don't have control over the authentication mode it uses nor can I change it, so is there any way at all to configure my App Service to use Azure AD and authenticate using a windows account (same account used on Azure portal)?
On a side note, I communicate with the WCF service on prem through a hybrid connection on the App Service. Not sure if that makes any difference
I have created a WCF service that is hosted using windows service.
The windows service is running under LocalSystem under services.msc
I only want to allow accept requests from my asp.net UI users who are part of dmain's user group?
Eventually we will have multiple UIs and I want to not write security checks code in the UI.
How do I check who is making the call so I could do something like:
if (incomingUserGroup != "GroupRequired)
{
throw NotAllowedException();
}
You can inspect the security credentials of the calling user through the OperationContext. This will be subject to your having made the service available on an endpoint using a secured binding such as netTcpBinding or WSHttpBinding.
OperationContext.Current.ServiceSecurityContext.WindowsIdentity.Groups
I have various bits of functionality implemented in WCF web services which are currently consumed by an Excel client via a local COM-visible library. I wish to implement some of the front-end functionality in a web client. I set up my client proxy using
dataChannel.Credentials.Windows.AllowedImpersonationLevel = TokenImpersonationLevel.Delegation;
ASP.NET impersonation is turned on as is windows authentication (no anonymous). When web services and web site are hosted on the same server there are no issues and the desktop user's credentials are passed from browser to web site to WCF perfectly. However, when web site and web services are hosted on different boxes (same domain, intranet only) I get 401 authentication errors. What am I doing wrong?
It sounds like you are suffering from the kerberos "double hop" problem. By default windows does not pass the kerberos authentication token onto another server so if you have user accesses webserver A and authenticates, webserver A accesses service on webserver B. WEbserver A does not pass the auithentication through to webserver B so you get a 401. I think this article should help you enable kerberos delegation between the web site server and the web service server