Token dell'app
È possibile utilizzare gli app token di PowerShell Universal sia con gli endpoint API personalizzati sia con la management API. La management API utilizza i ruoli standard Administrator, Operator e Reader. Gli app token delle API personalizzate possono utilizzare sia ruoli personalizzati sia quelli integrati.
È possibile concedere gli App Token utilizzando la Admin Console oppure è possibile utilizzare direttamente la Management API.
Admin Console
Per concedere un token nella Admin Console, si porti su Security \ Tokens. Faccia clic sul pulsante Create App Token per concedere un App Token.
Quando fa clic su Create App Token, una finestra di dialogo consente di specificare Identity, Role e la scadenza del token.
Management API
È inoltre possibile concedere app token agli utenti dalla management API. Per concedere un App Token a livello di codice tramite l'API, può procedere come segue:
Gli amministratori possono concedere app token a qualsiasi utente specificando l'ID identity dell'utente. Per concedere un app token a un'identity tramite l'API REST, l'utente deve avere un ruolo definito. Il ruolo Operator definisce l'utente e al suo App Token verrà concesso l'accesso in base a tale ruolo.
Ruoli
I ruoli degli App Token vengono assegnati direttamente nel token stesso. I ruoli indicano ciò che il token è in grado di eseguire. Non vengono calcolati durante l'uso, pertanto la mappatura da ruolo a claim non funziona con gli app token.
Consigliamo inoltre di limitare il numero di ruoli all'interno di un app token. Più ruoli vengono aggiunti al token, maggiore sarà la dimensione del token, con conseguente riduzione delle prestazioni o problemi con alcuni strumenti che non consentono valori di token più lunghi.
È possibile utilizzare ruoli personalizzati con un insieme personalizzato di autorizzazioni per limitare il numero di ruoli, fornendo comunque un accesso personalizzato alla piattaforma PowerShell Universal. Le autorizzazioni vengono valutate quando il ruolo viene utilizzato. Ciò significa che assegnare un ruolo personalizzato a un token lo rende più flessibile rispetto a un ruolo integrato, poiché le autorizzazioni possono essere aggiunte o rimosse da un ruolo senza generare un nuovo token.
Migrazione degli App Token
È possibile migrare gli app token tra sistemi utilizzando la management API. Ciò è utile quando si sviluppa per scenari ad alta disponibilità.
Di seguito è riportato un esempio della POST necessaria per creare un app token esistente in qualsiasi istanza PSU. Si noti che la chiave di firma deve essere la stessa tra le istanze. È necessario un app token valido nel sistema di destinazione per creare i token migrati.
Sicurezza avanzata degli App Token
Quando la sicurezza avanzata degli app token è abilitata, i valori dei token sono accessibili solo al momento della creazione. Vengono sottoposti ad hashing e il database memorizza il valore hash anziché il token. Il token si utilizza allo stesso modo di qualsiasi altro token.
L'abilitazione della sicurezza degli app token invaliderà tutti i token esistenti.
Token di sistema
I token di sistema sono un modo per fornire token a sistemi non utente. Non sono legati direttamente all'identità di un utente. È possibile fornire un nome per il token, oltre alla scadenza e ai ruoli.
Chiavi di firma
Chiave di firma locale
Per impostazione predefinita, PowerShell Universal crea una chiave di firma basata sulla stringa Jwt \ SigningKey in appsettings.json. Questo valore viene utilizzato per codificare e decodificare il token. Se le chiavi di firma non corrispondono, il token sarà considerato non valido. La modifica della chiave di firma invaliderà tutte le chiavi di firma esistenti.
Chiave di firma remota
Potrebbe voler utilizzare un documento di discovery OAuth 2.0 per fornire la convalida della chiave di firma. Utilizzando un sistema remoto di questo tipo, può garantire che, quando le chiavi di firma vengono modificate, non sia necessario modificare la configurazione di PowerShell Universal. Per utilizzare una chiave di firma remota, imposti il valore Jwt \ DiscoveryDocument in appsettings.json sull'URL del documento di metadati OAuth 2.0. Quando PowerShell Universal viene caricato, leggerà le chiavi di firma dal documento e le fornirà al sistema di convalida JWT.
App Token esterni
Quando si configura una chiave di firma remota, i token vengono quindi generati dal provider OAuth 2.0. Per questo motivo, anche le informazioni sui claim vengono generate da tale provider. Per assegnare correttamente ruoli e autorizzazioni all'interno di PowerShell Universal, dovrà assicurarsi che i claim corretti siano definiti all'interno del token. PowerShell Universal valuterà i seguenti valori di claim all'interno di un token.
PSUPermission - Definisce le autorizzazioni del token
Roles - Definisce i ruoli del token.
Per consentire l'accesso alle risorse all'interno di un'istanza di PowerShell Universal, si assicuri che il token contenga i claim corretti. Ad esempio, il token seguente consentirebbe l'accesso completo alle management API di PowerShell Universal perché fornisce il claim PSUPermission con un selettore per tutte le autorizzazioni. Può utilizzare l'esempio riportato di seguito per vedere come ottenere questo risultato in Auth0.
In alternativa, può abilitare la valutazione dei claim per i token JWT. Per impostazione predefinita, PowerShell Universal utilizza un insieme statico di autorizzazioni quando riceve un token. Se abilita la valutazione dei claim per i token JWT, il sistema di autorizzazione elaborerà il token e aggiungerà le autorizzazioni quando il token viene utilizzato anziché quando viene generato.
Valutazione dei claim per i token
Per abilitare la valutazione dei claim per i token, può modificare appsettings.json per indicare a PSU di eseguire la valutazione dei claim durante l'esecuzione della convalida del token.
Questo utilizzerà roles.ps1 per verificare i claim dei token forniti e assegnare le autorizzazioni in base ai ruoli qualificati.
Esempio: token di accesso Auth0 con valutazione dei claim
Utilizzando le funzionalità standard di Auth0, può generare token in grado di fornire ruoli in base ai claim del token. Ciò non richiede trigger o azioni speciali all'interno di Auth0.
Creare un'applicazione Auth0
In Auth0, crei un'applicazione per una regular web application. Può farlo facendo clic su Applications \ Applications e quindi su Create Application.
Creare un'API Auth0
Successivamente, crei un'API Auth0 facendo clic su Applications \ APIs e quindi su Create API. Imposti il nome e il namespace su valori univoci e lasci le altre opzioni sui valori predefiniti.
Creare ambiti di autorizzazione personalizzati nella propria API
All'interno della propria API, definisca autorizzazioni personalizzate, ad esempio una con un nome di ruolo.
Autorizzare l'applicazione a utilizzare l'API
Nelle impostazioni dell'applicazione, faccia clic su APIs e attivi l'interruttore accanto all'API per autorizzare l'applicazione a utilizzare l'API. Selezioni le autorizzazioni che desidera fornire all'applicazione. Queste appariranno come claim di autorizzazione nel token.
Recuperare un token di accesso da Auth0
Con l'applicazione e l'API definite, ora può richiedere un token di accesso in Auth0. I valori client_id e client_secret si trovano nella pagina Application Details. Il valore audience deve essere l'Identifier della sua API.
Configurare PowerShell Universal
Sarà necessario configurare PowerShell Universal per utilizzare Auth0 come provider JWT. Può farlo modificando il file appsettings.json. Questi devono includere i valori di Auth0. Il DiscoveryDocument farà parte del suo tenant e aiuta a definire dati come le chiavi di firma per i token JWT. L'Issuer sarà l'URL del suo tenant. L'Audience sarà l'identifier della sua API.
Configurare un ruolo da mappare all'autorizzazione Auth0
Infine, crei un ruolo che si mappi all'autorizzazione Auth0. L'esempio seguente verifica che il token API abbia un claim permissions con il valore Administrator come configurato sopra. In tal caso, al token viene assegnato il ruolo API Admin, che dispone di tutte le autorizzazioni all'interno della management API di PowerShell Universal.
Utilizzo di un App Token con PowerShell Universal
Ora che dispone di un app token Auth0, può utilizzarlo esattamente come farebbe con gli app token integrati.
Esempio: token di accesso Auth0 con claim personalizzati
È possibile utilizzare le API e le applicazioni Auth0 per fornire app token per PowerShell Universal.
Creare un'applicazione Auth0
In Auth0, crei un'applicazione per una regular web application. Può farlo facendo clic su Applications \ Applications e quindi su Create Application.
Creare un'API Auth0
Successivamente, crei un'API Auth0 facendo clic su Applications \ APIs e quindi su Create API. Imposti il nome e il namespace su valori univoci e lasci le altre opzioni sui valori predefiniti.
Autorizzare l'applicazione a utilizzare l'API
Nelle impostazioni dell'applicazione, faccia clic su APIs e attivi l'interruttore accanto all'API per autorizzare l'applicazione a utilizzare l'API.
Recuperare un token di accesso da Auth0
Con l'applicazione e l'API definite, ora può richiedere un token di accesso in Auth0. I valori client_id e client_secret si trovano nella pagina Application Details. Il valore audience deve essere l'Identifier della sua API.
Configurare PowerShell Universal
Sarà necessario configurare PowerShell Universal per utilizzare Auth0 come provider JWT. Può farlo modificando il file appsettings.json. Questi devono includere i valori di Auth0. Il DiscoveryDocument farà parte del suo tenant e aiuta a definire dati come le chiavi di firma per i token JWT. L'Issuer sarà l'URL del suo tenant. L'Audience sarà l'identifier della sua API.
Utilizzo di un App Token con PowerShell Universal
Ora che dispone di un app token Auth0, può utilizzarlo esattamente come farebbe con gli app token integrati.
Facoltativo: definire un trigger di azione Auth0
Quando si concede un nuovo token di accesso da Auth0, questo non conterrà i ruoli o le autorizzazioni standard come gli app token integrati in PowerShell Universal. È possibile controllare questo aspetto definendo una Custom Action e assegnandola al trigger credential-exchange.
Faccia clic su Actions, quindi su Library e Create Action e infine su Create Custom Action. Selezioni il trigger Password Reset / Post Challenge e assegni un nome all'azione.
Definisca l'azione impostando un claim personalizzato per il tipo di claim PSUPermission. Questo esempio fornisce semplicemente l'accesso completo alle API di PowerShell Universal. Può utilizzare il contesto dell'evento per definire quali autorizzazioni vengono ricevute in base alla richiesta del token di accesso.
Successivamente, aggiunga l'azione al trigger del flusso di lavoro per credential-exchange facendo clic su Actions, quindi su Triggers e infine su credential-exchange.
Trascini l'azione Set Permissions nel flusso di lavoro.
Una volta completata questa operazione, è possibile generare un nuovo token e accedere a qualsiasi API all'interno di PowerShell Universal.
Vedere anche
Ultimo aggiornamento
È stato utile?