I am using a windows identity impersonation on a WCF service. Is it necessary to call identity.Impersonate() each time when I need impersonation, or can WCF do it for me? If it can, then what configuration should I specify?
You can set this in the client configuration using allowedImpoersonationLevel of the windows element:
<windows allowedImpersonationLevel="Identification/Impersonation/Delegation/Anonymous/None"
allowNtlm="Boolean"/>
This page explains more and shows you where this element fits in the config file.
http://msdn.microsoft.com/en-us/library/ms731356(v=vs.100).aspx
Related
I have a web service running outside of .net that I need to invoke from a .NET client.
I was given a .NET client written in Visual Basic to test with.
The .NET client can access the web service with a clear-text SOAP message using basicHttpBinding.
I can configure a policy/binding for the external web service to use the Kerberos token for Message Level Protection and authentication. I can access this web service from the .NET client by modifying the configuration file to use wsHttpBinding.
Now, the requirement is to use the Kerberos token for authentication only and not sign/encrypt the SOAP message. That is, I only need the tags in the SOAP header. I have this configuration working on the external web service, but now I want to modify the configuration file so the .NET client only sends the and does not sign/encrypt any part of the SOAP message.
Is it possible to modify the .net client's .config file to do this?
My understanding is that basicHttpBinding can not be modified to use a Kerberos token (only UserName/Certificate).
I've tried disabling signing/encryption in wsHttpBinding via an attribute such as "defaultProtectionLevel=Sign/SignEncrypt/None", but this isn't available in wsHttpBinding (or I can't find it). I can only disable or enable message level protection and authentication with .
I've also tried building a customBinding, but can not disable signing/encryption and use the Kerberos token for authentication only.
Does anyone have a solution or some tips that could point me in the right direction to go about solving the above issues?
I have an asp.net 4 application that hosts a WCF REST service via WebServiceHost...
WebServiceHostFactory factory = new WebServiceHostFactory();
routes.Add(new ServiceRoute("mss", factory, typeof(ModuleStorage)));
My application has a custom authentication module and requires IIS Anonymous access. I also have Windows Integrated so that I can debug my application.
The issue I am having is the WebHttpBinding created by the WebServiceHost does not support having two authentication methods enabled in IIS. I can turn off Win. Auth. and it works but I can not debug.
So my question is... Can I enable WebHttpBinding to support both or can I somehow enable debugging without Win. Auth.
This service must be hosted as part of the application and I need a way to debug it.
Try debugging WCF REST Service using Fiddler, see the following links for more informations :
http://www.codeproject.com/Tips/213007/Debug-WCF-REST-Service
Depends what you are trying to debug. You could always trace the WCF service using SvcTraceViewer. Here is the config you can use on the server.
I ended up using ASP.NET Web API. I have to say so far I am a big fan!
http://www.asp.net/web-api
how can I use ASP.NET session in WCF? or is there any alternative way to use "ASP.NET Session" like structure in WCF such as data storage?
Try having a look as ASPCompatibityMode with WCF and you then turn it on and share the session in the service method
You cannot use the ASP.NET session, since you can easily run a WCF service without having the ASP.NET engine fired up, eg. using a netTcpBinding.
There is however session handling native in WCF, where you can specify this on the service contract using the SessionMode parameter on the ServiceContract attribute.
See http://msdn.microsoft.com/en-us/library/ms733040.aspx for more details
In case anyone is still facing this issue (trying to use a SESSION variable in a .NET Web App consuming a WCF Service). Don't worry about the [AspNetCompatibilityRequirements .......] or adding aspNetCompatibilityEnabled="true" in the web.config.
After playing around with all that for a while I found out all I had to do was change each [WebMethod] within the _______.ASMX.CS to [WebMethod (EnableSession=true)].
So change [WebMethod] to [WebMethod (EnableSession=true)]. That's it.
I found out that from http://weblogs.asp.net/stevewellens/archive/2009/04/05/using-session-state-in-a-web-service.aspx
Thanks!
Bonsai
I have a Windows Service that is self hosting a Wcf service, this Wcf service has a tcpBinding with default settings. The Windows service is running as LocalSystem.
The Wcf Service is referenced (default settings) by a Web application that is running in IIS 7.5 integrated pipeline within it's own application pool with its own identity.
Both are running on the same machine.
All is working fine, except that when in the Wcf Service when I check the identity of the current thread with:
Thread.CurrentPrincipal.Identity.Name
It returns the user of the Application Pool of the Web Application.. this is not what I expect. It looks like some sort of impersonation is going on in the Wcf service.
Is this standard behavior? I can't find any documentation on this.
And does it mean that when I try to access a database in the Wcf service i'm introducing a identity hop?
Edit, the config on service side:
Type serviceType = typeof(WcfService);
host = new ServiceHost(serviceType);
Binding tcpBinding = new NetTcpBinding( );
Uri tcpBaseAddress = new Uri("net.tcp://localhost:8001/Test");
host.AddServiceEndpoint(typeof (WcfService), tcpBinding, tcpBaseAddress);
host.Open();
On the client side:
NetTcpBinding tcpBinding = new NetTcpBinding(SecurityMode.Transport);
windowsService = new WindowsService.WcfServiceClient(tcpBinding, new EndpointAddress("net.tcp://localhost:8001/Test"));
I'm reading from Learning WCF by Michele Bustamante. I have used WCF for an application that I've refactored and we're interested in using WCF in new applications for the flexibility it offers. One of the downsides of WCF is that it can be tricky to use the .net attributes or .config files to get the settings just right. I have spent days tracking down issues with the WCF settings. I've even created automated tests that will check that my service runs the way it's supposed to.
In response to your question, Michele says very specifically in Chapter Seven that NetTcpBinding is secure by default, meaning that callers must provide Windows credentials for authentication. I believe that would explain why the thread appears to be running as the identity of the web service. This is to protect your service from being called by an unauthorized user.
I believe that the following quotation from pp. 419-420 will answer your question concisely. "If you are familiar with traditional .NET role-based security, you know that there is a security principal attached to each executing thread. That security principal holds the caller's identity, which may be tied to a Windows account or a custom database credential, and its roles."
That seems to state plainly that yes, this is standard behavior.
I believe that you can change the behavior through attributes and .config files. I recommend you get a good book on the subject. I spun my wheels in the sand a long time trying to get bits and pieces of information about WCF from the web.
To clearify:
I was checking the wrong property here. Because code would be executed under the WindowsIdentity.GetCurrent() identity.
By default this is NOT the same as the caller (which is in Thread.CurrentPrincipal.Identity). If you want this behaviour you can control this with:
host.Authorization.ImpersonateCallerForAllOperations = true;
and
[OperationBehavior(Impersonation = ImpersonationOption.Required)]
We actually have integrated security set at the website, and then any calls from the website to the WCF service we wrap in:
using (((WindowsIdentity)HttpContext.Current.User.Identity).Impersonate())
{
That makes sure the credentials of the logged in user are passed through, rather than the IIS app pool credentials.
Works like magic!
More information is needed, but I'm guessing that it's somewhere in the configuration for the binding on either the server side or the client side that impersonation is enabled. When adding service references, svcutil.exe is VERY aggressive in setting EVERY possible binding property in configuration.
If you could provide more information for the configuration on the server and client side, it would be appreciated.
I have this existing environment:
1) ASP.NET 3.5 web application
2) forms authentication with the SqlMembershipProvider
I need to add the following:
1) a Silverlight charting object embedded in a web page.
2) a WCF service to be consumed by:
a) the Silverlight component embedded in an authenticated
web page, as mentioned above
b) server-based WCF clients with certificate based authentication
My question is - what is the easiest/best way to configure the WCF endpoints for the Silverlight object to authenticate to the WCF service using the security context of the already logged-in user (via the page that’s hosting the Silverlight object) without having to use the user's username/password again?
I've researched a lot of the MSDN and Patterns & Practices material and I thought I had a decent grasp of many of the potential authentication scenarios. But I can't seem to figure out a way to tie them together for the scenario I've outlined. I've found other people posting similar questions to mine but none of the answers I've read seem to fully answer their questions either. (Maybe I'm making this harder than it needs to be?)
I would think that the solution would be to somehow use the authentication token/cookie generated in the asp.net form login and somehow pass that to the Silverlight object which then includes it in the WCF request. But I don't see how to configure the WCF endpoint to use that token.
(In some of my other projects I've implemented the server-to-server scenario in 2.b above using certificate-based authentication, so I'm not too worried about adding that to the current mix I've outlined.)
Thanks in advance for any insight or pointers to the path forward.
Terry
Thanks codemeit for trying to help but I finally figured out what I was doing wrong - it was pilot error.
In trying to configure the endpoints for my Silverlight app I was testing with an asp.net page. I finally realized that when I test that way, the client endpoint is no longer originating from the authenticated browser - the client endpoint is the IIS server which in turn executes the request against the WCF server endpoint. So the security context changes and HttpContext.Current.User.Identity is always empty at the WCF server endpoint.
Once I got my test SL app running in the browser, it automatically inherited the security context of the authenticated browser and then HttpContext.Current.User.Identity was correct and authenticated at the WCF server endpoint.
Have you tried to enable your WCF services with aspNet compatibility, then see if the following is true.
string currentUserName = HttpContext.Current.User.Identity.Name;
bool isLoggedIn = HttpContext.Current.User.Identity.IsAuthenticated;
if these properties are being populated with the expected values, then this is the one you are after.
To enable aspNet Compatibility
add to web.config
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
add to the service impl class
[AspNetCompatibilityRequirements
(RequirementsMode=AspNetCompatibilityRequirementsMode.Required)]
In this case, the endpoint would be using basicHttpBinding, and you could check the authentication at run time within WCF.