SOAP Webservice in Delphi?

[Elrond]

Hallo Zusammen,

ich versuche mich aktuell an der Implementierung eines SOAP Clients in Delphi.

Die wenige offizielle Hilfe von Embarcadero lässt bereits schlimmes vermuten, aber ich bin noch optimistisch das ich einfach die ganze tolle Magie in Delphi noch nicht gefunden habe.

Wie in der Delphi Hilfe steht, habe ich die benötigte WSDL Importiert und die erste Anfrage abgesendet, scheint ja genauso einfach zu sein wie in Java. Leider hat es nicht ansatzweise Funktioniert, die komplette Policy Deklaration der WSDL wurde ignoriert. Weder kam ein Fehler das eine Signatur nicht möglich ist, noch wurde der geforderte Timestamp oder Empfänger hinzugefügt, es war eine einfache nackte Anfrage.

Auf Anhieb habe ich auch keine vorgesehene Möglichkeit gefunden um die benötigten Punkte auszukonfigurieren. Es gibt nur die Basisklasse TSOAPHeader, keine einzige Ableitung davon. Es kann aber doch nicht sein das ich mich jetzt selber darum kümmern muss.

[Sherlock]

Ich hatte bisher keine Probleme mit Delphi als SOAP Client. Welche konkrete Fehlermeldung bekommst Du? Oder was genau geht nicht?

Sherlock

[Elrond]

Zitat:

Zitat von Sherlock (Beitrag 1389276)

Ich hatte bisher keine Probleme mit Delphi als SOAP Client. Welche konkrete Fehlermeldung bekommst Du? Oder was genau geht nicht?

Sherlock

Es fehlen alle geforderten SOAP Header. Im Detail fordert die WSDL ws-addressing und zum Teil darauf aufbauend ws-security für die Signatur über den Timestamp- und Empfängerknoten.

[hoika]

Hallo,
zeig uns doch mal die WSDL, Delphi hat in der Tat bei komplizierteren Strukturen Importprobleme.

[Elrond]

Zitat:

Zitat von hoika (Beitrag 1389280)

Hallo,
zeig uns doch mal die WSDL, Delphi hat in der Tat bei komplizierteren Strukturen Importprobleme.

Ich kann euch gerne die WSDL zur Verfügung stellen, jedoch denke ich, dass das Problem nichts mit der direkten WSDL zu tun hat.


Es geht um diesen allgemeinen Abschnitt der die Sicherheitsanforderungen des Webservices beschreibt:

Code:

<wsp:Policy>
    <wsp:ExactlyOne>
        <wsp:All>
            <sp:TransportBinding xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
                <wsp:Policy>
                    <sp:TransportToken>
                        <wsp:Policy>
                            <sp:HttpsToken RequireClientCertificate="false"/>
                        </wsp:Policy>
                    </sp:TransportToken>
                    <sp:AlgorithmSuite>
                        <wsp:Policy>
                            <sp:Basic256/>
                        </wsp:Policy>
                    </sp:AlgorithmSuite>
                    <sp:Layout>
                        <wsp:Policy>
                            <sp:Strict/>
                        </wsp:Policy>
                    </sp:Layout>
                    <sp:IncludeTimestamp/>
                </wsp:Policy>
            </sp:TransportBinding>
            <sp:EndorsingSupportingTokens xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
                <wsp:Policy>
                    <sp:X509Token
                            sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
                        <wsp:Policy>
                            <sp:RequireThumbprintReference/>
                            <sp:WssX509V3Token10/>
                        </wsp:Policy>
                    </sp:X509Token>
                    <sp:SignedParts>
                        <sp:Header Name="To" Namespace="http://www.w3.org/2005/08/addressing"/>
                    </sp:SignedParts>
                </wsp:Policy>
            </sp:EndorsingSupportingTokens>
            <sp:Wss11 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
                <wsp:Policy>
                    <sp:MustSupportRefThumbprint/>
                </wsp:Policy>
            </sp:Wss11>
            <sp:Trust10 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
                <wsp:Policy>
                    <sp:MustSupportIssuedTokens/>
                    <sp:RequireClientEntropy/>
                    <sp:RequireServerEntropy/>
                </wsp:Policy>
            </sp:Trust10>
            <wsaw:UsingAddressing/>
        </wsp:All>
    </wsp:ExactlyOne>
