CSA: Sicurezza, password, LDAP, SSL, SSO, XSS (solo On Premise)

ccppmop1581
Utilizzare Amministrazione di sistema
Clarity
(CSA) per gestire la protezione, impostare le password dei server di database, abilitare l'SSL, effettuare l'integrazione con i server LDAP, configurare l'SSO e gestire gli URL esterni.
2
Gestione delle password di server di database
Utilizzare una password per proteggere ciascun server. Se il server è in un cluster, la password di server non concede l'accesso agli altri server nel cluster.
Per ridurre al minimo il rischio di accessi non autorizzati, modificare periodicamente la password su ciascun server.
  1. Modificare la password del server di database. Per ulteriori informazioni, consultare la documentazione del database di terze parti.
  2. Modificare la password di CSA.
  3. Dopo aver modificato la password del server di database, riavviare i servizi.
Crittografia delle password di server
Per proteggere un file di password di un server, è possibile crittografarlo. È possibile abilitare la crittografia AES delle password del server tramite il file
properties.xml
. Questo metodo di crittografia richiede l'utilizzo di una password diversa (chiave) durante la crittografia delle password in
properties.xml
. Proteggere questa chiave non crittografata.
La crittografia sul lato server è vantaggiosa in quanto richiede all'utente di proteggere solo un'unica chiave, memorizzata in un file accessibile dal server. La chiave è obbligatoria solo all'avvio del server. Dopo l'esecuzione di
Classic PPM
, è possibile proteggere ulteriormente il file di chiave con un altro livello di crittografia. Se il file si trova su un dispositivo di archiviazione rimovibile, è possibile scollegarlo e custodirlo in un posto sicuro.
Quando si abilita la crittografia delle password del server, qualsiasi password non crittografata in
properties.xml
viene automaticamente crittografata al prossimo accesso di
Classic PPM
al file. Se si abilita la crittografia e si modifica direttamente
properties.xml
, è possibile immettere password non crittografate. All'accesso successivo al file (ad esempio quando un servizio viene distribuito o avviato) verranno crittografate quelle password che non lo sono.
Per crittografare le password del server, creare un file di chiave valido accessibile al server e contenente i file di proprietà. Ciascun server deve avere accesso al file di chiave (sulla rete) o a una copia (sul disco locale del server).
Procedere come descritto di seguito:
  1. Accedere a CSA.
  2. Fare clic su
    Pagina iniziale
    ,
    Server
    .
  3. Fare clic sul nome del server.
  4. Fare clic sulla scheda
    Protezione
    .
  5. Scegliere un'opzione e fare clic su
    Salva
    .
    • Per abilitare la crittografia con una chiave di sistema, selezionare l'opzione
      Uso della chiave di sistema
      nel campo
      Crittografia password
      . Questa opzione utilizza una chiave codificata fornita insieme al prodotto. Questa è l'opzione meno sicura delle due. Se si è a conoscenza della chiave di un'installazione di
      Clarity
      , si viene a conoscenza delle chiavi di tutte le installazioni. Questa opzione scoraggia le osservazioni accidentali. Se un dipendente osserva per caso la chiave di sistema, non vedrà alcuna password. Tuttavia, un intruso che tenta di ottenere l'accesso al sistema e già ha ottenuto l'accesso ai file sul server, sarà probabilmente in grado di decrittografare le password.
    • Per abilitare la crittografia con un file di chiave personalizzato, selezionare l'opzione
      Uso del file di chiave personalizzato
      . Immettere il percorso completo e il nome del file di chiave personalizzato nel campo
      File di chiave
      . Questa opzione richiede la creazione di un file di chiave e lo rende accessibile a tutti i server che eseguono
      Classic PPM
      . Il file di chiave è opportunamente protetto in modo che un intruso non sia affatto in grado di decrittografare le password senza una chiave.
      In caso di crittografia delle password con un file di chiave personalizzato, modificare il file di chiave personalizzato. In caso contrario, le password andranno perse (non sarà possibile decrittografarle). In questo caso, sarà necessario immettere nuovamente le password.
Modifica delle password del server di database
Procedere come descritto di seguito:
  1. Modificare la password del server di database sul database.
    Per ulteriori informazioni, consultare la documentazione del database di terze parti.
  2. Modificare la password del server di database in CSA in modo che corrisponda alla nuova password immessa. Accedere a CSA.
  3. Interrompere i servizi Applicazione
    Clarity
    (app) e Background
    Clarity
    (bg) completando le azioni seguenti:
    1. Fare clic su Pagina iniziale, Tutti i servizi.
    2. Selezionare le caselle di controllo accanto ad Applicazione
      Clarity
      e Background
      Clarity
      , quindi fare clic su Interrompi.
      I servizi vengono interrotti.
  4. Fare clic su Pagina iniziale, Server.
  5. Fare clic su Proprietà, quindi sulla scheda Database.
  6. Nella sezione Connessione interna: Niku, compilare i campi seguenti:
    • Password
      Immettere una nuova password.
    • Conferma password
      Immettere nuovamente la password.
  7. Fare clic su Salva.
  8. Riavviare i servizi Background
    Clarity
    (bg) e Applicazione
    Clarity
    (app):
    1. Fare clic su Pagina iniziale, Tutti i servizi.
    2. Selezionare le caselle di controllo accanto a Background
      Clarity
      (bg) e Applicazione
      Clarity
      (app), quindi fare clic su Avvio.
Configurazione di SSL (Secure Sockets Layer) in Apache Tomcat
SSL è un protocollo per la trasmissione di dati tra i nodi. Il protocollo utilizza un metodo crittografico per proteggere i dati dall'accesso non autorizzato in base a due chiavi: una chiave pubblica nota a tutti e una chiave privata (segreta) nota solo al destinatario del messaggio.
  • Poiché i passaggi in questa sezione fanno riferimento a componenti di terze parti, il supporto è limitato.
  • Stabilire la posizione di installazione di SSL. Ad esempio, per migliorare le prestazioni, utilizzare un altro server e non il server applicazioni.
  • Il comando
    keytool
    di Java rappresenta un mezzo molto diffuso per la creazione e la gestione dei certificati SSL. Sono disponibili altri strumenti e comandi.
  • I passaggi elencati vengono applicati a molti ambienti, ma non a tutti. Inoltre, i passaggi potrebbero non essere corretti in alcuni ambienti. In particolare, è possibile utilizzare i certificati autofirmati (non acquistati da un fornitore certificato, ad esempio Verisign o Thawte). Questi certificati potrebbero richiedere più installazioni prima dell'installazione del certificato reale. I nomi dei certificati variano.
  • Seguire le istruzioni dal proprio fornitore di certificato SSL anziché affidarsi unicamente ai passaggi riportati in questa pagina. È possibile che i fornitori richiedano di modificare determinati passaggi o comandi.
  • Per scopi di test, utilizzare la chiave privata fornita con
    Classic PPM
    .
Quando si utilizza il protocollo HTTP con SSL, viene indicato come HTTPS.
Quando SSL è abilitato sul servizio dell'applicazione, tutti i dati trasmessi tra applicazioni client (come un browser Web oppure Open Workbench) vengono crittografati. I dati vengono crittografati prima di essere inviati e decrittografati prima di essere ricevuti. Senza la crittografia SSL, un'entità non autorizzata potrebbe leggere i dati e appropriarsi di dati sensibili, quali nomi utente e password.
Procedere come descritto di seguito:
I passaggi riportati in questa pagina si applicano solo alla prima installazione di
Classic PPM
. È inoltre possibile installare un certificato rinnovato alla scadenza di quello precedente.
4
4
Generare una coppia di chiavi pubblica/privata
Utilizzare il comando
keytool
di Java per generare una coppia di chiavi pubblica/privata e creare una richiesta di firma del certificato (CSR).
I passaggi riportati in questa pagina forniscono solo i parametri Java richiesti. Per ulteriori informazioni su tutti i parametri per i comandi Java, consultare il sito Web della documentazione di Oracle.
Prima di mettere un sistema in produzione, creare un file keystore per la chiave privata e distribuire il file a tutti i server applicazioni. Se si dispone già di un altro file keystore, è possibile utilizzare il file con
Classic PPM
.
Procedere come descritto di seguito:
  1. Aprire il server applicazioni di
    Classic PPM
    , aprire un prompt dei comandi e generare una coppia di chiavi pubblica e privata con l'immissione del comando seguente:
    keytool -genkey -keystore /<Clarity Home Directory>/config/.keystore -keyalg RSA -storepass keystore
  2. Definire i seguenti valori:
    • -genkey
      Questa opzione genera un keystore se non ne esiste alcuno. Il keystore contiene la chiave pubblica e quella pubblica provvisoria.
    • keystore
      Specifica il percorso e il nome del file keystore. Per impostazione predefinita, il keystore è denominato
      .keystore
      e si trova nella directory
      /<Clarity Home Directory>/config/
      .
    • keyalg
      Specifica l'algoritmo che si utilizza per generare la coppia di chiavi (RSA in questo esempio).
    • storepass
      La password utilizzata per proteggere il keystore (che deve contenere almeno sei caratteri). Questa password viene fornita a tutti i comandi che accedono al keystore.
  3. Quando richiesto, immettere le informazioni corrette sulla propria organizzazione.
  4. Premere
    Invio
    quando viene richiesto di immettere la password chiave. La password chiave e la password del keystore devono coincidere.
Per un certificato autofirmato, esportare il file. cer dalla chiave privata generata e passare alla procedura successiva. Non creare una richiesta di firma del certificato (CSR). Tale richiesta non è obbligatoria in questo caso. Per esportare il file, utilizzare il comando seguente:
keytool –export -file <file_name.cer> -keystore <ClarityHome/config/.keystore> -storepass keystore
Creazione di richieste di firma del certificato (CSR)
Per sistemi di produzione, sostituire il certificato di test con un certificato effettivo e attestato. Per ottenere un certificato attestato, creare una richiesta di firma del certificato (CSR) e inviarla a un'autorità di certificazione. L'autorità di certificazione genera un certificato effettivo e autentica la chiave pubblica. La richiesta di firma del certificato è una richiesta di certificato SSL basato sulle informazioni del sistema. Non è necessario installare la richiesta di firma del certificato. Installare il certificato reale fornito dal fornitore SSL in risposta alla propria richiesta di firma del certificato. Seguire sempre le istruzioni del proprio fornitore SSL. Sono spesso richiesti comandi specifici per l'installazione di certificati root o intermedi. I fornitori potrebbero richiedere l'installazione di altri certificati.
Procedere come descritto di seguito:
  1. Sul server applicazioni di
    Classic PPM
    , aprire un prompt dei comandi e immettere il comando seguente:
    keytool -certreq -keystore /<Clarity Home Directory>/config/.keystore -keyalg RSA -file ca_ppm.csr
  2. Quando viene richiesta una password, immettere la password predefinita (
    keystore
    ).
  3. Definire i seguenti valori:
    • -certreq
      Genera una richiesta di firma del certificato (CSR).
    • keystore
      Specifica il percorso e il nome del file keystore. Per impostazione predefinita, il keystore è denominato
      .keystore
      e si trova nella directory <Clarity Home Directory>/config/.
    • keyalg
      Specifica l'algoritmo (RSA) da utilizzare per generare la coppia di chiavi.
    • file
      Specifica il nome (ca_ppm.csr) del file di richiesta di firma del certificato generato.
  4. Tramite il browser Web, aprire il sito Web della propria autorità di certificazione e fornire i contenuti della richiesta di firma del certificato.
    Utilizzare il processo specificato dall'autorità di certificazione. Il file CSR viene fornito dalla propria autorità di certificazione.
  5. Copiare il nuovo certificato (ad esempio, ca_ppm.cer) fornito dal fornitore SSL sul server applicazioni di
    Classic PPM
    .
    La chiave privata non viene modificata.
  6. Eseguire il backup del file del keystore copiandolo in un altro volume. Durante l'attesa del certificato reale, non modificare il file keystore. Eventuali modifiche possono causare problemi durante l'importazione del certificato reale. Qualora non fosse possibile importare il certificato reale o il file venisse modificato, è possibile ricominciare. Non generare una nuova richiesta di firma del certificato o attendere la nuova copia del certificato reale. Se si dispone della copia di backup del file keystore, sarà possibile risparmiare tempo.
Installazione dei certificati
Se il fornitore SSL ha inviato un certificato, importare la risposta dell'autorità di certificazione e sostituire il proprio certificato autofirmato con una catena di certificati. L'ultimo della catena è il certificato emesso dall'autorità di certificazione per autenticare la chiave pubblica. Il certificato successivo nella catena autentica la chiave pubblica dell'autorità di certificazione.
È possibile importare i certificati per creare una catena di certificati. I certificati autofirmati o i certificati creati sui propri server di certificazione verranno forniti direttamente dall'autore del certificato stesso. L'autore dei certificati può impostare l'attendibilità o le catene in modo che il certificato SSL abbia lo stesso funzionamento dei certificati acquistati dai fornitori SSL. Importare tutti i certificati root, intermedi e di altro tipo, nonché i certificati forniti dal fornitore SSL in risposta alla propria richiesta di firma del certificato.
Utilizzare queste operazioni per creare un file keystore contenente la chiave privata associata al certificato firmato dalla propria autorità di certificazione.
Procedere come descritto di seguito:
  1. Sul server applicazioni di
    Classic PPM
    , aprire un prompt dei comandi e immettere il comando seguente:
    keytool -import -keystore /<Clarity Home Directory>/config/.keystore -keyalg RSA -file
    Clarity
    - Source.cer -trustcacerts
    Potrebbe essere necessario importare il certificato intermedio principale dell'autorità di certificazione nel file keystore prima di importare il certificato. Per ulteriori informazioni, consultare la documentazione dell'autorità di certificazione di terze parti.
  2. Immettere la password keystore e premere Invio.
  3. Immettere
    .
Distribuzione del file keystore a tutti i server applicazioni
Se si hanno più server con servizi di applicazione, distribuire il keystore a tutti i server.
Procedere come descritto di seguito:
  1. Accedere a CSA.
  2. Interrompere tutti i servizi completando le azioni seguenti:
    1. Fare clic su Pagina iniziale, Tutti i servizi.
    2. Selezionare tutti i servizi, quindi fare clic su Interrompi.
  3. Fare clic su Distribuisci, Distribuisci tutto.
  4. Selezionare la casella corrispondente a ogni server, quindi fare clic su Distribuisci.
  5. Riavviare tutti i servizi completando le azioni seguenti:
    1. Fare clic su Pagina iniziale, Tutti i servizi.
    2. Selezionare tutti i servizi, quindi fare clic su Avvio.
      Il file keystore viene distribuito ai server con servizi di applicazione.
Impostazione di posizione e password per il file keystore
Ripetere questi passaggi per ciascun server nel cluster.
Procedere come descritto di seguito:
  1. Accedere a CSA.
  2. Per modificare il server, fare clic sull'icona Proprietà.
  3. Fare clic sulla scheda Protezione.
  4. Compilare i seguenti campi, quindi fare clic su Salva:
    • Keystore SSL
      Immettere la posizione del file keystore. Se si lascia il campo vuoto, viene utilizzato il valore predefinito
      <Clarity Home Directory>/config/.keystore
      .
    • Password SSL
      Immettere la password del keystore (il valore predefinito è
      keystore
      ).
    • Conferma password
      Immettere nuovamente la password del keystore.
  5. Interrompere e riavviare tutti i servizi completando le azioni seguenti:
    1. Aprire Pagina iniziale e fare clic su Tutti i servizi.
    2. Fare clic sull'icona Seleziona tutto per selezionare tutti i servizi, quindi su Interrompi.
    3. Fare clic sull'icona Seleziona tutto per selezionare tutti i servizi, quindi su Avvio.
Abilitazione di SSL su ciascun server
L'impostazione di Gestione SSL determina il comportamento dell'applicazione circa SSL. L'impostazione contiene le seguenti opzioni:
  • Deriva da impostazioni porta (implicita)
    Dipende dall'attivazione o dalla disattivazione delle porte del server Web. Questa impostazione emula il comportamento SSL delle release precedenti (prima della versione 13.0).
  • SSL in uso ma elaborato esternamente (esterna)
    Specifica che l'utilità di bilanciamento del carico o altri endpoint precedenti terminano l'SSL all'esterno del server applicazioni.
  • Commutare a HTTPS solo per le pagine riservate (ibrida)
    Specifica che
    Classic PPM
    passa attivamente da HTTP a HTTPS per le pagine protette e non protette.
  • Compatibile con HTTP e HTTPS senza commutazione (entrambe)
    Specifica che HTTP e HTTPS sono entrambi attivati. Non tentare di passare da uno all'altro.
  • Compatibile solo con HTTPS (completa)
    Specifica tutti gli SSL. Tutti i dati sono crittografati. Se necessario, passare a SSL.
  • Supporta solo HTTP (nessuna)
    Non specifica alcun SSL. Non è presente alcun dato.
Questa procedura illustra la configurazione della Gestione SSL con l'opzione Compatibile solo con HTTPS. Se si seleziona Deriva da impostazioni porta come opzione di Gestione SSL, sono necessarie le seguenti impostazioni di campo aggiuntive per ogni istanza dell'applicazione:
  • Con supporto HTTP
    Deselezionare la casella di controllo.
  • Con supporto HTTPS
    Selezionare la casella di controllo.
Per abilitare SSL, completare questi passaggi per ciascun server:
Procedere come descritto di seguito:
  1. Accedere a CSA.
  2. Fare clic su Pagina iniziale, Server.
  3. Fare clic sul nome del server che si desidera configurare.
  4. Fare clic sulla scheda Proprietà.
  5. Fare clic sulla scheda Applicazione.
  6. Nella sezione Server applicazioni, completare i seguenti campi:
    • Gestione SSL
      Selezionare l'opzione denominata
      Compatibile solo con HTTPS
      .
  7. In ogni sezione Istanza applicazione
    che è associata al server, completare i seguenti campi:
    • Porta HTTPS
      Immettere la porta che si desidera utilizzare per il traffico HTTPS.
    • URL di accesso a HTTPS
      Immettere l'URL HTTPS (inclusa la porta).
      Esempio:
      https://ca_ppm.mycompany.com:8443
  8. Salvare le modifiche.
  9. Interrompere e riavviare i servizi di applicazione completando le azioni seguenti:
    1. Fare clic su
      Pagina iniziale
      ,
      Tutti i servizi
      .
    2. Selezionare ciascun servizio che si desidera interrompere, quindi fare clic su
      Interrompi
      .
    3. Selezionare ciascun servizio che si desidera riavviare, quindi fare clic su
      Avvia
      .
Abilitazione di SSL per pagine protette da password
È possibile abilitare SSL solo per le pagine che contengono password utenti. Con questa configurazione, gli utenti vengono automaticamente reindirizzati da pagine protette a pagine non protette nell'applicazione. Il reindirizzamento è reso possibile mediante l'abilitazione contemporanea di HTTP e HTTPS.
Con questa configurazione, entrambe le porte sui sistemi operativi UNIX devono avere un numero maggiore di 1024. In via eccezionale, è possibile utilizzare i normali numeri di porta se si utilizza un comando SUDO per l'avvio dei servizi con autorizzazioni di tipo root. Questa eccezione non viene utilizzata con le installazioni di bilanciamento del carico o le installazioni con proxy. In questi casi, utilizzare gli intervalli di porta personalizzati. Negli ambienti non di produzione è ancora possibile scegliere di non utilizzare le utilità di bilanciamento del carico (con offload SSL facoltativo). È comunque
possibile
utilizzare le porte tradizionali inferiori a 1024.
Procedere come descritto di seguito:
  1. Accedere a CSA.
  2. Fare clic su
    Pagina iniziale
    ,
    Server
    .
  3. Fare clic sull'icona
    Proprietà
    del server che si desidera configurare.
  4. Fare clic sulla scheda
    Applicazione
    .
  5. Nella sezione
    Server applicazioni
    , completare i seguenti campi:
    • Gestione SSL
      Selezionare l'opzione
      Commutare a HTTPS solo per le pagine riservate
      .
  6. In ogni sezione Istanza applicazione
    che è associata al server, completare i seguenti campi:
    • Con supporto HTTP
      Selezionare la casella di controllo.
    • Con supporto HTTPS
      Selezionare la casella di controllo.
    • Porta HTTPS
      Immettere la porta desiderata per il traffico HTTPS.
      Per UNIX, i numeri di porta HTTP e HTTPS devono essere maggiori di 1024 a meno che non si utilizzi un comando SUDO.
    • URL di accesso a HTTP
      Immettere l'URL HTTP (inclusa la porta).
      Esempio:
      http://ca_ppm.mycompany.com:8080
    • URL di accesso a HTTPS
      Immettere l'URL HTTPS (inclusa la porta).
      Esempio:
      https://ca_ppm.mycompany.com:8443
  7. Configurare più server.
  8. Interrompere e riavviare ciascun servizio di applicazione:
    1. Fare clic sulla scheda
      Servizi
      .
    2. Selezionare ciascun servizio che si desidera interrompere, quindi fare clic su
      Interrompi
      .
    3. Selezionare ciascun servizio che si desidera riavviare, quindi fare clic su
      Avvia
      .
