Das Thema der Web Service-Sicherheit wurde in Teil vier dieser Artikelreihe bereits ausführlich erörtert, weshalb hier nur die wichtigsten Grundprinzipien kurz dargestellt werden.
Toms Web Services werden denselben spezifischen SOAP-Header zur Authentifizierung benutzen. Der Authentifizierungsprozess verläuft allerdings etwas anders. Der Web Service erwartet einen SOAP-Header mit einem einzelnen Sicherheits-Token-Key. Dieser Sicherheitsschlüssel wird durch den folgenden XML-Knoten in Toms Web.config-Datei gespeichert, der noch hinzugefügt werden muss:
Der Wert dieses Schlüssels ist sowohl in Toms Anwendung als auch in Johns Anwendung gespeichert. Weicht dieser Wert zwischen den beiden Abweichungen ab, gibt der Web Service einen Authentifizierungsfehler aus. Die Sicherheitsanforderungen von Tom sind nicht so hoch wie die von John, da er lediglich Zugriff auf eine Funktion bieten muss, mit der Johns Anwendung Bestellungen bestätigen kann.
Großansicht: Klick auf Bild |
Zusätzlich zum Abgleich der Werte des Sicherheits-Tokens wird der Web Service von Tom blockiert, indem HttpGet, HttpPost und die Dokumentationsprotokolle entfernt werden. Der Zugriff auf Toms Web Service erfolgt durch die Weitergabe einer Proxy-Klasse an Johns Anwendung. Abbildung A stellt den gesamten Ablauf in einem Diagramm dar.
Beim Online-Gaming kommt es nicht nur auf das eigene Können an. Auch die technischen Voraussetzungen…
Fast jedes zweite Unternehmen bietet keinerlei Schulungen an. In den übrigen Betrieben profitieren oft nur…
Huawei stellt auf der Connect Europe 2024 in Paris mit Xinghe Intelligent Network eine erweiterte…
Höchste Zeit für eine schnelle Kupfer-Glas-Migration. Bis 2030 soll in Deutschland Glasfaser flächendeckend ausgerollt sein.
Schon im April 2025 soll Android 16 den Status Plattformstabilität erreichen. Entwicklern gibt Google danach…
Die Hintermänner setzen KI-Chatbot-Tools als Köder ein. Opfer fangen sich den Infostealer JarkaStealer ein.
