Funzionamento del provisioning di applicazioni in Azure Active Directory

Il provisioning automatico si riferisce alla creazione di identità e ruoli utente nelle applicazioni cloud a cui gli utenti devono accedere. Oltre a creare le identità utente, il provisioning automatico include la manutenzione e la rimozione delle identità utente quando lo stato o i ruoli cambiano. Prima di iniziare una distribuzione, è possibile leggere questo articolo per informazioni sul funzionamento del provisioning di Azure AD e per ottenere consigli sulla configurazione.

Il servizio di provisioning di Azure AD effettua il provisioning degli utenti nelle app SaaS e in altri sistemi connettendosi a un endpoint dell'API di gestione utenti SCIM (System for Cross-Domain Identity Management) 2.0 dai fornitori di ogni applicazione. Questo endpoint SCIM consente ad Azure AD di creare, aggiornare e rimuovere gli utenti a livello programmatico. Per alcune applicazioni, il servizio di provisioning può anche creare, aggiornare e rimuovere oggetti aggiuntivi relative alle identità, ad esempio i gruppi e i ruoli. Il canale usato per il provisioning tra Azure AD e l'applicazione viene crittografato con crittografia HTTPS TLS 1.2.

Azure AD Provisioning ServiceFigura 1: Servizio di provisioning di Azure AD

Flusso di lavoro di provisioning utenti inuscita Figura 2: flusso di lavoro di provisioning utenti in uscita da Azure AD alle applicazioni SaaS più diffuse

Flusso di lavoro di provisioning utenti in ingressoFigura 3: flusso di lavoro di provisioning utenti "in ingresso" da applicazioni di Human Capital Management (HCM) comuni ad Azure Active Directory e Windows Server Active Directory

Provisioning con SCIM 2.0

Il servizio di provisioning di Azure AD usa il protocollo SCIM 2.0 per il provisioning automatico. Il servizio si connette all'endpoint SCIM per l'applicazione e usa lo schema dell'oggetto utente SCIM e le API REST per automatizzare il provisioning e il deprovisioning di utenti e gruppi. Per la maggior parte delle applicazioni nella raccolta di Azure AD viene fornito un connettore di provisioning basato su SCIM. Quando si compilano app per Azure AD, gli sviluppatori possono usare l'API di gestione utenti SCIM 2.0 per compilare un endpoint SCIM che integri Azure AD per il provisioning. Per informazioni dettagliate, vedere Creare un endpoint SCIM e configurare il provisioning utenti.

Per richiedere un connettore di provisioning automatico di Azure AD per un'app che non ne ha attualmente una, vedere Richiesta di applicazione di Azure Active Directory.

Autorizzazione

Le credenziali sono necessarie ad Azure AD per la connessione all'API di gestione degli utenti dell'applicazione. Durante la configurazione del provisioning utenti automatico per un'applicazione, è necessario immettere credenziali valide. Per le applicazioni della raccolta, è possibile trovare i tipi di credenziali e i requisiti per l'applicazione facendo riferimento all'esercitazione sull'app. Per le applicazioni non della raccolta, è possibile fare riferimento alla documentazione SCIM per comprendere i tipi e i requisiti delle credenziali. Nel portale di Azure sarà possibile testare le credenziali mediante un tentativo di connessione di Azure AD all'app di provisioning dell'app con le credenziali fornite.

Attributi di mapping

Quando si abilita il provisioning degli utenti per un'applicazione SaaS di terze parti, il portale di Azure ne controlla i valori degli attributi usando il mapping degli attributi. I mapping determinano gli attributi utente trasmessi tra Azure AD e l'applicazione di destinazione durante il provisioning o l'aggiornamento degli account utente.

Esiste un set preconfigurato di attributi e mapping degli attributi tra gli oggetti utente di Azure AD e gli oggetti utente di ogni app SaaS. Alcune app gestiscono altri tipi di oggetti insieme a utenti e gruppi.

Un aspetto importante da considerare quando si configura il provisioning è quello di esaminare e configurare il mapping degli attributi e i flussi di lavoro che definiscono il tipo di flusso di proprietà utente (o gruppo) da Azure AD all'applicazione. Rivedere e configurare la proprietà corrispondente (Abbina gli oggetti in base a questo attributo) che viene usata per identificare e abbinare in modo univoco utenti/gruppi tra i due sistemi.

