Laden...

WebService - Authentication Konzeptfrage

Erstellt von Floyd vor 14 Jahren Letzter Beitrag vor 14 Jahren 1.965 Views
Floyd Themenstarter:in
85 Beiträge seit 2006
vor 14 Jahren
WebService - Authentication Konzeptfrage

Hallo,

in meiner Firma habe ich nun den Auftrag bekommen einen Webservice zu entwickeln der jedoch in sachen Authentifizierung eine spezielle Anforderung hat. Die Frage ist, ob und wie sich die Anforderung lösen läßt:

Vorraussetzungen:
.Net Framework 2.0 (keine Lösungen bitte für 3.0 oder 3.5 vorschlagen)

Anforderung:

Und zwar sollen Methoden sowohl für das Intranet, als auch für das Extranet zur Verfügung gestellt werden. Das Extranet ist vom Intranet über eine Firewall getrennt.
Bei allen Anfragen die über das Extranet gestellt werden, sollen ein speziellen Token als Authentifizierung geprüft werden. Also eine Art Nutzername, Passwort. Alle Anfragen die über das Intranet gestellt werden, sollen jedoch OHNE dieses Authenfitizeirungstoken beantwortet werden.

Als Beispiel:

Eine Funktion Addiere(a,b) soll wenn Sie aus dem Intranet aufgerufen wird, ohne Authenfizierung, einfach beantwortet werden. Wird Sie jedoch vom Extranet ausgerufen, muss das Authentifizierungstoken geprüft werden.

Idee:

Ich hab gelesen das SoupHeader eine Lösung sein könnten. Ich hab mich auch belesen, wie das Funktionieren soll und auch einen Prototypen erstellt.
Doch wie könnte ich das machen, das ich bei Internen IP-Adressen die Authentifizierung (also der SoupHeader) nicht mitgeschickt wird, und somit auch nicht geprüft, und bei Externen es doch getan wird. Zudem müßte ich ja an die IP-Adresse kommen von dem der Request an den WebService gestartet wurde (bzw. die IP-Adresse des Firewalls).
Oder gibt es eine alternative?

Zusammengefasst:

Intern ohne Authentifizierung
Extern mit Authentifizierung

MFG Floyd

"...denn wir arbeiten nicht nur um uns selbst zu verbessern, sondern auch den Rest der Menschheit!"

blog.freakfabrik.net

3.003 Beiträge seit 2006
vor 14 Jahren

Pragmatischste Lösung ist vermutlich, für Intra- und Extranet verschiedene Endpunkte zur Verfügung zu stellen. Bei denen für den externen Zugriff konfigurierst du Message-Security - fertig. Oder wenigstens so gut wie fertig 😉.

LaTino
Oh, übrigens <excrement type="krümel">SOAP</excrement>

EDIT2: hab die Anforderung zum Framework nicht bemerkt...damn. Verschiedene Endpunkte sollte man auch mit ASP-Webservices zur Verfügung stellen können, wenn auch mit mehr Aufwand. Vielleicht gibt's auch bessere Vorschläge.

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

Floyd Themenstarter:in
85 Beiträge seit 2006
vor 14 Jahren

