Integrazione di ADFS 2.0 e 3.0 con OAM: prerequisito

Questo articolo descrive come integrare OAM con ADFS 2.0/3.0 per SSO Federation utilizzando il protocollo SAML 2.0. L'integrazione riguarda:

• Prerequisiti (questo articolo)

• ADFS 2.0/3.0 come IdP e OAM come SP

• ADFS 2.0/3.0 come SP e OAM come IdP

L'integrazione SAML 2.0 si basa su:

• Indirizzo e-mail che verrà utilizzato come formato NameID

• Il valore NameID contiene l'indirizzo di posta elettronica dell'utente

• L'associazione POST HTTP verrà utilizzata per inviare l'asserzione SAML all'SP

• Gli utenti esistono in entrambi i sistemi, ognuno con lo stesso indirizzo di posta elettronica in modo che possa essere utilizzato come attributo utente comune.

ADFS 2.0 è disponibile in Windows 2008 R2, mentre ADFS 3.0 è disponibile in Windows 2012 R2. Gli articoli mostrano gli screenshot per ADFS 3.0, mentre i passaggi documentati si applicano a entrambe le versioni.

Prerequisiti

Per eseguire l'integrazione con ADFS utilizzando il protocollo SAML 2.0, è necessario configurare OAM in modo che utilizzi HTTPS/SSL come endpoint. In caso contrario, ADFS non accetta i metadati SAML 2.0 di OAM durante la definizione del trust federativo.

Quando si integra ADFS come IdP con OAM come SP, occorre tenere conto dei seguenti punti:

• Per impostazione predefinita, ADFS IdP cifra l'asserzione SAML quando viene inviata all'SP utilizzando AES-256 e, per impostazione predefinita, il JDK utilizzato nella distribuzione OAM non può utilizzare una crittografia sicura come AES-256. Pertanto:

  • Configurare il JDK per una crittografia sicura

  • In alternativa, è necessario configurare ADFS IdP per disabilitare la cifratura

• Se ADFS IdP è configurato per l'autenticazione tramite l'autenticazione Basic HTTP o Windows Native Authentication, l'utente non potrà mai essere disconnesso come:

  • Una volta inserite, le credenziali di autenticazione Basic HTTP non possono essere rimosse dal browser, a meno che il browser non venga chiuso.

Nota: questa impostazione è valida per altri IdPs che utilizzano l'autenticazione Basic HTTP per chiedere conferma all'utente.

• Il browser è sempre collegato ad ADFS quando si utilizza l'autenticazione nativa di Windows.

• Per impostazione predefinita, ADFS richiede la firma dei messaggi mediante SHA-256, mentre per impostazione predefinita OAM utilizza SHA-1:

  • Configurare ADFS per utilizzare/accettare SHA-1

  • In alternativa, configurare OAM in modo che utilizzi SHA-256 per le firme

Infine, prima di integrare OAM e ADFS per SAML 2.0, è necessario scaricare i metadati per i due server.

Abilitazione di SSL

Esistono diversi modi per abilitare SSL sugli endpoint pubblici per OAM:

• Se un load balancer si trova accanto a OAM, è possibile abilitare/configurare SSL/HTTPS sul load balancer

• Se OHS fa fronte a OAM, OHS verrà configurato per SSL

• Se nessun componente si trova davanti a OAM, è possibile configurare il server WLS in cui è in esecuzione OAM per SSL/HTTPS

Dopo aver configurato il componente (Load balancer, OHS o WLS) per SSL, è necessario aggiornare la configurazione OAM in modo che faccia riferimento al nuovo endpoint come URL pubblico:

1. Andare alla console di amministrazione OAM: http(s)://oam-admin-host:oam-adminport/oamconsole

2. Passare a Configurazione, Impostazioni Access Manager

3. Impostare l'host del server OAM sul nome host dell'endpoint pubblico

4. Impostare Post server OAM sulla porta SSL dell'endpoint pubblico

5. Impostazione del protocollo del server OAM su https

