Edge per Private Cloud v. 4.17.01
Questo documento descrive come attivare il recupero e la revoca dei token di accesso OAuth 2.0 in base all'ID utente finale, all'ID app o a entrambi.
Gli ID app vengono aggiunti automaticamente a un token di accesso OAuth. Pertanto, dopo aver utilizzato la procedura riportata di seguito per attivare l'accesso ai token per un'organizzazione, puoi accedere ai token in base all'ID app.
Per recuperare e revocare i token di accesso OAuth 2.0 in base all'ID utente finale, è necessario che nel token di accesso sia presente un ID utente finale. La procedura riportata di seguito descrive come aggiungere un ID utente finale a un token esistente o a nuovi token.
Per impostazione predefinita, quando Edge genera un token di accesso OAuth 2.0, il token ha il formato:
{ "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" }
Tieni presente quanto segue:
- Il campo application_name contiene l'UUID dell'app associata al token. Se attivi il recupero e la revoca dei token di accesso OAuth 2.0 in base all'ID app, questo è l'ID app che utilizzi.
- Il campo access_token contiene il valore del token di accesso OAuth 2.0.
Per abilitare il recupero e la revoca dei token di accesso OAuth 2.0 in base all'ID utente finale, configura il criterio OAuth 2.0 in modo da includere l'ID utente nel token, come descritto nella procedura riportata di seguito.
L'ID utente finale è la stringa utilizzata da Edge come ID sviluppatore, non l'indirizzo email dello sviluppatore. Puoi determinare l'ID dello sviluppatore dall'indirizzo email dello sviluppatore utilizzando la chiamata dell'API Get Developer.
Dopo aver configurato Edge in modo da includere l'ID utente finale nel token, questo viene incluso come campo app_enduser, come mostrato di seguito:
{ "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" }
API per recuperare e revocare i token di accesso OAuth 2.0 per ID utente e ID app
Utilizza le seguenti API per accedere ai token OAuth in base all'ID utente, all'ID app o a entrambi:
- Ottenere il token di accesso OAuth 2.0 tramite ID utente finale o ID app
- Revoca del token di accesso OAuth 2.0 per ID utente finale o ID app
Procedura per l'abilitazione dell'accesso al token
Utilizza la procedura seguente per abilitare il recupero e la revoca dei token di accesso OAuth 2.0 in base all'ID utente finale e all'ID app.
Passaggio 1: attiva il supporto dell'accesso tramite token per un'organizzazione
Devi attivare l'accesso tramite token per ogni organizzazione separatamente. Chiama l'API PUT riportata di seguito per ogni organizzazione in cui vuoi attivare il recupero e la revoca dei token di accesso OAuth 2.0 in base all'ID utente finale o all'ID app.
L'utente che effettua la chiamata seguente deve avere il ruolo orgadmin o opsadmin per l'organizzazione. Sostituisci i valori in {curly braces} con i valori specifici della tua organizzazione:
> 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}
Passaggio 2: imposta le autorizzazioni per il ruolo opsadmin nell'organizzazione
Solo ai ruoli orgadmin e opsadmin di un'organizzazione devono essere concesse le autorizzazioni per recuperare (HTTP GET) e revocare (HTTP PUT) i token OAuth 2.0 in base all'ID utente o all'ID app. Per controllare l'accesso, imposta le autorizzazioni get e put sulla risorsa /oauth2 per un'organizzazione. La risorsa ha un URL nel seguente formato:
https://<ms-ip>:8080/v1/organizations/{org_name}/oauth2
Il ruolo orgadmin dovrebbe già disporre delle autorizzazioni necessarie. Per il ruolo opsadmin per la risorsa /oauth2, le autorizzazioni dovrebbero essere simili a quelle riportate di seguito:
<ResourcePermission path="/oauth2"> <Permissions> <Permission>get</Permission> <Permission>put</Permission> </Permissions> </ResourcePermission>
Puoi utilizzare la chiamata Ottieni autorizzazione per un'API di singola risorsa per vedere quali ruoli dispongono delle autorizzazioni per la risorsa /oauth2.
In base alla risposta, puoi utilizzare le chiamate API Aggiungi autorizzazioni per risorsa a un ruolo ed Elimina autorizzazione per risorsa per apportare le modifiche necessarie alle autorizzazioni della risorsa /oauth2.
Utilizza il seguente comando cURL per concedere al ruolo opsadmin le autorizzazioni get e put per la risorsa /oauth2. Sostituisci i valori in {curly braces} con i valori specifici della tua organizzazione:
> 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}
Utilizza il seguente comando cURL per revocare le autorizzazioni get e put per la risorsa /oauth2 da ruoli diversi da orgadmin e opsadmin. Sostituisci i valori in {curly braces} con i valori specifici della tua organizzazione:
> 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}
Passaggio 3: imposta la proprietà oauth_max_search_limit
Assicurati che la proprietà conf_keymanagement_oauth_max_search_limit nel file /opt/apigee/customer/application/management-server.properties sia impostata su 100:
conf_keymanagement_oauth_max_search_limit = 100
Se questo file non esiste, creane uno.
Questa proprietà imposta le dimensioni della pagina utilizzate durante il recupero dei token. Apigee consiglia un valore di 100, ma puoi impostarlo come preferisci.
In una nuova installazione, la proprietà dovrebbe essere già impostata su 100. Se devi modificare il valore di questa proprietà, riavvia il server di gestione e il processore di messaggi utilizzando i comandi:
> /opt/apigee/apigee-service/bin/apigee-service edge-management-server restart > /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
Passaggio 4: configura il criterio OAuth 2.0 che genera token per includere l'ID utente finale
Configura il criterio OAuth 2.0 utilizzato per generare i token di accesso in modo da includere l'ID utente finale nel token. Se includi gli ID utente finale nel token di accesso, puoi recuperare e revocare i token per ID.
Per configurare il criterio in modo da includere un ID utente finale in un token di accesso, la richiesta che crea il token di accesso deve includere l'ID utente finale e devi specificare la variabile di input che contiene l'ID utente finale.
Il criterio OAuth 2.0 riportato di seguito, denominato GeneraAccessTokenClient, genera un token di accesso OAuth 2.0. Tieni presente l'aggiunta del tag <AppEndUser> in grassetto che specifica la variabile contenente l'ID utente finale:
<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>
Puoi quindi utilizzare il seguente comando cURL per generare il token di accesso OAuth 2.0, passando l'ID utente come intestazione 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'
In questo esempio, appuserID viene passato come intestazione di richiesta. Puoi trasmettere le informazioni all'interno di una richiesta in molti modi. Ad esempio, in alternativa, puoi:
- Utilizza una variabile del parametro del modulo: request.formparam.appuserID
- Utilizza una variabile di flusso che fornisca l'ID utente finale