Come vedere lo stato di reindirizzamento da un STS / IDP

Question

Ho cercato (sondinato, anche) per una risposta a questo, ma non ho trovato nulla di utile finora. Sono abbastanza nuovo per ADFS, STS è in generale e WIF, quindi si per favore scusa qualsiasi ovvia ignoranza o uso inappropriato della terminologia. ;)

Attualmente sto integrando un'app MVC3 personalizzata con un IDP esterno, tramite ADFS. L'installazione ADFS in IDP è finita e funziona.

Alcune parti del sito sono accessibili agli utenti di Anon - nella modalità di autenticazione Web.config non è stato impostato su Nessuno. Le altre parti sono protette con i loro controller / metodi di azione decorati da un sistema personalizzato.Web.mvc.authorizeattribute.

Tutte le solite modifiche al web.config per l'utilizzo del wsfedesationauthenticationmodule sono state apportate e funziona al 95%; L'utente può sfogliare le parti accessibili dell'anon del sito. Quando cercano di colpire le parti protette, i controlli dell'attributo Autorizzano se hanno alcune informazioni personalizzate dal nostro IDP negli ICLAMSPrincipals associati a HTTPConText.Current.User e quindi imposta l'AzioneResult a 401 se non; Il wsfederationauthenticationmodule calcia e li reindirizza alla pagina di accesso della IDP. Quando entrano nei loro dettagli, vengono quindi reindirizzati con successo con alcuni biscotti di Fedauth e l'autorizzazione passa quindi.

Il problema inizia quando arrivano alla pagina di accesso della IDP. Questo particolare IDP ha un link per restituire direttamente al nostro sito (alla stessa pagina è stata effettuata la richiesta originale a), con questa risposta SAML incorporata da qualche parte (questo è in base alla loro documentazione)

URN: OASIS: NAME: TC: SAML: 2.0: Stato: AuthNFailed

A questo punto, ora sono "non autorizzati" e tutto l'utente vedrà (almeno in dev) è una pagina 401. Devi uccidere la sessione o altrimenti sbarazzarti di quel cookie per ricominciare.

Quello che devo fare è intercettare che la richiesta di reindirizzamento dell'IDP e sostanzialmente controlla per quel particolare stato di SAML, poiché l'utente dovrebbe quindi essere reindirizzato a una delle aree non autorizzate come se nulla sia accaduto. Ho provato qualcosa del genere in the global.asax:

 protected void Application_Start()
    {
        // mvc stuff here....

        // add handler to intercept handling creation of security tokens by WsFederationAuthnticationModule
        FederatedAuthentication.ServiceConfigurationCreated += OnServiceConfigurationCreated;
    }

    void OnServiceConfigurationCreated(object sender, ServiceConfigurationCreatedEventArgs e)
    {
        FederatedAuthentication
            .WSFederationAuthenticationModule
            .SessionSecurityTokenCreated += WSFederationAuthenticationModule_SecuityTokenCreated;
    }

    public void WSFederationAuthenticationModule_SecuityTokenCreated (Object sender, SessionSecurityTokenCreatedEventArgs args) 
    {          
        var token = args.SessionToken;
        // do something with the session token here e.g. check for SAML status
    }

.

.. Ma non posso vedere nulla di utile su quel token; Niente per indicare uno stato di risposta specifico. Il fatto che ci sia un cookie fedeuth a tutti ma nessuna informazione personalizzata dall'IDP è un morto regale che l'utente è stato lì, ma in qualche modo non è riuscito ad autenticare, ma in linea di principio voglio essere in grado di Vedi quello stato. Potrei dover affrontare timeouts presso l'IDP pure ....

Forse sto facendo tutto questo sbagliato, o semplicemente vecchio non capisco, ma in qualche modo può riempirmi su come determinare quegli stati di risposta?

Phew. Grazie! : D

Answer 1

OK, quindi ho intenzione di rispondere alla mia domanda.

La risposta se posso ottenere questo stato personalizzato dal mio IDP è un no, al momento. : (

Ma questo è solo perché ADFS non è configurato per catturarlo e passarlo. Apparentemente è necessario eseguire una codifica personalizzata per la catturazione delle informazioni dal canale posteriore aperto tra ADFS e l'IDP .... ben oltre l'attuale portata del lavoro.

Come un'opera per il momento:

.
• Se una richiesta viene effettuata al sito e non vi è alcun token SAML, è una nuova richiesta da parte di un utente che non ha fatto alcun tentativo di autenticazione presso l'IDP
• Se c'è un token Saml ma nessun ID dall'IDP nel token (che è presente solo quando aumenta correttamente), allora l'utente non ha funzionato per qualche motivo
  .
  • Se c'è un token Saml con l'ID presente, l'utente AUTH'd correttamente

    Non eccezionale ma accettabile. A proposito, tutto il credito va a ymc in questo Allora post per il seguente codice che consente di controllare i token SAML:

    void WSFederationAuthenticationModule_SecurityTokenReceived(object sender, SecurityTokenReceivedEventArgs e)
        {
            var message = SignInResponseMessage.CreateFromFormPost(Request) as SignInResponseMessage;
            var rstr = new WSFederationSerializer()
                .CreateResponse(message,
                new WSTrustSerializationContext(
                    SecurityTokenHandlerCollectionManager.CreateDefaultSecurityTokenHandlerCollectionManager()));
        } 
    

    .

    PCE!