</wsp:Policy>

Meine Erwartung aus Java und C# wären das mein Client nach den Import der WSDL Datei fast vollständig konfiguriert ist. In diesen Beispiel würde nur noch die Nennung des Signaturzertifikats fehlen.

In Delphi passiert jedoch nichts, es wird kein einziger geforderte SOAP Header mitgeschickt wie z.B. der Timestamp:

Code:

    
<wsu:Timestamp wsu:Id="TS-59e35d1a-97e3-45c0-a6e5-850e107005b4">
    <wsu:Created>2017-12-19T13:57:53.340Z</wsu:Created>
    <wsu:Expires>2017-12-19T14:02:53.340Z</wsu:Expires>
</wsu:Timestamp>

Es geht mir nicht um den SOAP Body, der wird richtig erzeugt.

[Union]

WS-Security wird nicht vom WsdlImporter unterstützt.

[Elrond]

Zitat:

Zitat von Union (Beitrag 1389325)

WS-Security wird nicht vom WsdlImporter unterstützt.

Soweit ich das überblicke wird es nicht nur vom Importer nicht unterstützt, er wird überhaupt in keinster Weise von Delphi unterstützt? Benötige ich einen Security Header, muss ich TSOAPHeader ableiten und einen eigenen Konverter schreiben. Eine Kryptobibliothek wird scheinbar auch nicht mitgeliefert, das bedeutet selbst wenn man sich diese absolut unnötige arbeit antun möchte würde man an diesen Punkt ebenfalls scheitern.

Wenn sich das wirklich so verhält bin ich ziemlich Fassungslos, wofür bezahlt man solch tierische Lizenzkosten...

[Union]

Hilft ja nichts. Hier ist ein Lösungsansatz. Ansonsten schreib den Client in einer Sprache für die es das WSS Framework und passende Import-Tools gibt und kopple den an Dein Delphi Programm.

[Elrond]

Zitat:

Zitat von Union (Beitrag 1389335)

Hilft ja nichts. Hier ist ein Lösungsansatz. Ansonsten schreib den Client in einer Sprache für die es das WSS Framework und passende Import-Tools gibt und kopple den an Dein Delphi Programm.

Aktuell handhabe ich das auch so, das ganze erzeugt aber eine unnötige Komplexität und die Kunden sind auch nicht begeistert warum jetzt noch Java/.net mitgeliefert wird. Für mich ist das wieder ein weiterer Sargnagel für Delphi.


In den letzten Tagen habe ich noch die Clever Internet Suite ausprobiert. Die konnte zumindest bis auf eine WSS-Anforderung alle erfüllen. Das einzige was nicht ging, war das einbinden des Zertifikats in die SOAP Nachricht. Nachträglich einfügen zerstört jedoch die Signatur, damit macht dieser eine Punkt wieder alles zunichte.

[Bernhard Geyer]

Zitat:

Zitat von Elrond (Beitrag 1389740)

Aktuell handhabe ich das auch so, das ganze erzeugt aber eine unnötige Komplexität und die Kunden sind auch nicht begeistert warum jetzt noch Java/.net mitgeliefert wird.

Net ist doch eh auf jedem Windows-Rechner drauf.
Aber müsste nicht Windows einen Importer haben, um aus einer SOAP-Schnittstelle ein COM-Interface zu erstellen das du dann nutzen kannst.
Leider kann ich dir keine weitern Infos dazu geben, da im Delphi-Umfeld mir SOAP seit langen nicht mehr begegnet ist (Hätte es vor Jahren mal gebraucht - hat sich dann aber anderweitig erledigt)

Zitat:

Zitat von Elrond (Beitrag 1389740)

Für mich ist das wieder ein weiterer Sargnagel für Delphi.

Wohl eher ein Sarg-Nägelchen.
Viele Firmen verlassen den SOAP-Weg (u.a. wegen der Komplexität u.a. bei Sicherheitsanforderungen) und wechseln auf REST/JSON und Co.
Schau mal nach ob es für deine Anforderung auch diese moderner Schnittstelle gibt?

Zitat:

Zitat von Elrond (Beitrag 1389740)

In den letzten Tagen habe ich noch die Clever Internet Suite ausprobiert.

Probier auch mal die IPWorks-Komponenten aus: http://cdn.nsoftware.com/help/IP9/dlp/SOAP.htm
Wir setzen von IPWorks die Komponenten für http(s)/ftp(s) ein und sind sehr zufrieden damit.

[Elrond]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1389750)

Zitat:

Zitat von Elrond (Beitrag 1389740)

Für mich ist das wieder ein weiterer Sargnagel für Delphi.

Wohl eher ein Sarg-Nägelchen.
Viele Firmen verlassen den SOAP-Weg (u.a. wegen der Komplexität u.a. bei Sicherheitsanforderungen) und wechseln auf REST/JSON und Co.
Schau mal nach ob es für deine Anforderung auch diese moderner Schnittstelle gibt?

Deine Aussage erscheint mir widersprüchlich, die Firmen verwenden kein SOAP mehr aufgrund der Komplexität bei den Sicherheitsanforderungen. Soweit ich weiß bietet REST aber überhaupt keine einheitliche Sicherheitsanforderungen. In der WSDL steht beschrieben wie die Signatur und Verschlüsselung der Inhaltsdaten zu erfolgen hat, für REST existiert meines Wissens nach sowas überhaupt nicht. Damit könnte jeder REST Service sein eigenes Süppchen kochen, was die Komplexität enorm steigern würde. Eher benötigen die meisten Webservices nicht mehr als eine Transportverschlüsselung und dafür wäre SOAP zu viel.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1389750)

Zitat:

Zitat von Elrond (Beitrag 1389740)

In den letzten Tagen habe ich noch die Clever Internet Suite ausprobiert.

Probier auch mal die IPWorks-Komponenten aus: http://cdn.nsoftware.com/help/IP9/dlp/SOAP.htm
Wir setzen von IPWorks die Komponenten für http(s)/ftp(s) ein und sind sehr zufrieden damit.

Danke, werde ich mir anschauen.

[MichaelT]

Delphi kann mit MTOM und WS* praktisch nicht wirklich umgehen, nicht out of the box.

Jo mei. Im Prinzip haben sich MS und SUN auf den Standard in eher trauter Zweisamkeit geeinigt. Es ist deren Zeug und geht uns mal prinzipiell nichts an.

Integrationsschnittstellen und damit verbundene Technologien gibt es zum Säuefüttern. Ich hätte mal kein Problem damit, dass ich ein .net oder Java Artefakt mitausliefere. Kommt aus dieser Welt, gehört in die Welt.

Musst du halt ausprogrammieren und grad im Umfeld von SOAP wurde dieses 'Ausprogrammieren' eher seitens der Werkzeuge am Ende durch Generierung unterstützt. Dafür brauchst du eine eigene Variante von Eclipse (Add-In) für jeden Schas, das ist die Kehrseite.

WS* hat eigentlich nur genervt und tut es heute auch noch.

Der SOAP Service allein ist in dem Technologiewulst noch nicht genug. Das geht viel weiter in diese absurden Konstrukte von verschachtelten XML Schema Definitionen, XSLT usw... Es haben viele Leute irgendetwas zur Praxis erhoben, das so nicht gemeint war.

Auf eine Third-Party Lösung wirst du zurückgreifen müssen in deinem Fall. Es ist vermutlich der pragmatischere Zugang.

Nicht falsch verstehen. Man kann nicht hergehen und jede vorstellbare Abhängigkeit welche nicht konsequent befriedigt wird in Richtung eines 'Delphi kann nix' auslegen.

Delphi ist in dem Umfeld XML/Java like ergänzt um .net WCF welches selbst seitens Java nicht mehr in letzter Konsequenz unterstützt nicht recht berühmt aufgestellt. In der Praxis gibt es die Ebene Infrastruktur die eigentlich solche Probleme sollte handeln. Die Realität schaut mal so aus, dass eine Applikation sich mit der Vermittlung von Nachrichten nicht hat anzupatzen. Es hat sich allein im Umfeld von Windows und Applikation dies eingebürgert.

Man kann auch die Kenntnis der Facebook API als Kompetenz ansehen, aber sobald nur genug solche Schnittstellen da sind, ändert sich die Sicht eher auf vergebene Liebesmüh.

Zitat:

Zitat von Elrond (Beitrag 1389269)

Hallo Zusammen,
ich versuche mich aktuell an der Implementierung eines SOAP Clients in Delphi.

