security.manager Nutzerinteraktionen

Übersicht

service.monitor kann in andere con terra Produkte integriert werden, so dass auch dort aktiv Daten über die Nutzung der Applikationen gesammelt werden. Ist die Integration erfolgt, werden folgende Parameter beim Zugriff des Clients mitprotokolliert:

grundlegende HTTP Anfrageparameter (URL, Protokoll)
grundlegende HTTP Antwortparameter (Dauer, HTTP Status Code)
User Agent
Authentifizierungsinformationen
Client IP

Ablauf

Konfigurationen für die map.apps Client-Integration befolgen
Integration von map.apps und security.manager Enterprise Edition (Server) (siehe unten)

Integration von map.apps und security.manager Enterprise Edition (Server)

security.manager
Version	Kommentar
< 4.15	Bitte aktualisieren Sie zunächst security.manager
4.15 - 4.18	Vorgehen wie unten beschrieben
ab 4.19	Die wss-Webapplikation ist bereits für die Integration vorbereitet, die Aktivierung erfolgt ausschließlich über die `application.properties` (siehe Anleitung unten). Die administration-Webapplikation kann analog manuell integriert werden (siehe Anleitung unten).

map.apps
Version	Kommentar
ab 4.7	Vorgehen wie unten beschrieben

INFO: Mit der Version 4.6.0 des service.monitor wurde die Datei ct-analytics-usagelog-api-<version>.jar umbenannt und heißt nun ct-monitor-analytics-message-extender-<version>.jar. Bitte beachten Sie dies in zukünftigen security.manager Versionen.

security.manager Enterprise Edition

Um Informationen über Requests an security.manager zu sammeln, muss der der Installation zugehörige GelfWebSecurityProcessor aktiviert werden. Der Prozessor sendet seine Daten üblicherweise per UDP Protokoll an die Logstash Pipeline, alternativ ist TCP-Versand möglich.

Gehen Sie zur Installation und Konfiguration wie folgt vor:

Installations- und Konfigurationsschritte (ab Version 4.19)

Die notwendigen Bibliotheken werden seit dieser Version für die wss-Webapplikation direkt mit ausgeliefert und müssen lediglich über die application.properties definiert/überschrieben werden. Dafür ist nur Schritt 1 nötig. Eine manuelle Integration der administration-Webappikation erfolgt durch die darauffolgenden Schritte.

Die konkrete Definition der Verbindungsparameter erfolgt in [SECURITY_MANAGER_DATA_FOLDER]/application.properties

analytics.enabled=true
analytics.gelf.host=myserver.domain.de
analytics.gelf.port=12201
analytics.gelf.protocol=udp
analytics.gelf.identifier=security.manager

Nur administration-Webapp:
1. Kopieren folgender Dateien von [security.manager]/webapps/wss/WEB-INF/lib nach [security.manager]/webapps/administration/WEB-INF/lib
  1. ct-monitor-analytics-message-extender-<version>.jar
  2. gelfclient-<version>.jar
  3. netty-all-<version>.Final.jar
2. Manuelles Anpassen der Datei [security.manager]/webapps/administration/WEB-INF/classes/spring-filter-config.xml:
  1. Hinzufügen der Bean-Referenz <ref bean="monitorAnalyticsFilter"/> hinter <ref bean="webSecurityFilter"/> (~ Zeile 50)
  2. Einfügen des unten stehenden Ausschnittes vor dem schließenden Beans-Element am Ende der Datei
    
    <bean id="monitorAnalyticsFilter" factory-bean="monitorAnalyticsFilterFactory" factory-method="create"/> <bean id="monitorAnalyticsFilterFactory" class="de.conterra.usagelog.support.SecmanEEMonitorFilterFactory" destroy-method="close" p:enabled="${analytics.enabled}" p:identifier="${analytics.gelf.identifier}" p:gelfHost="${analytics.gelf.host}" p:gelfPort="${analytics.gelf.port}" p:gelfProtocol="${analytics.gelf.protocol}" />
Der Servlet-Container muss nach erfolgter Änderung neu gestartet werden.

Installations- und Konfigurationsschritte (vor Version 4.19)

Um Informationen über Requests an security.manager zu sammeln, muss der der Installation zugehörige GelfWebSecurityProcessor aktiviert werden. Der Prozessor sendet seine Daten üblicherweise per UDP Protokoll an die Logstash Pipeline, alternativ ist TCP-Versand möglich.

Die *.jar Dateien aus /resources/analytics/webapp-integration/lib
1. nach [security.manager]/webapps/wss/WEB-INF/lib
2. nach [security.manager]/webapps/administration/WEB-INF/lib
Die Datei /resources/analytics/webapp-integration/security.manager-<version>/spring-filter-config-administration.xml:
1. nach [security.manager]/webapps/administration/WEB-INF/classes/spring-filter-config.xml
Die Datei /resources/analytics/webapp-integration/security.manager-<version>/spring-filter-config-wss.xml:
1. nach [security.manager]/webapps/wss/WEB-INF/classes/spring-filter-config.xml

Die konkrete Definition der Verbindungsparameter erfolgt in [SECURITY_MANAGER_DATA_FOLDER]/application.properties

analytics.gelf.server=myserver.domain.de
analytics.gelf.port=12201
analytics.message.src=security.manager
analytics.log.enabled=true

Der Servlet-Container muss nach erfolgter Änderung neu gestartet werden.

map.apps

Um Informationen über Requests an map.apps zu sammeln, muss der der Installation zugehörige GelfWebSecurityFilter aktiviert werden. Der Prozessor sendet seine Daten üblicherweise per UDP Protokoll an die Logstash Pipeline, alternativ ist TCP-Versand möglich.

Gehen Sie zur Installation und Konfiguration wie folgt vor:

Kopieren Sie folgende Dateien:
- die JAR Dateien aus /resources/analytics/webapp-integration/lib
  nach [map.apps]/WEB-INF/lib und
- die Datei /resources/analytics/webapp-integration/map.apps-<version>/spring-filter-config.xml
  nach [map.apps]/WEB-INF/classes/spring-filter-config.xml.

Die konkrete Definition der Verbindungsparameter erfolgt in [MAP_APPS_DATA_FOLDER]/application.properties

analytics.gelf.server=myserver.domain.de
analytics.gelf.port=12201
analytics.message.src=map.apps
analytics.log.enabled=true

Der Servlet-Container muss nach erfolgter Änderung neu gestartet werden.

Viele con terra Produkte unterstützen grundsätzlich die oben dargestellten Integrationswege mit service.monitor. Bitte fragen Sie nach Support Plus oder Dienstleistungen für zusätzliche Unterstützung.

Logging-Parameter

useragent

Informationen über Browsers und Betriebssystem.

Beispiel:

"user_agent": "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0"

client_ip

Anonymisierte Client IP.

Beispiel:

"client_ip": "123.12.12.000"

request

Informationen zu Anfrage-Parametern.

Beispiel:

"request": {
  "server_host": "test.remote.host.com",
  "url_query": "?queryProperty=testvalue",
  "server_context: "/wss",
  "referrer": "http://www.mytest.de",
  "protocol": "https"
}

auth

Authentifizierungsinformationen.

Beispiel:

"auth": {
  "authenticated": true,
  "user_id": "userA",
  "login_time": "2011-17-10 11:17:50",
  "group_name": "sampleGroup",
  "roles": [
    "admin",
    "editor"
  ]
}

response

Informationen zu Antwort-Parametern.

Beispiel:

"response": {
  "status": 200
}

response_time

Antwortzeit in Nano-Sekunden und Antwortzeit in Milli-Sekunden.

Beispiel:

"response_time": 12345678,
"response_time_ms": 1234.5678