Przeglądasz dokumentację Apigee Edge.
Przejdź do
Dokumentacja Apigee X. informacje.
Hasło właściciela zasobu (czyli „hasło”) jest używane głównie wtedy, gdy aplikacja cieszy się zaufaniem. W tej konfiguracji użytkownik podaje dane logowania na serwer zasobów (nazwę użytkownika i hasło) do aplikacji klienckiej, która wysyła je do Apigee w żądaniu tokena dostępu Edge. Serwer tożsamości weryfikuje dane uwierzytelniające. Jeśli są one prawidłowe, Edge kontynuuje generowanie danych. token dostępu i zwraca go do aplikacji.
O tym temacie
Ten temat zawiera ogólny opis i omówienie hasła właściciela zasobu OAuth 2.0 i omawiają, jak wdrożyć ten przepływ w Apigee Edge.
Przykłady, które mogą Ci się przydać
- Prośba token dostępu: typ przyznania hasła: pokazuje, jak utworzyć żądanie tokena, skonfigurować zasady protokołu OAuthV2 dotyczące typu przyznania hasła i jak skonfigurować punkt końcowy dla zasady w Edge.
- oauth-validate-key-secret: przykładowy serwer proxy w GitHubie, który możesz wdrożyć w Edge i wypróbować na zewnątrz. To kompleksowy przykład z rodzajem przyznania hasła. Zapewnia on najwyższą skuteczność to uwierzytelnianie danych logowania aplikacji klienckiej (klucz/klucz tajny) przed wysłaniem dane logowania użytkownika do dostawcy tożsamości.
Wideo
Film: obejrzyj ten film o wdrożeniu przyznawania hasła typu.
Przypadki użycia
Ten typ uwierzytelnienia jest przeznaczony dla aplikacji o wysokim poziomie zaufanych lub uprzywilejowanych, ponieważ użytkownik jest wymagany aby przekazać aplikacji dane logowania na serwer zasobów. Zwykle aplikacja wyświetla ekran logowania. w którym użytkownik wpisuje swoje dane.
Schemat przepływu
Poniższy diagram przepływu ilustruje przepływ typu przyznawania hasła właściciela zasobu w Apigee Serwer Edge obsługujący serwer autoryzacji.
Wskazówka: aby zobaczyć większą wersję tego diagramu, kliknij go prawym przyciskiem myszy i otwórz nową kartę lub zapisz ją i otwórz w przeglądarce obrazów.
Kroki w ramach procesu uwierzytelniania typu uwierzytelnienia hasła
Oto podsumowanie kroków wymaganych do wdrożenia typu przyznawania hasła, w którym Apigee Edge służy jako serwer autoryzacji.
Warunek wstępny: aplikacja kliencka musi być zarejestrowana w Apigee Edge, aby uzyskać identyfikator klienta i klucze tajnego klienta. Patrz sekcja Rejestrowanie aplikacji klienckich dla: .
1. Użytkownik rozpoczyna przepływ i wprowadza dane logowania.
Gdy aplikacja musi uzyskać dostęp do zabezpieczonych zasobów użytkownika (np. użytkownik kliknie w aplikacji), użytkownik zostanie przekierowany do formularza logowania.
2. Żądania aplikacji token dostępu z Apigee Edge
Aplikacja wysyła żądanie tokena dostępu, w tym dane logowania użytkownika, do Punkt końcowy GenerateAccessToken w Apigee Edge.
Oto przykładowe żądanie POST, które zawiera parametry wymagane dla tego typu uwierzytelnienia:
$ curl -i \ -X POST \ -H 'Content-Type: application/x-www-form-urlencoded' \ -H 'Authorization: Basic c3FIOG9vSGV4VHo4QzAySVg5T1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ' \ -d 'grant_type=password&username=the-user-name&password=the-users-password' \ https://docs-test.apigee.net/oauth/token
Polecenie to można też wykonać w następujący sposób, używając opcji -u do curl aby utworzyć nagłówek uwierzytelniania podstawowego zakodowanego w formacie base64.
$ curl -i \ -X POST \ -H 'Content-Type: application/x-www-form-urlencoded' \ -u sqH8ooHexTz8C02IX9ORo6rhgq1iSrAl:Z4ljtJdneBOjPMAU \ -d 'grant_type=password&username=the-user-name&password=the-users-password' \ https://docs-test.apigee.net/oauth/token
Każde z tych poleceń powinno znajdować się w jednym wierszu.
Dane logowania użytkownika znajdują się w parametrach formularza, a dane logowania klienta – zakodowane w nagłówku podstawowego uwierzytelniania HTTP. Szczegółowy opis tego wywołania interfejsu API znajdziesz w tym szczegółowe informacje na temat wymaganego nagłówka uwierzytelniania podstawowego, zapoznaj się z sekcją o uwierzytelnianiu hasła na stronie „Prośba o zgodę tokeny dostępu i kody autoryzacji”.
3. Edge weryfikuje klienta aplikacja
Przed wysłaniem nazwy użytkownika i hasła użytkownika do dostawcy tożsamości Edge musi znać że aplikacja kliencka wysyłająca żądanie jest prawidłową, zaufaną aplikacją. Możesz to zrobić np. za pomocą interfejsu API uwierzytelnianie za pomocą klucza w wywołaniu interfejsu API. W niektórych przypadkach może być potrzebna weryfikacja zarówno klucza klienta, i tajemnicy. Dostępny jest przykładowy serwer proxy, który ilustruje tę wszechstronną metodę w funkcji api-platform-samples.
4. Edge przetwarza dane logowania
Po sprawdzeniu aplikacji klienckiej możesz użyć objaśnienia dotyczącego usługi lub zasad JavaScriptu, aby wywołać z usługi tożsamości, wysyłając dane logowania użytkownika. Może to być na przykład usługa LDAP lub z dowolnej usługi, której chcesz użyć do weryfikacji danych logowania. Szczegółowe informacje na temat tych zasad znajdziesz w Więcej informacji: Wyodrębnianie zmiennych zasady i JavaScript .
Jeśli usługa tożsamości zweryfikuje dane logowania i zwróci odpowiedź 200, Edge kontynuować przetwarzanie żądania; w przeciwnym razie Edge przestaje przetwarzać i zwraca błąd aplikacji klienckiej.
5. Zasada OAuthV2 wykonuje
Jeśli dane logowania są prawidłowe, następnym krokiem przetwarzania jest wykonanie zasady OAuthV2 skonfigurowany pod kątem typu przyznania hasła. Oto przykład. Element <UserName> oraz <PassWord> elementów są wymagane. Można je pobrać ze zmiennych przepływu, które zostały zapisane z zasadą Extractvariables. Szczegółowe informacje na temat tych zasad znajdziesz w Więcej informacji: Zasady OAuthV2.
<OAuthV2 name="GetAccessToken"> <Operation>GenerateAccessToken</Operation> <ExpiresIn>360000000</ExpiresIn> <SupportedGrantTypes> <GrantType>password</GrantType> </SupportedGrantTypes> <GrantType>request.queryparam.grant_type</GrantType> <UserName>login</UserName> <PassWord>password</PassWord> <GenerateResponse/> </OAuthV2>
Jeśli działanie tej zasady zadziała, odpowiedź zostanie wygenerowana z powrotem do klienta z uprawnieniami dostępu token. Odpowiedź jest w formacie JSON. Oto przykład. Pamiętaj, że access_token jest jednym z elementy:
{ "issued_at": "1420258685042", "scope": "READ", "application_name": "ce1e94a2-9c3e-42fa-a2c6-1ee01815476b", "refresh_token_issued_at": "1420258685042", "status": "approved", "refresh_token_status": "approved", "api_product_list": "[PremiumWeatherAPI]", "expires_in": "1799", "developer.email": "tesla@weathersample.com", "organization_id": "0", "token_type": "BearerToken", "refresh_token": "IFl7jlijYuexu6XVSSjLMJq8SVXGOAAq", "client_id": "5jUAdGv9pBouF0wOH5keAVI35GBtx3dT", "access_token": "I6daIgMSiUgYX1K2qgQWPi37ztS6", "organization_name": "docs", "refresh_token_expires_in": "0", "refresh_count": "0" }
6. Klient wywołuje metodę Protected API
Teraz klient może wywoływać chroniony interfejs API za pomocą prawidłowego kodu dostępu. W tym Scenariusze są wysyłane do Apigee Edge (serwera proxy), a Edge odpowiada za ich weryfikację token dostępu przed przekazaniem wywołania interfejsu API do docelowego serwera zasobów. Tokeny dostępu są przekazywane w nagłówku autoryzacji. Na przykład:
$ curl -H "Authorization: Bearer I6daIgMSiUgYX1K2qgQWPi37ztS6 " http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282