Webservice Context User Access is Denied for Secure Store

Question

I am running a web application scoped webservice (WCF).
The webservice runs a method to read credentials from the secure store.
The method fails with the message:

Credentials were not found for the current user within the target application 'AppID' ...

Running the SPContext.Current.Web.CurrentUser in my method gives me: SHAREPOINT\system. This seems strange considering the fact that the hosting web application runs under it's own identity.

The Secure Store is configured according to here. I took different approaches to get credentials, but the latest code is:

SecureStoreCredentialCollection credentials = null;
SPServiceContext context =
SPServiceContext.GetContext(SPServiceApplicationProxyGroup.Default, SPSiteSubscriptionIdentifier.Default);

SecureStoreServiceProxy ssp = new SecureStoreServiceProxy();
ISecureStore iss = ssp.GetSecureStore(context);
credentials = iss.GetCredentials(appId);

I also tried to run this using the context of Centeral Administration Site or SPContext.Current.Site.

The secure store application Target Application Administrators and Members include all farm administrator accounts and the application pool identity. The same also applies to the Secure Store Service Administrators and Permissions.

My questions are: Is the way application runs under system account (SHAREPOINT\system) the reason for access error to the secure store?
Is it normal to have a web application scoped webservice running under system account by default? Is there possibly a missing part in my web application setup?

Any help is greatly appreciated.

Answer 1

This has been resolved:

While the return exception message has been completely misleading, I found the problem with the type of credentials (i.e. Group/ Individual) and as a result, setting the correct Credential Owner.

To find the exception I had to go back to SSS stored procedures and run a trace profiler on the proc_sss_GetCredentials.

By comparing the proc input and the steps inside, I have found that the problem is with matching IdentityClaimValueHash which is resulted from the Credential Owner value (when setting credential values). However you cannot set this value correctly when the type is set as Group. Selecting Individual as the type allowed me to set this value as the Farm administrator.

Of course to get this working one needs to set the Target Application Administrators correctly as well.

Using the trace profiler can also help identify which identity is sent to the service. Although SPContext was showing System Account, in the background the web application identity has been sent (based on my understanding all admin accounts are mapped to the System Account).

This link helped me to resolve this problem: