Integrazione applicazione (relying party)

casso127figsbrit
HID_application-integration
La finestra di dialogo Integrazione applicazione consente di configurare le modalità di gestione delle attività seguenti per il sistema di federazione:
  • Indirizzamento utenti all'applicazione di destinazione sul lato del relying party.
  • Mapping degli attributi di asserzione sugli attributi utilizzati dall'applicazione di destinazione.
  • Definizione degli account utente eseguita da un'applicazione di provisioning di terze parti.
  • Reindirizzamento degli utenti in caso di errore dell'autenticazione.
Configurazione dell'applicazione di destinazione (SAML, WSFED)
La sezione Applicazione di destinazione consente di specificare l'applicazione di destinazione e le modalità di indirizzamento utenti ad essa.
  • Modalità di reindirizzamento
    Specifica il metodo di reindirizzamento utente del relying party alla risorsa di destinazione.
    Valore predefinito
    : Nessun dato
    Le opzioni per questo campo sono le seguenti:
    • Nessun dato (impostazione predefinita)
      L'utente viene reindirizzato all'applicazione di destinazione mediante un codice HTTP 302 con un cookie di sessione, ma senza altri dati.
    • Dati cookie
      L'utente viene reindirizzato verso l'applicazione di destinazione mediante il reindirizzamento HTTP 302. Il reindirizzamento include un cookie di sessione e dati cookie aggiuntivi configurati a livello dell'entità di generazione delle asserzioni.
      Per SAML 1.1 e 2.0, l'abilitazione di questa opzione mostra il seguente campo aggiuntivo:
      URL di codifica dei dati del cookie di attributo
      Indica che l'attributo inviato nel cookie è codificato con l'URL. L'attributo presenta la codifica dell'URL perché i caratteri nell'URL seguono un solo scopo oltre a quello standard. L'impostazione è valida solo con la modalità di reindirizzamento Dati cookie.
      Se si specifica un carattere speciale nella tabella degli attributi dell'applicazione, selezionare questa opzione. Ad esempio, controllare questa impostazione per qualsiasi attributo con caratteri giapponesi. È possibile aggiungere i caratteri speciali dall'elenco a discesa oppure immetterli manualmente. Inoltre, è necessario che l'applicazione di destinazione decodifichi con l'URL il nome e il valore dell'attributo di applicazione ricevuto.
       
    • Cookie open-format
      L'utente viene reindirizzato verso l'applicazione di destinazione mediante il reindirizzamento HTTP 302 con un cookie open-format (nessun dato aggiuntivo). L'applicazione del cliente esegue la decrittografia del cookie crittografato per ottenere le informazioni utente.
      Se il relying party riceve un'asserzione con più valori di attributo, tutti i valori vengono trasferiti all'applicazione di destinazione.
    • Post cookie open-format
      L'utente viene reindirizzato verso l'applicazione di destinazione mediante il reindirizzamento HTTP 302 con un cookie open-format. Tuttavia, i dati vengono inviati in una richiesta HTTP-POST. Se si ritiene che i dati possano andare persi a causa delle restrizioni di lunghezza dei dati di cookie, selezionare questa opzione.
      Se si seleziona l'opzione Cookie open-format, l'interfaccia utente mostra i seguenti campi aggiuntivi:
      • Nome cookie open-format
        Specifica il nome del cookie open-format.
      • Trasformazione crittografia
        Indica l'algoritmo di crittografia utilizzato per crittografare il cookie open-format.
        Se si seleziona uno degli algoritmi compatibili con FIPS (algoritmi AES), è necessario che il sistema di destinazione utilizzi l'SDK di
        CA SiteMinder® Federation
        per il cookie. SDK deve trovarsi sullo stesso server dell'applicazione di destinazione.
        Se si utilizza .NET SDK per il cookie, utilizzare l'algoritmo di crittografia AES128/CBC/PKCS5Padding.
      • Password di crittografia
        Indica la password utilizzata per crittografare il cookie. I campi Password di crittografia e Conferma password sono obbligatori per il cookie open-format, mentre la password è facoltativa per il cookie legacy.
        Importante
        : se si fornisce una password per il cookie legacy, definire lo stesso valore per Java SDK di
        CA SiteMinder® Federation
        . La password consente a SDK di decrittografare il cookie. I valori vengono condivisi in una comunicazione fuori banda.
      • Conferma password
        Conferma la voce della password di crittografia.
      • Abilita HMAC
        Indica che viene generato un codice di autenticazione messaggi basato su hash (HMAC) mediante la password di crittografia nella finestra di dialogo.
        I codici di autenticazione messaggi (MAC) consentono di verificare l'integrità delle informazioni inviate tra due parti. Le due parti condividono una chiave segreta per il calcolo e la verifica dei valori di autenticazione del messaggio. Un codice di autenticazione messaggi basato su hash (HMAC) è un meccanismo MAC basato su funzioni di crittografia hash. I codici HMAC presentano un input di messaggio e una chiave segreta nota solo all'autore del messaggio e al destinatario desiderato.
        Se si seleziona la casella di controllo Abilita HMAC, il sistema genera un valore HMAC per il cookie open-format. Il valore HMAC viene posto all'inizio del valore del cookie open-format e crittografa la stringa intera. Il sistema inserisce la stringa crittografata nel cookie open-format, che viene quindi trasferito all'applicazione di destinazione.
      • Abilita cookie delimitato
        Specifica che il valore del cookie open-format è racchiuso tra virgolette. Questa specifica permette l'elaborazione del cookie in casi di inclusione di caratteri non supportati nel valore del cookie.
    • Intestazioni HTTP (solo SAML 1.1 e 2.0)
      L'utente viene reindirizzato all'applicazione di destinazione con intestazioni HTTP, ma senza altri dati. Il Policy Server può fornire più valori di attributo in un'intestazione singola separando ciascun valore da una virgola.
    • Conserva attributi
      L'utente viene reindirizzato mediante un codice HTTP 302 e un cookie di sessione, ma senza altri dati. Questa modalità indica inoltre al Policy Server di archiviare gli attributi estratti da un'asserzione nel session store.
      CA Single Sign-on
      può quindi fornire gli attributi come variabili di intestazione HTTP.
      per visualizzare l'opzione, abilitare il session store tramite la console di gestione del Policy Server.
       Se si seleziona Conserva attributi e l'asserzione contiene attributi vuoti, nel session store viene eseguita la scrittura di un valore NULL. Questo valore serve da segnaposto per l'attributo vuoto e viene trasferito a qualsiasi applicazione che utilizza l'attributo.
    • casso127figsbrit
      Reindirizzamento server
      Istruisce il sistema di federazione affinché passi gli attributi di intestazione e cookie ricevuti nell'asserzione all'applicazione di destinazione. Il servizio che utilizza le asserzioni raccoglie le credenziali utente per poi trasferire l'utente all'URL dell'applicazione di destinazione tramite il reindirizzamento lato server.
      Per utilizzare questa modalità, attenersi ai seguenti requisiti:
      • Tutti i file dell'applicazione di destinazione devono trovarsi nella directory principale dell'applicazione. Questa directory può essere:
        • Agente Web:
          web_agent_home
          \webagent\affwebservices
        • Secure Proxy Server Federation Gateway:
          sps_home
          \secure-proxy\Tomcat\webapps\affwebservices
           
      • L'URL di destinazione specificato deve essere
        relativo
        al contesto del servlet che utilizza l'asserzione. Il contesto è
        /affwebservices/public/
        e la radice di contesto è
        /affwebservices
        /, ovvero la directory principale dell'applicazione Federation Web Services. Non includere il contesto nell'URL. Ad esempio, l'URL di destinazione può essere
        /applications/doc1.html
        .
      • Definire realm, regole e policy per proteggere le risorse di destinazione. I realm devono contenere almeno il valore /affwebservices/ nel filtro delle risorse.
      • Installare un'applicazione Java o JSP personalizzata sul server utilizzato per l'applicazione Federation Web Services. L'Option Pack dell'agente Web o il Secure Proxy Server Federation Gateway installano Federation Web Services.
        La tecnologia di servlet Java consente alle applicazioni di passare le informazioni tra due richieste di risorsa con il metodo setAttribute dell'interfaccia ServletRequest.
        Il servizio che utilizza le asserzioni invia gli attributi utente all'applicazione di destinazione prima di reindirizzare l'utente alla destinazione. Il servizio invia gli attributi creando un oggetto dijava.util.HashMap. L'attributo contenente l'HashMap degli attributi SAML è Netegrity.AttributeInfo.
        Il servizio che utilizza le asserzioni passa due altri attributi Java.lang.String all'applicazione personalizzata:
        • L'attributo Netegrity.smSessionID rappresenta l'ID di sessione.
        • L'attributo Netegrity.userDN rappresenta il DN dell'utente.
      L'applicazione di destinazione legge questi oggetti dalla richiesta HTTP e utilizza i dati trovati negli oggetti mappa di hash.
  • Destinazione
    Specifica l'URL dell'applicazione di destinazione sul lato del relying party. Il valore immesso in questo campo diventa la risorsa di destinazione predefinita. Questo URL deve contenere un nome di dominio completo, a meno che non si selezioni Reindirizzamento server come la modalità di reindirizzamento. Per il reindirizzamento del server, l'URL di destinazione deve essere
    relativo
    al contesto del servlet che utilizza l'asserzione. Il contesto è
    /affwebservices/public/
    . Non includere il contesto nell'URL. Ad esempio, l'URL di destinazione può essere
    /applications/doc1.html
    .
    Se un proxy risiede all'interno del server con la risorsa di destinazione, immettere l'URL per l'host proxy. Il proxy gestisce tutte le richieste della federazione in locale. L'host proxy può essere qualsiasi sistema presente nel server di destinazione. L'host proxy può coincidere con
    Single Sign-On
    , purché l'accesso venga eseguito direttamente da Internet. Infine, durante il funzionamento di un proxy, l'URL specificato come destinazione deve passare tramite
    Single Sign-On
    . Ad esempio, se l'URL di base è fed.demo.com e la risorsa del server di back-end è mytarget/target.jsp, il valore per questo campo è http://fed.demo.com:5555/mytarget/target.jsp.
    Per SAML 2.0, è possibile lasciare questo campo vuoto se viene sostituito con il parametro di query RelayState. È possibile che il parametro di query RelayState sia compreso nell'URL di attivazione di Single Sign-On. Per abilitare la sostituzione, selezionare la casella di controllo Lo stato di inoltro sovrascrive la destinazione.
  • Timeout di inattività
    Indica il tempo di inattività di una sessione utente autorizzata prima che l'agente termini la sessione. Per evitare eventuali problemi quando gli utenti abbandonano la postazione di lavoro dopo aver eseguito l'accesso a una risorsa protetta, impostare il timeout di inattività su un intervallo breve. Se la sessione scade, gli utenti devono eseguire di nuovo l'autenticazione prima di accedere alle risorse.
    Questa funzione è attivata per impostazione predefinita. Per non specificare un timeout di inattività di sessione, deselezionare la casella di controllo. Il timeout di inattività di sessione predefinito è di un'ora.
    Nota
    la sessione scade entro un determinato intervallo di manutenzione dopo il valore di timeout di inattività specificato. Il numero di secondi specificati nella chiave di registro seguente determina il periodo di tempo:
    HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\
    CA Single Sign-on
    \CurrentVersion\SessionServer\MaintenancePeriod
    Ad esempio, impostare il timeout di inattività su 10 minuti. Impostare inoltre il registro di sistema per MaintenancePeriod sul valore predefinito. L'intervallo più lungo, prima della scadenza di una sessione a causa di inattività, è di 11 minuti (timeout + periodo di manutenzione).
    Per utilizzare questa funzionalità con lo schema di autenticazione di base, configurare l'agente Web per la richiesta di cookie.
    Fare attenzione ai punti seguenti:
    • Per le sessioni permanenti, abilitare il timeout di inattività e impostarlo su un valore maggiore rispetto a quello del periodo di convalida.
    • È possibile sostituire questa impostazione globale con l'attributo di risposta WebAgent-OnAuthAccept-Session-Idle-Timeout. Un valore pari a zero indica che la sessione non scade se inattiva.
    Valore predefinito
    : 60 secondi
    Ore
    Specifica il numero di ore per il periodo di timeout di inattività.
    Minuti
    Specifica il numero di minuti per il periodo di timeout di inattività.
    Timeout massimo
    Indica il tempo di attività massima di una sessione utente prima che sia richiesto dall'agente di rieseguire l'autenticazione.
    Questa funzione è attivata per impostazione predefinita. Per non specificare una durata massima di sessione, deselezionare la casella di controllo. La durata massima predefinita per una sessione è pari a due ore.
    • Ore
      Specifica il numero di ore per la durata massima di sessione.
    • Minuti
      Specifica il numero di minuti per la durata massima di sessione.
    Per utilizzare questa funzionalità con lo schema di autenticazione di base, configurare l'agente Web per la richiesta di cookie.
    Nota
    è possibile sostituire questa impostazione con l'attributo di risposta WebAgent-OnAuthAccept-Session-Max-Timeout.
  • Lo stato di inoltro sovrascrive la destinazione (solo SAML 2.0)
    (Facoltativo) Sostituisce il valore del campo di destinazione con il valore del parametro di query Stato di inoltro nella richiesta di avvio di Single Sign-On. Se selezionata, la casella di controllo offre un maggiore controllo sulla destinazione, in quanto il parametro di query Stato di inoltro consente di definire la destinazione in modo dinamico.
  • Convalida URL dominio di destinazione
    (Solo SAML 2.0) Indica al Policy di Server di confrontare il valore del campo Destinazione o la destinazione specificata nel parametro di query RelayState con il parametro ValidFedTargetDomain nell'Agent Configuration Object. Questa impostazione assicura che il relying party consenta l'accesso al dominio di destinazione richiesto.
  • Mantieni le variabili della sessione di autenticazione
    Consente di archiviare le informazioni da un'asserzione nel session store e di scriverle nel contesto di sessione. L'archiviazione delle informazioni di asserzione nel session store consente di utilizzare le informazioni per funzioni quali le risposte attive e le espressioni di policy. Se si seleziona questa casella di controllo, tra le informazioni di asserzione archiviate sono inclusi i valori NameID, NameIDFormat, ProviderID e AuthnContext.
    Questa impostazione è diversa dall'opzione Conserva attributi per la modalità di reindirizzamento all'applicazione di destinazione. Quando si mantengono le variabili della sessione di autenticazione, le informazioni sono disponibili per usi più complessi rispetto alle semplici intestazioni HTTP.
    Importante
    : per visualizzare la casella di controllo, abilitare il server di sessione tramite la console di gestione del Policy Server. Inoltre, selezionare la casella di controllo Usa sessione permanente nelle impostazioni SSO della configurazione di partnership.
  • Il parametro di query sovrascrive la destinazione predefinita (solo SAML 1.1)
    (Facoltativo) Sostituisce il valore del campo Destinazione con il valore del parametro di query di destinazione nella richiesta di avvio di Single Sign-On. Se selezionata, la casella di controllo offre un maggiore controllo sulla destinazione, in quanto il parametro di query consente di definire la destinazione in modo dinamico.
  • Periodo di validità cookie
    Indica la durata di validità del cookie open-format. Il periodo di validità viene inserito nel cookie in modo che l'applicazione di destinazione possa verificarne la validità prima di utilizzare i dati. È possibile impostare questo valore per le modalità di reindirizzamento con cookie open-format e intestazioni HTTP (quest'ultime utilizzano il cookie open-format). Per il cookie open-format, l'applicazione determina le azioni da eseguire alla scadenza del cookie. Per le intestazioni HTTP,
    CA Single Sign-on
    interrompe l'invio del cookie scaduto.
    Immettere l'intervallo espresso in ore, minuti e secondi. Il valore 00:00:00 indica che il cookie non scade.
