ADFS v2.0 Errore: MSIS7042: La stessa sessione del browser client ha reso '6' richieste negli ultimi secondi '1'

StackOverflow https://stackoverflow.com/questions/2640030

Domanda

La gente,   Ho un'applicazione ASP.NET MVC che sto tentando di fissare utilizzando la versione Release Candidate di ADFS v2.0 (Ginevra). Ho configurato l'applicazione come un trust della relying party, e ho utilizzato Fedutil.exe per modificare web.config dell'applicazione in modo che abbia le informazioni relative al server di Ginevra e utilizza il server di Ginevra come fonte reclami.

Tuttavia, quando provo e ha colpito l'applicazione MVC, che reindirizza a Ginevra, che poi (dopo di me avviso circa certs auto-firmato) mi reindirizza al app MVC di nuovo. Dopo aver accettato entrambe le avvertenze CERT auto-firmato, i due server giocare a ping-pong con l'altro in un ciclo infinito di reindirizzamento fino a quando finalmente Ginevra SPEWS il seguente messaggio:

La stessa sessione del browser client ha reso '6' richieste negli ultimi secondi '1'. Ci potrebbe essere una possibile configurazione male. Contattare l'amministratore per i dettagli.

Non ci sono errori nei registri eventi sul lato MVC o di Ginevra ad eccezione di un evento che contiene il messaggio di cui sopra. Se qualcuno mi potrebbe dare qualche informazione su come cercare di eseguire il debug, la diagnosi, e si spera risolvere questo problema, sarei eternamente grato.

Anche in questo caso, la casella di Ginevra è l'ADFS v2.0 Release Candidate e il sito ASP.NET MVC è stato costruito utilizzando la (fine '09) la versione più recente del Windows Identity Foundation SDK con web.config modificata utilizzando FedUtil.exe da l'SDK WIF.


Quindi sarà tutto ottenere una scossa da questo ... Ho provato questa stessa applicazione da Firefox e ... Lavori IT. Ottengo richiamato per le mie credenziali di dominio, i ADFS v2 server mi ri-indirizza una volta e poi mi finiscono sulla home page della mia candidatura, completa con il mio nome account e personalizzata saluto. Così ora il vero problema è questo: Perché l'inferno è IE8 impigliarsi in un loop di reindirizzamento infinito e Firefox non è ?? Dopo ancora ulteriori test, sono stato in grado di ottenere questo lavoro scenario, fuori dalla scatola, senza modifiche una qualsiasi delle cose gasdotto di default da ADFS v2 (RC) o da WIF (RTW) su entrambi i Safari e Firefox. IE8 è l'unico browser ad esporre qualsiasi trattare problema con questo scenario di autenticazione. Ho provato di tutto, tra cui l'installazione e confidando i CERT auto-firmato, aggiungendo i siti al mio Intranet locale e far cadere la sicurezza al minimo e anche impostare prima e cookie di terze parti per consentire sempre.

È stato utile?

Soluzione 2

Si scopre che il nome host del relying party ha avuto un carattere di sottolineatura in esso (khoffman_2). A quanto pare, la sottolineatura è un personaggio DNS illegale e SOLO IE rifiuterà l'informazione con la sottolineatura in esso.

I rinominato la mia macchina da khoffman_2 al khoffman2 e v2 ADFS / MVC combinazione parte che invoca funziona perfettamente su Firefox, Safari e Internet Explorer.

Altri suggerimenti

Ho avuto lo stesso problema con ADFS 1.0 E per risolverlo, ho fatto in modo che l'URL aveva una barra finale "/" che avrebbe sempre funziona in Firefox così come IE

ad esempio: https://somedomain.com/Application_2/

Anche se questo non è il tuo problema, abbiamo avuto problemi identici a quello che hai descritto. La nostra soluzione è stata quella:

  1. abilitato l'autenticazione di base in IIS (questo nulla risolto, ma è stato richiesto per i prossimi 2 passi)
  2. disattivare l'autenticazione di Windows in IIS (questo ha risolto il problema per alcuni browser IE, ma non tutti)
  3. Disattiva accesso anonimo in IIS (questo ha risolto il problema per il resto dei browser IE)

La risposta di Jaxidian è vicino.

Nel mio caso ho avuto solo a:

  • autenticazione di Windows -> Disabilitato

  • Anonymous Auth -> Abilitato

  • Rappresentazione ASP.NET -> Disabilitato

  • Moduli Auth -> Disabilitato

  • di Windows Auth -> Disabilitato

Questo ciclo può verificarsi quando un utente non è autorizzato ad accedere a una pagina.

Abbiamo avuto un attributo di autorizzazione personalizzato nostro controller MVC che i controlli per vedere se l'utente fosse in un ruolo in base alle attestazioni previste se l'impostazione per UseADFS era vero nei file di configurazione. Ho pensato che questo impostazione è stata impostata su true e fu confusa che ho continuato a ottenere l'adfs ciclo quando l'accesso alla pagina perché ero nei gruppi che sono stati autorizzati ad accedere alla pagina.

La chiave per la risoluzione dei problemi è stato quello di fare una pagina web che mostrava le mie affermazioni ADFS senza necessariamente richiedere l'autenticazione.

@if (User.Identity.IsAuthenticated)
{
    <div>UserName: @User.Identity.Name;</div>

    var claimsIdentity = User.Identity as System.Security.Claims.ClaimsIdentity;
    <table>
        @foreach (var claim in claimsIdentity.Claims)
        {
        <tr><td>@claim.Type</td><td>@claim.Value</td></tr>
        }
    </table>


}

Ho notato che mi è stato sempre collegato in ADFS, e le mie richieste sono state sempre insieme, in modo da ADFS stava lavorando. Il problema attuale è stato il mio file di configurazione ha avuto UserADFS = "true" invece di UseADFS = "true" che fondamentalmente ha causato la mia codice di autorizzazione personalizzato per falsa ritorno autorizzazione. Pertanto, la pagina continuava spedizioni mi riporta ad ADFS per l'autenticazione di nuovo.

In ogni modo, se un utente non ha rivendicazioni corrette per accedere alla pagina, quindi questo ADFS login può verificarsi loop, pure.

Inoltre, se hai scritto un attributo Autorizza personalizzato assicurati di controllare il seguente link che descrive come prevenire il ciclo.

reindirizzamento ciclo con attributo Netto MVC Autorizza con ADFS rivendicazioni

Custom HandleUnauthorizedRequest codice gestore per AuthorizeAttribute da questo link:

 protected override void HandleUnauthorizedRequest System.Web.Mvc.AuthorizationContext filterContext)
    {
        if (filterContext.HttpContext.Request.IsAuthenticated)
        {
            //One Strategy:
            //filterContext.Result = new System.Web.Mvc.HttpStatusCodeResult((int)System.Net.HttpStatusCode.Forbidden);

            //Another Strategy:
            filterContext.Result = new RedirectToRouteResult(
                new RouteValueDictionary(
                    new
                    {
                        controller = "u",
                        action = "LoginStatus",
                        errorMessage = "Error occurred during authorization or you do not have sufficient priviliges to view this page."
                    })
                );
        }
        else
        {
            base.HandleUnauthorizedRequest(filterContext);
        }
    }
Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top