Włącz pobieranie i unieważnianie tokenów dostępu OAuth 2.0 według identyfikatora użytkownika, identyfikatora aplikacji lub obu tych parametrów

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja Apigee X.
informacje.

W tej sekcji opisano, jak włączyć pobieranie i unieważnianie tokenów dostępu OAuth 2.0 przez identyfikator użytkownika, identyfikator aplikacji lub oba te elementy. Funkcja identyfikatora użytkownika wymaga specjalnej konfiguracji, tak jak to opisano w temat. Użytkownik końcowy odnosi się do użytkownika aplikacji, która wywołuje interfejs API.

Kiedy włączyć dostęp do identyfikatora użytkownika

Czasami warto przechowywać identyfikator użytkownika w tokenie dostępu. Włączanie dostępu do identyfikatora użytkownika końcowego tylko wtedy, gdy masz odpowiedni przypadek użycia. Na przykład:

  • Funkcja w witrynie lub aplikacji, dzięki której użytkownicy mogą sprawdzić, jakie aplikacje innych firm mają uprawnione oraz opcję unieważnienia dostępu do tych aplikacji.
  • Funkcja, która umożliwia upoważnionemu użytkownikowi unieważnianie wszystkich tokenów dostępu powiązanych z konkretnej aplikacji dewelopera.

Informacje o tokenach dostępu OAuth

Identyfikatory aplikacji są automatycznie dodawane do tokena dostępu OAuth. Dlatego po włączeniu tokena dostępu dla organizacji w sposób opisany poniżej możesz unieważniać 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, należy podać identyfikator użytkownika końcowego w tokenach dostępu. Poniższa procedura opisuje sposób dodawania identyfikatora użytkownika do istniejącego token.

Domyślnie, gdy Edge generuje token dostępu OAuth 2.0, token ma wyświetlany format 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 z tokenów dostępu OAuth 2.0 według identyfikatora aplikacji, to właśnie jest identyfikator aplikacji, którego używasz.
  • Pole access_token zawiera wartość tokena dostępu OAuth 2.0.

Domyślny token dostępu OAuth nie ma pola na identyfikator użytkownika. Aby włączyć pobieranie i unieważnienie tokenów dostępu OAuth 2.0 według identyfikatora użytkownika, musisz skonfigurować zasadę OAuth 2.0 , aby umieścić w tokenie identyfikator użytkownika w sposób opisany poniżej. Pamiętaj, że jeśli tylko chcesz pobrać i unieważnić tokeny dostępu OAuth 2.0 według identyfikatora aplikacji, nie musisz włączać dostęp według identyfikatora użytkownika.

Do punktu końcowego tworzenia tokena przekazujesz identyfikator użytkownika. Identyfikator użytkownika możesz przekazać jako parametr zapytania, parametr formularza lub w nagłówku (jak wyjaśniono w dalszej części tego tematu). Gdy skonfigurujesz Edge tak, aby uwzględnić użytkownika Identyfikator w tokenie jest zawarty w polu app_enduser, jak 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"
}

Więcej informacji o wykonywaniu wywołań interfejsu API, które wykonują te pobieranie i unieważnianie, znajdziesz w artykule te Dokumenty inteligentne:

Włączenie dostępu do tokenów OAuth 2.0 przez identyfikator użytkownika i identyfikator 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 Brzeg:

  • Wdrażanie w chmurze

    Wdrożenie Edge w chmurze oznacza, że większość konfiguracji jest obsługiwana przez Apigee. Ty odpowiadają jedynie za skonfigurowanie zasad OAuth 2.0, aby dodać identyfikator użytkownika do dostępu token. Aby dowiedzieć się więcej, zapoznaj się z poniższą procedurą.

  • Wdrożenie Edge na potrzeby Private Cloud

    W Apigee Edge dla Private Cloud (lokalnej) ponosisz pełną odpowiedzialność za konfiguracji. Więcej informacji można znaleźć w sekcji Operacje i Konfiguracja.

  • Apigee hybrydowy

    Dostęp do tokenów OAuth 2.0 według identyfikatora użytkownika jest domyślnie włączony. Ty odpowiadają jedynie za skonfigurowanie zasad OAuth 2.0, aby dodać identyfikator użytkownika do dostępu token. Więcej informacji znajdziesz w kroku 5 poniższej procedury.

Włączanie dostępu w chmurze

Krok 1. Włącz organizację w obsługują tę funkcję

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, aby poprosić o zaktualizowanie organizacji.

Krok 2. Przyznaj uprawnienia do zasobów oauth2 rolom Opsadmin i orgadmin

Należy nadać im tylko role orgadmin i opsadmin. uprawnienia do pobierania (get) i unieważniania (put) wywołań funkcji oauth2 zasób na podstawie identyfikatora użytkownika lub identyfikatora aplikacji.

Możesz użyć opcji Uzyskaj uprawnienia dla wywołania interfejsu Resource API w celu sprawdzenia, które role mają uprawnienia get i put uprawnienia dostępu do zasobu oauth2.

Jeśli musisz dodać lub usunąć jakieś uprawnienia, skontaktuj się z zespołem pomocy Apigee Edge, aby zlecić aktualizacje.

Krok 3. Skopiuj istniejące tokeny dostępu OAuth 2.0 do węzłów Cassandra

Wykonane przez zespół pomocy Apigee: w tym zadaniu zostaną utworzone kopie istniejącego protokołu OAuth 2.0 tokeny dostępu w organizacjach, których dotyczy problem, zostaną skopiowane i przechowywane w węzłach Cassandra. Procedura zostanie wykonany w węzłach Cassandra dla każdego poda Apigee Edge. Dzięki temu funkcja pobierania i unieważniania wywołań interfejsu API, aby wykonywać je dla wszystkich tokenów dostępu OAuth 2.0, istniejących nowo wygenerowane.

Krok 4. Dodaj właściwość oauth_max_search_limit do serwera zarządzania i wiadomości procesor

W tym zadaniu pliki keymanagement.properties serwera zarządzania oraz procesor wiadomości zostanie zaktualizowany, aby uwzględnić 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, aby poprosić o wprowadzenie tego interfejsu.

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 umieścić identyfikator użytkownika w token. Uwzględnienie identyfikatorów użytkowników w tokenach dostępu pozwoli na pobieranie danych. i unieważnia według identyfikatora użytkownika.

Aby skonfigurować zasadę uwzględniania identyfikatora użytkownika w tokenie dostępu, musisz podać zawierającą zmienną wejściową, która zawiera identyfikator użytkownika końcowego. Użyj tagu <AppEndUser>, aby określić .

Poniższa zasada OAuth 2.0 o nazwie GenerateAccessTokenClient generuje OAuth Token dostępu 2.0. Zwróć uwagę na dodanie pogrubionego tagu <AppEndUser>:

<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>

Następnie możesz wygenerować token dostępu OAuth 2.0 przy użyciu poniższego polecenia cURL, identyfikatora użytkownika w postaci parametru appuserID, nagłówek:

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 zawarte w prośbie możesz przekazać na wiele sposobów. Dla: Możesz też:

  • Używaj zmiennej parametru formularza: request.formparam.appuserID
  • Użyj zmiennej przepływu, która dostarcza identyfikator użytkownika końcowego