-
GEBIET DER
ERFINDUNG
-
Die
vorliegende Erfindung bezieht sich allgemein auf ein Telekommunikationsnetz,
das mit einem bedienenden Netz eines Internet-Dienstanbieters (ISP,
Internet Service Provider) gekoppelt ist, zum Ausführen der
Authentifizierung, Autorisierung und Abrechnung von Benutzern mit
Fernzugriff. Genauer betrifft die Erfindung Mittel, System und Verfahren, um
Netzen des obigen Typs zu ermöglichen,
den geeigneten Authentifizierungs-, Autorisierungs- und Abrechnungsserver
(hierin nachstehend als ein AAA-Server bezeichnet) zu bestimmen,
der für
einen Benutzer verantwortlich ist, der eine Dienstanforderung (Serviceanforderung)
ausgegeben hat.
-
HINTERGRUND
-
Der
Zugang zu Internetdiensten wird heutzutage durch einen ISP bereitgestellt.
In dem häufigsten
Szenarium managen unterschiedliche Betreiber das ISP-Netz und das
Zugangsnetz. Beide Netze werden somit als getrennte Netze betrachtet.
Der ISP führt
Authentifizierung, Autorisierung und Abrechnungsprüfungen für Benutzer
durch, die auf seine Dienste über
ein Zugangsnetz zugreifen. Insbesondere sind diese Benutzer Teilnehmer
eines Telekommunikationsnetzes, das als ein Zugangsnetz zu dem ISP-Netz
agiert.
-
Wenn
ein Benutzer eines Telekommunikationsnetzes wünscht, sich mit einem gewissen
Server zu verbinden, der zu einem ISP gehört, wird somit eine Dienstanforderung
von dem Benutzer zu dem ISP-Server über einen Netzzugangserver
(NAS, Network Access Server) gesendet, der zu dem Telekommunikationsnetz
gehört.
Ungeachtet dessen muss der Benutzer zuvor authentifiziert sein und
die Dienstanforderung muss zuvor durch eine Entität, wie etwa
einen Authentifizierungs-, Autorisierungs- und Abrechnungsserver (AAA-Server),
autorisiert sein. Wenn der Benutzer eine Dienstanforderung zu dem
NAS sendet, trägt
er zu diesem Zweck auch einen Benutzeridentifikator und ein Passwort
für seine eigene
Identifikation ein. Diese Information wird zu dem AAA-Server unter
Verwendung eines Kommunikationsprotokolls gesendet, wie etwa dem
Fernauthentifizierungs-Einwahl-Benutzerdienst (allgemein als RADIUS,
Remote Authentication Dial In User Service, bekannt), oder die RADIUS-Aktualisierung
(Aufrüstung),
bekannt als DIAMETER-Protokoll,
oder dergleichen.
-
Die
Internet Engineering Task Force (IETF) definiert das RADIUS-Protokoll
in RFC 2865. Gleichermaßen
ist das DIAMETER-Protokoll
in "draft-ietf-aaa-diameter-08.txt" definiert, was auch durch
die IETF vorangetrieben wird. Das Basiskonzept hinter DIAMETER ist,
ein Basisprotokoll vorzusehen, das erweitert werden kann, um AAA-Dienste für neue auf
Zugang bezogene Technologien vorzusehen. Sowohl die RADIUS- als
auch die DIAMETER-Spezifikationen beschreiben Protokolle, die zum
Ausführen
der Authentifizierung und Autorisierung ebenso wie zum Sammeln der
Abrechnungsinformation zwischen dem NAS und dem AAA-Server geeignet
sind, wo der NAS wünscht,
seine Verknüpfungen
zu authentifizieren.
-
Vorausgesetzt,
dass das verwendete Protokoll RADIUS ist, erhält, wenn ein NAS, der als ein
Client eines RADIUS-AAA-Servers arbeitet, eine eingehende Dienstanforderung
empfängt,
der NAS Identifikationsinformation von dem Benutzer, nämlich einen
Namen und ein Passwort, und gibt dann eine Authentifizierungsanforderung
zu dem RADIUS-AAA-Server aus. Der RADIUS- AAA-Server authentifiziert auf Empfang
der Identifikationsinformation und anderer NAS-Information hin den
Benutzer. Das heißt
abhängig
davon, wer der Benutzer ist, wird er autorisiert, um Zugang zu unterschiedlichen Diensten
und Möglichkeiten
zu haben. Die RADIUS-Attribute tragen die spezifischen Authentifizierungs-
und Autorisierungsdaten ebenso wie Information und Konfigurationsdetails
für die
Anforderungs- und Antwortpakete.
-
Z.B.
sind Attribute, die in diesen Paketen übertragen werden können, der
Benutzer-Name, das Benutzer-Passwort und andere. Insbesondere zeigt das
Attribut Benutzer-Name den Namen des Benutzers an, der zu authentifizieren
ist. Das Format dieses Benutzer-Namens in dem RADIUS-Protokoll kann
eines von mehreren Formen sein:
- – Text,
eine Form, die nur aus UTF-8 codierten Zeichen besteht
- – Netzzugangidentifikator
(NAI, Network Access Identifier), nämlich Benutzername@Bereich,
wie in RFC 2486 beschrieben
- – ausgezeichneter
Name (DN, Distinguished Name), der ein Name in ASN.1-Form ist, was
in Authentifizierungssystemen mit öffentlichem Schlüssel verwendet
wird.
-
Wenn
andererseits DIAMETER das verwendete Protokoll ist, ist die Prozedur ähnlich zu
dem vorherigen Fall. Ein NAS, der als ein Client eines DIAMETER-AAA-Servers
agiert, initiiert eine Anforderung für Authentifizierung und/oder
Autorisierung eines gegebenen Benutzers zu dem DIAMETER-AAA-Server.
Der DIAMETER-AAA-Server authentifiziert den Benutzer auf Empfang
der Identifikationsinformation und anderer NAS-Information hin. Das
heißt
abhängig
davon, wer der Benutzer ist, wird er autorisiert, um Zugang zu unterschiedlichen Diensten
und Möglichkeiten
zu haben.
-
Beliebige
Daten, die durch das DIAMETER-Protokoll transferiert werden, sind
in der Form eines Attributwertepaars (hierin nachstehend AVP, Attribute
Value Pear). Das AVP wird durch das Basis-DIAMETER-Protokoll unter
anderen Dingen zum Transportieren der Benutzerauthentifizierungsinformation
zu dem DIAMETER-AAA-Server verwendet. Der Benutzername wird in dem
Benutzer-Name-AVP vorgesehen, was ein NAI-Format erlaubt, oder in
einem UTF-8-Format, das mit der NAI-Spezifikation konsistent ist.
-
Ein
typisches Szenarium eines Telekommunikationsnetzes, das mit einem
ISP zum Vorsehen von Internet-Diensten gekoppelt ist, ist die Bereitstellung
von Internet-Zugang in einem allgemeinen Paketfunkdienst- (GPRS,
General Packet Radio Service) Netz. In diesem Szenarium kann ein
Gateway-GPRS-Unterstützungsknoten
(hierin nachstehend GGSN, Gateway GPRS Support Node) mit einem AAA-Server
zusammenarbeiten, typischerweise unter Verwendung des RADIUS-Protokolls.
Somit agiert ein GGSN als ein Client eines RADIUS-AAA-Servers.
-
Ein
anderes Szenarium ist ein drahtloses Lokalbereichsnetz (WLAN, Wireless
Local Area Network), das auf das Internet durch einen WLAN-Zugangspunkt
zugreift, der mit einem AAA-Server
mittels DIAMETER- oder RADIUS-Protokollen verbunden ist. Somit kann
ein WLAN-Zugangspunkt jeweils als ein Client eines DIAMETER-AAA-Servers
oder als ein Client eines RRDIUS-AAA-Servers
agieren.
-
Heutzutage
speichern die ISPs Benutzerinformation für alle ihre Benutzer in großen Hintergrund-Datenbanken,
nämlich
AAA-Servern, auf
die der AAA-Client zugreifen kann. In Szenarien, wo die Zahl von
Benutzern sehr hoch ist, ist diese Lösung nicht leicht skalierbar,
da die Größe der Datenbanken und
die Zahl von Abfragen pro Sekunde das Leistungsverhalten des Netzes
notwendigerweise verringern. Vorausgesetzt, dass jeder ISP seine
Benutzer in einem eindeutigen großen AAA-Server organisiert hat,
muss insbesondere eine direkte Beziehung zwischen dem AAA-Server
und dem anfordernden AAA-Client während der gesamten Sitzung
unterhalten werden, was in dem Fall von auf Abrechnung bezogenen
Transaktionen das erwartete AAA-Server-Leistungsverhalten benachteiligen
kann.
-
Eine
unmittelbare Lösung
für einen
ISP mit einer sehr hohen Zahl von Benutzern kann darin bestehen,
dass der ISP mehr als einen AAA-Server benötigt, um seine Benutzerinformation
zu organisieren. Ein erster Nachteil dieses mehrfachen AAA-Server-Rahmens
besteht darin, dass die Sicherheitsbeziehungen zwischen dem AAA-Client
und den unterschiedlichen AAA-Servern komplizierter werden. Ein zweiter
Nachteil besteht darin, dass die ISP-Netzstruktur für den AAA-Client,
der ein NAS sein kann, der durch einen anderen Betreiber betrieben
wird, sichtbarer wird, und somit Netzkonfigurationsabhängigkeiten
zwischen dem ISP und dem Betreiber des Telekommunikationsnetzes
erzeugt.
-
Unabhängig von
den obigen Nachteilen müssen
die AAA-Clients, die einen Dienst von einem ISP mit einer Vielzahl
von AAA-Servern
anfordern, wissen, welcher AAA-Server für eine bestimmte Dienstanforderung
eines gewissen Benutzers kontaktiert werden sollte. In Abwesenheit
anderer Kriterien kann ein AAA-Client sequenzielle Abfragen zu jenen
AAA-Servern eines gekoppelten ISP durchführen, bis der geeignete AAA-Server
gefunden ist, der für
einen gewissen Benutzer verantwortlich ist.
-
Besseres
Leistungsverhalten als für
sequenzielle Abfragen kann durch Zwischenstellen eines AAA-Proxy
(Stellvertreters) zwischen den AAA-Client und ein ISP-Netz mit einer
Vielzahl von AAA-Servern erreicht werden. Ein derartiger AAA-Proxy,
wie
US 6,298,383 beschreibt,
ist typischerweise in der Lage, zwischen AAA-Servern auf einer Basis
pro Domäne zu
unterscheiden. Indem von Benutzeridentifikatoren in einem NAI-Format
oder dergleichen, nämlich
Benutzername@Bereich, Gebrauch gemacht wird, kann ein ISP seine
Benutzer unter unterschiedlichen AAA-Servern auf einer Basis pro
Bereich anordnen. Der obige AAA-Proxy ist dann in der Lage, den
spezifischen AAA-Server
zu bestimmen, der für
alle Benutzer in einer spezifischen Domäne verantwortlich ist, nämlich die
Domäne,
die durch den Bereich adressiert wird, der durch derartige Benutzer
gemeinsam genutzt wird.
-
Gegenwärtig gibt
es kein anderes Kriterium zum Anordnen von Benutzern unter AAA-Servern
in einem ISP-Netz. In dieser Hinsicht kann nur der gut bekannte
und strukturierte Bereich in einem obigen NAI-Format, z.B. "acme.com", verwendet werden, um
einen eindeutigen AAA-Server unzweideutig zu bestimmen, der für eine gewisse
Domäne
in einem ISP-Netz verantwortlich ist.
-
Es
gibt jedoch Benutzer-Namensformate mit Ausnahme von NAI, oder nicht
konsistent strukturierte oder sogar unstrukturierte, für die ein
derartiger AAA-Proxy nicht in der Lage ist, unter einer Vielzahl von
AAA-Servern zu unterscheiden, und dies ist ein wesentlicher Nachteil
für die
ISPs. Z.B. ist ein AAA-Proxy, der Dienstanforderungen von einem GGSN
empfängt,
der als ein NAS eines GPRS-Netzes agiert, wobei der GGSN von der
Mobilteilnehmer-ISDN-Nummer (MSISDN, Mobile Subscriber ISDN number)
als Benutzeridentifikator Gebrauch macht, nicht in der Lage, einen
aus einer Vielzahl von AAA-Servern
für diese
Art von Benutzeridentifikator auszuwählen.
-
Außerdem,
und selbst für
Benutzer-Namen in NAI-Formaten, ist der AAA-Proxy nicht in der Lage, mehr
als einen AAA-Server für
die gleiche Domäne zu
unterscheiden. D.h. alle Benutzer, denen der gleiche Bereich in
einem NAI-Format gegeben ist, müssen
sich in dem gleichen AAA-Server in einem gewissen ISP-Netz befinden. Diese
eindeutige Anordnung aller Benutzer mit der gleichen Domäne oder
Bereich in dem gleichen AAA-Server wird als noch ein Nachteil für die ISPs
betrachtet, da kompliziertere Mechanismen für Lastausgleich zwischen AAA-Servern
unterschiedlicher Kapazität
eingeführt
werden sollten.
-
Ein
weiterer Nachteil, wo Benutzer-Namensformate einen Bereichs- oder
einen Domänenidentifikator
nicht einschließen,
besteht darin, dass die Einbeziehung des zuvor erwähnten AAA-Proxy nicht die Identifikation
eines eindeutigen AAA-Servers löst, der
für einen
gewissen Benutzer in einem ISP-Netz mit einer Vielzahl von AAA-Servern
verantwortlich ist. In dieser Hinsicht können Betreiber eines Telekommunikationsnetzes,
wo Teilnehmeridentifikatoren einen Bereichs- oder Domänenidentifikator
nicht einschließen,
diesen AAA-Proxy als eine überflüssige Entität sehen,
der das AAA-Dienst-Leistungsverhalten benachteiligt. Die Einführung dieses
AAA-Proxy kann jedoch die zwei zuvor erwähnten Nachteile überwinden
oder mindestens minimieren, Sicherheitsbeziehungen und Sichtbarkeit
der ISP-Netzstruktur,
insbesondere wenn der AAA-Proxy zu dem ISP-Netz gehört. In diesem
besonderen Fall ist die Einbeziehung eines derartigen AAA-Proxy
für das
Interesse des ISP von Vorteil, wohingegen Betreiber von Telekommunikationsnetzen
dieses obigen Typs benachteiligt werden.
-
Dadurch
ist es ein erstes Ziel der vorliegenden Erfindung, Mittel und Verfahren
zum Anordnen von Benutzern von AAA-Diensten unter einer Vielzahl von AAA-Servern
unabhängig
von Benutzeridentifikator-Schemata, Strukturen und anwendbarem Dienst
vorzusehen.
-
Es
ist ein weiteres Ziel der vorliegenden Erfindung, das obige erste
Ziel mit der Einbeziehung eines aufgerüsteten AAA-Proxy kompatibel
zu machen, um die obigen ersten und zweiten Nachteile zu lösen, jene,
die sich auf Sicherheitsbeziehungen und Sichtbarkeit der ISP-Netzstruktur
beziehen. Der aufgerüstete
(aktualisierte) AAA-Proxy ist in der Lage, den geeigneten AAA-Server,
der für
einen gegebenen Benutzer verantwortlich ist, unabhängig von
Benutzeridentifikator-Schemata, Strukturen und anwendbarem Dienst
auszuwählen,
wobei somit das erstes Ziel der vorliegenden Erfindung erfüllt wird.
-
STAND DER
TECHNIK
-
Ein
Startpunkt von Interesse wird in typischen drahtlosen Systemen der
zweiten Generation gefunden, wie GSM- und ANSI-41-Netzen. Da die drahtlosen Systeme
mehr und mehr Teilnehmer bekommen haben, haben die Betreiber hoch
dimensionierte Teilnehmerdatenbanken gewünscht, wie etwa das Heimatstandortregister
(HLR, Home Location Register), um eine große Menge von Abonnements zu
unterhalten, wobei die O&M-Aktivitäten minimiert werden,
und die Weiterleitungstabellen in dem Netz des Signalisierungssystems
Nummer 7 (SS7) optimiert werden. Das Erscheinen jüngeren Datums
von Nummernportabilitätsanforderungen,
in einigen Fällen
durch gesetzliche Regelung, wo einzelne Teilnehmer von einem HLR,
das zu einem Betreiber gehört, zu
einem anderen HLR, das zu einem anderen Betreiber gehört, bewegt
wurden, haben die Notwendigkeiten für einen Datenbankselektor zu
einem Muss gemacht.
-
Eine
beispielhafte Beschreibung eines derartigen Datenbankselektors kann
in der internationalen Anmeldung WO 99/23838 gefunden werden, wo
der Datenbankselektor in einem gewissen Netz als ein flexibles Nummernregister
(FNR) bezeichnet wird. Dieses FNR ist ein natürlicher Eingangspunkt in einem
drahtlosen Netz zweiter Generation für Abfragen, die sich auf jene
Teilnehmer beziehen, deren Benutzernummernserie zu dem Netz gehört, unabhängig davon,
welches Netz gegenwärtig
das Teilnehmerabonnement enthält.
D.h. das FNR umfasst alle Benutzer nummernserien, die ein derartiges
Netz adressieren, und auch einzelne Benutzernummern für Teilnehmer,
die in dieses Netz von einem anderen Netz portiert sind. Übrigens
sind einzelne Benutzernummern von Heimat-Teilnehmern, die zu einem
anderen Netz portiert wurden, besonders markiert und haben einen
besonderen Netzidentifikator, um einen Eingangsknoten in dem Netz
zu erreichen, wo der Teilnehmer gegenwärtig sein oder ihr Abonnement hält.
-
Auf
Teilnehmer bezogene Abfragen basierend auf Benutzernummern, wie
etwa IMSI- oder E.164-Formaten, werden zu dem FNR in einem Netz adressiert,
das durch das IMSI- oder E.164-Format adressiert werden. Diese Formate
entsprechen gut strukturierten Nummerserien einer vordefinierten Länge. Dann
bestimmt das FNR, ob die Abfrage einfach zu dem geeigneten HLR innerhalb
seines eigenen Netzes für
Teilnehmer transferiert werden sollte, die von anderen Netzen niemals
portiert oder importiert und wurden, oder ob die Abfrage zu dem
geeigneten Netz umgeleitet werden sollte, wo der Teilnehmer exportiert
wurde. Alle erforderlichen Weiterleitungs- und Adressierungsmechanismen
werden in unteren Signalisierungsschichten ausgeführt, wie
in dem Signalisierungsverbindungssteuerteil (SCCP, Signalling Connection
Control Part) innerhalb von SS7.
-
Obwohl
diese Lösung
als ein relevanter Stand der Technik betrachtet wird, stellt sie
dennoch ernsthafte Begrenzungen für eine direkte Anwendbarkeit
auf neuere Szenarien dar, die traditionelle feste und drahtlose
Telefonnetze mit dem Internet und Multimedia-Dienstnetzen in großen Telekommunikationssystemen
miteinander verbinden. Z.B. betrachtet dieser FNR-Stand der Technik
nur Signalisierung, Weiterleitung und Adressierung in Übereinstimmung mit
SS7-Prinzipien, wo Teilnehmer- oder
Benutzeridentifikatoren lediglich auf strukturierten Nummern basieren.
Außerdem
muss mindestens einer der Identifikatoren, die mit einem Teilnehmer
in Verbindung stehen, auf eine derartige Weise strukturiert sein,
dass die Analyse einer derartigen Nummer das geeignete HLR unzweideutig
identifiziert. Noch eine andere Begrenzung dieser vorherigen Lösung besteht
darin, dass weder andere neuere Identifikatorbereiche noch Protokollunterstützung außer auf
SS7 bezogener oberer Schichten während
der Entwicklung dieser drahtlosen Netze zweiter Generation betrachtet
wurden. Ferner wird in diesem Stand der Technik in Bezug auf Dienst-dedizierte
Server nichts antizipiert, wie etwa jene in Bezug auf AAA-Dienste, die
als Reaktion auf Abfragen basierend auf entsprechenden Benutzeridentifikatoren
adressiert werden müssen.
-
Dadurch
scheinen die zuvor erwähnten
Ziele der vorliegenden Erfindung durch die Unterweisungen von der
obigen Anmeldung nicht bewerkstelligt oder antizipiert zu werden.
In dieser Hinsicht ist die Bereitstellung eines Mittels und Verfahrens,
um eine ausgeglichene Anordnung von Benutzern unter einer Vielzahl
von AAA-Servern unabhängig
von Benutzeridentifikatorschemata, Strukturen und anwendbarem Dienst
dennoch ein Ziel der vorliegenden Erfindung. Das Mittel und das
Verfahren, kompatibel mit der Einführung eines AAA-Proxy zwischen
dem AAA-Client und einem ISP mit einer Vielzahl von AAA-Servern
zum Unterstützen
der ausgeglichenen Anordnung von Benutzer sind noch ein anderes
Ziel der vorliegenden Erfindung.
-
ZUSAMMENFASSUNG
DER ERFINDUNG
-
Es
wird ein Benutzerselektorproxy (USP, User Selector Proxy) zum Unterstützen einer
ausgeglichenen Anordnung von Benutzern unabhängig von Benutzeridentifikatorschemata,
Strukturen und anwendbarem Dienst, während er als ein Proxy agiert, vorgesehen,
wobei somit die Ziele der vorliegenden Erfindung erfüllt werden.
-
Deshalb
umfasst dieser USP Mittel zum Empfangen von Authentifizierungs-,
Autorisierungs- und Abrechnungs- (AAA-) Dienstanforderungen von einem
AAA-Client, Mittel zum Extrahieren einer Benutzerdomäne aus einem
empfangenen Benutzeridentifikator, Mittel zum Identifizieren des
AAA-Servers, der für
die Benutzerdomäne
in einem Internetdienstanbieter- (ISP) Netz verantwortlich ist,
Mittel zum Vorlegen der AAA-Dienstanforderung zu einem AAA-Server,
Mittel zum Empfangen der entsprechenden AAA-Dienstantwort von dem
AAA-Server und Mittel zum Rückgeben
der AAA-Dienstantwort zu dem AAA-Client, der die Anforderung ausgegeben hat.
Dieser USP in Übereinstimmung
mit der Erfindung umfasst auch Mittel zum Analysieren des empfangenen
Benutzeridentifikators, in entweder einem strukturierten oder unstrukturierten
Format und unabhängig
von Identifikatorschemata, um zu bestimmen, ob alle Benutzeridentifikatorfelder,
oder ein Benutzer-Name allein oder die Benutzerdomäne allein, oder
eine Kombination davon für
eine Auswahl eines AAA-Servers genommen wird, der für diesen
Benutzer verantwortlich ist; und Mittel zum Auswählen eines AAA-Servers, der
für den
Benutzer verantwortlich ist, in einem Internetdienstanbieter- (ISP)
Netz.
-
Der
Effizienz halber umfasst der Benutzerselektorproxy ferner einen
Speicher auf Einzelbenutzerbasis, oder auf der Basis einer Gruppe
von Benutzern oder beiden, zum Speichern mindestens eines Identifikators
für jeden
mindestens einen AAA-Server, der für einen gegebenen einzelnen
Benutzer oder eine Gruppe von Benutzern verantwortlich ist. Insbesondere
kann dieser Speicher durch eine interne oder externe Datenbank angeboten
werden, die Beziehungen zwischen Benutzeridentifikatoren und AAA-Serveridentifikatoren
auf Basis pro Benutzer und/oder pro Gruppe von Benutzern umfasst.
-
Eine
weitere vorteilhafte Anordnung von Benutzern kann erreicht werden,
indem es einen Benutzerselektorproxy, an gepasst zum Ersetzen beliebiger der
Benutzeridentifikatorfelder oder einer beliebigen Kombination davon,
durch neue auf einer Einzelbenutzerbasis oder einer Basis einer
Gruppe von Benutzern oder beiden oder auf einer AAA-Serverbasis gibt.
Dazu können
Beziehungen wie die obigen ferner neue Benutzeridentifikatorfelder
enthalten, und der USP Ersatzmittel zum Ersetzen der neuen Benutzeridentifikatorfelder
umfassen.
-
Zusätzlich,
und der Kompatibilität
halber, ist der obige Benutzerselektorproxy zum Kommunizieren mit
einem AAA-Client mit einem Protokoll angepasst, das gemäß RADIUS-
oder DIAMETER-Protokoll-Spezifikationen arbeitet.
-
Somit
kann dieser Benutzerselektorproxy als ein Authentifizierungs-, Autorisierungs-
und Abrechnungsproxy (AAA-Proxy) verwendet werden, mit dem auch
Benutzer, die durch Benutzeridentifikatoren in einem Nicht-NAI-Format
identifiziert werden, unter einer Vielzahl von AAA-Servern angeordnet
werden.
-
Die
Erfindung sieht auch ein Verfahren vor zum Vorsehen von Authentifizierungs-,
Autorisierungs- und Abrechnungs- (AAA-) Diensten in einem Telekommunikationsnetz,
das mit einem Internetdienstanbieter (ISP) gekoppelt ist. Dieses
Verfahren umfasst die Schritte zum Empfangen einer AAA-Dienstanforderung
in einem AAA-Proxy von einem AAA-Client; Extrahieren einer Benutzerdomäne aus einem
empfangenen Benutzeridentifikator, der in der AAA-Dienstanforderung
enthalten ist; Identifizieren in dem AAA-Proxy des AAA-Servers,
der für
den Benutzer verantwortlich ist in dem Internetdienstanbieter- (ISP)
Netz; Vorlegen der AAA-Dienstanforderung von dem AAA-Proxy zu dem
AAA-Server; Empfangen der entsprechenden AAA-Dienstantwort in dem
AAA-Proxy von dem AAA-Server; und Rückgeben der AAA-Dienstantwort
von dem AAA-Proxy zu dem AAA-Client, der die Anforderung ausgegeben hat.
In dieser Hinsicht wird mindestens die Kommunikation zwischen dem
AAA-Proxy und dem AAA- Client
mit einem Protokoll ausgeführt,
das gemäß RADIUS-
oder DIAMETER-Protokoll-Spezifikationen arbeitet.
-
Ferner
umfasst der Schritt zum Identifizieren in einem AAA-Proxy des AAA-Servers,
der für
einen angezeigten Benutzer verantwortlich ist, die Schritte zum
Analysieren des empfangenen Benutzeridentifikators, in entweder
einem strukturierten oder unstrukturierten Format, um zu bestimmen,
ob alle Benutzeridentifikatorfelder oder ein Benutzer-Name allein
oder die Benutzerdomäne
allein oder eine beliebige Kombination davon zur Auswahl eines AAA-Servers
genommen werden, der für
diesen Benutzer verantwortlich ist; und Auswählen eines AAA-Servers, der
für den
Benutzer verantwortlich ist in einem Internetdienstanbieter- (ISP)
Netz.
-
Um
die Effizienz des obigen Verfahrens zu verbessern, ein vorheriger
Schritt zum Speichern in dem AAA-Proxy auf Einzelbenutzerbasis oder
auf Basis einer Gruppe von Benutzern oder beiden mindestens einen
Identifikator für
jeden mindestens einen AAA-Server, der für einen gegebenen einzelnen Benutzer
oder eine Gruppe von Benutzern verantwortlich ist.
-
Das
Verfahren umfasst auch den vorteilhaften Schritt zum Ersetzen in
dem AAA-Proxy beliebiger der Benutzeridentifikatorfelder, oder einer
beliebigen Kombination davon, durch neue auf einer Einzelbenutzerbasis
oder auf einer Basis einer Gruppe von Benutzern oder beiden oder
auf einer AAA-Serverbasis.
-
Die
Erfindung sieht somit ein System vor, das ein Telekommunikationsnetz
umfasst, das mit einem Internetdienstanbieter- (ISP) Netz über einen Netzzugangserver
(NAS) gekoppelt ist, wobei der obige Benutzerselektorproxy (USP),
der als ein verbesserter AAA-Proxy agiert, der Eingangspunkt zu
dem ISP-Netz ist, wobei der NAS somit mit dem USP zusammenarbeitet.
-
KURZE BESCHREIBUNG DER
ZEICHNUNGEN
-
Die
Merkmale, Ziele und Vorteile der Erfindung werden durch Lesen dieser
Beschreibung in Verbindung mit den begleitenden Zeichnungen offensichtlich,
in denen:
-
1 eine
Teilansicht einer aktuellen Netzarchitektur darstellt, die zeigt,
wie ein Client Internetdienstanbieter- (ISP) Netze für einen Authentifizierungs-,
Autorisierungs- und
Abrechnungs (AAA-) Dienst auffordert, wobei ein erstes ISP-Netz
einen AAA-Server pro Domäne
hat und ein zweiter ISP Domänen
nicht unterscheidet;
-
2 eine
relevante Teilansicht einer Netzarchitektur gemäß der Erfindung darstellt,
wo ein Client ISP-Netze für
AAA-Dienste auffordert,
beide ISP-Netze mit einer Vielzahl von AAA-Servern zum Anordnen
von Benutzern, und mit einem Benutzerselektorproxy als Eingangspunkt
zu jedem ISP-Netz;
-
3 eine
Anwendung des Benutzerselektorproxy schematisch zeigt, der mit einem
AAA-Client und mit einem bestimmten AAA-Server durch Verwenden des RADIUS-Protokolls
zusammenarbeitet;
-
4 im
wesentlichen einen Nachrichtenfluss für die Herstellung von Sicherheitsverbindungen
zwischen einem AAA-Client
und einem Benutzerselektorproxy, und zwischen dem Benutzerselektorproxy
und einem bestimmten AAA-Server zeigt;
-
5a eine
beispielhafte Benutzeranordnungstabelle zeigt, die Beziehungen zwischen
Benutzern, einer Gruppe von Benutzern und dem mindestens einen AAA-Server
zeigt, der für
jeden Benutzer oder Gruppe von Benutzern verantwortlich ist;
-
5b,
im Gegensatz dazu, die konventionelle Anordnung von Benutzern auf
einer Basis pro Domäne
unter mehreren AAA-Servern zeigt, wobei jeder AAA-Server für eine Benutzerdomäne verantwortlich
ist
-
6 eine
Ausführungsform
eines Benutzerselektorproxy zeigt, der Weiterleitungsmittel und Protokollmittel
getrennt von und in Zusammenarbeit mit Verarbeitungsmitteln umfasst.
-
DETAILLIERTE
BESCHREIBUNG VON BEVORZUGTEN AUSFÜHRUNGSFORMEN
-
Gewöhnlich ist
ein AAA-Proxy zum Empfangen von AAA-Dienstanforderungen von einem AAA-Client
angepasst. Der Begriff AAA-Client
ist eine generische Form, wohingegen insbesondere ein Netzzugangserver
(NAS) für
ein Telekommunikationsnetz, der auf einen Internetdienstanbieter
(ISP) zugreift, in der Tat ein AAA-Client sein kann. In Übereinstimmung
mit 1 ist ein generischer AAA-Client (4)
mit ersten und zweiten Internetdienstanbietern (ISP-1, ISP-2) zum
Erteilen von Zugriff zu dem Internet (6) gekoppelt. Ein
derartiger AAA-Client (4) kann ein NAS sein, der mit einem
Telekommunikationsnetz mit unterschiedlichen Benutzeridentifikatoren
für unterschiedliche
Zwecke verbunden ist. In dieser typischen Architektur kann ein ISP
(ISP-1), der Benutzeridentifikatoren in der NAI-Form behandelt, mit expliziter Angabe
eines Bereichs oder einer Domäne,
seine Benutzer unter mehreren AAA-Servern (1, 2)
anordnen, wobei jeder AAA-Server für eine bestimmte Domäne verantwortlich
ist. Ein derartiger ISP (ISP-1) kann auch einen AAA-Proxy (5)
zum Bestimmen haben, welcher bestimmte AAA-Server (1, 2) für einen
gegebenen Teilnehmer in einer Domäne für Authentifizierungs-, Autorisierungs-
und Abrechnungsdienste verantwortlich ist. Andererseits kann ein
ISP (ISP-2), der
Benutzeridentifikatoren in einem anderen Format als der NAI-Form
behandelt, entweder strukturiert oder unstrukturiert, keinerlei
Vorteil aus einer Zwischenstellung eines derartigen AAA-Proxy zum
Zugreifen auf seinen eindeutigen AAA-Server (3) ziehen.
Darum ist der AAA-Proxy typischerweise in einem ISP-Netz enthalten,
wo eine Vielzahl von AAA-Servern existiert, wobei jeder AAA-Server
für eine
gewisse Domäne
verantwortlich ist, an Stelle davon, ein Teil des Telekommunikationsnetzes
oder ein Teil eines Zugangsnetzes zu sein. Außerdem ist ein derartiger AAA-Proxy
(5) somit in der Lage, die interne ISP- (ISP-1) Topologie
vor seinen zusammenarbeitenden AAA-Clients zu verbergen.
-
Das
Folgende beschreibt gegenwärtig
bevorzugte Ausführungsformen
von Mitteln, Verfahren und System zum Erlauben einer ausgeglichenen
Anordnung von Benutzern unter einer Vielzahl von AAA-Servern unabhängig von
Benutzeridentifikatorschemata, Strukturen und anwendbarem Dienst.
In Übereinstimmung
mit einem Aspekt der vorliegenden Erfindung ist ein Benutzerselektorproxy
(hierin nachstehend als USP bezeichnet) vorgesehen zum Agieren als
ein aufgerüsteter
AAA-Proxy und somit Empfangen von AAA-Dienstanforderungen von einem AAA-Client,
der einen ISP mit einer Vielzahl von AAA-Servern adressiert, die
für ausgeglichene
Anordnungen von Benutzern verantwortlich sind.
-
Wie
in 2 gezeigt, umfasst der Internetdienstanbieter
(ISP-1, ISP-2) eine Vielzahl von AAA-Servern (11, 12, 13, 21, 22, 23)
derart, dass sie durch einen USP (10, 20) adressiert
werden, der wiederum mit einem AAA-Client (4) verbunden
ist. D.h. jeder Internetdienstanbieter (ISP-1) (ISP-2) hat seine Benutzer
unter einer Vielzahl von AAA-Servern (11, 12, 13)
(21, 22, 23) in seinem eigenen ISP-Netz
angeordnet, wobei somit der USP von jedem ISP-Netz zum Analysieren
der Benutzeridentifikatoren verantwortlich ist, die in den Dienstanforderungen
enthalten sind, die von dem AAA-Client (4) empfangen werden.
-
Deshalb
umfasst der USP (10, 20) Verarbeitungsmittel,
um alle Benutzeridentifikatorfelder oder einen Benutzer-Namen allein
oder die Benutzerdomäne
allein oder eine Kombination davon zu analysieren, um die Weiterleitung
der AAA-Dienstanforderung, die von einem AAA-Client empfangen wird,
zu einem spezifischen AAA-Server durchzuführen, der für den entsprechenden Benutzer
verantwortlich ist.
-
Zusätzlich zu
den obigen Verarbeitungsmitteln ist der USP auch mit einer internen
Datenbankstruktur, oder allgemeiner gesagt, einem Speicher zum Speichern
von mindestens einem Identifikator für jeden mindestens einen AAA-Server
versehen, der für
einen gegebenen einzelnen Benutzer oder eine Gruppe von Benutzern
verantwortlich ist. Dies stellt sicher, dass mindestens ein AAA-Server
für einen
bestimmten Teilnehmer oder eine Gruppe von Teilnehmern verantwortlich
sein kann.
-
Außerdem könnte in Übereinstimmung
mit einem anderen Aspekt der vorliegenden Erfindung mehr als ein
AAA-Server einem beliebigen bestimmten Benutzer für Redundanz
oder Lastaufteilungszwecke zugewiesen sein, was zusätzliche
und unerwartete Vorteile gegenüber
klassischen ISP-Netzen bietet. Es kann ein AAA-Server unter einer
Vielzahl von möglichen
AAA-Servern ausgewählt
werden, abhängig
z.B. von einem Verfügbarkeitsstatus,
einem Lastaufteilungsstatus, einem zusätzlichen Prioritätsfeld,
durch sequenzielle Kommunikationen oder andere Auswahlkriterien.
-
In Übereinstimmung
mit noch einem anderen Aspekt der vorliegenden Erfindung wird im
Fall, dass kein bestimmter AAA-Server für einen Benutzer oder eine
Gruppe von Benutzern bestimmt werden kann, die AAA-Dienstanforderung
sanft verworfen, um Angriffe von Dienstverweigerung (DOS, Denial
Of Service) auszuschließen.
Dies bietet auch einen unerwarteten vorteilhaften Schutz für das ISP-Netz.
-
In
dieser Hinsicht zeigen 5a bzw. 5b die
logische Beziehung und andere Daten, die der USP gemäß der Erfindung
und ein traditioneller AAA-Proxy umfassen. Als Vergleich umfasst
ein Speicher (51), der in dem USP (10, 20)
enthalten ist, relevante AAA-Serverdaten für mindestens einen AAA-Server,
der für
spezifische Benutzer oder eine Gruppe von Benutzern verantwortlich
ist, wohingegen ein klassischer AAA-Proxy lediglich die AAA-Serveradressen
in Domänenprämissen speichert
(52). Ferner umfasst der Speicher (51), der in dem
USP enthalten ist, auch modifizierte Attribute, wie etwa einen neuen
Bereich oder einen neuen Benutzer-Namen oder neue Benutzeridentifikatorfelder oder
Kombinationen davon zum Ersetzen der empfangenen. Derartige Modifikationsdaten
treffen auch pro einzelnem Benutzer ebenso wie pro Gruppe von Benutzern
zu.
-
Genauer
wird eine Ausführungsform
der vorliegenden Erfindung in 5a veranschaulicht,
wo eine mögliche
Benutzeranordnungstabelle (51) in einem USP präsentiert
wird. Der interessierte Leser kann in dieser Tabelle erkennen, dass
unterschiedliche Benutzer von unterschiedlichen Domänen (Bereich.Nummer)
vorhanden sind, wobei einige von ihnen gruppiert sind (Gr-Nummer),
wohingegen andere auf individueller Basis verbleiben. Wo Benutzer
von unterschiedlichen Domänen
gruppiert sind, ist somit der mindestens eine AAA-Server, der für alle Benutzer
in einer Gruppe verantwortlich ist, auf einer Gruppenbasis an Stelle
von einer individuellen Basis markiert. Andererseits sind Benutzer,
die nicht gruppiert sind, einzeln mindestens einem AAA-Server zugewiesen,
der für
jeden Benutzer verantwortlich ist auf einer individuellen Basis.
Außerdem
kann jedem bestimmten Benutzer ein neuer Benutzer-Name oder ein neuer
Bereich zum Ersetzen des empfangenen gegeben werden, bevor die AAA-Dienstanforderung zu
dem geeigneten AAA-Server gelenkt wird. Sowohl Benutzern als auch
Grup pen kann des weiteren ebenso ein neuer Bereich zum Ersetzen
des empfangenen gegeben werden.
-
Diese
und andere beispielhafte Anordnungen können zum Erlauben einer ausgeglichenen
Anordnung von Benutzern unter einer Vielzahl von AAA-Servern abhängig von
unterschiedlichen Kriterien unter Prämissen des Internetdienstanbieters
als Beispiel angeführt
werden. Von einem Durchschnittsfachmann wird erwartet, andere Ausführungsformen vorzuschlagen,
die sich von dem obigen Ansatz nicht wesentlich unterscheiden und
somit in dem Bereich der vorliegenden Erfindung beinhaltet sind.
-
Der
in 2 gezeigte USP (10, 20) empfängt somit
den Verkehr, der von der Seite des AAA-Clients (4) generiert
wird und lenkt ihn zu dem entsprechenden AAA-Server (11, 12, 13)
(21, 22, 23), der für den gegebenen Teilnehmer
aktiv ist und zu dem anwendbaren Internetdienstanbieter (ISP-1)
(ISP-2) gehört.
-
Deshalb
empfängt
ein bestimmter USP (10, 20), wie in 6 gezeigt,
eine beliebige AAA-Dienstanforderung von einem AAA-Client für einen
angezeigten Benutzer durch Protokollmittel (50). Dann extrahiert
das Verarbeitungsmittel (53) alle relevanten Benutzeridentifikatorfelder,
die in Zusammenarbeit mit dem internen Datenbankspeicher (51) analysiert
werden, um zuerst zu bestimmen, ob ein beliebiges bestimmtes Benutzeridentifikatorfeld,
oder Kombinationen davon, durch gegebene neue Benutzeridentifikatorfelder
für den
angezeigten Benutzer ersetzt werden müssen oder nicht. Und zweitens
bestimmt das Verarbeitungsmittel (53) wahrscheinlich in
Zusammenarbeit mit dem Weiterleitungsmittel (54) eine Adresse
eines bevorzugten mindestens einen AAA-Servers, der für den Benutzer
verantwortlich ist, wo die AAA-Dienstanforderung hin gelenkt wird.
Ein interessierter Leser kann erkennen, dass das Weiterlei tungsmittel
als ein Teil des Verarbeitungsmittels enthalten sein kann, ohne
das erwartete technische Verhalten wesentlich zu ändern.
-
Z.B.
kann in einem Telekommunikationsnetz, wie einem GPRS-Netz, ein Netzzugangserver
(NAS) zum Zugreifen auf ein ISP-Netz
verwendet werden, was dem GPRS-Benutzern Zugang zu dem Internet-Netz
gibt. Ein derartiger NAS agiert dann als ein AAA-Client, der AAA-Dienstanforderungen
zu einem Benutzerselektorproxy (USP) in Übereinstimmung mit der Erfindung
ausgibt. Die Kommunikation zwischen dem USP und dem NAS kann mit
einem Protokoll ausgeführt
werden, wie z.B. RADIUS oder DIAMETER, wobei ein Benutzer durch
seine oder ihre MSISDN identifiziert wird.
-
Das
in 3 gezeigte Sequenzdiagramm ist ein veranschaulichendes
Beispiel des Verfahrens zum Anfordern eines AAA-Dienstes, wo das verwendete Protokoll
RADIUS ist. Der NAS gibt eine RADIUS-Zugangsanforderung, die den
Benutzeridentifikator enthält,
zu dem Benutzerselektorproxy aus. Eine derartige Anforderung wird
letztlich durch das Verarbeitungsmittel (53) behandelt,
das in dieser bevorzugten Ausführungsform
das Protokollmittel (50) und das Weiterleitungsmittel (54)
umfasst, die in 6 als getrennte logische Entitäten bezeichnet
sind. Das Verarbeitungsmittel (53) befragt (S-31) eine
interne Datenbank (51) in dem Benutzerselektorproxy, um eine
Adresse zum Lenken der RADIUS-Zugangsanforderung zu dem geeigneten
AAA-Server zu erhalten, der für
diesen Benutzer verantwortlich ist. Die interne Datenbank antwortet
(S-32) dem Verarbeitungsmittel mit einer derartigen AAA-Serveradresse, und
optional einem neuen Benutzeridentifikator (Benutzeridentifikator
bis). Schließlich
leitet das Verarbeitungsmittel die empfangene RADIUS-Zugangsanforderung
mit dem anwendbaren Benutzeridentifikator zu dem AAA-Server.
-
Vorausgesetzt,
dass eine Ausführungsform des
USP, wie in 6 veranschaulicht, für eine Verwendung
in dem vorangehenden Fall bevorzugt wird, wird die RADIUS-Zugangsanforderung
in dem Verarbeitungsmittel über
Protokollmittel (50) empfangen. Ferner wird die Adresse
eines geeigneten AAA-Servers, zurückgegeben (S-32) von der internen
Datenbank (51), durch das Verarbeitungsmittel wahrscheinlich
in Zusammenarbeit mit dem Weiterleitungsmittel (54) bestimmt.
Schließlich
wird die RADIUS-Zugangsanforderung von dem Verarbeitungsmittel (53) über Protokollmittel
(50) zu dem AAA-Server gerichtet.
-
Es
sollte vermerkt werden, dass die Verkehrsflüsse zwischen dem AAA-Client
(4) und dem Benutzerselektorproxy (10, 20)
unabhängig
von den Verkehrsflüssen
zwischen dem Benutzerselektorproxy (10, 20) und
den AAA-Servern (11, 12, 13) (21, 22, 23)
sind. Folglich stellt der AAA-Client (4), falls erforderlich,
Sicherheitsbeziehungen oder Sicherheitsverbindungen mit dem Benutzerselektorproxy
(10, 20) her, wobei somit die Existenz der AAA-Server
(11, 12, 13) (21, 22, 23)
in einem bestimmten ISP-Netz (ISP-1, ISP-2) aus Sicht einer Sicherheitsverbindung vollständig verborgen
wird.
-
In
dieser Hinsicht zeigt 4 eine Sicherheitsverbindungsherstellung
in Übereinstimmung
mit einem Aspekt der Erfindung. Ein AAA-Client, der insbesondere
ein Netzzugangserver (NAS) zum Zugreifen zu oder von einem Telekommunikationsnetz
sein kann, gibt eine Sicherheitsverbindungsanforderung, die einen
Benutzeridentifikator enthält,
zu dem Benutzerselektorproxy aus. Eine derartige Anforderung wird
durch das Verarbeitungsmittel (53), das das Protokollmittel
(50) enthalten kann, und das Weiterleitungsmittel (54),
veranschaulicht in 6, behandelt, oder kann einer
alternativen Ausführungsform
folgen, wie in 3 erläutert, obwohl nicht weiter
dargestellt. Das AAA-Proxymittel befragt (S-41) eine interne Datenbank
in dem Benutzerselektorproxy, um eine Adresse zum Lenken der Sicherheitsverbindungsanforderung
zu dem geeigneten AAA-Server zu erhalten, der für diesen Benutzer verantwortlich
ist. Die interne Datenbank antwortet (S-42) dem AAA-Proxymittel mit der
AAA-Serveradresse, und der AAA-Proxy leitet die empfangene Sicherheitsverbindungsanforderung
zu dem AAA-Server weiter.
-
Die
Erfindung wird oben in Verbindung mit verschiedenen Ausführungsformen
auf eine nicht einschränkende
Art und Weise, sondern lediglich veranschaulichend beschrieben.
Ein Durchschnittsfachmann kann diese Ausführungsformen modifizieren, ohne
wesentlich von dem Bereich abzuweichen, der durch die folgenden
Ansprüche
definiert wird.