Gdzie mam podłączyć autoryzację w Asp.net WebAPI?

Aktualizacja Lipiec 2014

Moja oryginalna odpowiedź dotyczyła WebApi 1. w WebApi 2 zaszły pewne zmiany, tzn. istnieje teraz IAuthenticationFilter, co oznacza, że można przenieść logikę uwierzytelniania z DelegatingHandler, która jest nieco bardziej elegancka.

Istnieje projekt Nuget tutaj , który oferuje implementację IAuthenticationFilter, a także wyjaśnia pewne tło do jego wprowadzenia.

Oprogramowanie pośredniczące OWIN jest teraz prawdopodobnie najlepszym miejscem do wdrożenia twojego logika uwierzytelniania - istnieje przykład uwierzytelniania certyfikatu tutaj i podstawowego uwierzytelniania OWIN Middleware tutaj w ten wpis na blogu pierwszy przykład jest preferowany, ponieważ demonstruje użycie klasy base AuthenticationHandler.

Porady dotyczące AuthorizationFilters pozostają w dużej mierze niezmienione.

End Update

Zazwyczaj...

Użyj DelegatingHandler do przeprowadzenia uwierzytelnienia... czyli kim jest ktoś. Użyj tego, aby ustawić zasadę wątku i kontekst użytkownika, dodawanie oświadczeń itp. Tutaj też można umieścić logikę autoryzacji, ale na dość globalną skalę. Osobiście zawsze używałbym AuthorizationFilters do autoryzacji.

Użyj AuthorizationFilters, aby ograniczyć kontrolery i działania do określonych osób. Są one używane, gdy można ekstrapolować ich uprawnienia z informacjami w oświadczeniach, principal, url lub parametry żądania http. Domyślny filtr autoryzacji może być użyty do ograniczenia dostępu do anonimowych użytkowników lub według ról (jeśli ustawione w czymś w rodzaju delegującego Handlera) - oczywiście możesz też zaimplementować własne AuthorizationFilters jeśli tego potrzebujesz.

Sporadycznie używaj ActionFilters, gdy musisz podjąć decyzję o autoryzacji za pomocą treści wiadomości, np. potrzebujesz dostępu do nieruchomości na jednostce, aby zdecydować, czy mają dostęp (oczywiście uważaj z tym (!)).

Uwaga:

AuthorizationFilters są wywoływane przed odczytaniem zawartości ciała, dlatego nie mają dostępu do treść wiadomości do podejmowania decyzji autoryzacyjnych dlatego ActionFilters a konkretnie OnActionExecuting jest używany do sporadycznego zgłaszania błędów uwierzytelniania.

Więc

W Twoim scenariuszu umieściłbym prosty DelegatingHandler, aby wziąć twój nagłówek i ustawić główny.

public class CustomAuthenticationMessageHandler : DelegatingHandler
{


    public CustomAuthenticationMessageHandler ()
    {

    }

    protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request,
                                                           CancellationToken cancellationToken)
    {
        Authenticate(request);

        return base.SendAsync(request, cancellationToken);
    }

    protected virtual void Authenticate(HttpRequestMessage request)
    {

        var authorisationHeader = request.Headers.Authorization;

        if (authorisationHeader == null)
        {
            return;
        }

        //Ensure you are happy with the header contents then

        {
            var principal = new GenericPrincipal(//new Identity , //Roles);
            Thread.CurrentPrincipal = principal;
            HttpContext.Current.User = principal;
        }

    }
}

Następnie użyj AuthorizationFilters, aby ograniczyć dostęp:

    [Authorize]
    public string Get()
    {

    }

    [Authorize(Roles = "Admin")]
    public string GetAdminOnly()
    {

    }

Aby zarejestrować globalne uwierzytelnienie

config.MessageHandlers.Add(new CustomAuthenticationMessageHandler());

Oznacza to, że w każdym żądaniu główny będzie ustawiony na null lub prawidłową tożsamość. Nie będzie obsługiwać autoryzacji, tj. nie odmówi dostępu do jakichkolwiek kontrolerów lub akcji.

Aby rozpocząć ochronę zasobów

Atakują chronione kontrolery i akcje ze standardowymi lub niestandardowymi atrybutami [Authorize]. Lub Zarejestruj się globalnie:

config.Filters.Add(new AuthorizeAttribute());

I tylko biała lista kontrolerów i akcji, które mają być niezabezpieczone przy użyciu atrybutu [AllowAnonymous].

Jeśli chcesz tylko uwierzytelnić na niektórych trasach

Wtedy możesz zmodyfikować swój DelegatingHandler trochę, aby ustawić InnerHandler trasę do właściwego kontrolera np.

public CustomAuthenticationMessageHandler(HttpConfiguration configuration)
{
       InnerHandler = new HttpRoutingDispatcher(configuration);
}

I wtedy możesz określić ten handler na swoich trasach w następujący sposób:

config.Routes.MapHttpRoute(
            name: "DefaultApi",
            routeTemplate: "myurl",
            defaults: new {},
            constraints: new {},
            handler: new CustomAuthenticationHandler(config)
            );