6. Fare clic su Apply.

Descrizione dell'immagine Access_Manager_Settings.jpg

Nota: dopo aver apportato le modifiche, il recupero dei metadati SAML 2.0 di OAM contiene i nuovi URL https.

Cifrazione efficace

Come accennato, per impostazione predefinita, ADFS IdP cifra l'asserzione SAML quando lo invia all'SP utilizzando AES-256 che viene considerato da Java come una cifra sicura (in contrapposizione alla "forza normale" come AES-128, AES-192, 3DES...).

A causa di motivi di esportazione legali, non è possibile inviare JDK con crittografie avanzate abilitate in JCE: administrator/integrator/developer deve scaricare e installare il criterio Java Cryptography Extension (JCE) Unlimited Strength Jurisiction.

Per aggiornare i file dei criteri JCE Unlimited Strength Jurisiction per supportare una cifratura efficace come AES-256, eseguire le seguenti operazioni:

1. Determinare la versione Java principale utilizzata nella distribuzione OAM.

2. Individuare la cartella JDK utilizzata dall'esecuzione OAM: $JDK_HOME/bin/java -version.

3. La versione principale verrà stampata (6 o 7).

4. Scarica la politica JCE Unlimited Strength Jurisiction.

5. Se si utilizza JDK 7:

   • http://www.oracle.com/technetwork/java/javas%20/downloads/index.htm

6. Se si utilizza JDK 6:

   • http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archivedownloads-java-plat-419418.html

7. Decomprimere il contenuto del file ZIP scaricato in una cartella temporanea.

8. Copiare i file local_policy.jar e US_export_policy.jar estratti nella directory JDK seguente (questa operazione sovrascrive i file local_policy.jar e US_export_policy.jar presenti nella cartella): $JDK_HOME/jre/lib/security.

9. Riavviare i server WLS nel dominio WLS per applicare le modifiche.

Per configurare ADFS per disabilitare la cifratura durante l'invio dell'asserzione SAML a un SP, effettuare le operazioni riportate di seguito.

1. Andare al computer in cui è distribuito ADFS.

2. Se si utilizza ADFS 2.0, fare clic su Menu di avvio , Programmi , Strumenti di amministrazione , Moduli di Windows PowerShell.

3. Se si utilizza ADFS 3.0, fare clic su Avvia menu , Strumenti amministrativi , Modulo Active Directory per Windows PowerShell.

4. Eseguire il comando seguente (sostituire RP_NAME con il nome SP utilizzato per creare il partner in ADFS): set-ADFSRelyingPartyTrust –TargetName“RP_NAME” –EncryptClaims $False.

Logout ADFS

Il protocollo SAML 2.0 definisce un profilo di logout in cui ogni partner federativo coinvolto in un SSO federativo per la sessione dell'utente corrente viene avvisato dell'utente che ha eseguito la disconnessione. Ciò consente ai vari partner della federazione di terminare la sessione dell'utente nel proprio dominio SSO.

ADFS IdP offre diversi modi per autenticare l'utente quando viene eseguito un SSO Federation:

• Autenticazione basata su FORM dove

  • Il server visualizza una pagina di login

  • L'utente immette le credenziali e le sottomette

• Autenticazione Basic HTTP

  • Dove il server restituisce un codice di stato 401 al browser

  • Il browser raccoglie le credenziali dell'utente

  • Il browser presenta le credenziali al server ADFS

Nota: il browser conserva le credenziali e le fornisce al server ADFS ogni volta che il browser accede ad ADFS, finché il browser non viene chiuso.

• Autenticazione integrata di Windows in cui ADFS sfrutta lo stato di autenticazione dell'utente nell'ambiente Windows: in questo caso, poiché l'utente è già connesso a Windows, l'utente viene autenticato automaticamente senza alcuna interazione con l'utente.

Diamo un'occhiata all'effetto (o non-effetto) del logout SAML 2.0 a seconda di come l'utente viene autenticato:

• SP avvia un'operazione SSO Federation con ADFS IdP

