2012-01-24 43 views
7

Obecnie próbuję dowiedzieć się, jak wykonać ręczne uwierzytelnianie systemu Windows w naszej aplikacji ASP.NET. Problem polega na tym, że mamy uruchomioną usługę OData i używamy funkcji FormsAuthentication, aby zapewnić ogólny mechanizm logowania i zezwolić na usunięcie instrukcji PUT & dla OData, w tym przekierowań formularzy.Ręczne uwierzytelnianie systemu Windows

Jednak dla niektórych klientów mamy zintegrowane uwierzytelnianie systemu Windows, aby umożliwić bezproblemową integrację dla użytkowników z aktywnym katalogiem. Problem polega na tym, że chcemy mieć możliwość przełączania metod uwierzytelniania bez łamania usługi Odata, ponieważ od niej zależymy.

Próbujemy naśladować mechanizmy uwierzytelniania systemu Windows za pomocą modułu IhttpModule. Do tej pory możemy wyłączyć tę funkcję na &, a otrzymamy wyzwanie, gdy zostanie wysłane żądanie. Co nie wiem, jak korzystać z otrzymanych informacji z przeglądarki do przeprowadzania uwierzytelniania przed aktywnego katalogu:

Jest to kod używamy wyodrębnić NTLM informacje z bieżącego żądania:

/// <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; 
} 

Pozwala nam to wyodrębnić nagłówek z żądania. Teraz muszę wiedzieć, w jaki sposób dokonuję uwierzytelnienia w tym katalogu aktywnym.

Taka jest logika używamy, aby wyodrębnić informację:

// 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; 
} 

nadzieję, że ktoś może dostarczyć anwser że muszę.

+0

Świetne pytanie - czeka na wspaniałą odpowiedź! –

+0

Wątpię, czy w ten sposób można mieszać uwierzytelnianie formularzy i okien. Dla zalutu musisz włączyć go w IIS (ponieważ IIS to ten, który zweryfikuje te poświadczenia), a win-auth i formula-auth nie mogą ze sobą współpracować w niektórych konfiguracjach IIS (na przykład zintegrowana pula aplikacji IIS7 +). Ponadto istnieje tylko jeden tryb auth, który można określić w pliku web.config. W klasycznej puli aplikacji możesz mieszać auth, ale nie w tych samych plikach/folderach. Jeśli właśnie to robisz, włącz funkcję win-auth w określonym folderze/pliku/ścieżce URL (np. Program obsługi aspx), a następnie użyj tej procedury do uwierzytelnienia użytkowników win/AD. –

+0

Spróbuj wpis: http://stackoverflow.com/questions/2539038/iis7-mixed-mode-authentication – Tjaart

Odpowiedz

0

porządku,

oparciu otrzymanych uwag na moje pytanie, mam wymyślić następującego roztworu do obejścia problemu, który mam. Wiem, że to nie jest czyste rozwiązanie, ale przynajmniej działa dla nas.

  • Utwórz nową aplikację internetową, która biegnie wewnątrz aplikacji
  • Ta część aplikacji opiera się na Windows Authentication
    • Wyłącz Uwierzytelnianie anonimowe & Forms Authentication
  • Tworzenie strony Login.aspx że obsługuje uwierzytelnianie systemu Windows
  • Generujemy plik cookie po zalogowaniu i przekierowaniu do oryginalnej aplikacji
  • Oryginalna aplikacja rozpoznaje plik cookie i przenosi użytkownika.

Wymaga to wygenerowania tych samych kluczy do szyfrowania dla obu aplikacji. Można to ustawić za pomocą modułu klucza maszynowego w menedżerze IIS dla swojej aplikacji. Jeśli klucze nie są równe dla obu aplikacji, proces kodowania/dekodowania pliku cookie nie powiedzie się. Ustawiamy je do automatycznego generowania przy użyciu SHA1, ale te same klucze dla obu aplikacji.

Teraz sprawdzamy ustawienia na oryginalnej stronie logowania, przekierowujemy na stronę logowania podaplikacji, jeśli jest wymagane uwierzytelnianie systemu Windows i wykonujemy logowanie w tym miejscu. Następnie przekierowujemy z powrotem na oryginalną stronę logowania i używamy pliku cookie, aby kontynuować.

Powoduje to kilka przekierowań podczas pierwszego logowania, ale po tym aplikacja działa tak płynnie, jak zawsze.

Powiązane problemy