@LaTino .. danke für die schnelle Antwort aber leider verstehe ich nur Bahnhof X(

"...denn wir arbeiten nicht nur um uns selbst zu verbessern, sondern auch den Rest der Menschheit!"

blog.freakfabrik.net

3.003 Beiträge seit 2006
vor 14 Jahren

Google mal nach "ASP webservice soap authentication". Dort gibt es einige Tutorials und Projekte, die zeigen, wie man Clients an ASP-Webservices authentifiziert, indem man Daten in den Header der SOAP-Nachricht schreibt bzw aus ihm liest.

Der Knackpunkt der Unterscheidung zwischen Intern/Extern liesse sich (bei WCF, also .NET 3.0+) lösen, indem man verschiedene Endpunkte konfiguriert. Ich erklärs mal ganz kurz, weil es für .NET 2.0-Webservices (also ASP-Webservices) möglicherweise etwas ähnliches gibt.

Ein Endpunkt ist eigentlich nur die Adresse, unter der ein Service eine Methode veröffentlicht. Man kann für einen Service verschiedene Endpunkte zur Verfügung stellen - verschiedene Adressen, unter denen dieselbe Methode abrufbar ist.

Der Clou an der Sache ist, dass man pro Endpunkt eine völlig andere Konfiguration (bzgl. des Übertragungsprotokolls, der Sicherheit und ähnlichem) festlegen kann. Das heisst: man könnte eine Methode schreiben, diese unter zwei Endpunkten veröffentlichen:

http://www.beispiel.com/Service/Methode
http://www.beispiel.com/Service/Methode/Authenticated

Das Ansprechen beider URIs würde letzten Endes dieselbe Methode aufrufen. Aber man könnte diese Endpunkte so konfigurieren, dass der eine Requests völlig unauthentifiziert annimmt, und der andere die Requests erst auf Berechtigung prüft, eh er eine Antwort erstellt.

Wie gesagt - mit WCF ist so etwas supereinfach und ohne Code lösbar (einfach durch Konfiguration). Ich kann mir vorstellen, dass man auch mit ASP-Webservices so etwas abbilden kann - wenn auch nicht so komfortabel. In jedem Fall wär's aber eine saubere Trennung.

Gruß,

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

Floyd Themenstarter:in
85 Beiträge seit 2006
vor 14 Jahren

Ah ok .. danke für die Erklärung. Das mit dem Soup-Headers hab ich schon gelesen und wie gesagt, sogar nen Prototypen erstellt der damit arbeitet.

Wie ich jedoch gerade sehe gibt es ein Required. Theoretisch könnt ich das ja auch auf False setzen und dann meinen Authentifizierungsmechanismus bauen (Wenn IP = die IP des Firefalls dann Prüfe Authentifierzierung etc.).

[SoapHeader ("Authentication", Required=true)]

Bei den Endpunkte. Hast du mal ne Idee oder ein Stichwort wonach ich suchen könnte?


Abseits, mal ne Frage: Kann ich generierte PDF-Dateien über Webservices übertragen? Also Files bis zu 20MB größe?

"...denn wir arbeiten nicht nur um uns selbst zu verbessern, sondern auch den Rest der Menschheit!"

blog.freakfabrik.net

3.003 Beiträge seit 2006
vor 14 Jahren

Ah ok .. danke für die Erklärung. Das mit dem Soup-Headers hab ich schon gelesen und wie gesagt, sogar nen Prototypen erstellt der damit arbeitet.

Wie ich jedoch gerade sehe gibt es ein Required. Theoretisch könnt ich das ja auch auf False setzen und dann meinen Authentifizierungsmechanismus bauen (Wenn IP = die IP des Firefalls dann Prüfe Authentifierzierung etc.).

Etwas in der Art, ja. (btw, Seife, nicht Suppe g) Vielleicht geht's auch so, dass du prinzipiell eine Authentifizierung machst, und beim authentifizieren auf die IP des Senders achtest, und bei der Firewall-IP direkt "true" lieferst - dann kannst du dir den Kram sparen, interne und externe Requests unterscheiden zu müssen, BEVOR du sie überhaupt anrührst.

Bei den Endpunkte. Hast du mal ne Idee oder ein Stichwort wonach ich suchen könnte?

Ich hab mal bisschen herumgeschaut. Dürfte viel mehr Handarbeit bedeuten, als ich angenommen hatte...wahrscheinlich doch kein praktikabler Weg.

Abseits, mal ne Frage: Kann ich generierte PDF-Dateien über Webservices übertragen? Also Files bis zu 20MB größe?

Abgesehen davon, dass es bereits ein Protokoll zum Übertragen von Dateien gibt, und dass ich grundsätzlich eher dafür bin, die Werkzeuge einzusetzen, die für den jeweiligen Anwendungszweck entworfen wurden - ja, kann man.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

Floyd Themenstarter:in
85 Beiträge seit 2006
vor 14 Jahren

Ok danke, werd noch ein bissel rumspielen .. ist ja eh bald Feierabend und dann erstmal Männertag ...

Vieleicht fällt einem übers Wochenende sogar noch ein alternative ein.

"...denn wir arbeiten nicht nur um uns selbst zu verbessern, sondern auch den Rest der Menschheit!"

blog.freakfabrik.net

S
8.746 Beiträge seit 2005
vor 14 Jahren

Einfach den Service auf zwei Ports anbieten: Einen Port für internen Zugang, der über die Firewall von außen nicht zugänglich ist. Dann noch einen Zugang über einen extern geschalteten, der vom Internet-Proxy vom Standard-HTTP-Port umgeleitet wird.

Für die Tokens:

http://www.code-magazine.com/Article.aspx?quickid=0611051

Ansonsten ist deine Beschreibung etwas unklar. Tokens werden eingesetzt um nicht bei jedem Request wieder und wieder eine (zeitraubende) Authentifizierung durchführen zu müssen. Dazu wird beim ersten Zugriff eine Token erzeugt mit dem dann im weiteren gearbeitet wird. Das nennt sich in WCF "Secure Session":

http://msdn.microsoft.com/en-us/library/ms733783.aspx

Floyd Themenstarter:in
85 Beiträge seit 2006
vor 14 Jahren

Bitte Ignoriert die sache mit den Tokens einfach und denkt euch das Nutzername & Passwort bei jedem Request zur Authentifizierung mitgeschickt werden. Der Begriff Tolen ist vieleicht fallsch gewählt.

Das Problem ist folgendes:

Derzeit haben wir 1 Datenbankserver und 4 Systeme die auf diesen Zugreifen. Diese 4 Systeme sind jedoch Teilweise nicht direkt mit dem Datenbank-Server vebunden sonder nutzen einen propriätären Dienst der in C geschrieben ist. Andere wiederrum greifen direkt auf den Datenbestand zu.

Ziel ist es nun 1. den Dienst durch eine .Net-Lösung abzulösen um die Wartbarkeit und Erweiterbarkeit zu erhöhen. Zum anderen sollen Aufgaben die von alle 4 System gleichermaßen oder in ähnlicher form gebraucht werden, zentral gelößt werden. Zum Beispiel, Datenabfrage, Datenaufbereitung, Datenspeicherung und hin und wieder mal eine PDF-Generierung.
Von den 4 Systemen sind 3 als Vertrauenswürdig anzusehen. Diese 3 brauchen keine extra Authentifizierung. Das 4ter System hingegen ist nicht vollständig vertrauenswürdig da dieses in der DMZ steht. Für letzteres soll also eine Art Benutzername, Passwort Authentifizierung notwendig sein. Also zum Beispiel ein LoginObjekt im SoapHeader. Das LoginObjekt würde aber für die Vertrauenswürdigen Systeme nicht gebraucht da dieses ihre Autorisierung nicht bescheinigen müssen.

Darüber hinaus nützen mir Beiträge zum Thema WCF Security nicht viel da WCF Security ja noch nicht mit 2.0 zur Verfügung steht oder irre ich mich da?

"...denn wir arbeiten nicht nur um uns selbst zu verbessern, sondern auch den Rest der Menschheit!"

blog.freakfabrik.net

2.760 Beiträge seit 2006
vor 14 Jahren

Hmm.. du könntest den Webservice so realisieren dass er gar keine Authentifizierung benötigt und einen Proxy davor bauen (so z.B. http://www.codeproject.com/KB/web-security/HTTPReverseProxy.aspx) Der Proxy oder die Firewall können dann entscheiden ob ein Paket von außen kommt oder nicht und der Proxy führt dann die Authentifizierung durch und nicht der WS.
Erkennt der Proxy das der Request von aussen kommt und die Authentifizierung schlägt fehl gibt er einfach ein 403 zurück.

S
8.746 Beiträge seit 2005
vor 14 Jahren

Darüber hinaus nützen mir Beiträge zum Thema WCF Security nicht viel da WCF Security ja noch nicht mit 2.0 zur Verfügung steht oder irre ich mich da?

Sorry, hatte ich nicht gesehen. Aber mal eine Frage: Wer fährt denn heutzutage noch einen Windows 2000 Server? Schon aus Sicherheitsgründen ist schwer davon abzuraten, gerade bei einem Server der über das Internet erreichbar sein soll. Auf der Client-Seite kann du ja .NET 2.0 mit WSE 3.0 einsetzen.

Bei simpler Username/PW-Anmeldung bietet sich wirklich eine Proxy-Lösung an.

2.760 Beiträge seit 2006
vor 14 Jahren

Wer fährt denn heutzutage noch einen Windows 2000 Server?

Hä? Habe nichts von einem 2000er Server gesehen... korregiere mich wenn ich falsch liege.

Floyd Themenstarter:in
85 Beiträge seit 2006
vor 14 Jahren

Deine Einwände sich berechtigt, jedoch kann ich an der Serverkonfiguration nix ändern und muss mich den gegebenheite anpassen.

"...denn wir arbeiten nicht nur um uns selbst zu verbessern, sondern auch den Rest der Menschheit!"

blog.freakfabrik.net

S
8.746 Beiträge seit 2005
vor 14 Jahren

Wer fährt denn heutzutage noch einen Windows 2000 Server?
Hä? Habe nichts von einem 2000er Server gesehen... korregiere mich wenn ich falsch liege.

.NET 2.0 auf dem Server ist ja gleichbedeutend mit W2K Server, ab 2003 Server geht ja 3.0 aufwärts. Ich finds halt nur sehr ulkig wenn man eine neue Anwendung auf einem nicht mehr unterstützten Betriebssystem mit einem veralteten Framework fährt. Auf dem Client irgendwo verständlich weil man ja mit irgendwelchen Rechner-Altlasten zu kämpfen hat. Der Server wird ja für eine solche Anwendung neu aufgesetzt.

Floyd Themenstarter:in
85 Beiträge seit 2006
vor 14 Jahren

@svenson: Never touch a running System .. ^^

ne ma im Ernst .. der Datenbank-Server und der Applikationsserver sind Windows 2003 Server. Aber es ist .Net 2.0 Installiert und nicht 3.0 oder 3.5. Und da wir leider keine Softwareschmeide sind sondern AdHoc an Produktiven Systemen arbeiten, muss die Server auch weitesgehend Störungsfrei den ganzen Tag laufen. Zwar kann ich mir auf dem VM-Ware-Server eine neue Instanz einrichten und Testen, entwickeln etc. wie ich lustig bin. Aber den Applikationsserver kann ich nicht mal eben neu starten. Ich war schon froh als ich vor 1,5 Jahren unsere Server-Admins davon überzeugen konnte .Net überhaupt auf alle Server mit zu installieren 😄

Edit: Und zuguter letzt ist einer der Dienste, die den WebService entgegen nehmen sollen ein WebServer auf nem Windows 2000 Rechner in der DMZ. Sobald der Chef bissel Geld locker macht wird der zwar ersetzt, jedoch dauert das noch etwas.

"...denn wir arbeiten nicht nur um uns selbst zu verbessern, sondern auch den Rest der Menschheit!"

blog.freakfabrik.net

Z
322 Beiträge seit 2006
vor 14 Jahren

Hallo,

habe mir das ganze hier durchgelesen und dabei hat sich die Frage gestellt, ob eine Authentifizierung über den SOAP unbedingt sein muss?! Ich könnte zB als Parameter ein Authentication-Objekt haben (Username/PW) und sobald der Webservice aufruf mit den 2 Parameter/INputs reinkommt, kann ich diese zB gegen eine DB (Tabelle: Zugangsdaten mit Log oder so) validieren.

Wo liegt der klare Vorteil von SOAP Header Authentifizierung?