2012-01-24 22 views
7

Attualmente sto cercando di capire come eseguire l'autenticazione manuale di Windows nella nostra applicazione ASP.NET. Il problema è che abbiamo un servizio OData in esecuzione e utilizzare FormsAuthentication per fornire il meccanismo di accesso generico e consentire i verbi PUT & DELETE per OData, inclusi i reindirizzamenti del modulo.Autenticazione Windows manuale

Tuttavia, per alcuni clienti è stata integrata l'autenticazione di Windows per consentire un'integrazione agevole per i propri utenti con la directory attiva. Il problema ora è che vogliamo essere in grado di cambiare i metodi di autenticazione senza interrompere il servizio Odata, perché dipendiamo da esso.

Quello che stiamo cercando di fare è imitare i meccanismi di autenticazione di Windows utilizzando un IhttpModule. Finora siamo in grado di disattivare la funzionalità su & e otteniamo la sfida quando viene effettuata una richiesta. Quello che non so è come usare le informazioni ricevute dal browser per eseguire l'autenticazione contro la directory attiva:

Questo è il codice che utilizziamo per estrarre le informazioni NTLM dalla richiesta corrente:

/// <summary> 
/// <para>Determines whether the current <see cref="HttpRequest"/> is a NTML challenge.</para> 
/// </summary> 
/// <param name="request">The <see cref="HttpRequest"/> to evaluate.</param> 
/// <param name="header">The output header to authenticate.</param> 
/// <returns>True if the current <see cref="HttpRequest"/> is considered a NTML challenge.</returns> 
protected bool IsNtlmChallenge(HttpRequest request, out string header) 
{ 
     const string headerName = @"Authorization"; 
     if (request.Headers.AllKeys.Contains(headerName)) 
     { 
      header = request.Headers[headerName]; 
      return true; 
     } 

     header = string.Empty; 
     return false; 
} 

Ciò ci consente di estrarre l'intestazione dalla richiesta. Quello che ho bisogno di sapere ora è come eseguo l'autenticazione con questo nella directory attiva.

Questa è la logica che usiamo per estrarre informazioni:

// Check if we need to handle authentication through Windows authentication or not. 
if (WindowsAuthentication) 
{ 
    string encryptedHeader; 

    // If this is a challenge from the client, perform the Windows Authentication using the 
    // information stored inside the header. 
    if(IsNtlmChallenge(HttpContext.Current.Request, out encryptedHeader)) 
    { 
     /* how to authenticate here with the encrypted header? */ 
    } 

    HttpContext.Current.Response.AddHeader("WWW-Authenticate", "NTLM"); 
    HttpContext.Current.Response.StatusCode = 401; 
    return; 
} 

La speranza qualcuno può fornire l'anwser che ho bisogno.

+0

Ottima domanda - in attesa di un'ottima risposta! –

+0

Dubito che sia possibile combinare l'autenticazione di form e windows in questo modo. Per winauth è necessario abilitarlo in IIS (perché IIS è quello che verificherà quelle credenziali), e win-auth e form-auth non possono funzionare insieme in alcune configurazioni di IIS (IIS7 + pool di app integrato, ad esempio). Inoltre, esiste una sola modalità di autenticazione che è possibile specificare in web.config. Mentre con il classico pool di app puoi mescolare auth, ma non sugli stessi file/cartelle. Se è ciò che stai facendo, abilita win-auth su una cartella/file/percorso url specifici (ad esempio, gestore di aspx), quindi usa quel gestore per autenticare gli utenti di win/AD. –

+0

Prova questo post: http://stackoverflow.com/questions/2539038/iis7-mixed-mode-authentication – Tjaart

risposta

0

Va bene,

sulla base dei commenti ricevuti sulla mia domanda, mi è venuta in mente la seguente soluzione per aggirare il problema che ho. So che non è una soluzione pulita, ma almeno funziona per noi.

  • crea una nuova applicazione Web che viene eseguito all'interno dell'applicazione
  • Questo sotto-applicazione si basa su autenticazione di Windows
    • Disabilita autenticazione anonima & autenticazione basata su form
  • Creare una pagina Login.aspx che gestisce l'autenticazione di Windows
  • Generiamo un cookie dopo il login e il reindirizzamento all'app originale
  • L'app originale riconosce il cookie e accetta l'utente.

Ciò richiede che vengano generate le stesse chiavi per la crittografia & decrittografia per entrambe le applicazioni. Questo può essere impostato utilizzando il Machine Key Module nel gestore IIS per la propria applicazione. Se le chiavi non sono uguali per entrambe le applicazioni, il processo di codifica/decodifica per il cookie fallirà. Li abbiamo impostati per generare automaticamente utilizzando SHA1, ma le stesse chiavi per entrambe le applicazioni.

Ora controlliamo le impostazioni sulla pagina di accesso originale, reindirizziamo alla pagina di accesso della sub-applicazione se è richiesta l'autenticazione di Windows ed esegui il login lì. Quindi reindirizziamo alla pagina di accesso originale e utilizziamo il cookie per continuare.

Ciò comporta alcuni reindirizzamenti quando si effettua il login iniziale, ma in seguito l'applicazione funziona senza problemi.