[Bernhard Geyer]

Zitat:

Zitat von Elrond (Beitrag 1389760)

Deine Aussage erscheint mir widersprüchlich, die Firmen verwenden kein SOAP mehr aufgrund der Komplexität bei den Sicherheitsanforderungen. Soweit ich weiß bietet REST aber überhaupt keine einheitliche Sicherheitsanforderungen. In der WSDL steht beschrieben wie die Signatur und Verschlüsselung der Inhaltsdaten zu erfolgen hat, für REST existiert meines Wissens nach sowas überhaupt nicht. Damit könnte jeder REST Service sein eigenes Süppchen kochen, was die Komplexität enorm steigern würde. Eher benötigen die meisten Webservices nicht mehr als eine Transportverschlüsselung und dafür wäre SOAP zu viel.

Bei JSON/REST brauch ich keine in JSON/REST implementierte Sicherheitslösung/Spezifikation. Ich nehme einfach das, was es schon seit Jahrzehnten gibe.
Ich Ruf eine URL auf und ob ich diese Aufruf erlaubt ist wird außerhalb meiner JSON/REST-Schnittstelle gelöst. Ich kann mich voll und ganz auf die eigene Logik konzentrieren.
Und solche Security-Lösung auf URL-Basis gibt es wie Sand am Meer.

[Elrond]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1389768)

Zitat:

Zitat von Elrond (Beitrag 1389760)

Deine Aussage erscheint mir widersprüchlich, die Firmen verwenden kein SOAP mehr aufgrund der Komplexität bei den Sicherheitsanforderungen. Soweit ich weiß bietet REST aber überhaupt keine einheitliche Sicherheitsanforderungen. In der WSDL steht beschrieben wie die Signatur und Verschlüsselung der Inhaltsdaten zu erfolgen hat, für REST existiert meines Wissens nach sowas überhaupt nicht. Damit könnte jeder REST Service sein eigenes Süppchen kochen, was die Komplexität enorm steigern würde. Eher benötigen die meisten Webservices nicht mehr als eine Transportverschlüsselung und dafür wäre SOAP zu viel.

Bei JSON/REST brauch ich keine in JSON/REST implementierte Sicherheitslösung/Spezifikation. Ich nehme einfach das, was es schon seit Jahrzehnten gibe.
Ich Ruf eine URL auf und ob ich diese Aufruf erlaubt ist wird außerhalb meiner JSON/REST-Schnittstelle gelöst. Ich kann mich voll und ganz auf die eigene Logik konzentrieren.
Und solche Security-Lösung auf URL-Basis gibt es wie Sand am Meer.

Irgendwie kann ich dir nicht ganz folgen, was gibt es bereits seit Jahrzehnten und warum ist es besser auf eine einheitliche Spezifikation zu verzichten? Wenn ich mich in meiner Anwendung auch noch um die Validität und Authentizität der Nachricht kümmern muss, dann ist es für mich das gegenteil von ganz auf die eigene Businesslogik zu konzentrieren. In SOAP ist dieses Verfahren genau spezifiziert und idealerweise kümmert sich ein Framework um alles weitere, auch sind die Anforderungen jeden Teilnehmer klar. Da REST zu diesen Thema keine Vorgaben macht (ist ja eigentlich mehr eine Architektur, darunter kann ich auch einfach SOAP Nachrichten verschicken) steigt die Komplexität. Der eine Service verwendeten den Standard X, der andere verwendet eine Eigenentwicklung usw.

[MichaelT]

Prinzipiell kommt mal die 'Message' Philosophie aus der U.S. Logistik. Bspw. war der Message Broker ein Unternehmenstyp welcher alle Message in Empfang genommen hat, zumeist konvertiert hat und hernach weiterversandt.


Als ein Relikt blieb die EAI Idee.

Ich persönlich habe mal probiert die EAI Patterns inkl laufendem Server Environment umzusetzen und ehrlich, es ist zuviel 'Hockn' (österr. für Arbeit). Das entschuldigt zwar nicht die Abwesenheit dieser Funktionalität in Delphi, ... Weise Voraussicht war nicht der Treiben, aber es war schon zu Zeiten von Delphi 7 REST stammt aus 2000 und SOAP 1.0 und 1.1 waren damals noch aktuell. Borland hatte damals eher REST im Foku und möglw. .net im Focus mit Delphi 2005. Vermutung meinerseits.

