6

Sto utilizzando il seguente esempio di codice per collegare il login di Azure AD alla mia applicazione (https://github.com/AzureADSamples/WebApp-OpenIDConnect-DotNet).Reindirizzare l'utente alla pagina di accesso personalizzata quando si utilizza Azure AD

Sto trovando che il codice funziona bene, ma voglio avere la possibilità di reindirizzare un utente a una pagina di accesso personalizzata se l'utente non ha ancora effettuato l'accesso o la loro sessione è scaduta. Sto lottando comunque per farlo funzionare e mi stavo chiedendo se questo è davvero possibile?

È in base alla progettazione che l'utente viene sempre reindirizzato alla pagina di accesso Microsoft per Azure AD piuttosto che alla propria pagina personalizzata o esiste un'impostazione che ho perso?

ho modificato il codice fornito in FilterConfig.cs per consentire l'attributo di filtro Autorizza:

filters.Add(new AuthorizeAttribute()); 

Ho anche aggiunto quanto segue al web.config ma senza effetto:

<authorization> 
<allow users="?" /> 
</authorization> 

All'interno del Startup.Auth.cs file Non riesco a vedere nessuna modifica possibile a app.UseOpenIdConnectAuthentication per consentirmi di impostare una pagina di accesso generica, come probabilmente posso fare con l'autenticazione basata sui cookie.

risposta

9

Dopo aver esaminato il codice, ho trovato la soluzione al mio problema.

Da Startup.Auth.cs:

app.UseCookieAuthentication(new CookieAuthenticationOptions { 
    LoginPath = new PathString("/Account/Login") 
}); 

app.UseOpenIdConnectAuthentication(
    new OpenIdConnectAuthenticationOptions { 
     ClientId = clientId, 
     Authority = authority, 
     PostLogoutRedirectUri = postLogoutRedirectUri, 
     AuthenticationMode = AuthenticationMode.Passive 
}); 

È l'inclusione della linea AuthenticationMode = AuthenticationMode.Passive che sembra fermare OpenIdConnectAuth dal compiere l'automatico 302 reindirizzamento alle pagine AAD login.

+0

@BenV che combina il tuo suggerimento di usare AAD premium per la schermata di login AAD personalizzata con quanto sopra, penso che questo sia un approccio molto più preferibile ad avere un flusso di login un po 'personalizzato. – choms79

+0

Se potessi passare questa risposta più volte, lo farei. –

0

Supponendo che Azure AD sia il provider di identità, è possibile Customize the login page, ma è necessario eseguire Azure AD Premium per farlo.

+0

Grazie per questo @BenV, speravo di poter avere il controllo completo all'interno della mia app e di presentare una pagina di accesso personalizzata ogni qualvolta fosse necessaria l'autorizzazione, ad esempio http: // /Account/Login. Immagino che tu non possa, perché ciò sconfigge lo scopo di AD Premium. – choms79

+0

L'idea è che invece di assumersi la responsabilità di ** in modo sicuro ** raccogliendo e trasportando personalmente le credenziali dell'utente, è possibile delegare questa responsabilità ad AAD. – BenV

0

questo forse quello che sto cercando ...

l'autenticazione

Questo campione permette ad un utente di accedere per Azure AD, senza la necessità di utilizzare gli accessi basati su browser nativi di Azure AD.

Capisco che questo è in qualche modo considerato un anti modello, in quanto rinuncerò ai meccanismi incorporati di Azure per gestire l'autenticazione a più fattori, le reimpostazioni di password ecc. Ma conserverò il pieno controllo dell'esperienza.

==== Modifica ==== Questo non è il modo in cui voglio andare, perché spoglio molto di ciò che AAD offre. In sostanza mi piacerebbe mantenere i flussi di controllo di AAD ma voglio solo avere la possibilità di controllare su quale pagina un utente atterra quando un utente non è loggato.

Attualmente il flusso è: Non autorizzato -> reindirizzamento 302 -> login AAD

mi piacerebbe: non autorizzata -> 302 reindirizzamento -> Auto ospitato login pagina desiderata -> pulsante di accesso utente stampa -> 302 reindirizzamento -> AAD login

suo questo flusso Non riesco a capire.

+0

Questo è anche un uso improprio del protocollo OAuth (che è destinato all'autorizzazione delegata) per l'autenticazione, che [alcuni dicono] (http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication .html) apre alcuni buchi di sicurezza. Ma sì, è tecnicamente possibile e tu mantenga il pieno controllo dell'UX. – BenV

Problemi correlati