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

Edge for Private Cloud wer. 4.17.05

W tym dokumencie opisujemy, jak włączyć pobieranie i unieważnianie tokenów dostępu OAuth 2.0 za pomocą identyfikatora użytkownika, identyfikatora aplikacji lub obu tych metod.

Identyfikatory aplikacji są automatycznie dodawane do tokena dostępu OAuth. Dlatego po wykonaniu czynności opisanej poniżej w celu włączenia dostępu przez tokeny w organizacji będziesz mieć 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ć ten identyfikator. Poniżej opisujemy, jak dodać identyfikator użytkownika do istniejącego lub do nowych tokenów.

Domyślnie, gdy Edge generuje 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 zasadę OAuth 2.0, aby uwzględnić identyfikator użytkownika w tokenie w sposób opisany poniżej.

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

Gdy skonfigurujesz Edge w taki sposób, aby zawierała identyfikator użytkownika końcowego 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",
  "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, identyfikatora aplikacji lub obu tych parametrów, użyj tych interfejsów API:

Procedura włączania dostępu do tokenów

Aby włączyć pobieranie i unieważnianie tokenów dostępu OAuth 2.0 według identyfikatora użytkownika i identyfikatora aplikacji, wykonaj podane niżej czynności.

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

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

Użytkownik, który wykonuje poniższe wywołanie, musi mieć przypisaną rolę orgadmin lub opsadmin w organizacji. Zastąp wartości w {nawiasach klamrowych} wartościami właściwymi 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. Ustaw uprawnienia roli opsadmin w organizacji

Tylko role orgadmin i opsadmin w organizacji powinny mieć uprawnienia do pobierania (HTTP GET) i unieważniania tokenów OAuth 2.0 (HTTP PUT) na podstawie identyfikatora użytkownika lub identyfikatora aplikacji. Aby kontrolować dostęp, ustaw uprawnienia na potrzeby pobierania i przyznawania uprawnień do zasobu /oauth2 organizacji. Ten zasób ma adres URL w postaci:

https://<ms-ip>:8080/v1/organizations/{org_name}/oauth2

Rola orgadmin powinna już mieć niezbędne uprawnienia. Uprawnienia roli opsadmin w zasobie /oauth2 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 Add Permissions for Resource to a Role (Dodaj uprawnienia zasobu do roli) i Delete Permission for Resource (Usuń uprawnienia do zasobu), aby wprowadzić niezbędne zmiany w uprawnieniach zasobów /oauth2.

Użyj poniższego polecenia cURL, aby przypisać rolę opsadmin rolę get i put do zasobu /oauth2. Zastąp wartości w nawiasach klamrowych {curly braces} wartościami właściwymi 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} 

Za pomocą tego polecenia cURL możesz anulować uprawnienia get i put dla zasobu /oauth2 na podstawie ról innych niż orgadmin i opsadmin. Zastąp wartości w {nawiasach klamrowych} wartościami właściwymi 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

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 ten 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 ją ustawić według własnego uznania.

W nowej instalacji właściwość powinna być już ustawiona na 100. Jeśli musisz zmienić wartość tej właściwości, uruchom ponownie serwer zarządzania i procesor wiadomości przy użyciu 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 z identyfikatorem użytkownika

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

Aby skonfigurować zasadę, aby uwzględnić identyfikator użytkownika w tokenie dostępu, żądanie, które tworzy token dostępu, musi zawierać ten identyfikator i musisz określić zmienną wejściową zawierającą ten identyfikator.

Poniższa zasada OAuth 2.0 o nazwie GenerateAccessTokenClient generuje token dostępu OAuth 2.0. Zwróć uwagę na dodatkowy pogrubiony tag <AppEndUser> określający 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>

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=k3nJyFJIA3p62TKIkLO6OJNXFmP&client_secret=gk5K5lIp943AY4'

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