Attivazione di una connessione JDBC protetta tra l'applicazione
Clarity
e i server di database su host separati con SSL
Per garantire la conformità tra i criteri di protezione delle informazioni e altri framework, si consiglia di crittografare le applicazioni quali
Clarity
in migrazione verso AWS, Azure e altri server cloud a livello di applicazione e database.
È possibile definire alcuni parametri nella stringa di connessione al database nel file delle proprietà di
Clarity
per l'attivazione di SSL.
  1. Attenersi alla procedura riportata precedentemente per installare il certificato SSL su Oracle o SQL Server.
  2. Aggiungere i seguenti attributi all'elemento di database del file delle proprietà di
    Clarity
    :
    1. Aggiungere
      useURL = "true"
    2. Nell'attributo
      URL
      , aggiungere
      encryptionmethod=SSL
      come illustrato di seguito:
    <database id="Niku" vendor="mssql" serviceName="niku" password="xxxxxx" upgradeStatus="upgradeNotNeeded" schemaName="niku" username="xxxxxxx" host="sqlservere.clarity.com" url="jdbc:clarity:sqlserver://sqlserver.clarity.com:1433;DatabaseName=NNNNN_STAGE;InsensitiveResultSetBufferSize=0;ProgramName=Clarity;encryptionmethod=ssl;" driver="com.ca.clarity.jdbc.sqlserver.SQLServerDriver" instanceName="" serviceId="NNNNN_STAGE" jndiDatabaseId="jdbc/NikuDS" useURL="true"/>
  3. È supportata anche la crittografia di rete Oracle. Aggiungere il seguente parametro all'URL JDBC:
    DataIntegrityLevel=required
  4. Aprire il file
    sqlnet.ora
    e verificare la presenza delle seguenti impostazioni di parametro:
    SQLNET.ENCRYPTION_SERVER = required
    SQLNET.CRYPTO_CHECKSUM_SERVER = required
    L'impostazione
    required
    abilita la crittografia o il servizio di integrità e disabilita la connessione nel caso in cui il lato client non sia abilitato per il servizio di protezione. Si tratta dell'impostazione predefinita per le distribuzioni del database sul servizio di database cloud.
  5. Riavviare i servizi.
Per verificare che la connessione di rete sia crittografata per SSL, eseguire una tracciatura di pacchetto wireshark e filtrarla con l'indirizzo IP del database SQL Server e il numero di porta definiti nella stringa di connessione.
Configurazione di
Classic PPM
per l'utilizzo di offloader SSL
In un servizio di applicazione SSL, i dati trasmessi tra applicazioni client vengono crittografati prima dell'invio e decrittografati prima della ricezione. La crittografia dei pacchetti SSL può causare un rallentamento delle prestazioni sui server applicazioni. Per gestire SSL, utilizzare un'utilità di bilanciamento del carico o un server proxy anziché il server applicazioni.
Se si utilizza un offloader SSL esterno, ad esempio un'utilità di bilanciamento del carico o un proxy inverso, l'offloader SSL crittografa il traffico HTTP per
Classic PPM
. L'offloader comunica con il client tramite HTTPS. Questa impostazione può migliorare le prestazioni ma richiede alcune configurazioni nel dispositivo offloader e in
Classic PPM
.
Assicurarsi che l'offloader SSL utilizzato disponga di una funzione di riscrittura dell'URL abilitata.
Procedere come descritto di seguito:
  1. Accedere a CSA.
  2. Fare clic su
    Pagina iniziale
    ,
    Server
    .
  3. Fare clic sull'icona
    Proprietà
    per il server che si desidera configurare.
  4. Fare clic sulla scheda
    Applicazione
    .
  5. Nella sezione
    Server applicazioni
    , completare i seguenti campi:
    • Gestione SSL
      Selezionare l'opzione denominata
      SSL in uso ma elaborato esternamente
      .
  6. Per ciascuna istanza dell'applicazione diversa da quella del server applicazioni di
    Classic PPM
    , completare le impostazioni seguenti:
    • Con supporto HTTP
      Specifica che per comunicare viene utilizzato HTTP. Selezionare la casella di controllo.
    • URL di accesso a HTTP
      Indica l'URL da utilizzare per il traffico tra
      Classic PPM
      e un client. Un offloader SSL diventa il front-end di
      Classic PPM
      in modo analogo a un'utilità di bilanciamento del carico che è il front-end in un ambiente di server multipli. Poiché l'URL dell'offloader SSL è protetto, immettere un URL HTTPS in questo campo utilizzando il formato seguente:
      https://<hostname>:CA Portal.
    • Con supporto HTTPS
      Questa casella di controllo non si applica quando si utilizza un offloader SSL. Deselezionare la casella di controllo.
  7. Salvare le modifiche.
