L'accesso utente del contesto WebService è negato per il negozio sicuro

Question

Sto eseguendo un'applicazione Web SCOPED WebService (WCF).
. Il servizio WebService esegue un metodo per leggere le credenziali dal negozio sicuro.
Il metodo non riesce con il messaggio:

.

Le credenziali non sono state trovate per l'utente corrente all'interno del bersaglio Applicazione 'AppID' ...

Esecuzione di spontext.current.web.currentuser nel mio metodo mi dà: SharePoint \ System. Questo sembra strano considerando il fatto che l'applicazione Web di hosting esegue sotto la sua identità personale.

Il negozio sicuro è configurato secondo qui . Ho preso approcci diversi per ottenere credenziali, ma l'ultimo codice è:

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

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

.

Ho anche provato a eseguire questo utilizzando il contesto del sito di amministrazione centrale o spontext.current.site.

Gli amministratori e gli amministratori dell'applicazione dell'applicazione Secure Store includono tutti gli account di amministrazione agricolo e l'identità del pool di applicazioni. Lo stesso vale anche per gli amministratori e le autorizzazioni del servizio di archiviazione sicuro.

Le mie domande sono: è il modo in cui l'applicazione viene eseguita in Account di sistema (SharePoint \ System) il motivo dell'errore di accesso al negozio sicuro?
È normale avere un'applicazione Web SCOPED WebService in esecuzione in un account di sistema per impostazione predefinita? C'è forse una parte mancante nella mia configurazione dell'applicazione Web?

Qualsiasi aiuto è molto apprezzato.

Answer 1

Questo è stato risolto:

Mentre il messaggio di eccezione di ritorno è stato completamente fuorviante, ho trovato il problema con il tipo di credenziali (I.e. Gruppo / individuale) e di conseguenza, impostazione del proprietario delle credenziali corrette.

Per trovare l'eccezione che dovevo tornare alle procedure memorizzate SSS e gestire un profiler Trace su Proc_SSS_GetCredentials.

Confrontando l'ingresso PROC e i passaggi all'interno, ho scoperto che il problema è con la corrispondenza dell'identityClamaimValueHash che è derivata dal valore del proprietario delle credenziali (quando si impostano i valori delle credenziali). Tuttavia non è possibile impostare questo valore correttamente quando il tipo è impostato come gruppo. Selezione individuale come il tipo mi ha permesso di impostare questo valore come amministratore della fattoria.

Naturalmente per ottenere questo funzionamento è necessario impostare correttamente gli amministratori dell'applicazione di destinazione.

L'utilizzo del profiler Trace può anche aiutare a identificare quale identità viene inviata al servizio. Sebbene SPContext mostri un account di sistema, in background è stata inviata l'identità dell'applicazione Web (in base alla mia comprensione Tutti gli account amministratori sono mappati sull'account di sistema ).

Questo link mi ha aiutato a risolvere questo problema: