Impostazione SAML 2.0: metadati e nessun metadato

Questo articolo copre i vantaggi dell'utilizzo dei metadati SAML 2.0 quando si stabilisce la fiducia tra due server federativi SAML 2.0, invece di fornire e immettere manualmente le informazioni digitando/copiando/incollando URL, certificati.

Definizione di un trust

La creazione di un trust nel contesto di SAML 2.0 WebSSO è l'atto di configurazione di un provider di identità SAML 2.0 e di un provider di servizi SAML 2.0 in modo che possano eseguire le operazioni SSO Federation.

Per stabilire la fiducia è necessario procedere come segue:

Creazione di una voce partner nel provider di identità SAML 2.0 che rappresenta il provider di servizi remoto con le informazioni riportate di seguito.
EntityID o ProviderID dell'SP, ovvero l'identificativo univoco che fa riferimento all'SP
URL del servizio consumer asserzioni in cui IdP reindirizza l'utente con l'asserzione SAML
Ciascuno di essi potrebbe avere un URL e un'associazione diversi, ad esempio urn:oasis:names:tc:SAML:2.0:bindings:HTTPArtifact, urn:oasis:names:tc:SAML:2.0:bindings:HTTPPOST o urn:oasis:names:tc:SAML:2.0:bindings:PAOS.
URL del servizio di logout in cui IdP reindirizza l'utente durante lo scambio di logout SAML 2.0
Ciascuno di essi potrebbe avere un'associazione diversa, ad esempio urn:oasis:names:tc:SAML:2.0:bindings:HTTPRedirect, urn:oasis:names:tc:SAML:2.0:bindings:HTTP- POST.
Ogni servizio può avere URL diversi per ricevere un messaggio LogoutRequest e un messaggio LogoutResponse
I certificati X.509 corrispondenti alla chiave privata utilizzata dall'SP per firmare i messaggi SAML 2.0 in uscita, ad esempio AuthnRequest,
Messaggi LogoutRequest/LogoutResponse o ArtifactResolve
I certificati X.509 corrispondenti alla chiave privata utilizzata dall'SP per decifrare i messaggi SAML 2.0 in entrata cifrati dall'elemento IdPs remoto con i certificati, ad esempio gli elementi Asserzione/NameID/Attribute all'interno di una risposta SSO
Creazione di una voce partner nel provider di servizi SAML 2.0 che rappresenta il provider di identità remoto con le informazioni riportate di seguito.
EntityID o ProviderID dell'IdP, ovvero l'identificativo univoco che fa riferimento a IdP
URL del servizio Single Sign-On in cui l'SP reindirizza l'utente con SAML AuthnRequest
Ciascuno di essi potrebbe avere un URL e un'associazione diversi, ad esempio urn:oasis:names:tc:SAML:2.0:bindings:HTTPRedirect, urn:oasis:names:tc:SAML:2.0:bindings:HTTPPOST o urn:oasis:names:tc:SAML:2.0:bindings:SOAP.
URL del servizio di logout in cui l'SP reindirizza l'utente durante lo scambio di logout SAML 2.0
Ciascuno di essi potrebbe avere un'associazione diversa, ad esempio urn:oasis:names:tc:SAML:2.0:bindings:HTTPRedirect, urn:oasis:names:tc:SAML:2.0:bindings:HTTP- POST.
Ogni servizio può avere URL diversi per ricevere un messaggio LogoutRequest e un messaggio LogoutResponse
I certificati X.509 corrispondenti alla chiave privata utilizzata da IdP per la firma dei messaggi SAML 2.0 in uscita, ad esempio i messaggi Asserzione, LogoutRequest/LogoutResponse o ArtifactResponse
I certificati X.509 corrispondenti alla chiave privata utilizzata da IdP per decifrare i messaggi SAML 2.0 in entrata cifrati da SP remoti con gli elementi (s), ad esempio l'elemento NameID all'interno di una richiesta di logout

In alto viene illustrata solo l'impostazione SSO Federation. Se i partner della federazione supportano altri servizi, ad esempio Autorità attributi e Richiedente attributo, è necessario scambiare più URL di servizio e informazioni sui certificati.

Processo manuale

Come si può vedere, ci possono essere molte informazioni scambiate tra gli amministratori responsabili della gestione dei server Federation e qualsiasi errore minore potrebbe causare la mancata impostazione dell'accordo Federation e causare errori di runtime.

Gli errori che potrebbero verificarsi a causa di un'istituzione di fiducia manuale potrebbero essere:

Usato certificato errato
Combinazione errata di URL/associazione del servizio, in cui ad esempio un URL del servizio consumer asserzioni utilizzato solo per l'associazione artifact viene utilizzato per l'associazione HTTP-POST
Typo negli URL
Specifica errata del nome host negli URL del servizio: poiché i cookie vengono utilizzati durante le operazioni SSO Federation. È primordiale utilizzare lo stesso nome host completamente qualificato, che è l'endpoint pubblico utilizzato dagli utenti per accedere ai server Federation. (Gli indirizzi IP o i nomi host non completamente qualificati generano errori)
Typo in ProviderIDs
URL mancanti

Tali errori si traducono in:

Verifica della firma o errori di decifrazione quando si utilizzano certificati errati Il server ha restituito un errore perché
- Il certificato non è valido
- URL mancanti per la funzionalità esercitata (ad esempio, URL di logout mancante)
- Sono stati utilizzati nomi host incoerenti (completamente qualificati, indirizzo IP e non completamente qualificati) ProviderID è sconosciuto, causato da un errore di battitura
- Loop infiniti, a causa dell'uso di nomi host incoerenti

Gli errori sopra elencati si verificano più di quanto le persone assumano, e questo porta al tempo trascorso inseguendo perché Federation SSO non funziona correttamente che quasi indica un errore di istituzione di Federation Trust.

Uso dei metadati SAML 2.0

Le specifiche SAML 2.0 definiscono il documento Metadati che contiene tutte le informazioni che un server deve conoscere sulla sua controparte per eseguire operazioni Federation con il partner remoto.

Le informazioni includono quanto segue.

URL servizi
Associazioni SAML per i servizi
Certificati per le operazioni di firma e cifratura
Quali messaggi verranno firmati (AuthnRequest, Asserzione)
Ruoli supportati da Federation Server (IdP, SP, Attribute Authority...)

I metadati SAML 2.0 vengono in genere generati dal server federativo stesso e vengono consumati dal server federativo del partner: pertanto non viene effettuato alcun intervento manuale per creare e utilizzare questo documento e quindi ridurre il numero di potenziali errori.

L'utilizzo dei metadati SAML 2.0 offre i vantaggi riportati di seguito.

Tutte le informazioni sono contenute in un unico documento
Il documento viene generato e utilizzato dai server federativi (le firme possono essere utilizzate per proteggere da eventuali manomissioni)
Nessuna informazione omessa
I dati sono coerenti (stessi nomi host utilizzati in tutti gli URL)

Ancora più importante, risparmia tempo riducendo la possibilità di errori durante lo stabilimento di fiducia della federazione, in modo che ci saranno meno possibilità di errori di runtime in seguito.

Altre risorse di apprendimento

Esplora altri laboratori su docs.oracle.com/learn o visita altri contenuti di formazione gratuiti sul canale Oracle Learning YouTube. Inoltre, visitare education.oracle.com/learning-explorer per diventare un Oracle Learning Explorer.

Per la documentazione sul prodotto, visitare Oracle Help Center.

Titolo e informazioni sul copyright

SAML 2.0 Setup Metadata vs No Metadata

F61884-01

September 2022