Configurazione dell'applicazione di destinazione (OAuth)
La sezione Applicazione di destinazione consente di specificare l'applicazione di destinazione e le modalità di indirizzamento utenti ad essa.
  • Modalità di reindirizzamento
    Specifica il metodo di reindirizzamento utente del relying party alla risorsa di destinazione. I valori disponibili sono:
    • Nessun dato
      Specifica che l'utente viene reindirizzato all'applicazione di destinazione mediante un codice HTTP 302 con un cookie di sessione, ma senza altri dati.
    • Dati cookie
      Specifica che l'utente viene reindirizzato all'applicazione di destinazione mediante un codice HTTP 302 con un cookie di sessione e altri dati di cookie configurati sul lato dell'entità di generazione asserzioni. Se si seleziona questa opzione, è disponibile l'opzione seguente:
      • URL di codifica dei dati del cookie di attributo
        Indica che l'attributo inviato nel cookie è codificato con l'URL. L'indicazione di codifica dell'URL è necessaria perché i caratteri nell'URL seguono un solo scopo oltre a quello standard. L'impostazione è valida solo con la modalità di reindirizzamento Dati cookie. Se i dati di cookie contengono attestazioni multivalore, selezionare questa opzione.
        Se si specifica un carattere speciale nella tabella degli attributi dell'applicazione, selezionare questa opzione. Ad esempio, selezionare questa impostazione per qualsiasi attributo con caratteri giapponesi. È possibile aggiungere i caratteri speciali dall'elenco a discesa oppure immetterli manualmente. Inoltre, è necessario che l'applicazione di destinazione decodifichi con l'URL il nome e il valore dell'attributo di applicazione ricevuto.
    • Cookie open-format
      Specifica che l'utente viene reindirizzato verso l'applicazione di destinazione mediante il reindirizzamento HTTP 302 con un cookie open-format, senza altri dati. L'applicazione del cliente esegue la decrittografia del cookie crittografato per ottenere le informazioni utente.
      Se il relying party riceve un'attestazione con più valori di attributo, tutti i valori vengono trasmessi all'applicazione di destinazione.
    • Post cookie open-format
      L'utente viene reindirizzato verso l'applicazione di destinazione mediante il reindirizzamento HTTP 302 con un cookie open-format. Tuttavia, i dati vengono inviati in una richiesta HTTP-POST. Se si ritiene che i dati possano andare persi a causa delle restrizioni di lunghezza dei dati di cookie, selezionare questa opzione.
    Se si seleziona l'opzione Cookie open-format, l'UI visualizza i seguenti campi aggiuntivi:
  • Nome cookie open-format
    Specifica il nome del cookie open-format.
  • Trasformazione crittografia
    Indica l'algoritmo di crittografia da utilizzare per crittografare il cookie open-format.
    Se si seleziona uno degli algoritmi compatibili con FIPS (algoritmi AES), è necessario che il sistema di destinazione utilizzi l'SDK di sistema per il cookie. SDK deve trovarsi sullo stesso server dell'applicazione di destinazione.
    Se si utilizza .NET SDK per il cookie, utilizzare l'algoritmo di crittografia AES128/CBC/PKCS5Padding.
  • Password di crittografia
    Indica la password utilizzata per crittografare il cookie.
  • Conferma password
    Conferma la voce della password di crittografia.
  • Abilita HMAC
    Indica che viene generato un codice di autenticazione messaggi basato su hash (HMAC) mediante la password di crittografia nella finestra di dialogo.
    I codici di autenticazione messaggi (MAC) consentono di verificare l'integrità delle informazioni inviate tra due parti. Le due parti condividono una chiave segreta per il calcolo e la verifica dei valori di autenticazione dei messaggi. Un codice di autenticazione messaggi basato su hash (HMAC) è un meccanismo MAC basato su funzioni di crittografia hash. I codici HMAC presentano un input di messaggio e una chiave segreta nota solo all'autore del messaggio e al destinatario desiderato.
    Se si seleziona la casella di controllo Abilita HMAC, il sistema genera un valore HMAC per il cookie open-format. Il valore HMAC viene posto all'inizio del valore del cookie open-format e crittografa la stringa intera. Il sistema inserisce la stringa crittografata nel cookie open-format, che viene quindi trasferito all'applicazione di destinazione.
  • Abilita cookie delimitato
    Specifica che il valore del cookie open-format è racchiuso tra virgolette. Questa specifica permette l'elaborazione del cookie in casi di inclusione di caratteri non supportati nel valore del cookie.
  • Periodo di validità cookie
    Indica la durata di validità del cookie open-format. Il periodo di validità viene inserito nel cookie in modo che l'applicazione di destinazione possa verificarne la validità prima di utilizzare i dati. L'applicazione stabilisce le azioni da intraprendere alla scadenza del cookie.
    Immettere l'intervallo espresso in ore, minuti e secondi.
  • Intestazioni HTTP (solo modalità proxy)
    L'utente viene reindirizzato all'applicazione di destinazione con intestazioni HTTP, ma senza altri dati.
  • Mantieni attestazioni in Session Store
    L'utente viene reindirizzato mediante un codice HTTP 302 e un cookie di sessione, ma senza altri dati. Questa modalità indica inoltre al Policy Server di archiviare gli attributi estratti da un'asserzione nel session store. Il sistema può fornire quindi gli attributi come variabili di intestazione HTTP.
    Nota
    è possibile selezionare PersistClaims e l'asserzione contenente gli attributi lasciati vuoti. In tal caso, verrà eseguita la scrittura di un valore NULL nel session store. Questo valore serve da segnaposto per l'attributo vuoto e viene trasferito a qualsiasi applicazione mediante l'attributo.
  • Destinazione
    Specifica l'URL dell'applicazione di destinazione sul lato del relying party. Il valore immesso in questo campo diventa la risorsa di destinazione predefinita. L'URL deve contenere un nome di dominio completo.
    Se un proxy risiede all'interno del server con la risorsa di destinazione, immettere l'URL per l'host proxy. Il proxy gestisce tutte le richieste della federazione in locale. L'host proxy può essere qualsiasi sistema presente nel server di destinazione. L'host proxy può coincidere con lo stesso sistema, purché l'accesso al sistema venga eseguito direttamente da Internet. Infine, quando si utilizza un proxy, l'URL specificato come destinazione deve passare tramite il sistema di federazione. Ad esempio, se l'URL di base è fed.demo.com e la risorsa del server di back-end è mytarget/target.jsp, il valore per questo campo è http://fed.demo.com:5555/mytarget/target.jsp.
    Non compilare il campo se viene sostituito con il parametro di query RelayState. È possibile che il parametro di query RelayState sia compreso nell'URL di attivazione di Single Sign-On. Per abilitare la sostituzione, selezionare la casella di controllo Lo stato di inoltro sovrascrive la destinazione.
  • Timeout di inattività
    Indica il tempo di inattività di una sessione utente autorizzata prima che il sistema di federazione termini la sessione. Per evitare eventuali problemi quando gli utenti abbandonano la postazione di lavoro dopo aver eseguito l'accesso a una risorsa protetta, impostare il timeout di inattività su un intervallo breve. Se la sessione scade, gli utenti devono eseguire di nuovo l'autenticazione prima di accedere alle risorse.
    Questa funzione è attivata per impostazione predefinita. Per non specificare un timeout di inattività di sessione, deselezionare la casella di controllo. Il timeout di inattività di sessione predefinito è di un'ora.
    Nota
    per le sessioni permanenti, abilitare il timeout di inattività e impostarlo su un valore superiore rispetto a quello del periodo di convalida.
    Valore predefinito
    : 1 ora
    Ore
    Specifica il numero di ore per il periodo di timeout di inattività.
    Minuti
    Specifica il numero di minuti per il periodo di timeout di inattività.
    Timeout massimo
    Indica il tempo massimo di attività di una sessione utente prima che sia richiesta una nuova autenticazione.
    Questa funzione è attivata per impostazione predefinita. Per non specificare una durata massima di sessione, deselezionare la casella di controllo.
    Valore predefinito
    : 2 ore
    • Ore
      Specifica il numero di ore per la durata massima di sessione.
    • Minuti
      Specifica il numero di minuti per la durata massima di sessione.
  • Lo stato di inoltro sovrascrive la destinazione
    (Facoltativo) Sostituisce il valore del campo di destinazione con il valore del parametro di query Stato di inoltro nella richiesta di avvio di Single Sign-On. Se selezionata, la casella di controllo offre un maggiore controllo sulla destinazione, in quanto il parametro di query Stato di inoltro consente di definire la destinazione in modo dinamico.
  • Convalida URL dominio di destinazione
    Fornisce al sistema di federazione le istruzioni per confrontare il valore del campo Destinazione o la destinazione specificata nel parametro di query RelayState con il parametro ValidFedTargetDomain nell'Agent Configuration Object. Questa impostazione assicura che il relying party consenta l'accesso al dominio di destinazione richiesto.