Weswegen auch im Falle von SOAP ein SOAP Proxy habe mir zu Gemüte und der aus Deutschen Landen von Thomas Bayer ist bis heute noch immer die erste Wahl. Membrane EAI

Ehre wem Ehre gebührt.

Ich habe damals auch alle möglichen und gängigen auf Java aufbauenden Stacks inkl. deren Erweiterungen mit ins Kalkül aufgenommen und dann wird die Sache schon massiv aufwendig. Eine WSDL ist eine Sache und ob ein Feld optional oder zwingend hängt stark von der Serverseite ab. SAP sofern der Server in ABAP implementiert pfeift sich auf dem Eck exakt gar nichts. Mittlerweile ist der externe RFC Server und der gepufferte RFC für so manchen Methodenaufruf schon wieder eine wesentlich praktikablere Option.

Leider hat die inkonsequente Umsetzung dazu geführt, dass eine saubere Defintion einer WSDL in der Praxis ad absurdum wurde geführt.

Damit muss man die Messages wieder 'mit der Hand' anpassen.

Es hat sich allein herausgestellt, dass die ursprüngliche Vision der User mapped die Nachrichten selbst ins kanonische Unternehmensmodell (sofern so eines überhaupt existiert) in Ermangelung von Werkzeugen defakto nicht praktikabel ist. Damit wurde auf einmal wieder die Programmierung interessant. Der Trend ist eher bezogen auf WS* eher neu (wenn auch schon lange her). CAMEL Umfeld ...

Weites hat sich in der Praxis (nicht nur bei einem Kollegen in dessen Company) gezeigt, wenn der Client nicht auf einem Knopfdruck generiert wird fällt die Akzeptanz relativ schnell grad auch beim Programmierer. Ergänzt wurde das ganze noch um den Java Debugger welcher dann erlaube die Nachrichten zu debuggen.

Das alles ewig auf Stand halten ... und dann geht wieder einer auf einen andere Backentechnologie und es fehlt ein Stück vom Glück. Davon mal abgesehen hinkt man noch weiter hinterher als eh schon jetzt und so wechselfreudig sind die Infrastrukturbetreiber in dem Umfeld auch nicht mehr. Man muss ewig und 3 Tage mit Gott und der Welt kompatibel bleiben.

Alles andere bewegt sich stark in Richtung REST oder ähnlich gelagerten Alternativen wie als ein Beispiel unter einer Myriade erwähnt.

macchina.io im IoT Umfeld als ein Beispiel aus Kärnten.


Ewig und 3 Tage bleibt die Legacy eine Plage und die Kompatibilität wird eher über Infrastruktur am Leben gehalten. Im großen Bild ist eher eine der Infrastruktur nahe Lösung wahrscheinlicher.

Wenn ich von dem Bild ausgehe hätte einerseits kein Problem weder mit Third-Party noch mit jvm oder .net verwandten ausgelieferten Artfakten. Es wird in Europa halt noch dauern bis die Einsicht kommt, dass nicht jede Applikation mit jedem Backend können kann. Im Moment haben die kleinen Unternehmen bspw. aus dem Automotive Umfeld eine normierte Schnittstelle, aber nichts desto trotz schicken die ERP und 'WAWI' Software Hersteller allesamt auf ein Backend bei einem Message Broker der diese Nachrichten im Rahmen von Infrastruktur handelt.

Ich habe gearbeitet in einem E-Fullfillment Center in Los Angeles und dort habe ich zumindest mitbekommen was die tatsächlichen Probleme damals waren. Wenn mal die Trucks kommen zum Lagerhaus, ausladen auf einem Ende und am anderen wieder ein. Dazwischen werden ein paar Zehntausend Päckchen bis zu einer Mio. Pakete (Päckchen) mit eigenen Aufklebern werden versehen und wenn das Pickerl drauf ist, knattert eine Message raus übers Netz, dann sind wir eher in der Realität von dem was kommt. Ein paar hunderttausend mal ein paar Cent läppert sich :-D. Das war/ist das Geschäft der Message Broker und Converter.

Ich persönlich sehr Delphi und auch SOAP in dem Umfeld eher bedingt.

Ich selbst habe dann noch mit dem 4Tier Open-Mom Message Broker experimentiert usw... Ging, aber war ein wenig zu bald. Messages zu konvertieren war auch schon damals eine Python Domäne.

