Scenario - Uso di Microsoft Entra ID per proteggere l'accesso alle piattaforme e alle applicazioni SAP

Questo documento fornisce consigli sulla progettazione tecnica e sulla configurazione delle piattaforme e delle applicazioni SAP quando si usa Microsoft Entra ID come servizio di autenticazione utente principale per SAP Cloud Identity Services. SAP Cloud Identity Services include l'autenticazione delle identità, il provisioning delle identità, la directory delle identità e la gestione delle autorizzazioni. Altre informazioni sulla configurazione iniziale per l'autenticazione nell'esercitazione sull'integrazione dell'accesso Single Sign-On (SSO) di Microsoft Entra con SAP Cloud Identity Services. Per altre informazioni sul provisioning e altri scenari, vedere Pianificare la distribuzione di Microsoft Entra per il provisioning utenti con applicazioni di origine e di destinazione SAP e gestire l'accesso alle applicazioni SAP.

Terminologia utilizzata in questa guida

Panoramica

Esistono molti servizi e componenti nello stack di tecnologie SAP e Microsoft che svolgono un ruolo negli scenari di autenticazione e autorizzazione degli utenti. I servizi principali sono elencati nel diagramma seguente.

Poiché esistono molte permutazioni di possibili scenari da configurare, ci concentriamo su uno scenario in linea con una strategia di microsoft Entra identity first. Si effettueranno i presupposti seguenti:

• Si vuole gestire tutte le identità in modo centralizzato e solo da Microsoft Entra ID.
• Si vogliono ridurre il più possibile le attività di manutenzione e automatizzare l'autenticazione e l'accesso alle app in Microsoft e SAP.
• Le linee guida generali per Microsoft Entra ID con IAS si applicano alle app distribuite in app BTP e SAP SaaS configurate in IAS. Verranno inoltre fornite raccomandazioni specifiche, se applicabili a BTP (ad esempio, usando i mapping dei ruoli con i gruppi di Microsoft Entra) e le app SaaS SAP (ad esempio, usando il servizio di provisioning delle identità per l'autorizzazione basata sui ruoli).
• Si presuppone anche che gli utenti siano già stati sottoposto a provisioning in Microsoft Entra ID e a tutti i sistemi SAP che richiedono il provisioning degli utenti per il funzionamento. Indipendentemente dal modo in cui è stato raggiunto: il provisioning potrebbe essere stato eseguito manualmente, da Active Directory locale tramite Microsoft Entra Connect o tramite sistemi HR come SAP SuccessFactors. In questo documento, pertanto, SuccessFactors viene considerato un'applicazione come qualsiasi altro utente (esistente) che accederà. Non viene illustrato il provisioning effettivo degli utenti da SuccessFactors in Microsoft Entra ID. Per altre informazioni sull'inserimento degli utenti in Microsoft Entra ID per l'uso con carichi di lavoro SAP, vedere Pianificare la distribuzione di Microsoft Entra per il provisioning utenti con applicazioni di origine e destinazione SAP e gestire l'accesso alle applicazioni SAP.

In base a questi presupposti, ci concentriamo principalmente sui prodotti e sui servizi presentati nel diagramma seguente. Questi sono i vari componenti più rilevanti per l'autenticazione e l'autorizzazione in un ambiente basato sul cloud.

Se si usa SAP Identity Management (IDM), è possibile eseguire la migrazione degli scenari di gestione delle identità da SAP IDM a Microsoft Entra. Per altre informazioni, vedere Eseguire la migrazione degli scenari di gestione delle identità da SAP IDM a Microsoft Entra.

Consigli

Riepilogo

• 1 - Usare l'autenticazione federata in SAP Business Technology Platform e applicazioni SAP SaaS tramite il servizio SAP Identity Authentication
• 2 - Usare Microsoft Entra ID per l'autenticazione e IAS/BTP per l'autorizzazione
• 3 - Usare i gruppi di Microsoft Entra per l'autorizzazione tramite raccolte ruoli in IAS/BTP
• 4 - Usare un singolo account secondario BTP solo per le applicazioni con requisiti di identità simili
• 5 - Usare il tenant IAS di produzione per tutte le autorizzazioni e l'autenticazione dell'utente finale
• 6 - Definire un processo per il rollover dei certificati di firma SAML

1 - Usare l'autenticazione federata in SAP Business Technology Platform e applicazioni SAP SaaS tramite il servizio SAP Identity Authentication

Contesto

Le applicazioni in BTP possono usare provider di identità tramite configurazioni di attendibilità per autenticare gli utenti usando il protocollo SAML 2.0 tra BTP/XSUAA e il provider di identità. Si noti che è supportato solo SAML 2.0, anche se il protocollo OpenID Connect viene usato tra l'applicazione stessa e BTP/XSUAA (non rilevante in questo contesto).

In BTP è possibile scegliere di configurare una configurazione di trust per SAP Cloud Identity Services - Identity Authentication (impostazione predefinita), ma quando la directory utente autorevole è Microsoft Entra ID, è possibile configurare la federazione in modo che gli utenti possano accedere con gli account Microsoft Entra esistenti.

Oltre alla federazione, è anche possibile configurare il provisioning utenti in modo che gli utenti di Microsoft Entra vengano sottoposte a provisioning in anticipo in BTP. Tuttavia, non esiste alcun supporto nativo per questo (solo per Microsoft Entra ID -> SAP Identity Authentication Service). Una soluzione integrata con supporto nativo è il servizio BTP Identity Provisioning. Il provisioning degli account utente in anticipo può essere utile per scopi di autorizzazione, ad esempio per aggiungere utenti ai ruoli. A seconda dei requisiti, tuttavia, è anche possibile ottenere questo risultato con i gruppi di Entra di Microsoft (vedere di seguito), il che potrebbe significare che non è necessario eseguire il provisioning degli utenti.

Quando si configura la relazione di federazione, sono disponibili più opzioni:

• È possibile scegliere di eseguire la federazione verso Microsoft Entra ID direttamente da BTP/XSUAA.
• È possibile scegliere di eseguire la federazione con IAS che a sua volta è configurata per la federazione con Microsoft Entra ID come provider di identità aziendale (noto anche come "PROXY SAML").

Per le applicazioni SAAS SAP IAS viene effettuato il provisioning e preconfigurato per semplificare l'onboarding degli utenti finali. Ad esempio SuccessFactors, Marketing Cloud, Cloud for Customer, Sales Cloud e altri. Questo scenario è meno complesso, perché IAS è direttamente connesso con l'app di destinazione e non viene inoltrato tramite proxy a XSUAA. In ogni caso, le stesse regole si applicano per questa configurazione come per Microsoft Entra ID con IAS in generale.

Che cosa è consigliabile?

Quando la directory utente autorevole è Microsoft Entra ID, è consigliabile configurare una configurazione di attendibilità in BTP verso IAS. IAS a sua volta è configurato per la federazione con Microsoft Entra ID come provider di identità aziendale.

Nella configurazione di attendibilità in BTP è consigliabile abilitare l'opzione "Crea utenti shadow durante l'accesso". In questo modo, gli utenti che non sono ancora stati creati in BTP ottengono automaticamente un account quando accedono tramite IAS/Microsoft Entra ID per la prima volta. Se questa impostazione viene disabilitata, solo gli utenti con provisioning preliminare potranno accedere.

Perché questa raccomandazione?

Quando si usa la federazione, è possibile scegliere di definire la configurazione di trust a livello di account secondario BTP. In tal caso, è necessario ripetere la configurazione per l'altro sottoaccount in uso. Usando IAS come configurazione di attendibilità intermedia, è possibile sfruttare la configurazione centralizzata in più account secondari ed è possibile usare funzionalità IAS come l'autenticazione basata sul rischio e l'arricchimento centralizzato degli attributi di asserzione. Per proteggere l'esperienza utente, queste funzionalità di sicurezza avanzate devono essere applicate solo in un'unica posizione. Potrebbe trattarsi di IAS o quando si mantiene Microsoft Entra ID come singolo archivio utente autorevole (come è la premessa di questo documento), questo sarebbe gestito centralmente da Microsoft Entra Conditional Access Management.

Nota: per IAS, ogni account secondario viene considerato come "applicazione", anche se all'interno di tale account secondario è possibile distribuire una o più applicazioni. All'interno di IAS, ogni applicazione può essere configurata per la federazione con lo stesso provider di identità aziendale (in questo caso l'ID Microsoft Entra).

Riepilogo dell'implementazione

In Microsoft Entra ID:

• Facoltativamente , configurare Microsoft Entra ID per l'accesso Single Sign-On facile (Seamless SSO), che consente agli utenti di accedere automaticamente quando si trovano nei dispositivi aziendali connessi alla rete aziendale. Quando è abilitato, gli utenti non hanno bisogno di digitare le password per accedere a Microsoft Entra ID e, di solito non devono digitare nemmeno i nomi utente.

In Microsoft Entra ID e IAS:

• Seguire la documentazione per connettere Microsoft Entra ID a IAS in modalità federativa (proxy) (documentazione SAP, Microsoft doc). Prestare attenzione all'impostazione nella NameID configurazione SSO in Microsoft Entra ID, perché gli UPN non sono necessariamente indirizzi di posta elettronica.
• Configurare "Applicazione in bundle" per l'uso dell'ID Microsoft Entra passando alla pagina "Autenticazione condizionale" e impostando "Default Authenticating Identity Provider" sul provider di identità aziendale che rappresenta la directory Microsoft Entra.

In BTP:

• Configurare una configurazione di attendibilità verso IAS (documentazione SAP) e assicurarsi che sia abilitato "Available for User Logon" (Disponibile per l'accesso utente) e "Create Shadow Users During Logon" (Crea utenti shadow durante l'accesso).
• Facoltativamente, disabilitare "Available for User Logon" (Disponibile per l'accesso utente) nella configurazione di attendibilità predefinita "SERVIZIO ID SAP", in modo che gli utenti eseguano sempre l'autenticazione tramite Microsoft Entra ID e non vengano visualizzati una schermata per scegliere il provider di identità.

2 - Usare Microsoft Entra ID per l'autenticazione e IAS/BTP per l'autorizzazione

Contesto

Quando BTP e IAS sono stati configurati per l'autenticazione utente tramite federazione verso Microsoft Entra ID, sono disponibili più opzioni per la configurazione dell'autorizzazione:

• In Microsoft Entra ID è possibile assegnare utenti e gruppi di Microsoft Entra all'applicazione Enterprise che rappresenta l'istanza DI SAP IAS in Microsoft Entra ID.
• In IAS è possibile usare l'autenticazione basata sul rischio per consentire o bloccare gli accessi e impedendo così l'accesso all'applicazione in BTP.
• In BTP è possibile usare raccolte ruoli per definire quali utenti e gruppi possono accedere all'applicazione e ottenere determinati ruoli.

Che cosa è consigliabile?

È consigliabile non inserire alcuna autorizzazione direttamente in Microsoft Entra e disattivare in modo esplicito "Assegnazione utente richiesta" nell'applicazione Enterprise in Microsoft Entra ID. Si noti che per le applicazioni SAML questa impostazione è abilitata per impostazione predefinita, pertanto è necessario eseguire un'azione esplicita per disabilitarla.

Perché questa raccomandazione?

Quando l'applicazione viene federata tramite IAS, dal punto di vista dell'ID Microsoft Entra, l'utente è essenzialmente "autenticato a IAS" durante il flusso di accesso. Ciò significa che Microsoft Entra ID non ha informazioni sull'applicazione BTP finale a cui l'utente sta tentando di accedere. Ciò implica anche che l'autorizzazione in Microsoft Entra ID può essere usata solo per eseguire un'autorizzazione con granularità molto grossolana, ad esempio consentendo all'utente di accedere a qualsiasi applicazione in BTP o a nessuno. Ciò sottolinea anche la strategia di SAP per isolare le app e i meccanismi di autenticazione a livello di account secondario BTP.

Anche se questo potrebbe essere un motivo valido per l'uso di "Assegnazione utente richiesta", significa che ora ci sono potenzialmente due posizioni diverse in cui le informazioni di autorizzazione devono essere mantenute: entrambe in Microsoft Entra ID nell'applicazione Enterprise (dove si applica a tutte le applicazioni BTP) e in ogni account secondario BTP. Ciò potrebbe causare confusione e errori di configurazione in cui le impostazioni di autorizzazione vengono aggiornate in un'unica posizione, ma non l'altra. Ad esempio: un utente è stato consentito in BTP ma non assegnato all'applicazione nell'ID Microsoft Entra, con conseguente errore di autenticazione.

Riepilogo dell'implementazione

Nell'applicazione Microsoft Entra Enterprise che rappresenta la relazione di federazione con IAS disabilitare "Assegnazione utente obbligatoria". Ciò significa anche che è possibile ignorare in modo sicuro l'assegnazione degli utenti.

3 - Usare i gruppi di Microsoft Entra per l'autorizzazione tramite raccolte ruoli in IAS/BTP

Contesto

Quando si vuole configurare l'autorizzazione per le applicazioni BTP, sono disponibili più opzioni:

• È possibile configurare il controllo di accesso con granularità fine all'interno dell'applicazione stessa, in base all'utente connesso.
• È possibile specificare l'accesso tramite ruoli e raccolte di ruoli in BTP, in base alle assegnazioni di utenti o alle assegnazioni di gruppi.

L'implementazione finale può usare una combinazione di entrambe le strategie. Tuttavia, per l'assegnazione tramite raccolte ruoli, questa operazione può essere eseguita su base utente oppure è possibile usare gruppi del provider di identità configurato.

Che cosa è consigliabile?

Se si vuole usare Microsoft Entra ID come origine autorevole per l'autorizzazione con granularità fine, è consigliabile usare i gruppi di Entra di Microsoft e assegnarli alle raccolte ruoli in BTP. Concedere agli utenti l'accesso a determinate applicazioni significa semplicemente aggiungerli ai gruppi Microsoft Entra pertinenti senza ulteriori configurazioni necessarie in IAS/BTP.

Con questa configurazione, è consigliabile usare l'ID gruppo di Microsoft Entra (ID oggetto) come identificatore univoco del gruppo, non il nome visualizzato ("sAMAccountName"). Ciò significa che è necessario usare l'ID gruppo come asserzione "Groups" nel token SAML rilasciato da Microsoft Entra ID. Inoltre, l'ID gruppo viene usato per l'assegnazione alla raccolta di ruoli in BTP.

Perché questa raccomandazione?

Se si assegnano utenti direttamente alle raccolte di ruoli in BTP, non si centralizzano le decisioni di autorizzazione in Microsoft Entra ID. Significa anche che l'utente deve esistere già in IAS prima di poter essere assegnato a una raccolta di ruoli in BTP e dato che è consigliabile la federazione anziché il provisioning degli utenti, significa che l'account shadow dell'utente potrebbe non esistere ancora in IAS al momento in cui si vuole eseguire l'assegnazione dell'utente. L'uso dei gruppi di Microsoft Entra e l'assegnazione di tali gruppi alle raccolte di ruoli elimina questi problemi.

L'assegnazione di gruppi alle raccolte ruoli può sembrare in contrasto con la raccomandazione precedente di non usare Microsoft Entra ID per l'autorizzazione. Anche in questo caso, tuttavia, la decisione di autorizzazione è ancora in corso in BTP, è solo che la decisione è ora basata sull'appartenenza al gruppo gestita in Microsoft Entra ID.

È consigliabile usare l'ID gruppo di Microsoft Entra anziché il nome perché l'ID gruppo è globalmente univoco, non modificabile e non può mai essere riutilizzato per un altro gruppo in un secondo momento; mentre l'uso del nome del gruppo potrebbe causare problemi quando il nome viene modificato e c'è un rischio per la sicurezza di avere un gruppo eliminato e un altro creato con lo stesso nome, ma con gli utenti che non devono avere accesso all'applicazione.

Riepilogo dell'implementazione

In Microsoft Entra ID:

• Creare gruppi a cui è possibile aggiungere gli utenti che devono accedere alle applicazioni in BTP( ad esempio, creare un gruppo Microsoft Entra per ogni raccolta di ruoli in BTP).
• Nell'applicazione Microsoft Entra Enterprise che rappresenta la relazione di federazione con IAS configurare gli attributi utente SAML e le attestazioni per aggiungere un'attestazione di gruppo per i gruppi di sicurezza:

  • Impostare l'attributo Source su "ID gruppo" e su Name Groups (digitato esattamente come questo, con maiuscole "G").

  • Inoltre, per mantenere i payload delle attestazioni di piccole dimensioni ed evitare l'incorrere nella limitazione in cui Microsoft Entra ID limiterà il numero di attestazioni di gruppo a 150 nelle asserzioni SAML, è consigliabile limitare i gruppi restituiti nelle attestazioni solo a quei gruppi assegnati in modo esplicito:

    • In "Quali gruppi associati all'utente devono essere restituiti nell'attestazione?" rispondere con "Gruppi assegnati all'applicazione". Quindi, per i gruppi da includere come attestazioni, assegnarli all'applicazione aziendale usando la sezione "Utenti e gruppi" e selezionando "Aggiungi utente/gruppo".

    

In IAS:

• Nella configurazione del provider di identità aziendale, nelle opzioni di federazione delle identità, assicurarsi di disabilitare "Use Identity Authentication user store"; in caso contrario, le informazioni sul gruppo da Microsoft Entra ID non verranno mantenute nel token SAML verso BTP e l'autorizzazione non riusciranno.

In BTP:

• Nelle raccolte ruoli utilizzate dalle applicazioni in tale sottoaccount eseguire il mapping delle raccolte ruoli ai gruppi di utenti aggiungendo una configurazione per il provider di identità IAS e impostando il nome sull'ID gruppo (ID oggetto) del gruppo Microsoft Entra.

4 - Usare un singolo account secondario BTP solo per le applicazioni con requisiti di identità simili

Contesto

All'interno di BTP, ogni account secondario può contenere più applicazioni. Tuttavia, dal punto di vista IAS una "applicazione in bundle" è un sottoaccount BTP completo, non le applicazioni più granulari al suo interno. Ciò significa che tutte le impostazioni di attendibilità, l'autenticazione e la configurazione di Accesso, nonché le opzioni personalizzazione e layout in IAS si applicano a tutte le applicazioni all'interno di tale account secondario. Analogamente, tutte le configurazioni di trust e le raccolte di ruoli in BTP si applicano anche a tutte le applicazioni all'interno di tale account secondario.

Che cosa è consigliabile?

È consigliabile combinare più applicazioni in un singolo account secondario BTP solo se hanno requisiti simili a livello di identità (utenti, gruppi, provider di identità, ruoli, configurazione trust, personalizzazione, ...).

Perché questa raccomandazione?

Combinando più applicazioni con requisiti di identità molto diversi in un singolo account secondario in BTP, è possibile che si riesca a ottenere una configurazione non sicura o che possa risultare più facilmente non configurata correttamente. Ad esempio: quando viene apportata una modifica di configurazione a una risorsa condivisa come un provider di identità per una singola applicazione in BTP, ciò influisce su tutte le applicazioni che si basano su questa risorsa condivisa.

Riepilogo dell'implementazione

Valutare attentamente come raggruppare più applicazioni tra sottoaccount in BTP. Per altre informazioni, vedere la documentazione del modello di account SAP.

5 - Usare il tenant IAS di produzione per tutte le autorizzazioni e l'autenticazione dell'utente finale

Contesto

Quando si lavora con IAS, in genere si dispone di un tenant di produzione e di sviluppo/test. Per account secondari o applicazioni diversi in BTP, è possibile scegliere il provider di identità (tenant IAS) da usare.

Che cosa è consigliabile?

È consigliabile usare sempre il tenant IAS di produzione per qualsiasi interazione con gli utenti finali, anche nel contesto di una versione o di un ambiente di sviluppo/test dell'applicazione a cui devono accedere.

È consigliabile usare altri tenant IAS solo per il test della configurazione correlata all'identità, che deve essere eseguita in isolamento dal tenant di produzione.

Perché questa raccomandazione?

Poiché IAS è il componente centralizzato che è stato configurato per la federazione con l'ID Microsoft Entra, esiste solo un'unica posizione in cui è necessario configurare e gestire la configurazione della federazione e dell'identità. La duplicazione di questa situazione in altri tenant IAS può causare errori di configurazione o incoerenze nell'accesso degli utenti finali tra ambienti.

6 - Definire un processo per il rollover dei certificati di firma SAML

Contesto

Quando si configura la federazione tra MICROSOFT Entra ID e IAS, nonché tra IAS e BTP, i metadati SAML vengono scambiati che contengono certificati X.509 usati per la crittografia e le firme crittografiche dei token SAML inviati tra entrambe le parti. Questi certificati hanno date di scadenza e devono essere aggiornate periodicamente (anche in situazioni di emergenza quando un certificato è stato compromesso, ad esempio).

Nota: il periodo di validità predefinito del certificato Microsoft Entra iniziale usato per firmare le asserzioni SAML è di 3 anni (e si noti che il certificato è specifico dell'applicazione enterprise, a differenza dei token OpenID Connect e OAuth 2.0 firmati da un certificato globale in Microsoft Entra ID). È possibile scegliere di generare un nuovo certificato con una data di scadenza diversa oppure creare e importare il proprio certificato.

Quando i certificati scadono, non possono più essere usati e devono essere configurati nuovi certificati. Pertanto, è necessario stabilire un processo per mantenere aggiornata la configurazione del certificato all'interno della relying party (che deve convalidare le firme) con i certificati effettivi usati per firmare i token SAML.

In alcuni casi, la relying party può eseguire questa operazione automaticamente fornendogli un endpoint di metadati che restituisce dinamicamente le informazioni sui metadati più recenti, ovvero un URL accessibile pubblicamente da cui la relying party può recuperare periodicamente i metadati e aggiornare l'archivio di configurazione interno.

IAS consente tuttavia di configurare solo i provider di identità aziendali tramite un'importazione del file XML dei metadati, non supporta la fornitura di un endpoint di metadati per il recupero dinamico dei metadati di Microsoft Entra ( ad esempio https://login.microsoftonline.com/my-azuread-tenant/federationmetadata/2007-06/federationmetadata.xml?appid=my-app-id). Analogamente, BTP non consente la configurazione di una nuova configurazione di attendibilità dall'endpoint dei metadati IAS ( ad esempio https://my-ias-tenant.accounts.ondemand.com/saml2/metadata), richiede anche un caricamento monouso di un file XML di metadati.

Che cosa è consigliabile?

Quando si configura la federazione delle identità tra due sistemi , ad esempio Microsoft Entra ID e IAS e IAS e BTP, assicurarsi di acquisire la data di scadenza dei certificati in uso. Assicurarsi che questi certificati possano essere sostituiti in anticipo e che sia disponibile un processo documentato per aggiornare i nuovi metadati in tutte le relying party che dipendono da questi certificati.

Come illustrato in precedenza, è consigliabile configurare una configurazione di trust in BTP verso IAS, che a sua volta viene configurata per la federazione con Microsoft Entra ID come provider di identità aziendale. In questo caso, i certificati seguenti (usati per la firma e la crittografia SAML) sono importanti:

• Certificato dell'account secondario in BTP: quando cambia, è necessario aggiornare la configurazione SAML 2.0 dell'applicazione in IAS.
• Certificato tenant in IAS: quando cambia, è necessario aggiornare sia la configurazione SAML 2.0 dell'applicazione aziendale in Microsoft Entra ID che la configurazione trust in BTP.
• Certificato dell'applicazione aziendale nell'ID Microsoft Entra: quando cambia, è necessario aggiornare la configurazione SAML 2.0 del provider di identità aziendale in IAS.

SAP include implementazioni di esempio per le notifiche dei certificati client con SAP Cloud Integration e la gestione quasi scaduta. Questo può essere adattato con Azure Integration Services o PowerAutomate. Tuttavia, devono essere adattati per lavorare con i certificati server. Questo approccio richiede un'implementazione personalizzata.

Perché questa raccomandazione?

Se i certificati sono autorizzati a scadere o quando vengono sostituiti in tempo, ma le relying party che dipendono da essi non vengono aggiornate con le nuove informazioni sul certificato, gli utenti non potranno più accedere a qualsiasi applicazione tramite la federazione. Ciò può comportare tempi di inattività significativi per tutti gli utenti durante il ripristino del servizio riconfigurando i metadati.

Riepilogo dell'implementazione

Aggiungere un indirizzo di notifica tramite posta elettronica per la scadenza del certificato in Microsoft Entra ID e impostarlo su una cassetta postale di gruppo in modo che non venga inviato a un singolo utente (che potrebbe anche non avere più un account entro la scadenza del certificato). Per impostazione predefinita, solo l'utente che ha creato l'applicazione aziendale riceverà una notifica.

Valutare la possibilità di creare l'automazione per eseguire l'intero processo di rollover del certificato. Ad esempio, è possibile verificare periodicamente la scadenza dei certificati e sostituirli durante l'aggiornamento di tutte le relying party con i nuovi metadati.

Uso di Azure AD B2C come provider di identità

Azure Active Directory B2C fornisce un'identità business-to-customer come servizio. Dato che l'integrazione con Azure AD B2C è simile a come consentire agli utenti aziendali di accedere con Microsoft Entra ID, le raccomandazioni sopra riportate si applicano per lo più quando si vuole usare Azure AD B2C per i clienti, i consumatori o i cittadini e consentire loro di usare le identità di account locali, aziendali o sociali preferite.

Esistono tuttavia alcune importanti differenze. La configurazione di Azure AD B2C come provider di identità aziendale in IAS e la configurazione della federazione tra entrambi i tenant è descritta in modo più dettagliato in questo post di blog.

Registrazione di un'applicazione SAML in Azure AD B2C

Azure AD B2C non dispone di una raccolta di applicazioni aziendali che è possibile usare per configurare facilmente la relazione di trust con il provider di identità aziendale in IAS. Sarà invece necessario usare criteri personalizzati per registrare un'applicazione SAML in Azure AD B2C. Questa applicazione SAML svolge lo stesso ruolo logico dell'applicazione aziendale in Microsoft Entra ID, pertanto si applicano le stesse indicazioni relative al rollover dei certificati SAML, ad esempio.

Autorizzazione con Azure AD B2C

Azure AD B2C non supporta in modo nativo l'uso di gruppi per creare raccolte di utenti a cui è possibile assegnare l'accesso, il che significa che le indicazioni per usare i gruppi di Microsoft Entra per l'autorizzazione tramite raccolte ruoli in BTP devono essere implementate in modo diverso.

Fortunatamente, Azure AD B2C è altamente personalizzabile, quindi è possibile configurare i token SAML inviati a IAS per includere eventuali informazioni personalizzate. Per diverse opzioni sul supporto delle attestazioni di autorizzazione, vedere la documentazione che accompagna l'esempio ruoli app di Azure AD B2C, ma in breve: tramite il relativo meccanismo di estendibilità del connettore API è possibile usare facoltativamente gruppi, ruoli dell'app o anche un database personalizzato per determinare a quale utente è consentito accedere.

Indipendentemente dalla provenienza delle informazioni di autorizzazione, può quindi essere generato come Groups attributo all'interno del token SAML configurando tale nome di attributo come tipo di attestazione partner predefinito nello schema delle attestazioni o eseguendo l'override del tipo di attestazione partner nelle attestazioni di output. Si noti tuttavia che BTP consente di eseguire il mapping delle raccolte ruoli agli attributi utente, il che significa che qualsiasi nome di attributo può essere usato per le decisioni di autorizzazione, anche se non si usa il nome dell'attributo Groups .

Passaggi successivi

• Altre informazioni sulla configurazione iniziale in questa esercitazione
• pianificare la distribuzione di Microsoft Entra per il provisioning utenti con applicazioni di origine e destinazione SAP e
• gestire l'accesso alle applicazioni SAP
• Scoprire altri scenari di integrazione SAP con Microsoft Entra ID e oltre