Esecuzione del mapping sugli attributi di applicazione (SAML, WSFED)
La sezione Esegui il mapping sugli attributi di applicazione indica la modalità di mapping degli attributi di asserzione sugli attributi utilizzati dall'applicazione di destinazione.
  • Esecuzione del mapping sugli attributi di applicazione
    Indica che il mapping di attributo è abilitato. Se si seleziona la casella di controllo Enable Application Attributes (Abilita attributi applicazione), viene visualizzata la tabella Definizioni dell'attributo di applicazione. Questa tabella consente di specificare la modalità di mapping degli attributi di applicazione sugli attributi di asserzione.
    È necessario compilare le seguenti colonne nella tabella:
    Attributo di applicazione
    Elenca gli attributi utilizzati dall'applicazione di destinazione. Per impostazione predefinita, il nome dell'attributo di applicazione è uguale al nome dell'attributo di asserzione. È possibile modificare il nome dell'attributo di applicazione con qualsiasi nome richiesto dall'applicazione.
    Attributi di asserzione
    Specifica gli attributi dall'asserzione che si desiderano utilizzare come base per il mapping di un attributo di applicazione.
    Se si seleziona il pulsante <<, viene visualizzato il campo Aggiungi. Dall'elenco a discesa Aggiungi è possibile selezionare gli attributi di asserzione disponibili e i caratteri speciali da inserire nella regola di mapping.
Esecuzione del mapping sugli attributi di applicazione (OAuth)
La sezione Esegui il mapping sugli attributi di applicazione indica la modalità di mapping degli attributi di attestazione sugli attributi utilizzati dall'applicazione di destinazione.
  • Esecuzione del mapping sugli attributi di applicazione
    Indica che il mapping di attributo è abilitato. Se la casella di controllo Abilita mapping di attributo viene selezionata, verrà visualizzata la tabella Definizioni dell'attributo di applicazione. Questa tabella consente di specificare la modalità di mapping degli attributi di applicazione sugli attributi di asserzione.
    È necessario compilare le seguenti colonne nella tabella:
    Attributo di applicazione
    Elenca gli attributi utilizzati dall'applicazione di destinazione. Per impostazione predefinita, il nome dell'attributo di applicazione è uguale al nome dell'attributo di asserzione. È possibile modificare il nome dell'attributo di applicazione con qualsiasi nome richiesto dall'applicazione.
    Attributi di attestazione
    Specifica gli attributi dall'attestazione da utilizzare come base per il mapping di un attributo di applicazione.
    Se si seleziona il pulsante <<, viene visualizzato il campo Aggiungi. Dall'elenco a discesa Aggiungi, è possibile selezionare i caratteri speciali da inserire nella regola di mapping.
Provisioning utente (SAML, WSFED)
La sezione Provisioning utente consente di determinare le modalità di definizione degli account utente con un'applicazione di provisioning di terze parti.
  • Provisioning utente
    Questa sezione consente di determinare il funzionamento di un provisioning utente.
  • Tipo di provisioning
    Indica se un'applicazione di provisioning remota stabilisce account utente. Se il Policy Server utilizza un'applicazione di provisioning, selezionare Remoto.
    Impostazione predefinita
    : nessuna
    Opzioni
    : Nessuno, Remoto
    Nota
    è possibile selezionare Remoto come tipo di provisioning. In tal caso, configurare un'opzione di distribuzione per il trasferimento dei dati di asserzione all'applicazione di provisioning.
  • Opzione di distribuzione
    (Solo provisioning remoto) Definisce il reindirizzamento del browser con i dati di asserzione verso l'applicazione di provisioning. Il trasferimento dei dati di asserzione può essere eseguito mediante cookie o intestazioni HTTP.
    Opzioni:
    • Cookie open-format
      Distribuisce le informazioni di asserzione SAML in un cookie open-format. Se si utilizza un cookie open-format, l'applicazione di provisioning è in grado di leggere il cookie senza SDK. Se l'applicazione di provisioning utilizza .NET, è possibile installare .NET SDK sul server di provisioning e utilizzarlo per leggere il cookie open-format.
    • Post cookie open-format
      Distribuisce le informazioni di asserzione in un cookie open-format. I dati vengono tuttavia inviati in una richiesta HTTP-POST. Se si ritiene che i dati possano andare persi a causa delle restrizioni di lunghezza dei dati di cookie, selezionare questa opzione.
    • Intestazioni HTTP
      Il Policy Server trasferisce i dati di asserzione mediante intestazioni HTTP.
  • URL server di provisioning
    Identifica l'URL del server di terze parti che ospita l'applicazione di provisioning.
    Valore
    : un URL valido
Se si seleziona l'opzione Cookie open-format, completare i seguenti campi aggiuntivi:
Nome cookie open-format
Specifica il nome del cookie open-format.
  • Trasformazione crittografia
    Indica l'algoritmo di crittografia utilizzato per crittografare il cookie open-format.
  • Password di crittografia
    Indica la password utilizzata per crittografare il cookie. I campi Password di crittografia e Conferma password sono obbligatori per il cookie open-format, ma i parametri sono facoltativi per il cookie legacy.
    Importante: se si fornisce una password per il cookie legacy, usare lo stesso valore per Java SDK di
    CA SiteMinder® Federation
    . La password è necessaria affinché SDK esegua la decrittografia del cookie. I valori vengono condivisi in una comunicazione fuori banda.
  • Conferma password
    Conferma la voce della password di crittografia.
  • Abilita HMAC
    Indica che il sistema genera un codice di autenticazione messaggi basato su hash (HMAC) mediante la password di crittografia specificata nella finestra di dialogo.
    I codici di autenticazione messaggi (MAC) consentono di verificare l'integrità delle informazioni inviate tra due parti. Le due parti condividono una chiave segreta per il calcolo e la verifica dei valori di autenticazione del messaggio. Un codice di autenticazione messaggi basato su hash (HMAC) è un meccanismo MAC basato su funzioni di crittografia hash. I codici HMAC presentano un input di messaggio e una chiave segreta nota solo all'autore del messaggio e al destinatario desiderato.
    Se si seleziona la casella di controllo Abilita HMAC, il sistema genera un valore HMAC per il cookie open-format. Il valore HMAC viene posto all'inizio del valore del cookie open-format e crittografa la stringa intera.
    CA Single Sign-on
    inserisce la stringa crittografata nel cookie open-format, che viene quindi trasferito all'applicazione di destinazione.
  • Abilita cookie delimitato
    Specifica che il valore del cookie open-format è racchiuso tra virgolette. Questa specifica permette l'elaborazione del cookie in casi di inclusione di caratteri non supportati nel valore del cookie.
Periodo di validità cookie
Indica la durata di validità del cookie open-format. Il periodo di validità viene inserito nel cookie in modo che l'applicazione di destinazione possa verificarne la validità prima di utilizzare i dati. È possibile impostare questo valore per le modalità di reindirizzamento con cookie open-format e intestazioni HTTP (quest'ultime utilizzano il cookie open-format). Per il cookie open-format, l'applicazione determina le azioni da eseguire alla scadenza del cookie. Per le intestazioni HTTP, l'agente interrompe l'invio dei cookie scaduti.
Immettere l'intervallo espresso in ore, minuti e secondi.
Provisioning utente (OAuth)
La sezione Provisioning utente consente di determinare le modalità di definizione degli account utente con un'applicazione di provisioning di terze parti.
    • Tipo di provisioning
      Indica se un'applicazione di provisioning remota stabilisce account utente.
    • Opzione di distribuzione
      Definisce la modalità di reindirizzamento di un browser con dati utente all'applicazione di provisioning. Il sistema di federazione può trasmettere i dati utente mediante un cookie o intestazioni HTTP. Le opzioni disponibili sono elencate di seguito:
      • Cookie open-format
        Distribuisce le informazioni utente OAuth in un cookie open-format. Se si utilizza un cookie open-format, l'applicazione di provisioning è in grado di leggere il cookie senza SDK. Se l'applicazione di provisioning utilizza .NET, è possibile installare l'SDK .NET sul server di provisioning e utilizzarlo per leggere il cookie open-format.
      • Post cookie open-format
        Distribuisce le informazioni utente OAuth in un cookie open-format. I dati vengono tuttavia inviati in una richiesta HTTP-POST. Se si ritiene che i dati possano andare persi a causa delle restrizioni di lunghezza dei dati di cookie, selezionare questa opzione.
      Se si seleziona l'opzione Cookie open-format, completare i seguenti campi aggiuntivi:
    • Nome cookie open-format
      Specifica il nome del cookie open-format.
    • Trasformazione crittografia
      Indica l'algoritmo di crittografia per crittografare il cookie open-format.
    • Password di crittografia e Conferma password
      Indica la password utilizzata per crittografare il cookie. I campi Password di crittografia e Conferma password sono obbligatori per il cookie open-format.
    • Abilita HMAC
      Indica che viene generato un codice di autenticazione messaggi basato su hash (HMAC) mediante la password di crittografia nella finestra di dialogo.
      I codici di autenticazione messaggi (MAC) consentono di verificare l'integrità delle informazioni inviate tra due parti. Le due parti condividono una chiave segreta per il calcolo e la verifica dei valori di autenticazione dei messaggi. Un codice di autenticazione messaggi basato su hash (HMAC) è un meccanismo MAC basato su funzioni di crittografia hash. I codici HMAC presentano un input di messaggio e una chiave segreta nota solo all'autore del messaggio e al destinatario desiderato.
      Se si seleziona la casella di controllo Abilita HMAC, il sistema genera un valore HMAC per il cookie open-format. Il valore HMAC viene posto all'inizio del valore del cookie open-format e crittografa la stringa intera. Il sistema di federazione inserisce la stringa crittografata nel cookie open-format, che viene quindi trasferito all'applicazione di destinazione.
    • Abilita cookie delimitato
      Specifica che il valore del cookie open-format è racchiuso tra virgolette. Questa specifica permette l'elaborazione del cookie in casi di inclusione di caratteri non supportati nel valore del cookie.
Intestazioni HTTP (solo modalità proxy)
  • Se il sistema è in modalità proxy, il sistema trasmette i dati di asserzione in intestazioni HTTP.
  • URL server di provisioning
    Identifica l'URL del server di terze parti che ospita l'applicazione di provisioning.
  • Periodo di validità cookie
    Indica la durata di validità del cookie open-format. Il periodo di validità viene inserito nel cookie in modo che l'applicazione di destinazione possa verificarne la validità prima di utilizzare i dati. È possibile impostare questo valore per le modalità di reindirizzamento con cookie open-format e intestazioni HTTP. Le intestazioni HTTP utilizzano il cookie open-format. Per il cookie open-format, l'applicazione determina le azioni da eseguire alla scadenza del cookie. Per le intestazioni HTTP, il sistema interrompe l'invio dei cookie scaduti.
URL di reindirizzamento dello stato (SAML, WSFED)
La sezione URL di reindirizzamento dello stato consente di determinare la modalità di reindirizzamento dell'utente utilizzata da
CA Single Sign-on
in caso di errore dell'autenticazione.
È possibile che si verifichi un errore dell'autenticazione basata sull'asserzione nel sito che utilizza le asserzioni. In caso di errore dell'autenticazione, il sistema di federazione consente di reindirizzare l'utente verso applicazioni diverse (URL) per un'ulteriore elaborazione. Ad esempio, in caso di errore dell'operazione di rimozione dell'ambiguità utente, è possibile configurare
CA Single Sign-on
per reindirizzare l'utente verso un sistema di provisioning. Il sistema di provisioning può creare un account utente basato sulle informazioni trovate nell'asserzione SAML.
È possibile configurare una o più delle opzioni seguenti. Se si verifica la condizione della causa dell'errore,
CA Single Sign-on
reindirizza l'utente all'URL configurato.
Nota
: il reindirizzamento dell'errore viene eseguito solamente se il sistema è in grado di analizzare la richiesta correttamente e ottenere le informazioni necessarie per identificare l'entità di generazione asserzioni e il relying party.
Comprende le impostazioni seguenti:
  • Utente non trovato
    Identifica l'URL utilizzato per il reindirizzamento dell'utente in una delle condizioni seguenti:
    • Nel messaggio di Single Sign-On non è presente LoginID.
    • La directory utenti non contiene LoginID con la stringa di ricerca definita.
  • Messaggio SSO non valido
    Identifica l'URL al quale
    CA Single Sign-on
    reindirizza l'utente in una delle condizioni seguenti:
    • Il messaggio di Single Sign-On non è valido in base alle regole riportate negli schemi SAML.
    • Il consumatore richiede un'asserzione crittografata, che non è contenuta nel messaggio di Single Sign-On.
  • Credenziali utente non accettate (messaggio SSO)
    Identifica l'URL al quale
    CA Single Sign-on
    reindirizza l'utente nella maggior parte delle condizioni di errore. Sono escluse le condizioni di errore relative a un utente non trovato o al messaggio di Single Sign-On non valido. L'asserzione può essere valida, ma
    CA Single Sign-on
    non accetta il messaggio per vari motivi, quali:
    • Errore di convalida della firma digitale XML
    • Errore nell'operazione di decrittografia XML (SAML 2.0)
    • Errore di convalida delle condizioni XML, come un messaggio scaduto o una mancata corrispondenza dei destinatari.
    • Dichiarazione di autenticazione assente dalle asserzioni nel messaggio SSO.
  • 302 Nessun dato (valore predefinito)
    Reindirizza l'utente mediante un codice HTTP 302 con un cookie di sessione, ma senza altri dati.
  • HTTP Post
    Reindirizza l'utente mediante il protocollo HTTP POST.
