L'accès utilisateur du contexte WebService est refusé pour un magasin sécurisé

Question

J'exécute une application Web WebService (WCF). de
Le service WebService exécute une méthode pour lire des informations d'identification à partir du magasin sécurisé.
La méthode échoue avec le message:

Les informations d'identification n'ont pas été trouvées pour l'utilisateur actuel dans la cible Application 'Appid' ...

Exécution du SPContext.Current.Web.Currentatuser dans ma méthode me donne: SharePoint \ System. Cela semble étrange envisager le fait que l'application Web d'hébergement fonctionne sous sa propre identité.

Le magasin sécurisé est configuré selon ici . J'ai pris différentes approches pour obtenir des informations d'identification, mais le dernier code est:

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

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

J'ai également essayé d'exécuter cela à l'aide du contexte du site d'administration central ou de SPContext.current.Site.

L'application Secure Store Cible Les administrateurs et les membres incluent tous les comptes d'administrateur de la ferme et l'identité du pool d'applications. La même chose s'applique également aux administrateurs et aux autorisations de service de magasin sécurisé.

Mes questions sont les suivantes: La manière dont l'application est exécutée sous compte système (SharePoint \ System) la raison de l'erreur d'accès au magasin sécurisé?
Est-il normal d'avoir une application Web Storervice Storervice exécutée sous un compte système par défaut? Est-il possible d'une pièce manquante dans ma configuration de l'application Web?

Toute aide est grandement appréciée.

Answer 1

Ceci a été résolu:

Bien que le message d'exception de retour a été complètement trompeur, j'ai trouvé le problème avec le type d'informations d'identification (c'est-à-dire le groupe / personne) et par conséquent, définissant le propriétaire de l'identifiant correct.

Pour trouver l'exception, je devais revenir aux procédures stockées SSS et exécuter un profileur de trace sur le proc_ssss_getcredentials.

En comparant la saisie de la procédure et les étapes à l'intérieur, j'ai constaté que le problème est avec correspondance IdentityClaimValuehash, résultant de la valeur du propriétaire des informations d'identification (lors de la définition des valeurs d'identification). Cependant, vous ne pouvez pas définir correctement cette valeur lorsque le type est défini en groupe. Sélectionner une personne comme le type m'a permis de définir cette valeur en tant qu'administrateur de la ferme.

Bien sûr, pour que cela fonctionne, il faut également définir les administrateurs d'applications cible correctement.

L'utilisation du profileur de trace peut également aider à identifier l'identité envoyée au service. Bien que SPContext affichait le compte système, l'identité d'application Web a été envoyée (basée sur ma compréhension Tous les comptes administrateurs sont mappés sur le compte système ).

Ceci link m'a aidé à résoudre ce problème: