Jaki jest najlepszy sposób uwierzytelniania w usłudze sieci Web?

Question

Mamy interfejs API usługi .NET. Obecnie ludzie używają definicji SOAP do korzystania z interfejsu API, ponieważ wymagamy uwierzytelniania przez niestandardowy element uwierzytelniania w nagłówku SOAP. Działa świetnie. w porządku.

SOAP wymaga, aby żądanie było POST. Chcemy umożliwić użytkownikom używanie czasownika GET (aby można było go buforować).

Jaki jest najlepszy sposób na zaoferowanie prostego interfejsu API GET (nie musi to być usługa sieciowa!), Który oferuje również uwierzytelnianie?

przykład API trasa:

http://www.blah.com/api/Search?query=Foo

Czy jest to dopuszczalne i powszechna praktyka?

http://www.blah.com/api/Search?query=Foo&Key=<some guid>

UWAGA: Ja też nie chcą zaimplementować SSL ani instalowania dodatkowego oprogramowania ani wtyczek w IIS, itd. Itp

Answer 1

Jeśli serwis internetowy musi być zabezpieczone, i zakładam, że tak jest, ponieważ obecnie posiadasz nagłówek Authentication, wtedy powinieneś ponownie rozważyć użycie GET i nie używać SSL, przynajmniej dla części uwierzytelniającej. Co najmniej chciałbym wysłać żądanie autoryzacji przez SSL do usługi sieciowej/aplikacji. Jeśli nie chcesz podawać uwierzytelnienia przy każdym żądaniu, musisz przyjąć (i wygenerować w serwisie) plik cookie autoryzacji, który konsument może użyć do kolejnych wniosków.

Unikałbym używania uwierzytelniania w adresie URL z dokładnie tego powodu, dla którego chcesz wspierać GET - jeśli adres URL może być buforowany, to poświadczenia również zostaną zapisane w pamięci podręcznej. Łamie to bezpieczeństwo usługi internetowej, ponieważ każdy może ponownie użyć zapisanych w pamięci podręcznej poświadczeń.

Answer 2

Korzystając z interfejsu API GET only, potrzebowałbym pierwszej metody, która pobiera unikalny identyfikator sesji.

Np: GET/api action = auth & username = użytkownik & password = hashedpassword zwróci 16 znaków tokena, które można przechowywać na swojej stronie i wymaga to unikalny token dla każdej kolejnej rozmowy.

Jeśli API został wykonany w PHP, możesz użyć jego funkcji obsługi sesji w PHP, aby to osiągnąć (ma limit czasu/usuwanie pamięci). W ASP.NET istnieją podobne funkcje.

Jest podatny na powtórne ataki (ktoś chwyta lub zgaduje identyfikator sesji), ale jeśli chcesz czegoś prostego, to jest droga. Jakakolwiek strona nienależąca do HTTPS byłaby narażona na atak w ten sam sposób. Możesz powiązać identyfikator sesji z adresem IP użytkownika, aby uzyskać dodatkowe zabezpieczenia.

Answer 3

Jeśli korzystasz z WCF, możesz zbudować wbudowane mechanizmy bezpieczeństwa. Jeśli nie chcesz używać standardowych frameworków dla bezpieczeństwa, najprawdopodobniej zamierzasz zabezpieczyć się przez zaciemnienie.

Answer 4

Jeśli klienci znajdują się w tej samej domenie, można włączyć zintegrowane uwierzytelnianie systemu Windows w aplikacji IIS. Twoja aplikacja będzie teraz akceptować tylko uwierzytelnionych użytkowników systemu Windows. Dodaj własną rolę RoleProvider, aby uzyskać dokładniejszą, opartą na rolach szczegółowość.

Answer 5

Podobny do odpowiedzi Thomasa Eyde: możesz użyć systemu jednokrotnego logowania, takiego jak siteminder, do zabezpieczenia adresu URL. Osoba dzwoniąca musi załączyć token, który zwykle jest przechowywany w pliku cookie, ale można go dodać do ciągu zapytania.

Każda platforma SSO lub usługa zarządzania usługami sieciowymi celowo utrudni uwierzytelnianie, jeśli nie będzie korzystać z protokołu SSL.