Technische Anforderungen an die Applikation
Allgemeine technische Anforderungen
Auf dieser Seite werden allgemeine technische Anforderungen an die Applikation beschrieben. Dazu gehören wichtige Vorgaben für die Sicherheit, die Proxy Awareness, d.h. die Applikation muss zwingend die folgenden Anforderungen erfüllen, damit sie mit dem Standardservice eIAM integriert werden kann.Verschlüsselte Datenübermittlung
Die gesamte Datenübermittlung vom Webbrowser bis zur Applikation MUSS mittels TLS im Transport Layer verschlüsselt werden. Damit die WAF Features von eIAM und die Reverse Proxy Funktionalität möglich ist, muss die Verschlüsselung zwischen dem Browser und der Applikation auf dem Loadbalancer vor der WAF und auf dem eIAM-Web PEP aufgebrochen werden und eine neue, ebenfalls verschlüsselte Verbindung etabliert werden. Ebenso muss die gesamte für die Authentifizierung des Benutzers notwendige Kommunikation auf dem Transport Layer verschlüsselt erfolgen.Proxy-Awareness
Um die Integration von Applikationen in den Service eIAM zu ermöglichen, werden Anforderungen an die sogenannte Proxy-Awareness der Applikation gestellt. Applikationen, die Proxy-Aware gebaut sind, lassen sich ohne zusätzlichen Aufwand hinter einem Reverse Proxy einsetzen und somit in den Service eIAM integrieren.Ob eine Web-Applikation Proxy-Aware ist, lässt sich herausfinden, indem man die Applikation über den Reverse Proxy testet oder aber den HTML-Content nach vollqualifizierten oder absoluten Links durchsucht. J2EE-Servlet-Applikationen sind in der Regel Proxy-Aware oder können durch eine Anpassung der Deployment-URL ohne grossen Aufwand Proxy-Aware gemacht werden. Verändert sich der HTML-Content bei einer Anpassung der Deployment-URL nicht, so ist die Applikation vollständig Proxy-Aware.
Nachfolgend werden die Kriterien für die Proxy-Awareness genauer erläutert. Diese Anforderungen sind von mit eIAM verwendeten Applikationen zwingend zu erfüllen.
Bemerkung
Ist für Applikationen ausserhalb der Netze der Bundesverwaltung keine Anforderung von eIAM.
URLs in "Proxy-Awaren" Applikationen
Typischerweise verwendet der Benutzer eine Applikation, in dem er Anfragen an URLs adressiert. Eine URL kann entweder eine vollqualifizierte, eine absolute oder eine relative Adresse sein. Im Gegensatz zu einer vollqualifizierten URL enthält eine relative URL weder ein Schemapräfix noch die Server-Adresse, sondern lediglich den Pfad und den Namen des Zieldokuments. Der Pfad selbst kann wiederum absolut (ausgehend vom Root-Verzeichnis des Web-Servers) oder relativ zum Verzeichnis des Quelldokuments gebildet werden. Beginnt der Pfad mit “/”, handelt es sich um eine absolute Pfadangabe ausgehend vom jeweiligen Root-Verzeichnis.
In der folgenden Tabelle sind die verschiedenen Arten von Links mit Beispielen aufgeführt.
| Art des Links | Beispiel |
| Relative Pfade | ./Documents/index.html ../images/logo.gif ../../resources/title_bar.png |
| Absolute Pfade | /myapp/Documents/index.html /myapp/images/logo.gif |
| Vollqualifizierte URL | https://mycompany.com/myapp/Documents/index.html https://mycompany.com/myapp/images/logo.gif |
In der nachfolgenden Abbildung werden die verschiedenen Arten von Links dargestellt, wie sie in der Applikation verwendet werden müssen.
-
- Verwendung der verschiedenen Arten von Links
Die folgenden Regeln gelten für die Fälle aus der obigen Abbildung.
| Fall | Link | Type | Regel |
| 1 | ./Documents/index.html | Relativer Pfad innerhalb der Applikation | 1. Regel |
| 2 | ../images/logo.gif | Relativer Pfad auf interne Ressourcen] | 3. Regel |
| 3 | /otherapp/start.do | Absoluter Pfad auf eine andere Applikation hinter dem gleichen PEP (identischer FQDN)] | 4. Regel |
| 4 | https://www.otherserver. com/foo/bar/ | Vollqualifizierte URL auf externen Web Ressource (ausserhalb des FQDN der aktuellen Applikation) | 5. Regel |
Für die Applikationsentwicklung gelten folgende Vorgaben:
Verwendung von relativen URLs1. Regel: Applikationen müssen für die Integration in eIAM relative URLs innerhalb der Applikation verwenden.
Die Verwendung von relativen URLs ist eine notwendige, jedoch nicht hinreichende Bedingung für Proxy-Awareness. In einer Proxy-Umgebung werden auf dem Reverse-Proxy alle integrierten Applikationen auf eine dedizierte Top-Level-Location (Root-Location) abgebildet (z.B. “https://somehost.ch/myappl/”). Daraus lassen sich zusätzlich die in den nachfolgenden Abschnitten beschriebenen Kriterien für die Proxy-Awareness ableiten.
Self-contained URLs
2. Regel: Web-Applikationen und deren Ressourcen müssen unter einer Self-contained URL erreichbar und funktionsfähig sein.
Da der Proxy das Servlet Mapping und damit den Aufbau der Filter Chain anhand der URL vornimmt, müssen Web-Applikationen unter einer eigenen, in sich geschlossenen URL (Self-contained URL) erreichbar und funktionsfähig sein (z.B. “https://somehost.ch/myappl/”). Sie dürfen nicht unter dem Root-Verzeichnis (d.h. "https://somehost.ch/") eingesetzt sein. Dies gilt für alle Ressourcen, welche die Applikation zur Verfügung stellt – also auch Style-Sheets, Bilder, Scripts usw.
URLs innerhalb von Applikationen
3. Regel: Alle Links auf applikationsinterne Ressourcen innerhalb der Applikation müssen relative Pfadangaben sein.
In ähnlicher Weise müssen Links innerhalb der Applikation, welche eigene Ressourcen adressieren, relativ sein (z.B. "./pics/picture.gif") und dürfen nicht absolut angegeben werden (z.B. "http://somehost.ch/myappl/pics/picture.gif").
Applikationen über absolute Pfade koppeln
4. Regel: Applikationen werden mittels absoluter Pfadangaben ohne Serveradressen gekoppelt.
Wird innerhalb einer Applikation eine weitere Applikation adressiert, so spricht man von gekoppelten Applikationen. Innerhalb vom eIAM muss diese Koppelung ausschliesslich über den Proxy erfolgen. Der Applikation muss bekannt sein, wie ihre Partnerapplikation über den Proxy erreichbar ist. Links auf Partnerapplikationen sind dementsprechend als absolute Pfadangaben ohne Angabe der Serveradresse zu realisieren (z.B. “/otherapp/start.do”).
Adressierung externer URLs
5. Regel: Applikationsexterne URLs werden immer über absolute Server- und Pfadangaben adressiert
URLs, welche eine externe Ressource ansprechen (z.B. Verweis auf eine Webseite einer anderen Organisation oder allgemeine Webseite im Internet), werden selbstverständlich absolut mit Server- und Pfadangaben angegeben. Es muss sichergestellt sein, dass solche URLs global erreichbar sind.
Das HTML-Tag “basehref”
6. Regel: Der HTML-Tag “basehref” darf in keiner HTML-Seite gesetzt sein.
Oft wird der HTML-Tag “basehref” benutzt, um die Menge von repetitivem Text in einem HTML-Dokument zu reduzieren. Das “basehref”-Tag gibt dem Browser an, dass alle relativen Links in diesem Dokument mit der angegebenen Adresse beginnen. Das hilft zwar beim Erstellen eines HTML-Dokuments, weil Layout und Verhalten einfach lokal getestet werden können und das Dokument nicht auf einem Server platziert werden muss. In einer Proxy-Umgebung ist es jedoch schlecht umsetzbar, weil der Proxy die Applikation auf eine dedizierte Top-Level-Location abbildet. Somit darf das “basehref”-Tag in keiner HTML-Seite gesetzt sein.
Angabe des Content-Type
7. Regel: Der Content-Type muss immer angegeben werden.
Der Content-Type muss stets angegeben werden, da sonst der Reverse-Proxy einen Default-Wert einsetzt. Dabei kann es dann im Browser zu unerwünschten Effekten kommen (HTML-Code wird als Text dargestellt).
Die nachfolgenden Regeln sind für Applikationen ausserhalb der Netze der Bundesverwaltung keine Anforderung von eIAM.
URIs innerhalb von Applikationen
8. Regel: Die verschiedenen URI Namespaces einer Applikation mit unterschiedlichem Schutzbedarf müssen einfach strukturiert sein und dürfen sich nicht überlappen.
Überlappungen finden statt, wenn man z.B. /appl1/private/* und /appl1/private/public/* verschieden schützen möchte. Innerhalb des an sich geschützten Pfades /appl1/private/* befindet sich hier ein nicht geschützter Pfad ./public/*. Dies ist nicht zulässig.
Cookies für Session-Tracking
9. Regel: Die Verwendung von Cookies für das Session-Tracking der Applikation ist zwingend.
Das Session Tracking der Applikation hat per Session Cookie zu erfolgen. URL-Rewriting als Session Tracking Methode wird von eIAM nicht unterstützt.
Session-Tracking
10. Regel: Applikatorische Timings sollen höher sein als diejenigen auf dem PEP. Der PEP ist der Master über die Sessions.
Es ist wichtig, dass die Applikationen ihre Session Dauer und Timeouts dem PEP anpassen.
SAML/Nachrichten auf fixe URL's
11. Regel: Applikationen innerhalb der Netze der Bundesverwaltung müssen SAML/Nachrichten auf fixen URLs entgegennehmen.
Bei Applikationen innerhalb der Netze der Bundesverwaltung, ist die Zieladresse der Antwort des eIAM-Web PEP auf den AuthnRequest der Applikation ist fest und wird in den Metadaten der Applikation vor konfiguriert. Die Applikation muss also die SAML Response, den LogoutRequest und die LogoutResponse auf je einer fixen URL entgegennehmen.
SSO-Session beenden
12. Regel: Beim Beenden einer SSO-Session (SLO Single Logout/Timeout) können Applikationen über die konfigurierte Logout URI vom PEP informiert werden.
Es kann pro Applikation jeweils ein LogoutURI im eIAM-Web PEP konfiguriert werden. Ist dieser URI definiert, so wird jede innerhalb dieser SSO-Session verwendete Applikation benachrichtigt, wenn die SSO-Session beendet wird. So können Applikationen vom PEP über beendete SSO-Sessions informiert werden, um ihrerseits die Session des Benutzers sauber zu schliessen.
Von eIAM reservierte Query Parameter
Die folgenden Query Parameter sind für den Service eIAM reserviert und DÜRFEN NICHT von den Applikationen verwendet werden.- ?logout
- ?login
Von eIAM unterstützte http Verben
Die folgenden http Verben werden durch den Service eIAM standardmässig unterstützt:- GET
- POST
Bemerkung
Ist für Applikationen ausserhalb der Netze der Bundesverwaltung keine Anforderung von eIAM.
eIAM Cookie Handling
Standardmässig werden von der Applikation ausgestellten Cookies auf dem eIAM-Web PEP gecached und nicht bis an den Web Browser durchgelassen. Die von der Applikation gesetzten Cookies verkehren also nur zwischen dem eIAM PEP und der Applikation.Falls Cookies, welche die Applikation setzt, nicht auf dem PEP gecached werden sollen, sondern bis auf den Web Browser des Benutzers durchgelassen werden müssen, so muss dies im eIAM-Dossier unter Angabe des exakten Namens des Cookies bei der Bestellung des Service eIAM vermerkt werden.
Werden Cookies vom PEP an den Web Browser des Benutzers vom PEP durchgelassen, so werden diese automatisch umgeschrieben (Pfad und Host), so dass diese für den PEP und nicht für die Applikation gelten.
Bemerkung
Ist für Applikationen ausserhalb der Netze der Bundesverwaltung keine Anforderung von eIAM.
eIAM Request Timeout
Der eIAM-Web PEP kann eine begrenzte Anzahl von gleichzeitig gestellten http Requests abarbeiten. Daher wird im Interesse aller über den eIAM-Web PEP erreichbaren Anwendungen die Zeit limitiert, in welcher ein solcher Prozess mit dem Warten auf die Antwort der Anwendung besetzt wird. Damit wird sichergestellt, dass dieser Prozess wieder zur Abarbeitung eines anderen Requests freigegeben wird und nicht eine einzelne fehlerhafte Anwendung die Verfügbarkeit anderer Anwendungen negativ beeinflusst.Erfahrungsgemäss warten Anwender kaum länger als 1-2 Minuten, ob auf ihren Request noch eine Antwort geliefert wird, bis sie entweder aufgeben (den Browser schliessen oder auf eine andere Ressource navigieren) oder den Request erneut senden (Refresh).
Der Wert für diesen Timeout ist in eIAM-Web auf 2 Minuten gesetzt. Nach diesem Intervall wird an den Client eine html Fehlerseite mit dem http Code 502 (Upstream Server not available) ausgeliefert.
Der Wert für den Request Timeout kann in begründeten Ausnahmefällen pro Mapping anders konfiguriert werden.Für die Änderung des Wertes muss ein Antrag gestellt werden.
Bemerkung
Ist für Applikationen ausserhalb der Netze der Bundesverwaltung keine Anforderung von eIAM.
Client Tracking zwischen eIAM-Web PEP – Webbrowser
Es wird vom PEP ein nicht-persistentes Session Cookie auf den Namen '<eiam-amt>' z.B. ‚eiam-bit‘ ausgestellt. Das Client-Tracking auf dem PEP basiert auf diesem Cookie. Das Cookie wird nach dem Etablieren eines Security Kontextes (Session) auf dem PEP erneuert.Das vom eIAM-Web PEP ausgestellte Session Cookie besitzt folgende Attribute:
- HttpOnly - (Der Webbrowser darf nicht zulassen, dass das Cookie von einem Skript ausgelesen wird. Dies ist nicht in allen, vor allem älteren Browsern unterstützt.)
- Secure - (Der Webbrowser darf das Cookie nur über eine auf dem Transport Layer gesicherte Verbindung zurückschicken)
- Host – (nicht gesetzt) per Default auf den FQDN des Herausgebers des Cookies ausgestellt
- Path – / (Root)
Client Tracking zwischen Applikation – eIAM-Web PEP
Wird von der Applikation ein Security-Kontext mit der Session des Benutzers auf dem PEP etabliert, so MUSS die Applikation ein Client Tracking basierend auf Cookie verwenden. Die Cookies der Applikation verkehren nur zwischen Applikation und PEP und werden nicht an den Webbrowser des Benutzers weitergereicht. Andere Session Tracking Mechanismen wie SSL-ID, und URL Rewriting werden vom Service eIAM nicht unterstützt.Bemerkung
Ist für Applikationen ausserhalb der Netze der Bundesverwaltung keine Anforderung von eIAM.
Applikation Logout Knopf mit Logoutseite und Re-Login Möglichkeit
Die zu integrierende Applikation muss den Benutzern die Möglichkeit bieten ihre aktuell laufende Session zu beenden. Dazu ist in der Applikation eine Schaltfläche oder ein Link welcher ein Logout initiiert zu implementieren. Bei Applikationen welche mittels STS-PEP implementiert sind (Standard), leitet der STS-PEP den Benutzer dann zur Logoutseite der Applikation weiter. Diese Logoutseite, welche von der Applikation bereitgestellt werden muss, bestätigt dem Benutzer, dass seine Session korrekt abgeschlossen wurde.-
- Logout Bestätigung mit Re-Login
Damit sich ein Benutzer direkt nach einem Logout wieder in die Fachapplikation einloggen kann, gibt es den optional wählbaren «Erneut einloggen» Button auf der Logoutseite. Dieser Button erleichtert die Navigation falls man sich direkt wieder einloggen möchte, zum Beispiel, wenn der Benutzer eine Aktion in der Fachapplikation vergessen hat oder etwas an der Fachapplikation getestet wird. Der Button ist auf allen Umgebungen REF, ABN und PROD verfügbar.