Authentifikation bei SOAP?

dennis81 · 22.01.2011, 12:47

Hi zusammen.

Ich programmiere zur Zeit eine Anwendung mit dem Zend Framework. Funktioniert alles prima, obwohl das hier kaum Relevanz hat...

In der Anwendung werde auch Nutzer bzw. Empfänger gepflegt. Erst einmal geschieht das rein in der Anwendung von den Redakteuren. Nun soll es aber so sein, dass Empfänger ihre eigenen auf einer Webseite (die mit der Anwendung nichts zu tun hat) bearbeiten können sollen.

Ich habe mir eine Lösung via SOAP vorgestellt. Meine SOAP Schnittstelle könnte grob 4 Methoden bereitstellen:

Code:

string login(userIdent, passwordHash)
string getForm(userIdent, secToken)
string saveForm(userIdent, secToken, data)
string unsubsribe(userIdent, secToken)

Irgendwie muss ich ja auch für die Sicherheit sorgen. login soll also den Benutzer identifizieren und eine Art Security Token übergeben, dass eindeutig ist und z.B. nur eine gewisse Gültigkeit besitzt (hier fehlen mir noch Implementierungsdetails). Bei jeder weiteren Methode soll dann nur noch das Token mit übergeben werden. Ich müsste also nicht das Kennwort irgendwo zwischenspeichern (auch nicht den Hash davon).

Ich habe mir auch gedacht, ob es evtl. Sinn macht, ein Handshake zu implementieren. D.h., dass beide "Partner" aus dem 1. Token mit einer beiden zur Verfügung stehenden Methode ein zweiten Token berechnen, dass dann immer abgeglichen wird.

Nun meine Frage(n):
Ist das Vorgehen überhaupt praktikabel?
Macht es grundsätzlich Sinn, dass beim Datenaustauch über SOAP zu implementieren?
Sehe ich evtl. zu viele Risiken? (Wobei das ja kaum geht)

Danke schon mal!

Sirke · 22.01.2011, 14:21

Ich gehe mal davon aus - da wir hier im PHP Forum sind - dass du SOAP über HTTP verwenden möchtest. Dann bietet sich auf jeden Fall an die Authentifikation nicht selbst zu schreiben, sondern SAML über SOAP über HTTP zu verwenden. Damit schlägt man dann viele Fliegen mit einer Klappe!

Ich verstehe nur deine Frage nach dem Sinn nicht ganz: Lautet die Frage eigentlich, ob Sicherheit Sinn macht oder ob man die Sicherheit auf eine andere Ebene verschieben sollte? Welche Ebenen bieten sich denn bei dir noch an?

dennis81 · 22.01.2011, 16:04

Die Frage nach dem Sinn bezog sich auf die Ebene. Also, dass die SOAP Schnittstelle das regelt. Aber mir fiele jetzt auch nichts anderes an.
Und ja, via http. Ich schaue mir mal SAML an.

mquadrat · 25.01.2011, 09:46

SAML wäre ein Ansatz um die Berechtigung für ein konkretes Objekt abzuprüfen (wenn ich mich jetzt nicht irre - ist ne Weile her). Wenn es primär darum geht den Web-Service als solchen gegen unbefugte Nutzung abzusichern wäre eher ein Blick auf WS* nötig. Damit lässt sich sowohl die Authentifikation als auch Verschlüsselung etc. regeln.

Die Frage, die sich mir stellt ist also was du überhaupt schützen möchtest (ggf. hast du es geschrieben, bin aber erst beim ersten Kaffee

)

dennis81 · 25.01.2011, 18:32

Vorab, ich bin noch nicht dabei, das ganze umzusetzen. Da habe ich momentan noch ein paar andere Dinge zu tun.

Es geht darum, Profile bearbeiten zu können. Wenn meine Anwendung ein öffentliches Interface hätte, würde ein einfacher Login genügen. Aber ich möchte das unabhängig von der Anwendung anbieten können und dachte da eben an SOAP. Ich benötige aber dennoch eine Art Login-Mechanismus, zum einen um mir benutzerbezogene Daten von der SOAP-Schnittstelle liefern zu lassen und zum anderen, um sicherzustellen, dass nicht unbefugt Daten anderer Mitglieder manipuliert und ausgelesen werden können.

