2009-09-16 13 views
22

Chciałbym stworzyć architekturę usług internetowych, która może być wywoływana przez różne platformy, takie jak urządzenia mobilne, aplikacje WinForm, iPhone, BlackBerry, nazwę. Tak więc przechodzenie z czymś takim jak WCF i wiązaniem wsHttp prawdopodobnie zabije to i musiałbym przejść do wiązania basicHttp dla kompatybilności.Najlepszy sposób na stworzenie systemu TOKEN do uwierzytelniania wywołań usług internetowych?

Powiedziałem, że potrzebuję systemu do generowania tokena przy pierwszym logowaniu (uwierzytelnianie), a następnie używam tego tokena dla wszystkich kolejnych wywołań, jak sądzę, aby zweryfikować uwierzytelnienie i zezwolić na wykonanie metody.

Ktoś ma wskazówki lub sugestie, jak to zrobić? 1) Wygeneruj token i co wiąże się z zabezpieczonym tokenem? 2) Jak długo jest to dobry dowód, niektórzy użytkownicy mogą korzystać z aplikacji przez wiele godzin, a nawet "przespać" swój komputer

Dziękuję za radę.

+1

Moje pytanie dotyczy raczej najlepszego sposobu przenoszenia tego tokena tam iz powrotem oraz wszystkich połączeń, nie tyle o tym, jak się uwierzytelnić. Kiedy serwer wygeneruje token (klasę serializowaną), jaki jest najlepszy sposób dołączenia go do wszystkich kolejnych wywołań? Jako parametr do metod lub może być dołączony jako nagłówek lub coś takiego, więc jest przezroczysty dla wszystkich metod (kontrakty serwisowe). – Neal

Odpowiedz

15

Jeśli używasz tylko jednego tokena, który jest podawany przez serwer podczas początkowego uwierzytelniania, może być używany do każdego żądania, jeśli zostanie przechwycony. Twoją jedyną obroną jest czas wygaśnięcia.

Co więcej, zależy to od opcji wdrożenia.

Bardziej zabezpieczonym systemem jest dodawanie znacznika czasu (i ewentualnie numeru dodatkowego) do każdego żądania, podpisywanie go i dołączanie go do każdego żądania. Wymaga, aby klient obsługiwał poświadczenia uwierzytelniające, znał implementację podpisu i podpisywał każde żądanie.

Alternatywnie można uwierzytelnić serwer przy każdym żądaniu (można to zrobić za pomocą OpenID) lub rozdać pewną liczbę tokenów i ponownie wykonać uwierzytelnienie, gdy potrzeba więcej (można to zrobić za pomocą protokołu OAuth). Jeśli klient może przechowywać referencje, mogą one być niewidoczne dla użytkownika. Są to bardziej złożone, wymagające zaszyfrowanego transportu, takiego jak SSL dla niektórych interakcji, oraz klienta, który potrafi mówić przekierowaniami HTTP i obsługiwać pliki cookie lub inny zapisany stan. Klient nie musiałby wiedzieć, jak się podpisać, ale jeśli możesz zrobić SSL, prawdopodobnie nie potrzebujesz złożoności w pierwszej kolejności.

Jeśli nie potrzebujesz być agnostykiem klienta, prawdopodobnie chcesz podpisać prośby.

Aby podpisać implementacje, przykłady i biblioteki, należy zapoznać się z usługami Amazon Web Services, OpenID lub OAuth.

Jeśli chodzi o czas wygaśnięcia tokena, zależy to od Twoich potrzeb. Dłuższy czas życia tokenów zwiększa ataki powtórki okna. Symbol jednorazowy sprawia, że ​​token jest jednorazowego użytku, ale wymaga więcej stanu na serwerze.

3

Powinieneś sprawdzić OAuth. Jest to standard uwierzytelniania API, prawdopodobnie wystarczy podłączyć istniejącą implementację do swojej usługi.

+0

Protokół OAuth pozwala ustawić parametry według własnych upodobań. Proponuję zapoznać się z niektórymi dostawcami usług i sprawdzić, co zrobili z OAuth. http://wiki.oauth.net/ServiceProviders –

Powiązane problemy