2015-04-07 9 views
8

Ho un'app ASP.NET MVC 5 che esegue l'autenticazione con Azure Active Directory. Volevo abilitare SSL su di essa attraverso l'app. e quindi sfruttato filtri globali come segue:Abilitazione SSL nell'app ASP.NET MVC 5 risultati nel problema OpenIdConnectProtocolValidator

public class FilterConfig 
{ 
    /// <summary> 
    /// Registers the global filters. 
    /// </summary> 
    /// <param name="filters">The filters.</param> 
    public static void RegisterGlobalFilters(GlobalFilterCollection filters) 
    { 
     filters.Add(new RequireHttpsAttribute()); 
    } 
} 

Dopo questo ho anche impostato 'Abilita SSL' nelle proprietà del progetto è true. Questo mi ha dato il seguente URL SSL ->https://localhost:34567. Ho aggiornato il progetto per avere questo nel suo percorso IIS Express sotto la 'Scheda Web' sotto Server in 'URL del progetto'. Tuttavia durante l'esecuzione del sito eseguo il seguente errore:

IDX10311: RequireNonce is 'true' (default) but validationContext.Nonce is null. A nonce cannot be validated. If you don't need to check the nonce, set OpenIdConnectProtocolValidator.RequireNonce to 'false'.

I have auth. abilitato sul sito. Io uso la directory di Azure Active.

Il codice di sicurezza è la seguente:

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

     app.UseWindowsAzureActiveDirectoryBearerAuthentication(
      new WindowsAzureActiveDirectoryBearerAuthenticationOptions 
      { 
       Audience = audience, 
       Tenant = tenant,  
      }); 

L'autenticazione. I valori vengono letti dal web.config e sono i seguenti:

<add key="ida:ClientId" value="<some_guid>" /> 
<add key="ida:Audience" value="https://localhost:34567/" /> 
<add key="ida:AADInstance" value="https://login.windows.net/{0}" /> 
<add key="ida:Tenant" value="microsoft.onmicrosoft.com" /> 
<add key="ida:PostLogoutRedirectUri" value="https://localhost:34567/" /> 

ho provato a installare RequireNonce false come indicato nel messaggio di errore come segue:

ProtocolValidator = new OpenIdConnectProtocolValidator 
       { 
        RequireNonce = false 
       } 

Ma questo solo portato a un invalido richiesta di errore.

Qualcuno potrebbe aiutarmi a capire qual è il problema? Tutto ha funzionato alla grande fino a quando SSL non è stato abilitato.

+1

Credo di aver capito. L'applicazione. i dettagli in Azure AD sono cablati per dipendere dall'endpoint HTTP originale. Aggiornerà questo una volta convalidata la mia teoria. –

+0

Anche questo lo sto facendo ... –

+0

Per favore, hai risolto questo errore? Sono nella stessa situazione. – Mastenka

risposta

13

È possibile ignorare le eccezioni se il messaggio di errore inizia con OICE_20004 o contiene IDX10311. Nota: farlo a proprio rischio.

Notifications = new OpenIdConnectAuthenticationNotifications() 
{ 
    RedirectToIdentityProvider = (context) => 
    { 
     // Ensure the URI is picked up dynamically from the request; 
     string appBaseUrl = context.Request.Scheme + "://" + context.Request.Host + context.Request.PathBase + context.Request.Uri.PathAndQuery; 
     context.ProtocolMessage.RedirectUri = context.Request.Scheme + "://" + context.Request.Host + context.Request.PathBase + context.Request.Uri.PathAndQuery; 
     context.ProtocolMessage.PostLogoutRedirectUri = appBaseUrl; 
     return Task.FromResult(0); 
    }, 
    AuthenticationFailed = (context) => 
    { 
     if (context.Exception.Message.StartsWith("OICE_20004") || context.Exception.Message.Contains("IDX10311")) 
     { 
      context.SkipToNextMiddleware(); 
      return Task.FromResult(0); 
     } 
     return Task.FromResult(0); 
    }, 
} 
+4

Potresti aggiungere qualche altra descrizione alla soluzione che fornisci? – abarisone

+1

Ha funzionato per me, in uno scenario: l'utente utilizza il pulsante Indietro del browser per passare alla pagina di autenticazione SSO. –

+0

puoi aggiungere qualche descrizione ad esso. –

2

Posso riprodurre questo errore premendo il pulsante Indietro un paio di volte sulla mia applicazione Web, anche dopo il login riuscito. si può provare queste 2 cose: nel codice qui sotto:

app.UseOpenIdConnectAuthentication(
       new OpenIdConnectAuthenticationOptions 
       { 
        ClientId = mViewWebSite.ClientId, 
        Authority = mViewWebSite.Authority, 
        PostLogoutRedirectUri = mViewWebSite.PostLogoutRedirectUri 
       }); 

protocollo aggiuntivo validatore come su delle opzioni di autenticazione, come quello che l'errore suggerisce:

ProtocolValidator = new Microsoft.IdentityModel.Protocols.OpenIdConnectProtocolValidator(){ 
          RequireNonce = false 
         } 

o aggiungere la notifica, da questo si può rilevare questo errore e reindirizzare a qualche pagina di errore. Lo faccio per renderlo grazioso. Finché la gente di Katana non la risolve.

Notifications = new OpenIdConnectAuthenticationNotifications 
         { 
          AuthenticationFailed = context => 
          { 
           context.HandleResponse(); 
           context.Response.Redirect("/Error.aspx?message=" + context.Exception.Message); 
           return Task.FromResult(0); 
          } 
         }, 
6

Dal portale di gestione Azure, verificare che l'applicazione sotto la directory attiva corrispondente ha lo stesso Sign On URL e risposta URL.

Se non sono uguali, si ottiene questo errore.

Ciò accade quando si abilita SSL perché modifica solo l'URL di accesso all'URL HTTPS mentre l'URL di risposta rimane lo stesso URL HTTP.

Edit: Continuate a leggere se volete sapere esattamente perché questo sta accadendo,

Quando si tenta di accedere alla app utilizzando l'URL https, imposta un cookie con un numero unico (nonce) nel tuo browser e fa clic su Azure AD per l'autenticazione. Dopo l'autenticazione, il browser deve consentire l'accesso a quel cookie. Ma poiché l'URL di accesso e l'URL di risposta sono diversi, il browser non riconosce la tua app e non dà accesso a quel cookie e quindi l'applicazione genera questo errore.

1

Sono riuscito a risolvere questo problema utilizzando il seguente metodo nel file Global.asax. Almeno questo non mostrerà l'eccezione al client. Uso ELMAH per rilevare le eccezioni.

protected void Application_Error(object sender, EventArgs args) 
    { 
     var ex = Server.GetLastError(); 
     if (ex.Message.Contains("IDX10311:")) 
     { 
      Server.ClearError(); 
      Response.Redirect("https://www.yoursitename.com");     
     } 
0

Beh probabilmente sarebbe meglio guardare il codice sorgente katana, da che ho trovato il tipo di eccezione per essere OpenIdConnectProtocolInvalidNonceException quindi mi occupo in questo modo.

 if (n.Exception is OpenIdConnectProtocolInvalidNonceException && 
      n.OwinContext.Authentication.User.Identity.IsAuthenticated) 
     { 
      n.SkipToNextMiddleware(); 
      return; 
     } 

Ho questa eccezione popup sui browser che nascondono le pagine e gli utenti che fanno clic sul pulsante Indietro dopo l'accesso.

0

Il problema qui è semplice ... mi ci sono volute ore per capirlo. Dal momento che stavo testando il mio locale non aveva https e per dirti la verità quando inizialmente creavo la mia app in Azure AD poiché non mi aspettavo che fosse https durante il mio test, l'ho reso semplice http (URL HomePage di replyUrl, Esci tutto quel jazz)

Poi dopo aver fatto questo ho incontrato il problema del ciclo infinate un sacco di persone sono sempre. Allora ho deciso di prendere in giro il CERT sul mio locale e sì che è sbarazzato del redirect infinate ma poi ha portato un altro il "IDX10311: RequireNonce è 'vero'" uno

farla breve ... rendere il vostro AzureAD App https in tutti i suoi endpoint. e wallah!

0

Basta aggiungere un altro caso in cui mi sono imbattuto: la rete a cui ci si connette potrebbe modificare il contenuto HTML.

Un cliente ha chiamato con un problema: non è riuscito a superare questo errore. Era un nuovo portatile in cui non si era collegato prima. Dopo circa un'ora di provare diverse soluzioni possibili, ho deciso di controllare la rete a cui era connesso.

Si scopre che era connesso a una rete in un aeroporto, aperto e non protetto, e che non utilizzava un servizio VPN (mancano alcuni SETA lì). Non so esattamente chi ha gestito quella rete o cosa stessero facendo, ma il servizio di Azure AD deve aver rilevato un qualche tipo di manomissione con il nonce.

Nel momento in cui l'utente si è connesso a una rete attendibile, il problema è stato risolto.