Proxy di inversione HTTP DCC con OAM e OAM

In questo articolo viene illustrata la funzione DCC (Detached Credential Collector) HTTP Reverse Proxy introdotta nella release 11.1.2.2.0.

In una distribuzione in cui questa funzione è abilitata, un agente SSO WebGate:

In questa modalità, tutte le interazioni tra utenti/client e OAM vengono eseguite tramite WebGate DCC HTTP Reverse Proxy: nessun utente accederà più direttamente ai server OAM.

Questa nuova funzionalità DCC HTTP Reverse Proxy è diversa dalla precedente DCC per il login basato su HTTPBasic/FORM, in quanto non funziona per i flussi SSO Federation (modalità IdP o SP).

Panoramica

Questo articolo non include topologie contenenti proxy inversi HTTP o load balancer esposti ai vari componenti OAM (il server OAM stesso o gli agenti WebGate), ma include un caso d'uso verso la fine che indica come utilizzare il proxy inverso HTTP DCC nelle distribuzioni HA, frontate da un load balancer.

Autenticazione senza DCC

Il flusso di autenticazione senza DCC è il caso d'uso più comune, in cui l'utente viene reindirizzato dagli agenti SSO che proteggono le risorse nel dominio di sicurezza a OAM per richieste di verifica e autenticazione. Una distribuzione OAM tipica è costituita dalle entità riportate di seguito.

Il diagramma riportato di seguito descrive un ambiente di questo tipo.

Descrizione dell'immagine local_security_domain.jpg

Nel flusso di test utilizzare LDAPScheme OOTB come schema per proteggere le risorse del dominio di sicurezza locale.

Un flusso di autenticazione locale che utilizza LDAPScheme è costituito dai seguenti elementi:

  1. L'utente richiede l'accesso a una risorsa protetta, definita in OAM per essere protetta da LDAPScheme.

  2. L'agente SSO WebGate intercetta la richiesta HTTP, determina che l'utente deve essere autenticato e reindirizza l'utente al server OAM per l'autenticazione.

  3. L'utente accede al server OAM; il server avvia un flusso di autenticazione utilizzando LDAPScheme e visualizza la pagina di login

Descrizione dell'immagine local_authentication_flow.jpg

Dopo che l'utente ha immesso le proprie credenziali e ha fatto clic sul pulsante Login, si verifica quanto riportato di seguito.

  1. Il server OAM convalida le credenziali, crea una sessione per l'utente, imposta un cookie nel browser dell'utente e reindirizza l'utente alla risorsa protetta.

  2. L'utente richiede l'accesso alla risorsa. Questa volta l'agente SSO WebGate rileva che l'utente è autenticato e concede l'accesso alla risorsa

Descrizione dell'immagine local_security_workflow.jpg

DCC per il login basato su HTTP-Basic/FORM

Il DCC per il login basato su HTTP-Basic/FORM è stato introdotto nelle release precedenti di OAM 11g e consente a un amministratore di designare un agente SSO WebGate come entità che:

Nel flusso di test utilizzare DCCLDAPScheme basato su LDAPScheme OOTB, ma con l'URL della richiesta di verifica aggiornato per fare riferimento al DCC WebGate. Questo schema viene utilizzato per proteggere le risorse del dominio di sicurezza locale.

Un flusso di autenticazione locale che utilizza il file DCCLDAPScheme personalizzato è costituito dai seguenti elementi:

  1. L'utente richiede l'accesso a una risorsa protetta, definita in OAM per essere protetta da DCCLDAPScheme.

  2. L'agente SSO WebGate intercetta la richiesta HTTP, determina che l'utente deve essere autenticato e reindirizza l'utente alla pagina di login di DCC WebGate per l'autenticazione.

  3. L'utente accede alla pagina di login di DCC WebGate e fornisce le credenziali.

  4. Il DCC WebGate interagisce direttamente con il server OAM e con il protocollo NAP OAM per convalidare le credenziali e creare una sessione per l'utente. Il DCC WebGate reindirizza l'utente alla risorsa protetta.

  5. L'utente richiede l'accesso alla risorsa. Questa volta l'agente SSO WebGate rileva che l'utente è autenticato e concede l'accesso alla risorsa.

Proxy inverso HTTP DCC

Il proxy inverso HTTP DCC è stato introdotto nella release 11.1.2.2.0 di OAM e consente all'amministratore di configurare un agente SSO WebGate che funge da endpoint pubblico per il server OAM e OAM:

Nota: in pratica, DCC WebGate diventa l'endpoint pubblico per OAM e OAM e funge da proxy inverso HTTP, tramite il protocollo NAP OAM.

In questo test, dopo che OAM e WebGate sono stati configurati per DCC HTTP Reverse Proxy e utilizza LDAPScheme OOTB come schema per proteggere le risorse del dominio di sicurezza locale (lo schema non sarà stato modificato).

Nota: qualsiasi schema di autenticazione con un URL di richiesta di verifica contenente un percorso relativo può essere utilizzato in questa modalità DCC, ad esempio FederationScheme. Inoltre, la funzionalità IdP è compatibile con la modalità DCC specificata

Un flusso di autenticazione locale che utilizza LDAPScheme è costituito dai seguenti elementi:

  1. L'utente richiede l'accesso a una risorsa protetta, definita in OAM per essere protetta da LDAPScheme.

  2. L'agente SSO WebGate intercetta la richiesta HTTP, determina che l'utente deve essere autenticato e reindirizza l'utente a WebGate DCC per l'autenticazione.

  3. L'utente accede al DCC WebGate e inoltra la richiesta al server OAM. Il server avvia un flusso di autenticazione utilizzando LDAPScheme, restituisce una pagina di login da visualizzare al DCC WebGate e il DCC WebGate visualizza la pagina di login all'utente.

Descrizione dell'immagine local_authentication_flow_LDAP.jpg

Dopo che l'utente ha immesso le credenziali e ha fatto clic sul pulsante Login, si verifica quanto riportato di seguito.

  1. Il DCC WebGate invia la richiesta HTTP contenente le credenziali al server OAM che le convalida, crea una sessione per l'utente, crea un cookie e restituisce una risposta HTTP con il cookie e un comando di reindirizzamento al DCC WebGate; il DCC WebGate imposta il cookie nel browser dell'utente e reindirizza l'utente alla risorsa protetta.

  2. L'utente richiede l'accesso alla risorsa. Questa volta l'agente SSO WebGate rileva che l'utente è autenticato e concede l'accesso alla risorsa

Descrizione dell'immagine local_security_LDAPworkflow.jpg

Impostazione del proxy di inversione HTTP DCC

Impostazione iniziale di impostazione

I passi necessari per configurare una distribuzione OAM per DCC HTTP Reverse Proxy sono suddivisi in:

Per configurare un agente SSO WebGate specifico come DCC WebGate, effettuare le operazioni riportate di seguito.

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

  2. Passare a Access Manager, Agenti SSO.

  3. Cercare la voce WebGate già registrata.

  4. Fare clic e aprire la voce WebGate.

  5. Selezionare la casella Consenti operazione Collector credenziali.

  6. Nella casella Parametro definito dall'utente, aggiungere la riga seguente: TunneledUrls=/oam,/oamfed.

  7. Fare clic su Applica.

Descrizione dell'immagine Setting_DCC.jpg

Per aggiornare i criteri di autenticazione per i servizi OAM e OAM, effettuare le operazioni riportate di seguito.

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

  2. Passare a Access Manager, Domini applicazione.

  3. Cercare il dominio dell'applicazione correlato al DCC WebGate.

  4. Aprire il dominio dell'applicazione.

  5. Fare clic sulla scheda Risorse.

  6. Configurare la risorsa seguente come risorse pubbliche contrassegnando le risorse come non protette e impostando un criterio di autenticazione pubblico e un criterio di autorizzazione pubblica:

  7. Fare clic su Apply.

Descrizione dell'immagine Authentication_Policies.jpg

Per aggiornare la configurazione OAM in modo da specificare WebGate DCC come nuovo endpoint pubblico per OAM

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

  2. Passare a Configurazione, Impostazioni Access Manager.

  3. Nell'host del server OAM, immettere il nome host utilizzato per accedere a DCC WebGate tramite il browser.

  4. Nella porta del server OAM, immettere la porta utilizzata per accedere a DCC WebGate tramite il browser.

  5. Nel protocollo del server OAM, immettere il protocollo HTTP utilizzato per accedere a DCC WebGate tramite il browser.

  6. Una volta fatto, questi tre campi devono fare riferimento all'endpoint DCC WebGate HTTP/HTTPS.

  7. Fare clic su Applica.

Descrizione dell'immagine OAM_configuration.jpg

Una volta apportate le tre modifiche alla configurazione, OAM e OAM sono configurati per utilizzare il DCC WebGate come proxy inverso HTTP sul protocollo NAP.

Come test, se la federazione è stata abilitata nella sezione Servizi disponibili di configurazione della console di amministrazione OAM, è possibile accedere ai metadati OAM tramite l'URL WebGate DCC: http(s)://dcc-webgatehost:dcc-webgate-port/oamfed/idp/metadata e visualizzare i metadati SAML 2.0 per OAM. Nella configurazione, i metadati sono visualizzati senza dover riavviare alcun servizio e gli URL dei servizi Federation fanno riferimento alla posizione WebGate DCC e non al server OAM.

Nota: se è necessario aggiornare la versione ProviderID di Federation, è possibile eseguire questa operazione mediante la console di amministrazione OAM, la configurazione, la federazione e la modifica viene riportata nell'attributo entityID dei metadati.

Un esempio di metadati è entityID derivato dalla console di amministrazione OAM, dalla configurazione e dalla sezione Federazione:

<md:EntityDescriptor entityID="hUp://oam.acme.com
/oam/fed" ...>
  ...
  <md:IDPSSODescriptor>
    ...
    <md:ArtifactResolutionService ...
Location="hUp://dcc-webgate.acme.com:7777
/oamfed/idp/soap"/>
    <md:SingleLogoutService ... Location="hUp://dccwebgate.acme.com:7777/oamfed/idp/samlv20"/>     <md:SingleSignOnService ... Location="hUp://dccwebgate.acme.com:7777/oamfed/idp/samlv20"/>
    ...
  </md:IDPSSODescriptor>
  ...
</md:EntityDescriptor>

autenticazione locale

Nella distribuzione di test sono stati distribuiti i seguenti elementi:

LDAPScheme è l'OTB e non è stato modificato, in particolare il parametro URL richiesta di verifica non fa riferimento a WebGate DCC:

Descrizione dell'immagine Local_Authentication.jpg

Prima di configurare OAM, OAM e WebGate2 per il proxy inverso HTTP DCC, la richiesta di accesso alla risorsa protetta /cgi-bin/printenv su OHS1 ha comportato l'intercettazione della richiesta da parte di WebGate1 e il reindirizzamento del browser al server OAM per l'autenticazione:

Descrizione dell'immagine Access_Manager_Screen.jpg

Dopo aver immesso le credenziali corrette, OAM stava convalidando il nome utente o la password e reindirizzando il browser alla risorsa protetta.

Dopo aver configurato OAM, OAM e WebGate2 per il proxy inverso HTTP DCC, la richiesta di accesso alla risorsa protetta /cgi-bin/printenv in OHS1 comporta l'intercettazione della richiesta da parte di WebGate1 e il reindirizzamento il browser al DCC WebGate per l'autenticazione che inoltra la richiesta HTTP sul protocollo NAP al server OAM che rimanda al DCC WebGate una pagina da visualizzare:

Descrizione dell'immagine Protected_Access_Screen.jpg

Quando si immettono le credenziali corrette, si verifica quanto riportato di seguito.

OAM come fornitore di servizi

Questa modalità è leggermente diversa dallo use case di autenticazione locale. Le uniche differenze sono:

Nota: non è necessaria alcuna configurazione speciale per utilizzare FederationScheme con il proxy di inversione HTTP DCC.

FederationScheme è l'OTB e non è stato modificato, in particolare il parametro URL richiesta di verifica non fa riferimento a WebGate DCC:

Descrizione dell'immagine Authentication_Schemes.jpg

Quando viene richiesta la risorsa protetta, si verifica quanto riportato di seguito.

  1. L'utente richiede l'accesso a una risorsa protetta, definita in OAM per essere protetta da FederationScheme.

  2. L'agente SSO WebGate intercetta la richiesta HTTP, determina che l'utente deve essere autenticato e reindirizza l'utente a WebGate DCC per l'autenticazione.

  3. L'utente accede al DCC WebGate, che raggruppa le richieste HTTP e le invia tramite NAP al server OAM. Il server determina che l'utente deve essere sottoposto a richiesta di verifica tramite FederationScheme e che il modulo OAM/SP viene richiamato.

  4. OAM/SP crea una richiesta SAML e costruisce un URL di reindirizzamento 302 con il messaggio SAML; OAM raggruppa i dati e restituisce la risposta al DCC WebGate che restituisce la risposta HTTP al browser dell'utente.

  5. Il browser dell'utente viene reindirizzato a IdP con la richiesta SAML

