Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Per impostazione predefinita, MSAL impedisce i reindirizzamenti dell'intero frame all'endpoint di autenticazione di Microsoft Entra ID quando un'app viene visualizzata all'interno di un iframe, il che significa che non è possibile usare le API di reindirizzamento per l'interazione dell'utente con l'IdP:
- Questa restrizione viene imposta perché Microsoft Entra ID rifiuterà di eseguire il rendering di qualsiasi richiesta di interazione dell'utente (ad esempio, immissione delle credenziali, consenso, disconnessione e così via) in un iframe generando l'errore
X-FRAME OPTIONS SET TO DENY, una misura presa per impedire attacchi clickjacking. - È invece necessario basarsi sulle API popup di MSAL se è necessaria l'interazione dell'utente e/o sulle API invisibile all'utente (
ssoSilent(),acquireTokenSilent()) se è possibile evitare l'interazione dell'utente. - Analogamente, dovrai usare l'API logoutPopup() per le disconnettezioni (:warning: se l'app usa una versione
msal-browserprecedente alla versione 2.13, assicurati di aggiornare e sostituire l'logout()API, perché tenterà un reindirizzamento full-frame a Microsoft Entra ID). - Quando si usano le API popup, è necessario tenere conto di eventuali restrizioni di sandboxing imposte dall'app padre. In particolare, l'app padre deve impostare il
allow-popupsflag quando l'iframe è in modalità sandbox.
Azure AD B2C offre un'esperienza di accesso incorporata, che consente di eseguire il rendering di un'interfaccia utente di accesso personalizzata in un iframe. Poiché MSAL impedisce il reindirizzamento in iframe per impostazione predefinita, è necessario impostare l'opzione di configurazione allowRedirectInIframe su true per poter usare questa funzionalità. Si noti che l'abilitazione di questa opzione per le app in Microsoft Entra ID non è consigliata a causa della restrizione precedente.
Restrizioni del browser
Poiché Microsoft Entra cookie di sessione all'interno di un iframe sono considerati cookie di terze parti, alcuni browser (ad esempio Safari o Chrome in modalità in incognito) bloccano o cancellano questi cookie per impostazione predefinita. Ciò influirà sull'esperienza di Single Sign-On per le app iframed perché non avrà accesso ai cookie di sessione di IdP (vedere: Single Sign-On).
Inoltre, quando i cookie di terze parti sono disabilitati in Chrome, le app MSAL iframed non avranno accesso all'archiviazione locale o sessione. MSAL userà l'archiviazione in memoria come soluzione di fallback in questo caso.
Autenticazione unica
È possibile ottenere l'accesso Single Sign-On tra app iframed e padre con la stessa originee con cross-originse si passa un hint per l'account dall'app padre all'app iframed.
App con la stessa origine
Le app incorporate in iframe e le app padre della stessa origine possono accedere alla stessa istanza della cache di MSAL.js ed eseguire l'accesso senza prompt, a condizione che entrambe configurino MSAL per usare l'archiviazione locale come cache. Per altre informazioni, vedere Single Sign-On con MSAL.js
App con cross-origin
Le app incorporate tramite iframe e le app padre di origine diversa possono utilizzare l'API ssoSilent() per realizzare il Single Sign-On. A tale scopo, l'app padre deve passare all'app incorporata in un iframe uno dei seguenti elementi: un account, un loginHint (nome utente) o un ID di sessione (sid).
Le app possono tentare di usare ssoSilent senza alcun parametro precedente. Tenere tuttavia presente che esistono considerazioni aggiuntive quando si usa ssoSilent senza fornire informazioni sulla sessione dell'utente.
Per la comunicazione tra origini diverse tra app incorporate in un iframe e app padre, puoi valutare alcune alternative:
- È possibile aggiungere parametri di query all'URL di origine dell'iframe nell'app principale e recuperarli in seguito nell'iframe figlio:
// Create the main myMSALObj instance
// configuration parameters are located at authConfig.js
const myMSALObj = new msal.PublicClientApplication({
auth: {
clientId: "ENTER_CLIENT_ID",
authority: "https://login.microsoftonline.com/ENTER_TENANT_ID",
redirectUri: "/redirect", // set to a blank page for handling auth code response via popups
},
cache: {
cacheLocation: "localStorage", // set your cache location to local storage
},
});
window.onload = () => {
const urlParams = new URLSearchParams(window.location.search);
const sid = urlParams.get("sid");
// attempt SSO
myMSALObj.ssoSilent({
sid: sid
}).then((response) => {
// do something with response
}).catch(error => {
// handle errors
});
}
- È possibile utilizzare l'API postMessage() nell'applicazione principale e rimanere in ascolto degli eventi di messaggio nell'applicazione figlia:
// Create the main myMSALObj instance
// configuration parameters are located at authConfig.js
const myMSALObj = new msal.PublicClientApplication({
auth: {
clientId: "ENTER_CLIENT_ID",
authority: "https://login.microsoftonline.com/ENTER_TENANT_ID",
redirectUri: "/redirect", // set to a blank page for handling auth code response via popups
},
cache: {
cacheLocation: "localStorage", // set your cache location to local storage
},
});
const parentDomain = "http://localhost:3001";
window.addEventListener("message", (event) => {
// check the origin of the data
if (event.origin === parentDomain) {
const sid = event.data;
// attempt SSO
myMSALObj.ssoSilent({
sid: sid
}).then((response) => {
// do something with response
}).catch(error => {
// handle errors
});
}
});
Gestione degli errori
Dovresti intercettare e gestire eventuali errori se ssoSilent() non riesce. In particolare:
- InteractionRequiredError: verrà generata se è necessario il consenso, l'utente deve eseguire l'autenticazione a più fattori e così via. Questo errore può essere spesso gestito semplicemente avviando un'API interattiva.
-
BrowserAuthError: verrà generata se non viene fornito alcun hint di account o non valido, i popup vengono bloccati e così via. È necessario controllare e
errorCodegestire questi elementi in modo appropriato.
myMSALObj.ssoSilent({
sid: sid
}).then((response) => {
// do something with response
}).catch(error => {
if (error instanceof msal.InteractionRequiredAuthError) {
myMSALObj.loginPopup()
.then((response) => {
// do something with response
});
} else if (error instanceof msal.BrowserAuthError) {
if (error.errorCode === "silent_sso_error") {
// e.g. username is null
}
if (error.errorCode === "popup_window_error") {
// e.g. popups are blocked
}
} else {
console.log(error);
}
});
Interazione dell'utente
Se si vuole ridurre al minimo la comunicazione con IdP che richiede l'interazione dell'utente o se si verificano problemi con i popup per qualsiasi motivo, è possibile prendere in considerazione alcune opzioni:
Concedi il consenso dell'amministratore. In questo modo si garantisce che non siano presenti richieste di consenso per le autorizzazioni richieste dall'app quando gli utenti accedono per la prima volta.
Preautorizzare le app client. Ciò garantisce che non siano presenti richieste di consenso per le autorizzazioni richieste dall'API Web quando viene chiamato dalle app client.
Disconnessione singola
È possibile usare MSAL.js con un URI di disconnessione del canale frontale per ottenere l'effetto di disconnessione unica tra le app incorporate in un iframe e l'app padre. Ad esempio, se vuoi che gli utenti vengano disconnessi automaticamente dalle app incorporate in iframe quando si disconnettono dall'app principale, devi abilitare il logout front-channel per le app incorporate in iframe. Per farlo, consulta: Come configurare un URI di logout front-channel.