È possibile personalizzare i mapping degli attributi predefiniti in base alle esigenze aziendali. Quindi è possibile modificare o eliminare i mapping degli attributi esistenti oppure crearne di nuovi. Per i dettagli, vedere Personalizzazione dei mapping degli attributi del provisioning utenti per le applicazioni SaaS.

Quando si configura il provisioning in un'applicazione SaaS, come mapping degli attributi è possibile specificare il mapping di espressioni. Per questo tipo di mapping è necessario scrivere un'espressione analoga a uno script, che permette di trasformare i dati utente in formati più idonei all'applicazione SaaS. Per i dettagli, vedere Scrittura di espressioni per i mapping degli attributi.

Scoping

Ambito basato sull'assegnazione

Per il provisioning in uscita da Azure AD a un'applicazione SaaS, basarsi sulle assegnazioni di utenti o gruppi è il modo più comune per determinare quali utenti sono inclusi nell'ambito del provisioning. Poiché le assegnazioni utente vengono usate anche per l'abilitazione di Single Sign-On, è possibile usare lo stesso metodo per gestire l'accesso e il provisioning. L'ambito basato sull'assegnazione non si applica agli scenari di provisioning in ingresso, ad esempio giorni lavorativi e Successfactor.

  • Gruppi. Con un piano di licenza Azure AD Premium è possibile usare gruppi per assegnare l'accesso a un'applicazione SaaS. Quindi, quando l'ambito del provisioning è impostato su Sincronizza solo gli utenti e i gruppi assegnati, il servizio di provisioning di Azure AD effettuerà il provisioning o il deprovisioning degli utenti a prescindere che siano membri o meno di un gruppo assegnato all'applicazione. Non viene effettuato il provisioning dell'oggetto gruppo, a meno che l'applicazione non supporti gli oggetti gruppo. Assicurarsi che i gruppi assegnati all'applicazione dispongano della proprietà "SecurityEnabled" impostata su "True".

  • Gruppi dinamici. Il servizio di provisioning utenti Azure AD è in grado di leggere ed effettuare il provisioning degli utenti in gruppi dinamici. Tenere presenti questi consigli e avvertenze:

    • L'utilizzo di gruppi dinamici può compromettere le prestazioni del provisioning end-to-end da Azure AD alle applicazioni SaaS.

    • La velocità di provisioning o deprovisioning di un utente di un gruppo dinamico in un'applicazione SaaS dipende dalla velocità con cui il gruppo dinamico riesce a valutare le modifiche all'appartenenza. Per informazioni su come controllare lo stato di elaborazione di un gruppo dinamico, vedere Controllare lo stato di elaborazione per una regola di appartenenza.

    • Quando un utente perde l'appartenenza al gruppo dinamico, viene considerato come un evento di deprovisioning. Si consideri questo scenario quando si creano regole per i gruppi dinamici.

  • Gruppi annidati. Il servizio di provisioning utenti Azure AD non è in grado di leggere o di effettuare il provisioning degli utenti in gruppi annidati. Può effettuare la lettura e il provisioning solo degli utenti che sono membri immediati del gruppo assegnato in modo esplicito. Si tratta di una limitazione delle "assegnazioni basate su gruppi alle applicazioni", che ha effetto anche su Single Sign-On e viene descritta in Uso di un gruppo per gestire l'accesso ad applicazioni SaaS. Come soluzione alternativa è consigliabile assegnare in modo esplicito o definire l'ambito nei gruppi contenenti gli utenti di cui è necessario effettuare il provisioning.

Ambito basato sugli attributi

È possibile usare i filtri di ambito per definire regole basate su attributi per determinare gli utenti per i quali viene eseguito il provisioning per un'applicazione. Questo metodo viene usato comunemente per il provisioning in ingresso dalle applicazioni di Gestione connessione ibrida ad Azure AD e Active Directory. I filtri di ambito sono configurati come parte dei mapping degli attributi per ogni connettore di provisioning dell'utente di Azure AD. Per informazioni dettagliate sulla configurazione dei filtri di ambito basati su attributi, vedere Provisioning dell'applicazione basato su attributi con filtri per la definizione dell'ambito.

Utenti B2B (guest)

