Bei einem Identity-Aware Proxy (IAP) handelt es sich um eine Software, die im Allgemeinen als Reverseproxy oder als Teil einer Software fungiert, die Reverseproxy- und Lastausgleichsfunktionen kombiniert. Dieses Konzept unterscheidet sich von den standardmäßigen Architekturkomponenten durch die Rolle des IAP bei der Authentifizierung eingehender Anforderungen, da nicht nur ein Backend-System oder ein externes Authentifizierungsmuster verwendet wird.
Dieses Thema bezieht sich fast ausschließlich auf ArcGIS Enterprise. Die meisten ArcGIS Online-Workflows interagieren nicht direkt mit einem Identity-Aware Proxy, obwohl externe Services oder URLs, die ArcGIS Online als Elemente hinzugefügt wurden, auf diese Weise geschützt werden können.
In den meisten Bereitstellungen, in denen ein Reverseproxy oder Load Balancer verwendet wird, arbeitet die Komponente weitgehend in einem transparenten Modus. Das bedeutet, dass Anforderungen von einem Client vom Proxy nicht wesentlich bearbeitet oder geändert, sondern direkt an das Backend-System weitergeleitet werden. Manchmal wird dabei ein Anforderungsheader hinzugefügt, um dem Backend-System zu signalisieren, dass die Anforderung über diesen Proxy gestellt wurde. In diesen Architekturen ist die Authentifizierung bei einem ArcGIS-System für einen Benutzer, der den Reverseproxy oder Load Balancer passiert, funktional identisch mit der eines Benutzers, der ohne diesen Zwischen-Layer direkt auf die Software zugreift.
Wenn ein IAP verwendet wird, überprüft der Reverseproxy zunächst, ob der Benutzer authentifiziert ist, indem er nach Authentifizierungsdaten oder -objekten sucht, z. B. nach einem Token, API-Schlüssel oder einem websitespezifischen Cookie. Wenn keine vorhanden oder diese ungültig sind, werden alle Anforderungen an das Backend-System sofort an einen Authentifizierungsanbieter oder -prozess umgeleitet, der auf den IAP-Konfigurationen basiert. Erst nachdem sich der Benutzer ordnungsgemäß über diesen Identity-Provider authentifiziert hat und mit einem gültigen Sicherheitstoken oder einer gültigen Anmeldeinformation an die IAP-Schnittstelle zurückgegeben wird, wird seine Anforderung an das Backend-System weitergeleitet. Wichtig ist, dass diese Sicherheitskennung außerhalb des Backend-Systems verwaltet wird, d. h. das Backend-System weiß in der Regel nichts über die über den IAP ausgehandelte Sitzung des Benutzers. Dies bedeutet, dass sich der Benutzer in einem Szenario, in dem sich ArcGIS Enterprise hinter einem IAP befindet, nach der ersten vom IAP initiierten Anmeldung erneut bei dem von ArcGIS angegebenen IdP authentifizieren muss, um eine Sitzung mit ArcGIS einzurichten.
Viele Softwarekomponenten und -systeme können so konfiguriert werden, dass sie die im Konzept des Identity-Aware Proxys enthaltenen Funktionen unterstützen. Hier einige gängige Beispiele:
Listener-Regel, die die Authentifizierung erzwingtJeder Reverseproxy, der einen “Vorauthentifizierungs-Layer” bereitstellt oder für den ein Token, ein Cookie oder andere Anmeldeinformationen erforderlich sind, kann im Rahmen der Erläuterungen zur ArcGIS-Architektur als Identity-Aware Proxy betrachtet werden. Einige IAPs sind mehr oder weniger konfigurierbar, erlauben Ausnahmen für bestimmte URLs oder bieten unterschiedliche Authentifizierungsmethoden, die von der einfachen formularbasierten Anmeldung bis hin zu OpenID Connect und SAML-basierten Anmeldeoptionen reichen.
IAPs werden häufig verwendet, um benutzerdefinierte öffentlich zugängliche Webanwendungen und Endpunkte zu schützen, bei denen ein Benutzer hauptsächlich über einen Webbrowser auf eine Webanwendung zugreift und die Anforderungen an die Backend-APIs in derselben Domäne wie die Anwendung liegen, sodass eine erste Anmeldung vom Benutzer wiederverwendet werden kann, um weitere Anforderungen zu stellen. Einige Backend-APIs können so entwickelt werden, dass sie einen Header oder eine andere Anforderungseigenschaft nutzen, die den IAP durchläuft (z. B. eine Signatur, die den Benutzernamen des Benutzers angibt), und diese Informationen dann verwenden, um den Inhalt oder die Logik der API-Antwort zu beeinflussen.
Die meisten ArcGIS-Client-Anwendungen, ob Web-, Desktop- oder mobile Anwendungen, initiieren die Authentifizierung bei ArcGIS über OAuth. Dieser Prozess, der das Registrieren der Client-App bei ArcGIS, das Initiieren einer Anmeldesitzung, das Bereitstellen gültiger Anmeldeinformationen und die anschließende Verwendung des Antwortcodes zum Generieren eines Token umfasst, ist für jeden dieser Client-Typen konsistent. Dieser OAuth-Anmeldeprozess erstreckt sich über verschiedene Webseiten oder HTTP-Anforderungen und erfolgt in der Regel in einem eingebetteten Browser (bei nativen Apps) oder im selben Browserfenster (bei Web-Apps).
Beim ArcGIS OAuth-Prozess und insbesondere bei der In-App-Verwendung des resultierenden ArcGIS-Zugriffstokens wird davon ausgegangen, dass der Client über transparenten Zugriff auf das Backend-System verfügt. Anders ausgedrückt: ArcGIS-Clients wissen lediglich, wie sie sich bei ArcGIS-Systemen authentifizieren – während der OAuth-Prozess im Browser das Senden des Benutzers an einen SAML- oder OIDC-Identity-Provider umfassen kann, wird am Ende der generierte OAuth-Code an den Benutzer zurückgegeben, und bei nativen Apps wird das zusätzliche Browserfenster geschlossen. Nachdem die OAuth-Anmeldung abgeschlossen ist, geht der Client davon aus, dass er transparente HTTP-Anforderungen (sowie das ArcGIS-Token) zur weiteren Verwendung an ArcGIS Online- oder ArcGIS Enterprise-Endpunkte senden kann. Die vom IDP festgelegten Anmeldeinformationen oder Sitzungen werden nicht mehr verwendet oder als relevant für ArcGIS angesehen. In einem IAP-Szenario überprüft der IAP ständig, ob alle eingehende Anforderer zuvor beim IAP authentifiziert wurden, was zu mehreren häufigen Problemen führen kann.
In einem ArcGIS OAuth-Anmeldeprozess gibt es in der Regel zwei konfigurierte Eigenschaften, die das Initiieren des OAuth-Prozesses unterstützen: die Eigenschaft client_id und die Eigenschaft portal_url.
https://www.arcgis.com oder eine organisationsspezifische Subdomäne wie https://myorg.maps.arcgis.com.https://gis.mydomain.org/portal – mit einem Domänennamen und einem Webkontext (/portal).Das Anwendungsverhalten des ArcGIS-Clients nähert sich diesem Prozess im Allgemeinen, indem zunächst überprüft wird, ob es sich bei der konfigurierten URL um ein gültiges ArcGIS Enterprise- oder ArcGIS Online-System handelt, indem eine Anforderung wie (portal_url) + /sharing/rest/info?f=json gesendet wird.
Diese Anforderung gibt eine kurze JSON-Antwort zurück, die die verwendete API-Version angibt, um sicherzustellen, dass das System eine unterstützte Version für diese spezifische Clientanwendung ist.
Wenn eine ArcGIS-Anwendung einen Benutzer auffordert, eine ArcGIS Enterprise-URL für die Verbindung anzugeben, gibt die erste Anforderung vom ArcGIS-Client an /sharing/rest/info?f=json häufig eine 302-HTTP-Antwort zurück, die den Benutzer zur IAP-Anmeldeseite umleitet.
Dies führt dazu, dass die ArcGIS-Client-Anwendung den Endpunkt nicht als gültig akzeptiert, da er sich nicht als ArcGIS-Bereitstellung, sondern als HTML-Anmeldeseite darstellt. Dies führt zu einer Ablehnung, da die Client-Anwendung versucht, eine bösartige Website daran zu hindern, eine ArcGIS Enterprise-Bereitstellung zu imitieren, z. B. wenn jemand Typosquatting verwendet, um Informationen anzufordern, oder den Benutzer auffordert, seine Anmeldeinformationen auf dieser Site einzugeben, wo sie gestohlen und missbraucht werden könnten.
Bei nativen Apps, wie bei ArcGIS Pro und mobilen ArcGIS-Apps, wird die OAuth-Anmeldung über einen eingebetteten Browser durchgeführt. Und obwohl die IAP-Sitzung in diesem Browser erfolgreich eingerichtet werden kann, geht nach dem Schließen dieses Browsers das Cookie verloren, das im Allgemeinen gesetzt wird (um den Benutzer als Benutzer zu identifizieren, der sich bereits beim IAP authentifiziert hat), sodass die nachfolgenden Anforderungen an ArcGIS, die direkt von der nativen Anwendung initiiert wurden, mit einer erneuten 302-Antwort blockiert werden.
Bei erfolgreicher Konzeption können mehrere Workflows mit IAP-Funktionen kombiniert werden.
Obwohl Identity-Aware Proxys eindeutig eine recht verbreitete Klasse des Anwendungsschutzes sind, gibt es derzeit wenig Standardisierung oder Konsistenz zwischen ihren Implementierungen, was die zuverlässige Implementierung der Unterstützung für eine breite Palette von IAP-ähnlichen Systemen erschwert. Esri untersucht die zukünftige Unterstützung für mehr IAP-basierte Workflows von nativen Anwendungen und wird versuchen, Unterstützung in einer gemeinsam implementierbaren, standardbasierten Methode bereitzustellen, die in Zukunft auf viele verschiedene Softwaredistributionen angewendet werden kann.