La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.
Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).
In questo documento viene descritto come configurare l'autenticazione SAML (Security Assertion Markup Language) in particolare per l'appliance ASA (Adaptive Security Appliance) AnyConnect con Microsoft Azure MFA.
Cisco raccomanda la conoscenza dei seguenti argomenti:
Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
SAML è un framework basato su XML per lo scambio dei dati di autenticazione e autorizzazione tra domini di sicurezza. Instaura una relazione di fiducia tra l'utente, un provider di servizi (SP) e un provider di identità (IdP) che consente all'utente di accedere contemporaneamente a più servizi. Microsoft Azure MFA si integra perfettamente con l'appliance Cisco ASA VPN per fornire ulteriore sicurezza agli accessi a Cisco AnyConnect VPN.
Metadati: si tratta di un documento basato su XML che garantisce una transazione sicura tra IdP e SP. Permette ai due provider di negoziare accordi.
Ruoli supportati dai dispositivi (IdP, SP)
Un dispositivo può supportare più ruoli e può contenere valori sia per un SP che per un IdP. Nel campo EntityDescriptor viene specificato un descrittore IDPSSODescriptor per le informazioni relative al provider IdP con accesso Single Sign-On o un descrittore SPSSDescriptor per le informazioni relative a un provider SP con accesso Single Sign-On. Questa distinzione è importante per configurare correttamente il processo SAML, in quanto occorre usare sempre i valori corretti a seconda del provider.
ID entità: questo campo è un identificatore univoco per un SP o un IdP. Un singolo dispositivo può disporre di più servizi e utilizzare ID entità diversi per differenziarli. Ad esempio, l'appliance ASA usa ID entità diversi per i diversi tunnel-group che devono essere autenticati. Un IdP che autentica ogni gruppo di tunnel dispone di voci di ID entità separate per ogni gruppo di tunnel al fine di identificare con precisione tali servizi.
L'appliance ASA può supportare più provider di identità e ha un ID entità separato per ciascun provider per differenziarli. Se una delle due parti riceve un messaggio che non contiene un ID entità già configurato, è probabile che il dispositivo elimini il messaggio interrompendo il processo di autenticazione SAML. L'ID entità si trova nel campo EntityDescriptor accanto all'ID autorità (authorityID).
URL servizio: definiscono l'URL di un servizio SAML fornito dall'SP o dall'IdP. Per i provider di identità, equivale in genere ai servizi Single Logout Service e Single Sign-On. Per i provider di servizi, equivale in genere ai servizi Assertion Consumer Service e Single Logout Service.
L'URL del servizio Single Sign-On specificato nei metadati del provider di identità viene usato dal provider di servizi per reindirizzare l'utente al provider di identità e procedere all'autenticazione. Se questo valore non è configurato correttamente, il provider di identità non riceve o non è in grado di elaborare correttamente la richiesta di autenticazione inviata dal provider di servizi.
L'URL del servizio Assertion Consumer Service specificato nei metadati del provider di servizi viene utilizzato dal provider di identità per reindirizzare l'utente al provider di servizi e fornire informazioni sul tentativo di autenticazione. Se non è configurato correttamente, il provider di servizi non riceve l'asserzione (risposta) o non è in grado di elaborarla correttamente.
L'URL del servizio Single Logout Service è disponibile sia sul provider di servizi sia sul provider di identità. Viene utilizzato per facilitare la disconnessione di tutti i servizi SSO dal provider di servizi ed è facoltativo sull'ASA. Quando l'URL del servizio SLO presente nei metadati del provider IdP è configurato sul provider SP, quando l'utente si disconnette dal servizio sul provider SP, il provider SP invia la richiesta al provider IdP. Una volta che l'IdP ha eseguito correttamente la disconnessione dell'utente dai servizi, reindirizza nuovamente l'utente all'SP e utilizza l'URL del servizio SLO trovato nei metadati dell'SP.
Associazioni SAML per URL servizio: le associazioni sono il metodo utilizzato dall'SP per trasferire le informazioni all'IdP e viceversa per i servizi. Includono il reindirizzamento HTTP, il test POST HTTP e gli artefatti. Ogni metodo ha un modo diverso di trasferire i dati. Il metodo di binding supportato dal servizio è incluso nella definizione dei servizi. Ad esempio: SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location=https://saml.example.com/simplesaml/saml2/idp/SSOService.php/ >. L'ASA non supporta il binding degli artefatti. L'ASA usa sempre il metodo di reindirizzamento HTTP per le richieste di autenticazione SAML, quindi è importante scegliere l'URL del servizio SSO che usa il binding di reindirizzamento HTTP in modo che il provider di identità ne sia informato.
Per garantire la riservatezza e l'integrità dei messaggi scambiati tra il provider SP e il provider IdP, SAML offre la possibilità di criptare e firmare i dati. Il certificato utilizzato per crittografare e/o firmare i dati può essere incluso nei metadati in modo che l'estremità che riceve possa verificare il messaggio SAML e assicurarsi che provenga dall'origine prevista. I certificati usati per la firma e la crittografia si trovano nei metadati, rispettivamente in KeyDescriptor use="signing" e in KeyDescriptor use="encryption", quindi X509Certificate. L'ASA non supporta la crittografia dei messaggi SAML.
Passaggio 1. Accedere al portale di Azure e scegliere Azure Active Directory.
Passaggio 2. Come illustrato in questa immagine, scegliere Applicazioni aziendali.
Passaggio 3. Scegliere Nuova applicazione, come illustrato nell'immagine.
Passaggio 4. Nella sezione Aggiungi dalla raccolta, digitare AnyConnect nella casella di ricerca, scegliere Cisco AnyConnect dal pannello dei risultati, quindi aggiungere l'app.
Passaggio 5. Scegliere la voce di menu Accesso singolo, come illustrato nell'immagine.
Passaggio 6. Selezionate SAML, come mostrato nell'immagine.
Passaggio 7. Modificare la sezione 1 con questi dettagli.
a. Identifier (Entity ID) - https://<VPN URL>/saml/sp/metadata/<TUNNEL-GROUP NAME> b. Reply URL (Assertion Consumer Service URL) - https://<VPN URL>/+CSCOE+/saml/sp/acs?tgname=<TUNNEL-GROUP NAME> Example: vpn url called asa.example.com and tunnel-group called AnyConnectVPN-1
Passaggio 8. Nella sezione Certificato di firma SAML, scegliere Scarica per scaricare il file del certificato e salvarlo nel computer.
Passaggio 9. Questa operazione è obbligatoria per la configurazione dell'ASA.
In questa sezione, Test1 è abilitato in modo da usare l'accesso Single-Sign-On Azure e permettere di accedere all'applicazione Cisco AnyConnect.
Passaggio 1. Nella pagina di panoramica dell'app, scegliere Utenti e gruppi, quindi Aggiungi utente.
Passaggio 2. Scegliere Utenti e gruppi nella finestra di dialogo Aggiungi assegnazione.
Passaggio 3. Nella finestra di dialogo Aggiungi assegnazione fare clic sul pulsante Assegna.
Passaggio 1. Creare un trust point e importare il certificato SAML.
config t
crypto ca trustpoint AzureAD-AC-SAML revocation-check none no id-usage enrollment terminal no ca-check crypto ca authenticate AzureAD-AC-SAML -----BEGIN CERTIFICATE----- … PEM Certificate Text you downloaded goes here … -----END CERTIFICATE----- quit
Passaggio 2. Questi comandi eseguono il provisioning del provider di identità SAML.
webvpn saml idp https://xxx.windows.net/xxxxxxxxxxxxx/ - [Azure AD Identifier] url sign-in https://login.microsoftonline.com/xxxxxxxxxxxxxxxxxxxxxx/saml2 - [Login URL] url sign-out https://login.microsoftonline.com/common/wsfederation?wa=wsignout1.0 – Logout URL trustpoint idp AzureAD-AC-SAML - [IdP Trustpoint] trustpoint sp ASA-EXTERNAL-CERT - [SP Trustpoint] no force re-authentication no signature base-url https://asa.example.com
Passaggio 3. Applica autenticazione SAML a una configurazione tunnel VPN.
tunnel-group AnyConnectVPN-1 webvpn-attributes saml identity-provider https://xxx.windows.net/xxxxxxxxxxxxx/ authentication saml end write memory
Nota: se si apportano modifiche alla configurazione IdP, è necessario rimuovere la configurazione del provider di identità saml dal gruppo di tunnel e riapplicarla per rendere effettive le modifiche.
Passaggio 1. Connettersi all'URL della VPN e immettere il log nei dettagli di Azure AD.
Passaggio 2. Approvare la richiesta di accesso.
Passaggio 3. AnyConnect è connesso.
Esempio di debug:
[SAML] consume_assertion: l'identificatore di un provider è sconosciuto a #LassoServer. In order to register a provider in a #LassoServer object, you must use the methods lasso_server_add_provider() or lasso_server_add_provider_from_buffer(). [L'identificativo di un provider è sconosciuto a #LassoServer. Per registrare un provider in #LassoServer, usare i metodi lasso_server_add_provider() o lasso_server_add_provider_from_buffer()]
Problema: in genere, indica che il comando saml idp [entityID] nella configurazione webvpn dell'ASA non corrisponde all'ID entità IdP trovato nei metadati dell'IdP.
Soluzione: verificare l'ID entità del file di metadati dell'IdP e modificare il comando saml idp [entity id] in modo che corrisponda a questo.
Esempio di debug:
[SAML] NotBefore:2017-09-05T23:59:01.896Z NotOnOrAfter:2017-09-06T00:59:01.896Z timeout: 0
[SAML] consume_assertion: asserzione scaduta o non valida
Problema 1. Ora ASA non sincronizzata con l'ora dell'IdP.
Soluzione 1. Configurare l'ASA con lo stesso server NTP usato da IdP.
Problema 2. Asserzione non valida tra l'ora specificata.
Soluzione 2. Modificare il valore di timeout configurato sull'appliance ASA.
Esempio di debug:
[Lasso] func=xmlSecOpenSSLEvpSignatureVerify:file=signatures.c:line=493:obj=rsa-sha1:subj=EVP_VerifyFinal:error=18:data do not match:signature do not match
[SAML] consume_assertion: il profilo non è in grado di verificare una firma sul messaggio
Problema: l'ASA non è in grado di verificare il messaggio firmato dall'IdP o non è presente alcuna firma da verificare per l'ASA.
Soluzione: controllare il certificato di firma IdP installato sull'appliance ASA per verificare che corrisponda a quanto inviato dall'IdP. Se confermato, verificare che la firma sia inclusa nella risposta SAML.
Esempio di debug:
[SAML] consume_assertion: il gruppo di destinatari dell'asserzione non è valido
Problema: il gruppo di destinatari definito dall'IdP non è corretto.
Soluzione: correggere la configurazione del gruppo di destinatari nel provider di identità. Deve corrispondere all'ID entità dell'ASA.
Esempio di debug: impossibile ricevere alcun debug dopo l'invio della richiesta di autenticazione iniziale. The user is able to enter credentials at IdP but IdP does not redirect to ASA. (Impossibile ricevere i debug dopo aver inviato la richiesta di autenticazione iniziale. L'utente può immettere le credenziali sul provider di identità, ma il provider di identità non lo reindirizza all'ASA.)
Problema: il provider di identità è configurato per l'URL del servizio consumer di asserzione errato.
Soluzione/i: verificare l'URL di base nella configurazione e accertarsi che sia corretto. Controllare i metadati dell'ASA con il comando show per accertarsi che l'URL del servizio Assertion Consumer Service sia corretto. Verificare che entrambi i parametri siano corretti sull'ASA, quindi controllare che l'URL del provider di identità sia corretto.
Esempio: dopo la modifica o la modifica di un URL Single Sign-On, il certificato dell'SP, SAML non funziona e invia le configurazioni precedenti.
Problema: l'appliance ASA deve rigenerare i metadati quando viene modificata una configurazione. Questa operazione non è automatica.
Soluzione: dopo aver apportato le modifiche, nel gruppo di tunnel interessato rimuovere e riapplicare il comando saml idp [entity-id].
La maggior parte delle procedure di risoluzione dei problemi SAML implica una configurazione errata che può essere rilevata quando si controlla la configurazione SAML o si eseguono i debug. debug webvpn saml 255 può essere utilizzato per risolvere la maggior parte dei problemi. Tuttavia, negli scenari in cui questo debug non fornisce informazioni utili, è possibile eseguire altri debug:
debug webvpn saml 255 debug webvpn 255 debug webvpn session 255 debug webvpn request 255
Revisione | Data di pubblicazione | Commenti |
---|---|---|
3.0 |
11-Aug-2023 |
PII rimossa.
SEO, Alt Text, Style Requirements, Machine Translation and Formatting aggiornati. |
1.0 |
19-Aug-2020 |
Versione iniziale |