WCF service in claims-enabled SharePoint app

Question

I have a WCF service hosted in a Claims-enabled SharePoint 2010 webapp.

Using wsHttpBinding I can get a console client to use Windows (Kerberos) authentication against the service. Within the service, I impersonate the calling user, and try to open an SPSite instance.

As soon as I call something on the SPSite object, such as SPSite.RootWeb.Title, the service silently crashes. The ULS log yields an unknown SPRequest error, with an id implying a permission issue.

The user is a site collection administrator, so those rights aren't the problem here.

How can I get this running? What's the best practice for WCF service auth in Claims-enabled SharePoint 2010?

Answer 1

Do you also have FBA users?

Writing to disc or accessing other non-SharePoint resources may cause SharePoint get nervous and to terminate the web-service thread. I needed to do logging in a SharePoint list and to perform some tasks in timer-jobs instead of directly in the web-service call.

Web-services in SharePoint took some effort to get working. This works for me:

1. Follow this blog post by Arjun Chakraborty, except the part where you push web.config with deploy to the hive and overwrite the existing ISAPI web.config.

2. Don't use your own binding, use a binding TextStreamBindingNoSecurity that SharePoint built-in web-services uses. This also works for https using TextStreamBindingHttpsNoSecurity binding. Why the bindings are named ...NoSecurity I don't understand.

3. Edit your web.service config into the ISAPI web.config according to the 2 previous steps.

If you have an FBA user you need to use authentication.asmx web-service for authentication from the client.

Now you have proper authentication and http- and user-context in your web-service code, and elevating is no problem.

Answer 2

I'm going to make some assumptions about the code, but without snippets, these assumptions could be wrong. Update this post with code snippets in order for us to help better.

I would recommend attaching your debugger to IIS and stepping through the code. Or add some sort of logging functionality to dump the following information to find out what ASP.Net and SharePoint thinks is the currently logged in user:

IPrincipal currentUser = System.Web.HttpContext.User;

You likely aren't getting the executing user's credentials across, especially if you are trying to use wsHttpBinding. I know when I tried to work with claims-enabled web services via SharePoint, basicHttpBinding was much easier to work with than wsHttpBinding.