-
HINTERGRUND DER ERFINDUNG
-
1. Gebiet der Erfindung
-
Die Erfindung betrifft allgemein
Computersysteme. Insbesondere Verfahren und eine Vorrichtung zum
Bereitstellen einer verteilten Authentisierung in einem Unternehmens-Computersystem.
-
Beschreibung
des verwandten Sachstands
-
In modernen Computerumgebungen eines Unternehmens
sind eine Anzahl von Personalcomputern, Workstations, Großrechnern
und dergleichen zusammen mit anderen Vorrichtungen wie etwa großen Massenspeicher-Untersystemen,
Netzschnittstellen wie auch Schnittstellen zu öffentlichen Telefonsystemen
verbunden, die eine integrierte Umgebung bereitstellen, in welcher
eine Information unter den verschiedenen Benutzern geteilt werden
kann. Typischer Weise können
Benutzer eine Vielzahl von Betriebsschritten durchführen, einschließlich Bestellprozeduren,
Fertigung, Versand, Rechnungsstellung, Bestandsaufnahme und andere
Betriebsschritte, in welchem ein Teilen von Daten auf einer Echtzeitbasis einen
beträchtlichen
Vorteil gegenüber
beispielsweise einem Aufrechterhalten getrennter Aufzeichnungen
und einem Versuchen, sie später
abzugleichen, bereitstellt.
-
Ein Problem, das in einer Computerumgebung
eines Unternehmens auftritt, besteht oft darin, dass die verschiedenen
Benutzer Programme verwenden, die auf der Grundlage eines Daten-
oder Programmiermodells entwickelt worden sind, das die Daten, die
sie empfangen, verarbeiten und speichern, eindeutig für dieses
bestimmte Programm sein werden. Eine Lösung für dieses Problem besteht darin,
es zu erzwingen, dass sämtliche
Typen von Programmen auf ein Daten- oder Programmiermodell des gleichen
Typs eingeschränkt
werden. Jedoch treten mehrere Probleme bei dieser Strategie auf,
wovon eines beispielsweise darin besteht, dass, während ein
Einschränken
des Unternehmens-Computersystems auf eine einzige Plattform für manche Typen
von Programmen effizient sein kann, es für andere Typen von Programmen
sehr ineffizient sein kann.
-
Eine weitere Strategie, die verwendet
wird, um das Problem einer Plattform-übergreifenden Kommunikation
zu überwinden,
besteht darin, eine Informationsaustauschmaschine bereitzustellen,
die Daten zwischen Plattformen übersetzen
kann. Während
es dies zulassen wird, dass jedes Programm sein eigenes Daten- oder
Programmiermodell aufweist, erfordert es ein Einrichten und Aufrechterhalten
von Austauschmaschinen für
eine Anzahl von Programmen und dass ein Benutzer eine geeignete Austauschmaschine
wählt,
wenn eine Information von einem anderen Programm importiert oder
exportiert wird. Zusätzlich
werden, wenn die Anzahl von Benutzern und/oder Austauschmaschinen
zunimmt, um die Bedürfnisse
eines expandierenden Systems zu befriedigen, die Verbindungen zwischen
jeder der Komponenten untragbar komplex, indem sie eine "Spaghetti-ähnliche
Masse" bilden. Diese
Zunahme in einer Komplexität
begrenzt die Skalierbarkeit eines integrierten Satzes von Computerressourcen
effektiv, da jedwede zusätzliche
Computerressource ein Rekonfigurieren des gesamten Systems erfordert.
-
Als ein Beispiel ist 1 eine Veranschaulichung eines herkömmlichen
Unternehmens-Computersystems 100. Das Unternehmens-Computersystem 100 schließt Austauschmaschinen 102–110 ein, die
in der Lage sind, auf jedwede Anzahl und Typen von Informationsquellen 112 und 114 zuzugreifen und
diese kreuzzuverbinden. Derartige Quellen schließen verschiedene Datenbankverwaltungssysteme,
Anwendungsprogramme, große
Massenspeicher-Untersysteme, Netzschnittstellen wie auch Schnittstellen
zu öffentlichen
Telefonsystemen wie etwa zu dem Internet ein. Die Datenbankverwaltungsanwendungen
schließen
allgemein Computerprogramme ein, die auf eine herkömmliche
Weise durch digitale Computersysteme über jedwede Anzahl von Computerplattformen
ausgeführt
werden. Typischer Weise schließen
die Austauschmaschinen Computerprogramme ein, die durch digitale
Computersysteme ausgeführt
werden (die die gleichen digitalen Computersysteme sein können, auf
welchen die jeweiligen Anwendungsprogramme ausgeführt werden).
Die Austauschmaschinen und die Anwendungsprogramme werden auf einer
Anzahl von digitalen Computersystemen verarbeitet und gehalten, die
beispielsweise durch ein Netz 116 verbunden sind, das Datenzugriffsanforderungen, übersetzte Datenzugriffsanforderungen
und Antworten zwischen den Computersystemen, auf welchen die Austauschmaschinen
und Anwendungsprogramme verarbeitet werden, überträgt. Wie ersehen werden kann,
nimmt, wenn das Unternehmens-Computersystem
expandiert, die Anzahl von Anwendungsprogrammen und zugeordneten
digitalen Computersystemen zu, um die Bedürfnisse des expandierten Unternehmens-Computersystems
zu befriedigen. Die Skalierbarkeit dieses Typs eines Unternehmens-Computersystems
ist schlecht, da jedwede substantielle Zunahme in der Anzahl von
digitalen Computern in hohem Maße
die Komplexität
des Netzes 116 erhöht,
was wiederum die Ressourcen, die erforderlich sind, um das System 100 zu
pflegen und zu aktualisieren, in hohem Maße erhöht.
-
Ein Zugang zum Lösen der Probleme einer Plattformübergreifenden
Kommunikation und einer Skalierbarkeit besteht darin, Komponenten-basierte, mehrrangige
Anwendungen auf der Grundlage von beispielsweise der Enterprise
JavaBeans (EJB)-Technologie
von Sun Microsystems Inc., Mountain View, CA., zu verwenden. Die
Enterprise JavaBeans-Technologie stellt in der Form eines EJB-Servers
eine mehrrangige Auslegung dar, die ein Entwickeln, Ausbringen und
Pflegen von Unternehmensanwendungen vereinfacht. Sie ermöglicht es
Entwicklern, sich auf die Spezifizierungen eines Programmierens
ihrer Geschäftslogik
zu fokussieren, indem sie sich auf den EJB-Server, Systemdienste bereitzustellen,
und Anwendungen der Client-Seite (sowohl alleinstehende als auch
innerhalb von WEB-Browsern), die Benutzer-Interaktion bereitzustellen,
verlassen. Einmal entwickelt, kann die Geschäftslogik auf Server ausgebracht
werden, die für vorhandene
Bedürfnisse
einer Organisation geeignet sind.
-
Obwohl die EJB-Server-Technologie
eine Skalierbarkeit verbessert und viele der Probleme, die ein Plattformübergreifendes
Betriebsverhalten betreffen, löst,
verbleibt immer noch der Bedarf, eine gewisse Form einer Plattformübergreifenden
Sicherheit bereitzustellen, da eine Anzahl der Computersysteme innerhalb
des Unternehmens-Computersystems ihre eigenen Authentisierungs-Protokolle
und Verfahren aufweist.
-
Die US-5708780 beschreibt ein Verfahren, durch
welches ein Browser auf geschützte
Dateien, die von einem Host-Server gehalten werden, zugreifen kann.
Wenn der Browser eine überwachte
Seite anfordert, dann bestimmt der Server, ob ein Sitzungs-Identifizierer "SID" in der Anforderung
vorhanden ist. Wenn nicht, dann wird die Anforderung an einen Authentisierungs-Server
gerichtet. Der Authentisierungs-Server
bestimmt dann, ob ein SID zugeordnet werden kann, oder ob der Client
authentisiert werden muss, so dass ein SID zu dem Client zum Einschluss
in eine nachfolgende Zugriffsanforderung gesendet werden kann.
-
Die US-5560008 beschreibt ein verteiltes Datenverarbeitungssystem
in einem Computernetz. Eine Anforderung nach einem Dienst wird von
einer Benutzer-Client-Maschine
zu einem Server gesendet. Die Anforderung schließt eine Information ein, um
sicherzustellen, dass der Benutzer autorisiert ist, den Server zu
benutzen, und die Berechtigungen und Fähigkeiten des Benutzers ein,
wenn er den Server benutzt. Der Server richtet die Berechtigungen
ein und speichert diese Information als eine Berechtigungsstruktur
und gibt einen kleinen Wert zu dem Benutzer zurück, der ein Berechtigungsidentifizierer ist.
Dann schließt
jedes Mal, wenn der Benutzer auf den Server zugreift, eine Anforderung
nach einem Dienst, die eine Autorisierung erfordert, den Berechtigungsidentifizierer
ein, so dass der Server die Berechtigungsstruktur für den Benutzer
identifizieren und bestimmen kann, ob der Benutzer autorisiert ist.
-
Die "Enterprise JaveBeans Technologie – Server
Component Model for the Java Platform", Patricia Seybold Group, Dezember 1998
(1998-12), XP002160756 beschreibt ein Modell für die Entwicklung und die Ausbringung
wiederverwendbarer Java-Server-Komponenten, die in Arbeits-Anwendungssysteme
zusammengesetzt werden können. Die
Server-Komponenten laufen auf einem Anwendungs-Server, der ein Teil
einer Enterprise-Java-Plattform
ist, die eine Java-Umgebung ist, die großskalige verteilte missionskritische
Anwendungssysteme unterstützt.
-
Die US-5884038 beschreibt ein Verfahren zum
Versehen von Internet-Protokolladressen mit einem Domänennamen-Server
für mehrfache WEB-Server
eines Internet-Hosts. Jedem WEB-Server ist ein relatives Gewicht
auf der Grundlage seiner individuellen Verarbeitungsleistung zugeordnet. Wenn
DNS-Auflösungsanforderungen
von Clients empfangen werden, gibt der DNS IP-Adressen für die WEB-Server
proportional zu dem relativen Gewicht des Servers zurück. Dies
hilft dabei, die Wahrscheinlichkeit eines Lastungleichgewichts zwischen WEB-Servern zu verringern.
-
Deswegen wäre es, in Anbetracht des Vorangehenden,
vorteilhaft und deswegen wünschenswert,
ein skalierbares, Plattform-übergreifendes
Unternehmens-Computersystem zu haben, das die Fähigkeit aufweist, eine transparente
Mehrfachplattform-Sicherheit bereitzustellen.
-
ZUSAMMENFASSUNG DER ERFINDUNG
-
Die Erfindung kann auf zahlreiche
Weisen implementiert werden, die ein Verfahren, eine Vorrichtung
und ein Computersystem einschließen. Aspekte und Ausführungsformen
der Erfindung werden untenstehend diskutiert.
-
In einem Aspekt der Erfindung ist
ein Verfahren zum Zugreifen auf eine geschützte Ressource in einem Mehrfachplattform-Unternehmens-Computersystem
bereitgestellt, das einen Authentisierungs-Server aufweist, der
angeordnet ist, eine Berechtigung, die von einem anfordernden Client
als ein Berechtigungseigentümer,
um auf die geschützte Ressource
zuzugreifen, zu authentisieren, wobei der Authentisierungs-Server sicher mit
dem anfordernden Client und einem Server, der mit der geschützten Ressource
verbunden ist, verbunden ist, umfassend ein Bereitstellen einer
Berechtigungsanforderung an den Authentisierungs-Server von dem
anfordernden Client, wobei die Berechtigungsanforderung Authentisierungsdaten
einschließt,
die anzeigend für
die geschützte
Ressource sind, ein Authentisieren des anfordernden Clients durch
den Authentisierungs-Server, auf der Grundlage der Authentisierungsdaten, auf
die geschützte
Ressource zuzugreifen, ein Authentisieren des anfordernden Clients,
ein Privileg, das der geschützten
Ressource zugeordnet ist, auszuüben,
wobei das Privileg zusätzlich
zu dem gewährten
Zugriff ist, ein Versehen des anfordernden Clients mit einer Referenz
auf die Berechtigung, ein Überreichen
der Referenz auf die Berechtigung zusammen mit einer Zugriffsanforderung
auf die geschützte
Ressource an den Server, ein Validieren der Berechtigung durch den
Authentisierungs-Server, wenn sie dem Server überreicht wird, und ein Gewähren eines
Zugriffs des anfordernden Clients auf die geschützte Ressource durch den Server,
wenn die Berechtigung validiert ist.
-
In einem weiteren Aspekt stellt die
Erfindung einen Authentisierungs-Server zur Verwendung in einem
verteilten Objekt-Computersystem zum Zugreifen auf eine geschützte Ressource
unter Verwendung des Verfahrens des einen Aspekts der Erfindung
bereit, wobei der Authentisierungs-Server angeordnet ist, eine Berechtigung
bereitzustellen, die einem berechtigen Benutzer eine Erlaubnis gewährt, auf
eine geschützte
Ressource zuzugreifen, die in Authentisierungsdaten identifiziert
ist, die in einer zugeordneten Berechtigungsanforderung eingeschlossen
sind, die von einem anfordernden Client bereitgestellt wird, und
umfasst einen Berechtigungsanforderungs-Verifizierer, der angeordnet
ist, zu bestimmen, ob zusätzliche
Authentisierungsdaten von dem Authentisierungs-Server erforderlich
sind, um dem anfordernden Client die Berechtigung zu gewähren, einen
Bereichsauthentisierer, der mit dem Berechtigungsanforderung-Verifizierer
gekoppelt ist, der angeordnet ist, den anfordernden Client in einem
angeforderten Bereich zu authentisieren, wenn bestimmt wird, dass
es dem anfordernden Client gestattet ist, auf den angeforderten
Bereich zuzugreifen, einen Berechtigungsübersetzer, der mit dem Bereichsauthentisierer
gekoppelt ist, der angeordnet ist, dem anfordernden Client ein angefordertes
Privileg in dem authentisierten Bereich zu gewähren, wenn bestimmt wird, dass
dem anfordernden Client das angeforderte Privileg in dem authentisierten
Bereich zugestanden wird, und einen Berechtigungsgenerator, der
mit dem Berechtigungsübersetzer
gekoppelt ist, der angeordnet ist, um dem anfordernden Client die
Berechtigung bereitzustellen.
-
In einer bevorzugten Ausführungsform
ist der Server ein Enterprise Java Bean (EJB)-Server.
-
In noch einem weiteren Aspekt der
Erfindung ist ein Computerprogrammcode bereitgestellt, der von einem
Computer ausführbar
ist, um die obigen beiden Aspekte der Erfindung zu implementieren.
-
Diese und andere Vorteile der vorliegenden Erfindung
werden auf ein Lesen der folgenden detaillierten Beschreibungen
und ein Studieren der verschiedenen Figuren der Zeichnungen offensichtlich werden.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Die Erfindung kann, zusammen mit
weiteren Vorteilen davon, am besten unter Bezugnahme auf die folgende
Beschreibung verstanden werden, die in Verbindung mit den zugehörigen Zeichnungen
genommen wird.
-
In den Zeichnungen zeigen:
-
1 ein
herkömmliches
Unternehmens-Computersystem;
-
2 einen
Unternehmens-Java Bean (EJB)-Server gemäß einer Ausführungsform
der Erfindung;
-
3 ein
beispielhaftes Mehrfachplattform-Unternehmens-Computersystem gemäß einer Ausführungsform
der Erfindung;
-
4 ein
Flussdiagramm, das einen Prozess, wenn ein Client eine Berechtigung
erhält,
um auf ein Objekt zuzugreifen, gemäß einer Ausführungsform
der Erfindung detailliert zeigt;
-
5A ein
Flussdiagramm, das den Prozess detailliert zeigt, wenn ein Client
eine Berechtigung von einem Authentisierungs-Server anfordert, gezeigt
in 4 als ein Betriebsschritt 404;
-
5B ein
Transaktionsdiagramm, das die Anforderung/Antwort zwischen dem anfordernden Client
und dem Authentisierungs-Server gemäß einer Ausführungsform
der Erfindung detailliert zeigt;
-
6 ein
Flussdiagramm, das einen Prozess detailliert zeigt, wenn ein Authentisierungs-Server
einen Client in geeigneten Bereichen authentisiert, gezeigt in 4 als ein Betriebsschritt 406;
-
7 ein
Flussdiagramm, das einen Prozess 700 detailliert zeigt,
wenn die Berechtigung von dem Authentisierungs-Server übersetzt
wird, wie in 4 als ein
Betriebsschritt 408 gezeigt;
-
8 ein
Flussdiagramm, das einen Prozess detailliert zeigt, wenn auf ein
Objekt oder eine andere geschützte
Ressource zugegriffen wird, wie in 4 als
ein Betriebsschritt 412 gezeigt; und
-
9 ein
Computersystem, das eingesetzt werden kann, um die vorliegende Erfindung
zu implementieren.
-
DETAILLIERTE
BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
-
In der folgenden Beschreibung werden
Rahmensysteme und Verfahren zum Bereitstellen sicherer Transaktionen
in einem Mehrfachplattform-Unternehmenscomputer beschrieben. Obwohl
die Erfindung anfangs hinsichtlich eines Authentisierungs-Servers beschrieben
werden wird, der auf einem Enterprise Java Bean (EJB)-basierten
Unternehmens-Computersystem liegt, kann die vorliegende Erfindung
in jedwedem Netzcomputersystem einschließlich jener, die mehrfach verzweigte
Objektorientierte Computersysteme einschließen, verwendet werden.
-
Im allgemeinen lokalisiert in einem
EJB-basierten Unternehmens-Computersystem, das eine Anzahl von verbundenen EJB-Servern
aufweist, wenn eine anfordernde Clientanwendung wie etwa beispielsweise
ein Applet in einem Browser es wünscht,
auf eine sichere, oder geschützte,
Datenbank oder eine andere Ressource zuzugreifen, die anfordernde
Clientanwendung zuerst einen Authentisierungs-Server. In einer Ausführungsform
lokalisiert der anfordernde Client einen Authentisierungs-Server,
in dem zuerst auf einen Benennungs-Server zugegriffen wird, der
eine Adresse für
den Authentisierungs-Server im Ansprechen auf eine Client-Anforderung bereitstellt.
Der anfordernde Client fordert dann eine Berechtigung von dem Authentisierungs-Server an.
In einer Implementierung versieht die Berechtigung den anfordernden
Client mit der Fähigkeit,
auf eine geschützte
Ressource wie etwa eine externe Datenbank zuzugreifen. Um die Berechtigung
zu erhalten, muss der anfordernde Client jedoch zuerst den Authentisierungs-Server
mit einer Information versehen, die einen Bereich, oder Bereiche,
einschließt,
für welche
der Client authentisiert zu werden wünscht. Mit Bereichen ist die
Benutzer-/Benennungs-/Authentisierungsdaten-Datenbank,
die auf Plattformen wie etwa UNIX, Windows NT, etc., enthalten ist,
gemeint, auf welche das Objekt, auf das der Client zuzugreifen wünscht, läuft. Im
Wegen eines Beispiels muss, wenn der Client auf eine sichere Datenbank
zuzugreifen wünscht,
die in einer UNIX-Plattform läuft,
er zuerst anfordern, dass der Authentisierungs-Server den anfordernden
Client in der UNIX-Plattform
im Auftrag des anfordernden Clients authentisiert.
-
Sobald der Authentisierungs-Server
den Client in dem (den) Bereich(en) authentisiert hat, übersetzt
der Authentisierungs-Server dann die Privilegien, die durch den
Bereich gewährt
werden, in die Berechtigung und gibt eine entfernte Referenz auf
die Berechtigung zu dem Client zurück. Der Client kann dann die
entfernte Referenz auf die Berechtigung für nachfolgende Zugriffsanforderungen
verwenden, wie etwa für
Objekte oder geschützte
Ressourcen wie etwa Datenbanken. Durch ein Bereitstellen einer entfernten
Referenz auf die Berechtigung ist die Erfindung deswegen geeignet
angeordnet, um auf jedweder Anzahl und jedwedem Typ von Computersysteme
mit mehrfachen Teilprozessen (multi-threaded) zu laufen.
-
Einer der grundlegenden Aufbaublöcke eines
EJB-basierten Unternehmens-Computersystems ist einer, der als ein
Enterprise Java Bean (EJB)-Server bezeichnet wird. 2 veranschaulicht die Architektur eines
EJB-Servers 200 gemäß einer Ausführungsform
der Erfindung. Da die EJB-Spezifikation nicht irgendein entferntes
Objekt-"Draht"-Protokoll beauftragt,
kann der EJB-Server 200 mehrfache Protokolle wie RMI, IIOP
(CORBA) und DCOM unterstützen,
was anzeigt, dass ein Client zu dem EJB-Server 200 nicht
in der JAVA-Sprache geschrieben werden muss. In der beschriebenen
Ausführungsform
ist der EJB-Server 200 eine Sammlung von Diensten zum Unterstützen einer
EJB-Installation. Diese Dienste schließen ein Verwalten verteilter Transaktionen,
ein Verwalten verteilter Objekte und verteilter Aufrufe an diese
Objekte, und Systemdienste niedrigen Niveaus ein. Kurz gesagt verwaltet der
EJB-Server 200 die Ressourcen, die benötigt werden, um eine EJB-Komponente
(oder Bean) 202, die in einem EJB-Container 204 eingeschlossen
ist. In der beschriebenen Ausführungsform
ist der EJB-Container 204 eine Haus-Einheit für EJB-Komponenten
wie etwa die EJB-Komponente 202, die eine skalierbare,
sichere Transaktionsumgebung bereitstellt, in welcher EJB-Komponenten
arbeiten können.
Der EJB-Container 204 handhabt die Objektlebensdauer einschließlich eines
Schaffens und Zerstörens
eines Objekts wie auch eines Handhabens der Zustandsverwaltung von
EJB-Komponenten.
-
Da der EJB-Container 204 für einen
Klienten 206 transparent ist, ist kein Client-API für ihn vorhanden.
Wenn eine EJB-Komponente
in dem EJB-Container 204 installiert ist, stellt der EJB-Container 204 zwei
Implementierungen bereit: Eine Implementierung der EJB-Heimschnittstelle 208 der
EJB- Komponente,
die untenstehend diskutiert ist, und eine entfernte Schnittstelle
der EJB-Komponente.
-
Wenn ein Bean auf dem EJB-Server 200 installiert
ist, wird eine entfernte Schnittstelle, die als ein EJB-Objekt 210 bezeichnet
wird, automatisch erzeugt. Das EJB-Objekt 210 ist ein Objekt,
das nur die entfernte Schnittstelle, die von dem Programmierer spezifiziert
ist, freilegt. Auf diese Weise wirkt das EJB-Objekt 210 wie
ein Vertreter, der jedwede entfernten Objektaufrufe auffängt und
die geeigneten Verfahren auf der Unternehmens-Bean-Instanz aufruft.
Der EJB-Container 204 implementiert
die EJB-Heimschnittstelle 208 jedes Beans 202,
der in dem Container installiert ist. Er lässt die Schaffung eines Beans,
die Löschung
eines Beans und eine Abfrage von Information oder "Metadaten" über einen Bean zu.
-
3 veranschaulicht
ein beispielhaftes EJB-basiertes Unternehmens-Computersystem 300 gemäß einer
Ausführungsform
der Erfindung. Das Unternehmens-Computersystem 300 schließt einen Authentisierungs-Server 302 ein,
der sicher mit einem WEB-Server 304 gekoppelt ist. In der
beschriebenen Ausführungsform
ist der WEB-Server 304 ein Java-basierter WEB-Server, der
nur für
dieses Beispiel verwendet wird und als solcher nicht als einschränkend für den Umfang
der Erfindung auszulegen ist. Der WEB-Server 304 ist wiederum
mit einem Client 306 gekoppelt, der typischer Weise ein WEB-Browser ist, der
eingebettete Anwendungen wie etwa Applets aufweisen kann, die verwendet
werden, um sichere http-Anfragen
(HTTPs) zu erzeugen. Es sei drauf hingewiesen, dass, um sicherzustellen, dass
keine ausgegebene Berechtigung gestohlen oder anderweitig unrechtmäßig verwendet
wird, sämtliche
Verbindungen innerhalb des Unternehmens-Computersystems im wesentlichen sicher
sein müssen,
indem beispielsweise verschiedene Verschlüsselungsverfahren verwendet
werden, die Durchschnittsfachleuten altbekannt sind. In manchen Implementierungen
wird ein Benennungs-Server
307 verwendet, um den Ort (z.
B. die Adresse) des Authentisierungs-Servers 302 zu identifizieren.
-
Der WEB-Server 304 ist auch
sicher mit irgendeiner Anzahl und Typen von EJB-Servern 308–312 gekoppelt.
Es sei darauf hingewiesen, dass in der beschriebenen Ausführungsform
jeder der EJB-Server 308–312 auf Plattformen
I, II bzw. III läuft, und
deswegen als der EJB-Server 200 implementiert ist, der
in 2 gezeigt ist. Für dieses
Beispiel ist eine sichere, oder geschützte, externe Datenbank 314,
die auf der Plattform I läuft,
sicher mit dem EJB-Server 308 verbunden. Die sichere Datenbank 314 ist
durch Datenbanken verkörpert,
die eine sichere Information enthalten, die sich beispielsweise
auf Bankkonten, eine Personalidentifikation und jedweden anderen
Typ oder jedwede andere Klasse einer Information bezieht, die als
privilegiert und deswegen geschützt
anzusehen ist. In manchen Fällen
erfordert ein Zugreifen auf die sicher Datenbank 314 spezifische
Privilegien, die nicht allen verfügbar sind, die andernfalls
auf die Datenbank 314 Zugriff haben würden. Ein derartiges Beispiel
ist der Fall, wo die Datenbank 314 beispielsweise Gehaltsabrechnungsinformation
einschließt,
so dass nur spezifischen Individuen in einer Organisation das Privileg
gewährt
wird, darauf zuzugreifen. In diesem Fall ist dann, zusätzlich zu
einem allgemeinen Zugriff ein spezifischeres Privileg erforderlich,
um bestimmte Aufgaben durchzuführen,
wie etwa jemandem eine Erhöhung
zu geben.
-
Um dem Authentisierungs-Server 302 eine Berechtigung
bereitzustellen, die einen geeigneten Zugriff auf einen anfordernden
Client ermöglicht,
der in diesem Fall der (WEB-Browser 304 ist),
muss der anfordernde Client dem Authentisierungs-Server 302 eine
Information bereitstellen, die sich beispielsweise auf ein Spezifizieren
bezieht, für
welchen Bereich der Client 306 zu authentisieren ist, indem
das Authentisierungsverfahren (d. h. BASIC, FORM_BASED) spezifiziert
wird, und der Authentisierungstyp (d. h. U/P, SSL_CLIENT) spezifiziert
wird.
-
Es sei darauf hingewiesen, dass,
wenn der Authentisierungs-Server 302 bestimmt
hat, für
welche Bereiche (und welche zusätzlichen
Privilegien, falls vorhanden) dieser anfordernde Client 306 authentisiert
ist, ein Berechtigungsobjekt 316, das auch als eine Berechtigung
bezeichnet wird, instanziiert wird. Eine Referenz 318 auf
diese Berechtigung wird dann an den Client 306 im Wege
des WEB-Servers 304 übergeben.
Da nur eine Referenz auf die Berechtigung zu dem anfordernden Client übergeben wird,
können
sich andere Clients wie etwa beispielsweise Teilprozesse (Threads),
die mit dem Authentisierungs-Server 302 gekoppelt sind,
auch auf die gleiche Berechtigung beziehen.
-
Sobald der anfordernde Client (d.
h. der Client 306) die Referenz auf die Berechtigung empfangen
hat, kann ein Zugriff auf jedwede Anzahl von sicheren Ressourcen
durch ein Übergeben
einer spezifischen Zugriffsanforderung zusammen mit der Referenz
auf die bestimmte Ressource, auf die zugegriffen werden soll, erlangt
werden. Es sei jedoch darauf hingewiesen, dass die Berechtigung
nur für
jene Bereiche gültig
ist, für
welche sie ursprünglich
authentisiert worden ist. Deswegen wird jedwede sichere Ressource,
die in einem Bereich angeordnet ist, für welchen eine Authentisierung
nicht gewährt
worden ist, dem Client 306 einen Zugriff versagen, bis
eine neue Berechtigung ausgegeben ist, die einen Zugriff auf den
bestimmten Bereich authentisiert, oder gegenwärtige Berechtigung mit den
authentisierten Attributen von diesem Bereich aktualisiert ist.
-
Beispielsweise muss, wenn es ein
Benutzer, der den Client 306 implementiert, wünscht, auf
die Datenbank 314 zuzugreifen, um beispielsweise ein Gehaltsabrechnungsprogramm
zu betreiben, eine sichere http-Anforderung (HTTPs) erzeugt werden,
die eine Berechtigung für
einen Zugriff auf die Datenbank 314 erzeugt. Wenn zusätzliche
Privilegien außer
einem bloßen
Zugriff erforderlich sind, um die Transaktion zu vervollständigen,
dann muss diese Tatsache in der Information eingeschlossen sein,
die von dem Benutzer bereitgestellt wird. In manchen Fällen wird der
Authentisierungs-Server 302 zu dem WEB-Server 304 zurückantworten,
dass eine zusätzliche
Information erforderlich ist, wobei in diesem Fall eine Frage- und
Antwortsitzung initiiert werden wird, bis zu der Zeit, da der Authentisierungs-Server 302 bestimmt
hat, dass er genug Information hat, um dem anfordernden Client für den angeforderten
Bereich (die angeforderten Bereiche) eine Berechtigung entweder
zu gewähren
oder zu versagen.
-
Sobald der Authentisierungs-Server
genug Information hat, um die Berechtigungsanforderung zu verarbeiten,
validiert er jene Bereiche, für
welche die Berechtigung einen Zugriff für irgendeinen Client gewähren wird,
der eine Referenz auf diese Berechtigung besitzt. Es ist wichtig
darauf hinzuweisen, dass, da die Referenz auf die Berechtigung analog
zu einem "bearer
bond" ist, nur berechtigte
Klienten die Referenz besitzen sollten. Deswegen ist ein Verwenden
sicherer Leitungen zwischen den verschiedenen Elementen des Unternehmens-Computersystems 300 eine
wichtige Erwägung
während
einer Auslegung und einer Implementierung. Der Authentisierungs-Server 302 gewährt oder
versagt eine Berechtigung auf der Grundlage der zugeführten Information,
und in diesem Fall, wenn eine Berechtigung versagt wird, wird ein
Fehlermarker zu dem anfordernden Client 306 geschickt.
Andererseits, wenn der Authentisierungs-Server 302 bestimmt,
dass eine Berechtigung gewährt
werden sollte, wird dann ein Berechtigungsobjekt instanziiert und,
in einer Implementierung, in dem Authentisierungs-Server 302 gespeichert
und eine Referenz auf dieses Berechtigungobjekt wird dem anfordernden
Client 306 übergeben.
-
Sobald der anfordernde Client 306 die
Referenz auf die Berechtigung aufweist, schickt er eine Anforderung,
auf die Datenbank 314 zuzugreifen, zu dem EJB-Server 308.
In einer Ausführungsform
ist die Datenbankzugriffsanforderung von einer Referenz auf die
Berechtigung begleitet, derart, dass der EJB-Server 308 sicherstellen
kann, dass die anfordernde Einheit (d. h. der Client 306)
die richtige Authentisierung aufweist, um ein Geschäft mit der
Datenbank 314 abzuwickeln. In manchen Fällen wird es erforderlich sein,
dass der EJB-Server 308 auf
einen weiteren der EJB-Server zugreift, wie etwa den EJB-Server 310,
um die angeforderte Transaktion zu vervollständigen. In diesem Fall wird
die Anforderung von dem EJB-Server 308 an den EJB-Server 310 ebenso
auch von der Referenz auf die Berechtigung begleitet. Wenn die Berechtigung
für die
Ressourcen, die mit dem EJB-Server 310 gekoppelt sind,
gültig
ist, dann wird ein Zugriff gewährt
und die Transaktion wird vervollständigt, andernfalls wird ein
Zugriff versagt. Es ist deswegen zumindest aus diesem Grund dass,
wenn die Anforderung an den Authentisierungs-Server 302 gerichtet
wird, er ein Privileg für
jeden Bereich, für
welchen ein Zugriff erforderlich sein wird, anfordert.
-
4 ist
ein Flussdiagramm, das einen Prozess 400 für einen
Client, um eine Berechtigung zu erhalten, um auf ein Objekt zuzugreifen,
gemäß einer Ausführungsform
der Erfindung detailliert zeigt. Es sei darauf hingewiesen, dass
der Prozess 400 in zwei Unterregime unterteilt werden kann,
spezifisch in jene, indem Aktionen durch den anfordernden Client (auch
als Client-Seite bezeichnet) ausgeführt werden, und jene Aktionen,
die von dem Authentisierungs-Server (auch als Authentisierungs-Server-Seite
bezeichnet) ausgeführt
werden. Damit ein Client eine Transaktion durchführt, muss er gleichzeitig einen
Zugriff auf ein Objekt oder eine andere geschützte Ressource erhalten. In
der beschriebenen Ausführungsform
muss der Client deswegen einen Besitz einer Berechtigung erlangen,
die es dem Client ermöglicht,
als ein Berechtigungsbesitzer, auf bestimmte Objekte oder andere
geschützte
Ressourcen in dem Unternehmens-Computersystem zuzugreifen. In dem
Fall, wo die verschiedenen Ressourcen auf unterschiedlichen Betriebsplattformen
laufen, muss der anfordernde Client diese Plattformen identifizieren, um
so authentisiert zu werden, um die Transaktion zu vervollständigen.
-
Der Prozess 400 zum Erhalten
und Verwenden einer Berechtigung startet in einer Implementierung
bei 402 durch den anfordernden Client, der auf einen Benennungs-Server
zugreift, der angeordnet ist, den Ort oder eine Adresse eines Authentisierungs-Servers
bereitzustellen. In manchen Ausführungsformen
ist der Benennungs-Server nicht erforderlich, da er nur die Adresse
des Authentisierungs-Servers
bereitstellt, die durch andere Verfahren bereitgestellt werden kann,
wie sie Durchschnittsfachleuten altbekannt ist. Nachdem der Ort des
Authentisierungs-Servers dem anfordernden Client bekanntgemacht
worden ist, stellt der anfordernde Client eine Berechtigungsanfrage
an den Authentisierungs-Servers bei 404, indem er seine
Adresse und verschiedene Daten, die die Authentisierung betreffen,
durchgibt. Eine derartige zugehörige
Information kann den Bereich (die Bereiche) einschließen, für welche
eine Authentisierung notwendig ist, um die erwartete Transaktion
zu vervollständigen,
wie auch jedwede speziellen Privilegien, die erforderlich sind, um
manche oder sämtliche
der erwarteten Transaktionen zu vervollständigen. Sobald der Authentisierungs-Server
die Anforderung von dem anfordernden Client empfangen hat, authentisiert
der Authentisierungs-Server
den Client in dem geeigneten Bereich (in den geeigneten Bereichen)
bei 406 durch ein Instanziieren eines Berechtigungsobjekts.
Der Authentisierungs-Server ruft dann ein Übersetzungsverfahren für das Berechtigungsobjekt
bei 408 auf und gibt eine Referenz auf das Berechtigungsobjekt
zu dem anfordernden Client bei 410 zurück. In der beschriebenen Ausführungsform
ist das Berechtigungsobjekt in dem Authentisierungs-Server gespeichert,
und nur eine Referenz auf das Berechtigungsobjekt wird weitergegeben.
Auf diese Weise können
mehrfache Teilprozesse (Threads) auf das gleiche Berechtigungsobjekt
zugreifen, wodurch ein Betriebsverhalten und eine Effizienz in dem
Unternehmens-Computersystem verbessert wird.
-
Sobald der anfordernde Client die
Referenz auf das Berechtigungsobjekt erhalten hat, ist der anfordernde
Client in der Lage, einer geschützten
Ressource bei 412 eine Objektzugriffsanforderung in Verbindung
mit der Referenz auf das Berechtigungsobjekt bereitzustellen.
-
5A ist
ein Flussdiagramm, das den Prozess 500, bei dem ein Client
eine Berechtigung von einem Authentisierungs-Server anfordert, der in 4 als ein Betriebsschritt 404 gezeigt
ist, detailliert zeigt. Es sei darauf hingewiesen, dass der Prozess 500 nur
eine mögliche
Implementierung des Betriebsschritts 404 ist, und als solcher
nicht als einschränkend
für den
Umfang oder Grundgedanken der Erfindung auszulegen ist. Der Prozess 500 beginnt
bei 502, wenn der Client anfordert, eine Authentisierung
zu beginnen, indem das Verfahren auf dem Authentisierungs-Server
aufgerufen wird, indem seine eigene Adresse durchgegeben wird. In
einer Antwort empfängt
der anfordernde Client eine leere Berechtigung bei 504,
die als ein Platzhalter verwendet wird. Als nächstes wird bei 506 eine
Authentisierungsanforderung unter Verwendung von Authentisierungsdaten
initiiert, die dem Authentisierungs-Server von dem anfordernden
Client bereitgestellt werden. Auf der Grundlage der Authentisierungsdaten gibt
der Authentisierungs-Server anfangs einen Statusmarker bei 508 zurück. In einem
Status zeigt der Statusmarker einen fehlerhaften Status an, was
bedeutet, das dem anfordernden Client eine Authentisierung auf der
Grundlage teilweise von den bereitgestellten Authentisierungsdaten
versagt worden ist. Eine derartige Versagung kann auf einem Anzeigen eines
Bereichs basiert sein, für
welchen dem anfordernden Client ein Zugriff versagt ist, oder dass
spezielle Privilegien innerhalb eines zugestandenen Bereichs versagt
werden. In jedem Fall wird der Fehlermarker zu dem anfordernden
Client bei 510 zurückgegeben.
-
In dem Fall, wo der Statusmarker
ein Fehlerfrei-Marker ist, gibt dann der Authentisierungs-Server eine
Referenz auf eine Berechtigung zu dem anfordernden Client bei 410.
In manchen Fällen
jedoch ist eine zusätzliche
Information des anfordernden Clients erforderlich, und in diesen
Fällen
wird ein Fortsetzungsmarker zurückgegeben,
derart, dass entweder der Client mehr Information anfordert oder
eine zusätzliche
Information bei 512 bereitstellt, nach welcher eine Steuerung
zu 506 zurückgegeben
wird.
-
In dem Fall, wo ein Fortsetzungsmarker
zurückgegeben
wird, ist 5B ein Transaktionsdiagramm,
das die Anforderung/Antwort zwischen dem anfordernden Client und
dem Authentisierungs-Server gemäß einer
Ausführungsform
der Erfindung detailliert zeigt. Es sei darauf hingewiesen, dass
in dem Fall, dass ein bedingter Statusmarker zurückgegeben wird, jedwede Anzahl
von Zwischeninformationsaustauschschritten vorhanden sein kann,
bis zu der Zeit, wenn der Authentisierungs-Server zufriedengestellt
ist, dass er genug Information hat, um entweder eine Berechtigung
zu gewähren
oder zu versagen.
-
6 ist
ein Flussdiagramm, das einen Prozess 600, bei dem ein Authentisierungs-Server
einen Client in geeigneten Bereichen authentisiert, der in 4 als ein Betriebsschritt 406 gezeigt
ist, detailliert zeigt. Es sei darauf hingewiesen, dass der Prozess 600 nur
eine mögliche
Implementierung des Betriebsschritts 406 ist, und als solcher
nicht als einschränkend
für den
Umfang oder den Grundgedanken der Erfindung auszulegen ist. Der
Prozess 600 beginnt bei 602, indem der Authentisierungs-Server Authentisierungsdaten
von dem anfordernden Client erlangt, wie beispielsweise in 5B gezeigt. Eine Bestimmung
wird bei 604 ausgeführt,
ob zusätzliche Daten
erforderlich sind oder nicht, und wenn zusätzliche Daten nicht erforderlich
sind, dann authentisiert der Authentisierungs-Server den anfordernden
Client bei 606, andernfalls werden mehr Daten durch den Authentisierungs-Server erlangt. Wenn
Authentisierung als erfolgreich bei 608 erachtet wurde,
wird dann eine Steuerung zu einem Betriebsschritt 408 der 4 gegeben, wo der Authentisierungs-Server die
Berechtigung übersetzt.
Falls die Authentisierung jedoch als fehlerhaft erachtet wurde,
dann wird ein Fehlermarker bei 610 zurückgegeben.
-
7 ist
ein Flussdiagramm, das einen Prozess 700 zum Übersetzen
der Berechtigung durch den Authentisierungs-Server, wie in 4 als ein Betriebsschritt 408 gezeigt,
detailliert zeigt. Es sei darauf hingewiesen, dass der Prozess 700 nur
eine mögliche
Implementierung des Betriebsschritts 408 ist und als solcher
nicht als einschränkend
für den Umfang
oder den Grundgedanken der Erfindung auszulegen ist. Der Prozess 700 startet
bei 702 durch den Authentisierungs-Server, der bestimmt,
ob zusätzliche
Privilegien entweder angefordert worden sind oder als geeignet erachtet
werden. Wenn zusätzliche
Privilegien geeignet sind, dann werden diese zusätzlichen Privilegien durch
den Authentisierungs-Server für
den anfordernden Client bei 704 gewährt. Wenn jedoch keine zusätzlichen
Privilegien erforderlich sind, dann wird die Berechtigung in einer Ausführungsform,
um eine unautorisierte Verwendung der Berechtigung zu verhindern,
bei 706 digital signiert. Die Berechtigung wird dann bei 708 beispielsweise
durch ein Einstellen einer Verfallsperiode validiert, nach welcher
die Berechtigung einer Zerstörung
oder einer anderweitigen Überführung als
Abfall unterworfen wird. Bei 710 wird dann eine Referenz auf
die validierte Berechtigung zu dem anfordernden Client bei 410 zurückgegeben.
-
8 ist
ein Flussdiagramm, das einen Prozess 800 zum Zugreifen
auf ein Objekt oder eine andere geschützte Ressource, wie in 4 als ein Betriebsschritt 412 gezeigt, detailliert
zeigt. Es sei darauf hingewiesen, dass der Prozess nur eine mögliche Implementierung
des Betriebsschritts 412 ist und als solcher nicht einschränkend für den Umfang
oder den Grundgedanken der Erfindung ausgelegt werden. Der Prozess 800 beginnt
bei 802, indem der anfordernde Client eine Zugriffsanforderung
auf eine geschützte
Ressource initiiert. Nachdem die geschützte Ressource die Ressourcenzugriffsanforderung
bei 804 empfängt,
validiert und verifiziert der Authentisierungs-Server die zugeordnete
Berechtigung, die der geschützten
Ressource zusammen mit der Zugriffsanforderung bei 806 überreicht
wurde. Wenn die Validierung und Verifikation als nicht erfolgreich bei 808 erachtet
worden sind, dann wird ein Zugriff bei 810 versagt, andernfalls
wird dann eine Bestimmung bei 812 ausgeführt, ob
die Berechtigung die richtigen gewährten Privilegien aufweist.
Wenn die richtigen Privilegien nicht gewährt sind, wird der Zugriff
bei 810 versagt, andernfalls wird dem anfordernden Client
ein Zugriff auf die geschützte
Ressource bei 814 gewährt.
-
9 veranschaulicht
ein Computersystem 900, das eingesetzt werden kann, um
die vorliegende Erfindung zu implementieren. Das Computersystem 900 oder,
spezifischer die CPUs 902 kann angeordnet sein, eine virtuelle
Maschine zu unterstützen,
wie von Durchschnittsfachleuten erkannt werden wird. Wie es im Stand
der Technik altbekannt ist, wirkt ein ROM 904, Daten und
Instruktionen unidirektional zu den CPUs 902 zu übertragen,
während
ein RAM 906 typischer Weise verwendet wird, um Daten und
Instruktionen auf eine bidirektionale Weise zu übertragen. Die CPUs 902 können allgemeine
jedwede Anzahl von Prozessoren einschließen. Beide primären Speichervorrichtungen 904, 906 können jedwedes geeignete
computerlesbare Medium einschließen. Ein zweites Speichermedium 908,
das typischer Weise eine Massenspeichervorrichtung ist, ist auch
bidirektional mit den CPUs 902 gekoppelt und stellt eine zusätzliche
Datenspeicherkapazität
bereit. Die Massenspeichervorrichtung
908 ist ein computerlesbares Medium,
das verwendet werden kann, um Programme einschließlich eines
Computercodes, Daten und dergleichen zu speichern. Typischer Weise
ist die Massenspeichervorrichtung 908 ein Speichermedium
wie etwa eine Festplatte oder ein Band, welches im allgemeinen langsamer
als die primären
Speichervorrichtungen 904, 906 ist. Eine Massenspeichervorrichtung 908 kann
die Form eines Magnet- oder Papierbandlesers oder einer anderen
altbekannten Vorrichtung annehmen. Es wird erkannt werden, das die Information,
die innerhalb der Massenspeichervorrichtung 908 gehalten
wird, in geeigneten Fällen
auf eine standardisierte Weise als ein Teil eines RAM 906 als
ein virtueller Speicher eingeschlossen sein kann. Eine spezifische
primäre
Speichervorrichtung 904 wie etwa eine CD-ROM kann auch
Daten unidirektional zu den CPUs 902 weitergeben.
-
Die CPUs 902 sind auch mit
einer oder mehreren Eingangs-/Ausgangsvorrichtungen 910 verbunden,
die Vorrichtungen wie etwa Videomonitore, Trackballs, Mäuse, Tastaturen,
Mikrofone, berührungsempfindliche
Anzeigen, Übertragerkartenleser, Magnet-
oder Papierbandleser, Tafeln, Stifte, Sprach- oder Handschrift-Erkennungseinrichtungen
oder andere altbekannte Eingabevorrichtungen wie beispielsweise
natürlich
andere Computer einschließen können, aber
nicht darauf beschränkt
sind. Schließlich
können
die CPUs 902 wahlweise mit einem Computer oder einem Telekommunikationsnetz,
z. B. einem Internet-Netz oder einem Intranet-Netz unter Verwendung
einer Netzverbindung, wie allgemein bei 912 gezeigt, gekoppelt
sein. Mit einer derartigen Netzverbindung wird erwogen, dass die
CPUs 902 eine Information von dem Netz empfangen könnten, oder
eine Information an das Netz in dem Verlaufe eines Durchführens der
oben beschriebenen Verfahrensschritte ausgeben könnten. Eine derartige Information,
die oft als eine Sequenz von Instruktionen, die unter Verwendung
der CPUs 902 auszuführen sind,
dargestellt wird, kann von einem Netz empfangen oder an dieses ausgegeben
werden, beispielsweise in der Form eines Computerdatensignals, das in
einer Trägerwelle
enthalten ist. Die oben beschriebenen Vorrichtungen und Materialien
werden Durchschnittsfachleuten auf dem Gebiet der Computerhardware- und Software vertraut
sein.
-
Obwohl nur einige wenige Ausführungsformen
der vorliegenden Erfindung beschrieben worden sind, ist zu verstehen,
dass die vorliegende Erfindung in vielen anderen spezifischen Formen
verwirklicht werden kann, ohne von dem Umfang der vorliegenden Erfindung
abzuweichen.
-
Obwohl die Verfahren eines Bereitstellens von
Plattformübergreifenden
Sicherheitsprotokollen gemäß der vorliegenden
Erfindung insbesondere für die
Implementierung bezüglich
einer JavaTM-basierten Umgebung geeignet
sind, können
die Verfahren allgemein auf jedwede geeignete Objekt-basierte Umgebung
angewandt werden. Insbesondere sind die Verfahren zur Verwendung
in Plattform-unabhängigen
Objekt-basierten Umgebungen geeignet. Es sei darauf hingewiesen,
dass die Verfahren auch in manchen verteilten Objekt-orientierten
Systemen implementiert werden können.
-
Während
die vorliegende Erfindung beschrieben worden ist, mit einem Computersystem verwendet
zu werden, das einen zugeordneten WEB-Browser aufweist, sollte erkannt
werden, dass die vorliegende Erfindung allgemein auf jedwedem geeigneten
Objekt-orientierten Computersystem implementiert werden kann. Deswegen
sind die vorliegenden Beispiel als veranschaulichend und nicht einschränkend zu
betrachten, und die Erfindung ist nicht auf die hierin gegebenen
Details beschränkt,
sondern kann innerhalb des Umfangs der angehängten Ansprüche modifiziert werden.