Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Domyślnie biblioteka MSAL uniemożliwia przekierowania całej strony do punktu końcowego uwierzytelniania usługi Microsoft Entra ID, gdy aplikacja jest wyświetlana wewnątrz elementu iframe, co oznacza, że nie można używać interfejsów API przekierowań do interakcji użytkownika z dostawcą tożsamości:
- To ograniczenie wprowadzono, ponieważ Microsoft Entra ID odmówi wyświetlenia jakiegokolwiek monitu wymagającego interakcji użytkownika (np. wprowadzania poświadczeń, wyrażenia zgody, wylogowania itp.) w elemencie iframe, zgłaszając
X-FRAME OPTIONS SET TO DENYbłąd; jest to środek stosowany w celu zapobiegania atakom typu clickjacking. - Zamiast tego musisz polegać na interfejsach API wyskakujących biblioteki MSAL, jeśli wymagana jest interakcja użytkownika i/lub dyskretne interfejsy API (
ssoSilent(),acquireTokenSilent()), jeśli można uniknąć interakcji z użytkownikiem. - Podobnie musisz użyć interfejsu API logoutPopup() do wylogowywania (:warning: jeśli aplikacja używa wersji
msal-browserstarszej niż v2.13, pamiętaj, aby ją uaktualnić i zastąpić interfejs APIlogout(), ponieważ będzie on próbował wykonać przekierowanie całej ramki do Microsoft Entra ID). - W przypadku korzystania z interfejsów API wyskakujących okien należy wziąć pod uwagę wszelkie ograniczenia mechanizmu sandbox nałożone przez aplikację nadrzędną. W szczególności aplikacja nadrzędna musi ustawić flagę
allow-popups, gdy dla elementu iframe włączono piaskownicę.
usługa Azure AD B2C oferuje osadzone środowisko logowania, które umożliwia renderowanie niestandardowego interfejsu użytkownika logowania w elemecie iframe. Ponieważ biblioteka MSAL domyślnie uniemożliwia przekierowywanie w elementach iframe, należy ustawić opcję konfiguracji allowRedirectInIframe na wartość true , aby móc korzystać z tej funkcji. Należy pamiętać, że włączenie tej opcji dla aplikacji w Microsoft Entra ID nie jest zalecane ze względu na powyższe ograniczenie.
Ograniczenia przeglądarki
Ponieważ pliki cookie sesji Microsoft Entra w ramce iframe są traktowane jako pliki cookie innych firm, niektóre przeglądarki (na przykład Safari lub Chrome w trybie incognito) domyślnie blokują lub czyściją te pliki cookie. Wpłynie to na logowanie jednokrotne w przypadku aplikacji osadzonych w ramkach iframe, ponieważ nie będą one miały dostępu do plików cookie sesji IdP (zobacz: Logowanie jednokrotne).
Ponadto gdy pliki cookie stron trzecich są wyłączone w Chrome, aplikacje MSAL osadzone w ramkach iframe nie będą miały dostępu do pamięci localStorage ani sessionStorage. Biblioteka MSAL przejdzie w tym przypadku na magazynowanie w pamięci.
Jednokrotne logowanie
Za pomocą możesz uzyskaćlogowanie jednokrotne między aplikacją osadzoną w ramce iframe a aplikacją nadrzędną zarówno w przypadku tego samego pochodzenia, jak iróżnego pochodzenia, jeśli przekażesz wskazówkę dotyczącą konta z aplikacji nadrzędnej do aplikacji osadzonej w ramce iframe.
Aplikacje z tym samym źródłem
Aplikacje osadzone w elemencie iframe i aplikacje nadrzędne o tym samym pochodzeniu mogą mieć dostęp do tej samej instancji pamięci podręcznej MSAL.js i umożliwiać logowanie bez wyświetlania monitów, pod warunkiem że obie aplikacje skonfigurują bibliotekę MSAL tak, aby używała pamięci lokalnej do buforowania. Więcej informacji znajdziesz w: logowaniu jednokrotnym z MSAL.js
Aplikacje z różnych źródeł
Aplikacje osadzone w elemencie iframe i aplikacje nadrzędne działające w różnych domenach mogą korzystać z interfejsu API ssoSilent(), aby zapewnić logowanie jednokrotne (SSO). W tym celu aplikacja nadrzędna powinna przekazać konto,loginHint (nazwa użytkownika) lub identyfikator sesji (sid) do aplikacji iframed.
Aplikacje mogą próbować używać ssoSilent bez żadnego z powyższych parametrów. Należy jednak pamiętać, że podczas korzystania z niej należy wziąć ssoSilent bez podawania żadnych informacji o sesji użytkownika.
W przypadku komunikacji między różnymi źródłami między aplikacjami osadzonymi za pomocą iframe a aplikacjami nadrzędnymi istnieje kilka alternatyw, które można rozważyć:
- Parametry zapytania można dodać do adresu URL elementu iframe w aplikacji nadrzędnej i pobrać je później w elemencie podrzędnym:
// 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
});
}
- Możesz użyć interfejsu API postMessage() w aplikacji nadrzędnej i nasłuchiwać zdarzeń message w aplikacji podrzędnej:
// 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
});
}
});
Obsługa błędów
Jeśli operacja ssoSilent() zakończy się niepowodzeniem, należy przechwycić i obsłużyć wszelkie błędy. W szczególności:
- InteractionRequiredError: zostanie zgłoszony, jeśli jest wymagana zgoda, użytkownik musi wykonać uwierzytelnianie wieloskładnikowe itd. Ten błąd może być często obsługiwany przez zainicjowanie interaktywnego interfejsu API.
-
BrowserAuthError: zostanie zgłoszony, jeśli nie podano podpowiedzi konta lub jest ona nieprawidłowa, wyskakujące okienka są blokowane itd. Należy przeanalizować
errorCodei odpowiednio to obsłużyć.
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);
}
});
Interakcja użytkownika
Jeśli chcesz zminimalizować komunikację z dostawcą tożsamości, która wymaga interakcji z użytkownikiem lub jeśli masz problemy z wyskakujących okienek z jakiegokolwiek powodu, możesz rozważyć następujące opcje:
Udziel zgody administratora. Gwarantuje to, że nie ma monitów o zgodę dotyczących uprawnień wymaganych przez aplikację podczas pierwszego logowania użytkowników.
Wstępnie autoryzuj aplikacje klienckie. Gwarantuje to, że nie ma monitów o zgodę na uprawnienia wymagane przez internetowy interfejs API, gdy są wywoływane przez aplikacje klienckie.
Wylogowanie jednokrotne
Możesz użyć MSAL.js z adresem URI wylogowania kanałem frontowym, aby uzyskać efekt pojedynczego wylogowania pomiędzy aplikacjami osadzonymi w ramkach iframe i aplikacjami nadrzędnymi. Jeśli na przykład chcesz, aby użytkownicy automatycznie wylogowywali się z aplikacji osadzonych w ramkach iframe, gdy wylogują się z aplikacji nadrzędnej, powinieneś włączyć wylogowanie front-channel dla aplikacji osadzonych w ramkach iframe. Aby to zrobić, zapoznaj się z informacjami w: Jak skonfigurować identyfikator URI wylogowania w kanale front-channel.