Edge for Private Cloud w wersji 4.17.01
Ten dokument zawiera opis sposobu włączania pobierania i odwoływania tokenów dostępu OAuth 2.0 według identyfikatora użytkownika lub identyfikatora aplikacji albo obu tych identyfikatorów.
Identyfikatory aplikacji są automatycznie dodawane do tokena dostępu OAuth. Dlatego po wykonaniu opisanej poniżej procedury włączania dostępu do tokenów dla organizacji możesz uzyskać dostęp do tokenów według identyfikatora aplikacji.
Aby pobrać i unieważnić tokeny dostępu OAuth 2.0 według identyfikatora użytkownika, musisz mieć w tokenie dostępu 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 tokenem. 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.
Po skonfigurowaniu przeglądarki Edge tak, aby zawierała identyfikator użytkownika 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 odwoływania 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:
- Uzyskiwanie tokena dostępu OAuth 2.0 na podstawie identyfikatora użytkownika końcowego lub identyfikatora aplikacji
- Unieważnianie tokena dostępu OAuth 2.0 na podstawie identyfikatora użytkownika końcowego lub identyfikatora aplikacji
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 interfejs PUT API poniżej w przypadku każdej organizacji, w której chcesz umożliwić pobieranie i odwoływanie tokenów dostępu OAuth 2.0 za pomocą identyfikatora użytkownika końcowego lub identyfikatora aplikacji.
Użytkownik wykonujący poniższe wywołanie musi mieć rolę orgadmin lub opsadmin w organizacji. Zastąp wartości w {nawiasach klamrowych} wartościami odpowiednimi dla Twojej organizacji:
> curl -H "Content-type:text/xml" -X POST \
https://<ms-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 {userEmail}:{mypassword}
Krok 2. Skonfiguruj uprawnienia dla roli administratora operacyjnego w organizacji
Tylko role orgadmin i opsadmin w organizacji powinny 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://<ms-ip>:8080/v1/organizations/{org_name}/oauth2
Rola orgadmin powinna już mieć niezbędne 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.
Za pomocą poniższego polecenia cURL przypisz rolę opsadmin uprawnienia get i put do zasobu /oauth2. Zastąp wartości w {nawiasy klamrowe} wartościami specyficznymi dla Twojej organizacji:
> curl -X POST -H 'Content-type:application/xml' \
http://<ms-ip>:8080/v1/organizations/{org}/userroles/opsadmin/permissions \
-d '<ResourcePermission path="/oauth2">
<Permissions>
<Permission>get</Permission>
<Permission>put</Permission>
</Permissions>
</ResourcePermission>' \
-u {USEREMAIL}:{PWD}
Użyj tego polecenia cURL, aby cofnąć uprawnienia get i put dla zasobu /oauth2 z ról innych niż orgadmin i opsadmin. Zastąp wartości w {nawiasach klamrowych} wartościami odpowiednimi dla Twojej organizacji:
> curl -X DELETE -H 'Content-type:application/xml' \
http://<msip>:8080/v1/organizations/{org-name}/userroles/{roles}/permissions \
-d '<ResourcePermission path="/oauth2">
<Permissions></Permissions>
</ResourcePermission>' \
-u {USEREMAIL}:{PWD}
Krok 3. Ustaw właściwość oauth_max_search_limit
Upewnij się, że wartość właściwości conf_keymanagement_oauth_max_search_limit w pliku /opt/apigee/customer/application/management-server.properties jest ustawiona na 100:
conf_keymanagement_oauth_max_search_limit = 100
Jeśli plik nie istnieje, utwórz go.
Ta właściwość określa rozmiar strony używany podczas pobierania tokenów. Apigee zaleca wartość 100, ale możesz ustawić ją 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ć zasadę tak, aby uwzględniała identyfikator użytkownika w tokenie dostępu, żądanie tworzące token dostępu musi zawierać identyfikator użytkownika końcowego oraz podać zmienną wejściową, która zawiera ten identyfikator.
Podana niżej zasada OAuth 2.0 o nazwie GenerateAccessTokenClient generuje token dostępu OAuth 2.0. Zwróć uwagę na dodanie pogrubionego tagu <AppEndUser>, który określa zmienną z identyfikatorem 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 wygenerować token dostępu OAuth 2.0 za pomocą poniższego polecenia cURL, 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 parametr appuserID jest przekazywany jako nagłówek żądania. Informacje w ramach żądania możesz przekazywać na wiele sposobów. Możesz na przykład:
- Używaj zmiennej parametru formularza: request.formparam.appuserID
- Używanie zmiennej przepływu, która udostępnia identyfikator użytkownika