Why is GetUserProfileByName from InfoPath Forms Services with claims authentication failing?

Question

I have a web application with an ADFS 2.0 trusted identity provider, and it's the only authentication provider. When I login, SharePoint correctly associates me with the my stored profile, but calls to GetUserProfileByName in UserProfileService.asmx fail even after manually setting AccountName to DOMAIN\USERNAME.

I've tried querying through a UDC that had stored domain credentials too with no success. The error I'm getting when calling the GetUserProfileByName is:

The following query failed: GetUserProfileByName (User: 0e.t||, Form Name: TestGetUserProfileSITESTEST_PUBnew, IP: , Connection Target: dc/UserProfileConnection.udcx, Request: /_layouts/FormServer.aspx?XsnLocation=/FormServerTemplates/TestGetUserProfileSITESTEST_PUBnew.xsn&SaveLocation=/up&Source=/up/Forms/AllItems.aspx&DefaultItemOpen=1, Form ID: urn:schemas-microsoft-com:office:infopath:TestGetUserProfileSITESTEST-PUBnew:-myXSD-2011-07-26T21-38-47 Type: DataAdapterException, Exception Message: The remote server returned an error: (500) Internal Server Error. Server was unable to process request. ---> Attempted to perform an unauthorized operation. The remote server returned an error: (500) Internal Server Error.)

If I extend the web application and add Kerberos or NTLM authentication to the new zone, the UserProfileService works fine in the new zone.

I cannot get the UserProfileService to work for trusted identity providers. Has anyone found a solution?

Answer 1

InfoPath Form Services does not support claims based authentication (that's what MS Support told us, when we faced a similar issue with Nintex Workflow.asmx about a month back).

If you look in the IIS logs you will see that the calls to the UserProfileService.asmx are getting made as nt authority\anonymous user instead of the currently logged in user. This happens because FormServer when making the call to the WS is able to use only Basic or Digest mode for passing credentials.

You can fix the issue temperorily by using the udcx:Authentication tag of the udcx file, either by speciying a hard coded user name and password or setting it up to use Secure store service. This fix works because the GetProfileByName method does not require the the currently logged in user to be imperonated when making the call.

But sooner or later you would come across a scenario in which you need to make a call to a Web Service that requires that the call be made using the logged in user's credentials (for eg: GetRunningWorkflowTasksForCurrentUser method in Nintex Workflow.asmx), which would fail if you are using InfoPath Form Services in a Claims based environment

Answer 2

First, it looks like you are trying to make a call to the web service from InfoPath using a data connection library using udcxs. Have you tried hard coding the URL reference into the InfoPath form? Are you seeing this failure when it is published, or in preview mode?

Second, you may be running into the relative nature of virtual SharePoint directories. In this case _vti_bin. The _vti_bin folder doesn't actually exist, it just a pointer. The section of the URL previous to the _vti_bin determines the context, and the last part (UserProfileService.asmx) specifies the file.

Can you navigate to the Url that you are using for the UserProfile service directly? It should pop up a webservice command list. Your url should also match the area where you are working (publish location). Ie. https://<your server>/_vti_bin/UserProfileService.asmx is wrong, it will run at the top level context. Rather it should be https://<your sever>/<your publish-work location>/_vti_bin/UserProfileService.asmx

Answer 3

I would have checked that WebDAV is enabled on the server.

MSDN article Building SharePoint Applications with InfoPath 2010 (Part 2 of 2) (MSDN refresh) tells in context ow walkthrough on using GetUserProfileByName SOAP service:

• " Important:

  The SharePoint application and code described in this article will not work if SharePoint is configured for forms-based authentication. To work correctly, the web application that hosts this SharePoint application must be configured to use classic-mode authentication. For more information about configuring SharePoint authentication, see Plan authentication methods (SharePoint Server 2010)".

Answer 4

I was faced with a similar issue and ULS logs gave the same error. You should check the visitors permission to the site collection. I had the "everyone" group in there and connection would fail with 500 error, BUT once I added the

"NT AUTHORITY\Authenticated Users"

to the visitors group the connection started to work. My guess is that as stated above that the web service call is using the user set up in IIS as state above by "SharePoint Dude"

I didn't convert my connection to a .udcx file on this specific connection but if you do make sure to edit your .udcx file and replace the line:

<udc:Authentication><udc:SSO AppId='' CredentialType='' /></udc:Authentication>

with the following code:

<udc:Authentication><udc:SSO AppId='InfoPathWebService' CredentialType='NTLM' /></udc:Authentication>

Hope this helps someone in the future.

Thanks.

SG.

Answer 5

I'm pretty sure the CredentialType is case sensitive and should be "Ntlm" -- according the documentation on the udcx schema from Microsoft.