Mit dem Ansatz trenne die Applikation vom Message Routing selbst und meine Uni-Kollege mit seiner Company auf Dauer wesentlich besser gefahren.

Das mal Abseits der SOAP Frage ... allein da das Thema gut passt.

Zitat:

Zitat von Elrond (Beitrag 1389269)

Hallo Zusammen,

ich versuche mich aktuell an der Implementierung eines SOAP Clients in Delphi.

[Bernhard Geyer]

Zitat:

Zitat von Elrond (Beitrag 1389774)

Irgendwie kann ich dir nicht ganz folgen, was gibt es bereits seit Jahrzehnten

z.b. Http Basic Authentication (über https)
Cookies and session management
Token in HTTP headers (z.B. OAuth 2.0)

Zitat:

Zitat von Elrond (Beitrag 1389774)

und warum ist es besser auf eine einheitliche Spezifikation zu verzichten?

Es wird doch nicht auf eine einheitliche Spezifikation verzichtet. Es wird halt einfach eingenommen die schon (teilweise) schon sehr lange existiert.

Zitat:

Zitat von Elrond (Beitrag 1389774)

Wenn ich mich in meiner Anwendung auch noch um die Validität und Authentizität der Nachricht kümmern muss,

Musst du nicht. Diese ist letztendlich komplett außen vor. In Delphi sind über die Jahre für die ganzen schon existierenden Verfahren (wie OAuth) Komponenten dazu gekommen, so das der Implementierungsaufwand sehr überschaubar wird.

Zitat:

Zitat von Elrond (Beitrag 1389774)

In SOAP ist dieses Verfahren genau spezifiziert

Vermutlich Leitet auch SOAP über ein Art Überspezifikation. Statt etwas zu verwenden das es schon gibt meint man es in SOAP neu erfinden zu müssen.

Zitat:

Zitat von Elrond (Beitrag 1389774)

und idealerweise kümmert sich ein Framework um alles weitere, auch sind die Anforderungen jeden Teilnehmer klar.

Dann nimm doch so ein Framework. Bei Delphi/Emba wird es in diesem Bereich sehr wahrscheinlich keine Erweiterungen geben. Dazu ist SOAP hinter JSON/REST und Co. mittlerweile relativ unbedeutend geworden ist. Die Zukunft ist JSON/REST. SOAP ist mittlerweilen (fast) CORBA 2.0 zu nennen.
Evtl. ist auch der Schlusssatz in diesem Heise-Artikel ganz gut

Zitat:

Zitat von Elrond (Beitrag 1389774)

Da REST zu diesen Thema keine Vorgaben macht (ist ja eigentlich mehr eine Architektur, darunter kann ich auch einfach SOAP Nachrichten verschicken) steigt die Komplexität.

Klar kannst du über normale http-Abfragen auch SOAP-Nachrichten verschicken.
Du kannst dich aber auch gleich ins Knie schießen. Kommt aufs gleiche raus.

Zitat:

Zitat von Elrond (Beitrag 1389774)

Der eine Service verwendeten den Standard X, der andere verwendet eine Eigenentwicklung usw.

:gruebel: Nö. Passiert eigentlich nicht. Es gibt eine Hand voll Standards die man Einsetzen kann. Aber den Aufwand einer Eigenentwicklung wird sich keiner antun.

[EmWieMichael]

Elrond, hast Du diesen Thread, insbesondere Seite 3, gesehen. Funktioniert bei mir seit Jahren einwandfrei im gesicherten Deutschland-Online-Netz (DOI), mit Client-Zertifikaten.
Vielleicht hilfts Dir...

[Elrond]

@MichaelT

Ein Interessanter Einblick, auch kommen mir einige Punkte bekannt vor.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1389780)

Zitat:

Zitat von Elrond (Beitrag 1389774)

Irgendwie kann ich dir nicht ganz folgen, was gibt es bereits seit Jahrzehnten

z.b. Http Basic Authentication (über https)
Cookies and session management
Token in HTTP headers (z.B. OAuth 2.0)