È possibile usare il servizio di provisioning utenti di Azure AD per effettuare il provisioning degli utenti B2B (guest) in Azure AD in applicazioni SaaS. Tuttavia, perché gli utenti B2B possano accedere all'applicazione SaaS con Azure AD, la funzionalità Single Sign-On basata su SAML dell'applicazione SaaS deve essere configurata in modo specifico. Per altre informazioni su come configurare le applicazioni SaaS per supportare gli accessi dagli utenti B2B, vedere Configurare app SaaS per Collaborazione B2B.

Nota

UserPrincipalName per un utente B2B rappresenta l'indirizzo di posta elettronica dell'utente esterno alias@theirdomain come "alias_theirdomain#EXT#@yourdomain". Quando l'attributo userPrincipalName viene incluso nei mapping degli attributi come attributo di origine e viene effettuato il provisioning di un utente B2B, #EXT# e il dominio viene rimosso dall'attributo userPrincipalName, quindi viene usato solo il relativo alias@theirdomain originale per la corrispondenza o il provisioning. Se è necessario che sia presente il nome completo dell'entità utente, incluso #EXT# e il dominio, sostituire userPrincipalName con originalUserPrincipalName come attributo di origine.
userPrincipalName = alias@theirdomain
originalUserPrincipalName = alias_theirdomain#EXT#@yourdomain

Cicli di provisioning: Iniziale e incrementale

Quando Azure AD è il sistema di origine, il servizio di provisioning usa la funzionalità di query delta per tracciare le modifiche nei dati di Microsoft Graph per monitorare gli utenti e i gruppi. Il servizio di provisioning esegue un ciclo iniziale rispetto al sistema di origine e a quello di destinazione, seguita da cicli incrementali periodici.

Ciclo iniziale

Quando viene avviato il servizio di provisioning, il primo ciclo consiste nelle operazioni seguenti:

  1. Il servizio esegue una query su tutti gli utenti e i gruppi presenti nel sistema di origine e recupera tutti gli attributi definiti nei mapping degli attributi.

  2. Il servizio filtra gli utenti e i gruppi restituiti, usando assegnazioni configurate o filtri di ambito basati su attributi.

  3. Quando un utente viene assegnato o incluso nell'ambito per il provisioning, il servizio esegue una query sul sistema di destinazione per individuare un utente corrispondente usando gli attributi di corrispondenza specificati. Esempio: Se il nome userPrincipal nel sistema di origine è un attributo di corrispondenza ed è mappato a userName nel sistema di destinazione, il servizio di provisioning esegue una query sul sistema di destinazione per trovare i valori di userName che corrispondono ai valori del nome userPrincipal nel sistema di origine.

  4. Se nel sistema di destinazione non viene trovato un utente corrispondente, questo viene creato usando gli attributi restituiti dal sistema di origine. Dopo aver creato l'account utente, il servizio di provisioning rileva e memorizza nella cache l'ID del sistema di destinazione per il nuovo utente. Questo ID viene usato per eseguire tutte le operazioni future su tale utente.

  5. Se invece viene trovato un utente corrispondente, questo viene aggiornato usando gli attributi forniti dal sistema di origine. Dopo aver abbinato l'account utente, il servizio di provisioning rileva e memorizza nella cache l'ID del sistema di destinazione per il nuovo utente. Questo ID viene usato per eseguire tutte le operazioni future su tale utente.

  6. Se i mapping degli attributi contengono attributi "di riferimento", il servizio esegue altri aggiornamenti nel sistema di destinazione per creare e collegare gli oggetti a cui viene fatto riferimento. È ad esempio possibile che nel sistema di destinazione un utente abbia un attributo "Manager" collegato a un altro utente creato nel sistema di destinazione.

  7. Al termine del ciclo iniziale, il servizio salva in modo permanente una filigrana che fornisce il punto di partenza per i successivi cicli incrementali.

Alcune applicazioni come ServiceNow, G Suite e Box supportano non solo il provisioning degli utenti ma anche quello dei gruppi e dei relativi membri. In questi casi, se nei mapping è abilitato il provisioning di gruppi, il servizio di provisioning sincronizza sia gli utenti che i gruppi e successivamente anche le appartenenze ai gruppi.

Cicli incrementali

