CSA: Sicherheit, Kennwörter, LDAP, SSL, SSO, XSS (nur On-Premise)

ccppmop1592
Verwenden Sie die
Clarity
-Systemverwaltung (CSA), um die Sicherheit zu verwalten, Kennwörter für den Datenbankserver festzulegen, SSL zu aktivieren, LDAP-Server zu integrieren, SSO zu konfigurieren und externe URLs zu verwalten.
2
Kennwörter für den Datenbankserver verwalten
Verwenden Sie ein Serverkennwort, um die einzelnen Server zu sichern. Wenn sich der Server in einem Cluster befindet, können Sie mithilfe des Serverkennworts nicht auf andere Server im Cluster zugreifen.
Ändern Sie regelmäßig das Kennwort auf allen Servern, um das Risiko unbefugter Zugriffe zu minimieren.
  1. Ändern Sie das Kennwort für den Datenbankserver. Weitere Informationen finden Sie in der Dokumentation zur Datenbank.
  2. Ändern Sie das Kennwort für CSA.
  3. Starten Sie die Dienste nach der Änderung der Datenbankserver-Kennwörter neu.
Verschlüsseln von Serverkennwörtern
Um die Kennwortdatei eines Servers zu schützen, können Sie die Kennwortdatei verschlüsseln. Sie können die AES-Verschlüsselung von Serverkennwörtern über die Datei
properties.xml
aktivieren. Bei Verwendung dieser Verschlüsselungsmethode muss ein separates Kennwort (Schlüssel) verwendet werden, wenn die Kennwörter in der Datei
properties.xml
verschlüsselt werden. Bewahren Sie diesen unverschlüsselten Schlüssel sicher auf.
Der Vorteil der Verschlüsselung auf Serverseite liegt darin, dass nur ein Schlüssel geschützt werden muss. Dieser wird in einer Datei gespeichert, auf die der Server zugreifen kann. Der Schlüssel ist nur beim Serverstart erforderlich. Wenn
Classic PPM
ausgeführt wird, können Sie die Schlüsseldatei zusätzlich mit einer weiteren Verschlüsselungsschicht schützen. Wenn sich die Datei auf einem Wechseldatenträger befindet, können Sie diesen abnehmen und sicher verwahren.
Wenn Sie die Verschlüsselung des Serverkennworts aktivieren, werden in der Datei
properties.xml
alle Klartextkennwörter verschlüsselt, wenn
Classic PPM
das nächste Mal auf die Datei zugreift. Wenn Sie die Verschlüsselung aktivieren und die Datei
properties.xml
direkt bearbeiten, können Sie Kennwörter im Klartextformat eingeben. Beim nächsten Zugriff auf die Datei (beispielsweise wenn ein Dienst bereitgestellt oder gestartet wird) werden diese Klartextkennwörter verschlüsselt.
Um Serverkennwörter zu verschlüsseln, erstellen Sie eine gültige Schlüsseldatei, auf die der Server zugreifen kann und in der die Eigenschaftdatei enthalten ist. Alle Server müssen entweder auf die Schlüsseldatei (über das Netzwerk) oder auf eine Kopie (auf der lokalen Serverfestplatte) zugreifen können.
Gehen Sie wie folgt vor:
  1. Melden Sie sich bei CSA an.
  2. Klicken Sie auf
    Startseite
    ,
    Server
    .
  3. Klicken Sie auf den Namen des Servers.
  4. Klicken Sie auf die Registerkarte
    Sicherheit
    .
  5. Wählen Sie eine Option aus, und klicken Sie auf
    Speichern
    .
    • Um die Verschlüsselung mithilfe eines Systemschlüssels zu aktivieren, wählen Sie die Option
      Systemschlüssel verwenden
      in dem Feld
      Kennwörter verschlüsseln
      aus. Bei dieser Option wird ein hartkodierter Schlüssel verwendet, der im Lieferumfang des Produkts enthalten ist. Hierbei handelt es sich um die weniger sichere der beiden Optionen. Wenn der Schlüssel für eine
      Clarity
      -Installation bekannt ist, ist der Schlüssel für alle Installationen bekannt. Diese Option vermeidet zufälligen Zugriff. Wenn ein Mitarbeiter ohne schlechte Absichten nach dem Systemschlüssel sucht, werden keine Kennwörter angezeigt. Wenn jedoch ein Eindringling versucht, Zugriff auf das System zu erhalten und bereits auf Dateien auf dem Server zugreifen kann, ist er wahrscheinlich in der Lage, die Kennwörter zu entschlüsseln.
    • Um Verschlüsselung mit einer benutzerdefinierten Schlüsseldatei zu aktivieren, aktivieren Sie die Option
      Benutzerdefinierte Schlüsseldatei verwenden
      . Geben Sie den vollständigen Pfad und den Dateinamen für die benutzerdefinierte Schlüsseldatei im Feld
      Schlüsseldatei
      ein. Bei Verwendung dieser Option ist es erforderlich, eine Schlüsseldatei zu erstellen, auf die alle Server zugreifen können, auf denen
      Classic PPM
      ausgeführt wird. Die Schlüsseldatei ist gut gesichert, sodass ein Eindringling vor die praktisch unlösbare Aufgabe gestellt wäre, die Kennwörter ohne Schlüssel zu entschlüsseln.
      Wenn Sie die Kennwörter mit einer benutzerdefinierten Schlüsseldatei verschlüsseln, ändern Sie die benutzerdefinierte Schlüsseldatei. Andernfalls gehen Ihre Kennwörter verloren (sie können nicht entschlüsselt werden). In diesem Fall müssen Sie die Kennwörter erneut eingeben.
Ändern von Kennwörtern für den Datenbankserver
Gehen Sie wie folgt vor:
  1. Ändern Sie Ihr Kennwort für den Datenbankserver in der Datenbank.
    Weitere Informationen finden Sie in der Dokumentation zur Datenbank.
  2. Ändern Sie das Kennwort für den Datenbankserver in CSA mit dem neuen Kennwort, das Sie eingegeben haben. Melden Sie sich bei CSA an.
  3. Halten Sie den
    Clarity
    -Anwendungsdienst (app) und den
    Clarity
    -Hintergrunddienst (bg) an, indem Sie die folgenden Aktionen durchführen:
    1. Klicken Sie auf Startseite, Alle Dienste.
    2. Aktivieren Sie die Kontrollkästchen neben "
      Clarity
      -Anwendung" und "
      Clarity
      -Hintergrund", und klicken Sie auf "Anhalten".
      Die Dienste werden angehalten.
  4. Klicken Sie auf Startseite, Server.
  5. Klicken Sie auf "Eigenschaften" und anschließend auf die Registerkarte "Datenbank".
  6. Füllen Sie im Bereich "Interne Verbindung: Niku" die folgenden Felder aus:
    • Kennwort
      Geben Sie ein neues Kennwort ein.
    • Kennwort bestätigen
      Geben Sie das Kennwort erneut ein.
  7. Klicken Sie auf Speichern.
  8. Starten Sie den
    Clarity
    -Hintergrunddienst (bg) und den
    Clarity
    -Anwendungsdienst (app) neu:
    1. Klicken Sie auf Startseite, Alle Dienste.
    2. Aktivieren Sie die Kontrollkästchen neben "
      Clarity
      -Hintergrund" (bg) und "
      Clarity
      -Anwendung" (app), und klicken Sie auf "Anfang".
Konfigurieren von Secure Sockets Layer (SSL) in Apache Tomcat
SSL ist ein Protokoll für die Übertragung von Daten zwischen Knoten. Zum Schutz der Daten vor unbefugtem Zugriff verwendet dieses Protokoll eine kryptografische Methode, die auf zwei Schlüsseln basiert: einem öffentlichen Schlüssel, der allgemein bekannt ist, und einem privaten (geheimen) Schlüssel, der nur dem Empfänger der Nachricht bekannt ist.
  • Da sich die Schritte in diesem Abschnitt auf Komponenten von Drittanbietern beziehen, ist die Unterstützung eingeschränkt.
  • Entscheiden Sie, wo Sie SSL installieren. Zum Beispiel: Verwenden Sie einen anderen Server und nicht den Anwendungsserver, um die Leistung zu verbessern.
  • Der Java-Befehl
    keytool
    ist eine beliebte Methode, um SSL-Zertifikate zu erstellen und zu verwalten. Andere Tools und Befehle stehen zur Verfügung.
  • Die aufgeführten Schritte gelten für viele Umgebungen, aber nicht für alle Umgebungen. Außerdem können die Schritte in einigen Umgebungen auch falsch sein. Sie können insbesondere selbstsignierte Zertifikate (nicht von einem zertifizierten Anbieter wie Verisign oder Thawte erworben) verwenden. Diese Zertifikate erfordern möglicherweise mehrere Installationen, bevor das echte Zertifikat installiert wird. Die Namen für diese Zertifikate variieren.
  • Folgen Sie den Anweisungen des SSL-Zertifikatanbieters, anstatt sich ausschließlich auf die Schritte auf dieser Seite zu verlassen. Möglicherweise verlangen Anbieter, dass Sie bestimmte Schritte oder Befehle ändern.
  • Verwenden Sie für Tests den privaten Schlüssel, der in
    Classic PPM
    enthalten ist.
Wenn HTTP mit SSL verwendet wird, wird es als "HTTPS" bezeichnet.
Wenn SSL für den Anwendungsdienst aktiviert ist, werden alle Daten, die zwischen Client-Anwendungen (z. B. einem Webbrowser oder Open Workbench) übertragen werden, verschlüsselt. Die Daten werden vor dem Versand verschlüsselt und vor dem Empfang entschlüsselt. Ohne SSL-Verschl üsselung können nicht autorisierte Entitäten die Daten lesen und vertrauliche Information wie Benutzernamen und Kennwörter entnehmen.
Gehen Sie wie folgt vor:
Die Schritte auf dieser Seite gelten nur bei der ersten Installation von
Classic PPM
. Sie können auch ein erneuertes Zertifikat installieren, wenn ein altes Zertifikat abläuft.
4
4
Generieren eines Schlüsselpaars (öffentlich/privat)
Verwenden Sie den Java-Befehl
keytool
, um ein Schlüsselpaar (öffentlich/privat) zu generieren und um eine Zertifikatsignieranforderung (Certificate Signing Request, CSR) zu erstellen.
Die Schritte auf dieser Seite geben nur die erforderlichen Java-Parameter an. Vollständige Informationen zu allen Parametern für diese Java-Befehle finden Sie auf der Dokumentationswebsite von Oracle.
Bevor Sie das System in der Produktionsumgebung verwenden, erstellen Sie eine Schlüsselspeicherdatei für den privaten Schlüssel, und verteilen Sie diese Datei an alle Anwendungsserver. Wenn Sie bereits eine andere Schlüsselspeicherdatei haben, können Sie die Datei auch mit
Classic PPM
verwenden.
Gehen Sie wie folgt vor:
  1. Öffnen Sie den
    Classic PPM
    -Anwendungsserver und anschließend eine Eingabeaufforderung, und geben Sie den folgenden Befehl ein, um das Schlüsselpaar mit öffentlichem und privatem Schlüssel zu generieren:
    keytool -genkey -keystore /<Clarity Home Directory>/config/.keystore -keyalg RSA -storepass keystore
  2. Definieren Sie die folgenden Werte:
    • -genkey
      Diese Option generiert einen Schlüsselspeicher, wenn noch keiner vorhanden ist. Der Schlüsselspeicher enthält den öffentlichen Schlüssel und den öffentlichen Dummy-Schlüssel.
    • keystore
      Gibt den Pfad und Dateinamen der Schlüsselspeicherdatei an. Der Schlüsselspeicher heißt standardmäßig
      .keystore
      und befindet sich im Verzeichnis
      /<Clarity-Basisverzeichnis>/config/
      .
    • keyalg
      Gibt den Algorithmus an, den Sie bei der Generierung des Schlüsselpaars verwenden (in diesem Beispiel RSA).
    • storepass
      Das Kennwort, das verwendet wird, um den Schlüsselspeicher zu schützen (mindestens sechs Zeichen lang). Dieses Kennwort wird an alle Befehle weitergegeben, die auf den Schlüsselspeicher zugreifen.
  3. Wenn Sie dazu aufgefordert werden, geben Sie die gewünschten Informationen zu Ihrer Organisation ein.
  4. Wenn Sie dazu aufgefordert werden, das Schlüsselkennwort einzugeben, drücken Sie die
    Eingabetaste
    . Das Schlüsselkennwort und das Kennwort des Schlüsselspeichers müssen identisch sein.
Exportieren Sie bei einem selbstsignierten Zertifikat die .cer-Datei aus dem privaten Schlüssel, den Sie generiert haben, und überspringen Sie den nächsten Schritt. Erstellen Sie keine Zertifikatsignieranforderung (Certificate Signing Requests, CSR). Eine CSR ist in diesem Fall nicht erforderlich. Um die Datei zu exportieren, verwenden Sie folgenden Befehl:
keytool –export -file <file_name.cer> -keystore <ClarityHome/config/.keystore> -storepass keystore
Erstellen einer Zertifikatsignieranforderung (Certificate Signing Requests, CSR)
Ersetzen Sie das Testzertifikat in einem Produktionssystem durch ein echtes, zertifiziertes Zertifikat. Um ein zertifiziertes Zertifikat zu erhalten, erstellen Sie eine Zertifikatsignieranforderung, und senden Sie sie an eine Zertifizierungsstelle. Die Zertifizierungsstelle generiert ein echtes Zertifikat, das Ihren öffentlichen Schlüssel authentifiziert. Die CSR ist eine Anforderung eines echten SSL-Zertifikats, das auf den Informationen für Ihr System basiert. Sie installieren nicht die CSR. Sie installieren das echte Zertifikat, das von Ihrem SSL-Anbieter als Antwort auf Ihre CSR bereitgestellt wird. Folgen Sie immer den Anweisungen Ihres SSL-Anbieters. Bei spezifischen Befehlen ist es oft erforderlich, Root-Zertifikate oder Zwischenzertifikate zu installieren. Bei manchen Anbietern ist es möglicherweise erforderlich, andere Zertifikate zu installieren.
Gehen Sie wie folgt vor:
  1. Öffnen Sie auf dem
    Classic PPM
    -Anwendungsserver eine Eingabeaufforderung, und geben Sie den folgenden Befehl ein:
    keytool -certreq -keystore /<Clarity Home Directory>/config/.keystore -keyalg RSA -file ca_ppm.csr
  2. Wenn Sie nach einem Kennwort gefragt werden, geben Sie das Standardkennwort (
    keystore
    ) ein.
  3. Definieren Sie die folgenden Werte:
    • -certreq
      Generiert eine Zertifikatsignieranforderung.
    • keystore
      Gibt den Pfad und Dateinamen der Schlüsselspeicherdatei an. Der Schlüsselspeicher wird standardmäßig
      .keystore
      genannt und im Verzeichnis /<Clarity-Basisverzeichnis>/config/ gespeichert.
    • keyalg
      Gibt den Algorithmus (RSA) an, der bei der Generierung des Schlüsselpaars verwendet werden soll.
    • file
      Gibt den Namen (ca_ppm.csr) der generierten Zertifikatsanforderungsdatei an.
  4. Öffnen Sie in einem Webbrowser die Website der Zertifizierungsstelle, und geben Sie den Inhalt der von Ihnen generierten Zertifikatsignieranforderung an.
    Befolgen Sie den Prozess Ihrer Zertifizierungsstelle. Sie erhalten Ihre Zertifikatsignieranforderung von der Zertifizierungsstelle.
  5. Kopieren Sie das neue Zertifikat (z. B. ca_ppm.cer), das Ihr SSL-Anbieter auf dem
    Classic PPM
    -Anwendungsserver bereithält.
    Es bestehen keine Auswirkungen auf Ihren privaten Schlüssel.
  6. Sichern Sie die Schlüsselspeicherdatei, indem Sie sie in ein anderes Volume kopieren. Ändern Sie die "keystore"-Datei nicht, während Sie auf das echte Zertifikat warten. Änderungen können Probleme beim Importieren des echten Zertifikats verursachen. Wenn Sie das echte Zertifikat nicht importieren können oder wenn ein Benutzer die Datei ändert, dann können Sie von vorne beginnen. Generieren Sie keine neue CSR, oder warten Sie auf eine neue Kopie des echten Zertifikats. Sie sparen Zeit, wenn Sie die Sicherungskopie der Schlüsselspeicherdatei haben.
Installieren von Zertifikaten
Wenn Sie ein Zertifikat von Ihrem SSL-Anbieter erhalten haben, importieren Sie die Antwort von der Zertifizierungsstelle, und ersetzen Sie das selbstsignierte Zertifikat durch eine Zertifikatskette. Am Ende der Kette befindet sich das von der Zertifizierungsstelle ausgestellte Zertifikat, das Ihren öffentlichen Schlüssel authentifiziert. Das nächste Zertifikat in der Kette ist ein Zertifikat, das den öffentlichen Schlüssel der Zertifizierungsstelle authentifiziert.
Sie importieren die Zertifikate, um eine Zertifikatskette zu erstellen. Bei selbstsignierten Zertifikaten oder bei Zertifikaten, die auf Ihren eigenen Zertifikatsserver erstellt wurden, stellt der Ersteller die Zertifikate bereit. Als Ersteller richten Sie die Vertrauensstellungen/Prozessketten ein, damit SSL problemlos funktioniert, wie Zertifikate, die Sie von SSL-Anbietern erwerben. Importieren Sie alle Root-Zertifikate, Zwischenzertifikate, andere Zertifikate und das echte Zertifikat, die von Ihrem SSL-Anbieter als Antwort auf Ihre CSR bereitgestellt wurden.
Führen Sie die folgenden Schritte aus, um eine Schlüsselspeicherdatei zu erstellen, die Ihren privaten Schlüssel enthält und mit dem signierten Zertifikat Ihrer Zertifizierungsstelle gekoppelt ist.
Gehen Sie wie folgt vor:
  1. Öffnen Sie den
    Classic PPM
    -Anwendungsserver und anschließend eine Eingabeaufforderung, und geben Sie den folgenden Befehl ein:
    keytool -import -keystore /<Clarity Home Directory>/config/.keystore -keyalg RSA -file
    Clarity
    - Source.cer -trustcacerts
    Möglicherweise müssen Sie das Zwischenzertifikat Ihrer Stammzertifizierungsstelle in die Schlüsselspeicherdatei importieren, bevor Sie Ihr Zertifikat importieren. Weitere Informationen finden Sie in der Dokumentation der Zertifizierungsstelle.
  2. Geben Sie das Kennwort für den Schlüsselspeicher ein, und drücken Sie die Eingabetaste.
  3. Geben Sie
    yes
    ein.
Verteilen der Schlüsselspeicherdatei an die Anwendungsserver
Wenn Sie mehrere Server mit Anwendungsdiensten verwenden, verteilen Sie den Schlüsselspeicher an alle Server.
Gehen Sie wie folgt vor:
  1. Melden Sie sich bei CSA an.
  2. Beenden Sie alle Dienste, indem Sie die folgenden Aktionen durchführen:
    1. Klicken Sie auf Startseite, Alle Dienste.
    2. Wählen Sie alle Dienste aus, und klicken Sie auf "Anhalten".
  3. Klicken Sie auf "Verteilen", "Alle verteilen".
  4. Aktivieren Sie das Kontrollkästchen neben allen Servern, und klicken Sie auf "Verteilen".
  5. Starten Sie alle Dienste neu, indem Sie die folgenden Aktionen durchführen:
    1. Klicken Sie auf Startseite, Alle Dienste.
    2. Wählen Sie alle Dienste aus, und klicken Sie auf "Anfang".
      Die Schlüsselspeicherdatei wird an die Server mit Anwendungsdiensten verteilt.
Legen Sie den Speicherort und das Kennwort für die Schlüsselspeicherdatei fest.
Wiederholen Sie diese Schritte für jeden Server im Cluster.
Gehen Sie wie folgt vor:
  1. Melden Sie sich bei CSA an.
  2. Um den Server zu ändern, klicken Sie auf das Eigenschaftssymbol.
  3. Klicken Sie auf die Registerkarte Sicherheit.
  4. Füllen Sie die folgenden Felder aus, und klicken Sie auf "Speichern":
    • SSL-Schlüsselspeicher
      Geben Sie den Speicherort der Schlüsselspeicherdatei ein. Wenn Sie das Feld leer lassen, wird der Standardwert
      <Clarity-Basisverzeichnis>/config/.keystore
      verwendet.
    • SSL-Kennwort
      Geben Sie das Kennwort für den Schlüsselspeicher ein (der Standardwert lautet
      keystore
      ).
    • Kennwort bestätigen
      Geben Sie das Kennwort für den Schlüsselspeicher erneut ein.
  5. Beenden Sie alle Dienste, und starten Sie sie neu, indem Sie die folgenden Aktionen durchführen:
    1. Öffnen Sie die Startseite, und klicken Sie auf "Alle Dienste".
    2. Klicken Sie auf das Symbol "Alles markieren", um alle Dienste auszuwählen, und klicken Sie auf "Anhalten".
    3. Klicken Sie auf das Symbol "Alles markieren", um alle Dienste auszuwählen, und klicken Sie auf "Anfang".
SSL auf jedem Server aktivieren
Die Einstellung "SSL-Handling" bestimmt das Verhalten der Anwendung bezüglich SSL. Die Einstellung enthält die folgenden Optionen:
  • Von Porteinstellungen ableiten (implizit)
    Das SSL-Handling wird davon abgeleitet, ob Webserver-Ports aktiviert oder deaktiviert sind. Diese Einstellung emuliert das SSL-Verhalten von früheren Releases (vor Version 13.0).
  • SSL wird verwendet, jedoch extern verarbeitet (extern)
    Gibt an, dass der Lastenausgleich oder ein anderer vorhergehender Endpunkt die SSL-Verwendung außerhalb des Anwendungsservers beendet.
  • Nur für sensible Seiten zu HTTPS wechseln (hybrid)
    Gibt an, dass
    Classic PPM
    für sichere und unsichere Seiten aktiv zwischen HTTP und HTTPS wechselt.
  • HTTP und HTTPS unterstützen, ohne wechseln zu müssen (beides)
    Gibt an, dass HTTP und HTTPS aktiviert sind. Versuchen Sie nicht, zwischen den beiden Modi zu wechseln.
  • Nur HTTPS unterstützen (voll)
    Es wird durchwegs SSL verwendet. Alles wird verschlüsselt. Wechseln Sie bei Bedarf zu SSL.
  • Nur HTTP unterstützen (keines von beidem)
    SS wird nicht verwendet. Es wird durchwegs Klartext verwendet.
Diese Schritte erklären die Einrichtung von SSL-Handling mit der Option "Nur HTTPS unterstützen". Wenn Sie als Option für SSL-Handling "Von Porteinstellungen ableiten" auswählen, sind die folgenden zusätzlichen Feldeinstellungen für alle Anwendungsinstanzen erforderlich:
  • HTTP aktiviert
    Deaktivieren Sie das Kontrollkästchen.
  • HTTPS aktiviert
    Aktivieren Sie das Kontrollkästchen.
Um SSL zu aktivieren, führen Sie diese Schritte für jeden Server aus:
Gehen Sie wie folgt vor:
  1. Melden Sie sich bei CSA an.
  2. Klicken Sie auf Startseite, Server.
  3. Klicken Sie auf den Namen des Servers, den Sie konfigurieren möchten.
  4. Klicken Sie auf die Registerkarte "Eigenschaften".
  5. Klicken Sie auf die Registerkarte Anwendung.
  6. Füllen Sie im Bereich Anwendungsserver das folgende Feld aus:
    • SSL-Handling
      Aktivieren Sie die Option
      Nur HTTP unterstützen
      .
  7. Füllen Sie in jedem mit dem Server verbundenen Bereich
    Anwendungsinstanz
    folgende Felder aus:
    • HTTPS-Port
      Geben Sie den Port ein, für den Sie HTTPS-Datenverkehr verwenden möchten.
    • HTTPS-Eingabe-URL
      Geben Sie die HTTPS-URL (einschließlich des Ports) ein.
      Beispiel:
      https://ca_ppm.mycompany.com:8443
  8. Speichern Sie Ihre Änderungen.
  9. Beenden Sie die Anwendungsdienste, und starten Sie sie neu, indem Sie die folgenden Aktionen durchführen:
    1. Klicken Sie auf
      Startseite
      ,
      Alle Dienste
      .
    2. Wählen Sie alle Dienste aus, die Sie anhalten möchten, und klicken Sie auf
      Anhalten
      .
    3. Wählen Sie alle Dienste aus, die Sie neu starten möchten, und klicken Sie auf
      Anfang
      .
Aktivieren von SSL für kennwortgeschützte Seiten
Sie können festlegen, dass SSL nur für die Seiten aktiviert ist, die Benutzerkennwörter enthalten. Bei dieser Konfiguration werden Benutzer automatisch zwischen sicheren und unsicheren Seiten in der Anwendung weitergeleitet. Die Umleitung wird durch die gleichzeitige Aktivierung von HTTP und HTTPS ermöglicht.
Für diese Konfiguration müssen beide Ports in UNIX-Betriebssystemen größer als 1024 sein. Als Ausnahme können Sie die regulären Portnummern verwenden, wenn Sie einen SUDO-Befehl verwenden, um die Dienste mit Root-ähnliche Berechtigungen zu starten. Diese Ausnahme wird nicht angewendet, wenn ausgewogene Installationen oder Proxy-Installationen verwendet werden. Verwenden Sie in diesen Fällen benutzerdefinierte Portbereiche. In Nicht-Produktionsumgebungen können Sie immer noch auswählen, ob ein Lastenausgleich (mit optionaler SSL-Abladung) verwendet werden soll. Sie
können
weiterhin die herkömmlichen Ports unter 1024 verwenden.
Gehen Sie wie folgt vor:
  1. Melden Sie sich bei CSA an.
  2. Klicken Sie auf
    Startseite
    ,
    Server
    .
  3. Klicken Sie auf das
    Eigenschaftssymbol
    für den Server, den Sie konfigurieren möchten.
  4. Klicken Sie auf die Registerkarte
    Anwendung
    .
  5. Füllen Sie im Bereich
    Anwendungsserver
    das folgende Feld aus:
    • SSL-Handling
      Aktivieren Sie die Option
      Nur für sensible Seiten zu HTTPS wechseln
      .
  6. Füllen Sie in jedem mit dem Server verbundenen Bereich
    Anwendungsinstanz
    folgende Felder aus:
    • HTTP aktiviert
      Aktivieren Sie das Kontrollkästchen.
    • HTTPS aktiviert
      Aktivieren Sie das Kontrollkästchen.
    • HTTPS-Port
      Geben Sie den Port ein, der für den HTTPS-Datenverkehr verwendet werden soll.
      Für UNIX müssen die HTTP- und HTTPS-Portnummern höher als 1024 sein, es sei denn, Sie verwenden einen SUDO-Befehl.
    • HTTP-Eingabe-URL
      Geben Sie die HTTP-URL (einschließlich des Ports) ein.
      Beispiel:
      http://ca_ppm.mycompany.com:8080
    • HTTPS-Eingabe-URL
      Geben Sie die HTTPS-URL (einschließlich des Ports) ein.
      Beispiel:
      https://ca_ppm.mycompany.com:8443
  7. Konfigurieren Sie weitere Server.
  8. Beenden Sie jeden Anwendungsdienst, und starten Sie ihn neu:
    1. Klicken Sie auf die Registerkarte
      Dienste
      .
    2. Wählen Sie alle Dienste aus, die Sie anhalten möchten, und klicken Sie auf
      Anhalten
      .
    3. Wählen Sie alle Dienste aus, die Sie neu starten möchten, und klicken Sie auf
      Anfang
      .
Aktivieren einer sicheren JDBC-Verbindung zwischen den
Clarity
-Anwendungs- und -Datenbankservern auf separaten Hosts mit SSL
Zur Einhaltung von Richtlinien zur Informationssicherheit und anderer Frameworks müssen Sie Anwendungen wie
Clarity
auf AWS, Azure und anderen Cloud-Servern möglicherweise auf Anwendungs- und Datenbankebene verschlüsseln.
Sie können in der
Clarity
-Eigenschaftendatei bestimmte Parameter in der Zeichenfolge für die Datenbankverbindung definieren, um SSL zu aktivieren.
  1. Führen Sie die oben genannten Schritte aus, um das SSL-Zertifikat auf dem Oracle- oder SQL-Server zu installieren.
  2. Fügen Sie im Datenbankelement der
    Clarity
    -Eigenschaftendatei die folgenden Attribute hinzu:
    1. Fügen Sie
      useURL="true"
      hinzu.
    2. Fügen Sie im
      url
      -Attribut
      encryptionmethod=SSL
      hinzu, wie unten gezeigt:
    <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. Die Oracle-Netzwerkverschlüsselung wird ebenfalls unterstützt. Fügen Sie in der JDBC-URL den folgenden Parameter hinzu:
    DataIntegrityLevel=required
  4. Öffnen Sie die Datei
    sqlnet.ora
    , und bestätigen Sie, dass sie die folgenden Parametereinstellungen enthält:
    SQLNET.ENCRYPTION_SERVER = required
    SQLNET.CRYPTO_CHECKSUM_SERVER = required
    Diese Einstellung
    required
    aktiviert den Verschlüsselungs- oder Integritätsdienst und lässt keine Verbindung zu, wenn der Client nicht für den Sicherheitsdienst aktiviert ist. Dies ist die Standardeinstellung für Datenbankbereitstellungen in Database Cloud Service.
  5. Starten Sie die Dienste neu.
Um zu überprüfen, ob die Netzwerkverbindung mit SSL verschlüsselt ist, führen Sie eine Paketverfolgung mit Wireshark durch, und filtern Sie nach IP-Adresse und Portnummer der SQL Server-Datenbank, die in der Verbindungszeichenfolge definiert sind.
Konfigurieren von
Classic PPM
für die Verwendung mit SSL-Offloadern
Für SSL-Anwendungsdienste wird die Datenübertragung zwischen Client-Anwendungen vor dem Versand verschlüsselt und vor dem Empfang entschlüsselt. Die Verschlüsselung der SSL-Pakete kann zu Leistungsbeeinträchtigungen auf Anwendungsservern führen. Um SSL zu verarbeiten, verwenden Sie einen Lastenausgleich oder einen Proxy-Server statt der Anwendungsserver.
Wenn ein externer SSL-Offloader wie ein Lastenausgleich oder ein Reverse-Proxy verwendet wird, verschlüsselt der SSL-Offloader den HTTP-Datenverkehr für
Classic PPM
. Der Offloader kommuniziert über HTTPS mit dem Client. Diese Einstellungen können die Leistung verbessern. Das Offloader-Gerät und
Classic PPM
müssen jedoch entsprechend konfiguriert werden.
Stellen Sie sicher, dass der eingesetzte Offloader eine aktivierte Funktion zum Neuschreiben von URLs aufweist.
Gehen Sie wie folgt vor:
  1. Melden Sie sich bei CSA an.
  2. Klicken Sie auf
    Startseite
    ,
    Server
    .
  3. Klicken Sie auf das
    Eigenschaftensymbol
    für den Server, den Sie konfigurieren möchten.
  4. Klicken Sie auf die Registerkarte
    Anwendung
    .
  5. Füllen Sie im Bereich
    Anwendungsserver
    das folgende Feld aus:
    • SSL-Handling
      Aktivieren Sie die Option
      SSL wird verwendet, jedoch intern verarbeitet
      .
  6. Legen Sie für jede Anwendungsinstanz mit Ausnahme der Instanz des
    Classic PPM
    -Anwendungsservers die folgenden Einstellungen fest:
    • HTTP aktiviert
      Gibt an, dass für die Kommunikation HTTP verwendet wird. Aktivieren Sie das Kontrollkästchen.
    • HTTP-Eingabe-URL
      Gibt die URL an, die Sie für den Datenverkehr zwischen
      Classic PPM
      und einem Client verwenden möchten. Wenn Sie einen SSL-Offloader verwenden, wird der Offloader zum Front-End für
      Classic PPM
      , in etwa so, wie das Lastenausgleichsmodul in einer Umgebung mit mehreren Servern das Front-End ist. Da es sich bei der URL des SSL-Offloaders um eine sichere URL handelt, geben Sie in dieses Feld eine HTTPS-URL im folgenden Format ein:
      https://<Hostname>:CA Portal.
    • HTTPS aktiviert
      Dieses Kontrollkästchen ist nicht anwendbar, wenn Sie einen SSL-Offloader verwenden. Deaktivieren Sie das Kontrollkästchen.
  7. Speichern Sie die Änderungen.
Konfigurieren von
Clarity
für die HTTPS-Verwendung
Die folgenden Schritte gelten für eine
Clarity
-Umgebung ohne Cluster.
In diesem Verfahren erstellen Sie einen Schlüsselspeicher und eine Zertifikatsanforderung. Nehmen Sie nach dem Import der Zertifikate Anpassungen in CSA vor.
Für eine architektonische Implementierung mit Lastenausgleich aktivieren Sie SSL, indem Sie das Zertifikat auf dem Lastenausgleichsmodul installieren, und nicht auf den Anwendungsservern. Ändern Sie auf der Registerkarte
Anwendung
den Feldwert
SSL-Handling
in
SSL wird verwendet, jedoch intern verarbeitet
.
Gehen Sie wie folgt vor
:
  1. Melden Sie sich bei dem Server an, auf dem
    Clarity
    gehostet wird.
  2. Navigieren Sie zu dem Verzeichnis, in dem Sie Ihren privaten Schlüssel speichern möchten. Beispiel:
    C:\ppm150101
  3. Bereiten Sie die Antworten auf die Eingabeaufforderungen in Schritt 5 im Voraus vor.
  4. Erstellen Sie mit folgendem Befehl einen Schlüsselspeicher: "keytool -genkey -keystore C:\ppm15101\keystore.jks -keyalg RSA -storepass changeit".
    "Keystore.jks" ist der Name des Schlüsselspeichers und "changeit" das Kennwort. Ändern Sie das Kennwort in ein stärkeres Kennwort, wenn Sie diesen Befehl ausführen.
  5. Mehrere Eingabeaufforderungen werden angezeigt. Geben Sie Ihre Server- und Organisationsdetails an. Verwenden Sie die Informationen, die Sie in Schritt 3 vorbereitet haben. Die Zertifizierungsstellen können Ihnen alle erforderlichen Details bereitstellen. Kontaktieren Sie sie, wenn Sie nicht alle Aufforderungen selbst beantworten können.
  6. Wenn Sie
    Vor-und Nachname
    angeben müssen, geben Sie den vollständigen Namen des Servers ohne
    http://
    oder
    https://
    ein.
  7. Erstellen Sie eine Zertifikatsanforderung:
    keytool -certreq -keystore C:\ppm15101\keystore.jks -keyalg RSA -file myRequest0.cer
  8. Um ein Zertifikat für den Server zu erhalten, senden Sie diese Datei an die Zertifizierungsstelle.
  9. Stellen Sie sicher, dass Sie die folgenden Zertifikate haben, bevor Sie in den Schlüsselspeicher importieren:
    1. Serverzertifikat
    2. Zwischenzertifikat
    3. Stammzertifikat
      (Fragen Sie die Zertifizierungsstelle nach dem Stamm- und Zwischenzertifikat.)
  10. Importieren Sie das Stammzertifikat, und ersetzen Sie hierbei Name des Schlüsselspeichers, Pfad, Name des Zertifikats und Patch sowie weitere Parameter:
    keytool -import -keystore C:\ppm15101\keystore.jks -keyalg RSA -file root.cer -trustcacerts -alias root
  11. Importieren Sie das Zwischenzertifikat:
    keytool -import -keystore C:\ppm15101\keystore.jks -keyalg RSA -file intermediate.cer -trustcacerts -alias intermediate
  12. Importieren Sie das Serverzertifikat:
    keytool -import -keystore C:\ppm15101\keystore.jks -keyalg RSA file server.cer -trustcacerts -alias server
Vornehmen von Änderungen in CSA
  1. Melden Sie sich bei CSA an, und klicken Sie auf die Registerkarte
    Sicherheit
    .
  2. Geben Sie im Feld
    SSL-Schlüsselspeicher
    den vollständig qualifizierten Pfad zu Ihrem Schlüsselspeicher ein.
  3. Füllen Sie die Felder
    SSL-Kennwort
    und
    Kennwort bestätigen
    aus.
  4. Klicken Sie auf die Registerkarte
    Anwendung
    .
  5. Ändern Sie
    SSL-Handling
    in
    HTTP und HTTPS unterstützen, ohne wechseln zu müssen
    .
  6. Wählen Sie im Bereich
    Anwendungsinstanz: App
    die Option
    HTTPS aktiviert
    aus.
  7. Ändern Sie "HTTPS-Port" in eine Zahl, die der
    Clarity
    -Anwendung zugewiesen ist (dies ist organisationsabhängig). Die Portnummer kann beispielsweise "8043" lauten.
  8. Ändern Sie "HTTPS-Eingabe-URL" auf den genauen Servernamen, der während der Erstellung des Schlüsselspeichers angegeben wurde.
  9. Starten Sie den Anwendungsdienst neu.
  10. Überprüfen Sie, ob HTTPS funktioniert, indem Sie mithilfe von HTTPS navigieren. Verwenden Sie hierbei die richtige Portnummer und URL. Die URL kann beispielsweise "https://servername.organization.com:8043/" lauten.
  11. Ändern Sie "SSL-Handling" in "Nur HTTPS unterstützen".
  12. Starten Sie den Anwendungsdienst neu.
Wenn Sie ein Zertifikat falsch importiert haben und löschen möchten, kann ein Befehl wie der folgende verwendet werden: "keytool -keystore c:\ppm15101\keystore.jks -alias root -delete".
Ein sehr nützlicher Befehl, um alle Zertifikate in einem Schlüsselspeicher aufzulisten, ist folgender: "keytool -keystore c:\ppm15101\keystore.jks -list". Um eine ausführliche Version anzuzeigen, verwenden Sie "keytool -keystore c:\ppm15101\keystore.jks -list -v".
Die hier genannten Pfade gelten für ein Windows-Betriebssystem. Wenn die Anwendung auf einem Linux-Betriebssystem basiert, ändern Sie die Pfadangabe entsprechend der Linux-Konvention. Mit Ausnahme der Pfade bleibt der Befehl unverändert.
Integrieren von
Classic PPM
mit LDAP-Servern (Lightweight Directory Access Protocol)
Eine Lightweight Directory Access Protocol-Schnittstelle (LDAP) für anwendungsübergreifende Zugriffsberechtigungen kann vorteilhaft sein. Der Zugriff wird von einem zentralen Verzeichnisserver gesteuert, sodass die Benutzer für alle Anwendungen denselben Benutzernamen und dasselbe Kennwort verwenden können. Folgende Optionen werden unterstützt:
  • LDAP v2-Protokoll (einfach) verwendet einen kleinen Teil der LDAP-Funktionalität einschließlich Authentifizierung (Klartext oder SSL), Binden und Suchen.
  • LDAP v3-Steuerelement für "Paged Results", wie in RFC 2696 definiert.
Für die Synchronisierung zwischen Ihrem Verzeichnisserver und
Classic PPM
werden Benutzer batchweise vom Verzeichnisserver abgerufen. Die Batch-Größe ist in den LDAP-Konfigurationseinstellungen von
Classic PPM
festgelegt.
Sitzungsbasierte Cookies verwenden ein Token, um auf Sitzungsdaten zuzugreifen. Das Token wird für einzelne Anwendungsumgebungen im Cache und für Clusterumgebungen in einer Datenbank aufbewahrt. Der Webbrowser des Benutzers muss Cookies von
Classic PPM
akzeptieren, die sitzungsbasiert sind und nicht auf dem Datenträger gespeichert werden. Wenn sich der Benutzer abmeldet, werden die Sitzungsinformationen in der Datenbank und im Cache, die dem Cookie entsprechen, gelöscht.
Die Integration von
Classic PPM
mit einem LDAP-Server bietet die folgenden Vorteile:
  • Vereinfachung der Verwaltung von Benutzernamen und Kennwörtern. Die IT-Abteilung muss nur ein Benutzername-/Kennwortpaar für einen Benutzer verwalten.
  • Authentifizierungs-Support. Unterstützung seitens der IT-Abteilung ist nur erforderlich, wenn Benutzer Probleme bei der Authentifizierung haben.
  • Verbesserung der Benutzerfreundlichkeit. Benutzer müssen sich nur an einen Benutzernamen und ein Kennwort erinnern.
  • Verbesserung der Benutzerverwaltung. Benutzernamen und E-Mail-Informationen können in LDAP gespeichert werden.
  • Erhöhung der Sicherheit. Wenn nur ein Benutzername und ein Kennwort verwendet werden, ist es einfacher, komplexe Kennwörter zu verwenden und diese öfter zu ändern. Und wenn sich Benutzer nur an ein Kennwort erinnern müssen, ist die Wahrscheinlichkeit geringer, dass ein naheliegendes Kennwort gewählt wird.
Mit dem Auftrag "LDAP - Neue und geänderte Benutzer synchronisieren" werden LDAP-Einträge synchronisiert. Danach speichert der Auftrag Datum und Uhrzeit der letzten erfolgreichen Ausführung und speichert die Informationen in der Datenbanktabelle MN_DIRECTORY_SERVERS. Bei der nächsten Ausführung des Hintergrundauftrags werden die Einträge synchronisiert. Der Auftrag synchronisiert nur vor Kurzem erstellte oder geänderte Benutzereinträge, deren Zeitstempel einen höheren Wert haben als der Wert in der Eigenschaft CMN_DIRECTORY_SERVERS.LAST_SYNC_DATE.
  • Classic PPM
    überprüft nicht, ob der Benutzer in einer Gruppe oder einer in der CSA angegebenen Suche in LDAP aktiv oder inaktiv ist.
    Classic PPM
    überprüft nur, ob ein Benutzer in einer
    Classic PPM
    -Gruppe vorhanden ist bzw. ob ein gesuchtes Attribut in
    Classic PPM
    vorhanden ist.
  • Classic PPM
    erkennt keine verschachtelten Gruppen in LDAP. Bevor Sie den Auftrag
    LDAP – Neue und geänderte Benutzer synchronisieren
    oder den Auftrag
    LDAP – Veraltete Benutzer synchronisieren
    ausführen, stellen Sie sicher, dass die Benutzer einer
    Clarity
    -Gruppe zugeordnet sind, die in der CSA-Suche gefunden werden kann. Benutzer in Gruppen, die in der LDAP-Gruppe von
    Classic PPM
    verschachtelt sind, werden bei der Ausführung von LDAP-Synchronisierungsaufträgen nicht überprüft.
  • Ein Benutzer, der auf dem LDAP-Server deaktiviert ist, wird bei der nächsten Ausführung des Synchronisierungsauftrags in
    Classic PPM
    deaktiviert. Wenn der Benutzer auf dem LDAP-Server erneut aktiviert wird, wird er in
    Classic PPM
    nicht erneut aktiviert. Sie müssen die Ressource selbst erneut aktivieren.
Bevor Sie LDAP implementieren, wählen Sie einen kompatiblen LDAP-Server aus.
Sie müssen für jeden Server, auf dem ein Anwendungsdienst ausgeführt wird,
Classic PPM
für die LDAP-Authentifizierung einrichten. Um diese Schritte erfolgreich durchzuführen, konfigurieren Sie einen LDAP-Server. Wiederholen Sie bei einem
Classic PPM
-Servercluster die folgenden Schritte für jeden Server im Cluster.
Gehen Sie wie folgt vor:
  1. Erstellen Sie eine Ressource als Testbenutzer, den Sie verwenden können, um als LDAP-Benutzer auf
    Classic PPM
    zuzugreifen.
    Die Benutzer-ID des Testbenutzers in
    Classic PPM
    muss genauso lauten wie der LDAP sAMAccountName in Microsoft Active Directory oder die UID für andere LDAP-Implementierungen.
  2. Legen Sie fest, wie die LDAP-Benutzer definiert werden, die Zugriff auf
    Classic PPM
    haben.
    Sie können Gruppenauthentifizierung aktivieren, indem Sie eine Gruppe angeben und/oder eine Kombination aus Attribut und Wert für LDAP erstellen. Sie können diese Einstellung in der CSA auf der Seite
    Server: Eigenschaften
    für die Sicherheit festlegen.
  3. Definieren Sie die Eigenschaften des LDAP-Servers.
  4. Richten Sie
    Classic PPM
    für die Authentifizierung ein.
  5. Halten Sie alle
    Classic PPM
    -Dienste an, und starten Sie sie neu.
Definieren der LDAP-Server-Eigenschaften
Sie können die LDAP-Servereigenschaften in CSA definieren.
Gehen Sie wie folgt vor:
  1. Melden Sie sich bei CSA an.
  2. Klicken Sie auf das
    Eigenschaftssymbol
    für den Server, den Sie einrichten möchten.
  3. Klicken Sie auf die Registerkarte
    Sicherheit
    .
  4. Füllen Sie die Felder im Bereich
    LDAP-Server
    aus:
    • URL:
      Gibt die LDAP-Server-URL an. Wenn auf dem LDAP-Server SSL aktiviert ist, verwenden Sie das LDAPS-Protokoll in der URL (anstelle des Standard-LDAP-Protokolls).
    • Stammkontext:
      Gibt den LDAP-Namenskontext an, z. B.: "ou=People, dc=niku, dc=com".
    • Nach Benutzer suchen:
      Gibt den Benutzernamen mit den entsprechenden Anmeldeinformationen für die Anbindung an den LDAP-Server an.
    • Kennwort:
      Gibt das Kennwort an, das im Feld "Kennwort bestätigen" bestätigt wird.
    • Suchfilter:
      Legt die Suchfilterzeichenfolge fest (wie in RFC 2254 definiert).
    • Datum/Uhrzeit-Format:
      Legt das Format für Datum und Uhrzeit fest, das auf dem LDAP-Server verwendet wird.
    • Gruppenname:
      Aktiviert die Gruppenauthentifizierung. Geben Sie den Gruppennamen ein, und geben Sie im Feld "Gruppenkennung" die Gruppen-ID ein.
    • Nicht-LDAP-Benutzer zulassen:
      Gibt an, dass der Zugriff auf
      Classic PPM
      über alternative Authentifizierungsmethoden erlaubt ist.
    • Gruppenmitgliedschaften verwenden:
      Aktivieren Sie dieses Kontrollkästchen (standardmäßig deaktiviert), wenn Sie die Leistung für den Auftrag "LDAP – Veraltete Benutzer synchronisieren" verbessern möchten. Der Auftrag verwendet Gruppenmitgliedschaften für die Synchronisierung und erfordert eine Umkehrbeziehung von Benutzern zu Gruppen in LDAP. Der Standardwert ist
      memberOf
      . Sie können jedoch einen anderen Wert im Feld angeben.
    • Gruppenkennung der Benutzer:
      Wenn Sie einen anderen Wert als das Standardattribut
      memberOf
      angeben müssen, geben Sie die von LDAP unterstützte Gruppenkennung hier ein.
      Gruppenmitgliedschaften verwenden
      und
      Gruppenkennung der Benutzer
      sind in Patch 15.5.1.1 verfügbar.
  5. Klicken Sie auf
    Speichern
    .
  6. Halten Sie alle
    Classic PPM
    -Dienste an, und starten Sie sie neu, indem Sie die folgenden Aktionen durchführen:
    1. Klicken Sie auf
      Startseite
      ,
      Alle Dienste
      .
    2. Klicken Sie auf das Symbol für
      Alles markieren
      , um die Kontrollkästchen neben allen Diensten zu aktivieren, und klicken Sie auf
      Anhalten
      .
    3. Klicken Sie auf das Symbol für
      Alles markieren
      , um die Kontrollkästchen neben allen Diensten zu aktivieren, und klicken Sie auf
      Anfang
      .
  7. Klicken Sie auf
    Speichern
    .
  8. Klicken Sie in CSA auf die Registerkarte
    Anwendung
    .
  9. Wählen Sie im Bereich
    Anwendungsserver
    die Option
    LDAP verwenden
    aus, und klicken Sie auf
    Speichern
    .
LDAP-Synchronisierung
Die folgenden LDAP-Synchronisierungsaufträge sind gemeinsam an der Synchronisierung von
Classic PPM
mit LDAP beteiligt:
  • Auftrag "LDAP - Neue und geänderte Benutzer synchronisieren"
    Dieser Auftrag synchronisiert LDAP-Datensätze mit
    Classic PPM
    -Datensätzen, indem er die Benutzer synchronisiert, die Sie zur LDAP-Gruppe von
    Classic PPM
    hinzufügen. Der Auftrag aktiviert auch die Benutzer auf dem
    Classic PPM
    -Server. Wenn Sie die Option "Suchfilter" verwenden und ein Attribut in ein Attribut umändern, das von
    Classic PPM
    verwendet wird, wird der Benutzer auf dem
    Classic PPM
    -Server aktiviert. Die Aktivierung tritt bei der nächsten Ausführung des Auftrags in Kraft. Anschließend speichert der Auftrag das Datum und die Uhrzeit des letzten Zeitpunkts, an dem der Auftrag erfolgreich ausgeführt wurde. Die Informationen werden in der Datenbanktabelle CMN_DIRECTORY_SERVERS gespeichert. Der Auftrag synchronisiert nur kürzlich erstellte oder geänderte Benutzereingaben. Für die Synchronisierung muss der Zeitstempel höher als der Wert im Feld CMN_DIRECTORY_SERVERS.LAST_SYNC_DATE sein.
  • Auftrag "LDAP - Veraltete Benutzer synchronisieren"
Dieser Auftrag deaktiviert Benutzer, die Sie aus der LDAP-Gruppe von
Classic PPM
auf dem LDAP-Server entfernen oder deren Datensätze nicht mehr das gewählte Attribut enthalten. Dieser Auftrag überprüft nicht, ob der Benutzer in der LDAP-Gruppe von
Classic PPM
oder in der von der CSA angegebenen Suche in LDAP aktiv oder inaktiv ist. Um Benutzer in
Classic PPM
mit dem Auftrag zu deaktivieren, entfernen Sie sie aus der LDAP-Gruppe von
Classic PPM
, oder entfernen Sie das Suchattribut, das in der CSA angegeben ist. Damit diese Synchronisierungsaufträge ordnungsgemäß funktionieren, müssen die Bereiche "LDAP-Server" und "LDAP-Attributzuordnung" in der CSA richtig konfiguriert sein.
Sie müssen für jeden Auftrag einen Ablaufplan auswählen.
Best Practice
: Führen Sie diese Aufträge nachts durch.
Um die Datenbank mit dem Verzeichnisserver zu synchronisieren, löschen Sie alle Zeilen aus der Datenbanktabelle CMN_DIRECTORY_SERVERS, und führen Sie den Hintergrundauftrag erneut aus. Sie können den Auftrag auch für eine bestimmte Gruppe ausführen, sodass nur die Datensätze für diese Benutzer betroffen sind.
Erzwingen einer vollständigen Synchronisierung durch den Auftrag "LDAP - Neue und geänderte Benutzer synchronisieren"
Möglicherweise müssen Sie den Auftrag
LDAP - Neue und geänderte Benutzer synchronisieren
außer Kraft setzen und erzwingen, dass der Auftrag eine vollständige Synchronisierung durchführt.
Gehen Sie wie folgt vor:
  1. Löschen Sie die Zeile aus der CMN_DIRECTORY_SERVERS-Datenbanktabelle.
  2. Führen Sie den Auftrag erneut durch (oder planen Sie ihn erneut).
LDAP-Problembehandlung
Häufige LDAP-Probleme und Reaktionsmöglichkeiten:
  • Um den LDAP-Authentifizierungsprozess zu debuggen, aktivieren Sie die Erfassung von Debug-Meldungen in den Protokollen der Sicherheitskomponente. Halten Sie alle Hintergrunddienste außer jenem, für den Sie Debug-Meldungen aktivieren, an. Starten Sie den Hintergrunddienst neu, damit die Änderungen in Kraft treten, und prüfen Sie die Protokolldatei (bg-ca.log).
  • Wenn Sie die
    Classic PPM
    -Protokolle auf Fehlermeldungen überprüfen, finden Sie möglicherweise LDAP-spezifische Fehlercodes.
    Beschreibungen von LDAP-spezifischen Fehlercodes finden Sie in der LDAP-Dokumentation des Drittanbieters.
  • Wenn Sie sich nicht mit einem LDAP-Benutzernamen und LDAP-Kennwort bei
    Classic PPM
    anmelden können, beachten Sie Folgendes:
    • Verwenden Sie ein aktives LDAP-Konto, das auch als aktives Konto in
      Classic PPM
      vorhanden ist?
    • Haben Sie die LDAP-Konfiguration aktiviert, indem Sie in der CSA auf der Seite "Eigenschaften" des Anwendungsservers das Feld "LDAP verwenden" ausgewählt haben?
    • Haben Sie in der CSA auf der Seite "Eigenschaften" des Sicherheitsservers im Feld "Nach Benutzer suchen" die richtige Benutzer-ID und im Feld "Kennwort" das richtige Kennwort eingegeben?
    • Spezifischere Meldungen finden Sie in den Protokolldateien.
    • Die Verarbeitungszeit für den Auftrag
      LDAP – Veraltete Benutzer
      synchronisieren oder den Auftrag
      LDAP – Neue und geänderte Benutzer
      synchronisieren hängt von der Anzahl der Benutzer ab, die vom Verzeichnisdienst in
      Classic PPM
      geladen werden. Eine große Anzahl kann zu längeren Verarbeitungszeiten führen.
Problembehandlung bei LDAP-Synchronisierungsaufträgen
Wenn ein LDAP-Synchronisierungsauftrag oder -Authentifizierungsprozess nicht erwartungsgemäß funktioniert, führen Sie eine der folgenden Aufgaben aus:
  • Überprüfen Sie die Protokolldateien der LDAP-Synchronisierung im Verzeichnis "/niku/Clarity/logs/ldapsync".
  • Überprüfen Sie die Datei "*users*.xml". Diese Datei enthält eine Liste mit Benutzernamen, die aus dem LDAP-Server extrahiert wurden. Wenn diese Datei fehlt, konnte die Kommunikation zwischen
    Classic PPM
    und dem LDAP-Server nicht erfolgreich durchgeführt werden.
  • Überprüfen Sie die Datei "*sync*.xml". Diese Datei enthält die Ergebnisse einer Gateway-Benutzerimportsitzung. Wenn diese Datei fehlt, konnte die Kommunikation zwischen
    Classic PPM
    und dem Gateway nicht erfolgreich durchgeführt werden.
  • Aktivieren Sie Debug-Meldungen in der Sicherheitskomponente, indem Sie die folgenden Schritte durchführen:
    1. Bearbeiten Sie die Datei
      "bg-logger.xml"
      , und fügen Sie die Kategorie
      com.niku.security
      hinzu.
    2. Setzen Sie die Priorität auf
      debug
      .
    3. Starten Sie den
      Clarity
      -Hintergrunddienst (bg) neu, damit die Änderungen in Kraft treten.
    4. Überprüfen Sie die Datei "bg-ca.log".
    5. Wenn in Ihrem Cluster mehrere bg-Dienste vorhanden sind, beenden Sie alle bis auf einen. Wenn nur ein bg-Dienst aktiv ist, wird sichergestellt, dass der Auftrag tatsächlich auf dem Server ausgeführt wird, den Sie debuggen. Sie können Debugging auch jeweils einzeln auf Dienstebene aktivieren.
Überprüfen der LDAP-Synchronisierungsprotokolle
Überprüfen Sie die Übertragungsprotokolle der LDAP-Synchronisierung, die sich im folgenden Verzeichnis befinden:
<Clarity Home Directory>/logs/ldapsync
Protokolldateien in Zusammenhang mit den Aufträgen zum Synchronisieren neuer und geänderter Benutzer:
  • ldapusers_nm_*.xml: Liste mit Benutzern, die sich im Verzeichnisserver befinden, der mit
    Classic PPM
    synchronisiert werden soll.
  • ldapsync_nm_*.xml: Liste mit Meldungen (Erfolg/Fehler/Warnung) für diesen Synchronisierungsauftrag.
Protokolldateien in Zusammenhang mit dem Auftrag
LDAP - Veraltete Benutzer synchronisieren
:
  • ldapusers_ia_*.xml: Liste mit Benutzern, die in
    Classic PPM
    deaktiviert werden sollen.
  • ldapsync_ia_*.xml: Liste mit Meldungen (Erfolg/Fehler/Warnung) für diesen Synchronisierungsauftrag.
Aktivieren von Debugging-Meldungen
Die Sicherheitskomponente erfasst Debug-Meldungen. Halten Sie alle
Clarity
-Hintergrunddienste (bg) in Ihrer Implementierung mit Ausnahme des Dienstes an, für den Sie Debug-Meldungen aktivieren. Starten Sie den
Clarity
-Hintergrunddienst (bg) neu, damit die Änderungen in Kraft treten, und prüfen Sie die Protokolldatei (bg-niku.log).
Gehen Sie wie folgt vor:
  1. Melden Sie sich bei CSA an.
  2. Klicken Sie auf Startseite, Server.
  3. Klicken Sie auf das Symbol "Protokolle" für den Server, für den Sie Debug-Meldungen aktivieren möchten.
  4. Klicken Sie auf die Unterregisterkarte "Konfiguration bearbeiten".
  5. Klicken Sie im Bereich "Kategorien" auf "Kategorie hinzufügen".
  6. Geben Sie den folgenden Wert für den neuen Einzelposten ein:
    • Name
      Geben Sie
      com.niku.security
      ein.
    • Priorität
      Wählen Sie "Debuggen" in der Dropdown-Liste aus.
  7. Speichern Sie die Änderungen.
    Debug-Meldungen sind aktiviert.
Konfigurieren von LDAP und SSL
Wenn ein LDAP-Server mit SSL (Secure Socket Layer) ausgeführt wird, müssen Sie LDAP und SSL konfigurieren. Der
Classic PPM
-Administrator muss das vertrauenswürdige Sicherheitszertifikat für den LDAP-Server auf dem Computer installieren, auf dem die
Clarity
-Hintergrunddienste (bg) ausgeführt werden. Um das Zertifikat zu installieren, verwenden Sie den keytool-Befehl des Java 7-JDK.
Geben Sie die folgenden Befehle über die Eingabeaufforderung ein:
keytool -import -v -trustcacerts -alias <alias> -file <certificate file name> -keystore cacerts
Beispiel:
$cd $JAVA_HOME/jre/lib/security $keytool -import -v -trustcacerts -alias NikuLdapServer -file TrustedRootCert.der -keystore cacerts
Konfigurieren von Single Sign-On (SSO) für
Classic PPM
Die Einzelanmeldung ist ein Authentifizierungsprozess, der es Benutzern ermöglicht, mit einem einzelnen Benutzernamen und Kennwort auf mehrere Systeme zuzugreifen. Nachdem der Server mithilfe der Informationen im LDAP-Verzeichnis die Identität eines Benutzers authentifiziert hat, gewährt er mit SSO entsprechend den Zugriffsberechtigungen des Benutzers Zugriff auf die angeforderten Informationen.
Sie können die Einzelanmeldung so festlegen, dass
Classic PPM
mit der internen Portalanwendung, für die der Benutzer authentifiziert wird, integriert wird. Dank der Einzelanmeldungsfunktion müssen Benutzer nicht jedes Mal ihren Benutzernamen und ihr Kennwort eingeben, wenn sie zwischen Anwendungen wechseln. Die Portalanwendung enthält Links (URLs) zu anderen internen Anwendungen. Nachdem die Portalanwendung einmal aufgerufen wurde, werden keine Authentifizierungsdialogfelder mehr angezeigt. Stattdessen werden die Benutzer direkt zur Anwendung weitergeleitet. Die Portalanwendung verfügt über ein Einzelanmeldungs-Plug-in, das die Benutzer zunächst auffordert, sich im Portal anzumelden, und sie anschließend zur gewünschten Anwendung weiterleitet. Auf diese Weise ist es nicht möglich, dass Benutzer eine Seite mit einem Lesezeichen versehen und dann später zurückkehren, ohne sich zuerst anzumelden.
Die Einzelanmeldung bietet die folgenden Vorteile:
  • Verwaltung von Benutzername und Kennwort. Die IT-Abteilung muss nur ein Benutzername-/Kennwortpaar für einen Benutzer verwalten.
  • Authentifizierungs-Support. Unterstützung seitens der IT-Abteilung ist nur erforderlich, wenn Benutzer Probleme bei der Authentifizierung haben.
  • Verwendbarkeit. Benutzer müssen sich nur einen Benutzernamen und ein Kennwort merken und sich nur einmal anmelden.
  • Sicherheit. Wenn nur ein Benutzername und ein Kennwort verwendet werden, ist es einfacher, komplexe Kennwörter zu verwenden und diese öfter zu ändern. Die Wahrscheinlichkeit ist geringer, dass ein naheliegendes Kennwort gewählt wird, wenn sich Benutzer nur an ein Kennwort erinnern müssen.
Best Practice:
Wenn Sie CA SiteMinder oder eine andere Software für Einzelanmeldung verwenden, konfigurieren Sie die Software so, dass eckige Klammern (< und >) in der URL erlaubt sind. Wenn Sie SiteMinder verwenden, deaktivieren Sie z. B "CssChecking". Andernfalls führen URLs mit eckigen Klammern zu Fehlern, wenn sie in
Classic PPM
verwendet werden. In gewissen Fällen enthalten URLs eckige Klammern, die meistens durch Prozesse mit Bedingungen wie <, <=, > oder >=) entstehen.
Gehen Sie wie folgt vor:
  1. Konfigurieren Sie den Server für die Einzelanmeldung und den Proxy-Server so, dass sie auf
    Classic PPM
    verweisen und ein Authentifizierungstoken übergeben, das einen gültigen
    Classic PPM
    -Benutzernamen enthält.
    Konfigurieren Sie den Server für die Einzelanmeldung so, dass die Eingabe-URL folgendermaßen lautet:
    http://<server>/niku/nu#action:npt.overview
  2. Melden Sie sich bei CSA an, und klicken Sie auf "Startseite", "Server".
  3. Klicken Sie auf den Namen des Servers, den Sie bearbeiten möchten.
  4. Klicken Sie auf die Unterregisterkarte "Anwendung".
  5. Um LDAP zu verwenden, aktivieren Sie im Bereich "Anwendungsserver" das Kontrollkästchen "LDAP verwenden".
    Wenn LDAP aktiviert ist, verwenden Nicht-Browser-Clients denselben Benutzernamen und dasselbe Kennwort.
  6. Aktivieren Sie im Bereich "Application Instance" (Anwendungsinstanz) das Kontrollkästchen "Einzelanmeldung verwenden", und klicken Sie auf "Speichern".
  7. Klicken Sie auf die Registerkarte Sicherheit.
  8. Füllen Sie im Bereich "Verschlüsselung" die folgenden Felder aus:
    • SSL-Schlüsselspeicher
      Gibt den Pfad zur Schlüsselspeicherdatei an.
      Beispiel
      : <Schlüsselspeicherpfad>/server.keystore.
    • SSL-Kennwort
      Gibt das Kennwort für den Schlüsselspeicher an. Bestätigen Sie die Eingabe im Feld "Kennwort bestätigen".
  9. Füllen Sie die folgenden Felder im Bereich "LDAP-Server" aus:
    • URL
      Gibt die LDAP-Server-URL an.
    • Stammkontext
      Gibt den Namenskontext für den LDAP-Server an, z. B.: "ou=People, dc=niku, dc=com".
    • Nach Benutzer suchen
      Gibt den Benutzernamen mit den entsprechenden Anmeldeinformationen für die Anbindung an den LDAP-Server an.
    • Kennwort
      Gibt das Kennwort für den LDAP-Server an. Bestätigen Sie die Eingabe im Feld "Kennwort bestätigen".
    • Batch-Größe
      Aktiviert den synchronen Vorgang. Legen Sie die Batch-Größe mithilfe der folgenden Kriterien fest:
      • 0. Alle vom Server empfangenen Ergebnisse werden sofort, wenn sie generiert werden, angenommen.
      • Zahl ungleich Null. Die Meldungen werden blockiert, bis
        n
        Meldungen vom Server empfangen wurden. Die Aufzählung wird fortgesetzt, weitere Meldungen werden in die Warteschlange gestellt.
      • Die Standardgröße des Batch beträgt 1. Eine Aufzählung der Suchergebnisse aus einem synchronen Suchvorgang gibt Meldungen sofort zurück, wenn sie vom Server empfangen werden.
    • Suchfilter
      Legt die Suchfilterzeichenfolge fest (wie in RFC 2254 definiert).
    • Datums-/Uhrzeitformat
      Legt das Format für Datum und Uhrzeit fest, das auf dem LDAP-Server verwendet wird.
    • Gruppenname
      Gibt die Gruppe an, die für Gruppenauthentifizierung aktiviert ist.
    • Gruppenkennung
      Gibt die Gruppen-ID für die Gruppe, die für Gruppenauthentifizierung aktiviert ist.
    • Nicht-LDAP-Benutzer zulassen
      Zeigt an, ob Nicht-LDAP-Benutzer auf die Anwendung mit einer alternativen Authentifizierungsmethode zugreifen dürfen.
  10. Füllen Sie die folgenden Felder im Bereich "LDAP-Attributzuordnung" aus:
    Benutzername
    Legt das Attribut für den Benutzernamen fest.
    Vorname
    Legt das Attribut für den Vornamen fest.
    Nachname
    Legt das Attribut für den Nachnamen fest.
    Vollständiger Name
    Legt das Attribut für den Nachnamen fest.
    E-Mail-Adresse
    Legt das Attribut für die E-Mail-Adresse fest.
    Zeitstempel ändern
    Legt das Attribut für die Änderung des Zeitstempels fest.
  11. Füllen Sie im Bereich "Einzelanmeldung" die folgenden Felder aus:
    Token-Name
    Gibt das HTTP-Cookie an, das
    Classic PPM
    als gültiges Authentifizierungstoken zum Initiieren einer Benutzersitzung akzeptiert.
    Token-Art
    Legt den Token-Typ fest. Werte sind:
    Cookie.
    Das Token ist in einem Cookie enthalten.
    Header.
    Das Token ist in der Kopfzeile der Nachricht enthalten.
    Parameter.
    Das Token wird in einem Parameter angegeben.
    Abmelde-URL
    Legt die vollständig qualifizierte URL fest, die angezeigt wird, wenn sich ein Benutzer abmeldet.
    Authentifizierungsfehler-URL
    Legt die vollständig qualifizierte URL fest, die angezeigt wird, wenn ein Benutzer nicht authentifiziert werden kann.
  12. Speichern Sie die Änderungen.
  13. Starten Sie die Anwendung neu, und melden Sie sich als Anwendungsadministrator bei
    Classic PPM
    an.
    Die Seite mit den Systemeinstellungen wird angezeigt.
Konfigurieren von Single Sign-On (SSO) für
Clarity
Um die SSO-Implementierung für
Clarity
zu aktivieren, konfigurieren Sie Ihren SSO-Server, wie in der folgenden Prozedur beschrieben. Die angegebenen Beispiele für die Konfigurationseinstellungen gelten für den SiteMinder-SSO-Server. Die Einstellungen können je nach SSO-Server, den Sie verwenden, unterschiedlich sein.
Bevor Sie Ihren SSO-Server für
Clarity
konfigurieren, stellen Sie sicher, dass SSO für
Classic PPM
aktiviert ist. Weitere Informationen finden Sie unter Konfigurieren von SSO für
Classic PPM
. Wenn SSO nicht für
Classic PPM
konfiguriert ist, dann funktioniert SSO für
Clarity
nicht.
Gehen Sie wie folgt vor:
  1. Schützen Sie die folgenden URLs für
    Clarity
    :
    https://<server:port>/pm*
    https://<server:port>/ppm/rest/*
    SiteMinder-Beispiel
    :
    Erstellen Sie in der vorhandenen Domäne, die den
    Classic PPM
    -Bereich hat, zwei neue Bereiche:
    Erstellen Sie einen Bereich mit einer Regel, um die REST-APIs zu schützen.
    • Name
      :
      Clarity
      -REST-API-Regel
    • Beschreibung
      : Regel zum Schutz der
      Classic PPM
      -Rest-APIs
    • Attribute
      ,
      Ressource
      : ppm/rest/*
    • Listenfeld
      Aktion
      ,
      Web-Agent-Aktion
      : Wählen Sie Get, Post, Put, Delete und Head aus
    Erstellen Sie einen Bereich mit einer Regel zum Schutz von
    Clarity
    .
    • Name
      :
      Classic PPM
      Neue Benutzeroberflächenregel
    • Beschreibung
      : Regel zum Schutz von
      Clarity
    • Attribute
      ,
      Ressource
      : pm*
    • Listenfeld
      Aktion
      ,
      Web-Agent-Aktion
      : Wählen Sie Get, Post, Put, Delete und Head aus
      Navigieren Sie nach Angabe der Regeln zur Registerkarte "Regeln", und fügen Sie die vorhandene
      Antwort
      aus SSO für
      Classic PPM
      zu jeder neuen Regel hinzu. Die Antwort gibt den Namen des Benutzernamen-Cookies und das Wertformat an, das
      Classic PPM
      -SSO erwartet.
    image2017-1-27 9:44:40.png
  2. Konfigurieren Sie die folgenden Eigenschaften für den Web-Agenten:
    1. Fügen Sie folgende URL zur vorhandenen Logoff-URL-Liste hinzu:
      https://<server:port>/ppm/rest/v1/auth/logout
    2. Fügen Sie folgende URL zur Liste der URLs hinzu, die ignoriert werden sollen:
      https://<server:port>//pm/js/core/layout/logout.html
    3. Fügen Sie folgende Dateierweiterungen zur Liste der ignorierten Erweiterungen hinzu:
      • .woff
      • .svg
      • .ttf
      • .eot
    4. Entfernen Sie einfache Anführungszeichen (wenn der Wert vorhanden ist) aus der Zeichenliste für ungültige URLs.
    5. Entfernen Sie einfache Anführungszeichen (wenn der Wert vorhanden ist) aus der Zeichenliste für ungültige Abfragen.
SiteMinder-Beispiel:
Ändern Sie folgende Agenteneigenschaften:
  • IgnoreExt:
    Fügen Sie die Dateierweiterungen .woff, .svg, .ttf und .eot in die Liste der ignorierten Erweiterungen hinzu.
  • IgnoreUrl
    : Fügen Sie /pm/js/core/layout/logout.html in die Liste der ignorierten URLs hinzu.
  • LogoffUri:
    Fügen Sie /ppm/rest/v1/auth/logout in die Logoff-URI-Liste hinzu.
  • BadUrlChars:
    Entfernen Sie die einfachen Anführungszeichen, wenn dieser Wert vorhanden ist.
  • BadQueryChars:
    Entfernen Sie die einfachen Anführungszeichen, wenn dieser Wert vorhanden ist.
Verwenden von LDAP mit der Einzelanmeldung
Sie können LDAP mit der Einzelanmeldung verwenden.
Best Practice
: Für die Einzelanmeldung ist es zwar nicht erforderlich, dass LDAP aktiviert ist, aber LDAP sollte aus den folgenden Gründen mit der Einzelanmeldung verwendet werden:
  • Nicht-Browser-Clients können die Vorteile der Einzelanmeldung optimal nutzen.
  • Wenn nur die Einzelanmeldung aktiviert ist, müssen Benutzerinformationen wie Namen und E-Mail-Adressen weiterhin in
    Classic PPM
    verwaltet werden. Wenn LDAP aktiviert ist, werden diese Daten im Verzeichnisserver gespeichert.
Verwenden von LDAP ohne die Einzelanmeldung
Die Einzelanmeldung bietet wenig zusätzliche Vorteile gegenüber LDAP. Benutzer müssen ihren Benutzernamen und ihr Kennwort in
Classic PPM
eingeben, alle anderen Vorteile werden jedoch auch durch LDAP geboten. Die Systemkonfiguration gestaltet sich für LDAP alleine viel einfacher. Bei LDAP ist kein Proxy-Server oder Einzelanmeldungs-Server und nur eine
Classic PPM
-Instanz erforderlich.
Optionen für Sicherheitslücken bei seitenübergreifendem Scripting (XSS) einstellen
Angriffe auf standortübergreifende Skripterstellung (XSS) fügen bösartige Skripte in ansonsten vertrauenswürdige Webseiten ein. Ein XSS-Angreifer verwendet eine Webanwendung, um bösartigen Code an einen Endbenutzer zu senden, im Allgemeinen in Form eines Browserseitenskripts. Diese Angriffe sind erfolgreich, wenn eine Webanwendung Benutzereingabedaten in die generierte Ausgabe einschließt, ohne zuerst die Eingabedaten zu validieren oder zu verschlüsseln.
Der Browser des Endbenutzers kann nicht ermitteln, ob das Skript bösartig ist. Weil das bösartige Skript von einer vertrauenswürdigen Quelle zu kommen scheint, führt der Browser den Code aus. Der Code kann auf Cookies, Sitzungs-Token oder andere vertrauliche Informationen zugreifen.
Um die XSS-Sicherheitslücken abzudecken, sollte jede Benutzereingabe, die an den Browser zurückgeschickt wird, zur Absicherung durch Eingabevalidierung überprüft werden. Benutzereingaben sollten richtig geschützt werden, bevor sie in die Ausgabeseite eingeschlossen werden. Ordnungsgemäße Ausgabeverschlüsselung stellt sicher, dass die Benutzereingabe immer als Text im Browser behandelt wird, nicht als aktiver Inhalt, der ausgeführt werden kann.
Zum Schutz vor XSS-Sicherheitslücken verarbeitet die Anwendung die Freigabe und Beschränkung von Benutzereingaben ab Version 14.1 und 14.2 entsprechend (Escape-Mechanismus). Um Änderungen an den Standardeinstellungen für Einschränkungen oder sonstige Hilfestellung bei XSS-Sicherheitsproblemen anzufordern, setzen Sie sich mit ca.com/support in Verbindung.
5
5
Validierung von XSS-Benutzereingaben
Classic PPM
überprüft, ob an den Browser zurückgesendete Benutzereingaben frei von XSS sind. Das Produkt vergleicht die Benutzereingabe mit einem Satz von Zeichenfolgemustern, die häufig für XSS verwendet werden. Wenn ein Teil der Benutzereingabe mit einem dieser häufig verwendeten Mustern übereinstimmt, schränkt
Classic PPM
die XSS-Zeichenfolge in der Benutzereingabe ein (versieht sie mit Escape-Zeichen).
Das Produkt beschränkt die XSS-Zeichenfolge mittels Escape-Zeichen vor und nach der Zeichenfolge. Diese Zeichen sind für den Endbenutzer sichtbar. Die Escape-Zeichen weisen den Browser an, Skript- oder HTML-Tags, die an die Benutzereingabe angefügt sind, zu ignorieren.
Standardmäßig ist die XSS-Erkennung aktiviert. URL-Attribute und Website-Links sind von dieser Prüfung ausgenommen. Weitere Informationen zum Ändern dieser Einstellungen finden Sie unter "Festlegen von Einschränkungen für XSS-Benutzereingaben".
Festlegen von Einschränkungen für XSS-Benutzereingaben
Benutzereingaben, die eines der häufigen XSS-Muster enthalten, müssen mit Escape-Zeichen versehen werden, bevor Sie auf die Ausgabeseite gelangen. Diese Ausgabekodierung stellt sicher, dass die Benutzereingabe als Text und nicht als aktiver, ausführbarer Inhalt behandelt wird. Über Verwaltungsoptionen können Sie XSS-Einschränkungen (den Escape-Mechanismus) aktivieren oder deaktivieren.
Um die Einstellung für ein Option zu ändern, führen Sie SQL-Datenbankanweisungen aus.
Gehen Sie wie folgt vor:
  1. Greifen Sie auf die Datenbanktabelle CMN_OPTION_VALUES zu.
  2. Aktualisieren Sie den Tabelleneintrag für die gewünschte Option. Informationen zu den einzelnen Optionen finden Sie in den Beschreibungen der Optionen.
  3. Leeren Sie den Cache-Speicher.
Option für XSS-Einschränkung
Dies Option beschränkt die XSS-Zeichenfolge in der Benutzereingabe, wenn sie einem Muster in der Option CMN.XSS.PATTERNS entspricht. Diese Systemoption gilt für die gesamte
Classic PPM
-Anwendung mit Ausnahme von URL-Attributen und Website-Links. Sie können Einschränkungen für URL-Attribute und Website-Links über separate Optionen festlegen.
  • RESTRICT.APP.XSS
    Werte: True (Einschränkungen aktiviert), False (Einschränkungen deaktiviert)
    Standard: True
Der Inhalt von "HtmlPortlet" ist nicht eingeschränkt (er enthält keine Escape-Zeichen). HTML-Portlets führen alle Skripts im HTML-Inhalt aus. Dies ist das erwartete Verhalten.
Um die Option RESTRICT.APP.XSS zu ändern, aktualisieren Sie die Datenbanktabelle CMN_OPTION_VALUES mit folgender SQL-Anweisung:
update cmn_option_values set value='false|true' where option_id = (select id from cmn_options where option_code=' RESTRICT.APP.XSS')
Sicherheitshinweise
: Durch die Anwendung dieses Befehls zum Aktualisieren wird nicht verhindert, dass ein Javascript in ein HTML-Portlet codiert wird und dieser Javascript auf dem Client-Rechner ausgeführt wird. Als Administrator konzentrieren Sie sich auf Server und schützen diese vor Meltdown und Spectre. Sie sorgen sich weniger über potenziell gefährlichen Javascript auf Client-Rechnern, da Sie nicht so viel Kontrolle darüber haben.
Um einen schwerwiegenderen Angriff starten zu können, muss der Angreifer in der Lage sein, den Code auf dem Prozessor des Opfers auszuführen. Zum Rendern von modernen Websites muss die jeweilige Web-JavaScript-Engine zulassen, dass ein nicht vertrauenswürdiger JavaScript-Code auf dem Prozessor des Benutzers ausgeführt werden kann. Ein Javascript, der Teil eines HTML-Portlets ist, wird auf dem Client-Rechner im Browser und nicht auf dem Server ausgeführt.
Clarity
führt kein serverseitiges Javascript aus.
Die XSS-Einschränkungen filtern Parameter in Formular-Beiträgen und URLs heraus, die möglicherweise bösartigen Javascript-Code enthalten, der bei Rücksendung zum Client-Browser ausgeführt wird und den Client-Rechner potenziell schaden kann. Diese Einschränkungen werden von Filtern in der Webanwendung gehandhabt, die auf eine vom Client an den Server übermittelte Anforderung mit der Absicht funktionieren, dass die Antwort an den Client ausgeführt oder dermaßen umgeleitet wird, damit der Client nicht gefährdet wird. Ein von einem Benutzer mit Javascript codierter HTML-Portlet durchläuft diese Filter nicht. Es ist eine Antwort auf eine von
Clarity
durchzuführende Aktion, z. B. um ein Portlet anzuzeigen. Die Antworten durchlaufen den Filter nicht. Wenn also ein Benutzer ein HTML-Portlet codiert und Javascript darin einfügt, wird der Javascript-Code nur auf seinem eigenen Client-Rechner ausgeführt.
Option für URL-Attributwert bei XSS-Sicherheitsproblemen
Diese Option beschränkt den (in Studio erstellten) URL-Attributwert, wenn er einem Muster in der Option CMN.XSS.PATTERNS entspricht.
  • RESTRICT.URL.ATTR.XSS
    Werte: True (Einschränkungen aktiviert), False (Einschränkungen deaktiviert)
    Standard: False
Um die Option RESTRICT.URL.ATTR.XSS zu ändern, aktualisieren Sie die Datenbanktabelle CMN_OPTION_VALUES mit folgender SQL-Anweisung:
update cmn_option_values set value='false|true' where option_id = (select id from cmn_options where option_code=' RESTRICT.URL.ATTR.XSS')
Option für Website-Links bei XSS-Sicherheitsproblemen
Diese Option beschränkt den Eingabewert für Website-Links, wenn er einem Muster in der Option CMN.XSS.PATTERNS entspricht.
  • RESTRICT.SITE.LINKS.XSS
    Werte: True (Einschränkungen aktiviert), False (Einschränkungen deaktiviert)
    Standard: False
Um die Option RESTRICT.SITE.LINKS.XSS zu ändern, aktualisieren Sie die Datenbanktabelle CMN_OPTION_VALUES mit folgender SQL-Anweisung:
update cmn_option_values set value='false|true' where option_id = (select id from cmn_options where option_code=' RESTRICT.SITE.LINKS.XSS')
Option für häufige XSS-Muster
Diese Option definiert Zeichenfolgenmuster, die häufig für XSS verwendet werden. Sie können zu dieser Option Werte hinzufügen, um weitere Zeichenfolgenmuster einzuschließen.
  • 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]*\\\'(.*?)\\\'
Um Muster hinzuzufügen, greifen Sie auf die Datenbanktabelle CMN_OPTION_VALUES zu, und fügen Sie die neuen Muster in die Option CMN.XSS.PATTERNS ein.
Beispiel: Hinzufügen des neuen Musters "onfocus" zur Option 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
Security-Antwortkopfzeile: X-XSS-Schutz und Optionen für X-Inhaltstypen
Webbrowser verfügen standardmäßig über zwei Security-Antwortkopfzeilen als zusätzliche Schutzebene.
  • X-XSS-Schutz
    : Die Kopfzeile
    X-XSS-Protection
    zwingt den XSS-Filter in den Modus "Aktivieren", auch wenn er deaktiviert ist. Diese Antwortkopfzeile wird von den Browsern Internet Explorer, Chrome und Safari unterstützt und hindert Seiten am Laden, wenn der Browser zurückgespiegelte XSS-Angriffe erkennt. Diese Antwortkopfzeile ist in modernen Browsern dann nicht erforderlich, wenn Anwendungen eine wirkungsvolle Content-Security-Policy (CSP) implementieren, die die Verwendung von unsicherem Inline-JavaScript verhindert. Obwohl die Sicherheitsmaßnahmen bei
    Clarity
    in dieser Hinsicht einen hohen Standard erfüllen, bietet die Anwendung diesen Schutz auch für Benutzer älterer Browser, die CSP noch nicht unterstützen.
  • Optionen für X-Inhaltstypen
    : Die
    X-Content-Type-Options
    Kopfzeile ist ein Marker, die der Server verwendet, um Änderungen an den in den Kopfzeilen für den Inhaltstyp festgelegten MIME-Typen zu verhindern.
Sollten wider Erwarten Probleme auftreten, können Sie die Kopfzeilen einzeln oder alle auf einmal mit den folgenden SQL-Befehlen in der Netzwerkantwort deaktivieren:
  • So deaktivieren Sie
    Optionen für X-Inhaltstypen: 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%'
  • So deaktivieren Sie
    X-XSS-Schutz: 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%'
  • So deaktivieren Sie alle Header:
    call CMN_OPTION_VALUES_DEL_SP('ENABLED_RESPONSE_HEADERS');
Externe URLs
Die externalUrl-Eigenschaft ist eine optionale Anwendungseinstellung, die externe oder Verbund-Authentifizierungsschemas in Benachrichtigungen unterstützt. Wenn "externalUrl" nicht angegeben ist, wird für
Classic PPM
-Benachrichtigungen mit URLs die standardmäßige Eigenschaft "entryUrl" verwendet.
Die standardmäßige entryUrl-Eigenschaft verweist direkt auf den
Classic PPM
-Server. Durch die Eigenschaft "externalUrl" wird die Anforderung zuerst an einen externen Server umgeleitet, der die Anmeldungsauthentifizierung für die Sitzung durchführt. Der externe Server leitet die ursprüngliche Anforderung mithilfe von Single Sign-On (SSO) zurück an
Classic PPM
. Über diese Methode wird sichergestellt, dass sich der Benutzer nicht direkt in
Classic PPM
anmelden muss. Wenn der Benutzer auf eine Benachrichtigungsverknüpfung klickt, wird die externe Authentifizierung durchgeführt und die Anforderung an
Classic PPM
weitergeleitet. Wenn der Benutzer bereits angemeldet ist, wird die Anforderung automatisch ohne Unterbrechung weitergeleitet.
Die externe URL ersetzt nicht die standardmäßige Eingabe-URL, sondern ergänzt diese. Die aus den beiden URLs bestehende zusammengesetzte URL enthält externe und interne Adressen, die verschlüsselt sind, um sicherzustellen, dass eingebettete URLs ordnungsgemäß übergeben werden. Der Authentifizierungspfad kann mehrere Server einschließen, sodass URLs im Allgemeinen Abfrageparameter enthalten, die jedem Server das Ziel für die Umleitung nach dem Verarbeiten der Anforderung mitteilen.
Die externalUrl-Eigenschaft unterstützt die folgenden Makros:
  • ${entryurl}
    Fügt die aktuelle entryUrl-Konfigurationseigenschaft ein.
  • replace(regex,replacement,text)
    Ersetzt alle Instanzen von "regex" mit "replacement" in "text".
  • encode()
    Ersetzt den Text durch UTF-8-kodierten Text.
Makros können verbunden und verschachtelt werden.
Geben Sie eingeschränkte XML-Zeichen, z. B. kaufmännische Und-Zeichen, in Form des entsprechenden Entitätsnamens (, &) ein. Andernfalls können keine
Classic PPM
-Dienste gestartet werden.
Beispiel: Erstellen einer externen URL
Der Authentifizierungspfad für eine bestimmte Umgebung bestimmt "externalUrl". Der Authentifizierungspfad enthält namentlich die Adressen von jedem Server im Pfad und die Parameter, die jeder Server erfordert. Bevor Sie diesen Wert festlegen, erfassen Sie die erforderlichen Informationen, um den Pfad zu bestimmen.
Umgebungsbeispiel:
  • Server 1
    Zweck
    : Externer Authentifizierungsserver
    Adresse
    : http://auth.somecompany.com
    Erforderliche Parameter
    : REDIRECT
    Beschreibung
    : Authentifiziert (ggf. einschließlich Anmeldung) und leitet dann an die im REDIRECT-Parameter angegebene Adresse um.
  • Server 2
    Zweck
    : Interner Authentifizierungsserver
    Adresse
    : http://sso.mycompany.com
    Erforderliche Parameter
    : TARGET
    Beschreibung
    : Führt die interne Einzelanmeldung durch und leitet die Anforderung dann an die im TARGET-Parameter angegebene Adresse um.
  • Server 3
    Zweck
    :
    Classic PPM
    -Anwendungsserver
    Adresse
    : http://ca_ppm.mycompany.com
    Erforderliche Parameter
    : Alle standardmäßigen
    Classic PPM
    -Parameter
    Beschreibung
    : Die Adresse, die in "entryUrl" angegeben ist.
Anforderungen werden also zunächst an das externe Identitätsverwaltungssystem unter http://auth.somecompany.com geleitet. Anschließend werden die Anforderungen an den internen Einzelanmeldungs-Server unter http://sso.mycompany.com und schließlich an den Server unter http://ca_ppm.mycompany.com geleitet.
Gehen Sie wie folgt vor:
  1. Die Erstellung der externen URL beginnt, wenn Sie den ersten Stopp hinzufügen, den externen Authentifizierungsserver:
    externalUrl=http://auth.somecompany.com
    Dieser Server benötigt einen Parameter, REDIRECT, der angibt, wohin der Server die Anforderung nach der Verarbeitung leiten soll. In diesem Beispiel soll die Anforderung an den internen Authentifizierungsserver geleitet werden:
    externalUrl=http://auth.somecompany.com?REDIRECT=http://sso.mycompany.com
  2. Der interne Einzelanmeldungs-Server benötigt einen Parameter, TARGET, der die standardmäßige
    Classic PPM
    -Eingabe-URL enthält. Das ${entryurl}-Makro wird automatisch auf die aktuelle entryUrl-Einstellung erweitert, wenn Benachrichtigungen gesendet werden:
    externalUrl=http://auth.somecompany.com?REDIRECT=http://sso.mycompany.com?TARGET=${entryurl}
  3. Die externe URL ist fast vollständig. Es fehlt nur ein Schritt.
    Der Parameter REDIRECT für Server 1 enthält Zeichen, die UTF-8-kodiert werden müssen, damit sie in einer Abfragezeichenfolge sicher weitergeleitet werden können. Das Kodierungsmakro geht darauf ein:
    externalUrl=http://auth.somecompany.com?REDIRECT=encode(http://sso.mycompany.com?TARGET=${entryurl})
    Server 2 verfügt auch über einen Parameter, der kodiert werden muss:
    externalUrl=http://auth.somecompany.com?REDIRECT=encode(http://sso.mycompany.com?TARGET=encode(${entryurl}))
    Die encode()-Makros sind verschachtelt. Die Verschachtelung führt dazu, das innere Makro doppelt kodiert ist, d. h. der UTF-8-kodierte Text wird ein zweites Mal kodiert. Die doppelte Kodierung ist erforderlich, weil Server 1 den vollständigen REDIRECT-Parameter am ersten Stopp dekodiert und Server 2 einen UTF-8-kodierten Parameter erwartet. Das Kodierungsmakro kann so oft verschachtelt werden, wie erforderlich ist, um sicherzustellen, dass der letzte Parameter über die richtige Kodierung verfügt.
Der Anforderungs-Lebenszyklus
Wenn eine neue
Classic PPM
-E-Mail-Benachrichtigung generiert wird, werden die Eigenschaften "externalUrl" und "entryUrl" verwendet, um eine entsprechende Click-Through-URL für das Ereignis zu generieren. Die standardmäßige URL (ohne externalUrl) kann folgendermaßen aussehen:
http://ca_ppm.mycompany.com/niku/nu#action:timeadmin.currentTimesheet
Wenn die externalUrl-Eigenschaft wie in diesem Beispiel aktiviert ist, sieht die generierte URL wie folgt aus:
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
Bei diesem Beispiel handelt es sich um eine URL, die auf Server 1 verweist, und einen einzelnen Parameter mit den Adressen von Server 2 und Server 3 und Eigenschaften mit UTF-8-Kodierung (die Eingabe-URL ist doppelt kodiert). Wenn ein Benutzer auf diese URL klickt, wird die Anforderung an Server 1 gesendet (http://auth.somecompany.com). Server 1 dekodiert den Parameter (den gesamten Text nach REDIRECT=) in:
http://sso.mycompany.com?TARGET=http%3A%2F%2Fca_ppm.mycompany.com%2Fniku%2Fnu%23action%3Atimeadmin.currentTimesheet
Server 1 verwendet die URL für die Weiterleitung an Server 2. Die Parameterzeichenfolge für Server 2 ist weiterhin kodiert, obwohl die vollständige Abfragezeichenfolge von Server 1 dekodiert wurde. Dieses Beispiel veranschaulicht die Auswirkungen der doppelten Kodierung. Server 2 dekodiert anschließend den TARGET-Parameter in Folgendes:
http://ca_ppm.mycompany.com/niku/nu#action:timeadmin.currentTimesheet
Die vorangehende URL ist der endgültige URL. Die URL ist dekodiert und kann von
Classic PPM
verarbeitet werden. Währenddessen sind Server 1 und Server 2 ihren Authentifizierungspflichten nachgekommen. Wenn die Anforderung schließlich bei
Classic PPM
ankommt, enthält sie das korrekte Einzelanmeldungs-Authentifizierungstoken, um den Benutzer zu identifizieren. Abgesehen von der Generierung der korrekten URL bei der Benachrichtigung ist
Classic PPM
nicht am Authentifizierungsprozess beteiligt.
Problembehandlung in Bezug auf externe URLs
Um eine problematische externe URL zu korrigieren, muss bekannt sein, welche Werte jeder Server in der Kette erwartet. Nur so können Sie sicherstellen, dass die URLs und Parameter an jeder Stelle korrekt kodiert sind. Sie können eine bestimmte Benachrichtigungs-URL mithilfe der folgenden Schritte manuell überprüfen.
Gehen Sie wie folgt vor:
  1. Beschaffen Sie sich ein Dienstprogramm für die UTF-8-Dekodierung. Ein einfaches Dienstprogramm kann heruntergeladen werden.
  2. Generieren Sie eine Benachrichtigungs-E-Mail mit der aktuellen externen URL-Einstellung.
  3. Überprüfen Sie die URL, und stellen Sie sicher, dass der erste Teil der URL auf Server 1 verweist. Der erste Teil der URL umfasst alles bis zum ersten Fragezeichen.
  4. Verwerfen Sie alles bis zum ersten Fragezeichen (einschließlich des Fragezeichens), sodass nur die Parameterzeichenfolge übrig bleibt, die an Server 1 übergeben wurde.
  5. Dekodieren Sie die verbleibende Zeichenfolge mit dem Hilfsprogramm für die UTF-8-Dekodierung.
    Die dekodierte Zeichenfolge steht für die Parameter, die an Server 1 übergeben werden. Stellen Sie sicher, dass die Parameter korrekt sind.
  6. Verwerfen Sie den Parameternamen (in diesem Beispiel REDIRECT), und stellen Sie sicher, dass der erste Teil der URL auf Server 2 verweist. Auch in diesem Fall ist alles bis zum Fragezeichen im ersten Teil der URL enthalten.
  7. Verwerfen Sie erneut alles bis zum Fragezeichen, und dekodieren Sie dann die verbleibende Zeichenfolge einmal.
  8. Überprüfen Sie Folgendes:
    • Der erste Teil der URL verweist auf den
      Classic PPM
      -Server.
    • Die verbleibende Abfragezeichenfolge enthält standardmäßige
      Classic PPM
      -Parameter.
    • Die Parameter sind nicht kodiert.
Wie werden Benutzersitzungen in
Classic PPM
nachverfolgt?
Ein sitzungsbasiertes Cookies verfügt über ein Token, das verwendet wird, um auf Sitzungsdaten zuzugreifen, die an folgenden Speicherorten aufbewahrt werden:
  • Cache (für Umgebungen mit einer einzigen Anwendung)
  • Datenbank (für Clusterumgebungen)
Schränkt dies die Umgebung ein?
Der Webbrowser des Endbenutzers muss Cookies von der
Classic PPM
-Anwendung akzeptieren. Die Cookies sind sitzungsbasiert, sodass sie nicht auf dem Datenträger gespeichert werden.
Hat dieses Verfahren Auswirkungen auf Lastenausgleichsmodule oder Cluster?
Lastenausgleich und Clustering sind mit diesem Verfahren problemlos möglich. In vielen Unternehmen enthält
Classic PPM
Lastenausgleich und Cluster.
Kann eine Sitzung versehentlich oder absichtlich böswillig übernommen werden?
Um die Sitzung eines anderen Benutzers aus böswilligen Gründen zu übernehmen, muss der HTTP-Datenverkehr belauscht werden, um die Header mit dem Authentifizierungscookie zu entnehmen. Dieses Token ist jedoch nur gültig, solange der richtige Benutzer angemeldet ist. Nachdem sich dieser Benutzer abgemeldet hat, werden die Sitzungsinformationen in der Datenbank oder im Cache, in der bzw. in dem in
Classic PPM
der Cookie-Wert gespeichert ist, gelöscht.
Wie können Protokolle frei von Sitzungs-IDs gehalten werden?
Als Sicherheitsmaßnahme können Sie
Classic PPM
so konfigurieren, dass in Ihren Protokolldateien keine Sitzungs-IDs angezeigt werden. Bearbeiten Sie die Datei "logger.xml", um zu verhindern, dass diese Werte angezeigt werden. Ersetzen Sie das Protokollmuster (%u:%s:%a) durch das Muster (%U:%a).
Die folgenden Beispiele enthalten die Ergebnisse der Verwendung beider Muster in der Datei "logger.xml".
Beispiel: (%u:%s:%a)
Diese Codezeile zeigt an, wie das Muster für die Anzeige des Werts für die Sitzungs-ID in der Datei "logger.xml" erscheint.
<param name="ConversionPattern" value="%-5p %d{ISO8601} [%t] %c{2} (%u:%s:%a) %m\r\n"/>
Dieses Muster erzeugt Datensätze in einer Protokolldatei, die Werte für Sitzungs-IDs enthalten. Der folgende Datensatz aus der Datei "app-ca.log" enthält Werte für Sitzungs-IDs (fett):
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) Adding view FILTER_VIEW_LOADER::USER:NIKU.ROOT to transient cache
Beispiel: (%U:%a)
Diese Codezeile zeigt an, wie das Muster für die Vermeidung der Anzeige des Werts für die Sitzungs-ID in der Datei "logger.xml" erscheint.
<param name="ConversionPattern" value="%-5p %d{ISO8601} [%t] %c{2} (%U:%a) %m\r\n"/>
Dieses Muster erzeugt Datensätze in einer Protokolldatei, die keine Werte für die Sitzungs-ID enthalten. Das folgende Beispiel ist ein Datensatz aus der Datei "app-ca.log" ohne Werte für Sitzungs-IDs.
DEBUG 2014-08-18 19:52:02,494 [http-bio-80-exec-3] in.service (admin:npt.overview)
Classic PPM
unterstützt weitere Protokollierungsmuster, wenn das Layout in der Datei "logger.xml" für einen Appender auf "NikuLayout" gesetzt ist.
Musteroption
Zweck
u
Erstellt die Benutzer-ID in der Protokolldatei mit der Mandanten-ID.
Beispiel: (%u) erstellt im Protokoll die Ausgabe (clarity:admin).
U
Erstellt die Benutzer-ID in der Protokolldatei.
Beispiel: (%U) erstellt im Protokoll die Ausgabe (admin).
s
Erstellt die Sitzungs-ID im Protokoll.
Beispiel: (%s) erstellt im Protokoll die Ausgabe (5077018__8DF3B2A0-F398-4A4B-BC35-E9A012065CE0).
a
Erstellt die Aktions-ID im Protokoll.
Beispiel: (%a) erstellt im Protokoll die Ausgabe (npt.overview).
Weitere Informationen zu unterstützten Mustern in Version 1.2 von log4j finden Sie in der API-Dokumentation für die Klasse "PatternLayout" auf https://logging.apache.org.