Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje
W tej sekcji opisaliśmy, jak włączyć pobieranie i unieważnianie tokenów dostępu OAuth 2.0 według identyfikatora użytkownika, identyfikatora aplikacji lub obu tych metod. Funkcja identyfikatora użytkownika wymaga specjalnej konfiguracji opisanej w tym temacie. Użytkownik to użytkownik aplikacji, która wywołuje interfejs API.
Kiedy włączyć dostęp na podstawie identyfikatora użytkownika
Czasami warto zapisać identyfikator użytkownika w tokenie dostępu. Włącz funkcję dostępu za pomocą identyfikatora użytkownika tylko wtedy, gdy masz odpowiedni przypadek użycia. Na przykład:
- Funkcja witryny lub aplikacji, dzięki której użytkownicy mogą sprawdzić, które aplikacje innych firm zostały autoryzowane, i umożliwić cofnięcie dostępu do tych aplikacji.
- Funkcja, która umożliwia upoważnionemu użytkownikowi unieważnienie wszystkich tokenów dostępu powiązanych z konkretną aplikacją dewelopera.
Informacje o tokenach dostępu OAuth
Identyfikatory aplikacji są automatycznie dodawane do tokena dostępu OAuth. Dlatego po włączeniu dla organizacji dostępu przy użyciu tokena w sposób opisany poniżej możesz unieważnić tokeny dostępu według identyfikatora aplikacji.
Aby można było pobrać i unieważnić tokeny dostępu OAuth 2.0 według identyfikatora użytkownika, token dostępu musi zawierać ten identyfikator. Procedura poniżej opisuje, jak dodać identyfikator użytkownika do istniejącego tokena.
Domyślnie, gdy Edge generuje token dostępu OAuth 2.0, token ma format przedstawiony poniżej:
{
"issued_at" : "1421847736581",
"application_name" : "a68d01f8-b15c-4be3-b800-ceae8c456f5a",
"scope" : "READ",
"status" : "approved",
"api_product_list" : "[PremiumWeatherAPI]",
"expires_in" : "3599", //--in seconds
"developer.email" : "tesla@weathersample.com",
"organization_id" : "0",
"token_type" : "BearerToken",
"client_id" : "k3nJyFJIA3p62DWOkLO6OJNi87GYXFmP",
"access_token" : "7S22UqXGJDTuUADGzJzjXzXSaGJL",
"organization_name" : "myorg",
"refresh_token_expires_in" : "0", //--in seconds
"refresh_count" : "0"
}
Pamiętaj:
- Pole application_name zawiera identyfikator UUID aplikacji powiązanej z tokenem. Jeśli włączysz pobieranie i unieważnianie tokenów dostępu OAuth 2.0 według identyfikatora aplikacji, jest to identyfikator aplikacji, którego używasz.
- Pole access_token zawiera wartość tokena dostępu OAuth 2.0.
W domyślnym tokenie dostępu OAuth nie ma pola na identyfikator użytkownika. Aby umożliwić pobieranie i unieważnianie tokenów dostępu OAuth 2.0 według identyfikatora użytkownika, musisz skonfigurować zasadę OAuth 2.0 tak, aby uwzględniała w tokenie identyfikator użytkownika zgodnie z procedurą poniżej. Pamiętaj, że jeśli chcesz tylko pobierać i unieważniać tokeny dostępu OAuth 2.0 według identyfikatora aplikacji, nie musisz włączać dostępu przez identyfikator użytkownika końcowego.
Przekazujesz identyfikator użytkownika do punktu końcowego tworzenia tokena. Identyfikator użytkownika możesz przekazywać jako parametr zapytania, parametr formularza lub w nagłówku (co zostało wyjaśnione w dalszej części tego tematu). Po skonfigurowaniu przeglądarki Edge w celu uwzględnienia identyfikatora użytkownika w tokenie zostanie on uwzględniony w polu app_enduser, jak pokazano poniżej:
{
"issued_at" : "1421847736581",
"application_name" : "a68d01f8-b15c-4be3-b800-ceae8c456f5a",
"scope" : "READ",
"app_enduser" : "6ZG094fgnjNf02EK",
"status" : "approved",
"api_product_list" : "[PremiumWeatherAPI]",
"expires_in" : "3599", //--in seconds
"developer.email" : "tesla@weathersample.com",
"organization_id" : "0",
"token_type" : "BearerToken",
"client_id" : "k3nJyFJIA3p62DWOkLO6OJNi87GYXFmP",
"access_token" : "7S22UqXGJDTuUADGzJzjXzXSaGJL",
"organization_name" : "myorg",
"refresh_token_expires_in" : "0", //--in seconds
"refresh_count" : "0"
}
Aby dowiedzieć się, jak wykonywać wywołania interfejsu API, które powodują pobieranie i unieważnianie danych, zobacz te inteligentne dokumenty:
- Unieważnianie tokena dostępu OAuth2 według użytkownika lub identyfikatora aplikacji
- Uzyskiwanie tokena dostępu OAuth2 według użytkownika lub identyfikatora aplikacji
Zapewnienie dostępu do tokenów OAuth 2.0 według identyfikatora użytkownika i identyfikatora aplikacji
Sposób włączania dostępu do tokenów OAuth 2.0 według identyfikatora użytkownika i identyfikatora aplikacji zależy od sposobu wdrożenia Edge:
Wdrożenie w chmurze
Wdrożenie Edge w chmurze oznacza, że większość konfiguracji jest obsługiwana przez Apigee. Musisz tylko skonfigurować zasadę OAuth 2.0 tak, aby dodać identyfikator użytkownika do tokena dostępu. Więcej informacji znajdziesz w poniższej procedurze.
Wdrożenie brzegowe chmury prywatnej
W przypadku Apigee Edge dla Private Cloud (lokalnej) jesteś w pełni odpowiedzialna za konfigurację. Więcej informacji znajdziesz w opisie operacji i konfiguracji.
Hybrydowe Apigee
Dostęp do tokenów OAuth 2.0 według identyfikatora użytkownika jest domyślnie włączony. Musisz tylko skonfigurować zasadę OAuth 2.0 tak, aby dodać identyfikator użytkownika do tokena dostępu. Aby dowiedzieć się więcej, zobacz krok 5 tej procedury.
Włączanie dostępu w chmurze
Krok 1. Włącz obsługę tej funkcji w organizacji
Ta funkcja musi być włączona w każdej organizacji, która ma obsługiwać tę funkcję.
Skontaktuj się z zespołem pomocy Apigee Edge i poproś o zaktualizowanie organizacji.
Krok 2. Przyznaj rolom opsadmin i orgadmin uprawnienia do zasobów oauth2
Uprawnienia do pobierania (get) i unieważniania (put) wywołań zasobu oauth2 na podstawie identyfikatora użytkownika lub identyfikatora aplikacji powinny mieć tylko role orgadmin oraz opsadmin.
Możesz użyć wywołania interfejsu API Get Permission for a Resource, aby sprawdzić, które role mają uprawnienia get i put do zasobu oauth2.
Jeśli musisz dodać lub usunąć uprawnienia, skontaktuj się z zespołem pomocy Apigee Edge i poproś o przeprowadzenie aktualizacji.
Krok 3. Skopiuj istniejące tokeny dostępu OAuth 2.0 do węzłów Cassandra
Wykonywane przez zespół pomocy Apigee: w tym zadaniu kopie istniejących tokenów dostępu OAuth 2.0 z organizacji, których dotyczy problem, zostaną skopiowane i zapisane w węzłach Cassandra. Ta procedura zostanie wykonana w węzłach Cassandra dla każdego poda Apigee Edge. Dzięki temu będzie można pobierać i anulować wywołania interfejsu API w odniesieniu do wszystkich istniejących i nowo wygenerowanych tokenów dostępu OAuth 2.0.
Krok 4. Dodaj właściwość oauth_max_search_limit do serwera zarządzania i podmiotu przetwarzającego wiadomości
W tym zadaniu pliki keymanagement.properties serwera zarządzania i podmiotu przetwarzającego wiadomości zostaną zaktualizowane, aby zawierały tę właściwość: oauth_max_search_limit =
100. 100 to zalecana wartość Apigee, ale można ją ustawić według własnego uznania.
Skontaktuj się z zespołem pomocy Apigee Edge i poproś o wprowadzenie tego ustawienia.
Krok 5. Skonfiguruj zasadę OAuth 2.0, aby wygenerować tokeny dostępu zawierające identyfikatory użytkowników
Skonfiguruj zasadę OAuth 2.0 używaną do generowania tokenów dostępu, aby uwzględnić w tokenie identyfikator użytkownika Jeśli uwzględnisz w tokenach dostępu identyfikatory użytkowników, będziesz mieć możliwość pobierania i unieważniania danych za pomocą identyfikatora użytkownika.
Aby skonfigurować zasadę, aby uwzględnić identyfikator użytkownika w tokenie dostępu, musisz określić zmienną wejściową zawierającą ten identyfikator. Aby określić zmienną, użyj tagu <AppEndUser>.
Poniższa zasada OAuth 2.0 o nazwie GenerateAccessTokenClient generuje token dostępu OAuth 2.0. Zwróć uwagę na dodatkowy tag <AppEndUser> wyróżniony pogrubieniem:
<OAuthV2 async="false" continueOnError="false" enabled="true" name="GenerateAccessTokenClient">
<DisplayName>OAuth 2.0.0 1</DisplayName>
<ExternalAuthorization>false</ExternalAuthorization>
<Operation>GenerateAccessToken</Operation>
<SupportedGrantTypes>
<GrantType>client_credentials</GrantType>
</SupportedGrantTypes>
<GenerateResponse enabled="true"/>
<GrantType>request.queryparam.grant_type</GrantType>
<AppEndUser>request.header.appuserID</AppEndUser>
<ExpiresIn>960000</ExpiresIn>
</OAuthV2>
Możesz następnie użyć poniższego polecenia cURL, aby wygenerować token dostępu OAuth 2.0, przekazując identyfikator użytkownika jako nagłówek appuserID:
curl -H "appuserID:6ZG094fgnjNf02EK" / https://myorg-test.apigee.net/oauth/client_credential/accesstoken?grant_type=client_credentials / -X POST / -d 'client_id=k3nJyFJIA3p62TKIkLO6OJNi87GYXFmP&client_secret=gk58jK5lIp943AY4'
W tym przykładzie appuserID jest przekazywany jako nagłówek żądania. Informacje możesz przekazywać w ramach żądania na wiele sposobów. Na przykład możesz:
- Używanie zmiennej parametru formularza: request.formparam.appuserID
- Użyj zmiennej przepływu, która zawiera identyfikator użytkownika