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 reindirizzamentoSpecifica il metodo di reindirizzamento utente del relying party alla risorsa di destinazione.Valore predefinito: Nessun datoLe 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 cookieL'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 attributoIndica 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-formatL'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-formatL'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-formatSpecifica il nome del cookie open-format.
- Trasformazione crittografiaIndica 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 diCA SiteMinder® Federationper 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 crittografiaIndica 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 diCA SiteMinder® Federation. La password consente a SDK di decrittografare il cookie. I valori vengono condivisi in una comunicazione fuori banda.
- Conferma passwordConferma la voce della password di crittografia.
- Abilita HMACIndica 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 delimitatoSpecifica 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 attributiL'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-onpuò 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.
- casso127figsbritReindirizzamento serverIstruisce 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 essererelativoal 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.
- DestinazioneSpecifica 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 essererelativoal 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 conSingle Sign-On, purché l'accesso venga eseguito direttamente da Internet. Infine, durante il funzionamento di un proxy, l'URL specificato come destinazione deve passare tramiteSingle 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.Notala 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\MaintenancePeriodAd 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 secondiOreSpecifica il numero di ore per il periodo di timeout di inattività.MinutiSpecifica il numero di minuti per il periodo di timeout di inattività.Timeout massimoIndica 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.- OreSpecifica il numero di ore per la durata massima di sessione.
- MinutiSpecifica 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 autenticazioneConsente 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à cookieIndica 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-oninterrompe 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 reindirizzamentoSpecifica il metodo di reindirizzamento utente del relying party alla risorsa di destinazione. I valori disponibili sono:
- Nessun datoSpecifica che l'utente viene reindirizzato all'applicazione di destinazione mediante un codice HTTP 302 con un cookie di sessione, ma senza altri dati.
- Dati cookieSpecifica 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 attributoIndica 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-formatSpecifica 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-formatL'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.
- Nome cookie open-formatSpecifica il nome del cookie open-format.
- Trasformazione crittografiaIndica 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 crittografiaIndica la password utilizzata per crittografare il cookie.
- Conferma passwordConferma la voce della password di crittografia.
- Abilita HMACIndica 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 delimitatoSpecifica 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à cookieIndica 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 StoreL'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.
- DestinazioneSpecifica 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.Notaper le sessioni permanenti, abilitare il timeout di inattività e impostarlo su un valore superiore rispetto a quello del periodo di convalida.Valore predefinito: 1 oraOreSpecifica il numero di ore per il periodo di timeout di inattività.MinutiSpecifica il numero di minuti per il periodo di timeout di inattività.Timeout massimoIndica 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
- OreSpecifica il numero di ore per la durata massima di sessione.
- MinutiSpecifica 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 destinazioneFornisce 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 applicazioneIndica 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 applicazioneElenca 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 asserzioneSpecifica 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 applicazioneIndica 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 applicazioneElenca 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 attestazioneSpecifica 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 utenteQuesta sezione consente di determinare il funzionamento di un provisioning utente.
- Tipo di provisioningIndica se un'applicazione di provisioning remota stabilisce account utente. Se il Policy Server utilizza un'applicazione di provisioning, selezionare Remoto.Impostazione predefinita: nessunaOpzioni: Nessuno, RemotoNotaè 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-formatDistribuisce 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-formatDistribuisce 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 HTTPIl Policy Server trasferisce i dati di asserzione mediante intestazioni HTTP.
- URL server di provisioningIdentifica 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 crittografiaIndica l'algoritmo di crittografia utilizzato per crittografare il cookie open-format.
- Password di crittografiaIndica 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 diCA SiteMinder® Federation. La password è necessaria affinché SDK esegua la decrittografia del cookie. I valori vengono condivisi in una comunicazione fuori banda.
- Conferma passwordConferma la voce della password di crittografia.
- Abilita HMACIndica 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-oninserisce la stringa crittografata nel cookie open-format, che viene quindi trasferito all'applicazione di destinazione.
- Abilita cookie delimitatoSpecifica 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 provisioningIndica se un'applicazione di provisioning remota stabilisce account utente.
- Opzione di distribuzioneDefinisce 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-formatDistribuisce 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-formatDistribuisce 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.
- Nome cookie open-formatSpecifica il nome del cookie open-format.
- Trasformazione crittografiaIndica l'algoritmo di crittografia per crittografare il cookie open-format.
- Password di crittografia e Conferma passwordIndica la password utilizzata per crittografare il cookie. I campi Password di crittografia e Conferma password sono obbligatori per il cookie open-format.
- Abilita HMACIndica 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 delimitatoSpecifica 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 provisioningIdentifica l'URL del server di terze parti che ospita l'applicazione di provisioning.
- Periodo di validità cookieIndica 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 trovatoIdentifica 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 validoIdentifica l'URL al qualeCA Single Sign-onreindirizza 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 qualeCA Single Sign-onreindirizza 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, maCA Single Sign-onnon 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 PostReindirizza 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 serverServer 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 valideURL 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 autorizzatiURL 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.0Identifica 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.0aIdentifica 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.0Identifica 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.0aIdentifica 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.0Identifica l'URL di reindirizzamento dell'utente utilizzato daCA Single Sign-onFederation 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.0aIdentifica 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 PostReindirizza l'utente mediante il protocollo HTTP POST.