mquadrat · 25.01.2011, 19:25

Stellt sich die Frage nach dem Schutzbedürfnis. WS* ist immer so eine Sache in der Implementierung.

Wie sieht dein Transportweg aus? Verschlüsselt (HTTPS) oder offen? Wenn offen, arbeitest du mit einem Challenge-Response oder muss das Passwort über die Leitung? Offener Transportweg und Klartext-Passwort sollte unbedingt vermieden werden.

dennis81 · 26.01.2011, 07:53

Zitat:

Zitat von mquadrat

Wie sieht dein Transportweg aus? Verschlüsselt (HTTPS) oder offen? Wenn offen, arbeitest du mit einem Challenge-Response oder muss das Passwort über die Leitung? Offener Transportweg und Klartext-Passwort sollte unbedingt vermieden werden.

Wie gesagt, noch arbeite ich gar nicht daran. Ich möchte herausfinden, welcher Weg sinnvoll ist. Inwiefern da https eingerichtet werden kann, müsste ich noch mal klären. Wäre aber durchaus sinnvoll.

An ein Challenge-Response habe ich auch schon gedacht. Aber was wäre hier eine geeignete "Aufgabe" die es zu lösen gilt?
Ich muss meinem Partner ja im Prinzip einen Parameter angeben, den er nach einem bestimmten Verfahren in eine korrekte Antwort umwandeln kann. Wie hat ein solcher Algorithmus auszusehen? Welche Eigenschaften benötigt er?

mquadrat · 26.01.2011, 12:45

Also bei den RFID Karten läuft das wenn ich nicht irre über zufällige Rechenaufgaben in denen Variablen vorkommen, die nur den korrekten Kommunikationspartnern bekannt sind. Also ein Pre-Shared-Secret. Könnten aber auch noch weitere Variablen sein, die adhoc berechnet werden.

Das Wichtigste ist, dass sowohl die Challenge als auch der Response bei jeder Authentifikation unterschiedlich sind um Replay-Attacken abzuwähren.

G.Schuster · 26.01.2011, 15:17

Da Replay-Attacken bereits angesprochen wurden gibt's auch eine vereinfachte Möglichkeit, indem ein zeitabhängiger Hash des Passworts generiert wird.
Setzt allerdings voraus, das Client und Server annähernd die gleiche Uhrzeit haben.
Client: $pw = sha1(sha1($password).$time.$nonce);
-> sende $pw, $time, $nonce an Server
Server: $time älter als z.B. 5 Minuten: ablehnen
Andernfalls: sha1($sha1PasswordAusDb.$time.$nonce) = $hashedPW?

Mit den Einzelkomponenten fängt ein Angreifer nur bedingt etwas an, für einen Replay hat er im Grunde genau die Zeitspanne, die der Hash gültig ist.
Hat aber immernoch den Vorteil, dass das Passwort weder im Klartext noch als immer gleicher Hash übertragen wird.
Mit etwas mehr Arbeit könnte man natürlich bereits "verbrauchte" Hashs auch noch sperren, das sollte ein Replay dann relativ gut verhindern.

Sirke · 26.01.2011, 19:52

Die Variante von G.Schuster ist nicht sinnvoll, weil zum einem Server und Client die gleiche Uhrzeit haben müssen, was zur Folge hat, dass ein authentischer Zeitserver zum Einsatz kommen muss (was noch mehr Aufwand zur Folge hat), zum anderen ist der Hash über einen unbekannten Wert für die eine Seite eine falsche herangehensweise, da wenn man schon ein gemeinsames Geheimnis teilt, dann kann man dieses auch zum Verschlüsseln nutzen...

@dennis81: Wenn du selbst keine Ahnung davon hast ein Authentifikations-Protokoll zu entwerfen, dann würde ich an deiner Stelle auf bereits bekannte Protokolle setzen. Vorallem solltest du dir vorher im klaren drüber sein, ob symmetrische Kryptographie oder asymmetrische Kryptographie zum Einsatz kommen soll, ob evtl eine PKI bereits existiert oder gewünscht ist...
Generell musst du wissen, was du genau haben möchtest: Soll nur die Echtheit der Daten bestätigt werden, soll anschließend noch verschlüsselt kommuniziert werden oder oder oder...

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
WSDL Zugriff SOAP (Authenifizierung)	PatrickStar88	PHP-Fortgeschrittene	1	01.12.2010 12:24
SOAP, MySQL Beispielcode	Ralf Meyer	PHP Tipps 2010	8	16.11.2010 14:47
SOAP Server und PHP	MaHzeL	PHP-Fortgeschrittene	4	14.07.2010 19:00
PHP und SOAP timeout	Yuen	PHP Tipps 2010	1	06.07.2010 12:12
Scriptsuche Soap Schnittstelle mit eigener class	mawiba	Scriptbörse	0	09.12.2009 15:07
Probleme mit SOAP über HTTPS - Timeouts	soesti	PHP Tipps 2009	0	30.09.2009 14:44
SOAP API von validator.w3.org auslesen	Sascha1976	PHP Tipps 2009	3	03.07.2009 18:34
SOAP Dokumentelstil	Mad_Dog	PHP-Fortgeschrittene	2	19.09.2008 20:27
Fragen und Verwendung der SOAP Erweiterung von PHP	Tanja	PHP-Fortgeschrittene	5	15.09.2008 09:29
Größenbeschränkung bei PEAR SOAP Antwort?	Anotherone	PHP-Fortgeschrittene	1	13.01.2008 20:32
SOAP Server Parameter richtig zuordnen	Anotherone	PHP Tipps 2008	0	12.12.2007 11:23
SOAP bindings ?!?	stonefred71	PHP-Fortgeschrittene	0	08.11.2007 18:27
php5 soap extension, soap attachment	zcmaster	PHP-Fortgeschrittene	0	07.08.2006 16:09
SOAP und PHP	cola	PHP-Fortgeschrittene	21	01.06.2006 11:33
[Erledigt] XML String an Webservice übergeben (SOAP)		PHP-Fortgeschrittene	3	26.08.2005 12:40

22.01.2011, 12:47
dennis81 Erfahrener Benutzer Registriert seit: 13.05.2009 Beiträge: 1.167 PHP-Kenntnisse: Fortgeschritten	Authentifikation bei SOAP? Hi zusammen. Ich programmiere zur Zeit eine Anwendung mit dem Zend Framework. Funktioniert alles prima, obwohl das hier kaum Relevanz hat... In der Anwendung werde auch Nutzer bzw. Empfänger gepflegt. Erst einmal geschieht das rein in der Anwendung von den Redakteuren. Nun soll es aber so sein, dass Empfänger ihre eigenen auf einer Webseite (die mit der Anwendung nichts zu tun hat) bearbeiten können sollen. Ich habe mir eine Lösung via SOAP vorgestellt. Meine SOAP Schnittstelle könnte grob 4 Methoden bereitstellen: Code: string login(userIdent, passwordHash) string getForm(userIdent, secToken) string saveForm(userIdent, secToken, data) string unsubsribe(userIdent, secToken) Irgendwie muss ich ja auch für die Sicherheit sorgen. login soll also den Benutzer identifizieren und eine Art Security Token übergeben, dass eindeutig ist und z.B. nur eine gewisse Gültigkeit besitzt (hier fehlen mir noch Implementierungsdetails). Bei jeder weiteren Methode soll dann nur noch das Token mit übergeben werden. Ich müsste also nicht das Kennwort irgendwo zwischenspeichern (auch nicht den Hash davon). Ich habe mir auch gedacht, ob es evtl. Sinn macht, ein Handshake zu implementieren. D.h., dass beide "Partner" aus dem 1. Token mit einer beiden zur Verfügung stehenden Methode ein zweiten Token berechnen, dass dann immer abgeglichen wird. Nun meine Frage(n): Ist das Vorgehen überhaupt praktikabel? Macht es grundsätzlich Sinn, dass beim Datenaustauch über SOAP zu implementieren? Sehe ich evtl. zu viele Risiken? (Wobei das ja kaum geht) Danke schon mal! __________________ Es ist schon alles gesagt! Nur noch nicht von allen! (Karl Valentin) Wenn du eine weise Antwort verlangst, musst du vernünftig fragen. (Johann Wolfgang von Goethe)


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

22.01.2011, 14:21
Sirke Erfahrener Benutzer Registriert seit: 04.07.2003 Beiträge: 359 PHP-Kenntnisse: Fortgeschritten	Ich gehe mal davon aus - da wir hier im PHP Forum sind - dass du SOAP über HTTP verwenden möchtest. Dann bietet sich auf jeden Fall an die Authentifikation nicht selbst zu schreiben, sondern SAML über SOAP über HTTP zu verwenden. Damit schlägt man dann viele Fliegen mit einer Klappe! Ich verstehe nur deine Frage nach dem Sinn nicht ganz: Lautet die Frage eigentlich, ob Sicherheit Sinn macht oder ob man die Sicherheit auf eine andere Ebene verschieben sollte? Welche Ebenen bieten sich denn bei dir noch an?

22.01.2011, 16:04
dennis81 Erfahrener Benutzer Registriert seit: 13.05.2009 Beiträge: 1.167 PHP-Kenntnisse: Fortgeschritten	Die Frage nach dem Sinn bezog sich auf die Ebene. Also, dass die SOAP Schnittstelle das regelt. Aber mir fiele jetzt auch nichts anderes an. Und ja, via http. Ich schaue mir mal SAML an. __________________ Es ist schon alles gesagt! Nur noch nicht von allen! (Karl Valentin) Wenn du eine weise Antwort verlangst, musst du vernünftig fragen. (Johann Wolfgang von Goethe)

25.01.2011, 09:46
mquadrat Erfahrener Benutzer Registriert seit: 02.09.2009 Beiträge: 1.019 PHP-Kenntnisse: Fortgeschritten	SAML wäre ein Ansatz um die Berechtigung für ein konkretes Objekt abzuprüfen (wenn ich mich jetzt nicht irre - ist ne Weile her). Wenn es primär darum geht den Web-Service als solchen gegen unbefugte Nutzung abzusichern wäre eher ein Blick auf WS* nötig. Damit lässt sich sowohl die Authentifikation als auch Verschlüsselung etc. regeln. Die Frage, die sich mir stellt ist also was du überhaupt schützen möchtest (ggf. hast du es geschrieben, bin aber erst beim ersten Kaffee ) __________________ Wir suchen PHP Entwickler (Vollzeit) im Raum Darmstadt / Rhein-Main. Infos via E-Mail mueller@new-frontiers.de

25.01.2011, 18:32
dennis81 Erfahrener Benutzer Registriert seit: 13.05.2009 Beiträge: 1.167 PHP-Kenntnisse: Fortgeschritten	Vorab, ich bin noch nicht dabei, das ganze umzusetzen. Da habe ich momentan noch ein paar andere Dinge zu tun. Es geht darum, Profile bearbeiten zu können. Wenn meine Anwendung ein öffentliches Interface hätte, würde ein einfacher Login genügen. Aber ich möchte das unabhängig von der Anwendung anbieten können und dachte da eben an SOAP. Ich benötige aber dennoch eine Art Login-Mechanismus, zum einen um mir benutzerbezogene Daten von der SOAP-Schnittstelle liefern zu lassen und zum anderen, um sicherzustellen, dass nicht unbefugt Daten anderer Mitglieder manipuliert und ausgelesen werden können. __________________ Es ist schon alles gesagt! Nur noch nicht von allen! (Karl Valentin) Wenn du eine weise Antwort verlangst, musst du vernünftig fragen. (Johann Wolfgang von Goethe)