URL di reindirizzamento aggiuntivi per SAML 2.0
Per un service provider SAML 2.0, è possibile specificare anche gli URL di reindirizzamento per errori HTTP 500, 400 e 405. Selezionare le opzioni di reindirizzamento che si desiderano abilitare, quindi immettere l'URL associato. Sono disponibili le seguenti opzioni:
  • Abilita reindirizzamento degli errori del server
    Server Error URL (URL dell'errore del server)
    : specifica l'URL di reindirizzamento utente in caso di errore del server HTTP 500. Un utente può riscontrare un errore 500 perché una condizione imprevista impedisce al server Web di eseguire la richiesta del client. Se si verifica questo errore, l'utente viene inviato all'URL specificato per un'ulteriore elaborazione.
    Esempio: http://www.redirectmachine.com/error_pages/server_error.html
  • Abilita reindirizzamento delle richieste non valide
    URL della richiesta non valido
    : specifica l'URL di reindirizzamento utente in caso di errore HTTP 400 - Richiesta non valida o HTTP 405 - Metodo non consentito. Un utente può riscontrare un errore 400 a causa di una richiesta non valida. Un utente può riscontrare un errore 405 anche quando il server Web non consente l'esecuzione di un metodo o di un'azione particolare. Se si verificano questi errori, l'utente viene inviato all'URL specificato per un'ulteriore elaborazione.
    Esempio: http://www.redirectmachine.com/error_pages/invalidreq_error.html
  • Abilita reindirizzamento degli accessi non autorizzati
    URL di reindirizzamento dell'accesso non autorizzato
    : specifica l'URL di reindirizzamento utente in caso di errore HTTP 403 - Accesso negato. È possibile riscontrare un errore 403 perché l'URL in una richiesta punta alla destinazione errata, ad esempio a una directory invece che a un file. Se si verifica questo errore, l'utente viene inviato all'URL specificato per un'ulteriore elaborazione.
    Esempio: http://www.redirectmachine.com/error_pages/unauthorized_error.html
URL di reindirizzamento dello stato (OAuth)
La sezione URL di reindirizzamento dello stato consente di determinare la modalità di reindirizzamento dell'utente utilizzata da
CA Single Sign-on
in caso di errore dell'autenticazione.
È possibile che si verifichi un errore dell'autenticazione basata sull'asserzione nel sito che utilizza le asserzioni. In caso di errore dell'autenticazione, Federation Standalone consente di indirizzare l'utente verso applicazioni diverse (URL) per un'ulteriore elaborazione. Ad esempio, in caso di errore dell'operazione di rimozione dell'ambiguità utente, è possibile configurare
CA Single Sign-on
per reindirizzare l'utente verso un sistema di provisioning. Il sistema di provisioning può creare un account utente basato sulle informazioni trovate nell'asserzione SAML.
È possibile configurare una o più delle opzioni seguenti. Se si verifica la condizione della causa dell'errore,
CA Single Sign-on
reindirizza l'utente all'URL configurato.
Comprende le impostazioni seguenti:
  • Errore del server remoto
    • OAuth 2.0
      Identifica l'URL utilizzato dal sistema per il reindirizzamento dell'utente nel caso in cui si verifichino i seguenti errori di OAuth 2.0:
      • Si è verificata una condizione imprevista che non consente al server di autorizzazione di completare la richiesta dell'utente.
      • Il server di autorizzazione non è in grado di elaborare la richiesta dell'utente a causa di temporaneo sovraccarico o manutenzione del server.
    • OAuth 1.0a
      Identifica l'URL utilizzato dal sistema per il reindirizzamento dell'utente nel caso in cui il server di autorizzazione restituisca un errore HTTP 500.
  • Messaggio di richiesta non valido
    • OAuth 2.0
      Identifica l'URL utilizzato dal sistema per il reindirizzamento dell'utente nel caso in cui si verifichino i seguenti errori di OAuth 2.0:
      • La sintassi della richiesta utente non è corretta.
      • L'ambito della richiesta utente non è valido, è sconosciuto o incorretto.
      • Il server di autorizzazione non supporta l'acquisizione del codice di autorizzazione con il metodo specificato.
    • OAuth 1.0a
      Identifica l'URL utilizzato dal sistema per il reindirizzamento dell'utente nel caso in cui il server di autorizzazione restituisca un errore HTTP 400 o 404.
  • Credenziali utente non accettate
    • OAuth 2.0
      Identifica l'URL di reindirizzamento dell'utente utilizzato da
      CA Single Sign-on
      Federation Standalone nel caso in cui si verifichino i seguenti errori di OAuth 2.0:
      • Il client non dispone dell'autorizzazione per richiedere il codice di autorizzazione con il metodo specificato.
      • Il server di autorizzazione ha rifiutato la richiesta.
    • OAuth 1.0a
      Identifica l'URL utilizzato dal sistema per il reindirizzamento dell'utente nel caso in cui il server di autorizzazione restituisca un errore HTTP 401 o 403.
  • 302 Nessun dato (valore predefinito)
    Reindirizza l'utente mediante un codice HTTP 302 con un cookie di sessione, ma senza altri dati.
  • HTTP Post
    Reindirizza l'utente mediante il protocollo HTTP POST.