-
HINTERGRUND DER ERFINDUNG
-
Die
Erfindung betrifft im Allgemeinen das Gebiet der computerbezogenen
Transaktionen im Bereich des Internet und insbesondere ein Verfahren und
System zur Abwicklung von End-to-End-Geschäftstransaktionen
in einer auf dem Übertragungskontroll-/Internetprotokoll
(TCP/IP) basierenden Umgebung.
-
Bekannte
B2C-(Business-to-Customer) oder B2B-(Business-to-Business) Servicetransaktionen lassen
sich in elektronisch bereitgestellte Services – z. B. Medien-Streaming, Dateiübertragung,
E-Mail, SMS, Spiele usw. – und
solche Services unterteilen, welche die physische Lieferung von
Waren wie im Einzelhandel erfordern. In professionelle Websites oder
Webportale, welche die zuvor erwähnten
Services bereitstellen, muss ein Prozess implementiert sein, der
den Benutzerzugriff auf diejenigen Benutzer beschränkt, die über die
notwendigen Zugriffsberechtigungen verfügen.
-
Ein
bekanntes besonderes Problem in diesem Bereich ist folglich die
Authentifizierung durch Dritte, die nachfolgend vereinfachend als
Benutzerauthentifizierung bezeichnet wird. Da das Internetprotokoll
unter Prozessgesichtspunkten statusunabhängig ist, um die Authentizität eines
Benutzers zu garantieren, der auf eine Website oder ein Webportal zugreift,
für die
bzw. das Zugriffsbeschränkungen gelten,
ist beim Zugriff auf eine andere Website oder ein anderes Portal
bzw. beim erneuten Zugriff auf dieselbe Website oder dasselbe Portal
die wiederholte Ausführung
einer Prozedur zur Benutzerauthentifizierung notwendig.
-
Ein
erster Ansatz zur Inangriffnahme des oben genannten Problems ist
in der europäischen Patentanmeldung
EP 1 039 724 A2 dargelegt.
Darin wird ein System zur Benutzerauthentifizierung mit Hilfe der
IP-Adresse des Benutzers, die dem Computer eines Benutzers von einem
DHCP-Server (Dynamic Host Configuration Protocol) zugewiesen wird, beschrieben.
Dadurch wird das Datenpaar aus Benutzer und IP-Adresse zur Benutzerauthentifizierung seitens
eines Authentifizierungsservers verwendet. Nachdem dieser Server
die Autorisierung des Benutzers erkannt hat, wird das erwähnte Datenpaar
auf einem LDAP-Server (Lightweight Directory Access Protocol) gespeichert.
Die gespeicherten Informationen können dann zur Authentifizierung
des Benutzers für
Anwendungen verwendet werden, die auf anderen Computern ausgeführt werden.
-
Als
einen anderen Ansatz legt die PCT-Anmeldung
WO 113 598 A2 zur Benutzerauthentifizierung
ein Schema für
die dynamische, drahtlose Zuweisung von Internetadressen dar. Einem
Benutzer einer mobilen Kommunikationseinheit, die über ein OBS-Netz
(Optical Burst Switch) kommuniziert, wird eine eindeutige IP-Adresse
zugewiesen. Der OBS enthält
insbesondere eine Master-Autorisierungsinstanz
für die
Ticketvergabe, die eine Datenbank mit eindeutigen IP-Adressen verwaltet,
die den auf das Netz zugreifenden Benutzern zugewiesen werden können. Der
OBS enthält
ferner ein Gateway, eine Master-Routingdatenbank und mindestens
eine mobile Kommunikationseinheit, die mit einem OBS in Kontakt
steht. Nach diesem Ansatz erfolgt die Authentifizierung von Benutzern
im Netz durch die Übertragung
verschlüsselter
Zufallszahlen zwischen einer Benutzerauthentifizierungs-Site und
einer mobilen Kommunikationseinheit.
-
Die
oben erörterten
Ansätze
nach dem Stand der Technik umfassen oder erfordern eine ziemlich komplexe
und teure Technologie für
die Abwicklung der thematisierten End-to-End-Geschäftstransaktionen zwischen einem
Benutzer und einer oder mehreren Internet-Vertriebseinheiten (Produkt
usw.) und/oder einem oder mehreren Serviceanbietern, wobei die Geschäftstransaktion
unbedingt die Berechtigung des Benutzers zum Zugriff auf die Websites
oder Portale erfordert.
-
Hinzu
kommt, dass das oben erwähnte DHCP-Protokoll
es nicht zulässt,
das Ende oder die Beendigung einer bestehenden Onlinesitzung eines Benutzers
zu bestimmen. Da eine IP-Adresse dynamisch zugeordnet wird, kann
eine dritte Person eine bereits zugeordnete IP-Adresse prinzipiell
missbrauchen, da die IP-Adresse auf dem LDAP-Server noch auf den
Namen des vorherigen Benutzers registriert ist. Insofern kann dieser
bestehende Ansatz nicht als sicher erachtet werden.
-
Außerdem bieten
die bekannten Ansätze, wie
bereits erwähnt,
keine technisch vereinfachte Plattform für die Servicebereitstellung
und Bezahlung in einer IP-Umgebung des Internet. Hinzu kommt, dass
die Problematik der Abrechnung über
das Internet im Allgemeinen zurzeit noch nicht gelöst ist.
Es gibt ferner kein Netz, das auf den derzeit verfügbaren Funktionen
zur Authentifizierung und Zugriffssteuerung basiert. Heute muss
jeder Serviceanbieter seine eigene anwendungsspezifische Lösung installieren.
-
Das
US-Patent 5,845,070 legt
Sicherheitsmaßnahmen
gegen die Offenlegung von vertraulichen Informationen dar, die für den Erwerb
von Gütern
und Services über
eine Internetsite benötigt
werden. Die vertraulichen Informationen werden in eine Datenbank
aufgenommen, die Teil eines Verfolgungs- und Authentifizierungsmoduls
ist. Die vertraulichen Informationen werden mit einer weiteren Datenmenge
verknüpft,
die eine für
den Benutzer zu konfigurierende eingerahmte IP-Adresse (Framed IP Address)
enthält,
die ausschließlich
zur Verwendung während
jedes Anmelde- und Abmeldevorgangs ausgegeben wird. Mit dieser weiteren
Datenmenge wird eine Abfrage des Verfolgungs- und Authentifizierungsmoduls
gestartet, um die Kreditwürdigkeit
des Benutzers zu prüfen.
-
ÜBERBLICK ÜBER DIE ERFINDUNG
-
Es
ist deshalb eine Aufgabe der vorliegenden Erfindung, ein Verfahren
und ein System zur Abwicklung der zuvor erörterten End-to-End-Geschäftstransaktionen
bereitzustellen – d.
h. zur Abwicklung von Transaktionen zwischen einem Benutzer und
einer Vertriebseinheit oder einem Serviceanbieter gemäß der obigen
Definition, aber beispielsweise nicht zur Abwicklung von Transaktionen
zwischen einem Benutzer und einem Internet-Service-Provider (ISP) – die eine
sichere Methode vor allem in Bezug auf die Bestimmung und/oder Anerkennung
der Authentizität beider
an der Transaktion beteiligten Personen darstellen, und welche die
Ausführung
dieser Geschäftstransaktionen
mit minimalem technischen und finanziellen Aufwand ermöglichen.
-
Die
oben genannten Aufgaben werden durch die Merkmale der unabhängigen Ansprüche erfüllt, die
sich auf einen Sitzungskontext und einen Vertriebseinheitskontext
beziehen. Vorteilhafte Ausführungsarten
sind Gegenstand der Unteransprüche.
-
Das
der Erfindung zugrunde liegende Konzept ist die Bereitstellung einer
vorzugsweise als Middleware implementierten und zwischen einer IP-Schicht
und einer Serverschicht in dem bekannten OSI-Referenzmodell für die Kommunikation
offener Systeme (Open Systems Interconnection) angeordneten Verwaltungs- oder Serverinstanz,
die eine einmalige und eindeutige Benutzer- oder Teilnehmeranmeldung – nachfolgend
als „einmalige
Anmeldung" (Single
Sign-on, SSO) bezeichnet – ermöglicht und einen
Pool von IP-Adressen bereitstellt, die für die Zuordnung zu diesen Benutzern
verfügbar
sind. Mit der Bestätigung
der Benutzeranmeldung ordnet die Serverinstanz eine IP-Adresse aus
dem Pool zu, und zwischen der Serverinstanz und dem Computer oder der
Telekommunikationseinheit des Benutzers wird eine dauerhafte IP-basierte
Punkt-zu-Punkt-Verbindung (PPP) hergestellt. Gleichzeitig wird die IP-Adresse
des Benutzers zusammen mit allen für die Abrechnung, Authentifizierung
und Autorisierung (AAA) relevanten Attributen aufgezeichnet oder
gespeichert. Des Weiteren wird der Netzzugriff des Benutzers kontinuierlich überwacht,
und es wird ermittelt, ob die Onlinesitzung beendet wird. Ist dies
der Fall, wird die dem Benutzer zugeordnete IP-Adresse inaktiviert
und in den Pool von IP-Adressen zurückgestellt.
-
In
einer bevorzugten Ausführungsart
wird eine dauerhafte IP-Tunnelverbindung (Verbindung über ein
virtuelles privates Netz) zwischen der Serverinstanz und dem Computer
oder der Telekommunikationseinheit eines Benutzers hergestellt,
wobei das Bereitstellen eines sehr zuverlässigen Mechanismus, mit dem
sich die von einem Benutzer vorgenommene Beendigung einer Onlinesitzung
erkennen lässt,
folglich auf sichere Weise die oben erwähnte Situation verhindert,
in der ein erhöhtes
Potenzial für den
Missbrauch oder unsachgemäßen Gebrauch
einer bereits zugewiesenen IP-Adresse besteht. Es gilt zu betonen,
dass die Zuverlässigkeit
dieses Mechanismus hauptsächlich
durch die Kombination aus dauerhafter IP-Verbindung und direkter Überwachung
des Benutzerverhaltens hinsichtlich des Netzzugriffs erreicht wird.
-
Gemäß einem
Aspekt der Erfindung dient die aktuelle IP-Adresse des Benutzers
während
der folgenden Onlinesitzung als Autorisierungstoken. Dann können die
gespeicherten Informationen von der Serverinstanz einer E-Company
zur Verfügung
gestellt werden, für
die der betreffende Benutzer/Teilnehmer eine gültige Teilnehmerberechtigung
besitzt, und Standardprotokolle für IP-Anwendungen zur Authentifizierung,
Autorisierung und Abrechnung können zwischen
der E-Company und jedem E-Service-Anbieter angewendet werden, mit dem
der Benutzer/Teilnehmer E-Commerce-Geschäfte beliebiger Art abwickeln
möchte.
-
Gemäß einem
anderen Aspekt wird mindestens die dem Benutzer zugeordnete IP-Adresse
zusammen mit mindestens einem Attribut kontinuierlich aufgezeichnet
oder gespeichert, das für
die Abrechnung und/oder Authentifizierung und/oder Autorisierung
relevant ist. Ein Beispiel für
ein solches Attribut ist die Telefonnummer des Benutzers.
-
Gemäß einem
anderen Aspekt hat die Serverinstanz (Middleware) im Hinblick auf
den begrenzten Pool verfügbarer
IP-Adressen und die Rolle der Serverinstanz bei der Zuweisung einer
IP-Adresse zu einem angemeldeten Benutzer die vollständige Kontrolle über den
Prozess der IP-Adresszuweisung, und die IP-Adresse fungiert gemäß der Erfindung
somit als eindeutige Benutzer-ID, die für weitere Authentifizierungsprozeduren
verwendet werden kann, die während
der folgenden Onlinesitzung von dem Benutzer einzuleiten sind.
-
Gemäß dem vorgeschlagenen
Authentifizierungsprozess wird während
der Authentifizierungsprozedur zur einmaligen Anmeldung, die im
Netz des entsprechenden zugrunde liegenden Netz-Serviceanbieters
des Benutzers bzw. Teilnehmers ausgeführt wird, dem Benutzer/Teilnehmer
eine IP-Adresse zugewiesen. Es wird hiermit betont, dass die Zuweisung
oder Zuordnung der IP-Adresse aus dem Pool verfügbarer IP-Adressen ein notwendiger
Teil der vorgeschlagenen Funktionalität der Serverinstanz bzw. Middleware
ist. Die vorgeschlagene Prozedur unterstützt somit die Zuweisung sowohl
von dynamischen als auch von statischen IP-Adressen.
-
Die
Korrelation zwischen dem Authentifizierungsnamen eines Benutzers
und der diesem Namen zugewiesenen vorhandenen IP-Adresse sowie die
Erfassung der Gültigkeit
dieser Korrelation wird ausschließlich von der oben erwähnten Serverinstanz
(Middleware) mit Hilfe eines Sitzungskontextes vorgenommen. Jeder
Identifikationsprozess für
einen Benutzer/Teilnehmer, der alle von einem E-Service-Anbieter
angebotenen Services in Anspruch nehmen möchte, wird allein anhand der
zugewiesenen IP-Adresse eingeleitet. Infolgedessen darf die wahre
Identität,
die z. B. durch den Benutzernamen oder andere benutzerspezifische
Informationen angegeben wird, notwendigerweise nicht den oben erwähnten E-Service-Anbietern
mitgeteilt werden. Wenn für
angeforderte Services und/oder Waren bestimmte Benutzerattribute
zusätzlich
erforderlich sind, können
diese jedoch ausnahmsweise den E-Service-Anbietern von der Middleware
zur Verfügung
gestellt werden. Hierfür
wird nur die IP-Adresse benötigt,
die dem Benutzer/Teilnehmer zum Zeitpunkt der Bereitstellung dieser
zusätzlichen
Informationen zugewiesen wurde.
-
In
einer bevorzugten Ausführungsart
umfasst oder enthält
der Sitzungskontext vom Benutzer ausgelöste Transaktionsereignisse,
insbesondere Abrechnungsstarts oder dergleichen, damit die Authentizität des Benutzers
während
einer kompletten Onlinesitzung kontinuierlich gültig bleibt, und damit die
vorhandene Autorisierung von den benutzerbezogenen End-to-End-Geschäftstransaktionen,
wie z. B. den von E-Service-Anbietern auf Websites oder in Internetportalen
angebotenen Video-on-Demand-Services,
genutzt werden kann.
-
Der
vorgeschlagene Mechanismus ermöglicht
einem Benutzer folglich während
einer unterbrechungsfreien Onlinesitzung auf vorteilhafte Weise den
Zugang zu unterschiedlichen kommerziellen Websites oder Portalen
im Internet, um verschiedene der oben erwähnten B2C-Transaktionen auszuführen. Zur
Abwicklung dieser Transaktionen braucht der Benutzer nicht immer
wieder aufs Neue weitere Anmeldeprozeduren seitens der E-Service-Anbieter durchzuführen, da
die Serverinstanz ein vorhandenes Maß für die Authentizität des Benutzers
beibehält.
Darüber
hinaus werden AAA-Prozeduren nur von einer Instanz abgewickelt,
bei der es sich um die erfindungsgemäße Serverinstanz handelt. Die
Erfindung stellt somit unabhängig
von der Technologie und dem Verfahren für den Zugriff auf die IP-Services eine
allgemeine Lösung
für das
Problem der zuverlässigen
Authentifizierung, Autorisierung und Abrechnung dar.
-
Wenn
sich der Benutzer abmeldet (ausloggt) oder die zur Serverinstanz
bestehende Verbindung auf irgendeine Weise getrennt wird, beendet
die Serverinstanz den Sitzungskontext des Benutzers, wodurch die
aktuell anhängige
Benutzersitzung geschlossen wird. Daraufhin werden alle bereitgestellten
Services gestoppt, und bis zur erneuten Anmeldung des Benutzers
wird keine Autorisierung erteilt. Jeder darüber hinaus anhängige Vertriebseinheitskontext
bleibt jedoch unabhängig
von dem beendeten Sitzungskontext bestehen. Die in der Datenbank enthaltenen
Informationen dienen zur Herstellung der Verbindung zwischen bereitzustellenden
und abzurechnenden Services und dem Konto des Benutzers oder Teilnehmers.
Auch die Abrechnungsinformationen stehen für jede mit dem Service- oder
Zugangsanbieter verknüpfte
Fakturierungsanwendung zur Verfügung.
Der vorgeschlagene Sitzungskontext löst daher auch das oben erwähnte Problem
der Statusunabhängigkeit
von TCP/IP.
-
Es
ist anzumerken, dass die Kombination aus einfacher Registrierung
(SSO) und Verarbeitung einer IP-Adresse eines Benutzers zur Schaffung
eines ununterbrochenen Sitzungskontextes, der während der folgenden Benutzersitzung
dauerhaft aufrechterhalten wird, die Authentizität des Benutzers über die
gesamte unterbrechungsfreie Onlinesitzung garantiert, so dass die
Ausführung
weiterer Anmeldeprozeduren seitens jeder Vertriebseinheit und/oder jedes
Serviceanbieters, die bzw. der während
der Sitzung angesteuert wird, auf vorteilhafte Weise vermieden wird.
-
Mit
anderen Worten wird die IP-Adresse von der Erfindung als ein Schlüsselinstrument
der vorgeschlagenen Serverinstanz verwendet, da die IP-Adresse die
einzige Information ist, die jede Serviceinstanz in jeder der zwei
Gruppen (virtuell/real) zur Entscheidung über eine Autorisierungsanfrage
gegenüber
der Serverinstanz benötigt.
Dies ist die Basis für
eine sichere Rechnungsstellung oder Bezahlung sowie für die Bereitstellung
und Inanspruchnahme von Servicequalität. Ein weiterer Vorteil dieser Technologie
ist, dass der Client in jeder Serviceschicht anonym bleibt. Potenziell
kann jede durch eine IP-Adresse dargestellte reale Einheit zu einem Leistungsempfänger werden,
auf den die Fakturierung angewendet werden muss.
-
Der
vorgeschlagene Prozess ermöglicht trotz
der zuvor erwähnten
Statusunabhängigkeit
des TCP/IP-Protokolls die sichere Abwicklung der oben erwähnten Transaktionen
und bewahrt somit aufgrund der mit dem Sitzungskontext in Beziehung
stehenden Zugriffssteuerung, die auf der eindeutigen IP-Adresse
basiert, die Vertriebseinheit und/oder die Serviceanbieter effektiv
vor dem unbefugten Zugriff durch andere, d. h. vor nicht autorisierten
Zugriffen auf Websites oder Internetportale, für die Zugriffsbeschränkungen
gelten. Die zwischen aufeinander folgenden Sitzungen sich zufällig ändernde
IP-Adresse garantiert die Behandlung von Zugriffsberechtigungen
mit maximaler Sicherheit. Die Erfindung schützt somit Vertriebseinheiten
und/oder Serviceanbieter mit minimalem Sicherheitsaufwand effektiv
vor illegalen Manipulationen durch nicht berechtigte Benutzer. Es
ist ferner anzumerken, dass der Sitzungskontext wegen seines Zufallscharakters
von einem Eindringling nicht simuliert werden kann. Hinzu kommt,
dass die Bereitstellung und Bezahlung in einem beliebigen denkbaren
Szenario erfolgt, in dem das Internetübertragungsprotokoll TCP/IP
als grundlegendes Transportschema für die Integration von E-Companies dient.
Demzufolge sind keine zusätzlichen
Informationen zu übertragen,
damit der Benutzer während
der Sitzung weitere Anmeldeprozeduren durchführen kann.
-
Die
Erfindung lässt
sich in globalem Maßstab auf
Computernetze anwenden. Einzige Voraussetzung ist, dass die Benutzer über ein
gewisses Maß an
IP-Konnektivität
verfügen.
Die vorgeschlagene Serverinstanz kann gemäß einem ersten Aspekt Teil eines
globalen Netzes wie dem globalen Netz von IBM oder Teil jedes anderen
Netzes für
Nachrichtenübertragungsservices
(Messaging Service Network, MSN) sein. Hieraus würde ein Geschäftsmodell
resultieren, das nur einen Akteur als Zahlungsvermittler umfasst,
der einerseits jede Geschäftstransaktion zwischen
Kunden und Serviceanbietern kontrolliert und andererseits seine
eigenen Services seinen Benutzern/Teilnehmern direkt verkauft und
in Rechnung stellt.
-
Als
Alternative kann die Serverinstanz von einem großen Netzbetreiber, z. B. einem
gemeinsamen Anwendungs-Service-Provider
(ASP) oder einem Telekommunikationsunternehmen, bereitgestellt werden,
der bzw. das einer beliebigen Anzahl von E-Companies Hosting-Services
bereitstellt. In diesem Fall wird die Zahlungsvermittlung entweder von
diesem Unternehmen angeboten oder von einer beliebigen E-Company,
der Services per Hosting bereitgestellt werden, oder von beiden.
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
Die
Erfindung wird nachfolgend anhand einer bevorzugten Ausführungsart
beschrieben. Dabei wird auf die beiliegenden Zeichnungen Bezug genommen.
Darin zeigen:
-
1 ein Übersichtsblockdiagramm,
dass eine typische B2C-Serviceumgebung im Internet gemäß der Erfindung
veranschaulicht;
-
2 die
Grundprinzipien für
die Zuweisung von IP-Adressen im Internet gemäß dem Stand der Technik;
-
3 den
Prozessfluss einer bevorzugten Ausführungsart der Erfindung anhand
eines Flussdiagramms;
-
4 das
aus dem Stand der Technik bekannte RADIUS-Protokoll für die Bereitstellung
der Authentifizierung, der Autorisierung und der Konfiguration von
Informationen zwischen einem Netzzugriffsserver (Network Access
Server, NAS) und einem gemeinsam genutzten Authentifizierungsserver;
-
5 ein
schematisches Blockdiagramm zur Veranschaulichung einer Vermittlungsschichtstruktur,
die eine erfindungsgemäße Middleware
enthält;
-
6 die
Interoperation der vorgeschlagenen Middleware mit einer Reihe von
E-Companies und
-
7 mögliche Integrationsprofile
für die Hauptkomponenten
der in 5 dargestellten Vermittlungsschichtstruktur.
-
DETAILLIERTE BESCHREIBUNG
DER BEVORZUGTEN AUSFÜHRUNGSART
-
Die
in 1 exemplarisch dargestellte B2C-Umgebung veranschaulicht
die grundlegenden Prinzipien der Erfindung mit Hilfe einer typischen B2C-Internetumgebung,
die zwei mit dem Internet 104 verbundene, exemplarische
(Internet-) E-Service-Anbieter 100, 102 enthält (nachfolgend
als „Vertriebseinheit
oder Serviceanbieter" bezeichnet),
die für
eine Anzahl anderer potenzieller Vertriebseinheiten/Serviceanbieter
stehen, die hier nicht dargestellt sind. Die dargestellte Netzumgebung
ermöglicht
einem Benutzer, Geschäftstransaktionen
von einem Benutzercomputer 106 (PC oder Workstation) mit diesen
E-Service-Anbietern 100, 102 auszuführen. Die
B2C-Umgebung enthält
insbesondere eine so genannte „E-Company" 108, die
eine Serverinstanz 110 zur Abwicklung dieser End-to-End-Geschäftstransaktionen
zwischen dem Benutzer und der Anzahl von Vertriebseinheiten oder
Serviceanbietern 100, 102 anbietet. Die Serverinstanz 110 wird
gemäß der vorliegenden
Ausführungsart
durch eine dedizierte Middleware implementiert, die zwischen einer IP-Schicht
und einer Serverschicht (OSI-Modell) angeordnet ist, wie später ausführlicher
erörtert
wird.
-
Der
Benutzercomputer 106 greift über einen E-Network-Betreiber 112 (=
Internetzugangsanbieter) auf das Internet 104 zu, wobei
die Verbindung zwischen dem Computer 106 und dem E-Network-Betreiber 112 gemäß der vorliegenden
Ausführungsart
auf einer gewöhnlichen
Telefonverbindung über
das analoge Telefonnetz (Plain Old Telephone Service, POTS) 114,
einem dienstintegrierenden digitalen Fernmeldenetz (Integrated Services
Digital Network, ISDN) oder dergleichen basiert.
-
Während einer
ersten Anmeldung des Benutzers beim E-Network-Betreiber 112 wird ein Kommunikationskanal 116 zu
einem Netzzugriffsserver (NAS) 118 des E-Network-Betreibers 112 eingerichtet.
Der NAS 118 ist mit einer Datenbank 120 verbunden.
Die Datenbank 120 speichert insbesondere Benutzerinformationen
der Kunden des E-Network-Betreibers 112 und kann folglich
während
der Anmeldung des Benutzers eine Prozedur zur Benutzerauthentifizierung
ausführen.
Der E-Network-Betreiber 112 verwaltet ferner einen Bestand
(Pool) an verfügbaren
IP-Adressen A, B, C, D usw. Nach der erfolgreichen Anmeldung des
Benutzers wird dem Benutzer eine dieser IP-Adressen, im diesem Beispiel die
Adresse „A", zugewiesen.
-
Es
wird nun davon ausgegangen, dass der Benutzer bei dem E-Network-Betreiber 112 über eine spezielle
Teilnehmerberechtigung verfügt,
um End-to-End-Geschäftstransaktionen
oder sogar private End-to-End-Transaktionen
mit anderen Internetbenutzern über
die Serverinstanz 110 der Erfindung abzuwickeln. In diesem
Fall stellt der Anbieter 108 der Serverinstanz (Middleware) 110 dem
Benutzercomputer 106 im Voraus ein für diese Transaktionen verwendbares
Wählprogramm
für ein
virtuelles privates Netz (VPN) bereit. Das VPN-Wählprogramm ermöglicht den
Aufbau einer Verbindung zum virtuellen privaten Netz in Form einer
Punkt-zu-Punkt-Verbindung
(PPP) zwischen dem Benutzercomputer 106 und der Serverinstanz 110.
Dadurch wird dem Benutzer seitens der Serverinstanz 110 eine
andere IP-Adresse aus dem Pool vorhandener verfügbarer IP-Adressen zugewiesen.
Die anhängige
VPN-Verbindung, die auf der neuen IP-Adresse „b" basiert, wird insbesondere als IP-Tunnelverbindung 122 zwischen
dem Benutzercomputer 106 und der Serverinstanz 110 implementiert,
was in 1 durch die gestrichelte Linie angezeigt wird.
-
Bei
einem VPN handelt es sich nach dem Stand der Technik um eine Gruppe
von zwei oder mehr Computersystemen, die üblicherweise mit einem privaten
Netz (ein von einer Organisation ausschließlich zur Eigennutzung eingerichtetes
und verwaltetes Netz) verbunden sind, das eingeschränkten Zugriff
auf öffentliche
Netze hat, und die „sicher" über ein öffentliches Netz kommunizieren.
VPNs können zwischen
einer einzelnen Maschine und einem privaten Netz (Client-Server-Verbindung)
oder zwischen einem Remote-LAN und einem privaten Netz (Server-Server-Verbindung)
bestehen. Die Sicherheitsmerkmale unterscheiden sich von Vertriebseinheit (Produkt)
zu Vertriebseinheit, aber die meisten Sicherheitsexperten stimmen
darin überein,
dass VPNs Folgendes beinhalten: Verschlüsselung, leistungsfähige Authentifizierung
von remote angebundenen Benutzern oder Hosts sowie Mechanismen zum
Maskieren oder Verbergen von Informationen zur Topologie des privaten
Netzes vor potenziellen Angreifern im öffentlichen Netz.
-
Die
Prinzipien der in 1 dargestellten Ausführungsart
lassen sich dahingehend zusammenfassen, dass die oben beschriebene
Serverinstanz 110 die einmalige Anmeldung für die Benutzerauthentifizierung
erforderlich macht und gewährleistet.
Bei der Anmeldung eines Benutzers wird ein Sitzungskontext 124 zwischen
der dem Benutzer aktuell zugewiesenen IP-Adresse und seinem Konto
erstellt. Während
der Lebensdauer des Sitzungskontextes 124 wird jede Transaktion
mit einem beliebigen E-Service-Anbieter 100, 102 mit
Hilfe der vorgeschlagenen Serverinstanz 110 autorisiert.
Für die
Autorisierung eines beliebigen E-Services 100, 102 gegenüber der
Serverinstanz 110 ist lediglich die IP-Adresse des Clients
erforderlich, die als solche das grundlegendste Attribut im Internet 104 ist.
-
Genauer
gesagt würde
ein E-Service-Anbieter 100, 102, wie z. B. ein
Internet-Shop, der wie hierin vorgeschlagen integriert ist, einfach
nur die IP-Adresse des Benutzers verwenden müssen, um den Benutzer mit Hilfe
eines Abfrageservices zu authentifizieren, welcher zur Architektur
der vorgeschlagenen Serverinstanz 110 gehört. Der
Benutzer kann seinerseits für
den E-Service-Anbieter 100, 102 nur einen Aliasnamen
verwenden. Die Serverinstanz 110 wiederum verfolgt alle
Abrechnungsereignisse beispielsweise in Bezug auf die Service-ID,
die Anzahl und den Preis. Dies ermöglicht zusätzlich die Vorfakturierung
und die Überwachung
von Prepaid-Konten und/oder Kundenkreditkonten hinsichtlich der
für die Zahlung
von Kleinbeträgen
geltenden Fakturierungsanforderungen. Die Abrechnungsdatensätze können folglich
an eine Nachfakturierungsinstanz weitergeleitet werden. Diese Nachfakturierungsinstanz
bildet eine Schnittstelle mit einer Instanz, die Preisstrukturen
verwaltet.
-
Die
vorgeschlagene Serverinstanz (Middleware) 110 unterstützt eine
beliebige Anzahl von E-Companies, für die folgende Definition gilt:
Sie bieten entweder einen einzigen Service oder eine Vielzahl unterschiedlicher
Services entweder selbst oder im Rahmen von Partnerschaftsvereinbarungen
mit anderen an. Die Schlüsselanforderung
besteht darin, dass diese Unternehmen vertragliche Beziehungen zu
ihren Teilnehmern pflegen und verwalten, deren Daten in einem Kundenverwaltungs-
oder sogar in einem Selbstverwaltungssystem aufbewahrt werden. Die
darin verwalteten Benutzerattribute für jedes Benutzerkonto und -unterkonto
lassen sich wie folgt gruppieren: Für die Authentifizierung und
die Autorisierung des Benutzerkontos relevante Attribute wie Benutzer-ID,
Kontonummer, Kennwort, Aliasname des Benutzers usw., ausführliche
Angaben zur Benutzeradresse wie vollständige Adressinformationen, Passnummer
usw., Attribute mit einem Bezug zu generischen Inhalten wie Filter,
Benutzervorlieben usw., Attribute mit einem Bezug zur Zahlungsweise
wie die Angabe, von welchem Bankkonto die Zahlung von Kleinbeträgen oder
anderen Beträgen
erfolgen soll. Des Weiteren wird in einer Umgebung für reale
Waren die Rechnungsstellung ausgelöst, nachdem die Lieferung an
den Kunden erfolgt ist und von diesem bestätigt wurde. Dies wird durch
die Einführung
von Workflowkomponenten erreicht, die Technologien für den mobilen
Zugriff sowie Paketdienste umfassen. Auch hier gelten wieder die
bereits definierten Regeln für
die reale Welt.
-
Darüber hinaus
ist anzumerken, dass die Serverinstanz 110 wegen der IP-Tunnelverbindung 122 überall im
Internet 104 physisch angeordnet sein kann, wobei sie vorzugsweise
innerhalb der Firewalls eines Intranet des E-Network-Betreibers 112 oder der
E-Company 108 angeordnet ist, wenn es sich bei der E-Company 108 um
ein von dem E-Network-Betreiber 112 unabhängiges Unternehmen
handelt. Des Weiteren verwendet die Serverinstanz 110 gemäß der bevorzugten
Ausführungsart
ein von einem dedizierten RADIUS-Server 126 bereitgestelltes
RADIUS-Protokoll (Remote Authentication Dial In User Service), das
nachfolgend noch erörtert
wird.
-
Es
gilt zu betonen, dass es in Fällen,
in denen der E-Network-Betreiber 112 auch
die oben beschriebenen, auf einer Serverinstanz 110 gemäß der Erfindung
basierenden E-Company-Services 108 bereitstellt,
d. h. die Serverinstanz 110 beibehält, nicht notwendig ist, die
oben erwähnten
zwei IP-Adressen bei der Anmeldung des Benutzers zuzuweisen, da der
Middleware-Anbieter die IP-Adresse anschließend zu Authentifizierungszwecken
zuweist.
-
In 2 sind
grundlegende Aspekte der nach dem Stand der Technik erfolgenden
Zuweisung von IP-Adressen veranschaulicht. 2 zeigt
ein Beispiel für
zwei mögliche
Verbindungsszenarios, in denen die Serverinstanz (Middleware) 200 zur
Anwendung kommt. Ein erster Computer 202 hat über den
zu einem ersten E-Network-Betreiber 206 gehörenden NAS-1 204 Zugriff
auf das Internet 203. Der erste E-Network-Betreiber 206 verwendet
die Middleware 200 weder zum Authentifizieren von Benutzern noch
zum Zuweisen von IP-Adressen. Der erste E-Network-Betreiber 206 verfügt über einen
eigenen Pool von IP-Adressen (z. B. 152.140.1.1/0), die der Middleware 200 nicht
bekannt sind. Auf dem ersten Computer 202 wird ein Tunnelclient
ausgeführt,
der eine Tunnelverbindung 208 zu der Middleware 200 herstellt,
sodass er sich selbst authentifizieren und eine „Middleware-IP-Adresse" (193.123.4.12) erhalten
kann. Wie oben und nachfolgend noch ausführlicher beschrieben, erstellt
die Middleware 200 einen Sitzungskontext für den ersten
Computer 202 und verwaltet diesen Sitzungskontext bis zur
Abmeldung des Benutzers. Mit dieser IP-Adresse kann der erste Computer 202 alle
von der Middleware 200 bereitgestellten Funktionen, z.
B. einmalige Anmeldung, nutzen.
-
Ein
zweiter Computer 210 hat über den zu einem zweiten E-Network-Betreiber 214 gehörenden NAS-2 212 ebenfalls
Zugriff auf das Internet 203 und verwendet die Middleware 200 zur
Authentifizierung und zur Zuweisung von IP-Adressen. Der zweite E-Network-Betreiber 214 verwendet
ebenfalls einen eigenen Pool von IP-Adressen (193.123.5.1/0), die im
Gegensatz zum ersten E-Network-Betreiber 206 der Middleware 200 bekannt
sind und von dieser verarbeitet werden. Da der über den NAS-2 212 erfolgende
Zugriff des zweiten Computers 210 auf das Internet von
der Middleware 200 gesteuert wird, ist in diesem Fall keine
Tunnelverbindung zum Generieren/Verwalten des notwendigen Sitzungskontextes erforderlich.
-
Wie
in dem in 1 dargestellten B2C-Szenario
können
beide Computer 202, 210 Geschäftstransaktionen mit E-Companies 216 und/oder
E-Service-Anbietern 218, 220 mit Hilfe der Middleware 200 abwickeln,
ohne dass es dabei von Belang ist, ob sie ihre „Middleware-IP-Adresse" über einen NAS oder, wie zuvor
beschrieben, über
einen Tunnelclient erhalten haben.
-
In 3 wird
eine bevorzugte Ausführungsart
des Transaktionsprozesses gemäß der Erfindung anhand
eines Prozessflussdiagramms veranschaulicht. 3 stellt
außerdem
die Grundprinzipien für die
Erstellung eines Sitzungskontextes in einem IP-Netz dar und zeigt,
wie Services bereitgestellt und alle relevanten Abrechnungsinformationen
und Fakturierungsparameter basierend auf dedizierten Servicemerkmalen
erfasst werden. In dem Diagramm stellt die y-Richtung von oben nach
unten die Zeit t dar, und die beiden vertikalen Linien 300, 302,
die in x-Richtung angeordnet sind, stellen verschiedene Transaktionskontexte
dar – in
diesem Beispiel insbesondere den zuvor beschriebenen Sitzungskontext und
zusätzlich
einen Vertriebseinheitskontext (Referenznummer 128 in 1).
-
Der
Prozess beginnt mit einer vom Benutzer eingeleiteten Anmeldeprozedur
(Schritt „a"), welche die zuvor
beschriebene Benutzerauthentifizierung einschließt. Eine IP-Adresse wird zugewiesen
und ein Sitzungskontext wird mit Hilfe des oben erwähnten RADIUS-Protokolls
erstellt. Ein Sitzungskontext zeichnet u. a. folgende im RADIUS-Protokoll
enthaltene Informationen auf: Benutzername, für den Benutzer zu konfigurierende
eingerahmte IP-Adresse (Framed IP Address) und Klasse, ID- der Abrechnungssitzung.
Der Sitzungskontext läuft
ab, wenn der Benutzer sich abmeldet (ausloggt), oder die Verbindung
getrennt wird.
-
Andere
Transaktionsereignisse, die vom Benutzer oder einem in eine Geschäftstransaktion
involvierten E-Service-Anbieter ausgelöst wurden, können prinzipiell
nur während
eines anhängigen
Sitzungskontextes eintreten, wobei der Sitzungskontext bestätigt wird
(Schritt „b"). In dem Augenblick,
in dem ein Benutzer eine Vertriebseinheit bestellt, wird eine Autorisierungsanfrage
(Schritt „c") an die Serverinstanz (Referenznummer 110 in 1)
gesendet. Die Middleware prüft
die vom Benutzer ausgegangene Anforderung der Vertriebseinheit und
legt fest, dass der Benutzer für
diese Kosten aufzukommen hat. Daraufhin wird ein so genannter Vertriebseinheitskontext
generiert (Schritt „c"). In diesem Beispiel
fordert der Benutzer einen Video-on-Demand-Service vom E-Service-Anbieter
an. Nach der erfolgreichen Autorisierung des Benutzers (Schritt „c") wird der Start des
angeforderten Video-on-Demand-Services (VoD-Services) (Schritt „d") zusammen mit einer
Abrechnungsnachricht (Acct-Start) angezeigt. Wenn der VoD-Service
erbracht wurde, z. B. nach dem Herunterladen oder Streaming der
kompletten Videodatei, wird eine Abrechnungsnachricht (Acct-Stop)
generiert, um die notwendige Fakturierung für das heruntergeladene Video
durchzuführen.
Der anhängige Vertriebseinheitskontext
wird daraufhin gelöscht (Schritt „f").
-
Wenn
sich der Benutzer abmeldet, wird der aufgezeichnete Sitzungskontext
gelöscht,
und die Zuordnung der anhängigen
IP-Adresse aufgehoben. Darüber
hinaus wird ein Abrechnungs-Stoppereignis ausgelöst (Schritt „g").
-
Jedes
besondere Serviceereignis wie das Zurückspulen, Anhalten/Fortsetzen
oder Vorspulen des Videos während
des Streamingprozesses löst eine
Abrechnungsnachricht (Acct-Intermediate)
aus.
-
Der
beschriebene Sitzungskontext wird von der vorgeschlagenen Middleware
verwaltet. Jede Serviceschicht bildet eine Schnittstelle mit der
Middleware hinsichtlich der Autorisierung zur Servicenutzung und
der Service-Abrechnung.
-
Es
gilt zu betonen, dass alle Sicherheitslücken (Viren, Würmer oder
andere Attacken auf den Computer des Kunden), die während einer
anhängigen
Onlinesitzung auftreten, die den oben beschriebenen Sitzungskontext
umfasst, auf dem Computer des Kunden mit Hilfe bekannter Firewall-Softwarelösungen geschlossen
werden können,
welche die Sockets von Betriebssystemen effektiv kontrollieren und überwachen.
Diese Sicherheitssoftwarelösungen können von
einer E-Company (im oben genannten Sinn) als E-Service (ebenfalls
im oben genannten Sinn) bereitgestellt werden. In Kombination mit
dem oben beschriebenen Kommunikationsprotokoll, das insbesondere
den Sitzungskontext enthält,
ist die hiermit erreichte Sicherheitsstufe erheblich höher als bei
Ansätzen
nach dem Stand der Technik.
-
Im
Folgenden wird unter Bezugnahme auf 4 das zuvor
erwähnte
RADIUS-Protokoll (Remote Authentication Dial In User Service), das
z. B. in den Dokumenten RFC2865, RFC2866, RFC2867 und RFC2868 (www.ietf.org)
veröffentlicht
ist, ausführlicher
beschrieben.
-
Das
RADIUS-Protokoll legt ein Verfahren zur Durchführung der Authentifizierung,
Autorisierung und Konfiguration von Informationen zwischen einem Netzzugriffsserver
(NAS) 400 und einem gemeinsam genutzten Authentifizierungsserver
dar. Ein erstes Schlüsselmerkmal
von RADIUS ist das ihm zugrunde liegende Client/Server-Modell, nach
welchem ein Netzzugriffsserver (NAS) als RADIUS-Client betrieben
wird. Aufgabe des Client ist es, Benutzerinformationen an zugeordnete
RADIUS-Server 402 zu leiten und anschließend die
zurückgegebene
Antwort zu verarbeiten. Im Gegensatz dazu haben RADIUS-Server die
Aufgabe, Benutzerverbindungsanforderungen zu empfangen, den Benutzer
zu authentifizieren und dann alle Konfigurationsinformationen zurückzugeben,
die der Client benötigt,
um dem Benutzer den Service bereitzustellen. Ein RADIUS-Server kann
als Proxy-Client für
andere RADIUS-Server oder andere Arten von Authentifizierungsservern
agieren.
-
Es
sollte erwähnt
werden, dass die Kommunikation zwischen einem NAS- und einem RADIUS-Server
auf dem bekannten User Datagram Protocol (UDP) basiert. Das im Protokollstandard
RFC 768 dokumentierte UDP ermöglicht
Benutzern den Zugriff auf IP-ähnliche
Services. UDP-Pakete werden genau wie IP-Pakete geliefert – als verbindungslose
Datagramme, die vor dem Erreichen ihrer Ziele gelöscht werden
können.
Der Einsatz von UDP ist sinnvoll, wenn der Einsatz von TCP zu komplex,
zu langsam oder einfach nicht notwendig ist. Genauer gesagt ist UDP
so definiert, dass es bei der paketvermittelten Computerkommunikation
in einer Umgebung, die aus einer Gruppe untereinander verbundener
Computernetze besteht, einen Datagramm-Modus zur Verfügung stellt.
Beim Einsatz dieses Protokolls wird davon ausgegangen, dass als
Grundprotokoll das Internetprotokoll (IP) verwendet wird. UDP wird
hauptsächlich
in Anwendungsprogrammen verwendet, um mit einem minimalen Protokollmechanismus
Nachrichten an andere Programme zu senden. Das Protokoll ist transaktionsorientiert,
und weder die Datenbereitstellung noch der Duplikatschutz sind garantiert. Bei
Anwendungen, bei denen es auf eine geordnete, zuverlässige Bereitstellung
von Datenströmen
ankommt, sollte das Übertragungskontrollprotokoll
TCP verwendet werden.
-
Die
oben erwähnte
Nachricht der Authentifizierungsanfrage enthält den vom Benutzer angegebenen
Namen und das von ihm angegebene Kennwort sowie die Identität der Zugriffseinheit,
welche die Anfrage sendet, und den für die Remoteverbindung verwendeten
Port. Da es im gesamten Netz zur Kommunikation mit dem RADIUS-Server
kommt, wird das vom Benutzer angegebene Kennwort üblicherweise vor
dem Senden der Authentifizierungsanfrage vom NAS verschlüsselt, um
die Wahrscheinlichkeit einer Beeinträchtigung zu minimieren.
-
Die
Authentifizierungsanfrage kann entweder über das lokale Netz an einen „lokalen" RADIUS-Server oder über ein
Weitverkehrsnetz an einen „Remoteserver" gesendet werden.
Dadurch lässt sich
der Entwurf der gesamten Netzarchitektur flexibilisieren, da der
RADIUS-Server an der am besten geeigneten Position und nicht unbedingt
am physikalischen Punkt des Remotezugriffs angeordnet werden kann.
Dies ist ein wichtiges Merkmal in Fällen, in denen eine als „Host" fungierende Organisation
zwar die Kontrolle über
den Authentifizierungsprozess behalten muss, aber die meisten oder
alle anderen Elemente der Infrastruktur für den Remotezugriff auslagern
möchte.
Das RADIUS-Protokoll ermöglicht
auch eine Authentifizierungsredundanz, indem es den Clienteinheiten
ermöglicht,
Anfragen an alternative Server zu leiten, wenn der primäre RADIUS-Server
nicht erreichbar ist.
-
Der
RADIUS-Server empfängt
die Authentifizierungsanfrage, prüft die Anfrage (um sicherzustellen,
dass sie von einer gültigen
Clienteinheit stammt) und entschlüsselt dann das Datenpaket,
um den Benutzernamen und das Kennwort offen zu legen. Diese Berechtigungsnachweise
werden dann an dasjenige System weitergeleitet, das für die Durchführung des
Authentifizierungsprozesses verwendet wird. Die zur Authentifizierung
der Benutzeranmeldungsanforderung verwendeten Informationen können in
einer Kennwortdatei, in einer zentralen Authentifizierungsdatenbank
oder in einem angepassten (oder proprietären) System enthalten sein.
Auch mit anderen kommerziell eingesetzten Sicherheitssystemen (z.
B. Kerberos), die das RADIUS-Protokoll unterstützen, kann zur Bereitstellung
der Authentifizierung eine Schnittstelle gebildet werden.
-
Nach
dem ordnungsgemäßen Abgleich
der Berechtigungsnachweise (Name und Kennwort) des den Zugriff anfordernden
Benutzers mit den gespeicherten Informationen gibt der RADIUS-Server
eine Nachricht zur Bestätigung
der Authentifizierung an den NAS-Server zurück. Diese Nachricht enthält die Verbindungsinformationen
(Netztyp und -services), die zur Verbindung des authentifizierten
Benutzers mit dem Netz notwendig sind. Die Art der Verbindung (TCP/IP,
PPP, SLIP usw.) und die Zugriffsbeschränkungen werden somit in Übereinstimmung
mit den zuvor festgelegten Richtlinien auf die Anmeldung des Benutzers
angewendet. Wenn im entgegengesetzten Fall die vom RADIUS-Client
empfangenen Berechtigungsnachweise nicht mit den Informationen im Speicher
für Authentifizierungsinformationen übereinstimmen,
gibt der Server eine Nachricht zur Verweigerung der Authentifizierung
an den NAS-Server zurück.
Diese Nachricht veranlasst den NAS-Server, dem anfordernden Benutzer
den Zugriff zu verweigern.
-
Das
RADIUS-Protokoll sorgt nicht nur für die Verschlüsselung
des Benutzerkennworts während der
Datenübertragungen
zwischen dem NAS-Server und dem Authentifizierungsserver, sondern
auch für zusätzliche
Sicherheit, um eine Gefährdung
der Authentifizierung aufgrund der Manipulation des Nachrichtenübertragungsprozesses
zu vermeiden. Wie oben erwähnt,
werden die zwischen den RADIUS-Clients
und RADIUS-Servern gesendeten Nachrichten geprüft, um das „Spoofing" in Bezug auf diese Anforderungen zu
verhindern. Der RADIUS-Server erfüllt diese Aufgabe, indem er
einen Authentifizierungsschlüssel
an die RADIUS-Clienteinheiten sendet. Diese Nachricht stellt als
digitale Signatur sicher, dass der richtige Authentifizierungsserver
tatsächlich Authentifizierungsnachrichten
erstellt.
-
Das
RADIUS-Protokoll bietet somit ein hohes Maß an Netzsicherheit, da Transaktionen
zwischen dem Client und dem RADIUS-Server durch die Verwendung eines „Shared
Secret" authentifiziert werden,
das niemals über
das Netz gesendet wird. Hinzu kommt, dass alle Benutzerkennwörter zwischen
dem Client und dem RADIUS-Server verschlüsselt gesendet werden, um die Möglichkeit
auszuschließen,
dass eine ein unsicheres Netz ausspähende Person das Kennwort eines
Benutzers ermitteln kann.
-
Darüber hinaus
bietet RADIUS flexible Authentifizierungsmechanismen, da der RADIUS-Server
eine Vielzahl unterschiedlicher Verfahren zur Authentifizierung
eines Benutzers unterstützen
kann. Er unterstützt
die Protokolle PPP, PAP oder CHAP, die Anmeldung unter UNIX und
andere Authentifizierungsmechanismen. RADIUS ist nicht zuletzt auch ein äußerst erweiterbares
Protokoll, da alle Transaktionen aus 3-Tupeln Attribut-Länge-Wert
mit variabler Länge
bestehen. Neue Attributwerte können
hinzugefügt
werden, ohne dass es zu einem Konflikt mit den vorhandenen Implementierungen
des Protokolls kommt.
-
Im
Hinblick auf die Authentifizierung und Autorisierung kann der RADIUS-Server 402 eine
Vielzahl unterschiedlicher Verfahren zur Benutzerauthentifizierung
unterstützen.
Anhand des Benutzernamens und des ursprünglich vom Benutzer vergebenen
Kennworts kann er die Protokolle PPP, PAP oder CHAP, die Anmeldung
unter UNIX und andere Authentifizierungsmechanismen unterstützen. In
der Regel besteht eine Benutzeranmeldung aus einer vom NAS-Server
am RADIUS-Server 402 vorgenommenen Abfrage – der Zugriffsanforderung
(Access-Request) – und
einer entsprechenden Antwort des Servers, der Zugriffsgewährung oder – verweigerung
(Access-Accept oder Access-Reject). Das Access-Request-Paket enthält den Benutzernamen, das verschlüsselte Kennwort,
die IP-Adresse des NAS-Servers und zusätzliche Informationen zur Art der
Netzverbindung.
-
Nachdem
der RADIUS-Server 402 die Access-Request-Nachricht vom
NAS-Server empfangen hat, durchsucht er eine Datenbank nach dem aufgelisteten
Benutzernamen. Wenn der Benutzername nicht in der Datenbank enthalten
ist, wird entweder ein Standardprofil geladen, oder der RADIUS-Server 402 sendet
unverzüglich
eine Access-Reject-Nachricht. Dieser Access-Reject-Nachricht kann eine
Textnachricht beigefügt
sein, die den Grund für die
Zugriffsverweigerung angibt.
-
Über die
RADIUS-Abrechnungsfunktionen können
zu Beginn und am Ende von Sitzungen Daten gesendet werden, welche
die während
der Sitzung verwendete Menge an Ressourcen (Zeit, Pakete, Bytes
usw.) angeben. Ein Internet-Service-Provider (ISP) kann mit Hilfe
einer auf RADIUS basierenden Zugriffssteuerung und Abrechnungssoftware
spezielle Sicherheits- und Fakturierungsanforderungen erfüllen.
-
Transaktionen
zwischen dem Client und dem RADIUS-Server 402 werden mit
Hilfe eines Shared Secret authentifiziert, das niemals über das
Netz gesendet wird. Hinzu kommt, dass Benutzerkennwörter zwischen
dem Client und dem RADIUS-Server 402 verschlüsselt gesendet
werden, um die Möglichkeit auszuschließen, dass
eine ein unsicheres Netz ausspähende
Person das Kennwort eines Benutzers ermitteln kann.
-
Der
auf der Informationstechnologie (IT) basierende Prozess oder Service
gemäß der Erfindung wird
hinsichtlich des OSI-Modells vorzugsweise hinter einer IP-Schicht
als Serverinstanz oder Middleware eines Servers implementiert, wie
in 5 veranschaulicht ist. Aus 5 ist ersichtlich,
dass der Prozess auf einem Interaktionsszenario basiert, das vier Hauptkomponenten
umfasst: einen E-Network-Betreiber 500, der die grundlegende
Netzinfrastruktur und die Zentralverbindung für die Ausführung der zugrunde liegenden Übertragungsprotokolle
bereitstellt, einen oder mehrere E-Service-Anbieter 502, mit
denen ein (nicht dargestellter) Benutzer beliebige kommerzielle
oder sogar nicht kommerzielle Geschäfte tätigen möchte, eine E-Company 504 zur Verwaltung
des gesamten Prozesses und eine der Netzinfrastruktur übergeordnete
Middleware 506 zur Verarbeitung eines so genannten „Sitzungskontextes", wie nachfolgend
ausführlicher
beschrieben wird, und zur Bereitstellung einer AAA-Steuerungseinrichtung
und einer Vertriebseinheitsverwaltung für die Abwicklung der zuvor
erwähnten
Geschäfte
im Einklang mit dem neuen, erfindungsgemäßen Geschäftsprozess.
-
5 stellt
zu diesem Zweck die allgemeine architektonische Struktur der vorgeschlagenen
Lösung
dar. Der Hauptaspekt der vorliegenden Ausführungsart ist, dass die Middleware-Engine
der von einem E-Network-Betreiber bereitgestellten IP-Vermittlungsschicht übergeordnet
ist. Dieser E-Network-Betreiber
kann mehrere Zugriffsverfahren (u. a. POTS, ISDN, mobile Verfahren)
unterstützen.
In 5 sind die verschiedenen Komponenten dargestellt:
-
1. Netz-Verbindungseinheit 508
-
Wenn
ein Client auf die Middleware 506 über ein Netz zugreift, das
nicht vom Anbieter der Middleware betrieben wird, muss ein Sitzungskontext
mit einer von der Middleware bereitgestellten IP-Adresse erstellt
werden. Die Netz-Verbindungseinheit erledigt diese Aufgabe unter
Anwendung von VPN-Technologien wie den Protokollen GRE, PPTP, L2F,
L2TP oder einem beliebigen anderen Tunnelprotokoll. Dieses Verfahren
gewährleistet
die Authentifizierung des Client über die AAA-Steuerungseinrichtung,
so dass er die Middleware-Funktionen im ganzen Umfang nutzen kann,
ohne dass sein Zugriff auf das Internet oder das Netz in irgendeiner
Weise eingeschränkt wird.
Wenn es sich bei dem E-Network-Betreiber und dem Anbieter der Middleware
um dasselbe Unternehmen handeln sollte, ist kein VPN erforderlich,
da die AAA-Steuerungseinrichtung (2) der Middleware auch die Authentifizierungsinstanz
für den
Netzzugriff darstellt, so dass dem Client folglich eine „Middleware-IP-Adresse" zugeordnet wird.
-
2. AAA-Steuerungseinrichtung 510
-
Die
AAA-Steuerungseinrichtung ist für
die Authentifizierung des Clients zuständig und stellt nach dem erfolgreichen
Abgleich der Benutzerdaten mit der Benutzerdatenbank der entsprechenden E-Company
eine IP-Adresse bereit. Sie hält
den Sitzungskontext des Clients bis zu dessen Abmeldung aufrecht.
-
Sie
autorisiert den Kunden zum Konsum oder Kauf einer von einem E-Service-Anbieter
bereitgestellten Vertriebseinheit. Sie vergleicht die Autorisierungsanfrage
mit den Angaben zur Teilnehmerberechtigung für den Service und den persönlichen
Informationen, die in den Profilen des Benutzers enthalten sind.
-
Wenn
der Anbieter der Middleware zufällig auch
der Netzbetreiber des Kunden ist, verwaltet die Einrichtung auch
die Zugriffsmerkmale des Benutzers in einem Zugriffsprofil, das
auch zur Autorisierung der Servicenutzung verwendet werden kann.
-
3. Vertriebseinheitsverwaltung 512
-
Wenn
ein Benutzer/Kunde eine Vertriebseinheit konsumieren/kaufen möchte, wird
von der Vertriebseinheitsverwaltung ein Kontext für diese
Vertriebseinheit generiert. Bei der Bestellung einer Vertriebseinheit
bittet die E-Company die Vertriebseinheitsverwaltung um die Prüfung, ob
die Kosten der Vertriebseinheit in Übereinstimmung mit den für den Kunden
geltenden Zahlungsbedingungen (Prepaid-Konto, Kreditrahmen, Kreditkarte)
gedeckt werden. Die Vertriebseinheitsverwaltung reagiert hierauf mit
einer Bestätigung
oder einer Ablehnung.
-
Die
Vertriebseinheitsverwaltung verfolgt die verschiedenen Transaktionen
und Status während des
gesamten Kaufprozesses.
-
Nach
der Bestätigung
der vollständigen
Lieferung der Vertriebseinheit wird ein Abrechnungsereignis generiert
und an die Fakturierungskomponente der entsprechenden E-Company
gesendet, und der Kontext wird daraufhin beendet.
-
Die
Vertriebseinheitsverwaltung nutzt Technologien wie SMS (Short Messaging
Service), IVR (Interactive Voice Response), E-Mail oder den Webzugriff
zur Bestätigung
und Benachrichtigung über die
verschiedenen Transaktionen während
der Lebensdauer des Vertriebseinheitskontextes.
-
4. CRM 514
-
Mittels
CRM verwaltet der Betreiber der E-Company die Benutzerdatenbank
für die
Kunden.
-
5. Benutzerdatenbank 516
-
Die
Benutzerdatenbank enthält
alle Informationen über
die Kunden der E-Company (Benutzerprofile mit Angaben zu Zahlungsbedingungen, Adresse,
Alter usw. sowie Serviceprofile mit Angaben zu Teilnehmerberechtigungen).
-
6. Fakturierung 518
-
Die
Fakturierungskomponente der E-Company bildet eine Schnittstelle
mit den verschiedenen Kreditkarten- und Bankinstitutionen. Sie wickelt
die Zahlungen für
die konsumierten/gekauften Vertriebseinheiten gemäß der vorkonfigurierten
Zahlungsbedingungen des Kunden ab.
-
Die
Fakturierungskomponente übernimmt auch
die Rechnungsstellung und wickelt die Zahlungen an den E-Service-Anbieter
ab.
-
7. E-Service-Verbindungseinheit 520
-
Die
E-Service-Verbindungseinheit führt
einen oder mehrere E-Service-Anbieter in einer Vertriebs-/Marketingplattform zusammen.
Sie ermöglicht dem
E-Service-Anbieter, seine Vertriebseinheiten über die E-Company anzubieten,
ohne dass er Kundeninformationen einholen und Fakturierungsmodalitäten beachten
muss.
-
6 zeigt
eine mögliche
Umgebung für B2B-Transaktionen
(Business-to-Business), in welcher die vorgeschlagene Middleware 600 mit
den drei verschiedenen E-Companies 602-606 über das
Internet 608 zusammenwirkt. Jede dieser E-Companies 602-606 verwaltet
einen Bestand an Benutzern (Kunden), welche die Vorteile aller Funktionen
der Middleware 600 in vollem Umfang nutzen können. Hierbei ist
anzumerken, dass zum Zweck der Vereinfachung die Benutzer, der NAS-Server
und die E-Service-Anbieter nicht dargestellt sind. Jede E-Company 602-606 verwaltet
ferner eine entsprechende Benutzerdatenbank 609, 610, 612 für diese
Benutzer und einen RADIUS-Server 614-618 zur Durchführung der oben
beschriebenen AAA-Services.
-
In 7 sind
schließlich
mögliche
Integrationsprofile für
die Hauptkomponenten der in 5 gezeigten
Vermittlungsschichtstruktur in einer Übersicht aller berücksichtigten
Rollen der Akteure dargestellt. Theoretisch gibt es noch einige
weitere mögliche
Kombinationen der vier Hauptkomponenten, die aber keine praktische
Bedeutung haben. Nachfolgend werden die sechs dargestellten Integrationsprofile
unter Bezugnahme auf die Ziffern I)-VI) aus 7 ausführlicher
beschrieben.
- I) Ein Unternehmen, z. B. ein
Telekommunikationsunternehmen als früherer klassischer Netzbetreiber,
das auf allen vier Ebenen (E-Network-Betreiber, Middleware-Betreiber,
E-Company und E-Service-Anbieter) agiert, kann eine ASP-Plattform
für mehrere
Services anbieten. Dabei agiert der Netzbetreiber mit seinen Geschäftsbereichen auch
als E-Company und nutzt dafür
seine eigene Infrastruktur. Er bietet seine eigenen E-Services an
und kann E-Services anderer Serviceanbieter integrieren und dafür seine
große
Teilnehmerdatenbank wirksam nutzen. Das Telekommunikationsunternehmen
kann integrierten Serviceanbietern (d. h. Einzelhändlern)
auch echte transaktionsbasierte Zahlungsservices anbieten.
- II) Stellt ein Unternehmen dar, das dem unter I) beschriebenen
Unternehmen ähnelt,
aber keine eigenen E-Services anbietet.
- III) Ein Unternehmen, das als Host für E-Companies auftreten möchte, agiert
als E-Network-Betreiber und Middleware-Betreiber. Es bietet Zugriffs-
und Bereitstellungsservices sowie sichere, konsumorientierte Zahlungs-
und Workflow-Management-Services an. Das Unternehmensprofil unter
Ziffer VI) stellt einen möglichen
Kunden dieses Unternehmens dar.
- IV) Zeigt eine Variante des Unternehmensbeispiels I), die über keine
eigenen Netzservices verfügt.
- V) Zeigt ein Unternehmen, das die unter II) beschriebenen Hosting-Services
anbietet, aber kein eigenes Netz betreibt und keine E-Services anbietet.
- VI) Zeigt ein Unternehmen, das eigene E-Services anbietet und
als Host für
die Services anderer Serviceanbieter agiert.