Wir reden grad aneinander Vorbei, du bezieht sich die ganze Zeit auf den Transportweg und ich auf den Inhalt. Die WSS-Spezifikation beschreibt nicht nur wie der Transport zu erfolgen hat sondern auch die Anforderungen an den Inhalt. Die Validität und Authentizität der Nachricht ist auch nach den Empfang gegeben, Beispielsweise während einer internen Weiterleitung und nur der Leser hat Zugriff auf den Inhalt. Soweit ich weiß gibt es in REST so etwas nicht, da der Inhalt unabhängig ist, es ist wie soll ich sagen eine rein technische Schnittstelle.

[Bernhard Geyer]

Zitat:

Zitat von Elrond (Beitrag 1389789)

Die WSS-Spezifikation beschreibt nicht nur wie der Transport zu erfolgen hat sondern auch die Anforderungen an den Inhalt.

Und welche Teile davon? Und wann ist das IRL (in Real Live) relevant?
Für Viele Anwendungsfälle ist das einfach überspezifiziert.

Zitat:

Zitat von Elrond (Beitrag 1389789)

Die Validität und Authentizität der Nachricht ist auch nach den Empfang gegeben,

Was genau davon? Wenn ich ein Nachricht per https verschicke (und die Verschlüsselung/Sicheheit durch lokale Firewalls/Virenscanner kaputt gemacht wurde ist die Authentizität gegeben.
Jetzt wäre die Frage was du mit Validität genau meinst?

Zitat:

Zitat von Elrond (Beitrag 1389789)

Beispielsweise während einer internen Weiterleitung

Jetzt mal konkret. Was soll hier wie kaputt gemacht werden/gefälscht werden.

Zitat:

Zitat von Elrond (Beitrag 1389789)

und nur der Leser hat Zugriff auf den Inhalt.

Solange du keine Transportverschlüsselung aktiv hast kann jeder den Inhalt lesen

Zitat:

Zitat von Elrond (Beitrag 1389789)

Soweit ich weiß gibt es in REST so etwas nicht

Ich denke das was du bisher angesprochen hast wird von (fast) keinen vermisst.

[Elrond]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1389793)

Zitat:

Zitat von Elrond (Beitrag 1389789)

Die WSS-Spezifikation beschreibt nicht nur wie der Transport zu erfolgen hat sondern auch die Anforderungen an den Inhalt.

Und welche Teile davon? Und wann ist das IRL (in Real Live) relevant?
Für Viele Anwendungsfälle ist das einfach überspezifiziert.

Es ist für alle Fälle relevant wo die Transportverschlüsselung nicht mehr ausreicht. Wurde diese ausgehebelt, vielleicht durch eine MITM-Attacke, dann sind die Daten weiterhin geschützt durch ihre eigene Verschlüsselung. Auch eine Mehrfachverschlüsselung kann in Frage kommen um sicherzugehen das alle Leser "anwesend" sind. In meinen konkreten Fall werden sensible personenbezogene Daten übermittelt.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1389793)

Zitat:

Zitat von Elrond (Beitrag 1389789)

Die Validität und Authentizität der Nachricht ist auch nach den Empfang gegeben,

Was genau davon? Wenn ich ein Nachricht per https verschicke (und die Verschlüsselung/Sicheheit durch lokale Firewalls/Virenscanner kaputt gemacht wurde ist die Authentizität gegeben.
Jetzt wäre die Frage was du mit Validität genau meinst?

Das die Nachricht unterwegs nicht verändert wurde.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1389793)

Zitat:

Zitat von Elrond (Beitrag 1389789)

Beispielsweise während einer internen Weiterleitung

Jetzt mal konkret. Was soll hier wie kaputt gemacht werden/gefälscht werden.

Server (Empfänger) wurde kompromittiert, ist der Leser aber intakt kann die Sicherheit der Nachricht noch gewährleistet werden.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1389793)

Zitat:

Zitat von Elrond (Beitrag 1389789)

und nur der Leser hat Zugriff auf den Inhalt.

Solange du keine Transportverschlüsselung aktiv hast kann jeder den Inhalt lesen

Natürlich sollte die Transportverschlüsselung aktiv sein, aber wenn nicht, dann kann eben nicht jeder den Inhalt lesen, weil der Inhalt verschlüsselt und ggf. noch signiert ist.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1389793)

Zitat:

Zitat von Elrond (Beitrag 1389789)

Soweit ich weiß gibt es in REST so etwas nicht

