6

Per l'utilizzo con Gestione API di Azure, Sto tentando di aggiungere ad Azure Active Directory (AAD) a livello di programmazione, nel mio caso utilizzando l'API Graph.Aggiunta di applicazioni a livello di programmazione in Azure AD Flusso di credenziali del client

Il mio scenario è il seguente: Al fine di proteggere un'API Web che desidero gestire con Azure API Management, voglio sfruttare la funzionalità OAuth di AAD per eseguire operazioni pesanti di autenticazione e rilascio dei token JWT, quindi utilizzare semplicemente il criterio validate-jwt per verificare che tutto sia a posto in Gestione API di Azure. Questo ha il vantaggio che posso più o meno omettere l'autenticazione nel mio servizio di back-end.

Questo funziona correttamente, purché sia ​​stata creata un'applicazione in Azure AD per l'applicazione Web di consumo, ma questa operazione deve essere eseguita manualmente dal portale di Azure; L'API di Azure non lo fa automaticamente.

Ora per quello che sto cercando di fare per ottenere il risultato automatico: volevo delegare l'abbonamento alle API in APIm ad un'altra app Web che sto scrivendo, e da lì voglio sfruttare l'API Graph per creare un Applicazione in Azure AD e concedere le autorizzazioni all'applicazione dell'API.

La prima cosa che ho cercato di fare era di avere una terza applicazione (la mia applicazione di servizio) con le autorizzazioni complete dell'applicazione all'applicazione Windows Azure Active Directory in Azure AD; ciò consente alla mia applicazione di accedere a AAD utilizzando l'API Graph REST. Riesco ad ottenere un token di accesso utilizzando la concessione client_credentials (da login.microsoft.com), ma questo token non mi permetta di fare un POST su https://graph.windows.net/(my AAD ID)/applications?api-version=1.5:

{ 
     "odata.error": { 
      "code": "Authorization_RequestDenied", 
      "message": { 
       "lang": "en", 
       "value": "Insufficient privileges to complete the operation." 
      } 
     } 
    } 

ho trovato (https://msdn.microsoft.com/Library/Azure/Ad/Graph/howto/azure-ad-graph-api-permission-scopes) che anche se mi concedo il permesso Directory.ReadWrite.All, l'applicazione (app-solo) non sarà in grado di creare o aggiornare le applicazioni:

Nota: esclude specificamente creare o aggiornare per le entità non elencati sopra. Questo include: Applicazione, Oauth2PermissionGrant, AppRoleAssignment, periferiche, ServicePrincipal, TenantDetail, domini, ecc

La prossima cosa che ho provato è stata la password di Grant Resource proprietario (grant_type=password), passando le mie credenziali in più, in modo che Posso impersonare me stesso nell'API Graph. Ora, il mio POST per il punto finale applications ha esito positivo.

La mia domanda bottom-of-the-line è: Posso concedere le autorizzazioni sufficienti per la mia applicazione in modo che io possa aggiungere applicazioni di programmazione utilizzando il flusso di credenziali del client, e non qualsiasi flusso che agisce per conto di un utente? E se sì, come è fatto?

+0

ho trovato ancora una discussione che molto probabilmente si riduce a esattamente lo stesso problema che ho: https://social.technet.microsoft.com/Forums/en-US/82ab8a7d- e17b-4e4a-9615-2bdf43f1866a/graph-api-call-returns-insufficient-privileges-to-complete-the-operation? forum = WindowsAzureAD Inoltre, ho trovato anche la pagina in cui sono discussi i permessi dell'API Graph: https : //msdn.microsoft.com/Library/Azure/Ad/Graph/howto/azure-ad-graph-api-permission-scopes – donmartin

+0

Forniscono la soluzione per il tuo problema? – juvchan

+0

No, sfortunatamente no. Impersonare un amministratore è l'unica "soluzione" che ho trovato finora. – donmartin

risposta

3

Mi dispiace Don. Al momento non abbiamo alcun ambito di autorizzazione per il flusso di credenziali del client (solo app) che può essere utilizzato per creare applicazioni o entità di servizio o creare autorizzazioni di autorizzazione oauth2 (o qualsiasi altra entità che hai menzionato sopra tramite la Directory. ReadWrite.All permesso). Stiamo lavorando su autorizzazioni aggiuntive per app che ti consentiranno di illuminare questo scenario, ma non ho un ETA che posso darti.

Questa operazione dovrebbe essere possibile se si utilizza l'app + utente (flusso di codice) e di concedere l'applicazione il permesso Directory.AccessAsUser.All - fino a quando v'è un utente utilizzando la vostra applicazione e che sono un inquilino admin.Non sono sicuro che questa soluzione sia accettabile per te (e credo sia simile a quello che stai utilizzando con il flusso della password, anche se ti consiglierei di usare il flusso del codice qui).

UPDATE: Ci sono un paio di nuove autorizzazioni solo per le app aggiunte per il grafico AAD. Application.ReadWrite.OwnedBy (che consente a un'app di creare/possedere un'altra app, ma solo aggiornare le app che ha creato - non sarà in grado di toccare altre app che non possiede) AND Application.ReadWrite.All (che consente a un'app di creare/gestire TUTTE le app in un tenant). Sembra che il primo sia appropriato. È vedere questi visualizzati nel portale di Azure per la risorsa grafico AAD. Tuttavia non sono attualmente documentati AFAIK.

Spero che questo aiuti,

+0

Sì, sarebbe una soluzione accettabile. Nel frattempo, abbiamo anche proposto la seguente idea (non verificata), che va nella stessa direzione, ma non richiede che l'utente abbia il ruolo di consumer API come amministratore di Active Directory: possiamo "kickstart" sul web di controllo l'app con un codice di autorizzazione concede l'utilizzo delle credenziali dell'amministratore di AD (in modo da non doverle memorizzare nell'app), quindi aggiorna successivamente il token nell'app per mantenere la rappresentazione dell'amministratore all'interno dell'app senza richiedere l'intervento manuale. Ma anche questo lascia un cattivo gusto. – donmartin

+0

Così le credenziali del cliente fluiscono nel lavoro generale? – Gobliins

+0

No. Non è così. La concessione della password del proprietario della risorsa lo fa. – donmartin