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

Ten dokument opisuje, jak włączyć pobieranie i unieważnianie tokenów dostępu OAuth 2.0 według identyfikatora użytkownika, identyfikatora aplikacji lub obu tych parametrów.

Identyfikatory aplikacji są automatycznie dodawane do tokena dostępu OAuth. Dlatego po włączeniu dostępu przez token dla organizacji za pomocą poniższej procedury możesz uzyskiwać 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, token dostępu musi zawierać identyfikator użytkownika. Poniżej opisano procedurę dodawania identyfikatora użytkownika końcowego do istniejącego lub nowego tokena.

Domyślnie, gdy Edge generuje token dostępu OAuth 2.0, ma on 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 tokiem. Jeśli włączysz pobieranie i unieważnia tokenów dostępu OAuth 2.0 według identyfikatora aplikacji, to właśnie ten identyfikator będzie używany.
  • Pole access_token zawiera wartość tokena dostępu OAuth 2.0.

Aby umożliwić pobieranie i odwoływanie tokenów dostępu OAuth 2.0 na podstawie identyfikatora użytkownika, skonfiguruj zasadę OAuth 2.0 tak, aby zawierała identyfikator użytkownika w tokenie. Aby to zrobić, wykonaj czynności opisane poniżej.

Identyfikator użytkownika to ciąg znaków, którego Edge używa jako identyfikatora dewelopera, a nie adres e-mail dewelopera. Identyfikator dewelopera możesz określić na podstawie jego adresu e-mail, korzystając z wywołania interfejsu API dewelopera.

Gdy skonfigurujesz Edge tak, aby uwzględniała identyfikator użytkownika końcowego w tokenie, zostanie on dodany jako pole 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",
  "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 tokenów dostępu OAuth 2.0 według identyfikatora użytkownika i identyfikatora aplikacji

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

Procedura włączania dostępu za pomocą tokena

Aby umożliwić pobieranie i unieważnianie tokenów dostępu OAuth 2.0 według identyfikatora użytkownika końcowego i identyfikatora aplikacji, wykonaj podaną niżej procedurę.

Krok 1. Włącz obsługę tokenów dostępu w organizacji

W przypadku każdej organizacji musisz osobno włączyć dostęp tokenów. Wywołaj poniższy interfejs PUT API w przypadku każdej 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 ten wywołanie musi mieć rolę orgadmin lub opsadmin w organizacji. Zastąp values wartościami określonymi w Twojej organizacji:

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. Skonfiguruj uprawnienia dla roli administratora operacyjnego w organizacji

Tylko użytkownicy o rolach orgadminopsadmin w organizacji powinni mieć uprawnienia do pobierania (HTTP GET) i odwoływania (HTTP PUT) tokenów OAuth 2.0 na podstawie identyfikatora użytkownika lub identyfikatora aplikacji. Aby kontrolować dostęp, skonfiguruj uprawnienia get i put dla zasobu /oauth2 dla organizacji. Adres URL tego zasobu ma postać:

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

Rola orgadmin powinna już mieć wymagane uprawnienia. W przypadku roli opsadmin dla zasobu /oauth2 uprawnienia powinny wyglądać tak:

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

Aby sprawdzić, które role mają uprawnienia do zasobu /oauth2, możesz użyć wywołania Get Permission for a Single Resource API.

Na podstawie odpowiedzi możesz użyć wywołań interfejsu API Dodaj uprawnienia zasobu do roli i Usuń uprawnienia zasobu, aby wprowadzić niezbędne zmiany w uprawnieniach zasobu /oauth2.

Aby przyznać roli opsadmin uprawnienia get i put w zasobie /oauth2, użyj tego polecenia curl. Zastąp values wartościami specyficznymi dla 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

Za pomocą poniższego polecenia curl unieważnij uprawnienia get i put dla zasobu /oauth2 z ról innych niż orgadmin i opsadmin. Zastąp values wartościami odpowiednimi dla Twojej 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. Skonfiguruj właściwość oauth_max_search_limit

Sprawdź, czy właściwość conf_keymanagement_oauth_max_search_limit w pliku /opt/apigee/customer/application/management-server.properties ma wartość 100:

conf_keymanagement_oauth_max_search_limit = 100

Jeśli tego pliku nie ma, utwórz go.

Ta właściwość określa rozmiar strony używany podczas pobierania tokenów. Apigee zaleca wartość 100, ale możesz ją ustawić według własnego uznania.

W przypadku nowej instalacji ta wartość powinna wynosić 100. Jeśli musisz zmienić wartość tej właściwości, uruchom ponownie serwer zarządzania i przetwarzanie wiadomości za pomocą tych poleceń:

/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, tak aby zawierała identyfikator użytkownika

Skonfiguruj zasadę OAuth 2.0 używaną do generowania tokenów dostępu, aby uwzględnić w tokenie identyfikator użytkownika. Dzięki uwzględnieniu identyfikatorów użytkowników w tokenie dostępu możesz pobierać i unieważniać tokeny według identyfikatora.

Aby skonfigurować zasady tak, aby zawierały identyfikator użytkownika w tokenie dostępu, żądanie, które tworzy token dostępu, musi zawierać identyfikator użytkownika. Musisz też określić zmienną wejściową zawierającą identyfikator użytkownika.

Podana niżej zasada OAuth 2.0 o nazwie GenerateAccessTokenClient generuje token dostępu OAuth 2.0. Zwróć uwagę na dodany pogrubiony tag <AppEndUser>, który określa zmienną zawierającą identyfikator użytkownika:

<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ć poniższego polecenia curl, aby wygenerować token dostępu OAuth 2.0, przekazując identyfikator użytkownika w nagłówku 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 przekazywane jako nagłówek żądania. Informacje w ramach żądania możesz przekazywać na wiele sposobów. Możesz na przykład:

  • Użyj zmiennej parametru formularza: request.formparam.appuserID
  • Używanie zmiennej przepływu, która udostępnia identyfikator użytkownika