HTTP-Sicherheits-Session-Management auf dem AS ABAP aktivieren 
Sie können optional HTTP-Sicherheits-Sessions verwenden und diese pro Mandant des AS ABAP aktivieren oder deaktivieren. Benutzer können dann Anwendungen, die eine Benutzeranmeldung erfordern, bei bestehender Sicherheits-Session ohne erneute Anmeldung starten. Bei Beendigung einer Sicherheits-Session beendet das System auch alle Anwendungen, die mit dieser Sicherheits-Session verknüpft sind.
Eine Sicherheits-Session beginnt mit der Anmeldung am System und endet mit der Abmeldung vom System. Dabei gibt es folgende Möglichkeiten der Abmeldung:
durch den Benutzer
durch den Systemverwalter
Ein Systemverwalter kann eine HTTP-Sicherheits-Session (und alle mit dieser Sicherheits-Session verknüpften Anwendungs-Sessions) über Transaktion SM05 beenden. Das Security Audit Log protokolliert dieses Ereignis.
durch Inaktivität, d.h. ausbleibender HTTP-Kommunikation mit dem System.
Sie können die Zeitspanne, ab der das System eine ausbleibende Kommunikation als Benutzerinaktivität wertet, parametrisieren (Profilparameter http/security_session_timeout).
Folgende Profilparameter sind für das HTTP-Sicherheits-Session-Management relevant.
Profilparameter |
Mögliche Werte |
Weitere Hinweise |
|---|---|---|
login/create_sso2_ticket |
0: Keine Tickets erstellen (SSO-Tickets) 1: SSO-Ticket samt Zertifikat erstellen 2: SSO-Ticket ohne Zertifikat erstellen 3: Nur Zusicherungstickets (keine Anmeldetickets) erstellen |
Lässt die Erzeugung von Anmelde- oder Authentifizierungszusicherungstickets zu.
SAP empfiehlt Ihnen, für ein ausstellendes System den Wert 3 mit Sicherheits-Session-Management zu verwenden. Die Verwendung von Anmeldetickets mit Sicherheits-Session-Management verhindert, dass die Funktion, die eine automatische Abmeldung wegen Inaktivität verursacht, einwandfrei funktioniert. Mit diesem Wert stellt das System weiterhin Zusicherungstickets aus, die für die Kommunikation zwischen Systemen verwendet werden. Wenn Sie Anmeldetickets unbedingt benötigen, empfiehlt Ihnen SAP, den Wert 2 zu verwenden, da Tickets ohne Zertifikate eine geringere Größe haben. Bei empfangenden Systemen empfiehlt Ihnen SAP, die Ticket-Erzeugung zu deaktivieren, also den Wert 0 zu verwenden. Weitere Informationen finden Sie im SAP-Hinweis 1562004. Ende der Empfehlung. |
login/accept_sso2_ticket |
0: Anmeldung mit Tickets ist unzulässig 1: Anmeldung mit Tickets ist zulässig |
Legt fest, ob das System Anmeldetickets und Zusicherungstickets akzeptiert |
login/ticketcache_entries_max |
Standardwert: 1000 |
Legt die maximale Anzahl von möglichen Einträgen im Cache für Anmeldetickets fest. |
login/ticketcache_off |
0: Keine Anmeldetickets im Cache halten (Vorschlagswert) 1: Anmeldetickets im Cache halten |
Legt fest, ob das System Anmeldetickets im Cache hält |
login/ticket_only_by_https |
1: Cookies nur bei HTTPS-Verbindungen vom Browser mitsenden. 0: Cookie immer mitsenden |
Gibt die Art des Sendens an, die das System verwendet für das Anmeldeticket-Cookie und das HTTP-Sicherheits-Session-Management-Cookie, die bei Ihrer Anmeldung über HTTP(S) im Browser generiert werden. |
icf/set_HTTPonly_flag_on_cookies |
0 = HTTPonly Attribut für alle ICF-Cookies aktiviert 1 = HTTPonly Attribut für ICF-Anmelde-Cookie deaktiviert 2 = HTTPonly Attribut für Cookies außer ICF-Anmelde-Cookie deaktiviert 3 = HTTPonly Attribut für alle ICF-Cookies deaktiviert |
Setzt das Attribut HTTPonly für ICF-Cookies
Ein Cookie als HTTPonly zu deklarieren, erhöht die Sicherheit Ihres Systems, da es den Zugriff auf dieses Cookie im Web-Browser durch client-seitige Skripte, Applets, Plug-Ins und Ähnliches verhindert. Dies kann Nebenwirkungen haben, da einige Anwendungen solche Technologien verwenden und sich auch auf diese Informationen verlassen. Diese Anwendungen funktionieren eventuell nicht mehr korrekt, da sie auf diese Informationen nicht zugreifen können. Ende der Warnung.
Ein Beispiel hierfür ist eine Anwendung, die Java-Applets verwendet, um eine bestimmte Funktion innerhalb einer Web-Browser-Anwendung auszuführen. Wenn ein Benutzer auf die Web-Browser-Anwendung zugreift, kann der Backend-Server den Benutzer authentifizieren und dem Benutzer ein Cookie (z.B. ein Anmeldeticket oder eine Session-ID) ausstellen, das zur weiteren Authentifizierung verwendet werden kann. Falls für dieses Cookie das HTTPonly-Attribut gesetzt ist, dann kann weder das Applet darauf zugreifen, noch wird das Cookie automatisch an den Server zurückgesendet, da das Applet seinen eigenen Kommunikationskanal verwendet. Daher gelangt der Benutzer entweder auf ein Anmeldebild oder er stellt funktionale Fehler fest (z.B. ein leeres Bild), obwohl der Benutzer bereits in der Web-Browser-Session authentifiziert worden war. Ende des Beispiels. |
icf/user_recheck |
0 = Überprüfung nicht aktiv 1 = Überprüfung aktiv |
Legt fest, ob das System bei einer zustandsbehafteten HTTP-Kommunikation (und somit der Adressierung einer vorhandenen Session) die Anmeldedaten für die HTTP-Anfragen erneut überprüft. Die Authentifizierungsdaten müssen dabei mit den in der Session gehaltenen Daten übereinstimmen.
Dieser Parameter ist nur relevant, wenn das Sicherheits-Session-Management nicht aktiv ist. Weitere Informationen finden Sie im SAP-Hinweis 1301591. Ende des Hinweises. |
http/security_session_timeout |
Standardwert: 1800 (30 Minuten) |
Legt das maximale Zeitintervall zwischen dem Empfang zweier HTTP-Requests (mit gültiger Sicherheits-SessionID) fest. Nach Ablauf dieser Frist werden alle Anwendungskontexte (bei Verwendung von zustandsbehafteten Web-Anwendungen), die auf diesem Applikationsserver mit einer Sicherheits-Session verbunden sind, abgebaut (und damit verbundene Ressourcen freigegeben - weitere Informationen: rdisp/plugin_auto_logout). Falls die Sicherheits-Session auf keinem anderen Applikationsserver mehr aktiv verwendet wird, wird auch die Sicherheits-Session abgebaut. Für web-basierte Anwendungen oder Services, die eine Authentifizierung erfordern, führen alle nachfolgenden HTTP-Requests zu einer Authentifizierungsanforderung. |
http/security_context_cache_size |
Standardwert: 2500 |
Bei aktivem HTTP-Sicherheits-Session-Management legt das System Session-Kontexte in einem server-lokalen Cache ab, um die Session-Inaktivitäts-Zeitüberschreitung zu überwachen. Sie können die Cache-Größe zur Laufzeit nicht verändern. Sie bestimmt sich aus der Verweildauer der Cache-Einträge (also des Session-Zeitüberschreitungswerts) und der zu erwartenden Anzahl an Benutzern, die gleichzeitig eine Applikationsserver-Instanz nutzen. |
rdisp/plugin_auto_logout |
Standardwert: 1800 Sekunden 0: System löscht den Kontext nicht automatisch |
Legt die maximale Inaktivitätsfrist für den Benutzerkontext eines externen Plug-Ins (z.B. HTTP) fest, bevor das System diesen abbaut. Sie können den Wert ohne oder mit Zeiteinheit angeben. Ohne Zeiteinheit bedeutet, dass das System Sekunde als Einheit wählt. Sie können aber auch M für Minute oder H für Stunde angeben. |
rdisp/autothtime |
Standardwert: 60 Sekunden |
Definiert den Zeitabstand für die im Taskhandler periodisch durchgeführten Überprüfungen, z.B. das automatische Zurücksetzen der Trace-Dateien, das Überprüfen des Kontextpools für RFC-Server oder externe Plug-Ins (HTTP, ..), die automatische Anmeldung für externe Plug-Ins (HTTP, ..) Sie können den Wert ohne oder mit Zeiteinheit angeben. Ohne Zeiteinheit bedeutet, dass das System Sekunde als Einheit wählt. Sie können aber auch M für Minute oder H für Stunde angeben. |
Empfehlung
Achtung
Beispiel
HinweisVorgehensweise
Starten Sie das HTTP-Session-Management (Transaktion SICF_SESSIONS).
Sie gelangen auf eine Liste aller im System vorhandenen Mandanten.
Markieren Sie die entsprechende Zeile, und wählen Sie die Taste Aktivieren.
Das Security Audit Log zeichnet die Aktivierung oder Deaktivierung des HTTP-Sicherheits-Session-Managements auf.