2013-09-30 12 views
7

Sto strappando i capelli fuori su questo, Ho un servizio WCF che posso chiamare tramite il browser e funziona bene, quando lo chiamo io dall'applicazione web con il metodo seguente ottengo un errore (401) non autorizzato. E il servizio non viene chiamato. Inoltre, quando eseguo la mia applicazione Web dalla mia macchina locale (modalità di debug con IIS Express) puntata sul mio server di sviluppo (IIS7) funziona, ma quando distribuisco la mia applicazione Web sul server di sviluppo e la indirizzo ai servizi del server di sviluppo fallisce con l'errore 401. Penso che questo sia qualcosa a che fare con IIS7 ma non sono sicuro al 100% e l'aiuto sarebbe super utile.Non passare credenziali per servizio WCF con una conseguente 401

Ho guardato on-line per le risposte, ma finora il migliore che ho trovato è this.

La mia chiamata di servizio è il seguente:

var request = (HttpWebRequest) WebRequest.Create(url); 
request.Method = "GET"; 
request.ContentType = "application/json; charset=utf-8"; 
request.AuthenticationLevel = AuthenticationLevel.MutualAuthRequested; 
request.Credentials = CredentialCache.DefaultCredentials; 

WebResponse responce = request.GetResponse(); 
Stream reader = responce.GetResponseStream(); 

var sReader = new StreamReader(reader); 
string outResult = sReader.ReadToEnd(); 
sReader.Close(); 

var result = (T) JsonConvert.DeserializeObject(outResult, typeof (T)); 
return result; 

La mia configurazione per il servizio è simile al seguente:

<service name="RGMPServices.Householding.Services.AccountService" behaviorConfiguration="Default"> 
    <endpoint address="" kind="webHttpEndpoint" endpointConfiguration="SecuredHttpEndpointBinding" contract="RGMPServices.Householding.Contracts.IAccountService" /> 
    </service> 

    <service name="RGMPServices.Householding.Services.HouseholdService" behaviorConfiguration="Default"> 
    <endpoint address="" kind="webHttpEndpoint" endpointConfiguration="SecuredHttpEndpointBinding" contract="RGMPServices.Householding.Contracts.IHouseholdService" /> 
    </service> 

    <service name="RGMPServices.Householding.Services.UserService" behaviorConfiguration="Default"> 
    <endpoint address="" kind="webHttpEndpoint" endpointConfiguration="SecuredHttpEndpointBinding" contract="RGMPServices.Householding.Contracts.IUserService" /> 
    </service> 
</services> 

<behaviors> 
    <endpointBehaviors> 
    <behavior name="webBehaviour"> 
     <webHttp /> 
    </behavior> 
    </endpointBehaviors> 
    <serviceBehaviors> 
    <behavior name="Default"> 
     <serviceMetadata httpGetEnabled="true" httpsGetEnabled="true" /> 
     <serviceDebug includeExceptionDetailInFaults="true" /> 
    </behavior> 
    </serviceBehaviors> 
</behaviors> 

<standardEndpoints> 
    <webHttpEndpoint> 
    <standardEndpoint name="SecuredHttpEndpointBinding" helpEnabled="true" automaticFormatSelectionEnabled="true"> 
     <security mode="TransportCredentialOnly"> 
     <transport clientCredentialType="Windows" /> 
     </security> 
    </standardEndpoint> 
    </webHttpEndpoint> 
</standardEndpoints> 

ho messo un po 'di registrazione sul chiamata di servizio del cliente, poco prima chiamo il servizio, la risposta è:

DEBUG 2013-10-01 13:15:13,569 452ms ServiceGetSingle - Passing Login: MYLANDOMAIN\MYLANUSERNAME

ERROR 2013-10-01 13:15:13,631 514ms ServiceGetSingle - ERROR Calling ServiceGetSingle with user credentials login: MYLANDOMAIN\MYLANUSERNAME System.Net.WebException: The remote server returned an error: (401) Unauthorized. at System.Net.HttpWebRequest.GetResponse() at Householding.Common.ServiceHelper.ServiceGetSingle[T](String url)

Il codice si presenta come:

logger.Debug("Passing Login: " 
    + System.Security.Principal.WindowsIdentity.GetCurrent().Name) 

Anche quando ho impostato l'AppPool per il mio sito al mio account di dominio è non mi ancora autorizza per accedere al servizio WCF, ma ancora una volta: si sta lavorando per il browser . Così strano!

+0

Non è sempre facile ottenere il funzionamento dell'autenticazione di WCF e Windows. Prova Fiddler sul client per tracciare il flusso http. Prova anche a configurare la traccia WCF sul server: http://msdn.microsoft.com/en-us/library/ms733025.aspx – Joe

risposta

1

Sembra probabile che sei una vittima del problema del doppio hop quando si utilizza Integrated Windows Authentication (IWA) e Kerberos. Il primo hop è dal tuo browser all'applicazione web; il secondo salto è dalla tua applicazione web al servizio WCF.

Ecco alcune risorse che spiegano più pienamente il problema, e possono offrire una soluzione:

È possibile configurare Active Directory per supportare Kerberos delegation (di solito ai ragazzi dell'infrastruttura non piace), oppure potresti disattivare la rappresentazione e noi e un account "servizio" per l'applicazione Web e il pool di app IIS che può autenticarsi con il servizio WCF per conto dell'utente finale.

1

Quali sono le credenziali predefinite sul server Dev? Prova a fare un registro proprio lì e guarda cosa ottieni.

Questo è ciò che ho il sospetto: corsa a livello locale, le credenziali sono le finestre creds. Quando si chiama il server di sviluppo da dev, le credenziali sarebbero qualsiasi account sul quale il sito Web è in esecuzione. Se quel particolare account non ha accesso, allora esploderebbe.

+0

AGGIORNATO IL PROBLEMA – Joshy

+0

È il registro da quando si esegue l'applicazione dal server di sviluppo? –

+0

sì è dal server di sviluppo – Joshy

1

Come hanno detto prima, questo sembra un problema di rappresentazione. Hai provato ad avviare il programma client con "Esegui come" per modificare le credenziali?

Inoltre è possibile modificare questa riga di codice

request.Credentials = CredentialCache.DefaultCredentials; 

a

request.Credentials = new NetworkCredential("MyUsername", "MyPassword"); 

E vedere se funziona. Inoltre è necessario creare l'account "MyUserName" con "MyPassword" sul server Web per farlo funzionare.

1

Questi errori possono essere causati quando l'utente autenticato non ha accesso al percorso fisico in cui il servizio WCF è ospitato. Sul server dev, aprire Gestione IIS e passare alla directory virtuale per il servizio. A destra nella barra delle azioni, fare clic su "Impostazioni di base". Sotto la casella di testo "Percorso fisico", fai clic su "Connetti come ...". Scegliere "User specifico" e provare a impostare a un account utente che si sa ha i diritti per la cartella fisica sul server dev. In genere, questo sarebbe un account di servizio la cui password non scade.

1

Quando si esegue dal browser, il browser invia le credenziali di autenticazione. Inoltre, iis express verrà eseguito come utente che ha effettuato l'accesso, quindi invierà anche le credenziali. Iis è diverso, verrà eseguito come account locale. Anche se si dispone dell'autenticazione sul proprio front end, questo non verrà passato al back-end. I token di rappresentazione di Windows sono limitati nel numero di hop consentiti, di solito pari a 0. Questo viene fatto per prevenire esattamente quello che stai facendo. Se si desidera che l'autenticazione front-end fluisca sul back-end, è consigliabile eseguire autonomamente l'autenticazione e accedere all'utente/passaggio. In alternativa, se si esegue autonomamente l'autenticazione, è possibile creare un token di rappresentazione che consente di passare a un'altra macchina e che dovrebbe funzionare.