• ADFS IdP deve autenticare/identificare l'utente

  • Se si utilizza l'autenticazione basata su FORM, ADFS visualizza una pagina di login e l'utente immette le proprie credenziali

  • Se si utilizza l'autenticazione Basic HTTP, ADFS restituisce il codice di risposta 401, il browser raccoglie le credenziali dall'utente e le presenta ad ADFS

  • Se si utilizza l'autenticazione integrata di Windows, il browser ottiene automaticamente un token Kerberos/NTLMSSP dal controller di dominio Windows/KDC che presenta al server ADFS. Nessuna interazione dell'utente.

• L'utente viene reindirizzato all'SP con un'asserzione SAML

• L'utente avvia il logout SAML 2.0 dall'SP

• SP reindirizza l'utente a ADFS IdP per il logout SAML 2.0

• ADFS cancella i cookie dal browser dell'utente (ma non memorizza nella cache le credenziali di autenticazione Basic HTTP se utilizzate in precedenza)

• Nello stesso browser, SP avvia un'operazione SSO Federation con ADFS IdP

• ADFS IdP deve autenticare/identificare l'utente

  • Se si utilizza l'autenticazione basata su FORM, ADFS visualizza una pagina di login e l'utente immette le proprie credenziali: l'utente viene sottoposto a richiesta di verifica e deve fornire le proprie credenziali.

  • Se si utilizza l'autenticazione Basic HTTP, ADFS restituisce il codice di risposta 401, il browser memorizza nella cache le credenziali raccolte in precedenza e le presenta automaticamente ad ADFS. Nessuna interazione degli utenti

  • Se si utilizza l'autenticazione integrata di Windows, il browser ottiene automaticamente un token Kerberos/NTLMSSP dal controller di dominio Windows/KDC che presenta al server ADFS. Nessuna interazione dell'utente.

Pertanto, se si utilizza l'autenticazione Basic HTTP o l'autenticazione Windows integrata come meccanismo di autenticazione in ADFS 2.0 IdP, dopo un logout, l'utente è ancora "collegato" in IdP e l'esecuzione di un nuovo SSO Federation non attiverà l'utente sottoposto a richiesta di verifica e comporta l'autenticazione automatica dell'utente in SP, dopo l'esecuzione dell'autenticazione SSO Federation.

Nota importante: il comportamento visto con il logout si applica anche ad altri IdPs (ad esempio OAM), che utilizzano l'autenticazione Basic HTTP come meccanismo di autenticazione

Metadati SAML 2.0

Per scaricare i metadati SAML 2.0 dal server ADFS 2.0/3.0, effettuare le operazioni riportate di seguito.

1. Aprire un browser.

2. Andare al servizio di pubblicazione dei metadati ADFS 2.0/3.0: https://adfs-host:adfs-port/FederationMetadata/2007-06/FederationMetadata.xml.

3. Salvare i metadati localmente utilizzando il pulsante Salva con nome nel browser.

Per scaricare i metadati SAML 2.0 da OAM:

1. Aprire un browser.

2. Andare al servizio di pubblicazione dei metadati OAM: http(s)://oam-runtime-host:oam-runtimeport/oamfed/idp/metadata o http(s)://oam-runtime-host:oam-runtimeport/oamfed/sp/metadata.

3. Salvare i metadati localmente utilizzando il pulsante Salva con nome nel browser.

Nota: assicurarsi di aver abilitato SSL in OAM prima di scaricare i metadati OAM, poiché i metadati contengono gli URL OAM.

SHA-256 e SHA-1

Dopo aver impostato Federation tra OAM e ADFS, è necessario effettuare le operazioni riportate di seguito.

• Configurare ADFS 2.0 per utilizzare/accettare SHA-1

• In alternativa, configurare OAM in modo che utilizzi SHA-256 per le firme

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

Integrating ADFS 2.0 and 3.0 with OAM Pre-requisite

F60452-01

September 2022

Copyright © 2022, Oracle and/or its affiliates.