Ich denke das was du bisher angesprochen hast wird von (fast) keinen vermisst.

Für die meisten ist es egal, wenn die Sicherheit jedoch solche Forderungen stellt, sieht es anders aus.

[Bernhard Geyer]

Kann es sein das du im Medizinbereich unterwegs bist?
Evtl. noch das sehr "erfolgreiche" Projekt Gesundheitskarte?

[Elrond]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1389813)

Kann es sein das du im Medizinbereich unterwegs bist?
Evtl. noch das sehr "erfolgreiche" Projekt Gesundheitskarte?

Ja, wie auch im Gesundheitswesen und öffentliche Verwaltung im Allgemeinen. Deiner restlichen Aussage nachzuurteilen scheinst du wenig Vertrauen in diesen Bereich zu setzen, leider ohne Begründung. Als kleine Nebeninformation, die gesamte öffentliche Verwaltung setzt auf den OSCI-Standard, das macht im Prinzip das gleiche wie SOAP mit den WS-Stack. Warum nicht gleich SOAP verwendet wurde kann ich nicht sagen (evtl begann die Planung bevor der WS-Stack den heutigen Umfang hatte). Das Behördennetz ist für außenstehende nicht direkt erreichbar, für die Kommunikation über das öffentliche Netz stehen sogenannte Empfänger bereit, diese haben mit den eigentlichen Empfänger (den Leser) absolut nichts gemeinsam. Aus diesen Grund müssen fast immer die Inhaltsdaten separat verschlüsselt werden. Mit anderen Worten das perfekte Szenario für SOAP und weil es so gut passt, setzt die aktuelle neuentwicklung von OSCI vollständig auf SOAP. Unsere Nachbarn scheinen den nicht abgeneigt zu sein und das große Ziel ist die Kommunikation innerhalb der EU mit OSCI-2 zu vereinheitlichen. Das ist ein echter Fortschritt, wenn ich daran denke wie für die EU-weite Erfassung von Asylanten ein Webservice aus den frühen 90er zum Einsatz kommt (einfach nur XML über http, zur Doku gibt es eine xsd..).

[Bernhard Geyer]

Zitat:

Zitat von Elrond (Beitrag 1389817)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1389813)

Kann es sein das du im Medizinbereich unterwegs bist?
Evtl. noch das sehr "erfolgreiche" Projekt Gesundheitskarte?

Ja, wie auch im Gesundheitswesen und öffentliche Verwaltung im Allgemeinen. Deiner restlichen Aussage nachzuurteilen scheinst du wenig Vertrauen in diesen Bereich zu setzen, leider ohne Begründung.

Sagen wir so: Man hat so seine Erfahrung im Medizinbereich ...

Zitat:

Zitat von Elrond (Beitrag 1389817)

Als kleine Nebeninformation, die gesamte öffentliche Verwaltung setzt auf den OSCI-Standard, das macht im Prinzip das gleiche wie SOAP mit den WS-Stack. Warum nicht gleich SOAP verwendet wurde kann ich nicht sagen (evtl begann die Planung bevor der WS-Stack den heutigen Umfang hatte) ...

Hättest du am Anfang mehr Infos geliefert, wäre es klar gewesen das in deinem Fall jegliche Diskussion sinnlos ist da hier von "anderer Stelle" alles vorgegeben ist und vermutlich eine Einflussnahme keine Chance hat. Evtl. hätten auch Mitforisten dir konkrete Tipps geben können, wenn sie gewusst hätten um welche konkrete Api es geht.

Ein Ähnliches "Spezifikations bis in Kleinste" gibt es sonst nur noch im Militär/Luftfahrtsbereich. Dort aber auch noch mit dem Problem das man Standards aus dem Papierzeitalter (als noch Dokumentation als "Schwerlastlieferung" in Papierform erfolgte auf im Digitalen Zeitalter unterstützen muss.
Ansonsten kann auch die "öffentliche Verwaltung" sagen wir mal "sehr herausfordernd" sein ...

[p80286]

@Bernhard
Ich war ja im Patentbereich tätig. Und ich muß zugeben zu Anfang habe ich mich gefragt was diese Definition bis in kleinste soll. Nach etwas Erfahrung mit der kreativen Schlampigkeit der Anwender - das sieht man doch - halte ich diesen Aufwand für durchaus gerechtfertigt.

Gruß
K-H