Configurazione di
Clarity
per l'utilizzo di HTTPS
Le operazioni riportate di seguito sono destinate agli ambienti
Clarity
non cluster.
In questa procedura, vengono generati un keystore e una richiesta di certificato. Dopo avere importato i certificati, apportare le modifiche necessarie in CSA.
Per un'implementazione dell'architettura con bilanciamento del carico, abilitare SSL con l'installazione del certificato sull'utilità di bilanciamento del carico e non sui server applicazioni. Nella scheda
Applicazione
, modificare il valore del campo
Gestione SSL
in
SSL in uso ma elaborato esternamente
.
Procedere come descritto di seguito
:
  1. Accedere al server che ospita
    Clarity
    .
  2. Accedere a una directory per archiviare la chiave privata. Ad esempio:
    C:\ppm150101
  3. Preparare le risposte alle richieste descritte nel Passaggio 5 in anticipo.
  4. Generare un keystore con il comando seguente: "keytool -genkey -keystore C:\ppm15101\keystore.jks -keyalg RSA -storepass changeit"
    Tenere presente che "Keystore.jks" è il nome del keystore, la cui password è "changeit". Quando viene eseguito il comando, modificare la password con una più sicura.
  5. Vengono visualizzati alcuni prompt per il completamento dei dettagli sul server e l'organizzazione. Utilizzare le informazioni preparate precedentemente nel passaggio 3. Le autorità di certificazione possono fornire tutti i dettagli necessari. Contattarle nel caso in cui non sia possibile rispondere ai prompt indipendentemente.
  6. Quando vengono richiesti il
    nome e il cognome
    , immettere il nome completo del server senza che
    http://
    o
    https://
    siano contenuti nel nome.
  7. Generare una richiesta di certificazione:
    keytool -certreq -keystore C:\ppm15101\keystore.jks -keyalg RSA -file myRequest0.cer
  8. Per ottenere un certificato del server, inviare il file all'Autorità di certificazione.
  9. Prima di eseguire l'importazione del keystore, accertarsi che i certificati siano pronti:
    1. certificato del server
    2. certificato intermedio
    3. certificato radice
      (Verificare la presenza dei certificati intermedio e radice con l'Autorità di certificazione)
  10. Importare il certificato radice (sostituire il nome del keystore, il percorso, il nome e la patch di certificato e altri parametri):
    keytool -import -keystore C:\ppm15101\keystore.jks -keyalg RSA -file root.cer -trustcacerts -alias root
  11. Importare il certificato intermedio:
    keytool -import -keystore C:\ppm15101\keystore.jks -keyalg RSA -file intermediate.cer -trustcacerts -alias intermediate
  12. Importare il certificato del server:
    keytool -import -keystore C:\ppm15101\keystore.jks -keyalg RSA file server.cer -trustcacerts -alias server
Modifiche a CSA
  1. Accedere a CSA e fare clic sulla scheda
    Protezione
    .
  2. Nel campo
    Keystore SSL
    , immettere il percorso completo al keystore.
  3. Compilare i campi
    Password SSL
    e
    Conferma password
    .
  4. Fare clic sulla scheda
    Applicazione
    .
  5. Modificare il campo
    Gestione SSL
    con
    Compatibile con HTTP e HTTPS senza commutazione
    .
  6. Nella sezione
    Istanza applicazione
    , selezionare
    Con supporto HTTPS
    .
  7. Modificare i valori del campo Porta HTTPS con un numero assegnato all'applicazione
    Clarity
    (dipendente dall'organizzazione). Ad esempio, il numero di porta può essere 8043.
  8. Modificare il valore del campo URL di accesso a HTTPS con il nome esatto del server fornito durante la generazione del keystore.
  9. Riavviare il servizio applicazione.
  10. Verificare che HTTPS sia attivo utilizzando HTTPS (utilizzare il numero di porta e l'URL corretti. Ad esempio, l'URL potrebbe essere https://servername.organization.com:8043/).
  11. Modificare il campo Gestione SSL in Compatibile solo con HTTPS.
  12. Riavviare nuovamente il servizio applicazione.
Se un certificato è stato importato in modo erroneo e si desidera eliminarlo, è possibile utilizzare un comando simile al seguente: "keytool -keystore c:\ppm15101\keystore.jks -alias root -delete"
Un altro comando utile per inserire tutti i certificati in un keystore è: "keytool -keystore c:\ppm15101\keystore.jks -list" and to turn verbose on, use "keytool -keystore c:\ppm15101\keystore.jks -list -v"
Infine, i percorsi indicati sono destinati a un sistema operativo Windows. Modificarli nel percorso di definizione della convenzione Linux nel caso in cui l'applicazione sia stata generata su tale sistema operativo. Gli elementi diversi dal percorso restano invariati.
Integrazione di
Classic PPM
con LDAP (Lightweight Directory Access Protocol)
Un'interfaccia LDAP (Lightweight Directory Access Protocol) può essere utile per autorizzare l'accesso utente a tutte le applicazioni. Un server di directory centrale controlla l'accesso consentendo agli utenti di utilizzare un nome utente e una password per tutte le applicazioni. Sono supportate le seguenti opzioni:
  • Il protocollo LDAP v2 (semplice) utilizza un piccolo sottoinsieme di funzionalità LDAP, tra cui autenticazione (non crittografata o SSL), binding e ricerca.
  • Controllo LDAP v3 per risultati di paging come definito in RFC 2696.
Per sincronizzare gli utenti tra il server di directory e
Classic PPM
, gli utenti vengono recuperati dal server di directory in batch. Le impostazioni della configurazione LDAP di
Classic PPM
specificano la dimensione del batch.
I cookie basati sulla sessione contengono un token utilizzato per accedere ai dati di sessione. Il token viene mantenuto nella cache per ambienti di applicazione singoli o in un database per ambienti clusterizzati. È necessario che il browser Web dell'utente accetti i cookie da
Classic PPM
, basati sulla sessione, in modo da non essere scritti nel disco. Quando l'utente si disconnette, le informazioni di sessione nel database e nella cache che corrispondono ai cookie vengono eliminate.
Dall'integrazione di
Classic PPM
con un server LDAP, è possibile trarre i vantaggi seguenti:
  • Semplificazione dell'amministrazione di nome utente e password. Al dipartimento IT è richiesta solo la gestione di una coppia nome utente e password per utente.
  • Supporto dell'autenticazione. Al dipartimento IT è richiesto il supporto di una sola posizione in cui gli utenti possono riscontrare problemi di autenticazione.
  • Miglioramento dell'usabilità. Gli utenti devono solo ricordarsi il nome utente e la password.
  • Miglioramento della gestione utenti. È possibile archiviare il nome utente e le informazioni di posta elettronica in LDAP.
  • Miglioramento della protezione. L'uso di un nome utente e di una password facilita l'utilizzo di password complesse e la modifica a intervalli più frequenti. La probabilità di scegliere una password familiare è ridotta quando c'è solo una password da ricordare.
Il processo LDAP - Sincronizza utenti nuovi e modificati sincronizza le voci LDAP. Quindi il processo archivia la data e l'ora dell'ultima volta in cui il processo è stato eseguito correttamente e le informazioni nella tabella di database MN_DIRECTORY_SERVERS. Durante il successivo processo eseguito in background, il processo sincronizza le voci. Il processo sincronizza solo le voci create di recente o le voci utente modificate in cui l'indicatore di data e ora è maggiore rispetto al valore rilevato nella proprietà CMN_DIRECTORY_SERVERS.LAST_SYNC_DATE.
  • Classic PPM
    non verifica se un utente in un gruppo o in una ricerca specificata da CSA è attivo o non attivo in LDAP.
    Classic PPM
    verifica solo se un utente è presente in un gruppo di
    Classic PPM
    o se un attributo di ricerca è presente in
    Classic PPM
    .
  • Classic PPM
    non è in grado di riconoscere i gruppi nidificati in LDAP. Prima di eseguire il processo
    LDAP - Sincronizza utenti nuovi e modificati
    o
    LDAP - Sincronizza utenti obsoleti
    , verificare che gli utenti siano associati a un gruppo di
    Clarity
    che possa essere trovato mediante la funzionalità di ricerca di CSA. Gli utenti in gruppi nidificati all'interno del gruppo
    Classic PPM
    LDAP non vengono controllati durante l'esecuzione dei processi di sincronizzazione LDAP.
  • Un utente disattivato sul server LDAP verrà disattivato in
    Classic PPM
    con l'esecuzione successiva del processo di sincronizzazione. Se un utente viene riattivato sul server LDAP, tale utente non verrà riattivato automaticamente in
    Classic PPM
    e sarà necessario riattivare la risorsa.
Prima di implementare LDAP, selezionare un server LDAP compatibile.
Configurare
Classic PPM
per l'autenticazione LDAP su ciascun server che esegue un servizio di applicazione. Per completare queste operazioni, configurare un server LDAP. Se si dispone di un cluster server di
Classic PPM
, ripetere queste operazioni su ciascun server nel cluster.
Procedere come descritto di seguito:
  1. Creare una risorsa, ad esempio l'utente di test, da utilizzare per accedere a
    Classic PPM
    come utente LDAP.
    In
    Classic PPM
    , l'utente di test deve avere lo stesso ID utente del nome sAMAccountName LDAP dell'utente in Microsoft Active Directory o in UID per le altre implementazioni LDAP.
  2. Decidere come definire gli utenti LDAP che dispongono dell'accesso a
    Classic PPM
    .
    È possibile abilitare l'autenticazione di gruppo specificando un gruppo e/o creando una combinazione attributo/valore su LDAP. È possibile definire questa impostazione dalla pagina di protezione
    Server: Proprietà
    in CSA.
  3. Definire le proprietà del server LDAP.
  4. Impostare
    Classic PPM
    per l'autenticazione.
  5. Interrompere e riavviare tutti i servizi di
    Classic PPM
    .
Definizione delle proprietà del server LDAP
È possibile definire le proprietà del server LDAP in CSA.
Procedere come descritto di seguito:
  1. Accedere a CSA.
  2. Fare clic sull'icona
    Proprietà
    del server che si desidera impostare.
  3. Fare clic sulla scheda
    Protezione
    .
  4. Nella sezione
    Server LDAP
    , compilare i seguenti campi:
    • URL
      : definisce l'URL del server LDAP. Se sul proprio server LDAP è abilitato SSL, utilizzare il protocollo LDAPS nell'URL (invece del protocollo LDAP predefinito).
    • Contesto radice
      : definisce il contesto di denominazione LDAP, ad esempio: "ou=People, dc=niku, dc=com".
    • Cerca utente
      : definisce il nome utente con le credenziali appropriate per il binding al server LDAP.
    • Password
      : definisce la password da confermare nel campo Conferma password.
    • Filtro di ricerca
      : definisce la stringa del filtro di ricerca (come definita in RFC 2254).
    • Formato data/ora
      : definisce il formato di data e ora utilizzato dal server LDAP.
    • Nome gruppo
      : abilita l'autenticazione di gruppo. Immettere il nome del gruppo e nel campo Identificatore gruppo immettere l'ID del gruppo.
    • Consenti utenti non LDAP
      : indica che l'accesso a
      Classic PPM
      è consentito tramite metodi di autenticazione alternativi.
    • Usa appartenenze al gruppo
      : selezionare questa casella di controllo (deselezionata per impostazione predefinita) se si desidera migliorare le prestazioni con il processo LDAP di sincronizzazione degli utenti obsoleti. Il processo utilizza le appartenenze ai gruppi nella sincronizzazione e richiede una relazione inversa dagli utenti ai gruppi nell'ambiente LDAP. Il valore predefinito è
      memberOf
      . Tuttavia, è possibile specificare un altro valore nel campo successivo.
    • Identificatore del gruppo in Utenti
      : se si desidera specificare un altro valore oltre all'attributo predefinito
      memberOf
      , immettere l'identificatore di gruppo supportato da LDAP.
      Le opzioni
      Usa appartenenze al gruppo
      e
      Identificatore del gruppo in Utenti
      sono disponibili nella patch 15.5.1.1.
  5. Fare clic su
    Salva
    .
  6. Interrompere e riavviare tutti i servizi di
    Classic PPM
    completando le azioni seguenti:
    1. Fare clic su
      Pagina iniziale
      ,
      Tutti i servizi
      .
    2. Fare clic sull'icona
      Seleziona tutto
      per selezionare la casella di controllo accanto a ciascun servizio, quindi fare clic su
      Interrompi
      .
    3. Fare clic sull'icona
      Seleziona tutto
      per selezionare la casella di controllo accanto a ciascun servizio, quindi fare clic su
      Avvia
      .
  7. Fare clic su
    Salva
    .
  8. In CSA, fare clic sulla scheda
    Applicazione
    .
  9. Nella sezione
    Server applicazioni
    , selezionare
    Usa LDAP
    , quindi fare clic su
    Salva
    .
Sincronizzazione LDAP
I processi di sincronizzazione LDAP seguenti interagiscono per la sincronizzazione di
Classic PPM
con LDAP:
  • Processo LDAP - Sincronizza utenti nuovi e modificati
    Questo processo sincronizza i record LDAP con i record di
    Classic PPM
    sincronizzando gli utenti aggiunti al gruppo LDAP di
    Classic PPM
    . Inoltre, il processo rende gli utenti attivi sul server di
    Classic PPM
    . Se si utilizza l'opzione del filtro di ricerca e si modifica un attributo con uno utilizzato da
    Classic PPM
    , l'utente viene attivato sul server di
    Classic PPM
    . L'attivazione si verifica alla successiva esecuzione del processo. Il processo archivia la data e l'ora dell'ultima volta in cui è stato eseguito correttamente nella tabella di database CMN_DIRECTORY_SERVERS. Il processo sincronizza solo le voci utente create o modificate di recente. Per la sincronizzazione, l'indicatore di data e ora deve essere maggiore del valore rilevato nel campo CMN_DIRECTORY_SERVERS.LAST_SYNC_DATE.
  • Processo LDAP - Sincronizza utenti obsoleti
Questo processo disattiva gli utenti rimossi dal gruppo LDAP
Classic PPM
sul server LDAP o il cui record non contiene più l'attributo di ricerca scelto. Il processo non controlla se un utente trovato nel gruppo LDAP
Classic PPM
o nella ricerca specificata in CSA sia attivo o non attivo in LDAP. Per disattivare gli utenti in
Classic PPM
mediante il processo, rimuovere gli utenti dal gruppo LDAP di
Classic PPM
o rimuovere l'attributo di ricerca specificato in CSA. Questi processi di sincronizzazione funzionano come previsto se sono state configurate correttamente le sezioni Server LDAP e Mapping attributo LDAP in CSA.
È necessario selezionare una pianificazione per ciascun processo.
Procedura consigliata:
eseguire questi processi di notte.
Per sincronizzare il database con il server di directory, eliminare tutte le righe dalla tabella di database CMN_DIRECTORY_SERVERS ed eseguire nuovamente il processo di background. È anche possibile eseguire il processo per un gruppo specifico in modo che siano interessati solo i record di tali utenti.
Imposizione del processo LDAP - Sincronizzazione di utenti nuovi e modificati per l'esecuzione della sincronizzazione completa
Potrebbe essere necessario ignorare il comportamento del processo
LDAP - Sincronizza utenti nuovi e modificati
e forzare una sincronizzazione completa.
Procedere come descritto di seguito:
  1. Eliminare la riga dalla tabella di database CMN_DIRECTORY_SERVERS.
  2. Eseguire (o pianificare) nuovamente il processo.
Risoluzione dei problemi LDAP
Di seguito sono riportati alcuni problemi LDAP comuni e i metodi di risoluzione:
  • Per eseguire il debug del processo di autenticazione LDAP, abilitare i messaggi di debug registrati dal componente di protezione. Interrompere tutti i servizi in background, ad eccezione di quello su cui si desidera abilitare i messaggi di debug. Riavviare il servizio in background in modo da rendere le modifiche effettive, quindi visualizzare il file di registro (bg-ca.log).
  • Durante la verifica dei messaggi di errore dei registri di
    Classic PPM
    , possono essere visualizzati codici di errore specifici di LDAP.
    Consultare la documentazione LDAP di terze parti per le descrizioni dei codici di errore specifici per LDAP.
  • Se non è possibile accedere a
    Classic PPM
    con un nome utente e una password LDAP, tenere presenti le informazioni seguenti:
    • Si sta utilizzando un account LDAP attivo esistente anche come account attivo in
      Classic PPM
      ?
    • È stata abilitata la configurazione LDAP selezionando il campo Usa LDAP nella pagina delle proprietà del server applicazioni in CSA?
    • Sono stati immessi l'ID utente corretto nel campo Cerca utente e la password corretta nel campo Password nella pagina delle proprietà del server di protezione in CSA?
    • Fare riferimento ai file di registro per messaggi più specifici.
    • Il tempo di elaborazione del processo
      LDAP - Sincronizza utenti obsoleti
      e il processo
      LDAP - Sincronizza utenti nuovi e modificati
      dipende dal numero di utenti caricati dal servizio di directory in
      Classic PPM
      . In particolare, un numero elevato di utenti può rallentare i tempi di elaborazione.
Risoluzione dei problemi per i processi di sincronizzazione LDAP
Quando un processo di sincronizzazione di LDAP o di autenticazione non funziona come previsto, eseguire una delle attività seguenti:
  • Controllare i file di registro di sincronizzazione LDAP nella directory /niku/Clarity/logs/ldapsync.
  • Controllare il file *users*.xml. Questo file contiene un elenco di nomi utenti estratti dal server LDAP. Se manca questo file, la comunicazione tra
    Classic PPM
    e il server LDAP non riesce.
  • Controllare il file *sync*.xml. Questo file contiene i risultati da una sessione di importazione di utente gateway. Se manca questo file, la comunicazione tra
    Classic PPM
    e il gateway non riesce.
  • Abilitare i messaggi di debug nel componente di protezione procedendo come segue:
    1. Modificare
      bg-logger.xml
      e aggiungere la categoria
      com.niku.security
      .
    2. Impostare la priorità su
      Debug
      .
    3. Riavviare il servizio Background
      Clarity
      (bg) in modo da rendere le modifiche effettive.
    4. Controllare il file bg-ca.log.
    5. Se si dispone di più servizi BG nel cluster, interromperli tutti eccetto uno. Se si dispone di un solo servizio BG si ha la sicurezza che il processo verrà eseguito sul server in corso di debug. È inoltre possibile attivare il debug in tutti i servizi singolarmente.
Controllo dei registri di sincronizzazione LDAP
Controllare i registri delle transazioni di sincronizzazione LDAP nella directory seguente:
<Clarity Home Directory>/logs/ldapsync
I file di registro relativi ai processi per utenti nuovi e modificati sono:
  • ldapusers_nm_*.xml: elenco degli utenti trovati nel server di directory da sincronizzare con
    Classic PPM
    .
  • ldapsync_nm_*.xml: elenco dei messaggi di operazione eseguita correttamente, errore o avviso relativi al processo di sincronizzazione.
I file di registro relativi al processo
LDAP - Sincronizza utenti obsoleti
sono:
  • ldapusers_ia_*.xml: elenco degli utenti da disattivare in
    Classic PPM
    .
  • ldapsync_ia_*.xml: elenco dei messaggi di operazione eseguita correttamente, errore o avviso relativi al processo di sincronizzazione.
Abilitazione dei messaggi di debug
Il componente di protezione registra i messaggi di debug. Interrompere tutti i servizi Background
Clarity
(bg) eccetto il servizio su cui è in corso l'abilitazione dei messaggi di debug. Riavviare il servizio Background
Clarity
(bg) in modo da rendere le modifiche effettive, quindi visualizzare il file di registro (bg-niku.log).
Procedere come descritto di seguito:
  1. Accedere a CSA.
  2. Fare clic su Pagina iniziale, Server.
  3. Fare clic sull'icona Registri per il server su cui si desiderano abilitare i messaggi di debug.
  4. Fare clic sulla scheda secondaria Modifica configurazione.
  5. Nella sezione Categorie, fare clic su Aggiungi categoria.
  6. Immettere il valore seguente per la nuova riga:
    • Nome
      Immettere
      com.niku.security
      .
    • Priorità
      Selezionare Debug dal menu a discesa.
  7. Salvare le modifiche.
    I messaggi di debug sono stati abilitati.
Configurazione di LDAP e SSL
Quando un server LDAP è in esecuzione con SSL (Secure Socket Layer), è necessario configurare LDAP e SSL. L'amministratore di
Classic PPM
deve installare il certificato di protezione attendibile per il server LDAP sul computer che esegue il servizio Background
Clarity
(bg). Per installare il certificato, utilizzare il keytool fornito con Java 7 JDK.
Immettere i comandi seguenti dal prompt dei comandi:
keytool -import -v -trustcacerts -alias <alias> -file <certificate file name> -keystore cacerts
Esempio:
$cd $JAVA_HOME/jre/lib/security $keytool -import -v -trustcacerts -alias NikuLdapServer -file TrustedRootCert.der -keystore cacerts
Configurazione di Single Sign-On (SSO) per
Classic PPM
Single Sign-On (SSO) è un processo di autenticazione che permette l'accesso di utenti a sistemi multipli utilizzando un solo nome utente e una sola password. Con SSO, quando il server utilizza le informazioni della directory LDAP per l'autenticazione dell'identità di un utente, consente l'accesso alle informazioni richieste in base ai privilegi di accesso dell'utente.
È possibile impostare SSO per l'integrazione di
Classic PPM
con l'applicazione di portale interna in cui l'utente esegue l'autenticazione. Con SSO non è più necessario immettere più volte il nome utente e la password quando si passa da un'applicazione all'altra. L'applicazione di portale include collegamenti (URL) ad altre applicazioni interne. Una volta richiamata l'applicazione di portale, gli utenti non visualizzano le finestre di dialogo per l'autenticazione ma accedono direttamente all'applicazione. L'applicazione di portale include un plug-in SSO che indirizza gli utenti all'accesso al portale e quindi all'applicazione appropriata. Così facendo, gli utenti non possono creare un segnalibro per la pagina e quindi accedervi nuovamente senza prima connettersi.
SSO offre i vantaggi seguenti:
  • Amministrazione di nome utente e password: Il dipartimento IT deve effettuare la gestione di un solo nome utente e di una sola password per utente.
  • Supporto dell'autenticazione: Al dipartimento IT è richiesto il supporto di una sola posizione in cui gli utenti possono riscontrare problemi di autenticazione.
  • Usabilità: Gli utenti devono solo ricordare il nome utente e la password ed eseguire l'accesso una sola volta.
  • Protezione: L'uso di un nome utente e di una password facilita l'utilizzo di password complesse e la modifica a intervalli più frequenti. La possibilità di scegliere una password familiare è ridotta quando c'è solo una password da ricordare.
Procedura consigliata
: se si utilizza CA SiteMinder o un altro software SSO, impostare la configurazione affinché siano consentiti i caratteri di parentesi angolare (< e >) nell'URL. Ad esempio, se si sta utilizzando SiteMinder, disabilitare CssChecking. In caso contrario, un URL contenente parentesi angolari genera un errore in
Classic PPM
. Un URL potrebbe contenere parentesi angolari create, ad esempio, da un processo con condizioni come <, <=, > o >=).
Procedere come descritto di seguito:
  1. Configurare il server SSO e il server proxy in modo che puntino a
    Classic PPM
    e trasmettano un token di autenticazione contenente un nome utente di
    Classic PPM
    valido.
    Configurare il server SSO per fare in modo che l'URL di accesso sia:
    http://<server>/niku/nu#action:npt.overview
  2. Accedere a CSA e fare clic su Pagina iniziale, Server.
  3. Fare clic sul nome del server che si desidera impostare.
  4. Fare clic sulla scheda secondaria Applicazione.
  5. Per utilizzare LDAP, nella sezione Server applicazioni, selezionare la casella di controllo Usa LDAP.
    Se LDAP è abilitato, i client non browser utilizzeranno lo stesso nome utente e la stessa password.
  6. Nella sezione Istanza applicazione, selezionare la casella di controllo Usa Single Sign-On, quindi fare clic su Salva.
  7. Fare clic sulla scheda Protezione.
  8. Nella sezione Crittografia, compilare i seguenti campi:
    • Keystore SSL
      Definisce il percorso del file keystore.
      Esempio
      : <pathtokeystore>/server.keystore).
    • Password SSL
      Definisce la password keystore. Una volta immessa, confermarla nel campo Conferma password.
  9. Nella sezione Server LDAP, compilare i seguenti campi:
    • URL
      Definisce l'URL del server LDAP.
    • Contesto radice
      Definisce il contesto di denominazione del server LDAP, ad esempio: "ou=People, dc=niku, dc=com".
    • Cerca utente
      Definisce il nome utente con le credenziali appropriate per il binding al server LDAP.
    • Password
      Definisce la password del server LDAP. Una volta immessa, confermarla nuovamente nel campo Conferma password.
    • Dimensione batch
      Abilita l'operazione sincrona. Impostare la dimensione batch con i criteri seguenti:
      • 0. Consente tutti i risultati ricevuti dal server non appena vengono generati.
      • Un numero diverso da zero. I messaggi sono bloccati finché non si ricevono
        n
        messaggi dal server. L'enumerazione avanza mentre vengono messi in coda altri messaggi.
      • La dimensione batch predefinita è 1. Un'enumerazione dei risultati di ricerca da un'operazione di ricerca sincrona restituisce i messaggi man mano che vengono ricevuti dal server.
    • Filtro di ricerca
      Definisce la stringa del filtro di ricerca (come definita in RFC 2254).
    • Formato data/ora
      Definisce il formato di data e ora utilizzato sul server LDAP.
    • Nome gruppo
      Definisce il gruppo abilitato per l'autenticazione di gruppo.
    • Identificatore gruppo
      Specifica l'ID di gruppo del gruppo abilitato per l'autenticazione di gruppo.
    • Consenti utenti non LDAP
      Indica se agli utenti non LDAP è consentito l'accesso all'applicazione con un metodo di autenticazione alternativo.
  10. Nella sezione Mapping attributo LDAP, compilare i seguenti campi:
    Nome utente
    Specifica l'attributo del nome utente.
    Nome
    Specifica l'attributo del nome.
    Cognome
    Specifica l'attributo del cognome.
    Nome completo
    Specifica l'attributo del cognome.
    Indirizzo di posta elettronica
    Specifica l'attributo dell'indirizzo di posta elettronica.
    Modifica indicatore data e ora
    Specifica l'attributo della modifica dell'indicatore di data e ora.
  11. Nella sezione Single Sign-On, completare i campi seguenti:
    Nome token
    Specifica il cookie HTTP che
    Classic PPM
    accetta come token di autenticazione valido per l'avvio di una sessione utente.
    Tipo token
    Specifica il tipo di token. I valori sono:
    Cookie.
    Il token è contenuto in un cookie.
    Intestazione.
    Il token è contenuto nell'intestazione di messaggio.
    Parametro.
    Il token è fornito in un parametro.
    URL disconnessione
    Definisce l'URL completo visualizzato alla disconnessione dell'utente.
    URL errore di autenticazione
    Definisce l'URL completo visualizzato quando non è possibile autenticare l'utente.
  12. Salvare le modifiche.
  13. Riavviare l'applicazione e accedere a
    Classic PPM
    come amministratore dell'applicazione.
    Verrà visualizzata la pagina delle impostazioni di sistema.
Configurazione di Single Sign-On (SSO) per
Clarity
Per abilitare l'implementazione di SSO per
Clarity
, configurare il server SSO come descritto nella procedura seguente. Gli esempi forniti per le impostazioni di configurazione sono applicabili al server SSO di SiteMinder. Le impostazioni possono essere differenti in base al server SSO utilizzato.
Prima di configurare il server SSO per
Clarity
, verificare che il server SSO sia abilitato per
Classic PPM
. Per ulteriori informazioni, consultare la sezione Configurazione di SSO per
Classic PPM
. Se SSO non è configurato per
Classic PPM
, non sarà possibile utilizzarlo per
Clarity
.
Procedere come descritto di seguito:
  1. Proteggere gli URL seguenti per
    Clarity
    :
    https://<server:port>/pm*
    https://<server:port>/ppm/rest/*
    Esempio di SiteMinder
    :
    Nel dominio esistente contenente il realm di
    Classic PPM
    , creare due nuovi realm:
    Creare un realm contenente una regola per la protezione delle API REST
    • Nome
      : Regola API REST
      Clarity
    • Descrizione
      : regola per la protezione delle API REST di
      Classic PPM
    • Attributi
      ,
      Risorsa
      : ppm/rest/*
    • Casella di riepilogo
      Azione
      ,
      Azione agente Web
      : selezionare Get, Post, Put, Delete e Head
    Creare un realm contenente una regola per la protezione di
    Clarity
    • Nome
      : nuova regola dell'interfaccia utente di
      Classic PPM
    • Descrizione
      : regola per la protezione di
      Clarity
    • Attributi
      ,
      Risorse
      : pm*
    • Casella di riepilogo
      Azione
      ,
      Azione agente Web
      : selezionare Get, Post, Put, Delete e Head
      Dopo aver definito le regole, accedere alla scheda Regole e aggiungere la
      risposta
      esistente di SSO di
      Classic PPM
      a ciascuna nuova regola SSO. La risposta definisce il nome del cookie dell'utente e il formato del valore previsto da
      Classic PPM
      SSO.
    image2017-1-27 9:44:40.png
  2. Configurare le seguenti proprietà per l'agente Web:
    1. Aggiungere il seguente URL all'elenco di URL di disconnessione esistenti:
      https://<server:port>/ppm/rest/v1/auth/logout
    2. Aggiungere il seguente URL all'elenco degli URL da ignorare:
      https://<server:port>//pm/js/core/layout/logout.html
    3. Aggiungere le seguenti estensioni di file all'elenco delle estensioni ignorate:
      • .woff
      • .svg
      • .ttf
      • .eot
    4. Rimuovere le virgolette singole (se il valore esiste) dall'elenco di caratteri URL non validi.
    5. Rimuovere le virgolette singole (se il valore esiste) dall'elenco dei caratteri di query non valida.
Esempio di SiteMinder:
Modificare le seguenti proprietà dell'agente:
  • IgnoreExt
    : aggiungere le estensioni di file .woff, .svg, .ttf e .eot all'elenco delle estensioni ignorate.
  • IgnoreUrl
    : aggiungere /pm/js/core/layout/logout.html all'elenco degli URL ignorati.
  • LogoffUri:
    aggiungere /ppm/rest/v1/auth/logout all'elenco degli URI di disconnessione.
  • BadUrlChars:
    rimuovere il valore di virgolette singole, se presente.
  • BadQueryChars
    : rimuovere il valore di virgolette singole, se presente.
Utilizzo di LDAP con SSO
È possibile utilizzare LDAP con Single Sign-On (SSO).
Procedura consigliata
: sebbene SO non richieda l'abilitazione di LDAP, si consiglia di utilizzare LDAP con SSO per le ragioni seguenti:
  • I client non browser traggono i maggiori vantaggi da SSO.
  • Solo con SSO, è ancora necessario gestire le informazioni utente, quali nomi e posta elettronica, all'interno di
    Classic PPM
    . Con LDAP, questi dati vengono gestiti nel server di directory.
Utilizzo di LDAP senza SSO
L'autenticazione SSO offre pochi vantaggi in più rispetto a LDAP. Gli utenti devono immettere il nome utente e la password per accedere a
Classic PPM
, ma gli altri vantaggi si applicano ancora con LDAP. La configurazione di sistema è molto più semplice con LDAP da solo. LDAP non richiede la presenza di un proxy o di un server SSO, in quanto è necessaria una sola istanza di
Classic PPM
.
Impostazione delle opzioni relative alle vulnerabilità di Cross-Site Scripting (XSS)
Gli attacchi Cross-Site Scripting (XSS) inseriscono script dannosi in siti Web attendibili. Un assalitore XSS utilizza un'applicazione Web per inviare a un utente finale un codice dannoso, generalmente nella forma di uno script lato browser. Questi attacchi riescono quando un'applicazione Web include dati di immissione utente nell'output che genera senza prima convalidare o codificare i dati di immissione.
Il browser dell'utente finale non è in grado di determinare se lo script è dannoso. Poiché lo script dannoso sembra provenire da una fonte attendibile, il browser esegue il codice. Il codice può accedere a cookie, token di sessione e altre informazioni sensibili.
Per risolvere le vulnerabilità XSS, è necessario verificare la sicurezza di tutti gli input forniti dall'utente che vengono rimandati al browser mediante convalida dell'input. L'input utente deve essere preceduto da caratteri di escape prima di essere incluso nella pagina di output. Una codifica di output adeguata assicura che l'input utente venga sempre trattato come testo all'interno del browser, invece che come contenuto attivo che è possibile eseguire.
Per evitare gli attacchi a partire da vulnerabilità XSS, a partire dalle release 14.1 e 14.2, l'applicazione gestisce le restrizioni (escape) e la convalida dell'input dell'utente. Per richiedere modifiche alle impostazioni delle restrizioni o per altro tipo di assistenza relativa a problemi di protezione da XSS, contattare il supporto tecnico su ca.com/support.
5
5
XSS: convalida dell'input dell'utente
Classic PPM
verifica che tutti gli input dell'utente rimandati al browser siano protetti da XSS. Il prodotto confronta l'input dell'utente con un set di schemi di stringhe comunemente utilizzati per XSS. Se qualsiasi parte dell'input dell'utente corrisponde a uno degli schemi comuni,
Classic PPM
limita (effettua l'escape) della stringa XSS nell'input dell'utente.
Il prodotto limita la stringa XSS inserendo caratteri di escape prima e dopo la stringa. Questi caratteri sono visibili all'utente finale. I caratteri di escape indicano al browser di ignorare qualsiasi script o tag HTML allegato all'input dell'utente.
Per impostazione predefinita, il rilevamento XSS è attivato. Gli attributi URL e i collegamenti ai siti sono esclusi da questo controllo. Per ulteriori informazioni sulla modifica di queste impostazioni, consultare la sezione Impostazione delle limitazioni per l'input dell'utente XSS.
XSS: restrizioni per l'input dell'utente
L'input dell'utente che contiene uno degli schemi XSS comuni va evitato prima che venga incluso nella pagina di output. La codifica di output assicura che l'input utente venga trattato come testo e non come contenuto attivo che è possibile eseguire. Le opzioni di amministrazione consentono di attivare o disattivare le limitazioni XSS (escape).
Per modificare l'impostazione di ciascuna opzione, eseguire le istruzioni del database SQL.
Procedere come descritto di seguito:
  1. Accedere alla tabella di database CMN_OPTION_VALUES.
  2. Aggiornare la voce della tabella corrispondente all'opzione specifica. Per informazioni su ciascuna opzione, consultare la relativa descrizione.
  3. Svuotare la cache.
XSS: opzione di restrizione
Questa opzione limita la stringa XSS nell'output dell'utente se la stringa corrisponde a uno schema nell'opzione CMN.XSS.PATTERNS. Questa opzione di sistema si applica all'intera applicazione
Classic PPM
, tranne agli attributi URL e ai collegamenti ai siti. È possibile impostare le limitazioni per gli attributi URL e i collegamenti ai siti tramite opzioni separate.
  • RESTRICT.APP.XSS
    Valori = True (limitazioni attivate), False (limitazioni disattivate)
    Valore predefinito = True
Il contenuto di HtmlPortlet non è limitato (con escape). Le portlet HTML eseguono uno script nel contenuto HTML, che è il comportamento previsto.
Per modificare l'opzione RESTRICT.APP.XSS, aggiornare la tabella di database CMN_OPTION_VALUES utilizzando la seguente istruzione SQL:
update cmn_option_values set value='false|true' where option_id = (select id from cmn_options where option_code=' RESTRICT.APP.XSS')
Note sulla protezione
: l'applicazione di questo comando di aggiornamento non impedisce la codifica dei portlet HTML con Javascript e che il Javascript venga eseguito sul computer client. In qualità di amministratore, ci si concentrerà sui server e su come proteggerli da Meltdown e Spectre, mentre i Javascript potenzialmente dannosi eseguiti sui computer client non costituiscono un elemento d'interesse, in quanto non soggetti al proprio controllo.
Per sferrare un attacco più grave, il suo autore deve poter eseguire codice sul processore della vittima. Per eseguire il rendering dei siti web moderni, qualsiasi modulo JavaScript Web deve consentire l'esecuzione di codice JavaScript non attendibile sul processore dell'utente. Qualsiasi codice Javascript incluso in un portlet HTML viene eseguito sul computer client nel browser e non sul server.
Clarity
non esegue JavaScript sul lato server.
Le restrizioni XSS escludono parametri all'interno di post per i form e URL che potrebbero contenere codice Javascript dannoso che, se rimandato al browser del client, verrebbe eseguito e potrebbe danneggiare il computer client. Tali restrizioni vengono gestite attraverso dei filtri dell'applicazione Web che vengono applicati a una richiesta inviata dal client al server, nella speranza che la risposta restituita al client venga eseguita o reindirizzata in modo tale che il client non venga danneggiato. Le portlet HTML codificate con Javascript dall'utente non superano questi filtri. Si tratta di una risposta a un'azione richiesta a
Clarity
, ad esempio, la visualizzazione di una portlet. Le risposte non passano attraverso il filtro. Pertanto se un utente codifica un portlet HTML inserendovi codice Javascript, tale codice verrà eseguito solo sul suo computer client.
XSS: opzione del valore di attributo URL
L'opzione limita il valore di attributo URL (creato con Studio) se il valore corrisponde a uno schema nell'opzione CMN.XSS.PATTERNS.
  • RESTRICT.URL.ATTR.XSS
    Valori = True (limitazioni attivate), False (limitazioni disattivate)
    Valore predefinito = False
Per modificare l'opzione RESTRICT.URL.ATTR.XSS, aggiornare la tabella di database CMN_OPTION_VALUES utilizzando la seguente istruzione SQL:
update cmn_option_values set value='false|true' where option_id = (select id from cmn_options where option_code=' RESTRICT.URL.ATTR.XSS')
XSS: opzione dei collegamenti ai siti
Questa opzione limita il valore della voce Collegamenti a siti se il valore corrisponde a uno schema nell'opzione CMN.XSS.PATTERNS.
  • RESTRICT.SITE.LINKS.XSS
    Valori = True (limitazioni attivate), False (limitazioni disattivate)
    Valore predefinito = False
Per modificare l'opzione RESTRICT.SITE.LINKS.XSS, aggiornare la tabella di database CMN_OPTION_VALUES utilizzando la seguente istruzione SQL:
update cmn_option_values set value='false|true' where option_id = (select id from cmn_options where option_code=' RESTRICT.SITE.LINKS.XSS')
XSS: opzione degli schemi XSS comuni
Questa opzione definisce gli schemi di stringhe che vengono comunemente utilizzati per XSS. È possibile aggiungere dei valori a questa opzione per includere ulteriori schemi di stringhe.
  • CMN.XSS.PATTERNS
    String patterns = </script> <script(.*?)> <script>(.*?)</script> alert(.*?) eval\\((.*?)\\) expression\\((.*?)\\) javascript: onerror(.*?)= onload(.*?)= src[\r\n]*=[\r\n]*\\\"(.*?)\\\" src[\r\n]*=[\r\n]*\\\'(.*?)\\\'
Per aggiungere degli schemi, accedere alla tabella di database CMN_OPTION_VALUES e includere i nuovi schemi nell'opzione CMN.XSS.PATTERNS.
Esempio: Aggiungere il nuovo schema "onfocus" all'opzione CMN.XSS.PATTERNS
Oracle
CMN_OPTION_VALUES_INS_SP('CMN.XSS.PATTERNS','true','true','onfocus(.*?)=',1);
MSSQL
EXEC CMN_OPTION_VALUES_INS_SP 'CMN.XSS.PATTERNS','true','true','onfocus(.*?)=',1
Intestazioni di risposta di sicurezza: X-XSS-Protection e X-Content-Type-Options
I browser web hanno dispongono di due intestazioni di risposta di sicurezza attivate per impostazione predefinita per fornire un ulteriore livello di protezione.
  • X-XSS-Protection
    : l'intestazione
    X-XSS-Protection
    impone l'abilitazione del filtro XSS, anche se questo è disabilitato. Supportata in browser quali Internet Explorer, Chrome e Safari, questa intestazione di risposta blocca il caricamento delle pagine quando il browser rileva attacchi XSS riflessi. Questa intestazione non è richiesta nei browser più recenti quando le applicazioni implementano una tecnologia un criterio di sicurezza del contenuto (CSP) efficace che disattiva l'uso di JavaScript in-line non sicuro. Sebbene
    Clarity
    garantisca una solida protezione in questo contesto, l'applicazione fornisce comunque la protezione per gli utenti dei browser Web meno recenti che non supportano ancora CSP.
  • X-Content-Type-Options
    : l'intestazione
    X-Content-Type-Options
    è un indicatore utilizzato dal server per impedire qualsiasi modifica ai tipi di MIME pubblicizzati nelle intestazioni Content-Type.
Sebbene improbabile, in caso di problemi è possibile disabilitare le singole intestazioni o tutte le intestazioni nella risposta di rete con i seguenti comandi SQL:
  • Per disabilitare le opzioni
    X-Content-Type-Options: nosniff
    delete from cmn_option_values where option_id in (select id from cmn_options where option_code like 'ENABLED_RESPONSE_HEADERS%') and value like 'X-Content-Type%'
  • Per disabilitare la protezione
    X-XSS-Protection: 1; mode=block
    delete from cmn_option_values where option_id in (select id from cmn_options where option_code like 'ENABLED_RESPONSE_HEADERS%') and value like 'X-XSS-Protection%'
  • Per disabilitare tutte le intestazioni:
    call CMN_OPTION_VALUES_DEL_SP('ENABLED_RESPONSE_HEADERS');
URL esterni
La proprietà externalUrl è un'impostazione di applicazione facoltativa che supporta schemi di autenticazione esterni o federati in messaggi di notifica. Se la proprietà externalUrl non viene specificata, i messaggi di notifica di
Classic PPM
contenenti degli URL utilizzano la proprietà entryUrl standard.
La proprietà entryUrl standard punta direttamente al server di
Classic PPM
. La proprietà externalUrl comporta prima l'indirizzamento della richiesta a un server esterno che consente l'autenticazione dell'accesso per la sessione. Il server esterno reindirizza la richiesta originale a
Classic PPM
mediante Single Sign-On (SSO). Questo metodo assicura che l'utente non dovrà accedere direttamente a
Classic PPM
. Quando l'utente fa clic su un collegamento di notifica, viene effettuata l'autenticazione esterna e la richiesta viene inoltrata a
Classic PPM
. Se l'utente ha già eseguito l'accesso, la richiesta viene inoltrata automaticamente senza interruzione.
L'URL esterno non sostituisce l'URL di accesso standard, bensì funziona con esso. I due URL formano un URL composto che include indirizzi esterni e interni, codificati per assicurare la corretta trasmissione degli URL integrati. Il percorso di autenticazione può includere più server multipli, perciò, in genere, gli URL includono parametri di query che indicano a ciascun server dove reindirizzare la richiesta dopo l'elaborazione.
La proprietà externalUrl supporta le macro seguenti:
  • ${entryurl}
    Inserisce la proprietà di configurazione entryUrl attuale.
  • replace(regex,replacement,text)
    Sostituisce tutte le istanze di "regex" con "replacement" in "text".
  • encode()
    Sostituisce il testo con codificato testo UTF-8.
È possibile combinare e annidare le macro.
Specificare i caratteri XML con limitazioni, come le e commerciali, usando il nome di entità equivalente (, &amp;). Se non si procede in questo modo, è possibile che l'avvio di tutti i servizi di
Classic PPM
venga impedito.
Esempio: Creazione di un URL esterno
Il percorso di autenticazione per un ambiente specifico consente di determinare la proprietà externalUrl. Il percorso di autenticazione include, in particolare, gli indirizzi di ciascun server nel percorso e i parametri richiesti da ciascun server. Prima di impostare questo valore, determinare il percorso raccogliendo le informazioni.
Ad esempio, considerare l'ambiente seguente:
  • Server 1
    Scopo
    : server di autenticazione esterna
    Indirizzo
    : http://auth.somecompany.com
    Parametri richiesti
    : REDIRECT
    Descrizione
    : esegue l'autenticazione (richiamando l'accesso se necessario), quindi il reindirizzamento all'indirizzo specificato nel parametro REDIRECT
  • Server 2
    Scopo
    : server di autenticazione interno
    Indirizzo
    : http://sso.mycompany.com
    Parametri richiesti
    : TARGET
    Descrizione
    : richiama Single Sign-On interno, quindi invia la richiesta all'indirizzo specificato nel parametro TARGET.
  • Server 3
    Scopo
    : server applicazioni di
    Classic PPM
    Indirizzo
    : http://ca_ppm.mycompany.com
    Parametri richiesti
    : tutti i parametri standard di
    Classic PPM
    Descrizione
    : indirizzo specificato in entryUrl.
Per riassumere, le richieste sono prima inviate all'indirizzo http://auth.somecompany.com, il sistema esterno di gestione dell'identità. Le richieste vengono quindi inviate al server Single Sign-On interno all'indirizzo http://sso.mycompany.com e infine al server all'indirizzo http://ca_ppm.mycompany.com.
Procedere come descritto di seguito:
  1. La costruzione dell'URL esterno inizia con l'aggiunta della prima interruzione, il server di autenticazione esterna:
    externalUrl=http://auth.somecompany.com
    Questo server richiede un parametro, REDIRECT, che indica al server dove indirizzare la richiesta dopo l'elaborazione. In questo esempio, la richiesta viene indirizzata al server interno di autenticazione:
    externalUrl=http://auth.somecompany.com?REDIRECT=http://sso.mycompany.com
  2. Il server SSO interno richiede un parametro, TARGET, che contiene l'URL di accesso standard di
    Classic PPM
    . La macro ${entryurl} si espande automaticamente all'impostazione entryUrl attuale quando vengono inviate le notifiche:
    externalUrl=http://auth.somecompany.com?REDIRECT=http://sso.mycompany.com?TARGET=${entryurl}
  3. L'URL esterno è quasi completato, resta ancora un passaggio.
    Il parametro REDIRECT per il server 1 contiene caratteri per cui occorre la codifica UTF-8 in modo da essere passati su una stringa di query in modo sicuro. La macro encode è riferita a quanto segue:
    externalUrl=http://auth.somecompany.com?REDIRECT=encode(http://sso.mycompany.com?TARGET=${entryurl})
    Il server 2 ha anche un parametro che è necessario codificare:
    externalUrl=http://auth.somecompany.com?REDIRECT=encode(http://sso.mycompany.com?TARGET=encode(${entryurl}))
    Le macro encode() sono nidificate. La nidificazione fa sì che quella interna venga codificata due volte, ossia che il testo con codifica UTF-8 venga codificato una seconda volta. Questa doppia codifica è necessaria perché il server 1 decodifica l'intero parametro REDIRECT alla prima interruzione e il server 2 prevede un parametro codificato UTF-8. È possibile nidificare la macro di codifica tante volte quante necessarie per assicurare che il parametro finale abbia la codifica corretta.
Ciclo di vita della richiesta
Quando viene generata una nuova notifica di posta elettronica di
Classic PPM
, le proprietà externalUrl ed entryUrl vengono utilizzate per generare un URL selezionabile appropriato per l'evento. L'URL standard (senza utilizzare externalUrl) potrebbe essere uguale a:
http://ca_ppm.mycompany.com/niku/nu#action:timeadmin.currentTimesheet
Con externalUrl abilitato come nell'esempio, l'URL generato sarebbe uguale a:
externalUrl=http://auth.somecompany.com?REDIRECT=http%3A%2F%2Fsso.mycompany.com%3FTARGET%3Dhttp%253A%252F%252Fca_ppm.mycompany.com%252Fniku%252Fnu%2523action%253Atimeadmin.currentTimesheet
L'esempio precedente contiene un URL che punta al server 1 e un parametro singolo con gli indirizzi e le proprietà con codifica UTF-8 dei server 2 e 3 (l'URL di accesso ripetuto due volte). Quando un utente fa clic su questo URL, la richiesta viene inviata al server 1 (http://auth.somecompany.com). Il server 1 decodifica il parametro (tutto il testo dopo REDIRECT=) in:
http://sso.mycompany.com?TARGET=http%3A%2F%2Fca_ppm.mycompany.com%2Fniku%2Fnu%23action%3Atimeadmin.currentTimesheet
Il server 1 utilizza l'URL per reindirizzare al server 2. La stringa di parametro per il server 2 è ancora codificata, anche se la stringa di query intera è stata decodificata dal server 1. L'esempio mostra l'effetto della doppia codifica. A sua volta, il server 2 decodifica il parametro TARGET per produrre:
http://ca_ppm.mycompany.com/niku/nu#action:timeadmin.currentTimesheet
Il precedente URL è quello finale. L'URL è decodificato e pronto per l'elaborazione di
Classic PPM
. Durante questi passaggi, il server 1 e il server 2 hanno eseguito i rispettivi processi di autenticazione. Quando la richiesta raggiunge finalmente
Classic PPM
, contiene il token di autenticazione Single Sign-On appropriato per identificare l'utente. Oltre a generare l'URL corretto quando viene prodotta la notifica,
Classic PPM
non è implicato nel processo di autenticazione.
Risoluzione dei problemi di URL esterni
Per risolvere i problemi relativi a URL esterni non funzionanti, è necessario comprendere quale valore è previsto per ciascun server nella catena. In seguito, è possibile verificare che la codifica degli URL e dei parametri sia corretta in ogni passaggio. È possibile verificare manualmente l'URL di una determinata notifica seguendo le fasi indicate.
Procedere come descritto di seguito:
  1. Ottenere un'utilità di decodifica UTF-8. È possibile scaricare un'utilità semplice.
  2. Generare un messaggio di posta elettronica di notifica con l'impostazione attuale di URL esterno.
  3. Esaminare l'URL e verificare che la prima parte punti al server 1. La prima parte dell'URL include tutto fino al primo punto interrogativo.
  4. Ignorare tutto fino al primo punto interrogativo incluso, lasciando la stringa di parametro passata al server 1.
  5. Decodificare la stringa restante una volta mediante l'utilità di decodificazione UTF-8.
    La stringa decodificata rappresenta i parametri passati al server 1. Verificare che i parametri siano corretti.
  6. Ignorare il nome parametro ("REDIRECT" nell'esempio) e verificare che la prima parte dell'URL punti al server 2. Ancora una volta, tutto fino al punto interrogativo viene incluso nella prima parte dell'URL.
  7. Ignorare ancora una volta tutto fino al punto interrogativo, quindi decodificare la stringa restante una volta.
  8. Verificare i punti seguenti:
    • La prima parte dell'URL punta al server di
      Classic PPM
      .
    • La stringa di query restante contiene parametri di
      Classic PPM
      standard.
    • I parametri non sono codificati.
In che modo
Classic PPM
registra le sessioni utente?
I cookie basati sulla sessione contengono un token utilizzato per accedere ai dati della sessione memorizzati nella cache nelle posizioni seguenti:
  • Cache (per un singolo ambiente di applicazione)
  • Database (per un ambiente clusterizzato)
Questo rappresenta un limite per l'ambiente?
È necessario che il browser Web dell'utente finale accetti i cookie dall'applicazione di
Classic PPM
. I cookie sono basati sulla sessione, perciò non vengono scritti sul disco.
Le utilità di bilanciamento del carico o i cluster sono interessati da questa tecnica?
Il bilanciamento del carico e il clustering funzionano correttamente con questa tecnica. Molte aziende bilanciano il carico di
Classic PPM
e lo rendono clusterizzato.
Sono possibili hijack accidentali o intenzionali di una sessione?
Per utilizzare in modo indebito la sessione di un utente, si dovrebbe spiare il traffico HTTP per ottenere le intestazioni contenenti il cookie di autenticazione. Questo token, comunque, è valido solo mentre l'utente è connesso. Quando l'utente effettua la disconnessione, le informazioni di sessione nel database o nella cache di
Classic PPM
corrispondenti al valore del cookie vengono eliminate.
Quale procedura occorre seguire per escludere gli ID sessione dai registri?
Come misura di protezione, è possibile configurare
Classic PPM
per impedire che i valori degli ID di sessione vengano visualizzati nei file di registro. Per impedire la visualizzazione di questi valori, modificare il file logger.xml. Sostituire lo schema di registro (%u:%s:%a) con lo schema (%U:%a).
Gli esempi seguenti mostrano i risultati dell'utilizzo di entrambi gli schemi di registro nel file logger.xml.
Esempio: (%u:%s:%a)
Questa riga di codice mostra come lo schema visualizza il valore dell'ID sessione nel file logger.xml.
<param name="ConversionPattern" value="%-5p %d{ISO8601} [%t] %c{2} (%u:%s:%a) %m\r\n"/>
Questo schema genera dei record in un file di registro con il valore dell'ID sessione. Il seguente record del file app-ca.log mostra il valore dell'ID sessione (in grassetto):
DEBUG 2014-08-18 19:52:02,949 [http-bio-80-exec-3] odf.view (ca_ppm:admin:
5077018__8DF3B2A0-F398-4A4B-BC35-E9A012065CE0
:npt.overview) Aggiunta della visualizzazione FILTER_VIEW_LOADER::USER:NIKU.ROOT alla cache temporanea
Esempio: (%U:%a)
Questa riga di codice mostra come lo schema impedisce che il valore dell'ID sessione venga visualizzato nel file logger.xml.
<param name="ConversionPattern" value="%-5p %d{ISO8601} [%t] %c{2} (%U:%a) %m\r\n"/>
Questo schema genera un record in un file di registro senza il valore dell'ID sessione. L'esempio seguente è un record del file app-ca-service.log in cui non viene visualizzato alcun valore dell'ID sessione.
DEBUG 2014-08-18 19:52:02,494 [http-bio-80-exec-3] in.service (admin:npt.overview)
Se il layout è impostato su NikuLayout nel file logger.xml per un appender,
Classic PPM
supporta schemi di registrazione aggiuntivi.
Opzione di schema
Scopo
u
Crea l'ID utente con l'ID titolare nel registro.
Esempio: (%u) crea l'output (clarity: admin) nel registro.
U
Crea l'ID utente nel registro.
Esempio: (%U) crea l'output (admin) nel registro.
s
Crea l'ID sessione nel registro.
Esempio: (%s) crea l'output (5077018__8DF3B2A0-F398-4A4B-BC35-E9A012065CE0) nel registro.
a
Crea l'ID azione nel registro.
Esempio: (%a) crea l'output (npt.overview) nel registro.
Per ulteriori informazioni sugli schemi log4j versione 1.2 supportati, consultare la documentazione API per la classe PatternLayout all'indirizzo https://logging.apache.org.