25.01.2011, 19:25
mquadrat Erfahrener Benutzer Registriert seit: 02.09.2009 Beiträge: 1.019 PHP-Kenntnisse: Fortgeschritten	Stellt sich die Frage nach dem Schutzbedürfnis. WS* ist immer so eine Sache in der Implementierung. Wie sieht dein Transportweg aus? Verschlüsselt (HTTPS) oder offen? Wenn offen, arbeitest du mit einem Challenge-Response oder muss das Passwort über die Leitung? Offener Transportweg und Klartext-Passwort sollte unbedingt vermieden werden. __________________ Wir suchen PHP Entwickler (Vollzeit) im Raum Darmstadt / Rhein-Main. Infos via E-Mail mueller@new-frontiers.de

26.01.2011, 12:45
mquadrat Erfahrener Benutzer Registriert seit: 02.09.2009 Beiträge: 1.019 PHP-Kenntnisse: Fortgeschritten	Also bei den RFID Karten läuft das wenn ich nicht irre über zufällige Rechenaufgaben in denen Variablen vorkommen, die nur den korrekten Kommunikationspartnern bekannt sind. Also ein Pre-Shared-Secret. Könnten aber auch noch weitere Variablen sein, die adhoc berechnet werden. Das Wichtigste ist, dass sowohl die Challenge als auch der Response bei jeder Authentifikation unterschiedlich sind um Replay-Attacken abzuwähren. __________________ Wir suchen PHP Entwickler (Vollzeit) im Raum Darmstadt / Rhein-Main. Infos via E-Mail mueller@new-frontiers.de

26.01.2011, 15:17
G.Schuster Erfahrener Benutzer Registriert seit: 21.12.2009 Beiträge: 415 PHP-Kenntnisse: Fortgeschritten	Da Replay-Attacken bereits angesprochen wurden gibt's auch eine vereinfachte Möglichkeit, indem ein zeitabhängiger Hash des Passworts generiert wird. Setzt allerdings voraus, das Client und Server annähernd die gleiche Uhrzeit haben. Client: $pw = sha1(sha1($password).$time.$nonce); -> sende $pw, $time, $nonce an Server Server: $time älter als z.B. 5 Minuten: ablehnen Andernfalls: sha1($sha1PasswordAusDb.$time.$nonce) = $hashedPW? Mit den Einzelkomponenten fängt ein Angreifer nur bedingt etwas an, für einen Replay hat er im Grunde genau die Zeitspanne, die der Hash gültig ist. Hat aber immernoch den Vorteil, dass das Passwort weder im Klartext noch als immer gleicher Hash übertragen wird. Mit etwas mehr Arbeit könnte man natürlich bereits "verbrauchte" Hashs auch noch sperren, das sollte ein Replay dann relativ gut verhindern. __________________ actra.development - Schwabstr. 2 - 70825 Münchingen www.actra.de/velopment/ - eMail: php.de@actra.de Zend Certified Engineer for PHP5

26.01.2011, 19:52
Sirke Erfahrener Benutzer Registriert seit: 04.07.2003 Beiträge: 359 PHP-Kenntnisse: Fortgeschritten	Die Variante von G.Schuster ist nicht sinnvoll, weil zum einem Server und Client die gleiche Uhrzeit haben müssen, was zur Folge hat, dass ein authentischer Zeitserver zum Einsatz kommen muss (was noch mehr Aufwand zur Folge hat), zum anderen ist der Hash über einen unbekannten Wert für die eine Seite eine falsche herangehensweise, da wenn man schon ein gemeinsames Geheimnis teilt, dann kann man dieses auch zum Verschlüsseln nutzen... @dennis81: Wenn du selbst keine Ahnung davon hast ein Authentifikations-Protokoll zu entwerfen, dann würde ich an deiner Stelle auf bereits bekannte Protokolle setzen. Vorallem solltest du dir vorher im klaren drüber sein, ob symmetrische Kryptographie oder asymmetrische Kryptographie zum Einsatz kommen soll, ob evtl eine PKI bereits existiert oder gewünscht ist... Generell musst du wissen, was du genau haben möchtest: Soll nur die Echtheit der Daten bestätigt werden, soll anschließend noch verschlüsselt kommuniziert werden oder oder oder...