Jak mogę zintegrować OpenID z interfejsem API MVC4

Question

Piszę Web API używając MVC4, który powinien być używany przez wiele typów klientów. Chcę użyć OpenID do uwierzytelnienia.

Mam już pobrany pakiet DotNetOpenAuth NuGet, ale jak dotąd wszystkie przykłady dotyczą aplikacji klienta, a nie API.

Mój problem jest prosty. Chcę, aby klienci wysyłali żądanie uwierzytelnienia do mojego interfejsu API. Interfejs API uwierzytelnia się z dostawcą OpenID. Interfejs API ustawia wszystko, co jest potrzebne, aby używać znaczników [Authorize] w wywołaniach api sieci web.

Rozumiem, że w aplikacjach .NET można wywołać FormsAuthentication.SetCookie, ale czy jest to również łatwe do wdrożenia rozwiązanie dla innych języków?

Pytanie w pigułce. Jak mogę zintegrować OpenID z interfejsem webowym MVC4, który pozwala na użycie tagu Authorize, który może być wywoływany i używany przez wiele języków?

Answer 1

Użytkownik może pomylić rolę uwierzytelniania i autoryzacji. Wygląda na to, że Twoje internetowe API potrzebuje zarówno.

Zacznijmy od autoryzacji. Każdy interfejs API (czyli URL strony internetowej, do której uzyskuje dostęp aplikacja kliencka inna niż przeglądarka), umożliwia dostęp anonimowy lub musi być autoryzowany (tj. Autoryzacja). Autoryzacja to domena OAuth. OAuth (v2, przypuszczalnie) opisuje, w jaki sposób klient autoryzuje połączenie z Twoim WebAPI.

Prawdopodobnie w ramach procesu autoryzacji użytkownik loguje się do usługi. Ten etap logowania użytkownika to uwierzytelnienie. I jest to ortogonalne w stosunku do autoryzacji. To, czy uwierzytelnisz użytkownika poprzez OpenID, nazwę użytkownika/hasło, certyfikat X.509 itp., Powinno być nieistotne dla sposobu autoryzacji twoich wywołań WebAPI. Innymi słowy, twoje metody WebAPI nie powinny przejmować się tym, jak użytkownik jest uwierzytelniany (czytaj: nie ma żadnych powiązań OpenID). To, co będą mieli, to zastosowany filtr autoryzacji, który weryfikuje autoryzację przychodzącego żądania i tłumaczy go na kilka informacji, w tym nazwę użytkownika konta, które autoryzowało dostęp, poziom dostępu, identyfikator autoryzowanego użytkownika. klient itp

Więc krok na raz, cały scenariusz może wyglądać następująco:

1. użytkownika obsługującego aplikację 3-ty klienta party (załóżmy dla uproszczenia, że ​​ta aplikacja klient jest 3rd strona internetowa) chce korzystać z funkcji, która wymaga dostępu klienta do interfejsu WebAPI w nazwie użytkownika.
2. Klient musi uzyskać zezwolenie na ograniczone podszywanie się pod użytkownika, gdy klient nawiąże połączenia z Twoim interfejsem WebAPI. Zaczynają się od przekierowania OAuth 2 do punktu końcowego autoryzacji w Twojej usłudze. Jeśli jest to zaimplementowane za pomocą DotNetOpenAuth, może to być klasa WebServerClient.
3. Punkt końcowy autoryzacji pełni rolę serwera autoryzacji OAuth 2 i jako taki używa klasy DotNetOpenAuth: AuthorizationServer. Pierwszą rzeczą, którą robi, jest sprawdzenie, czy w żądaniu znajduje się plik cookie uwierzytelniania formularzy ASP.NET. Ten plik cookie jest naturalnym wskazaniem, czy użytkownik zalogował się już do Twojej przeglądarki w przeglądarce, a jeśli tak, to kim jest ten użytkownik. Sprawdzanie tego ciasteczka to prosty telefon pod numer Controller.User. Należy zauważyć, że punktem końcowym autoryzacji jest MVC, a nie WebAPI, ponieważ jego odpowiedzią jest przeglądarka/użytkownik, a nie aplikacja kliencka. Załóżmy, że nie ma takiego pliku cookie, a Controller.User ma wartość null (lub User.Identity.IsAuthenticated jest false).Informacje na temat implementacji tego punktu końcowego można znaleźć w pliku OAuthAuthorizationServer.
4. Punkt końcowy autoryzacji odpowiada przekierowaniem na stronę logowania użytkownika, w tym parametrem redirectUrl w ciągu zapytania, który zachowuje pełny adres URL żądania autoryzacji OAuth 2.
5. Twoja strona logowania użytkownika to punkt końcowy MVC, który działa jako strona oparta na OpenID. Ten punkt końcowy używa klasy DotNetOpenAuth: OpenIdRelyingParty. Zauważ, że ten punkt końcowy nie wie nic o OAuth 2 ani o autoryzacjach. Po prostu uwierzytelnia użytkownika. Po uwierzytelnieniu użytkownika następuje przekierowanie z powrotem do adresu URL z argumentem redirectUrl. Zapoznaj się z przykładem OpenIdRelyingPartyMvc, aby dowiedzieć się, jak to zrobić.
6. Punkt końcowy autoryzacji powtarza swój poprzedni krok, z tą różnicą, że znajduje się plik cookie FormsAuthentication, aby przejść do wyświetlenia strony użytkownikowi z pytaniem, czy chce on upoważnić klienta do dostępu do danych użytkownika. Użytkownik klika tak. (uwaga: zaimplementuj ograniczenia XSRF i ograniczenia kliknięć na stronie autoryzacji użytkownika).
7. Punkt końcowy autoryzacji przetwarza odpowiedź twierdzącą użytkownika i wywołuje AuthorizationServer, aby utworzyć rekord autoryzacji i zwrócić odpowiedź klientowi. Jednym z rezultatów tego połączenia jest sformułowanie odpowiedzi przekierowania na klienta, która nadaje mu kod autoryzacyjny.
8. Przeglądarka pobiera teraz adres URL aplikacji klienckiej, która przekazuje mu kod autoryzacji. Następnie klient używa klasy WebServerClient w celu wymiany kodu autoryzacji dla tokena dostępu (i zwykle również tokena odświeżania).
9. Aplikacja kliencka wykonuje teraz bezpośrednie połączenia z adresami URL WebAPI, w tym tokenem dostępu uzyskanym przez OAuth 2 w nagłówku autoryzacji HTTP.
10. Twój WebAPI wypełnia rolę OAuth2 zasobów serwera, a filtr Autoryzacja atrybutów można zastosować do swoich metod WebAPI do sprawdzania poprawności przychodzących OAuth 2 token dostępu wykorzystuje klasę DotNetOpenAuth ResourceServer zrobić swoją pracę. Możesz odnieść się do próbki OAuthResourceServer, a nawet lepiej, David Christiansen's WebAPI sample, jak to zrobić.

To wszystko. I tak, rola klienta jest łatwa do napisania, bez względu na język lub bibliotekę, której używają.

BTW, próbki DotNetOpenAuth, do których się odnawiam, nie są dystrybuowane przez NuGet. Ty get the samples from SourceForge.