Ta strona została przetłumaczona przez Cloud Translation API.

Włącz dostęp do tokenów OAuth 2.0 za pomocą identyfikatora użytkownika i identyfikatora aplikacji

Edge for Private Cloud w wersji 4.19.01

Ten dokument opisuje, jak włączyć pobieranie i unieważnianie tokenów dostępu OAuth 2.0 przez identyfikator użytkownika, identyfikator aplikacji lub oba te elementy.

Identyfikatory aplikacji są automatycznie dodawane do tokena dostępu OAuth. Dlatego po użyciu poniżej, aby włączyć dostęp tokenem dla organizacji, możesz uzyskać dostęp do tokenów 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 tokenie dostępu. Poniżej opisano procedurę dodawania identyfikatora użytkownika końcowego do istniejącego tokena lub do nowych tokenów.

Domyślnie, gdy Edge wygeneruje token dostępu OAuth 2.0, token ma format:

{
  "issued_at" : "1421847736581",
  "application_name" : "a68d01f8-b15c-4be3-b800-ceae8c456f5a",
  "scope" : "READ",
  "status" : "approved",
  "api_product_list" : "[PremiumWeatherAPI]",
  "expires_in" : "3599",
  "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",
  "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.

Aby umożliwić pobieranie i unieważnianie tokenów dostępu OAuth 2.0 według identyfikatora użytkownika, skonfiguruj zasady OAuth 2.0 uwzględniające identyfikator użytkownika w tokenie, zgodnie z poniższą procedurą.

Identyfikator użytkownika to ciąg znaków używany przez Edge jako identyfikator dewelopera, a nie adres e-mail dewelopera. adresu. Identyfikator dewelopera możesz określić na podstawie adresu e-mail dewelopera przy użyciu metody Wywołanie interfejsu Developer API.

Gdy skonfigurujesz Edge tak, aby dołączała identyfikator użytkownika końcowego do tokena, 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",
  "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",
  "refresh_count" : "0"
}

Interfejsy API do pobierania i unieważniania Tokeny dostępu OAuth 2.0 według identyfikatora użytkownika i identyfikatora aplikacji

Użyj tych interfejsów API, aby uzyskać dostęp do tokenów OAuth według identyfikatora użytkownika, identyfikatora aplikacji lub obu tych elementów:

Procedura włączania dostępu do tokena

Wykonaj poniższe czynności, aby włączyć pobieranie i unieważnianie tokenów dostępu OAuth 2.0 przez identyfikator użytkownika i identyfikator aplikacji.

Krok 1. Włącz obsługę dostępu opartego na tokenach w organizacji

Dostęp za pomocą tokena musisz włączyć oddzielnie dla każdej organizacji. Wywołaj poniższy interfejs PUT API dla każdego organizacji, w której chcesz włączyć pobieranie i unieważnianie tokenów dostępu OAuth 2.0 według identyfikatora użytkownika lub identyfikatora aplikacji.

Użytkownik wykonujący poniższe wywołanie musi mieć rolę orgadmin lub opsadmin dla organizacji. Zastąp values wartością odpowiednią dla Twojej organizacji wartości:

curl -H "Content-type:text/xml" -X POST \
  https://management_server_IP;:8080/v1/organizations/org_name \
  -d '<Organization name="org_name">
      <Properties>
        <Property name="features.isOAuthRevokeEnabled">true</Property>
        <Property name="features.isOAuth2TokenSearchEnabled">true</Property>
      </Properties>
    </Organization>' \
  -u USER_EMAIL:PASSWORD

Krok 2. Ustaw uprawnienia roli Opsadmin w organizacji

Tylko role orgadmin i opsadmin w organizacji powinien mieć uprawnienia do pobierania (HTTP GET) i unieważniania tokenów OAuth (HTTP PUT) w oparciu o identyfikatora użytkownika lub identyfikatora aplikacji. Aby kontrolować dostęp, ustaw uprawnienia pobierania i przyznaj uprawnienia do zasobu /oauth2 dla: organizacji. Ten zasób ma adres URL w formacie:

https://management_server_IP:8080/v1/organizations/org_name/oauth2

Rola orgadmin powinna już mieć niezbędne uprawnienia. W przypadku atrybutu Rola opsadmin dla zasobu /oauth2 powinna wyglądać tak: to:

<ResourcePermission path="/oauth2">
  <Permissions>
    <Permission>get</Permission>
    <Permission>put</Permission>
  </Permissions>
</ResourcePermission>

Możesz użyć metody Pobierz Uprawnienie dla wywołania interfejsu Single Resource API w celu sprawdzenia, które role mają uprawnienia dla /oauth2 zasób.

Na podstawie odpowiedzi możesz użyć przycisku Dodaj uprawnienia zasobu do roli oraz ; Usuń uprawnienie dla wywołań interfejsu Resource API, aby wprowadzić niezbędne zmiany w /oauth2 uprawnienia do zasobów.

Aby przypisać rolę opsadmin, użyj tego polecenia curl Uprawnienia get i put dla zasobu /oauth2. Zastąp values z wartościami obowiązującymi w Twojej organizacji:

curl -X POST -H 'Content-type:application/xml' \
  http://management_server_IP:8080/v1/organizations/org_name/userroles/opsadmin/permissions \
  -d '<ResourcePermission path="/oauth2">
      <Permissions>
        <Permission>get</Permission>
        <Permission>put</Permission>
      </Permissions>
    </ResourcePermission>' \
  -u USEREMAIL:PASSWORD

Aby unieważnić get i put, użyj tego polecenia curl uprawnienia dla zasobu /oauth2 dla ról innych niż orgadmin i opsadmin. Zamień values na wartości właściwe dla organizacji:

curl -X DELETE -H 'Content-type:application/xml' \
  http://management_server_IP:8080/v1/organizations/org_name/userroles/roles/permissions \
  -d '<ResourcePermission path="/oauth2">
      <Permissions></Permissions>
    </ResourcePermission>' \
   -u USEREMAIL:PASSWORD

Krok 3: Konfiguracja właściwość oauth_max_search_limit

Upewnij się, że conf_keymanagement_oauth_max_search_limit miejsce zakwaterowania w: /opt/apigee/customer/application/management-server.properties ma wartość 100:

conf_keymanagement_oauth_max_search_limit = 100

Jeśli ten plik nie istnieje, utwórz go.

Ta właściwość określa rozmiar strony używanej przy pobieraniu tokenów. Apigee zaleca wartość 100, ale możesz ustawić je według własnego uznania.

W nowej instalacji właściwość powinna już mieć wartość 100. Jeśli zajdzie potrzeba zmiany adresu należy ponownie uruchomić serwer zarządzania i procesor komunikatów za pomocą polecenia:

/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

Krok 4. Skonfiguruj zasadę OAuth 2.0, która generuje tokeny, aby uwzględnić identyfikator użytkownika

Skonfiguruj zasadę OAuth 2.0 używaną do generowania tokenów dostępu, aby uwzględnić identyfikator użytkownika w token. Dzięki umieszczeniu identyfikatorów użytkowników w tokenie dostępu możesz pobierać i unieważniać tokeny za pomocą ID.

Aby skonfigurować zasadę tak, aby w tokenie dostępu uwzględniała identyfikator użytkownika, żądanie tworzące token dostępu musi zawierać identyfikator użytkownika końcowego. Trzeba też określić zmienną wejściową, zawiera identyfikator użytkownika.

Poniższa zasada OAuth 2.0 o nazwie GenerateAccessTokenClient generuje dostęp OAuth 2.0 token. Zwróć uwagę na pogrubiony tag <AppEndUser>, który określa zmienną zawierającą identyfikator użytkownika końcowego:

<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 użyć następującego polecenia curl, aby wygenerować dostęp OAuth 2.0 i 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=k3nJyFJIA3p62TKIkLO6OJNXFmP&client_secret=gk5K5lIp943AY4'

W tym przykładzie appuserID jest przekazywany jako nagłówek żądania. Możesz zdać zawarte w prośbie na wiele sposobów. Możesz na przykład:

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