2017-07-31 47 views
5

Mój serwis internetowy jest obecnie robi podstawowe login/uwierzytelnianie hasła w celu objęcia użytkownikowi wymiany do odbierania zdarzeń (jak nowe zdarzenia poczty etc) jak poniżej:Jak uwierzytelniania OAuth, aby uzyskać dostęp do API EWS

var service = new ExchangeService(exchangeVersion) 
            { 
             KeepAlive = true, 
             Url = new Uri("some autodiscovery url"), 
             Credentials = new NetworkCredential(username, password) 
            }; 

var subscription = service.SubscribeToPushNotifications(
            new[] { inboxFolderFoldeID }, 
            new Uri("some post back url"), 
            15, 
            null, 
            EventType.NewMail, 
            EventType.Created, 
            EventType.Deleted, 
            EventType.Modified, 
            EventType.Moved, 
            EventType.Copied); 

Mam teraz zastąpić mechanizm uwierzytelniania, aby korzystać z protokołu OAuth. Widziałem kilka przykładów, ale wszystkie z nich wydają się mówić o uwierzytelnianiu klienta (https://msdn.microsoft.com/en-us/library/office/dn903761%28v=exchg.150%29.aspx?f=255&MSPPError=-2147217396), ale nigdzie nie mogłem znaleźć przykładu, jak uwierzytelnić użytkownika wymiany za pomocą protokołu OAuth. Każda próbka kodu bardzo pomoże. Dzięki.

+0

Jeszcze jedna rzecz, która pojawiła się podczas badania Oauth dla EWS, jest dostępna tylko dla Office 365, a nie dla serwerów wymiany. https://msdn.microsoft.com/en-us/library/office/dn903761(v=exchg.150).aspx mówi, że "uwierzytelnianie OAuth dla EWS jest dostępne tylko w Exchange jako część Office 365. Aplikacje EWS wymagają Uprawnienie "Pełny dostęp do skrzynki pocztowej użytkownika". – tavier

+0

Niestety, żaden z linków nie mówi o tym, jak zmusić go do pracy z API zarządzanym przez EWS. Adres URL msdn, który napisałem w pytaniu, nie wydaje się uwierzytelniać użytkownika, ale po prostu autoryzowanie klienta wydaje się być – tavier

+0

Czy przejrzałeś https://blogs.technet.microsoft.com/ronba/2016/05/09/using-powershell i-office-365-rest-api-z-oauth /? – Eris

Odpowiedz

4

Nie jest jasne, co masz na myśli mówiąc o "usłudze sieciowej" i jak obecnie uzyskujesz nazwę użytkownika i hasło. Jeśli jest to jakaś strona internetowa, na której użytkownik musi się zalogować lub przekazać dane uwierzytelniające, konieczne będzie uruchomienie akceptacji OAuth2 z przeglądarki, tak jak przekierowanie przeglądarki klientów do autoryzowanego punktu końcowego, aby rozpocząć implicit grant lub code grant. Użytkownik zostanie wyświetlony ekran logowania na serwerze OAuth2 (a nie w aplikacji), po zalogowaniu użytkownika w kodzie lub tokenie dostępu (w zależności od grantu) zostanie on zwrócony do aplikacji, z której można korzystać w konstruktorze ExchangeService .

Jeśli ta usługa "internetowa" jest usługą uruchomioną na komputerze użytkownika, można skorzystać z jednej z metod opisanych poniżej.

Get AccessToken użyciu AuthenticationContext

Przykład wydaje się być oparty na starszej wersji klasy AuthenticationContext.

Wydaje się, że nowa wersja to other version, a teraz nazwa AcquireToken została zmieniona na AcquireTokenAsync/AcquireTokenSilentAsync.

Bez względu na to, której wersji używasz, nie będzie możliwe podanie nazwy użytkownika i hasła, tak jak w bieżącym kodzie. Możesz jednak zezwolić użytkownikowi na metodę uwierzytelniania AcquireToken[Async]. Co, powiedzmy sobie szczerze, jest bezpieczniejsze, niż pozwolenie twojej aplikacji na bezpośrednią obsługę tych sekretów. Zanim się zorientujesz, będziesz przechowywać hasła w postaci zwykłego tekstu w bazie danych (mam nadzieję, że jeszcze nie jesteś).

W obu wersjach metody te mają wiele przeciążeń o różnych parametrach i nieco innej funkcjonalności. Dla Państwa użytkowej przypadku Myślę, że są ciekawe:

Prompt zachowanie auto, w obu vesions , oznacza: użytkownik zostanie poproszony o poświadczenia, gdy nie są już buforowane. Oba konstruktory AuthenticationContext umożliwiają przekazanie pamięci podręcznej tokenów, którą można zaimplementować samodzielnie. do buforowania tokenów w pamięci, pliku lub bazie danych (zobacz this article dla przykładowej implementacji pamięci podręcznej plików).

Get AccessToken ręcznie

Jeśli naprawdę chcesz przekazać w poświadczeń użytkownika z kodu bez monitowania użytkownika, zawsze jest odwrotnie.W takim przypadku będziesz musiał zaimplementować Resource Owner Password Credentials grant zgodnie z opisem w OAuth2 specificatioin/RFC6749.

przypadek czy nie, mam biblioteki open-source o nazwie oauth2-client-handler który implementuje to do stosowania z HttpClient, ale w każdym razie, jeśli chcesz pójść tą drogą można kopać w tym kodzie, szczególnie począwszy od this method.

Zastosowanie Dostęp Reklamowe

Gdy masz token dostępu, można postępować z próbkami na this MSDN page, f.e .:

var service = new ExchangeService(exchangeVersion) 
        { 
         KeepAlive = true, 
         Url = new Uri("some autodiscovery url"), 
         Credentials = new OAuthCredentials(authenticationResult.AccessToken)) 
        }; 
+0

To odpowiada na wiele pytań, które miałem, dzięki :) ale chodzi o to, żeby pozbyć się hasła użytkownika, chcieliśmy wprowadzić oautha (to jest moje zrozumienie oauth), więc czy możliwe jest całkowicie zrezygnować z uwierzytelniania użytkownika i hasła użytkownika i uwierzytelnić użytkownika za pomocą tokena dostępu? Czytałem coś związanego z podszywaniem się pod użytkowników, ale nie dostałem dobrego kodu przykładowego, który pasowałby do moich wymagań. – tavier

+0

Ponadto obiekt ExchangeService wydaje się mieć właściwość o nazwie ImpersonatedUserId, co oznacza, że ​​mogę podszyć się pod konkretnego użytkownika i zasubskrybować go w celu otrzymywania powiadomień. Chyba nie, ale chciałem się upewnić :) – tavier

+0

Dzięki za edycję, faktycznie moja aplikacja to Web API z niektórymi punktami końcowymi (bez żadnego interfejsu użytkownika), do których użytkownik z niektórych klientów poczty elektronicznej będzie przekazywał swoje referencje (to jest obecny przepływ) jednak, jeśli to możliwe, chcielibyśmy wykluczyć konieczność podania hasła. – tavier