Anforderungen an die URLs der Applikation

Die Einhaltung der eIAM Anforderungen an die URLs ist verbindlich für Anwendungen, die innerhalb der Netzwerke der Bundesverwaltung betrieben werden!

Erläuterung der URL-Teilbereiche

URLs z.B. https://www.gate.amt.admin.ch/appl1/private/ einer Web Applikation bestehen aus einem Protokollteil (https://) einem Fully Qualified Domain Name (FQDN) Teil (www.gate.amt.admin.ch) und einem Pfad Teil (/appl1/private/) .

Nachfolgend werden die Vorgaben bezüglich dieser URL-Teilbereiche im Detail beschrieben.

Einstiegspunkt FQDN

Die Benennung des FQDN auf dem eIAM-Web PEP ist grundsätzlich vorgegeben:

eIAM PEP Extern (Bundesverwaltungsnetz, Kantonsnetz und Internet)

eIAM Instanz	FQDN
Produktion (PRO)	www.gate.<amt>.admin.ch
Abnahme (ABN)	www.gate-a.<amt>.admin.ch
Referenz (REF)	www.gate-r.<amt>.admin.ch

Dabei wird durch ein sogenanntes „Split Brain DNS“ Verfahren dafür gesorgt, dass der gleiche FQDN im Internet auf eine andere (externe) IP Adresse aufgelöst wird als im Netz der Bundesverwaltung, wo der FQDN auf eine Bundesverwaltungsnetz interne IP Adresse aufgelöst wird. Auf Seite eIAM werden die Requests aus dem Netz der Bundesverwaltung über andere eIAM-Web PEP Instanzen geführt als Requests von ausserhalb des Netzes der Bundesverwaltung. Für die Applikation ist dies jedoch transparent.

Applikationsbereiche

Der eIAM-Web PEP stellt einen Secure Reverse Proxy Server in einer Front Door Ausprägung dar. Er erlaubt es somit, dass mehrere Fachapplikationen in einer Single Sign-On Domäne über den gleichen FQDN angesprochen werden können. Dies verlangt eine saubere Trennung der Applikationen über die URI Pfade, da der eIAM-Web PEP anhand des Pfades die Wahl des Backends trifft, an welchen der http Request des Benutzers geschickt werden muss.
Damit der eIAM-Web PEP seine Funktion als Grobautorisierungsstufe korrekt ausführen kann, sind Applikationsbereiche zu definieren. Applikationsbereiche sind definiert durch die URL in der Applikation. Mit der Verzeichnisstruktur können Applikationsbereiche, auch URI Namespaces genannt, definiert werden.

Verschiedene Applikationsbereiche sind notwendig, wenn in der Applikation die Ressourcen in der Verzeichnisstruktur unterschiedlich geschützt werden müssen. So kann es sein, dass ein Teil der Applikation unauthentifiziert zugänglich ist, während ein anderer Teil der Applikation nur für authentifizierte und autorisierte Benutzer zugänglich ist, und wieder ein anderer Teil der Applikation nur mit einer hohen Authentifizierungsstärke zugreifbar sein soll.

Die Konfiguration einer solchen Policy gilt jeweils auch für alle Unterverzeichnisse (z.B. gilt eine Konfiguration für /appl1/private/* auch für /appl1/private/docs/*).
Nutzt man das nachfolgende Schema für die Applikationsbereiche, kann der eIAM-Web PEP bereits von Anfang an dafür sorgen, dass nur korrekt authentifizierte und autorisierte Zugriffe an die Applikation gelangen.

Beispiel URLs für öffentliche, geschützte und speziell geschützte Bereiche:

/appl1/* = Context Namespace der Applikation öffentlicher Bereich (unauthentifiziert)
/appl1/public/* = öffentlicher Bereich (unauthentifiziert)
/appl1/private/* = authentifizierter (verlangt Benutzeranmeldung) und autorisierter (verlangt grobgranulare Rolle) Bereich
/appl1/private/strong/* = authentifizierter (verlangt Benutzeranmeldung mit starker Authentifizierung) und autorisierter Bereich mit grobgranularer Rolle

Wichtig ist eine saubere Abgrenzung der verschiedenen URI Namespaces. Es ist natürlich auch möglich, den Zugriff auf den gesamten URI Namespace der Applikation per grobgranularer Rolle nur berechtigten Benutzern zugänglich zu machen. Ebenfalls ist es möglich, für die gesamte Applikation eine starke Authentifizierung zu verlangen.

Regel 8: 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.

Public

Dieser Bereich ist öffentlich und die URL kann von jedermann ohne Benutzeranmeldung und ohne Überprüfung von Berechtigungen aufgerufen werden.
Ressourcen, die vor einer Benutzerauthentifizierung verwendet werden sollen, müssen grundsätzlich in einem ungeschützten Bereich sein.

Authentisch und autorisiert mit Rolle APPL.ALLOW

Alle Applikationen haben eine Grobautorisierungsrolle ‚<Applikationsname aus eIAM-AM>.ALLOW’. Soll ein Benutzer auf eine Applikation berechtigt werden, so muss ihm mindestens diese Rolle in seinem Profil zugewiesen werden. Erst mit dieser grobgranularen Rolle hat der Benutzer überhaupt Zugriff auf die geschützten Bereiche der Applikation über den eIAM-Web PEP. Da dieser durchsetzt, dass der Benutzer der den Request sendet diese Rolle besitzen muss. Für jede Applikation muss zusätzlich eine minimale Stärke der Authentifizierung definiert werden.

eIAM verwendet die nachfolgenden Qualitäten der Authentifizierungen

Qualität der Authentifizierung (QoA) Das QoA Konzept . . .

Authentisch und autorisiert mit definierter feingranularer Rolle (Option)

Der eIAM Service bietet ein 2-stufiges Rollenkonzept für das Access Management an. So kann man zum Beispiel eine URL zusätzlich schützen und nur für die Rolle "Applikationsname aus eIAM-AM>.<ROLLE>" freigeben. Feingranulare Rollen müssen vor der Integration im eIAM-Dossier definiert werden.

Funktionsweise der eIAM Rollen Nach der erfolgreichen . . .

Authentisch mit starker Authentifizierung (Option)

Gewisse Teile oder die ganze Applikation können durch die Anforderung einer stärkeren Authentifizierung geschützt werden. Jene geschützten URLs können dann nur aufgerufen werden, falls sich der Benutzer mit einer als stärker geltenden Authentifizierung angemeldet hat. Welche Pfade mit welcher Authentifizierungsstärke geschützt werden müssen, muss vor der Integration im eIAM-Dossier definiert werden.

URI Namespace Management

Der eIAM-Web PEP macht ein Request Dispatching. Dies bedeutet, dass der PEP für jeden Request, der vom Webbrowser an den PEP geschickt wird, evaluieren muss, an welche Applikation der Request geschickt werden muss. Dafür werden auf dem PEP sogenannte Mappings definiert. Das Management der URI Namespaces ist wichtig, damit es nicht zu Überschneidungen der Namespaces kommt.

Der PEP kann Requests, welche der Webbrowser sendet, anhand der folgenden Möglichkeit dispatchen.

Request Dispatching mittels Request URI Mapping – Standard

Beispiel:
https://www.gate.amt.admin.ch/appl1/* => https://appl1.ssz.admin.ch/appl1/*
https://www.gate.amt.admin.ch/appl2/* => https://appl2.ssz.admin.ch/appl2/*
https://www.gate.amt.admin.ch/appl3/* => https://appl2.ssz.admin.ch/appl3/*

Aufbau einer URL: <entrypoint(pep)>/<application>/<access>/<resource>
Beispiel: https://www.gate.bit.admin.ch/myappl/private/welcome.html

Wobei die einzelnen Teile wie folgt definiert sind:

Key	Beschreibung
<entrypoint(PEP)>	Einstiegspunkt abhängig vom Mandant https://www.gate.amt.admin.ch
<application>	Für die Applikation reservierte URI, z.B. /myappl
<access>	Zugriffstyp gemäss Applikationsbereich, siehe Kapitel 0, z.B. /private
<resource>	Ressource innerhalb des Applikationsbereichs welcome.html

Von eIAM reservierte URI Namespaces

/_pep/*
/auth/*
/errorpages/*
/login/*
/styles/*
/scripts/*
/images/*
/nevisidm/*
/passwordchange/*
/pwreset/*
/apstat
/favicon.ico

Selbstverständlich darf jedoch eine Applikation z.B. den Namespace /appl1/public/images/* benutzen.

Von eIAM reservierte Query Parameter

Die folgenden Query Parameter sind von eIAM reserviert und dürfen von den Applikationen, welche den Service eIAM nutzen nicht verwendet werden.

?login
?logout