-
GEBIET
-
Die
vorliegende Erfindung beschreibt eine Sicherheitsarchitektur zur
Integration von Firmeninformationssystemen mit der J2EE-Plattform
(Java 2 Enterprise Edition-Plattform).
Die Sicherheitsarchitektur fügt
für die
Integration von Firmeninformationssystemen spezifische Sicherheitsdetails
zu den Sicherheitsanforderungen hinzu, die in anderen J2EE-Spezifikationen
festgelegt sind.
-
HINTERGRUND
-
Ein
Unternehmen ist bei seinen geschäftlichen
Aktivitäten
in kritischem Maße
abhängig
von den Informationen in seinem Firmeninformationssystem (EIS – Enterprise
Information System). Ein Verlust oder eine Ungenauigkeit von Informationen
oder ein unbefugter Zugriff auf das EIS können für ein Unternehmen sehr kostspielig
sein. Ein EIS kann gegen solche Sicherheitsbedrohungen unter Verwendung
von Mechanismen geschützt
werden, die das Identifizieren und Authentifizieren von Principalen,
das Durchführen
von Autorisierungs- und Zugriffskontrollen zur Bestimmung dessen,
ob ein Principal auf einen Anwendungsserver und/oder ein EIS zugreifen
darf, und das Bereitstellen einer sicheren Kommunikation zwischen
einem Anwendungsserver und einem EIS einschließen. Die Kommunikation über unsichere
Verbindungen kann unter Verwendung eines Protokolls (zum Beispiel
Kerberos) geschützt
werden, das Authentifizierungs-, Integritäts- und Geheimhaltungsdienste
bereitstellt. Die Kommunikation kann auch unter Verwendung einer
sicheren Verbindung (zum Beispiel SSL) abgesichert werden.
-
Ein
Principal ist eine Einheit, die durch einen Authentifizierungsmechanismus
authentifiziert werden kann, der in einem Unternehmen eingesetzt
wird. Ein Principal wird mit einem Principal-Namen identifiziert
und anhand von Authentifizierungsdaten authentifiziert. Der Inhalt
und das Format des Principal-Namens und der Authentifizierungsdaten
richten sich nach dem jeweiligen Authentifizierungsmechanismus.
-
Mit
einem Principal ist typischerweise eine Reihe von Sicherheitsattributen
verbunden. Diese Sicherheitsattribute beziehen sich auf die Authentifizierungs-
und Autorisierungsmechanismen. Beispiele sind unter anderem Sicherheitsrollen
und Berechtigungen (für
Sicherheits-Principale) und Berechtigungsnachweise für einen
Principal. Ein Berechtigungsnachweis enthält oder verweist auf Sicherheitsinformationen,
die einen Principal gegenüber
weiteren Diensten authentifizieren können. Ein Principal erhält einen
Berechtigungsnachweis bei der Authentifizierung oder von einem anderen
Principal, der ihm die Verwendung seines Berechtigungsnachweises
erlaubt (Principal-Delegation). Ein Endbenutzer ist eine Einheit
(Mensch oder Dienst), die als Quelle für eine Anfrage an eine Anwendung
fungiert. Ein Endbenutzer ist als ein Subjekt angegeben, wie es im
Rahmen des Java-Authentifizierungs- und Autorisierungsservice (JAAS)
festgelegt ist.
-
Ein
einleitender Principal ist ein Endbenutzer, der direkt mit der Anwendung
im Dialog steht. Ein Endbenutzer kann sich entweder mit einem Web-Client
oder mit einem Anwendungs-Client authentifizieren. Ein Aufrufer-Principal
ist ein Principal, der während
eines Verfahrensaufrufs mit einer Anwendungskomponente verbunden
ist. Ein Betriebsmitel-Principal ist ein Sicherheits-Principal,
unter dessen Sicherheitskontext eine Verbindung zu einer EIS-Instanz
hergestellt wird. Eine Sicherheitsdomäne ist ein Bereich, innerhalb
dessen bestimmte gemeinsame Sicherheitsmechanismen und Vorschriften
festgelegt sind. Ein Unternehmen kann mehr als eine Sicherheitsdomäne umfassen.
Daher können
sich ein Anwendungsserver und ein EIS in derselben oder in unterschiedlichen
Sicherheitsdomänen
befinden. In einer verwalteten Umgebung werden Anwendungskomponenten
in Web- oder EJB-Containern eingesetzt. Wenn ein Verfahren auf einer
Komponente aufgerufen wird, wird der mit der Komponente verbundene
Principal als Aufrufer-Principal bezeichnet.
-
Eine
Anwendungskomponente fordert eine Verbindung zu einer EIS-Instanz
unter dem Sicherheitskontext eines Betriebsmittel-Principals an.
Die Beziehung zwischen einem Betriebsmittel-Principal und seinen Attributen
und einem Aufrufer- oder einleitenden Principal ist davon abhängig, wie
die Principal-Delegation in einer Betriebsumgebung konfiguriert
ist.
-
Das
Einrichten einer neuen physikalischen Verbindung erfordert ein Anmelden
bei einer EIS-Instanz. Eine Änderung
des Sicherheitskontextes auf einer bestehenden physikalischen Verbindung
kann ebenfalls ein Anmelden auf dem EIS erfordern, was als erneute
Authentifizierung bezeichnet wird. Beim Anmelden auf dem EIS wird
im Allgemeinen ein Betriebsmittel-Principal festgelegt, unter dessen
Sicherheitskontext eine physikalische Verbindung zu einem EIS hergestellt
wird. Beim Anmelden auf dem EIS wird auch ein Betriebsmittel-Principal
authentifiziert, sofern dieser nicht bereits authentifiziert ist;
außerdem
wird eine sichere Verbindung zwischen dem Anwendungsserver und dem
EIS hergestellt, und die Zugriffssteuerung auf die EIS-Betriebsmittel
wird durchgeführt.
-
Es
gibt verschiedene Szenarien für
die EIS-Integration. Diese Szenarien konzentrieren sich auf die
Sicherheitsaspekte von Transaktionen. Eine J2EE-Anwendung ist eine
mehrstufige, internetfähige
Anwendung, die auf Firmeninformationssysteme (EIS) zugreift. Sie
besteht aus einer oder mehreren Anwendungskomponenten – Enterprise
Java Beans (EJB), Java Server Pages (JSP) und Servlets –, die in
Containern eingesetzt werden. Diese Container können Web-Container sein, die
JSP, Servlets und statische HTML-Seiten (HyperText Markup Language)
enthalten. Die Container können
aber auch EJB-Container sein, die EJB-Komponenten enthalten, sowie
Anwendungs-Client-Container,
die eigenständige
Anwendungs-Clients enthalten. In den folgenden Szenarien ist die
Beschreibung der Architektur und Sicherheitsumgebungen hinsichtlich
des Umfangs nur als Illustration zu verstehen.
-
1A zeigt
eine Anwendung, bei der ein Händler
ein Portal im World Wide Web (Internet) oder einem anderen Computernetz
betreibt, wobei Kunden auf das Portal zugreifen und von dem Händler angebotene
Produkte kaufen können.
Ein solches Portal wird hier als eStore bezeichnet. Das Unternehmen
A unterhält
eine eStore-Anwendung auf der Basis der J2EE-Plattform. Die eStore-Anwendung
besteht aus EJB und JSP/Servlets, die zusammenwirken, um die Gesamtfunktionalität der Anwendung
bereitzustellen. Die Anwendung nutzt auch eine eStore-Datenbank
zur Speicherung von Daten in Zusammenhang mit einem Produktkatalog,
Einkaufswagenfunktionen, Kundenregistrierung und -profilen, Transaktionsstatus
und -aufzeichnungen sowie Bestellstatus.
-
Mit
einem Webbrowser leitet ein Kunde eine Online-Transaktion mit der
eStore-Anwendung
ein. Die Online-Transaktion besteht aus einer Reihe von Kundenaktionen.
Im Allgemeinen blättert
ein Kunde den Online-Katalog durch, wählt die Produkte für den Kauf
aus, verbindet die ausgewählten
Produkte mit einer Einkaufswagenfunktion, gibt einen Benutzernamen
und ein Passwort ein, um eine sichere Transaktion zu starten, macht
die für
die Bestellung nötigen
Angaben und schickt die Bestellung ab.
-
Zur
Unterstützung
dieses eCommerce-Szenarios konfiguriert der für das Portal des Händlers zuständige Systemadministrator
eine eigene Sicherheitsdomäne
(mit spezieller Sicherheitstechnik und Sicherheitsrichtlinien) für die eStore-Anwendung.
Eine Firewall schützt
diese Sicherheitsdomäne
gegen unbefugten Zugriff aus dem Internet. Die Konfiguration der
Sicherheitsdomäne
für die
eStore-Anwendung umfasst einen sicheren Internet-Zugriff auf die
eStore-Anwendung. Der sichere Internet-Zugriff wird auf der Grundlage
der Anforderungen in der J2EE-Spezifikation eingerichtet.
-
Der
Systemadministrator richtet eine Datenbank zur Verwaltung der ständigen Daten
für die
eStore-Anwendung ein. Was die Sicherheit angeht, wird das Datenbanksystem
mit einer unabhängigen
Sicherheitsdomäne
konfiguriert. Diese Domäne
hat eigene Benutzer-Accounts sowie eigene Sicherheitsrichtlinien und
Mechanismen für
die Authentifizierung und Autorisierung. Der Systemadministrator
richtet einen eigenen Datenbank-Account (EStoreUser) zur Handhabung
von Datenbanktransaktionen ein. Die Datenbanktransaktionen entsprechen
den verschiedenen vom Kunden angestoßenen Dialogaktionen mit der
eStore-Anwendung. Der Administrator richtet auch einen weiteren
Datenbank-Account (EStoreAdministrator) zur Verwaltung der Datenbank
im Namen des eStore-Administrators ein. Dieser Verwaltungs-Account
hat eine höhere
Ebene von Zugriffsberechtigungen. Zur Erleichterung einer besseren
Skalierung der eStore-Anwendung
kann sich der Systemadministrator außerdem für die Einrichtung eines Lastausgleichs
von Datenbankoperationen über mehrere
Datenbanken hinweg entscheiden. Außerdem kann er die zugehörigen Daten
und Transaktionen basierend auf verschiedenen Kriterien für die Leistungsoptimierung
auf mehrere Datenbank-Accounts verteilen.
-
Einsatz
-
Beim
praktischen Einsatz der eStore-Anwendung richtet der Deployer die
Zugriffskontrolle für
alle authentifizierten Kunden-Accounts ein, das heißt die Kunden-Accounts, die Online-Transaktionen über das
Internet auf der Grundlage einer einzelnen Rolle (eStoreUserRole)
durchführen.
Der Deployer konfiguriert das Betriebsmitteladapterelement mit den
Sicherheitsinformationen, die für
die Einrichtung von Datenbankverbindungen erforderlich sind.
-
Diese
Sicherheitsinformationen sind der Datenbank-Account StoreUser und
dessen Passwort. Der Deployer richtet die Principal-Abbildung für den Zugriff
auf das Da tenbanksystem ein. Die Einsatzkonfiguration stellt sicher,
dass alle Datenbankzugriffe immer unter dem Sicherheitskontext des
Datenbank-Accounts EStoreUser erfolgen. Dieser Datenbank-Account
wird als Betriebsmittel-Principal bezeichnet. Alle authentifizierten Kunden
(als einleitende Principale bezeichnet) werden auf einen einzigen
Datenbank-Account EStoreUser abgebildet. Die eStore-Anwendung verwendet
einen implementierungsspezifischen Mechanismus zur Verknüpfung von
Datenbanktransaktionen (durchgeführt
unter einem einzelnen Datenbank-Account) mit der eindeutigen Kennung
(Sozialversicherungsnummer oder eStore-Kundenkennung) des einleitenden
Principals. Um sicherzustellen, dass der Datenbankzugriff ordnungsgemäß autorisiert
worden ist, führt
die eStore-Anwendung auch eine Zugriffskontrolle auf der Grundlage
der Rolle des einleitenden Principals durch. Weil alle einleitenden
Principale auf eine einzige Rolle abgebildet werden, ist dies in
der Praxis ein einfacher Fall. Dieses Szenario beschreibt eine n-zu-1-Abbildung,
wobei n eine beliebige Zahl sein kann. Je nach den Anforderungen einer
Anwendung kann der Deployer die Principal-Abbildung jedoch auch
anders als auf eine n-zu-1-Abbildung einstellen. Der Deployer kann
zum Beispiel jede Rolle auf einen einzigen Betriebsmittel-Principal
abbilden, wobei eine Rolle einem einleitenden Principal entspricht.
Hieraus ergibt sich eine Abbildung von [m Principalen und n Rollen]
auf [n Betriebsmittel-Principale], wobei m >= n. Bei einer solchen Principal-Abbildung muss der Deployer
sicherstellen, dass die Zugriffsberechtigungen der abgebildeten
Principale nicht kompromittiert werden.
-
1B zeigt
eine Mitarbeiter-Selbstbedienungsanwendung. Das Unternehmen B hat
eine Mitarbeiter-Selbstbedienungsanwendung (ESS) auf der Basis der
J2EE-Plattform entwickelt. Diese Anwendung unterstützt eine
Internet-Schnittstelle zu vorhandenen Personal- oder HR-Anwendungen,
die durch das ERP-System von Hersteller X unterstützt werden.
Die ESS-Anwendung stellt auch zusätzliche geschäftliche
Prozesse bereit, die speziell auf die Wünsche des Unternehmens B abgestimmt
sind. Die Anwendungsebene besteht aus EJB und JSP, die die individuelle
Anpassung der geschäftlichen
Prozesse ermöglichen
und eine standardisierte Internet-Schnittstelle im Unternehmen unterstützen.
-
Mit
der ESS-Anwendung kann ein Mitarbeiter (unter den Rollen von Manager,
Personalmanager und Mitarbeiter) verschiedene HR-Funktionen durchführen, einschließlich Personalinformationsmanagement, Lohnabrechnungsmanagement,
Vergütungsmanagement,
Leistungsverwaltung, Reisemanagement und Personalkostenplanung.
-
Die
Informationsservice-Abteilung (IS) des Unternehmens B hat ihre HR
ESS-Anwendung und
ihr ERP-System in einer sicheren Umgebung an einem physikalischen
Standort eingerichtet. Mitarbeiter des Unternehmens haben Zugriff
auf die HR-Anwendung. Der Zugriff basiert auf den Rollen und Zugriffsberechtigungen
der Mitarbeiter. Darüber
hinaus kann der Zugriff auf die Anwendung nur über das Intranet des Unternehmens
erfolgen.
-
Zur
Unterstützung
der verschiedenen Interaktions-Szenarien in Zusammenhang mit der
ESS-Anwendung richtet der Systemadministrator eine durchgängige, auf
Kerberos basierende Sicherheitsdomäne für diese Anwendungsumgebung
ein. Der Systemadministrator konfiguriert die Sicherheitsumgebung
zur Unterstützung
einer einmaligen Anmeldung; der Benutzer meldet sich nur einmal
an und kann dann auf alle von der ESS-Anwendung und ihrem zugrundeliegenden
ERP-System bereitgestellten Dienste zugreifen. Das einmalige Anmelden
wird durch die spezifischen Sicherheitsmechanismen und Richtlinien
für die
zugrundeliegende Sicherheitstechnik erreicht, wobei es sich in diesem
Fall um Kerberos handelt. Der Administrator des ERP-Systems konfiguriert
alle berechtigten Mitarbeiter als gültige Benutzer-Accounts im
ERP-System.
-
Der
Administrator richtet verschiedene Rollen (Manager, Personalmanager
und Mitarbeiter), Standardpasswörter
und Zugriffsberechtigungen ein. Diese Sicherheitsinformationen werden
synchron mit dem unternehmensweiten Verzeichnisservice geführt, der
von Kerberos zur Durchführung
der anfänglichen
Authentifizierung von Endbenutzern verwendet wird.
-
Beim
praktischen Einsatz der ESS-Anwendung legt der Deployer eine Standard-Delegationspolitik
des Client-Identitätswechsels
für das
Anmelden im EIS fest. In diesem Fall wissen der Anwendungsserver
und das ERP-System, dass es einleitende Principal ist, der auf ihre
jeweiligen Dienste zugreift, und sie führen die Zugriffskontrolle
auf der Basis dieses Wissens durch. In diesem Szenario verweisen
sowohl der einleitende Principal als auch der Betriebsmittel-Principal
auf denselben Principal. Dieser gemeinsame Principal wird unter Verwendung
von Kerberos authentifiziert, und seine Kerberos-Berechtigungsnachweise
gelten in den Sicherheitsdomänen
sowohl der Anwendung als auch des ERP-Systems. Der Deployer richtet
die Zugriffskontrolle für
alle authentifizierten Mitarbeiter (einleitender Principal) basierend
auf den konfigurierten Rollen – Manager, Personalmanager
und Mitarbeiter – ein.
Wenn das ERP-System Kerberos nicht unterstützt, wird ein alternatives
Szenario verwendet. Der Deployer oder Anwendungsserver-Administrator
richtet eine automatische Abbildung von Kerberos-Berechtigungsnachweisen (für den einleitenden
Principal) auf gültige
Berechtigungsnachweise (für
denselben Principal) in der Sicherheitsdomäne des ERP-Systems ein. Hierbei
ist zu beachten, dass der Anwendungsserver keine Abbildung der Berechtigungsnachweise
durchführt,
wenn das ERP-System Kerberos unterstützt.
-
Ein
Mitarbeiter leitet ein erstes Anmelden auf seinem Client-Desktop
ein. Er gibt seinen Benutzernamen und sein Passwort ein. Im Rahmen
dieses ersten Anmeldens wird der Mitarbeiter mit Kerberos KDC authentifiziert.
Nach erfolgreicher Anmeldung startet der Mitarbeiter seine Desktop-Umgebung.
Er bringt seinen Webbrowser auf die URL für die auf dem Anwendungsserver
laufende ESS-Anwendung. Zu diesem Zeitpunkt authentifiziert der
einleitende Principal C sich selbst gegenüber dem Anwendungsserver und
generiert einen Sessionschlüssel
mit dem Anwendungsserver. Die ESS-Anwendung ist so eingerichtet,
dass sie die Identität des
einleitenden Principals C wechselt, wenn sie auf das ERP-System
zugreift, das auf einem anderen Server läuft.
-
Obwohl
der Anwendungsserver direkt mit dem ERP-System verbunden ist, wird
der Zugriff auf das ERP-System im Namen des einleitenden Principals
angefragt. Damit dies funktioniert, muss der Principal C seine Identität und seinen
Kerberos-Berechtigungsnachweis an den Anwendungsserver delegieren
und dem Anwendungsserver erlauben, Anfragen an das ERP-System im
Namen des Principals C zu machen.
-
In 1C hat
das Unternehmen C eine integrierte Einkaufsanwendung, die es Mitarbeitern
ermöglicht,
eine internetbasierte Oberfläche
zur Durchführung
mehrerer Einkaufstransaktionen zu benutzen. Ein Mitarbeiter kann
den gesamten Beschaffungsprozess verwalten, von der Einrichtung
eines Beschaffungsantrags bis zur Genehmigung der Rechnung. Die
Einkaufsanwendung ist auch mit den bestehenden Finanzanwendungen
des Unternehmens integriert, so dass die abrechnungstechnischen
und finanziellen Aspekte der Beschaffungsabläufe verfolgt werden können.
-
Anwendungen
wie zum Beispiel in 1C sind auf der Grundlage der
J2EE-Plattform entwickelt
und eingesetzt worden und bestehen aus EJB und JSP. Die EJB-Komponenten ermöglichen
die Integration über die
unterschiedlichen Anwendungen hinweg – die Logistikanwendung von
einem anderen Hersteller (diese Anwendung stellt integrierte Einkaufs-
und Bestandsverwaltungsfunktionen bereit) und die Finanzbuchhaltungsanwendungen
(die Anwendungen, die von dem älteren
System von Hersteller Y unterstützt
werden).
-
Das
Unternehmen C ist typischerweise ein großes, dezentrales Unternehmen
mit geografisch verteilten Geschäftseinheiten
und Abteilungen. In diesem Szenario verwalten unterschiedliche IS-Abteilungen
das ERP-System X und das Vorläufersystem
Y. Darüber
hinaus können
das ERP-System X und das Vorläufersystem
Y in gesicherten Rechenzentren an unterschiedlichen geografischen
Standorten eingerichtet sein. Zuletzt ist die integrierte Einkaufsanwendung
an einem anderen geografischen Standort als das ERP-System X und das
Vorläufersystem
Y eingerichtet worden. Das ERP-System X und das Vorläufersystem
Y können
sich auch in unterschiedlichen Sicherheitsdomänen befinden, unterschiedliche
Sicherheitstechniken verwenden und eigene spezifische Sicherheitsvorschriften
und -mechanismen haben. Die integrierte Einkaufsanwendung ist in einer
Sicherheitsdomäne
eingerichtet, die sich von der für
das ERP-System X und das Vorläufersystem
Y unterscheidet. Zur Unterstützung
der verschiedenen Interaktions-Szenarien
für diese
integrierte Einkaufsanwendung legt der ERP-Systemadministrator einen
eigenen Account hogisticsAppUser im ERP-System an, wobei ein Passwort
und spezielle Zugriffsberechtigungen für diesen Account benutzt werden.
Dieser Benutzer-Account
hat nur Zugriff auf die Logistikprozesse, die von der integrierten
Einkaufsanwendung benutzt werden. In gleicher Weise legt der Systemadministrator
einen eigenen Account FinancialAppUser für das Vorläufersystem an. Auch für diesen
Account richtet er das Passwort und spezielle Zugriffsberechtigungen
ein. Als Teil der Betriebsumgebung für den Anwendungsserver konfiguriert
der Anwendungsserver-Administrator den Zugriff auf ein unternehmensweites
Verzeichnis. Dieses Verzeichnis enthält Sicherheitsinformationen
(Name, Passwort, Rolle und Zugriffsberechtigungen) für alle Mitarbeiter
im Unternehmen. Es wird zur Authentifizierung und Autorisierung
von Mitarbeitern verwendet, die die Einkaufsanwendung aufrufen.
Aufgrund der physikalischen Trennung in diesem Szenario erfolgt
der Zugriff auf die EIS-Systeme X und Y entweder über ein
sicheres privates Netz oder über
das Internet. Dies erfordert die Herstellung einer sicheren Verbindung
zwischen der Anwendungsserver-Domäne und den EIS-Systemen. Der
Anwendungsserver stellt die sichere Verbindung für einen Principal her, indem
zunächst
der Principal gegenüber
der EIS-Zieldomäne
authentifiziert wird. Danach gibt er die resultierenden Berechtigungsnachweise
des authentifizierten Principals an das EIS weiter und stellt einen
gemeinsam benutzten Sicherheitskontext her, so dass Mechanismen
für Datenintegrität und Geheimhaltung
die Datenintegrität
von Nachrichten zwischen dem Anwendungsserver und dem EIS schützen können.
-
Wie
vorstehend gezeigt und erläutert,
sind beim Sicherheitsmanagement für ein breites Spektrum von Anwendungs-Szenarien
zahlreiche Details zu beachten. Gegenwärtig gibt es keinen Standard
für mehrere
Anwendungen. Dies macht das Sicherheitsmanagement zu einem arbeitsintensiven
Aspekt der Anwendungsentwicklung, wobei viele nahezu gleiche Details
individuell für
einzelne Anwendungen angepasst werden müssen. Für Entwickler, die an zahlreichen
Anwendungen arbeiten, führt
das Fehlen von Sicherheitsstandards zu Doppelarbeit und ineffizienter
Verwendung von Betriebsmitteln.
-
Nach
einem Aspekt der vorliegenden Erfindung wird ein Verfahren zum Aufbau
einer sicheren Verbindung zwischen einer Anwendungskomponente und
einem Firmeninformationssystem nach Anspruch 1 bereitgestellt.
-
Nach
einem zweiten Aspekt der vorliegenden Erfindung wird ein Computersystem
zum Aufbauen einer sicheren Verbindung zwischen einer Anwendungskomponente
und einem Firmeninformationssystem nach Anspruch 2 bereitgestellt.
-
Die
vorliegende Erfindung geht auf die vorstehenden Probleme ein, indem
sie eine Sicherheitsarchitektur bereitstellt, die das durchgängige Sicherheitsmodell
für J2EE-basierte Anwendungen
erweitert, um die Integration mit EIS-Systemen auf der Basis einer
Connector-Architektur einzubeziehen. Die Sicherheitsarchitektur
nach der vorliegenden Erfindung unterstützt die Authentifizierung und
Autorisierung von Benutzern, die auf EIS-Systeme zugreifen, hält die Sicherheitsarchitekturtechnik
neutral und ermöglicht
die Unterstützung
eines bestimmten Sicherheitsvertrags durch verschiedene Sicherheitstechniken.
Darüber
hinaus unterstützt
die Sicherheitsarchitektur nach der vorliegenden Erfindung eine
Reihe von EIS-Systemen mit einem unterschiedlichen Maß an Sicherheitsunterstützung und
bestehenden Sicherheitsumgebungen sowie die Sicherheitskonfiguration
für ein
Betriebsmitteladapterelement in einer Betriebsumgebung. Die Sicherheitsarchitektur
nach der vorliegenden Erfindung bewahrt auch die Transparenz zwischen
dem Sicherheitsmodell für
die connector-basierte EIS-Integration und einem Anwendungskomponenten-Anbieter.
Dies schließt
die Unterstützung
für ein einmaliges
Anmelden über
mehrere EIS-Systeme hinweg ein.
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
1A, 1B und 1C zeigen
bekannte EIS-Systemintegrationen.
-
2 zeigt
ein übergeordnetes
Blockdiagramm der in Zusammenhang mit der vorliegenden Erfindung verwendeten
Hardware-Komponenten.
-
3 zeigt
die Schnittstellen in einer Ausführungsform
nach der vorliegenden Erfindung.
-
4 zeigt
die wichtigsten Funktionskomponenten einer Ausführungsform nach der vorliegenden
Erfindung.
-
5 und 6 zeigen
die wichtigsten Funktionskomponenten einer alternativen Ausführungsform nach
der vorliegenden Erfindung.
-
7 bis 12 zeigen
verschiedene Betriebsszenarien im Hinblick auf einen JAAS-Rahmen
bei den alternativen Ausführungsformen
nach der vorliegenden Erfindung.
-
AUSFÜHRLICHE
BESCHREIBUNG
-
2 zeigt
ein übergeordnetes
Blockdiagramm der typischerweise verwendeten Hardware nach einer Ausführungsform
der vorliegenden Erfindung. Der Computer 150 umfasst einen
Prozessor 152 mit einer Zentraleinheit (CPU) und zugehörigen integrierten
Schaltungen. Der Speicher 154 kann RAM- und NVRAM-Speicher
wie etwa Flash-Speicher
umfassen, um die Speicherung der von dem Prozessor 152 ausgeführten Software-Module
zu erleichtern, zum Beispiel die Sicherheitsarchitektur nach der
vorliegenden Erfindung (3 und 4). Außerdem umfasst
der Computer 150 eine Tastatur 158, eine Zeigevorrichtung 160 und
einen Monitor 162.
-
Massenspeichergeräte wie etwa
ein Festplattenlaufwerk 164 und ein CD-ROM-Laufwerk 166 können ebenfalls
in dem Computer 150 vorgesehen sein, um die Speicherung
der Sicherheitsarchitektur und der zugehörigen Dateien zu ermöglichen.
Der Computer 150 kann über
ein Modem 168 und eine Telefonleitung 170 mit
anderen Computern kommunizieren, um die Fernsteuerung des Sicherheitssystems
nach der vorliegenden Erfindung zu ermöglichen, mit anderen Benutzern
in Dialog zu treten oder Dateien zu benutzen, die an anderen Orten
gespeichert sind. Anstelle des Modems 168 und der Telefonleitung 170 können auch
andere Medien verwendet werden, zum Beispiel eine Direktverbindung
oder eine schnelle Datenleitung. Die vorstehend beschriebenen Komponenten
können
für den
Betrieb durch einen Kommunikationsbus 172 miteinander verbunden sein.
-
Authentifizierungsmechanismus
-
Ein
Anwendungsserver und ein EIS arbeiten zusammen, um sicherzustellen,
dass ein Betriebsmittel-Principal, der eine Verbindung zu einem
zugrundeliegenden EIS herstellt, ordnungsgemäß authentifiziert worden ist.
Die Connector-Architektur identifiziert üblicherweise unterstützte Authentifizierungsmechanismen wie
zum Beispiel einen einfachen auf einem Benutzer-Passwort basierenden
Authentifizierungsmechanismus, der spezifisch für ein EIS ist, sowie auf Kerberos
basierende Authentifizierungsmechanismen. Ein Authentifizierungsmechanismus-Element
wird in dem Deployment-Deskriptor benutzt, um anzugeben, ob ein
Betriebsmitteladapterelement einen bestimmten Authentifizierungsmechanismus
unterstützt
oder nicht.
-
Principal-Delegation
-
Wenn
eine Anwendungskomponente eine Verbindung von einem Betriebsmitteladapterelement
anfordert, erfolgt die Verbindungsanfrage unter dem Sicherheitskontext
eines Betriebsmittel-Principals. Die Beziehung eines Betriebsmittel-Principals
und seiner Sicherheitsattribute zu einem einleitenden/Aufrufer-Principal richtet
sich danach, wie der Betriebsmittel-Principal vom Systemadministrator
oder Deployer eingerichtet worden ist. Der Deployer kann einen Betriebsmittel-Principal
auf der Basis der Nicht-Delegierung
einrichten: In diesem Fall weist ein Betriebsmittel-Principal seine
eigene Identität
und Sicherheitsattribute auf, unabhängig von der Identität eines
einleitenden/Aufrufer-Principals.
-
Ein
Deployer kann einen Betriebsmittel-Principal auch auf der Basis
des Identitätswechsels
einrichten. In diesem Fall handelt der Betriebsmittel-Principal
im Auftrag eines einleitenden/Aufrufer-Principals. Um im Auftrag
eines Aufrufer-Principals zu handeln, müssen die Identität des Aufrufers
und die Berechtigungsnachweise an das Betriebsmitteladapterelement
und das EIS weitergeleitet oder delegiert werden. Der Mechanismus,
mit dem dies erfolgt, ist spezifisch für einen Sicherheitsmechanismus
und die Implementierung des Anwendungsservers. Bei einigen Szenarien
kann ein Aufrufer-Principal
ein Delegierter eines einleitenden Principals sein. In diesem Fall
wechselt ein Betriebsmittel-Principal transitiv zur Identität eines
einleitenden Principals. Ein Principal-Delegationsmechanismus ist
typischerweise spezifisch für
einen Sicherheitsmechanismus. Kerberos unterstützt zum Beispiel einen Mechanismus
für das
Delegieren der Authentifizierung. Ein Anwendungsserver kann auch
einen Berechtigungsnachweis- Abbildungsmechanismus
unterstützen.
Dieser Mechanismus kann erforderlich sein, wenn ein Anwendungsserver
und das EIS unterschiedliche Authentifizierungsdomänen unterstützen. Der
einleitende Principal ist zum Beispiel authentifiziert worden und
hat Berechtigungsnachweise auf der Grundlage eines öffentlichen
Schlüsselzertifikats.
Die Sicherheitsumgebung für
das EIS wird mit auf Kerberos basierenden Authentifizierungsdiensten
konfiguriert. Der Anwendungsserver ist so konfiguriert, dass er
die mit dem einleitenden Principal verbundenen Berechtigungsnachweise
auf der Grundlage eines öffentlichen
Schlüsselzertifikats
auf die Kerberos-Berechtigungsnachweise für den Betriebsmittel-Principal
abbildet. Im Falle der Berechtigungsnachweis-Abbildung hat der abgebildete
Betriebsmittel-Principal dieselbe Identität wie der einleitende/Aufrufer-Principal.
-
Autorisierungsmodell
-
Eine
Autorisierungskontrolle zur Sicherstellung, dass ein Principal Zugriff
auf ein EIS-Betriebsmittel hat, kann entweder im EIS oder im Anwendungsserver
oder in beiden angewendet werden. Die Autorisierungskontrolle im
EIS-Zielsystem kann auf EIS-spezifische
Weise erfolgen und ist hier nicht beschrieben. Ein EIS kann seine
Politik für
die Zugriffskontrolle anhand seiner spezifischen Sicherheitsrollen
und Berechtigungen festlegen. Die Autorisierungskontrolle kann auch
auf der Anwendungsserver-Ebene erfolgen. Ein Anwendungsserver kann
einem Principal zum Beispiel erlauben, eine Verbindung zu einem
EIS nur dann aufzubauen, wenn der Principal hierzu autorisiert ist.
J2EE-Container (zum Beispiel EJB- und Servlet-Container) unterstützen sowohl
die programmatische als auch die deklarative Sicherheit, die zur
Festlegung der Autorisierungspolitik verwendet werden kann.
-
Die
Kommunikation zwischen einem Anwendungsserver und einem EIS kann
Sicherheitsbedrohungen (zum Beispiel Änderung von Daten und Datenverlust)
unterliegen. Solchen Bedrohungen kann durch Aufbau einer sicheren
Verbindung begegnet werden.
-
Eine
sichere Verbindung sind gemeinsam genutzte Sicherheitsinformationen,
die es einer Komponente auf dem Anwendungsserver ermöglichen,
sicher mit einem EIS zu kommunizieren. Das Herstellen einer sicheren
Verbindung kann mehrere Schritte umfassen: 1) Der Betriebsmittel-Principal
wird gegenüber
dem EIS authentifiziert und kann verlangen, dass sich der Ziel-Principal
in der EIS-Domäne
selbst gegenüber
dem An wendungsserver authentifiziert. Ein Ziel-Principal kann vom
Systemadministrator als ein Sicherheits-Principal eingerichtet werden,
der mit einer laufenden EIS-Instanz oder einem bestimmten EIS-Betriebsmittel
verbunden ist. 2) Aushandeln einer Qualität des Schutzes, zum Beispiel
Geheimhaltung oder Integrität.
3) Ein Paar miteinander kommunizierender Einheiten – Anwendungsserver
und EIS-Instanz – stellt
einen gemeinsamen Sicherheitskontext unter Verwendung der Berechtigungsnachweise
des Betriebsmittel-Principals
her. Der Sicherheitskontext kapselt gemeinsame Zustandsinformationen,
die erforderlich sind, damit die Kommunikation zwischen dem Anwendungsserver
und dem EIS durch Integritäts-
und Geheimhaltungsmechanismen geschützt werden kann. Beispiele
für gemeinsame
Zustandsinformationen im Rahmen eines Sicherheitskontexts sind Kryptografieschlüssel und
laufende Nachrichtennummern. Eine sichere Verbindung zwischen einem
Anwendungsserver und einem EIS wird immer durch die Betriebsmitteladapterelement-Implementierung
hergestellt. Es ist zu beachten, dass eine Betriebsmitteladapterelement-Bibliothek
in dem Adressbereich des Anwendungsservers läuft. Sobald eine sichere Verbindung
erfolgreich hergestellt ist, wird die Verbindung mit dem Sicherheitskontext
des Betriebsmittel-Principals verbunden. Danach erfolgen alle Aufrufe
auf Anwendungsebene für
die EIS-Instanz unter Verwendung der Verbindung unter dem Sicherheitskontext
des Betriebsmittel-Principals.
-
Anwendungskomponenten-Anbieter
-
Bei
Entwicklung und Einsatz von Anwendungskomponenten folgt ein Anwendungskomponenten-Anbieter
einem der Sicherheitsmodelle, die in den Spezifikationen für die J2EE-Komponentenmodelle
festgelegt sind: EJB-, JSP- oder Servlet-Spezifikation. Die EJB-Spezifikation
legt zum Beispiel die Anforderungen für einen Bean-Anbieter und Anwendungs-Assembler
zur Unterstützung
des Sicherheitsmodells für
EJB-Komponenten fest.
-
Aus
der Sicht eines Anwendungskomponenten-Anbieters haben die verschiedenen
J2EE-Komponentenmodelle die nachstehenden Merkmale gemeinsam: 1)
Der Anwendungskomponenten-Anbieter hält sich unveränderlich
fern von der Last der Sicherung seiner Anwendung und konzentriert
sich auf die Entwicklung der geschäftlichen Funktionen seiner
Anwendung. 2) Sicherheitsbewusste Anwendungskomponenten-Anbieter können eine
einfache programmatische Schnittstelle verwenden, um die Sicherheit
auf Anwendungsebene zu verwalten. Die programmatische Schnittstelle
ermöglicht
es ei nem Anwendungskomponenten-Anbieter, Entscheidungen für die Zugriffskontrolle
auf der Grundlage des Sicherheitskontexts, des Principals und/oder
der mit dem Aufrufer eines Verfahrens verbundenen Rolle zu programmieren
und das programmatische Anmelden bei einem EIS zu verwalten. 3)
Der Anwendungskomponenten-Anbieter legt die Sicherheitsanforderungen
für seine
Anwendung deklarativ in einem Deployment-Deskriptor fest. Die Sicherheitsanforderungen
umfassen Sicherheitsrollen, Verfahrensberechtigungen und das Authentifizierungskonzept
für die
Anmeldung beim EIS. 4) Qualifiziertere Rollen – Anwendungsserver-Hersteller,
Connector-Anbieter, Deployer, Systemadministrator – übernehmen
die Verantwortung für
die Erfüllung
der Sicherheitsanforderungen insgesamt (gemäß Festlegung in den Deployment-Deskriptoren
des Betriebsmitteladapterelements und der Komponenten) und die Verwaltung
der Sicherheitsumgebung.
-
Eine
Anwendungskomponente fordert den Aufbau einer Verbindung unter dem
Sicherheitskontext eines Betriebsmittel-Principals an. Der Sicherheitskontext
umfasst Sicherheitsattribute – Rolle,
Zugriffsberechtigungen und Autorisierungsstufe für einen Betriebsmittel-Principal.
Sobald eine Verbindung erfolgreich hergestellt ist, wird die Verbindung
mit dem Sicherheitskontext des Betriebsmittel-Principals verbunden.
Danach erfolgen alle Aufrufe auf Anwendungsebene für die EIS-Instanz
unter Verwendung der Verbindung unter dem Sicherheitskontext des
Betriebsmittel-Principals.
-
Ein
Anwendungskomponenten-Anbieter hat die folgenden beiden Möglichkeiten
bezüglich
der Anmeldung beim EIS: 1) Der Anwendungskomponenten-Anbieter erlaubt
es dem Deployer, die Principal-Delegation und die EIS-Anmeldeinformationen
einzurichten. Der Deployer richtet zum Beispiel den Benutzernamen
und das Passwort für
den Aufbau einer Verbindung zu einer EIS-Instanz ein. 2) Der Anwendungskomponenten-Anbieter
meldet sich auf einem EIS aus dem Komponenten-Code an, indem er
explizit Sicherheitsinformationen für einen Betriebsmittel-Principal
angibt. Ein Anwendungskomponenten-Anbieter verwendet ein Deployment-Deskriptorelement
(Beispiel: res-auth für
EJB-Komponenten), um die Anforderung für einen der beiden vorstehenden
Ansätze
anzugeben. Wenn zum Beispiel das res-auth-Element auf Komponente
eingestellt ist, führt
der Komponenten-Code ein programmatisches Anmelden auf dem EIS durch;
lautet das res-auth-Element hingegen Container, übernimmt der Anwendungsserver
die Zuständigkeit
für die
Einrichtung und Verwaltung der Anmeldung beim EIS.
-
Containerverwaltetes Anmeldeszenario
-
Der
Anwendungskomponenten-Anbieter stellt das Deployment-Deskriptorelement
res-auth auf Container ein, damit der Anwendungsserver die Zuständigkeit
für die
Verwaltung der Anmeldung beim EIS übernimmt. Der Deployer richtet
die Principal-Abbildung ein, damit der Benutzer-Account für die Verbindung
zu der EIS-Instanz immer eStoreUser lautet. Der Deployer konfiguriert
auch die Authentifizierungsdaten, die zur Authentifizierung von
eStoreUser gegenüber
dem EIS nötig
sind. Der Komponenten-Code
ruft das Verfahren getConnection auf der ConnectionFactory-Instanz
ohne sicherheitsrelevante Parameter auf. Die Komponente verlässt sich
darauf, dass der Anwendungsserver die Anmeldung bei der EIS-Instanz
auf der Grundlage der vom Deployer konfigurierten Sicherheitsinformationen
verwaltet. Das nachstehende Codesegment zeigt ein Beispiel.
-
-
Komponentenverwaltetes Anmeldeszenario
-
Der
Anwendungskomponenten-Anbieter stellt das res-auth-Element auf Komponente
ein. Der Komponenten-Code führt
ein programmatisches Anmelden bei dem EIS durch.
-
Die
Anwendungskomponente gibt explizite Sicherheitsinformationen (Benutzername,
Passwort) an das Verfahren getConnection der ConnectionFactory-Instanz
weiter.
-
-
-
Anwendungsserver
-
Der
Anwendungsserver liefert eine Sicherheitsumgebung (mit bestimmten
Sicherheitsrichtlinien und -mechanismen), die die Sicherheitsanforderungen
der eingesetzten Anwendungskomponenten und Betriebsmitteladapterelemente
unterstützt
und dadurch einen sicheren Zugriff auf die angeschlossenen EIS-Systeme gewährleistet.
Der Anwendungsserver kann die Werkzeuge zum Einrichten von Sicherheitsinformationen
für die
Anmeldung beim EIS bereitstellen, wenn das res-auth-Element auf
Container eingestellt ist. Die Mindestanforderung ist die Unterstützung der
Benutzer/Passwort-basierten Authentifizierung während der Anmeldung beim EIS.
-
Der
Anwendungsserver kann einen Principal-Delegationsmechanismus bereitstellen,
so dass der einleitende/Aufrufer-Principal (direkt oder mittels
Abbildung) an ein zugrundeliegendes EIS weitergegeben werden kann.
Die Sicherheitsmechanismen und -richtlinien, die zur Unterstützung der
Principal-Delegation nötig sind,
liegen außerhalb
des Umfangs der Connector-Architektur. Diese Mechanismen und Richtlinien
sind im Allgemeinen spezifisch für
eine Sicherheitstechnik und einen Anwendungsserver. Der Anwendungsserver kann
die Werkzeuge zur Unterstützung
der Verwaltung seiner Sicherheitsdomäne bereitstellen. Die Verwaltung
der Sicherheitsdomäne
kann zum Beispiel das Einrichten und Verwalten der zugrundeliegenden
Authentifizierungsdienste, das Einrichten und Verwalten von Vertrauen
zwischen Domänen
und das Verwalten der Principale (einschließlich Identitäten, Schlüssel und
Attribute) entsprechend den Anforderungen der Sicherheitstechnik
umfassen.
-
Der
Anwendungsserver kann einen Mechanismus für ein einmaliges Anmelden unterstützen, der
sich über
Anwendungsserver und mehrere EIS-Systeme hinweg er streckt. Die Sicherheitsmechanismen
und -richtlinien, mit denen die einmalige Anmeldung erreicht wird,
liegen außerhalb
des Umfangs der Connector-Architektur.
-
EIS-Hersteller
-
Ein
EIS stellt die Sicherheitsinfrastruktur und eine Umgebung bereit,
die die Sicherheitsanforderungen der Client-Anwendungen unterstützen. Ein
EIS kann seine eigene Sicherheitsdomäne mit einem bestimmten Satz
von Sicherheitsrichtlinien und -mechanismen aufweisen oder als kann
es Teil einer unternehmensweiten Sicherheitsdomäne eingerichtet sein.
-
Connector-Anbieter
-
Das
Betriebsmitteladapterelement muss den Sicherheitsvertrag implementieren,
der als Teil der Connector-Verträge
festgelegt ist. Das Betriebsmitteladapterelement muss seine Sicherheitsmöglichkeiten
und -anforderungen mit Hilfe seines Deployment-Deskriptors angeben.
-
Deployer
-
Der
Deployer legt Sicherheitsrichtlinien fest, die den sicheren Zugriff
auf die zugrundeliegenden EIS-Systeme von den Anwendungskomponenten
sicherstellen. Der Deployer passt die vorgesehene Sicherheitsansicht
einer Anwendung für
den EIS-Zugriff,
wie mit einem Deployment-Deskriptor angegeben, an die tatsächlichen
Sicherheitsmechanismen und -richtlinien an, die von dem Anwendungsserver
und den EIS-Systemen
in der Ziel-Betriebsumgebung verwendet werden. Der Deployer verwendet
bestimmte Werkzeuge zur Durchführung
der vorstehenden Aufgaben. Das Ergebnis der Arbeit des Deployers
ist ein Sicherheitspolitik-Deskriptor, der spezifisch für die Betriebsumgebung
ist. Das Format des Sicherheitspolitik-Deskriptors ist spezifisch
für einen
Anwendungsserver.
-
Der
Deployer führt
die folgenden Einsatz- oder Deployment-Aufgaben für jede im
Deployment-Deskriptor einer Anwendungskomponente deklarierte Connection-Factory-Referenz (resource-ref-Element)
durch: 1) Bereitstellen der Connection-Factory-spezifischen Sicherheitskonfiguration,
die zum Öffnen
und Verwalten von Verbindungen zu einer EIS-Instanz nötig ist.
2) Verbinden der Connection-Factory-Referenz im Deployment-Deskriptor
einer Anwendungskomponente mit der JNDI-registrierten Referenz für die Connection-Factory.
Der Deployer kann den Mechanismus JNDI LinkRef verwenden, um eine
symbolische Verknüpfung
mit dem tatsächlichen
JNDI-Namen der Connection-Factory zu erzeugen. 3) Einrichten der
Principal-Abbildung und der Delegationsoptionen für die Anmeldung
beim EIS. Wenn die Principal-Abbildung von der auf der Anwendungsserver-Ebene
verwendeten Sicherheitsdomäne
auf die Sicherheitsdomäne
des EIS nötig
ist, ist der Deployer zuständig
für das
Einrichten der Principal-Abbildung.
Die Principal-Abbildung erfolgt in einer für den Anwendungsserver spezifischen
Weise und überschreitet
den Umfang der vorliegenden Beschreibung. 4) Wenn der Wert des Deployment-Deskriptorelements
res-auth Container lautet, ist der Deployer zuständig für das Konfigurieren der Sicherheitsinformationen
für die
Anmeldung beim EIS. Als Mindestanforderung muss der Deployer Benutzer/Passwort-basierte
Sicherheitsinformationen für
jede Connection-Factory-Referenz entsprechend der Deklaration durch
eine Anwendungskomponente angeben können.
-
Systemadministrator
-
Der
Systemadministrator arbeitet im Allgemeinen eng mit den Administratoren
der mehreren EIS-Systeme zusammen, die in einer Betriebsumgebung
eingerichtet sind. Die Aufgaben für die Systemverwaltung können auch
vom Deployer durchgeführt
werden. Der Systemadministrator fügt Betriebsmitteladapterelemente
in der Anwendungsserver-Umgebung hinzu, entfernt sie und konfiguriert
sie. Die Verwaltung der Sicherheitsdomäne liegt außerhalb des Umfangs der Connector-Spezifikation.
Der Systemadministrator führt
bestimmte Sicherheitsaufgaben aus, um eine Betriebsumgebung einzurichten.
Diese Aufgaben der Systemverwaltung können auf der Technik und den
Anforderungen des Authentifizierungsdienstes und darauf basieren, ob
ein unternehmensweites Verzeichnis unterstützt wird oder nicht. Der Systemadministrator
kann zum Beispiel eine Vertrauensdelegation für den Anwendungsserver einrichten,
um auf das EIS zuzugreifen, wenn Kerberos als unternehmensweiter
Authentifizierungsdienst verwendet wird.
-
Wenn
die unternehmensweite Sicherheitsinfrastruktur ein unternehmensweites
Verzeichnis unterstützt,
kann der Systemadministrator die Benutzer-Account-Informationen
sowohl für
den Anwendungsserver als auch für
das EIS in dem unternehmensweiten Verzeichnis konfigurieren. Die
in dem unternehmensweiten Verzeichnis geführten Account-Informationen
werden zur Authentifizierung von Benutzern verwendet, die eine Verbindung
zum EIS anfordern. Wenn ein EIS an einen Anwendungsserver angeschlossen
ist, kann der Systemadministrator einen Mechanismus für die Passwortsynchronisation
zwischen dem Anwendungsserver und dem EIS einrichten. Dadurch ist
sichergestellt, dass auf dem Anwendungsserver und dem EIS identische
Sicherheitsinformationen für
den Benutzer geführt
werden. Wenn das EIS eine Authentifizierung verlangt, gibt der Anwendungsserver
das Passwort des Benutzers an das EIS weiter.
-
Sicherheitsvertrag
-
In 3 und 4 erweitert
der Sicherheitsvertrag 200 zwischen dem Anwendungsserver 202 und dem
Betriebsmitteladapterelement 204 den Verbindungsverwaltungsvertrag
durch Hinzufügung
sicherheitsspezifischer Details. Dieser Sicherheitsvertrag 200 unterstützt die
Anmeldung beim EIS durch Weiterleiten der Verbindungsanfrage von
dem Betriebsmitteladapterelement 204 an den Anwendungsserver 202,
wobei es letzterem ermöglicht
wird, Sicherheitsdienste einzubinden. Der Sicherheitsvertrag 200 sieht
auch die Weitergabe des Sicherheitskontexts (JAAS-Subjekt, seiner
Principale und Berechtigungsnachweise) von dem Anwendungsserver 202 an
das Betriebsmitteladapterelement 204 vor. Der Sicherheitsvertrag 200 umfasst
die folgenden Klassen und Schnittstellen: Subjekt 106,
generischer Berechtigungsnachweis, Passwort-Berechtigungsnachweis,
Verbindungsmanager, verwaltete Connection-Factory und verwaltete
Verbindung. Das Subjekt 106 repräsentiert eine Gruppe von zugehörigen Informationen
für eine
einzelne Einheit, zum Beispiel eine Person. Solche Informationen
umfassen die Identitäten
des Subjekts 106 sowie seine sicherheitsrelevanten Attribute
(zum Beispiel Passwörter
und Kryptografieschlüssel).
Das Subjekt 106 kann mehrere Identitäten haben. Jede Identität ist als
ein Principal innerhalb des Subjekts 106 repräsentiert.
Ein Principal verbindet einfach einen Namen mit dem Subjekt 106.
Das Subjekt 106 kann auch sicherheitsrelevante Attribute
aufweisen, die als Berechtigungsnachweise bezeichnet werden. Sensible
Berechtigungsnachweise, die einen besonderen Schutz erfordern, zum
Beispiel private Kryptografieschlüssel, sind in einem privaten
Berechtigungsnachweis-Set gespeichert. Die Berechtigungsnachweise,
die gemeinsam benutzt werden sollen, zum Beispiel öffentliche
Schlüsselzertifikate
oder Kerberos-Servertickets, sind in einem öffentlichen Berechtigungsnachweis-Set
gespeichert. Unterschiedliche Berechtigungen sind erforderlich,
um auf die verschiedenen Berechtigungsnachweis-Sets zugreifen und
sie zu ändern.
Das Verfahren getPrincipals wird verwendet, um alle mit dem Subjekt 106 verbundenen
Principale abzurufen. Die Verfahren getPublicCredentials und getPrivateCredentials
werden verwendet, um alle öffentlichen
bzw. privaten Berechtigungsnachweise abzurufen, die zu dem Subjekt 106 gehören. Die
in der Setklasse definierten Verfahren werden verwendet, um das
als Ergebnis erhaltene Set von Principalen und Berechtigungsnachweisen
zu ändern.
-
Die
Schnittstelle 110 java.security.Principal wird verwendet,
um einen Betriebsmittel-Principal anzugeben. Der nachstehende Code-Auszug
ist ein Beispiel zur Veranschaulichung der Principal-Schnittstelle:
-
-
Das
Verfahren getName liefert als Ergebnis den eindeutigen Namen eines
Betriebsmittel-Principals. Ein Anwendungsserver 202 sollte
eine Implementierung der Principal-Schnittstelle verwenden, um einen
Betriebsmittel-Principal als Teil des Subjekts 106 an ein
Betriebsmitteladapterelement 204 weiterzugeben. Die Schnittstelle
javax.resource.spi.security.GenericCredential definiert eine vom
Sicherheitsmechanismus unabhängige
Schnittstelle für
den Zugriff auf den Sicherheitsberechtigungsnachweis eines Betriebsmittel-Principals.
-
Die
Schnittstelle 108 GenericCredential dient als Java-Wrapper über eine
zugrundeliegende mechanismusspezifische Darstellung eines Sicherheitsberechtigungsnachweises.
Die Schnittstelle 108 GenericCredential ermöglicht es
einem Betriebsmitteladapterelement 204, Informationen über einen
Sicherheitsberechtigungsnachweis zu extrahieren. Das Betriebsmitteladapterelement 204 kann
dann die Anmeldung beim EIS für einen
Betriebsmittel-Principal verwalten. Der nachstehende Code-Auszug
zeigt ein Beispiel für
die Schnittstelle 208 GenericCredential:
-
-
-
Die
Schnittstelle 208 GenericCredential unterstützt eine
Reihe von Get-Verfahren, um Informationen über einen Sicherheitsberechtigungsnachweis
zu erhalten. Das Verfahren getName liefert als Ergebnis den eindeutigen
Namen des mit einer GenericCredential-Instanz verbundenen Betriebsmittel-Principals.
-
Das
Verfahren getMechType liefert als Ergebnis die Art des Mechanismus
für die
GenericCredential-Instanz. In der Schnittstelle 208 GenericCredential
wird die Art des Mechanismus als Ergebnis in Form einer Zeichenfolge
nach der OID-Spezifikation angezeigt. Die Schnittstelle 208 GenericCredential
kann verwendet werden, um die Sicherheitsdaten für einen bestimmten Sicherheitsmechanismus
zu erhalten. Ein Beispiel sind die Authentifizierungsdaten, die
zum Aufbauen einer sicheren Verbindung mit einer EIS-Instanz im
Namen des zugehörigen
Betriebsmittel-Principals benötigt
werden. Das Verfahren getCredentialData liefert als Ergebnis die
Angabe des Berechtigungsnachweises als eine Byte-Array. Wenn die
Berechtigungsnachweis-Instanz nicht mehr benötigt wird, kann das Verfahren
destroy aufgerufen werden, um alle von der zugrundeliegenden Berechtigungsnachweisangabe
belegten Betriebsmittel freizugeben und alle sensiblen Informationen
zu vernichten. Unterstützt
ein Anwendungsserver 202 den Einsatz des Betriebsmitteladapterelements 204,
das GenericCredential als Teil des Sicherheitsvertrags 200 unterstützt, muss
der Anwendungsserver 202 eine Implementierung der Schnittstelle 208 GenericCredential
bereitstellen.
-
Die
Klasse 212 javax.resource.spi.security.PasswordCredential
dient als ein Platzhalter für
Benutzername und Passwort. Diese Klasse ermöglicht es einem Anwendungsserver 202,
den Benutzernamen und das Passwort über den Sicherheitsvertrag 200 an
das Betriebsmitteladapterelement 204 weiterzugeben. Das
Verfahren getUserName on PasswordCredential class wird verwendet,
um den Namen des Betriebsmittel-Principals zu erhalten.
-
Die
Schnittstelle 110 Java.security.Principal repräsentiert
einen Betriebsmittel-Principal.
Die Klasse PasswordCredential ist erforderlich, um das equals- und
das hashCode-Verfahren zu implementieren. Das nachstehende Codesegment
zeigt ein Beispiel hierfür.
-
-
Das
Verfahren getManagedConnectionFactory liefert als Ergebnis die ManagedConnectionFactory-Instanz,
für die
der Benutzername und das Passwort vom Anwendungsserver 202 eingerichtet
worden sind. Das Verfahren ConnectionManager.allocateConnection
wird von der Connection-Factory-Instanz des Betriebsmitteladapterelements 204 aufgerufen.
Dadurch kann das Betriebsmitteladapterelement 204 eine
Verbindungsanfrage an den Anwendungsserver 202 weiterleiten,
so dass letzterer Sicherheits- und andere Dienste einbinden kann.
-
-
Abhängig davon,
ob der Anwendungsserver 202 oder die Anwendungskomponente
dafür eingerichtet ist,
die Zuständigkeit
für die
Verwaltung der Anmeldung beim EIS zu übernehmen, sollte das Betriebsmitteladapterelement 204 das
Verfahren ConnectionManager.allocateConnection auf eine von mehreren
Weisen aufrufen. In einem containerverwalteten Anmeldeszenario gibt
die Anwendungskomponente keine Sicherheitsinformationen in dem Verfahren
getConnection weiter, und der Anwendungsserver 202 ist zur
Verwaltung der Anmeldung beim EIS konfiguriert. Der Anwendungsserver 202 stellt
die benötigten
Sicherheitsinformationen für
den Betriebsmittel-Principal durch seine konfigurierten Sicherheitsrichtlinien
und -mechanismen bereit (zum Beispiel die Principal-Abbildung).
Der Anwendungsserver 202 leitet die Authentifizierung des
Betriebsmittel-Principals gegenüber
dem EIS entweder selbst ein oder übergibt die Zuständigkeit
für die
Authentifizierung an das Betriebsmitteladapterelement 204.
-
In
einem komponentenverwalteten Anmeldeszenario liefert die Anwendungskomponente
explizite Sicherheitsinformationen in dem Verfahren getConnection.
Das Betriebsmitteladapterelement 204 ruft das Verfahren
allocateConnection auf, indem es Sicherheitsinformationen in dem
Parameter ConnectionRequestInfo weitergibt. Da die Sicherheitsinformationen
in ConnectionRequestInfo für
den Anwendungsserver 202 verdeckt sind, muss sich der Anwendungsserver 202 darauf
verlassen, dass das Betriebsmitteladapterelement 204 die
Anmeldung beim EIS verwaltet.
-
Der
nachstehende Code-Auszug zeigt ein Beispiel für die Verfahren in der Schnittstelle
ManagedConnectionFactory, die für
den Sicherheitsvertrag 200 relevant sind:
-
-
Beim
JNDI-Lookup wird die Instanz 216 ManagedConnectionFactory
von dem Anwendungsserver 202 mit einer Reihe von Konfigurationseigenschaften
konfiguriert. Diese Eigenschaften umfassen die Standard-Sicherheitsinformationen
und die für
die EIS-Instanz spezifischen Informationen (Host-Name, Port-Nummer),
die beim Einrichten einer neuen physikalischen Verbindung zum Einleiten
der Anmeldung bei dem zugrundeliegenden EIS erforderlich sind. Das
Verfahren createManagedConnection wird von dem Anwendungsserver 202 verwendet,
wenn er das Betriebsmitteladapterelement 204 auffordert,
eine neue physikalische Verbindung zu dem zugrundeliegenden EIS
einzurichten.
-
Der
Anwendungsserver 202 stellt verschiedene Sicherheitsdienste
bereit (Principal-Abbildung und -Delegation, einmaliges Anmelden),
bevor der Sicherheitsvertrag 200 mit dem Betriebsmitteladapterelement 204 verwendet
wird. Der Anwendungsserver 202 kann zum Beispiel den Aufrufer-Principal
auf den Betriebsmittel-Principal abbilden, bevor er das Verfahren
createManagedConnection aufruft, um eine neue Verbindung einzurichten
(unter dem Sicherheitskontext des Betriebsmittel-Principals). Die
Sicherheitskonfiguration in der Instanz 216 ManagedConnectionFactory
dient als Standardvorgabe, wenn der Anwendungsserver 202 keine Sicherheitsinformationen
für eine
Verbindungsaufbauanfrage an das Betriebsmitteladapterelement 204 weitergibt.
-
Der
Anwendungsserver 202 hat mehrere Optionen zum Aufrufen
des Verfahrens createManagedConnection. Option A: Der Anwendungsserver 202 ruft
das Verfahren createManagedConnection auf, indem er eine Subjekt-Instanz
ungleich null weitergibt, die den Betriebsmittel-Principal und dessen
entsprechenden passwort-basierten Berechtigungsnachweis enthält (angegeben
durch die Klasse PasswordCredential, die den Benutzernamen und das
Passwort liefert). Das Betriebsmitteladapterelement 204 extrahiert
den Benutzernamen und das Passwort aus dieser Subjekt-Instanz (durch
Suche nach einer Instanz PasswordCredential in dem Subjekt 106)
und verwendet diese Sicherheitsinformationen, um sich während des
Verbindungsaufbaus bei der EIS-Instanz anzumelden. Option B: Der
Anwendungsserver 202 ruft das Verfahren createManagedConnection
auf, indem er eine Subjekt-Instanz ungleich null weitergibt, die
den Betriebsmittel-Principal
und dessen Berechtigungsnachweise enthält. Bei dieser Option sind
die Berechtigungsnachweise durch die Schnittstelle 208 GenericCredential
repräsentiert.
Ein typisches Beispiel ist eine Subjekt-Instanz mit Kerberos-Berechtigungsnachweis.
Ein Anwendungsserver kann diese Option zum Beispiel für das Aufrufen
des Verfahrens createManagedConnection verwenden, wenn der Betriebsmittel-Principal
auf die Identität
des einleitenden/Anrufer-Principals wechselt und durch den Identitätswechsel
gültige
Berechtigungsnachweise erhalten hat. Ein Anwendungsserver kann diese
Option auch für
Szenarien mit Principal-Abbildung verwenden, wobei die Berechtigungsnachweise
eines Betriebsmittel-Principals durch die Schnittstelle 208 GenericCredential
repräsentiert
werden. Das Betriebsmitteladapterelement 204 verwendet
den Betriebsmittel-Principal und dessen Berechtigungsnachweise aus
der Subjekt-Instanz, um den EIS-Anmeldeprozess zu durchlaufen, bevor
eine neue Verbindung zum EIS eingerichtet wird. Option C: Der Anwendungsserver 202 fordert
das Betriebsmitteladapterelement 204 auf, die Anmeldung
beim EIS zu verwalten, indem er eine Subjekt-Instanz mit dem Wert null
weitergibt. Der Anwendungsserver 202 verwendet diese Option
für das
komponentenverwaltete Anmeldeszenario, bei dem Sicherheitsinformationen
in der Instanz ConnectionRequestInfo enthalten sind. Der Anwendungsserver 202 liefert
keine Sicherheitsinformationen, die von dem Betriebsmitteladapterelement 204 für die Verwaltung
der Anmeldung beim EIS verwendet werden können.
-
Vertrag für das Betriebsmitteladapterelement
-
sDas
Betriebsmitteladapterelement 204 kann die Anmeldung beim
EIS und die Einrichtung einer Verbindung in einer implementierungsspezifischen
Weise durchführen
oder es kann die GSS-API verwenden. Das Betriebsmitteladapterelement 204 hat
mehrere Optionen (entsprechend den Optionen für den Anwendungsserver) zur
Handhabung des Aufrufs für
das Verfahren createManagedConnection. Option A: Das Betriebsmitteladapterelement 204 prüft mit dem
Verfahren Subject.getPrivateCredentials explizit, ob die übergebene
Subjekt-Instanz eine Instanz PasswordCredential enthält. Dabei
nimmt der Sicherheitsvertrag 200 an, dass ein Betriebsmitteladapterelement
die nötigen
Sicherheitsberechtigungen hat, um private Berechtigungsnachweise aus
einer Subjekt-Instanz zu extrahieren. Wenn die Subjekt-Instanz eine
Instanz PasswordCredential enthält, extrahiert
das Betriebsmitteladapterelement 204 den Benutzernamen
und das Passwort aus PasswordCredential. Es verwendet die Sicherheitsinformationen
zur Authentifizierung des Betriebsmittel-Principals (entsprechend
dem Benutzernamen) gegenüber
dem EIS beim Aufbau einer Verbindung. In diesem Fall verwendet das
Betriebsmitteladapterelement 204 einen EIS-spezifischen
Authentifizierungsmechanismus. Weil eine Subjekt-Instanz mehrere
Instanzen PasswordCredential enthalten kann, sollte eine ManagedConnectionFactory 216 nur
die Instanz PasswordCredential verwenden, die über den Sicherheitsvertrag 200 speziell
für sie weitergegeben
worden ist. Mit dem Verfahren getManagedConnectionFactory kann eine
ManagedConnectionFactoryInstanz herausfinden, ob eine Instanz PasswordCredential
für die
Anmeldung bei der EIS-Zielinstanz verwendet werden muss. Die Implementierung 216 für ManagedConnectionFactory
verwendet das equals-Verfahren, um sich selbst mit der weitergegebenen.
Instanz zu vergleichen.
-
Option
B: Das Betriebsmitteladapterelement 204 prüft mit den
in der Schnittstelle für
das Subjekt 106 definierten Verfahren getPrivateCredentials
und getPrivateCreden tials explizit, ob die weitergegebene Subjekt-Instanz
eine Instanz GenericCredential enthält. Sensible Berechtigungsnachweise,
die besonderen Schutz erfordern, zum Beispiel private Kryptografieschlüssel, sind
in einem privaten Berechtigungsnachweis-Set gespeichert, während Berechtigungsnachweise,
die gemeinsam benutzt werden sollen, zum Beispiel öffentliche
Schlüsselzertifikate
oder Kerberos-Servertickets, in einem öffentlichen Berechtigungsnachweis-Set gespeichert
sind. Die beiden Verfahren getPrivateCredentials und getPrivateCredentials
sollten dementsprechend verwendet werden. Das Betriebsmitteladapterelement 204 verwendet
den Betriebsmittel-Principal und dessen Berechtigungsnachweise (wie
durch die Schnittstelle GenericCredential angegeben) in der Subjekt-Instanz,
um den EIS-Anmeldeprozess zu durchlaufen. Diese Option wird zum
Beispiel für
auf Kerberos basierende Berechtigungsnachweise verwendet, die der
Betriebsmittel-Principal durch Identitätswechsel erworben hat.
-
Das
Betriebsmitteladapterelement 204 verwendet das in der Schnittstelle
GenericCredential definierte Get-Verfahren, um Informationen über den
Berechtigungsnachweis und dessen Principal zu erhalten. Wenn ein
Betriebsmitteladapterelement den GSS-Mechanismus benutzt, verwendet
das Betriebsmitteladapterelement 204 eine Referenz auf
die Instanz GenericCredential in einer verdeckten Weise, ohne jede
Anforderung bezüglich
des Verstehens einer mechanismusspezifischen Darstellung des Berechtigungsnachweises.
Ein Betriebsmitteladapterelement muss jedoch eventuell die Darstellung
des Berechtigungsnachweises interpretieren, wenn das Betriebsmitteladapterelement 204 die
Authentifizierung in einer implementierungsspezifischen Weise einleitet.
-
Option
C: Wenn der Anwendungsserver 202 das Verfahren ManagedConnectionFactory.create-ManagedConnection
mit einer Subjekt-Instanz mit dem Wert null aufruft, hat das Betriebsmitteladapterelement 204 die
folgenden Optionen. Option 1: Das Betriebsmitteladapterelement 204 sollte
die von der Instanz ConnectionRequestInfo weitergegebenen Sicherheitsinformationen
extrahieren. Das Betriebsmitteladapterelement 204 sollte
den Betriebsmittel-Principal durch Kombinieren der in der Managed-ConnectionFactory-Instanz
konfigurierten Sicherheitsinformationen mit den von der Instanz
ConnectionRequestInfo weitergegebenen Sicherheitsinformationen authentifizieren.
Die Standardvorgabe für
das Betriebsmitteladapterelement 204 ist es, ein Übersteuern
der in der ManagedConnectionFactory-Instanz konfigurierten Sicherheitsinformationen
durch die Sicherheitsinformationen in dem Parameter ConnectionRequestInfo
zuzulassen. Option 2: Wenn das Betriebsmitteladapterelement 204 keine
Sicherheits konfiguration in ConnectionRequestInfo findet, verwendet
es die Standard-Sicherheitskonfiguration in der ManagedConnectionFactory-Instanz.
-
Das
Betriebsmitteladapterelement 204 kann eine physikalische
Verbindung (die bereits in dem Verbindungs-Pool unter einem anderen
Sicherheitskontext existiert) zu dem zugrundeliegenden EIS erneut
authentifizieren. Das Betriebsmitteladapterelement 204 führt die
Neuauthentifizierung durch, wenn der Anwendungsserver 202 das
Verfahren getConnection mit einem Sicherheitskontext (weitergegeben
als eine Subjekt-Instanz)
aufruft, der sich von dem unterscheidet, der vorher mit der physikalischen
Verbindung verbunden war. Die Unterstützung für die Neuauthentifizierung
ist davon abhängig,
ob ein zugrundeliegendes EIS den Neuauthentifizierungsmechanismus
für bestehende
physikalische Verbindungen unterstützt. Bei einer Ausführungsform,
bei der das Betriebsmitteladapterelement 204 die Neuauthentifizierung
nicht unterstützt,
sollte das Betriebsmitteladapterelement 204 Sicherheitsinformationen
ignorieren, die von dem Verfahren getConnection weitergegeben werden.
-
-
Das
Verfahren getConnection liefert als Ergebnis einen neuen Verbindungs-Handle. Wenn die
Neuauthentifizierung erfolgreich ist, hat das Betriebsmitteladapterelement 204 den
Sicherheitskontext der zugrundeliegenden Instanz ManagedConnection
in den geändert,
der mit der weitergegebenen Subjekt-Instanz verbunden ist. Das Betriebsmitteladapterelement 204 hat
die folgenden Optionen zur Handhabung des Aufrufs für ManagedConnection.getConnection,
wenn es die Neuauthentifizierung unterstützt. Option A: Das Betriebsmitteladapterelement 204 extrahiert
die PasswordCredentialInstanz aus dem Subjekt 106 und führt eine
EIS-spezifische Authentifizierung durch. Diese Option entspricht
der Option A, die in der Spezifikation für das Verfahren createManagedConnection
in der Schnittstelle ManagedConnectionFactory definiert ist. Option
B: Das Betriebsmitteladapterelement 204 extrahiert die
Instanz GenericCredential aus dem Subjekt 106 und verwaltet die
Authentifizierung entweder mit dem GSS- Mechanismus oder einem implementierungsspezifischen
Mechanismus. Diese Option entspricht der Option B, die in der Spezifikation
für das
Verfahren createManagedConnection in der Schnittstelle 216 ManagedConnectionFactory
definiert ist. Option C: In diesem Fall ist der Parameter Subjekt 106 null.
Das Betriebsmitteladapterelement 204 extrahiert die Sicherheitsinformationen
aus ConnectionRequestInfo (sofern vorhanden) und führt die
Authentifizierung in einer implementierungsspezifischen Weise durch.
Diese Option entspricht der Option C, die in der Spezifikation für das Verfahren
createManagedConnection in der Schnittstelle 216 ManagedConnectionFactory
definiert ist.
-
Das
Betriebsmitteladapterelement 204 muss den Sicherheitsvertrag 200 durch
Implementierung des Verfahrens ManagedConnectionFactory.create-ManagedConnection
unterstützen.
Das Betriebsmitteladapterelement 204 muss seine Unterstützung für den Sicherheitsvertrag 200 als
Teil seines Deployment-Deskriptors angeben. Die relevanten Deployment-Deskriptorelemente
sind authmechanism, authmechtype, reauthentication support und die
Schnittstelle credential.
-
Der
Anwendungsserver 202 muss das Verfahren ManagedConnectionFactory.
create-ManagedConnection unterstützen,
um den Sicherheitskontext während
der Anmeldung beim EIS an das Betriebsmitteladapterelement 204 weiterzugeben.
Der Anwendungsserver 202 muss alle drei Optionen A, B und
C verwenden können,
wie sie vorstehend in der Beschreibung für ManagedConnectionFactory
angegeben sind. Der Anwendungsserver 202 muss eine Implementierung
der Schnittstelle 208 GenericCredential bereitstellen,
um Betriebsmitteladapterelemente zu unterstützen, die GenericCredential
(und damit die Option B) als Teil des Sicherheitsvertrags 200 handhaben
können.
Der Anwendungsserver 202 muss das Verfahren allocateConnection
in seiner Implementierung des Verbindungsmanagers 214 implementieren.
Der Anwendungsserver 202 muss seine Verwendung des Sicherheitsvertrags 200 basierend
auf den von dem Betriebsmitteladapterelement 204 in seinem
Deployment-Deskriptor angegebenen Sicherheitsanforderungen konfigurieren.
Wenn zum Beispiel ein Betriebsmitteladapterelement angibt, dass
es nur die einfache Passwortauthentifizierung unterstützt, sollte
der Anwendungsserver 202 den Sicherheitsvertrag 200 für die Weitergabe
benutzen.
-
Bei
einer anderen Ausführungsform
(5 und 6) unterstützt die Sicherheitsarchitektur
nach der vorliegenden Erfindung die JAAS-basierte modulare Authentifizierung.
JAAS stellt einen Java-Standardrahmen und eine Programmierschnittstelle bereit,
die es Anwendungen ermöglicht,
Benutzer zu authentifizieren und Zugriffskontrollen für die Benutzer
durchzusetzen. JAAS lässt
sich auf der Grundlage der bereitgestellten Sicherheitsdienste in
zwei Teile unterteilen. Der erste Teil ist die modulare Authentifizierung.
Dieser Teil des JAAS-Rahmens ermöglicht
es einem Systemadministrator, die geeigneten Authentifizierungsdienste
modular einzusetzen, um die Sicherheitsanforderungen für eine Anwendungsumgebung
zu erfüllen.
Es ist nicht erforderlich, eine bestehende Anwendung zu modifizieren
oder neu zu kompilieren, um neue oder andere Authentifizierungsdienste
zu unterstützen.
Der zweite Teil von JAAS befasst sich mit der Autorisierung. Nachdem
die Authentifizierung erfolgreich abgeschlossen ist, bietet JAAS
die Möglichkeit,
Zugriffskontrollen auf der Grundlage der mit einem authentifizierten
Subjekt verbundenen Principale durchzuführen. Die auf dem Principal
basierenden JAAS-Zugriffskontrollen (Zugriffskontrollen auf der
Grundlage dessen, wer den Code ausführt) ergänzen die bestehenden auf der
Codequelle basierenden Zugriffskontrollen von Java 2 (Zugriffskontrollen
auf der Grundlage dessen, von wo der Code stammt und wer ihn abgezeichnet
hat).
-
Die
Connector-Sicherheitsarchitektur verwendet JAAS in einem Sicherheitsvertrag.
Eine JAAS-Subjektklasse wird als Teil des Sicherheitsvertrags zwischen
einem Anwendungsserver und einem Betriebsmitteladapterelement verwendet.
Diese Verwendung von JAAS-Schnittstellen macht es möglich, dass
der Sicherheitsvertrag von jeder speziellen Sicherheitstechnik oder
Mechanismen unabhängig
bleiben kann. Die Sicherheitsarchitektur benutzt auch einen JAAS-Rahmen
für die
modulare Authentifizierung, wodurch es möglich ist, dass ein Anwendungsserver
und seine zugrundeliegenden Authentifizierungsdienste voneinander
unabhängig bleiben
können.
Wenn weitere EIS-Systeme
angeschlossen werden und neue Authentifizierungsdienste erforderlich
sind (oder nachgerüstet
werden), können
diese modular in einen Anwendungsserver eingesteckt werden, ohne
dass Änderungen
an dem Anwendungsserver erforderlich sind. Die Connector-Architektur
verlangt, dass der Anwendungsserver und das Betriebsmitteladapterelement
die JAAS-Subjektklasse als Teil des Sicherheitsvertrags unterstützen. Ein
Anwendungsserver verwendet jedoch vorzugsweise den JAAS-Rahmen der
modularen Authentifizierung. Die Connector-Architektur erfordert
keine Unterstützung
für den
Autorisierungsteil des JAAS-Rahmens.
-
Die
Sicherheitsarchitektur befasst sich damit, wie JAAS von einem Anwendungsserver
benutzt werden sollte, um die Authentifizierungsanforderungen von
heterogenen EIS-Systemen zu unterstützen. Ein Anwendungsserver
unterstützt
vorzugsweise plattformweite JAAS-Module (auch als Authentifizierungsmodule
bezeichnet) für
Authentifizierungsmechanismen, die gemeinsam in mehreren EIS-Systemen
verwendet werden. Die Implementierung dieser JAAS-Module ist im
Allgemeinen spezifisch für
einen Anwendungsserver. Diese Module können jedoch auch so entwickelt
werden, dass sie über
Anwendungsserver hinweg wiederverwendbar sind. Ein Connector-Anbieter
kann eine maßgeschneiderte,
für ein
Betriebsmitteladapterelement spezifische Implementierung eines JAAS-Moduls
anbieten. Ein maßgeschneidertes
JAAS-Modul sollte mit einem Betriebsmitteladapterelement zusammengepackt
werden und sich in einen Anwendungsserver mit der JAAS-Architektur
einstecken lassen.
-
Die
JAAS-Spezifikation legt Anforderungen für die Entwicklung und Konfiguration
von JAAS-Modulen fest. Eine API für einen generischen Sicherheitsdienst
(GSS-API) ist eine
Standard-API, die Sicherheitsdienste für Aufrufer-Anwendungen in einer
generischen Weise bereitstellt. Zu diesen Sicherheitsdiensten gehören Authentifizierung,
Autorisierung, Principal-Delegation, Aufbau einer sicheren Verbindung
sowie Geheimhaltung und Integrität
pro Nachricht. Diese Dienste können
von einer Vielzahl von Sicherheitsmechanismen und Technologien unterstützt werden.
Eine Anwendung unter Verwendung einer GSS-API ruft diese Dienste
jedoch in einer generischen, mechanismusunabhängigen Weise auf und erreicht
Portierbarkeit auf der Quellebene. Im Kontext der Connector-Architektur
wird GSS-API als ein Betriebsmitteladapterelement zum Aufbau einer
sicheren Verbindung mit dem zugrundeliegenden EIS verwendet. Die
Verwendung des GSS-Mechanismus durch ein Betriebsmitteladapterelement
ist in den folgenden Szenarien typisch: 1) Das EIS unterstützt Kerberos
als einen externen Authentifizierungsdienst und verwendet die GSS-API
als generische API für
den Zugriff auf Sicherheitsdienste. 2) Das Betriebsmitteladapterelement
und das EIS benötigen
Datenintegritäts-
und Geheimhaltungsdienste während
ihrer Kommunikation über
unsichere Verbindungen. Die GSS-API ist für eine Reihe von Sicherheitsmechanismen
implementiert worden, darunter auch Kerberos V5.
-
Beim
Einsatz eines Betriebsmitteladapterelements ist der Deployer zuständig für das Konfigurieren der
erforderlichen JAAS-Module in der Betriebsumgebung. Die Konfiguration
von JAAS-Modulen basiert auf den von einem Betriebsmitteladapterelement
in seinem Deployment-Deskriptor angegebenen Sicherheitsanforderungen.
Das Element auth-mechanism in dem Deployment-Deskriptor gibt einen
Authentifizierungsmecha nismus an, der von einem Betriebsmitteladapterelement
unterstützt
wird. Die Standardtypen von Authentifizierungsmechanismen sind einfaches
Passwort und kerbv5. Wenn ein Betriebsmitteladapterelement zum Beispiel
die Unterstützung
für den
Authentifizierungsmechanismus kerbv5 vorschreibt, konfiguriert der
Deployer ein Kerberos-Modul in der Betriebsumgebung.
-
Der
Deployer richtet die Konfiguration der JAAS-Module auf der Grundlage
des in JAAS angegebenen Mechanismus ein. Weitere Einzelheiten sind
der Spezifikation für
javax.security.auth.login.Configuration zu entnehmen. Die JAAS-Konfiguration
umfasst die folgenden Informationen für jedes Betriebsmitteladapterelement:
1) Authentifizierungsmodule, die zur Authentifizierung eines Betriebsmittel-Principals
verwendet werden sollten, 2) Reihenfolge, in der die Authentifizierungsmodule
während
der sequentiellen Authentifizierung aufgerufen werden müssen, und
3) Flag-Wert zur Steuerung der Authentifizierungssemantik, wenn
sequentielle Module bei der Authentifizierung aufgerufen werden.
Das Format für
die vorstehende Konfiguration ist spezifisch für die jeweilige Implementierung
des Anwendungsservers.
-
In
einem betriebsmitteladapterelement-verwalteten Authentifizierungsszenario
(6) werden die folgenden Schritte ausgeführt: Die
Anwendungskomponente ruft das Verbindungsanfrageverfahren in dem
Betriebsmitteladapterelement auf, ohne Sicherheitsargumente zu übergeben.
Das Betriebsmitteladapterelement leitet die Verbindungsanfrage an
den Anwendungsserver weiter. Beim Einsatz des Betriebsmitteladapterelements
wird der Anwendungsserver so konfiguriert, dass er ein Principal-Abbildungsmodul
verwendet. Dieses Principal-Abbildungsmodul nimmt eine Subjekt-Instanz
mit dem Aufrufer-Principal und liefert als Ergebnis eine Subjekt-Instanz
mit einem gültigen
Betriebsmittel-Principal und einer PasswordCredential-Instanz. Diese
enthält
das Passwort zur Authentifizierung des Betriebsmittel-Principals.
Der Anwendungsserver ruft das Verfahren LoginContext.login auf.
Nach einer erfolgreichen Antwort vom Principal-Abbildungsmodul erhält der Anwendungsserver
eine Subjekt-Instanz, die den abgebildeten Betriebsmittel-Principal
mit einem gültigen
PasswordCredential aufweist. Der Anwendungsserver ruft das Verfahren
ManagedConnectionFactory.create-ManagedConnection
auf, in dem er eine Subjekt-Instanz ungleich null weitergibt. Die
Subjekt-Instanz enthält
den Betriebsmittel-Principal und dessen entsprechendes PasswordCredential,
das den Benutzernamen und das Passwort enthält. Das Betriebsmitteladapterelement
extrahiert den Benutzernamen und das Passwort aus der PasswordCre dential-Instanz.
Das Betriebsmitteladapterelement verwendet die Get-Verfahren (Verfahren
getPrivateCredentials), die in der Subjekt-Schnittstelle definiert
sind, um die PasswordCredential-Instanz zu extrahieren. Das Betriebsmitteladapterelement
verwendet die Benutzername- und Passwortinformationen (extrahiert
aus der PasswordCredential-Instanz), um den Betriebsmittel-Principal
gegenüber
dem EIS zu authentifizieren. Die Authentifizierung erfolgt während der
Herstellung der Verbindung durch einen Authentifizierungsmechanismus,
der spezifisch für
das zugrundeliegende EIS ist. Mit diesem Szenario kann die Connector-Architektur
eine EIS-spezifische Authentifizierung auf der Basis von Benutzername
und Passwort unterstützen.
-
7 zeigt
ein Szenario mit Kerberos und der Principal-Delegation, das die
folgenden Schritte umfasst: Der einleitende Principal authentifiziert
sich selbst gegenüber
dem Anwendungsserver unter Verwendung von Kerberos. Der einleitende
Principal weist ein Serviceticket für den Anwendungsserver und
ein TGT (von KDC ausgestelltes Ticket Granting Ticket) als Teil
seines auf Kerberos basierenden Berechtigungsnachweises auf. Der
Anwendungsserver ist so konfiguriert, dass die Identität des einleitenden
Principals beim Aufrufen der EIS-Instanz gewechselt wird. Auch wenn
der Anwendungsserver direkt mit dem EIS unter Verwendung des Betriebsmittel-Principals
verbunden ist, wird der Zugriff auf das EIS im Namen des einleitenden
Principals angefragt. Der Betriebsmittel-Principal wechselt auf
die Identität
des einleitenden Principals, indem er die Identität von letzterem übernimmt,
und führt
Anfragen an das EIS im Namen des einleitenden Principals durch.
Der Anwendungsserver ist so konfiguriert, dass das JAAS-Modul für Kerberos
verwendet wird. Der Anwendungsserver erzeugt eine LoginContext-Instanz,
indem er die dem einleitenden Principal entsprechende Subjekt-Instanz und eine
CallbackHandler-Instanz weitergibt. Als Nächstes ruft der Anwendungsserver
das Anmeldeverfahren für
die LoginContext-Instanz auf. Das Kerberos-Modul (aufgerufen über das Verfahren LoginContext.login)
erhält
ein Serviceticket für
die EIS-Instanz. Das Kerberos-Modul verwendet den CallbackHandler-Mechanismus,
um die nötigen
Informationen (für
das Erhalten eines Servicetickets) über die EIS-Zielinstanz von
dem Anwendungsserver zu erhalten. Nach einer erfolgreichen Antwort
von dem Kerberos-Modul ruft der Anwendungsserver das Verfahren ManagedConnectionFactory.create-ManagedConnection auf,
indem er eine Subjekt-Instanz mit dem Betriebsmittel-Principal und
dessen Kerberos-Berechtigungsnachweis weitergibt. Der Kerberos-Berechtigungsnachweis
ist durch die Schnittstelle GenericCredential angege ben. Das Betriebsmitteladapterelement
extrahiert den Betriebsmittel-Principal und dessen Kerberos-Berechtigungsnachweis
aus der Subjekt-Instanz. Das Betriebsmitteladapterelement stellt
eine neue physikalische Verbindung zum EIS her. Wenn das Betriebsmitteladapterelement
und das EIS die GSS-API zum Aufbau einer sicheren Verbindung unterstützen, gibt
das Betriebsmitteladapterelement den Kerberos-Berechtigungsnachweis
(jetzt mit dem Serviceticket für
das EIS) mit dem GSS-Mechanismus an die EIS-Instanz weiter. Können das Betriebsmitteladapterelement
und das EIS keine sichere Verbindung herstellen, kann das Betriebsmitteladapterelement
die physikalische Verbindung nicht als eine gültige Verbindung zu der EIS-Instanz
benutzen. Das Betriebsmitteladapterelement liefert als Ergebnis
eine Sicherheitsausnahme für
das Verfahren createManagedConnection.
-
Unterstützt ein
EIS den GSS-Mechanismus, kann ein Betriebsmitteladapterelement die
GSS-API verwenden, um eine sichere Verbindung mit der EIS-Instanz
aufzubauen, wie in 8 gezeigt. Dieses Szenario umfasst
die Kerberos-Authentifizierung nach der Principal-Abbildung. Der
Anwendungsserver ist so konfiguriert, dass er das Principal-Abbildungsmodul
und das Kerberos-Modul verwendet. Die beiden Authentifizierungsmodule
sind gestapelt, wobei das Principal-Abbildungsmodul das erste ist.
Der Anwendungsserver erzeugt eine LoginContext-Instanz, indem er
die Subjekt-Instanz
für den
Aufrufer-Principal und eine CallbackHandler-Instanz weitergibt.
Danach ruft der Anwendungsserver das Anmeldeverfahren für die LoginContext-Instanz
auf.
-
Das
Principal-Abbildungsmodul nimmt eine Subjekt-Instanz mit einem Aufrufer-Principal und liefert
als Ergebnis eine Subjekt-Instanz mit einem gültigen Betriebsmittel-Principal
und Authentifizierungsdaten für
die auf Kerberos basierende Authentifizierung. Das Principal-Abbildungsmodul
authentifiziert den Betriebsmittel-Principal nicht; es führt lediglich
die Principal-Abbildung durch, um den abgebildeten Betriebsmittel-Principal und dessen
Authentifizierungsdaten zu finden. Das Kerberos-Modul (aufgerufen
nach dem Principal-Abbildungsmodul) verwendet den Betriebsmittel-Principal
und dessen Authentifizierungsdaten zur Authentifizierung des Betriebsmittel-Principals.
Das Kerberos-Modul verwendet den CallbackHandler-Mechanismus, um
die nötigen
Informationen (für
das Erhalten eines Servicetickets) über die EIS-Zielinstanz von
dem Anwendungsserver zu erhalten. Nach einer erfolgreichen Kerberos-Authentifizierung
hat der Betriebsmittel-Principal einen Kerberos-Berechtigungsnachweis
mit einem gültigen
TGT und Serviceticket für
die EIS-Instanz. Der Kerberos-Berechtigungsnachweis ist durch die
Schnittstelle GenericCredential angegeben. Der Anwendungsserver
ruft das Verfahren ManagedConnectionFactory.create-ManagedConnection
auf, indem er eine Subjekt-Instanz mit dem Betriebsmittel-Principal
und dessen Kerberos-Berechtigungsnachweis weitergibt. Die übrigen Schritte sind
dieselben wie im vorherigen Szenario.
-
In 10 umfasst
ein Berechtigungsnachweis-Abbildungsszenario die folgenden Schritte:
Der Aufrufer-Principal ist authentifiziert worden und hat Berechtigungsnachweise
auf der Grundlage eines öffentlichen Schlüsselzertifikats.
Die Sicherheitsumgebung für
die EIS-Zielinstanz ist mit einem Kerberos-Authentifizierungsdienst
konfiguriert. Der Anwendungsserver ist mit einem Berechtigungsnachweis-Abbildungsmodul
konfiguriert, das den mit dem Aufrufer-Principal verbundenen Berechtigungsnachweis
auf der Grundlage eines öffentlichen
Zertifikats auf den Kerberos-Berechtigungsnachweis für den Betriebsmittel-Principal
abbildet. Der abgebildete Betriebsmittel-Principal hat dieselbe
Identität
wie der Aufrufer-Principal. Der Anwendungsserver ruft das konfigurierte
Berechtigungsnachweis-Abbildungsmodul auf, um die Berechtigungsnachweis-Abbildung
durchzuführen.
Der Anwendungsserver ruft das Verfahren LoginContext.login auf,
indem er eine dem einleitenden Principal entsprechende Subjekt-Instanz
und eine CallbackHandler-Instanz weitergibt.
-
Der
CallbackHandler ermöglicht
es dem Abbildungsmodul, alle vom Anwendungsserver bereitgestellten
Authentifizierungsdaten und die spezifischen Informationen für die EIS-Instanz
zu erhalten. Das Abbildungsmodul bildet den Berechtigungsnachweis
auf der Grundlage eines öffentlichen
Schlüsselzertifikats
für den
Aufrufer-Principal auf den auf Kerberos basierenden Berechtigungsnachweis
ab. Um diese Abbildung zu erreichen, verwendet das Modul die Authentifizierungsdaten
und die für
das EIS spezifischen Informationen, die entweder als Teil der Subjekt-Instanz
geführt
oder durch den JAAS-Rückrufmechanismus
erhalten werden. Nach erfolgreicher Abbildung der Berechtigungsnachweise
hat der Aufrufer-Principal (jetzt abgebildet auf einen Betriebsmittel-Principal)
einen Kerberos-Berechtigungsnachweis mit einem gültigen TGT und Serviceticket
für die
EIS-Instanz. Der Kerberos-Berechtigungsnachweis ist durch die Schnittstelle
GenericCredential angegeben. Der Anwendungsserver ruft das Verfahren
ManagedConnectionFactory.create-ManagedConnection auf, indem er
eine Subjekt-Instanz
mit dem Betriebsmittel-Principal und dessen abgebildetem Kerberos-Berechtigungsnachweis
weitergibt. Das Betriebsmitteladapterelement stellt eine neue physikalische
Verbindung zu dem EIS unter Verwendung des Kerberos-Berechtigungsnachwei ses
für den
Betriebsmittel-Principal her. Dieser Schritt ist im vorherigen Szenario
gezeigt.
-
In 11 kann
die Authentifizierung durch ein EIS-spezifisches JAAS-Modul erfolgen.
Dieses Szenario umfasst die folgenden Schritte: Bei der Konfiguration
eines Betriebsmitteladapterelements wird der Anwendungsserver so
konfiguriert, dass er ein EIS-spezifisches JAAS-Modul für die Authentifizierung
gegenüber dem
zugrundeliegenden EIS verwendet. Das konfigurierte JAAS-Modul unterstützt einen
für das
EIS spezifischen Authentifizierungsmechanismus. Der Anwendungsserver übernimmt
die Zuständigkeit
für die
Verwaltung der Authentifizierungsdaten und der JAAS-Konfiguration.
Der Anwendungsserver erhält
eine Anfrage von der Anwendungskomponente, um eine neue physikalische
Verbindung zu dem EIS einzurichten. Zur Herstellung einer neuen
physikalischen Verbindung muss der Betriebsmittel-Principal sich
selbst gegenüber
der zugrundeliegenden EIS-Instanz authentifizieren. Der Anwendungsserver
leitet die Authentifizierung des Betriebsmittel-Principals ein.
Er erzeugt eine LoginContext-Instanz,
indem er die Subjekt-Instanz und eine CallbackHandler-Instanz weitergibt.
-
Als
Nächstes
ruft der Anwendungsserver das Anmeldeverfahren für die LoginContext-Instanz
auf. Das JAAS-Modul authentifiziert den Betriebsmittel-Principal
gegenüber
dem zugrundeliegenden EIS. Es verwendet den vom Anwendungsserver
bereitgestellten Callback-Handler, um die Authentifizierungsdaten
zu erhalten. Der Anwendungsserver ruft das Verfahren ManagedConnectionFactory.create-ManagedConnection
auf, indem er die Subjekt-Instanz mit dem authentifizierten Betriebsmittel-Principal
und dessen Berechtigungsnachweis weitergibt. Das Betriebsmitteladapterelement
extrahiert den Berechtigungsnachweis (verbunden mit Subjekt-Instanz)
für den
Betriebsmittel-Principal
unter Verwendung der in der Subjekt-Schnittstelle definierten Verfahren.
Das Betriebsmitteladapterelement verwendet diese Berechtigungsnachweise,
um eine Verbindung zu dem zugrundeliegenden EIS herzustellen. In
diesem Szenario erfolgt die Authentifizierung eines Betriebsmittel-Principals
(eingeleitet durch den Anwendungsserver und durchgeführt durch
das JAAS-Modul) getrennt vom Aufbauen einer Verbindung zum EIS.
Das Betriebsmitteladapterelement verwendet den Berechtigungsnachweis
des Betriebsmittel-Principals, um eine Verbindung zum EIS herzustellen.
Das Herstellen dieser Verbindung kann eine weitere Authentifizierung
umfassen. Nach erfolgreichem Aufbau einer Verbindung zu dem EIS
liefert das Betriebsmitteladapterelement als Ergebnis die neu eingerichtete
Verbindung aus dem Verfahren ManagedConnectionFactory.create-ManagedConnection.
-
In 12 ermöglicht JAAS
einem Anwendungsserver die Verwaltung des einmaligen Anmeldens über mehrere
EIS-Instanzen hinweg. Der Systemadministrator kann verschiedene
JAAS-Module so konfigurieren, dass sie Sicherheitsinformationen
gemeinsam miteinander benutzen können.
Wenn ein einzelnes Subjekt auf unterschiedliche Benutzernamen und
Passwörter
für jedes
EIS abgebildet wird, können
die JAAS-Module
die vom Anwendungsserver gelieferten Sicherheitsinformationen koordiniert
auf die relevanten vom EIS angegebenen Informationen abbilden. Der
Anwendungsserver liefert zum Beispiel einen einzelnen Benutzernamen und
ein Passwort. Diese Sicherheitsinformationen werden auf die jeweiligen
EIS-spezifischen Benutzernamen und Passwörter abgebildet. Auf diese
Weise kann ein einzelnes Subjekt gegenüber mehreren EIS-Systemen authentifiziert
werden. Da JAAS die Möglichkeit
der Verbindung von Berechtigungsnachweisen für mehrere Sicherheitsmechanismen
mit einer Subjekt-Instanz unterstützt, kann der Anwendungsserver
auf Berechtigungsnachweise für
ein Subjekt zugreifen und das Subjekt gegenüber zusätzlichen EIS-Systemen authentifizieren. Weil
ein Berechtigungsnachweis die nötigen
Informationen für
die weitere Authentifizierung enthält, muss die Subjekt-Instanz
keine neuen Sicherheitsinformationen bereitstellen.