Dopo il ciclo iniziale, tutti gli altri cicli consisteranno in quanto segue:

  1. Il servizio esegue una query sul sistema di origine per trovare gli utenti e i gruppi che sono stati aggiornati dopo il salvataggio dell'ultima filigrana.

  2. Il servizio filtra gli utenti e i gruppi restituiti, usando assegnazioni configurate o filtri di ambito basati su attributi.

  3. Quando un utente viene assegnato o incluso nell'ambito per il provisioning, il servizio esegue una query sul sistema di destinazione per individuare un utente corrispondente usando gli attributi di corrispondenza specificati.

  4. Se nel sistema di destinazione non viene trovato un utente corrispondente, questo viene creato usando gli attributi restituiti dal sistema di origine. Dopo aver creato l'account utente, il servizio di provisioning rileva e memorizza nella cache l'ID del sistema di destinazione per il nuovo utente. Questo ID viene usato per eseguire tutte le operazioni future su tale utente.

  5. Se invece viene trovato un utente corrispondente, questo viene aggiornato usando gli attributi forniti dal sistema di origine. Se si tratta di un account appena assegnato e abbinato, il servizio di provisioning rileva e memorizza nella cache l'ID del sistema di destinazione per il nuovo utente. Questo ID viene usato per eseguire tutte le operazioni future su tale utente.

  6. Se i mapping degli attributi contengono attributi "di riferimento", il servizio esegue altri aggiornamenti nel sistema di destinazione per creare e collegare gli oggetti a cui viene fatto riferimento. È ad esempio possibile che nel sistema di destinazione un utente abbia un attributo "Manager" collegato a un altro utente creato nel sistema di destinazione.

  7. Se un utente precedentemente incluso nell'ambito per il provisioning viene rimosso dall'ambito e la relativa assegnazione viene annullata, il servizio disabilita l'utente nel sistema di destinazione eseguendo un aggiornamento.

  8. Se un utente precedentemente incluso nell'ambito per il provisioning viene disabilitato o eliminato temporaneamente nel sistema di origine, il servizio disabilita l'utente nel sistema di destinazione eseguendo un aggiornamento.

  9. Se un utente precedentemente incluso nell'ambito per il provisioning viene eliminato definitivamente nel sistema di origine, il servizio elimina l'utente nel sistema di destinazione. In Azure AD gli utenti vengono eliminati definitivamente dopo che sono trascorsi 30 giorni dall'eliminazione temporanea.

  10. Al termine del ciclo incrementale, il servizio salva in modo permanente una nuova filigrana che fornisce il punto di partenza per i successivi cicli incrementali.

Nota

È possibile disabilitare le operazioni di creazione, aggiornamento o eliminazione usando le caselle di controllo Azioni oggetto di destinazione nella sezione Mapping. La logica per disabilitare un utente durante un aggiornamento viene controllata anche tramite un mapping di attributi da un campo come "accountEnabled".

Il servizio di provisioning continuerà a eseguire cicli incrementali back-to-back all'infinito, in base agli intervalli definiti nell'esercitazione specifica di ogni applicazione. I cicli incrementali continueranno fino al verificarsi di uno degli eventi seguenti:

  • Il servizio viene arrestato manualmente tramite il portale di Azure o con il comando appropriato dell'API Microsoft Graph.
  • Viene attivato un nuovo ciclo iniziale usando l'opzione Riavvia provisioning nella portale di Azure o usando il comando Microsoft API Graph appropriato. Per effetto di questa operazione, le eventuali filigrane salvate vengono cancellate e tutti gli oggetti di origine vengono nuovamente valutati.
  • Viene attivato un nuovo ciclo iniziale a causa di una modifica nel mapping degli attributi o nei filtri di ambito. Per effetto di questa operazione, anche le eventuali filigrane salvate vengono cancellate e tutti gli oggetti di origine vengono nuovamente valutati.
  • Il processo di provisioning entra in quarantena (vedere sotto) a causa di errori molto frequenti e resta in quarantena per più di quattro settimane. In questo caso, il servizio viene disabilitato automaticamente.

Errori e ripetizione di tentativi

Se non è possibile aggiungere, aggiornare o eliminare un singolo utente nel sistema di destinazione a causa di un errore in tale sistema, il tentativo di eseguire questa operazione viene ripetuto nel ciclo di sincronizzazione successivo. Gli errori vengono continuamente riprovati, ridimensionando gradualmente la frequenza dei tentativi. Per risolvere l'errore, gli amministratori devono verificare i log di provisioning per determinare la causa radice del problema e intraprendere l'azione appropriata. Tra gli errori comuni possono essere inclusi i seguenti:

  • Per gli utenti nel sistema di origine non è definito un valore di attributo che è necessario nel sistema di destinazione.
  • Per gli utenti nel sistema di origine è definito un valore di attributo per cui è impostato un vincolo univoco nel sistema di destinazione e lo stesso valore è presente in un altro record utente

