-
Die
Erfindung betrifft eine Vorrichtung und ein Verfahren zur Vermittlung
und Beantwortung von AAA-Anfragen (Authentifizierung, Autorisierung
und Accouting) für
eine Nutzungsinstanz in verteilten DV-Architekturen (Datenverarbeitungs-Architekturen)
auf Basis von Rohdaten aus verteilten DV-Quellsystemen.
-
Gebiet
der Erfindung:
-
Die
Spezialisierung von Anbietern von Dienstleistungen bzw. Gütern, deren
Angebote über verteilte
Systeme (z.B. Internet) zugänglich
sind, auf ihre Kernkompetenz der Leistungserbringung bzw. Auslieferung
führt dazu,
dass sie gezwungen sind, sich externen Quellen zur Authentifizierung
und Autorisierung ihrer Nutzer bzw. Käufer zu bedienen. Authentifizierung,
Autorisierung und Zugriffskontrolle sind essenziell für die meisten
Internet-Dienstleister. Dies ist notwendig, wenn der Dienst selber
nicht für jeden
Nutzer offen zugänglich
sein soll, bzw. wenn eine Bezahlung notwendig ist, und wenn der
Dienst selber die Daten zur Autorisierung nicht hält.
-
Heutige
Verfahren z.B. im Umfeld von ISPs (Internet Service Providern) zur
Authentifizierung und Autorisierung basieren meist auf dem RADIUS
(Remote Authentication-Dial-In Service) Protokoll und bieten den
Zugang zu Diensten, die zentralisiert die Administration und Validierung
von Authentifizierungs- und Autorisierungsinformationen für einen Nutzernamen
zur Verfügung
stellen.
-
Heutige
Verfahren bieten den Anbietern von Dienstleistungen bzw. Gütern die
Möglichkeit,
sich zu verschiedenen ISPs oder Account-Providern zu verbinden.
Diese Account-Provider bieten auf Basis unterschiedlicher Protokolle,
proprietäre
Schnittstellen und Datenobjekte Informationen über die Authentifizierbarkeit
und Autorisierbarkeit von Nutzern. Dabei ist es die Aufgabe des
Anbieters von Dienstleistungen und Gütern, sich an die Schnittstellen
der Account-Provider anzupassen, was zu starken Aufwendungen in
der Entwicklung und Pflege von Schnittstellen führt, sofern der Dienstleister
seine Leistung oder Güter
den Nutzern mehrerer Account-Providern anbieten
möchte.
Je Kunden- und vertragsführenden Mandanten [m1](OSS/BSS) des Account-Providers muss
das verarbeitende DV-System des Dienstleisters die Quelldaten unterschiedlich
hinsichtlich der Autorisierungsinformation bearbeiten und bewerten. Darüber hinaus
hat der Dienstleister je nach Datenmodell und Informationsgehalt
des Account-Providers
verschiedene Logiken zur Auswertung der gelieferten Informationen
zu implementieren, um daraus eine Aussage über die Autorisierung für einen
Nutzer treffen zu können.
Oftmals führt
dies zu zusätzlichen und
unnötigen
Systembelastungen des Dienstleisters, da seine Technologie nicht
auf eine performante Abwicklung von Autorisierungsfragen an verteilte Quellsysteme
von Account-Providern ausgelegt ist, sondern sich auf die Leistungserbringung
konzentriert. Dies kann dazu führen,
dass ein Nutzer umständliche
Verfahren zur Authentifizierung und Autorisierung durchlaufen muss
und dabei z.B. für
das Medium Internet ungewohnt lange Wartezeiten oder Abfragedialoge
in Kauf nehmen muss.
-
Unter
dem Aspekt der Sicherheit und Vertrauenswürdigkeit müssen sich die Systeme des Diensteanbieters
und des Account-Providers
in den bisherigen Verfahren direkt gegeneinander Authentifizieren
und Autorisieren (z.B. Austausch von Credentials wie UN/PW oder
Zertifikaten). Dies bedeutet ggf. für den Dienstleister und den
Account-Provider eine systemseitige technische Integration je Anbindung.
-
In
der „Liberty
Alliance" wird ein
Rahmenwerk bzgl. Schnittstellen und grundlegenden Kommunikationslogiken
zwischen verteilten Systemen definiert. Dieser Standard bildet die
Grundlage für
ein mögliches
Verfahren zur Authentifizierung (z.B. Single Sign On) von Nutzungsinstanzen
in föderierenden Netzwerken.
Die Autorisierung und die Herbeiführung positiver Antworten ist
in diesem Standard nicht bearbeitet. Dem liegt zu Grunde, dass sich
Liberty Alliance im Gegensatz zu dem hier beschrieben Verfahren
nicht mit der Prozesslogik zu möglichen
kunden- und vertragsführenden
Backend Systemen und dessen technische und optimierte Abbildung
auf Systeme beschäftigt.
Dies ist eine große
Herausforderung, um neben den Schnittstellen in die föderative Welt
der Liberty Alliance kompatiblen Partner die Einbindung unterschiedlicher
Backendsysteme mit Autorisierungsinformationen zu verwirklichen.
-
Überblick über die
Erfindung
-
Da
immer mehr Mehrwertdienste über
das Internet angeboten werden, wird es immer wichtiger, eine Vorrichtung
und ein Verfahren anzubieten, die die Komplexität verringert, die Wiederverwendbarkeit steigert,
Schnittstellen reduziert und Datenverarbeitung in spezialisierte
Systeme verlagert. Das Verfahren über eine Vermittlerinstanz,
die auf die Verarbeitung von Autorisierungsanfragen, sowie Abfrage
und Bearbeitung von Autorisierungsrohdaten aus verteilten Quellsystemen
optimiert ist, verringert die Durchlaufzeit für den Prozess der Autorisierung.
Zusätzlich wird
dem Diensteanbieter und dem Accountprovider ein verlässliches
System zur Verfügung
gestellt, das eine sichere Kommunikation ermöglicht und eine geringe Ausfallquote
sichert und dies unter Berücksichtigung
geringerer Implementierungs- und Wartungsaufwendungen für den Händler/Dienstleister.
Die erhöhte
Performance wird dadurch erreicht, dass die Schnittstellen zu den
Account-Providern und die Kenntnis und Verarbeitung deren Datenstrukturen zentral
im DV-Vermittlersystem
durch ein eigenes Objektmodell optimiert wird. Dadurch werden die System-Ressourcen
des Dienstleisters entlastet und die Verarbeitung auf dem spezialisierten
DV-Vermittlersystem
effizienter durchgeführt.
-
Die
Erfindung betrifft eine Vorrichtung und ein Verfahren zur Vermittlung
und Beantwortung von AAA-Anfragen, insbesondere Autorisierungs- und/oder
Authentifizierungsanfragen für
eine Nutzungsinstanz in verteilten DV-Architekturen (Datenverarbeitungs-Architekturen)
auf Basis von Rohdaten aus verteilten DV-Quellsystemen.
-
Fragt
z.B. eine Nutzungsinstanz bei einem DV-System eine Leistung oder
die Auslieferung eines Guts nach, so ist von dem DV-System vor der
Leistungserbringung bzw. Auslieferung zu prüfen, ob die Nutzungsinstanz über die
dafür notwendigen
Berechtigungen (Merkmale zur Autorisierung) verfügt. Das Ergebnis einer Autorisierungsanfrage
liefert dem anfragenden DV-System die Information, ob es für eine bestimmte
Nutzungsinstanz berechtigt ist, die angeforderte Dienstleistung
zu erbringen oder ein Gut auszuliefern. So kann z.B. bei einem Musikverkaufsportal
die Nutzungsinstanz ein Web-Frontend sein, dass dem Benutzer eine
Vielzahl von MPEG- Songs anbietet.
Der Benutzer beabsichtig nun einen dieser Songs zu erwerben. Hierzu
muss durch das anfragende DV-System überprüft werden, ob der Benutzer berechtigt
ist.
-
Diese
anfragenden DV-Systeme, die eine Autorisierungsanfrage für eine Nutzungsinstanz
teilen, sprechen dazu über
eine einheitliche Schnittstelle ein DV-Vermittlersystem an. Die
Nutzungsinstanz wird dann über
einen sog. „redirect" von dem anfragenden
DV-System an das DV-Vermittlersystem übergeben. Dort wird meist zunächst eine
Authentifizierung für
die Nutzungsinstanz durchgeführt,
damit der Prozess der Autorisierung eingeleitet werden kann. Für das og.
Beispiel bedeutet dies, dass durch das Vermittlersystem ein Link
mit einer eindeutigen Kennung, wie z.B. einer Transaktions-ID, zurückgegeben
wird, die dann durch das anfragende System an den Browser des Benutzers
weitergeleitet wird, der dadurch auf das Vermittlersystem umgelenkt wird,
um dort die Autorisierung zu vervollständigen.
-
Das
DV-Vermittlersystem kennzeichnet sich durch ein eigenes Objektmodell,
eigene Datenstrukturen und eigene Datenverarbeitung zur Prüfung der Autorisierung
anhand vorhandener Rohdaten, die den Nutzungsinstanzen aus den DV-Quellsystemen zugeordnet
sind. Diese Rohdaten werden vom DV-Vermittlersystem aus den DV-Quellsystemen
abgefragt und im DV-Vermittlersystem
kombiniert und geprüft.
Liegen die Rohdaten nicht vollständig
vor, so kann die Nutzungsinstanz an weitere DV-Systeme übergeben
werden, um dort über
geschäftsvorfallspezifische
Prozesse notwendige Rohdaten in die Quellsysteme eintragen zu lassen
(nach dem Prinzip: „Herbeiführung positiver
Antworten"). Alternativ
kann die Nutzungsinstanz auch an ein weiteres DV-Vermittlersystem übergeben
werden, sofern dort eine Beantwortung der Autorisierungsanfragen
erwartet werden kann. Aus der Kombination der Rohdaten der DV-Quellsysteme
wird schließlich
die Antwort für
das anfragende DV-System erzeugt.
-
Nach
der Erzeugung des Autorisierungsergebnisses kann die Nutzungsinstanz
vom DV-Vermittlersystem wiedererkannt und den ursprünglichen, offenen
Autorisierungsanfragen zugeordnet werden. Dies kann z.B. in einer
konkreten technischen Abbildung auf der Basis von Zertifikaten oder
Cookies erfolgen, die auf den Systemen abgelegt werden. Die Nutzungsinstanz
wird vom Vermittlersystem wieder durch einen „redirect" zum anfragenden DV-System übergeben.
Das anfragende DV-System kann das Ergebnis der Anfrage beim DV-Vermittlersystem über die
Standardschnittstelle abfragen, und die Nutzungsinstanz die Nutzung
einer Dienstleistung oder die Auslieferung eines Gutes durchführen.
-
Im
Detail können
bei einer möglichen
Ausführungsform
die Schritte wie folgt aussehen:
Bei der Vorrichtung und dem
entsprechenden Verfahren zur Bereitstellung von Vermittlung und
Beantwortung von Autorisierungsanfragen für eine Nutzungsinstanz und
mindestens einen Service in verteilten DV-Architekturen, wobei die
Nutzungsinstanz und der Service mit der Möglichkeit ausgestattet sind, sich
mit einem gewöhnlichen
Computernetzwerk zu verbinden, werden folgende Schritte durch ein
oder mehrere DV-Vermittlersysteme durchgeführt.
- – Entgegennahme
einer Autorisierungsanfrage von einem anfragenden DV-System;
- – Übergabe
von Zielparametern für
die Nutzungsinstanz an das anfragende DV-System für einen Redirect
durch die Nutzungsinstanz. Es ist auch denkbar, dass das Vermittlersystem
die Nutzungsinstanz direkt kontaktiert, wenn vorher die Adresse
mitgeteilt wurde;
- – Entgegennahme
der Nutzungsinstanz und Zuordnung der Nutzungsinstanz zur Transaktion
der Autorisierungsanfrage;
- – Überprüfung der
Vollständigkeit
der
-
Authentifizierungsinformationen
der Nutzungsinstanz und ggf. Übergabe
an Systeme zur Authentifizierung und anschließenden Entgegennahme der Nutzungsinstanz.
Dies kann immer dann auftreten, wenn die Nutzungsinstanz dem DV-Vermittlersystem
zwar bekannt ist, aber für
die Anforderungen des anfragenden DV-Systems nicht hinreichend authentifiziert
(d.h. die "Vollständigkeit
der Authentifizierungsinformationen" ist im Sinne der Güte nicht gegeben), so wird
versucht, die Nutzungsinstanz z.B. gemäß Liberty Alliance oder beliebiger
anderer Verfahren hinreichend zu authentifizieren. (Dabei können weitere
Systeme zur Abwicklung der Authentifizierung genutzt werden bzw.
die Nutzungsinstanz an diese zum Zwecke der Authentifizierung übergeben werden.)
-
Ist
die Nutzungsinstanz nicht authentifizierbar (d.h. die "Vollständigkeit
der Authentifizierungsinformationen" ist im Sinne nicht vorliegender Informationen überhaupt
nicht gegeben), kann sie vom DV-Vermittlersystem in einen Registrierungsprozess mit
einem beliebigen System geführt
werden. Anschließend
ist die Nutzungsinstanz authentifizierbar und evtl. sind auch Daten
zur Autorisierung eingerichtet worden.
- – Prüfung der
Zuordenbarkeit der Nutzungsinstanz zu Backend-Systemen und ggf. Übergabe der Nutzungsinstanz
an Drittsysteme zur Generierung von Autorisierungsinformationen
und anschließende
Entgegennahme der Nutzungsinstanz;
- – Identifizierung
der für
die Nutzungsinstanz zuständigen
Backend-Systeme mit Informationen zur Autorisierung Anfrage von
Profilen und Rechten zu der Nutzungsinstanz an die Backend-Systeme;
- – Empfang
von Profildaten und Rechten zu der Nutzungsinstanz aus den Backend-Systemen;
- – Kombination
der Profildaten und Rechte mit den Anforderungen des anfragenden-DV-Systems
- – Bestimmen
von Autorisierungsergebnissen und ggfs. Bestimmen von alternativen
Möglichkeiten für die Generierung
von weiteren Autorisierungsinformationen, falls diese notwendig
sein sollten, und ggf. Übergabe
der Nutzungsinstanz an Drittsysteme zur Generierung von Autorisierungsinformationen
und anschließende
Entgegennahme der Nutzungsinstanz;
- – Erneute
Identifizierung der für
die Nutzungsinstanz zuständigen
Backend-Systeme mit Informationen zur Autorisierung;
- – Anfrage
von Profilen und Rechten zu der Nutzungsinstanz an die alternativen
Backend-Systeme;
- – Empfang
von Profildaten und Rechten zu der Nutzungsinstanz aus den alternativen
Backend-Systemen;
- – Kombination
der Profildaten und Rechte mit den Anforderungen des anfragenden
DV-Systems;
- – Bestimmen
von Autorisierungsergebnissen und Zuordnung zur Transaktion des
anfragenden Systems;
- – Übergabe
von Zielparametern für
das anfragende System an die Nutzungsinstanz; somit erfolgt die
aggregierte Übergabe
von definierten Informationen (Zielparametern) an das anfragende
System. (Zielparameter sind hierbei nicht unbedingt Parameter über das
Ziel, sondern eher die Werte, die durch das Verfahren dem anfragenden
System zur Verfügung
gestellt werden;
- – Entgegennahme
von Ergebnisanfragen durch das anfragende System, Auslieferung des
Ergebnisses und weiterer Informationen aus der Anfrage an das Back-End-System
an das anfragende System.
-
Mit
dem hier beschriebenen Verfahren wird die Performance für die Durchführung von
Autorisierungsanfragen durch eine zentrale hochperformante Komponente
optimiert und damit Antwortzeiten reduziert. Darüber hinaus wird ebenfalls die
Anzahl der Verfahrensschritte des Gesamtsystems im Vergleich zur
Direktansprache der anfragenden Dienste an die Account-Provider verringert.
Der Anbieter einer Dienstleistung bzw. eines Gutes wird damit unabhängig von
der Vielzahl der physikalischen Schnittstellen zu den Account-Providern.
-
Im
Gegensatz zu einer Middleware beherrscht die hier beschriebene Vorrichtung
und das dazugehörige
Verfahren nicht lediglich die Vermittlung zwischen unterschiedlicher
Software. Die hier beschriebene Technologie verwendet eigene Datenmodelle,
die es erlauben, zusammen mit eigenen Abfrage-, Kombinations-, und
Prüfmechanismen
eine Autorisierungsanfrage optimiert zu beantworten und gegebenenfalls
notwendige Zwischenprozesse einzuleiten.
-
Die
Vorrichtung und das Verfahren zur Vermittlung und Beantwortung von
Autorisierungsanfragen für
eine Nutzungsinstanz in verteilten DV-Architekturen ist gekennzeichnet
durch die im Folgenden beschriebenen Systeme.
-
Die
Nutzungsinstanz bezeichnet eine Person, eine Namensentität (Gruppenbezeichnung) oder
Maschine, die ein anderes DV-System, z.B. einen Internet Shop, Internetdienst
oder Netzelement nutzen möchte.
Im Falle einer Person bedeutet dies z.B., dass diese einen Computer
nutzt, auf dem sie Applikationen zur Nutzung anderer DV-Systeme
verwendet. Dieses können
Standardapplikationen wie ein Webrowser oder andere Applikationen
sein. Im Falle einer Maschine nutzt diese direkt weitere Systeme.
Eine solche Maschine kann beispielsweise ein Computer (PC, Set-Top
Box, mobiles Endgerät
mit SIM, etc.) sein, der eigene Authentifizierungsmerkmale besitzt,
die auf ihm hinterlegt wurden.
-
Die
Nutzungsinstanz verfügt über Funktionen
zur Anfrage auf Auslieferung eines Gutes oder Erbringung einer Dienstleistung
durch ein DV-System. Zur Kommunikation werden dabei adäquate standardisierte
Schnittstellenprotokolle eingesetzt, z.B. HTTP, FTP, POP3, IMAP,
SMTP (ggf. in Kombination mit SSL-Verschlüsselung).
-
Häufig alternativ
verwendete Bezeichnungen sind User, Nutzer, Kunde, Käufer, Verbraucher,
Endkunde, Endgerät.
-
Die
DV-Systeme, die von der Nutzungsinstanz angesprochen werden, werden
als anfragende DV-Systeme bezeichnet.
-
Anfragende
DV-Systeme zeichnen sich dadurch aus, dass sie der Nutzungsinstanz
ein Gut in digitaler Form ausliefern, eine Auslieferung anstoßen oder
den Zugriff der Nutzungsinstanz auf das anfragende DV-System gestatten,
um dort eine Applikation oder ein Netzelement zu nutzen. Gemein
ist diesen Nutzungsszenarien des anfragenden DV-Systems, dass die
erfolgreiche Abwicklung von Auslieferung und Zugriff nur für autorisierte
Nutzungsinstanzen erlaubt ist. Das anfragende System selber verfügt nicht über die
dazu notwendigen Autorisierungsinformationen.
-
Eine
Middleware organisiert dabei den Transport komplexer Daten (sog.
Messaging), vermittelt Funktionsaufrufe zwischen den Komponenten (sog.
Remote Procedure Calls), stellt die Transaktionssicherheit über ansonsten
unabhängige
Teilsysteme her (Funktion als Transaktions-Monitor), etc.
-
Beispiele
für anfragende
DV-Systeme sind Kommunikationsdienste, web-basierte Dienste, Mediendienste,
Netzwerkelemente.
-
Das
anfragende DV-System und die auf diesem integrierte Logik verfügt über die
folgenden Funktionen:
Erbringung einer Dienstleistung oder
Auslieferung eines digitalen Guts an die Nutzungsinstanz;
Austausch
von identifizierenden Datensätzen
(Austausch z.b. von Zertifikaten zur Authentifizierung);
Abfrage
weiterer DV-Systeme (DV-Vermittlersystem);
Übergabe von Parametern zur
Spezifikation der Autorisierungsanfrageüberführung der Nutzungsinstanz an
das DV-Vermittlersystem (redirect).
-
Führen von
Transaktionen; die Nutzungsinstanz sollte nach erfolgter Autorisierung
wieder der ursprünglichen
Anfrage zugeordnet werden können, um
das angeforderte Gut auszuliefern oder den angeforderten Zugriff
auf die Leistungserbringung zu ermöglichen. Die Zuordnung von
Transaktionen innerhalb der einzelnen Systeme erfolgt über den
Austausch von Transaktions-Identifiern,
die eine temporär
gültige-
und eindeutige Zuordnung von Anfragen anderer Systeme zu eigenen
Transaktionen ermöglicht.
-
Mögliche Protokolle
zwischen den Systemen und Instanzen sind z.B. HTTP mit oder ohne SSL-Verschlüsselung.
Darüber
können
via SOAP XML-Nachrichten ausgetauscht werden. Wesentlich ist hierbei
der Austausch der Transaktions-ID, um Prozesse über die Systeme miteinander
zu verknüpfen
und Datenaustausch den Transaktionen der einzelnen Systeme eindeutig
zuzuordnen.
-
Häufig alternativ
verwendete Bezeichnungen sind Service Provider, Dienstanbieter,
ASP (Application Service Provider), Dienst, Internet Service, Shop,
Merchant, Händler,
Anbieter, Verkäufersystem,
Content Provider, Content Aggregator, Netzelement.
-
Das
DV-Vermittlersystem bezeichnet einen Computer, der die Anfragen
des anfragenden DV-Systems entgegennimmt, sofern das anfragende DV-System
diese Anfragen durchführen
darf. Die Logik zur Entgegennahme der Anfragen, der Speicherung,
Wandlung und Interpretation von Datensätzen aus der Anfrage wird durch
die Vermittlerapplikation durchgeführt. Ebenso wird die Logik
zur Abfrage von Daten aus den Quellsystemen und, falls notwendig, die Überführung der
Nutzungsinstanz zur Einrichtung von Rohdaten von der Vermittlerapplikation
durchgeführt.
Alternativ dazu kann das Vermittlersystem die Nutzungsinstanz auch
an weitere DV-Vermittlersysteme überführen, um
dort die Anfrage von Rohdaten aus den dort angebundenen DV-Quellsystemen durchzuführen (Das
dazugehörige
Verfahren zur Ermittlung dieser Daten wird nicht erläutert, da
es Schnittstellen zu einer Vielzahl von System gibt, deren Erläuterung
zu weit führen
würde.
Hierbei tritt dann das erste DV-Vermittlersystem gegenüber dem zweiten
DV-Vermittlersystem als anfragendes DV-System auf. Dazu verfügt das DV-Vermittlersystem
auch über
die Funktionen des anfragenden DV-Systems.).
-
Das
DV-Vermittlersystem und die in der Vermittlerapplikation integrierte
Logik verfügt über Funktionen
zur:
Kommunikation mit weiteren DV-Systemen;
Authentifizierung
von anderen DV-Systemen;
Speicherung von Transaktionsdaten
und Anfragen;
Identifikation der zur Nutzungsinstanz gehörigen Quellsysteme;
Identifikation
der notwendigen Rohdaten;
Kombination und Bewertung von Rohdaten;
Bestimmung
des vorliegenden Geschäftsvorfalls
auf Basis der vorhandenen Informationen aus Anfragedatensatz und
Quellsystemen;
Bestimmung der notwendigen Schritte zur Herbeiführung einer
positiven Antwort für
das anfragende System;
Redirect-Fähigkeiten d.h. Entgegennahme
und Umleitung der Nutzungsinstanz zu anderen DV-Systeen unter Beibehaltung
von Kontextinformationen (Transaktionsmanagement).
-
Zur
Kommunikation werden dabei adäquate standardisierte
Schnittstellenprotokolle eingesetzt, z.B. HTTP (ggf. in Kombination
mit SSL-Verschlüsselung),
SOAP, RADIUS, LDAP. Zur gegenseitigen Authentifizierung der Systeme
kommen standardisierte Authentifizierungsmechanismen zum Einsatz,
z.B. Credentials (Application1D/ApplicatignSecret) oder Zertifikate.
-
Das
DV-Quellsystem besteht aus einem oder mehreren DV-Systemen mit autorisierungsrelevanten
Informationen bezüglich
der Nutzungsinstanz. Diese Rohdaten sind von dem Vermittlersystem
abfragbar oder werden auf Anfrage an das DV-Vermittlersystem übermittelt.
Meist stammen die Rohdaten aus OSS oder BSS[m6][c7].
-
In
DV-Quellsysteme können
auch transaktionsorientiert Rohdaten während der Beantwortung der
Autorisierungsanfrage erzeugt oder hinterlegt werden, wie es z.B.
bei einer Bezahlung beziehungsweise einer Bestätigung einer Anfrage auf Übernahme
einer Forderung stattfindet.
-
Das
DV-Quellsystem verfügt über eine
Reihe von Funktionen:
Funktion zur Kommunikation mit anderen
Systemen; Funktion zum Speichern von Daten in beliebigen Strukturen;
Anlegen, Ändern
und Löschen
von Daten; Funktion zur optionalen Abfrage von Daten aus anderen
DV-Systemen; Funktion für
das optionale direkte oder indirekte Eintragen, Ändern oder Löschen von
Daten mittels weiterer Applikationen; Funktionen für die Bestimmung
von Zugriffsrechten für
DV-Vermittlersysteme.
-
Zur
Kommunikation werden dabei adäquate standardisierte
Schnittstellenprotokolle eingesetzt, z.B. HTTP (ggf. in Kombination
mit SSL-Verschlüsselung),
SOAP, RADIUS, LDAP. Zur gegenseitigen Authentifizierung der Systeme
kommen standardisierte Authentifizierungsmechanismen zum Einsatz,
z.B. Credentials (Application1D/ApplicationSecret) oder Zertifikate.
-
Häufig alternativ
genutzte Bezeichnungen sind Account Provider, ISP, MNO, Backend
Systeme mit Nutzerdaten, OSS, BSS, Billing Systeme, Kundenmaster,
Kundenkatalog, Kundendatenbank; Vertragsdatenbank, Presence-Service-Session
Controller.
-
Im
Folgenden wird auf die sonstigen beteiligten DV-Systeme eingegangen.
Die Nutzungsinstanz ist mit der Infrastruktur eines Netzwerkoperators über einen
Netzzugangspunkt (sog. Access Point) verbunden. Der Netzzugangspunkt
mit seinen üblichen
Protokollen und Layern (Data link, Network, Transport, Application
Layer) wird nicht dargestellt und erläutert, da er allgemein bekannt
ist.
-
Die
Systeme können
zur Auflösung
von IP-Adressen einen Domain Name Service nutzen. Dieser ist nicht
dargestellt.
-
Für die Authentifizierung
und das Single-Sign-On gibt es verschiedene Lösungen, Systeme und Standards,
wie z.B. SAML[c8] (Verwendung im Liberty
Alliance Projekt). Diese Komponenten zur Authentifizierung können in
das DV-Vermittlungssystem integriert werden bzw. außerhalb
der hier betrachteten Komponenten liegen und werden nicht weiter
dargestellt.
-
Beschreibung der Figuren:
-
Die
Figur dient zur Darstellung eines Ausführungsbeispieles, das das Verständnis der
Erfindung erleichtern soll.
-
1 zeigt
den Verfahrensablauf mit der Kommunikation zwischen den einzelnen
Komponenten;
-
Bevorzugte Ausführungsform:
-
Die 1 zeigt
das Verfahren unter Berücksichtigung
von entsprechenden Vorrichtungen zur Vermittlung und Beantwortung von
Autorisierungsanfragen für
eine Nutzungsinstanz in verteilten DV-Architekturen mit den entsprechenden
Schritten.
-
Für die Nutzungsanfrage
fordert die Nutzungsinstanz S1 in (A) von dem anfragenden DV-System
S2 entweder die Auslieferung eines Guts oder die Nutzung einer DV-Applikation
oder eines Netzelementes an. Ist in S2 auf Grund eigener Informationen
nicht ersichtlich, ob es für
die Auslieferung bzw. Leistungserbringung an S1 berechtigt ist,
so ist eine Autorisierung notwendig. Zu diesen Zwecken nutzt S2
das DV-Vermittlersystem
S3, um eine Autorisierungsanfrage zu stellen. Als Antwort erwartet
das anfragende DV-System ein logisches Ja oder Nein und einen dazugehörigen Nutzungsinstanznamen. Optional
können
weitere Informationen übergeben werden.
-
Bei
der Autorisierungsanfrage stellt S2 eine Anfrage (B) zur Autorisierung
an S3. Die Anfrage ist nur erlaubt, wenn S2 bei S3 bekannt ist und
authentifiziert werden kann (Beispiele- IR-Adresse, Austausch von Geheimnissen
wie UN/PW, Zertifikate, etc.). Die Anfrage enthält Informationen über den
Anfragetyp (Autorisierung) und optional über Kennzeichner (z.B Name,
Warengruppen, Nummern, Preisinformationen, QoS-Parameter etc.) des
Guts bzw. Leistung. Mit der Anfrage durch ein berechtigtes anfragendes
DV-System öffnet
das DV-System intern eine Transaktion, die abgeschlossen wird, wenn
die Antwort auf die Frage ausgeliefert wurde oder nach einer definierten
Zeitspanne.
-
Damit
S3 feststellen kann, für
welche Nutzerinstanz es die Autorisierungsanfrage beantworten muss,
wird ein sog. redirect zu S1 durchgeführt. Dieser redirect kennzeichnet
sich durch die Übergabe von
Zielparametern an S3, der diese an die Nutzungsinstanz weiterreicht.
Die Nutzungsinstanz S1 verwendet diese Zielparameter, um in (C)
eine Verbindung mit S3 aufzubauen. Anhand der Zielparameter kann
die Nutzungsinstanz S1 dem anfragenden DV-System S2 zugeordnet werden.
Die Zielparameter werden zwischen dem DV-Vermittlersystem S3 und
dem anfragenden DV-System S2, z.B. in einer Server zu Server Kommunikation,
in einer den Vorfall beschreibenden Nachricht wie z.B. einer SOAP Nachricht übermittelt.
Entsprechend der Charakteristik des anfragenden DV-Systems S2 können die
Zielparamter z.B. bei einem Web-Service (S2 als Webservice) in Form
eines http-Redirects an den Browser der Nutzungsinstanz S1 übergeben
werden bzw. ebenfalls mittels SOAP-Nachrichten zwischen DV-Systemen.
-
Für die Quelldatenabfrage
gelten folgende Annahmen. Vorausgesetzt, die Nutzungsinstanz ist S3
bekannt, also bereits authentifiziert, so kann S3 auf Basis der
Kennung (z.B. Benutzername, Domainzusatz, eMail-Adresse, etc.) von
S1 die zugehörigen DV-Quellsysteme
identifizieren. Zu der Nutzungsinstanz werden in (D) alle verfügbaren Daten
in einer Server zu Server Kommunikation angefragt und von den Quellsystemen
ausgeliefert. Dabei wird je DV-Quellsystem das zugehörige Protokoll
und die dazugehörige
Schnittstelle bedient, unabhängig
vom Grad der Verteilung der Daten.
-
FALLUNTERSCHEIDUNG
1: Ist eine Nutzungsinstanz nicht authentifiziert (d.h. trägt kein
bekanntes Authentifizierungsmerkmal), so wird dies von S3 erkannt
und die Nutzungsinstanz wird z.B. gemäß Liberty Alliance oder beliebiger
anderer Verfahren authentifiziert. Dabei können weitere Systeme zur Abwicklung
der Authentifizierung genutzt werden bzw. die Nutzungsinstanz an
diese zum Zwecke der Authentifizierung übergeben werden. Diese Schritte der
impliziten Authentifizierung bzw. Registrierung und dazu eventuelle
Kommunikation mit weiteren Systemen ist hier nicht dargestellt.
-
FALLUNTERSCHEIDUNG
2: Ist die Nutzungsinstanz (auch in weiteren Systemen) noch nicht authentifizierbar;
kann sie von, S3 in einen Registrierungsprozess mit einem beliebigen
System geführt werden.
Anschließend
ist die Nutzungsinstanz authentifizierbar und evtl. sind auch Daten
zur Autorisierung eingerichtet worden. Eine Alternative dazu ist eine
generische Berechtigung, die einer nicht authentifizierbaren Nutzungsinstanz
von S3 in Abhängigkeit
von S2 zugeordnet wird. Weitere Abhängigkeiten sind möglich und
werden durch S3 bestimmt. Eine zweite Alternative ist die Einleitung
eines Prozesses, bei dem die Nutzungsinstanz die Rechte erwirbt,
so dass diese anschließend
für die
Autorisierungsabfrage zur Verfügung
stehen. Dieses Erwerben von Rechten kann z.B. durch eine Bezahlung
bei einem weiteren System erfolgen, so dass für die Nutzungsinstanz in Quellsystemen,
die an S3 angebunden sind, im Rahmen der Gesamttransaktion Rohdaten
eingerichtet werden. Für
diese Einrichtung bzw. Bezahlung wird die Nutzungsinstanz in (E)
mittels eines redirect an ein Quellsystem übergeben. Dort erwirbt S1 im
Schritt (F) die Einrichtung der Quelldaten in einem quelldatenspezifischen
Verfahren, welches für
das System S3 ohne Bedeutung ist und hier nicht dargestellt wird.
Nach erfolgter Abwicklung dieser Einrichtungsdialoge wird die Nutzungsinstanz
zuerst in (F), und dann in (E) mittels eines Redirects wieder an
S3 übergeben.
-
Die
Quelldaten werden in S3 auf Basis eines beschreibenden Dokuments
wie z.B. einer XML-Datei kombiniert und gegenüber dem für das System S2 hinterlegten
Regelwerk und einem beschreibenden Dokument verglichen. Das Regelwerk
besagt, welche Charakteristik an Informationen im S3 eigenen Objektmodell
für die
Nutzungsinstanz vorliegen muss, damit die Autorisierung positiv
beantwortet werden kann. Das Ergebnis des Vergleichs wird „als Autorisierungsantwort" zu der Transaktion
abgespeichert.
-
FALLUNTERSCHEIDUNG
3: Ist für
eine Nutzungsinstanz die Antwort auf die Autorisierungsanfrage nach
Auswertung der Rohdaten negativ, so wird S1 von S3, sofern dies
für das
anfragende System S2 erlaubt (Hinterlegung in einem beschreibenden
Dokument) ist, in einen Alternativprozess gemäß FALLUNTERSCHEIDUNG 2 (Redirect
in (E) und (F) zur Einrichtung von Rohdaten in Quellsystemen) geführt. Anschließend werden
die neuen Rohdaten bzgl. ihrer Autorisierungsinformation erneut
bewertet und eine Antwort für
S2 erzeugt.
-
Bei
der Redirect Antwort wird die Nutzungsinstanz über einen Redirect im gleichen
Verfahren wie unter „Redirect
Anfrage" mit den
Zielparametern für
S2 von S3 wieder an das anfragende DV-System S2 übergeben. Dabei wird in den
Zielparametern auch die Information übergeben, zu welcher Transaktion
die ursprüngliche
Anfrage bzw. Abfrage der Autorisierungsergebnisse zugeordnet ist.
-
An
Hand der Zielparameter aus dem vorherigen Verfahrensschritt kann
das System S2 das Ergebnis der Autorisierung in einer Server zu
Server Kommunikation z.B. mit einer SOAP Nachricht bei S3 abfragen
(B) und erhält
auf diesem Wege das Ergebnis der Autorisierung als Antwort. Die
Abfrage der Antwort erfolgt auf Basis der gleichen Schnittstelle wie
die Anfrage nach der Autorisierung beim DV-Vermittlersystem. Damit
wird dem anfragenden DV System eine einheitliche Schnittstelle unabhängig von den
notwendigen Schritten zur Erzeugung einer Antwort und unabhängig von
der Verteilung der Daten ermöglicht.
Optional zum Autorisierungsergebnis können z.B. zusätzliche
Daten zur Nutzungsinstanz übermittelt
werden (dies muss vom Protokoll unterstützt werden).
-
Das
anfragende DV-System S2 erbringt in (A) die Leistung in Abhängigkeit
von der Antwort. Die Nutzungsinstanz kann in einem weiteren Verfahren der
ursprünglichen
Nutzungsanfrage zugeordnet werden.