Webservice Provider / Authentifikation

[Driri]

Hallo,

wir haben schon ein paar Webservices unter Domino erstellt, diese laufen allerdings alle mit Server-Berechtigung und via Anonymous-Zugriff. Da es sich hier immer um unkritische Daten gehandelt hat, haben wir da bisher auch keinen Aufwand in die Sicherheit gesteckt.

Jetzt wollen wir das Thema aber mal "aufbohren" und dafür muß dann natürlich auch eine Authentifikation erfolgen und der Webservice als Webuser bzw. mit der Webuser-Berechtigung laufen.

Ich habe jetzt einfach einen ganz simplen Webservice als Test erstellt :

Code

Class Test
	
	Public Function TestText (eingabe As String) As String
		TestText = eingabe
	End Function
	
End Class

Aufgerufen via Anonymous funktioniert das auch tadellos. Wenn ich aber jetzt umstelle auf Authentifizierung (ACL, Webservice auf Webbenutzer), bekomme ich folgende Fehlermeldung :

INVALID_WSDL: : White spaces are required between publicId and systemId.

Leider hilft mir da Onkel Google auch nicht so recht weiter, denn mit der Meldung finde ich nur Hinweise auf Probleme bei Webservice Consumern.

Mein Kollege vom Web-Team meint, daß die WSDL nicht sauber ist. Da fehlen wohl einige Parameter bzw. die sind leer. Das würde auch zu der Fehlermeldung passen.

Ich habe nur keine Idee, was ich an dieser Stelle tun könnte. In den Eigenschaften des Webservice habe ich auch schon so ziemlich alle Einstellungen / Kombinationen durch (PortType, Programmiermodell, Nachrichtenformat und Operationsname in SOAP-Aktion aufnehmen).

Hat jemand so etwas schon mal gemacht ? Funktioniert das auch mit LotusScript-basierten Webservice oder muß man da auf Java zurückgreifen ?

[m3]

Ist die Session Authentication am Server oder zumindest für die SOAP URLs eh deaktiviert?

Ev. bekommt der SOAP Client ja die Webseite für die Anmeldung zu gesicht und verschluckt sich daran?

Mit SoapUI sollte man das im Response auf den SOAP Request sehen.

[Driri]

Session authentication ist auf Multiple Servers (SSO) eingestellt. Wir haben an dem Server einen LTPA-Token von unserem WebSphere Portal eingebunden.

Ziel der ganzen Geschichte ist dann auch, aus Portlets heraus auf Domino-Webservices zuzugreifen und dabei das SSO via LTPA zu nutzen.

SOAP UI schaue ich mir mal an, danke für den Tipp.

[Driri]

Das ist tatsächlich der Fall. Der SOAP Client bekommt die Login-Maske vom Domino als Antwort und kommt damit vermutlich nicht klar.

Jetzt bin ich da leider absoluter Neuling. Was ich via SOAP UI feststellen konnte, ist daß wenn ich bei der Authentifizierung auf "Preemptive" umschalte, die Anmeldung mit Benutzername und Kennwort sauber durchläuft und der Webservice mir auch eine korrekte Antwort liefert.

Hat da jemand eine Idee zu oder einen Tipp ?

[Thomas Schulte]

Geh mit dem Problem zu Tim. Der kann dir helfen.

[dnotes]

Gibst Du einen Benutzernamen und Kennwort mit??
Darüber kann er sich doch authentifizieren.

[m3]

Been there, done that

Du hast zwei Möglichkeiten
1) Der SOAP Client schickt einen gültigen LTPA Token im HTTP HEADER, nicht im SOAP header, mit. Damit wird der Request vom Domino http authentifiziert und dann an den SOAP code weitergeleitet

2) Du richtest im WebSite Dokument eine Regel ein, dass bei den SOAP URLs nicht Session, sondern Basic Authentication gilt. Dann muss der SOAP Client nur HTTP Basic Authentication machen und alles ist gut.

Mit "preemptive authentication" macht der SoapUI Client nichts anderes als (2),  nur wartet er nicht auf den Challenge sondern schickt schon im vorauseilenden Gehorsam Username/Passwort. Wenn Du auf Basic Auth. umstellst, brauchst Du das "preemtive" nicht.

BTW: Der Domino Server kann NICHT SOAP Authentication. (das können wir nur im SOAP Client code gegen einen anderen Server)

[Driri]

@dnotes

Klar. Wobei Ziel ja nicht Benutzername/Kennwort ist, sondern der LTPA-Token.


@Martin

Danke, ich gebe das mal an unseren Web-Spezi weiter. Mal schauen, ob wir da gemeinsam eine Lösung finden.

[flaite]

Klingt logisch der Vorschlag von Martin.
Ich hab ja vor Jahren ein Projekt mit einem Java Jakarta HTTPClient gegen Domino Webservices gemacht. In HTTPClient gibts auch so eine preemptive flag wie in SOAP UI. Das gilt übrigens auch als unsicher. War aber damals eh intranet.
Zur Sicherheit würd ich echt über ssl nachdenken. Ansonsten geht ja alles inkl. Passwörter unverschlüsselt übers Netz.
In sehr verteilten JEE Topologien wird übrigens in SOAP Webservices nicht der Server mit der Web-Anwendung angesprochen sondern ein anderer.
Bei Webservice Projekten am besten von der ersten Minute an ein HTTP sniffer wie wireshark oder fiddler benutzen. Dann hättest Du das mit der zurückgelieferten Authentifizierungs-Maske bei session based auth direkt erkannt.
 

[Driri]

Danke, ich bin in dem Umfeld noch ziemlich grün hinter den Ohren und für jede Hinweis dankbar.

SSL ist sowieso angedacht, allerdings noch nicht umgesetzt. Es handelt sich allerdings um eine Einbindung im Intranet, daher ist das evtl. nicht ganz so kritisch.

[flaite]

1. Klein anfangen.
2. Falls irgendein SOA Theoretiker dabei ist, am besten direkt bei mir melden. Da hab ich schon dolle Sachen erlebt. Im nachhinein hab ich bei einer Adam Bien Schulung gelernt, wie man solche Leute stoppen kann. Falls nicht, sehr viel besser.
3. Tooling! Es gibt so Proxie-Tools, die die zwischen Consumer und Producer ausgetauschten Messages interzepten, speichern und weiterleiten. Kann super-hilfreich sein, die Nachricht sehen zu können!
4. Encoding. Am besten, es ist alles UTF-8. Ansonsten früh mit Sonderzeichen testen.
5. Interoperabilität kann ein Problem sein. Gerade bei SOAP. Die ausgetauschten Datentypen möglichst einfach halten und früh testen, ob beide Endpunkte die übermittelten Datentypen verstehen.
6. Sich ernsthaft Gedanken machen, welches System für den Datenbestand das führende ist. Da hat ich auch schon interessante Meetings.