Questi errori possono essere risolti modificando i valori di attributo per l'utente interessato nel sistema di origine o modificando i mapping degli attributi in modo da non causare conflitti.

Quarantena

Se la maggior parte o tutte le chiamate al sistema di destinazione non riuscono a causa di un errore (ad esempio nel caso di credenziali di amministratore non valide), il processo di provisioning passa allo stato di "quarantena". Questo stato viene indicato nel report di riepilogo sul provisioning e tramite posta elettronica, se nel portale di Azure sono state configurate le notifiche di posta elettronica.

In stato di quarantena, la frequenza dei cicli incrementali viene gradualmente ridotta fino a diventare giornaliera.

Dopo che tutti gli errori sono stati risolti, il processo di provisioning esce dalla quarantena e viene avviato il ciclo di sincronizzazione successivo. Se lo stato di quarantena dura per più di quattro settimane, il processo di provisioning viene disabilitato. Per altre informazioni sugli stati di quarantena, vedere qui.

Tempo richiesto per il provisioning

Le prestazioni variano a seconda che il processo di provisioning esegua un ciclo di provisioning iniziale o incrementale. Per informazioni dettagliate sul tempo necessario per il provisioning e su come monitorare lo stato del servizio di provisioning, vedere Controllare lo stato del provisioning dell'utente.

Come stabilire se il provisioning utenti viene eseguito correttamente

Tutte le operazioni eseguite dal servizio di provisioning utenti vengono registrate nei Log di provisioning (anteprima) di Azure AD. Nei log sono incluse tutte le operazioni di lettura e scrittura eseguite nei sistemi di origine e di destinazione, oltre ai dati degli utenti che sono stati letti o scritti durante ogni operazione. Per informazioni su come leggere i log di provisioning nel portale di Azure, vedere la guida alla creazione di report sul provisioning.

Deprovisioning

Il servizio di provisioning di Azure AD mantiene i sistemi di origine e di destinazione sincronizzati con account di de-provisioning quando l'accesso utente viene rimosso.

Il servizio di provisioning supporta sia l'eliminazione che la disabilitazione (talvolta denominata eliminazione temporanea) degli utenti. La definizione esatta di disabilitazione ed eliminazione varia in base all'implementazione dell'app di destinazione, ma in genere una disabilitazione indica che l'utente non può accedere. Un'eliminazione indica che l'utente è stato rimosso completamente dall'applicazione. Per le applicazioni SCIM, una disabilitazione è una richiesta per impostare la proprietà attiva su false su un utente.

Configurare l'applicazione per disabilitare un utente

Assicurarsi di aver selezionato la casella di controllo per gli aggiornamenti.

Assicurarsi di disporre del mapping per l'applicazione attiva . Se si usa un'applicazione dalla raccolta di app, il mapping potrebbe essere leggermente diverso. Assicurarsi di usare il mapping predefinito/out della casella per le applicazioni della raccolta.

Disabilitare un utente

Configurare l'applicazione per eliminare un utente

Gli scenari seguenti attivano una disabilitazione o un'eliminazione:

  • Un utente viene eliminato in modo soft in Azure AD (inviato al cestino/Proprietà AccountEnabled impostato su false). 30 giorni dopo l'eliminazione in Azure AD, l'utente verrà eliminato definitivamente dal tenant. A questo punto, il servizio di provisioning invierà una richiesta DELETE per eliminare definitivamente l'utente nell'applicazione. In qualsiasi momento durante la finestra di 30 giorni, è possibile eliminare manualmente un utente in modo permanente, operazione che invia una richiesta di eliminazione all'applicazione.
  • Un utente viene eliminato/rimosso definitivamente dal cestino in Azure AD.
  • Un utente non viene assegnato da un'app.
  • Un utente passa dall'ambito all'esterno dell'ambito (non passa più un filtro di ambito).

Eliminare un utente