Descrizione dell'immagine Protected_Resource_Request.jpg

Quando l'utente immette le proprie credenziali in IdP, si verifica quanto riportato di seguito.

  1. IdP crea un'asserzione SAML e reindirizza il browser dell'utente con il messaggio SAML al DCC WebGate (ovvero l'endpoint Federation per OAM, pubblicato nei metadati SAML 2.0).

  2. Il browser dell'utente presenta l'asserzione SAML al DCC WebGate, che raggruppa le richieste HTTP e le invia tramite NAP al server OAM, che a sua volta richiama il modulo OAM/SP per elaborare l'asserzione SAML.

  3. OAM/SP convalida l'asserzione SAML, OAM crea una sessione utente, crea un reindirizzamento 302 alla risorsa protetta e restituisce la risposta al DCC WebGate che restituisce la risposta HTTP al browser dell'utente.

  4. L'utente viene reindirizzato alla risorsa protetta

  5. WebGate L'agente SSO concede l'accesso

Descrizione dell'immagine local_security_Webgatedomain.jpg

OAM come IdP

In questo caso d'uso, OAM funge da provider di identità e DCC WebGate è l'endpoint pubblico per IdP. In questa impostazione:

Nota: non è necessaria alcuna configurazione speciale per utilizzare IdP con il proxy di inversione HTTP DCC.

Quando un utente avvia un SSO Federation dall'SP remoto, si verifica quanto riportato di seguito.

  1. L'utente avvia un'operazione SSO Federation nell'SP remoto.

  2. L'SP remoto crea una richiesta SAML e reindirizza l'utente all'endpoint SAML 2.0 IdP con la richiesta SAML: questo endpoint è il proxy inverso HTTP DCC WebGate, pubblicato nei metadati SAML 2.0 IdP.

  3. L'utente accede all'endpoint pubblico SAML 2.0 IdP in DCC WebGate con la richiesta SAML; DCC WebGate inserisce nel package la richiesta HTTP e il messaggio SAML e lo inoltra al server IdP tramite il protocollo NAP OAM.

  4. Il server IdP elabora la richiesta SAML, determina che l'utente deve essere autenticato tramite LDAPScheme, richiama internamente OAM per l'autenticazione, che a sua volta restituisce alla DCC WebGate la pagina di login da visualizzare; la DCC WebGate decodifica la risposta da OAM inviata tramite NAP e restituisce la risposta HTTP al browser dell'utente.

Descrizione dell'immagine local_security_FedSSO.jpg

Dopo la visualizzazione della pagina di login, si verifica quanto riportato di seguito.

  1. L'utente immette le proprie credenziali e fa clic sul pulsante Login.

  2. DCC WebGate raccoglie i dati in entrata, li raggruppa e li invia al server OAM tramite NAP.

  3. OAM convalida le credenziali, crea una sessione per l'utente e restituisce internamente l'identità dell'utente a IdP; il server di federazione crea un'asserzione SAML e crea una risposta contenente l'asserzione, la raggruppa e la restituisce a DCC WebGate, che a sua volta decodifica i dati, e invia la risposta HTTP con l'asserzione SAML al browser dell'utente.

  4. Il browser dell'utente invia la risposta SAML al provider di servizi, che convalida l'asserzione.

Descrizione dell'immagine local_security_DCCWebgate.jpg

Proxy di inversione HTTP DCC e HA

In una distribuzione HA, i passi necessari per configurare i vari componenti (Load balancer, OAM...) vengono ancora applicati quando viene utilizzata la funzione Reverse Proxy HTTP DCC.

Prendiamo come esempio la seguente distribuzione (altri tipi di topologie HA utilizza un approccio simile):

La topologia in questo esempio è simile alla seguente:

Descrizione dell'immagine local_security_Topology.jpg

Le fasi richieste in questo esempio si basano su quanto segue.

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.