Per impostazione predefinita, il servizio di provisioning di Azure AD elimina temporaneamente o disabilita gli utenti che non rientrano nell'ambito. Se si vuole eseguire l'override di questo comportamento predefinito, è possibile impostare un flag per ignorare le eliminazioni dall'ambito.

Se si verifica uno dei quattro eventi precedenti e l'applicazione di destinazione non supporta le eliminazioni software, il servizio di provisioning invierà una richiesta DELETE per eliminare definitivamente l'utente dall'app.

Se viene visualizzato un attributo IsSoftDeleted nei mapping degli attributi, esso viene usato per determinare lo stato dell'utente e se inviare una richiesta di aggiornamento con active = false per eliminarlo temporaneamente.

Eventi di deprovisioning

La tabella seguente descrive come configurare le azioni di deprovisioning con il servizio di provisioning di Azure AD. Queste regole vengono scritte con l'applicazione non raccolta/personalizzata in mente, ma in genere si applicano alle applicazioni nella raccolta. Tuttavia, il comportamento per le applicazioni della raccolta può variare in quanto sono stati ottimizzati per soddisfare le esigenze dell'applicazione. Ad esempio, il servizio di provisioning di Azure AD può inviare sempre una richiesta agli utenti di eliminazione temporanea in determinate applicazioni anziché l'eliminazione temporanea, se l'applicazione di destinazione non supporta l'eliminazione temporanea degli utenti.

Scenario Come configurare in Azure AD
Se un utente non viene assegnato da un'app, eliminato in modo leggero in Azure AD o bloccato dall'accesso, non eseguire alcuna operazione. Rimuovere isSoftDeleted dai mapping degli attributi e/o impostare la proprietà ignora l'eliminazione dell'ambito su true.
Se un utente non viene assegnato da un'app, eliminato in modo leggero in Azure AD o bloccato dall'accesso, impostare un attributo specifico su true/false. Map isSoftDeleted all'attributo che si desidera impostare su false.
Quando un utente è disabilitato in Azure AD, non assegnato da un'app, eliminato in modo leggero in Azure AD o bloccato dall'accesso, inviare una richiesta DELETE all'applicazione di destinazione. Attualmente è supportato per un set limitato di applicazioni di raccolta in cui è necessaria la funzionalità. Non è configurabile dai clienti.
Quando un utente viene eliminato in Azure AD, non eseguire alcuna operazione nell'applicazione di destinazione. Assicurarsi che "Delete" non sia selezionato come una delle azioni dell'oggetto di destinazione nell'esperienza di configurazione attriubte.
Quando un utente viene eliminato in Azure AD, impostare il valore di un attributo nell'applicazione di destinazione. Non supportata.
Quando un utente viene eliminato in Azure AD, eliminare l'utente nell'applicazione di destinazione Questa configurazione è supportata. Assicurarsi che Delete sia selezionato come una delle azioni dell'oggetto di destinazione nell'esperienza di configurazione dell'attributo.

Limitazioni note

  • Se un utente gestito in precedenza dal servizio di provisioning non viene assegnato da un'app o da un gruppo assegnato a un'app verrà inviata una richiesta di disabilitazione. A questo punto, l'utente non è gestito dal servizio e non verrà inviata una richiesta di eliminazione quando vengono eliminati dalla directory.
  • Il provisioning di un utente disabilitato in Azure AD non è supportato. Devono essere attivi in Azure AD prima del provisioning.
  • Quando un utente passa dall'eliminazione temporanea all'attivo, il servizio di provisioning di Azure AD attiverà l'utente nell'app di destinazione, ma non ripristina automaticamente le appartenenze ai gruppi. L'applicazione di destinazione deve mantenere le appartenenze ai gruppi per l'utente inattivo. Se l'applicazione di destinazione non supporta questa operazione, è possibile riavviare il provisioning per aggiornare le appartenenze ai gruppi.

Consiglio

Quando si sviluppa un'applicazione, supporta sempre le eliminazioni temporanea e le eliminazioni hard. Consente ai clienti di ripristinare quando un utente è accidentalmente disabilitato.

Passaggi successivi

Pianificare una distribuzione automatica del provisioning utenti

Configurare il provisioning per un'app della raccolta

Creare un endpoint SCIM e configurare il provisioning durante la creazione dell'app

Risolvere i problemi di configurazione e provisioning degli utenti in un'applicazione.