DE60127834T2 - Sicherheitsarchitektur zur integration eines betriebsinformationssystems mit einer j2ee plattform - Google Patents

Sicherheitsarchitektur zur integration eines betriebsinformationssystems mit einer j2ee plattform Download PDF

Info

Publication number
DE60127834T2
DE60127834T2 DE60127834T DE60127834T DE60127834T2 DE 60127834 T2 DE60127834 T2 DE 60127834T2 DE 60127834 T DE60127834 T DE 60127834T DE 60127834 T DE60127834 T DE 60127834T DE 60127834 T2 DE60127834 T2 DE 60127834T2
Authority
DE
Germany
Prior art keywords
principal
security
eis
resource
application server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE60127834T
Other languages
English (en)
Other versions
DE60127834D1 (de
Inventor
Rahul Sunnyvale SHARMA
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sun Microsystems Inc
Original Assignee
Sun Microsystems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sun Microsystems Inc filed Critical Sun Microsystems Inc
Application granted granted Critical
Publication of DE60127834D1 publication Critical patent/DE60127834D1/de
Publication of DE60127834T2 publication Critical patent/DE60127834T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • G06F21/33User authentication using certificates
    • G06F21/335User authentication using certificates for accessing specific resources, e.g. using Kerberos tickets
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/105Multiple levels of security

Description

  • 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.
  • Figure 00150001
  • 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.
  • Figure 00150002
  • Figure 00160001
  • 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:
  • Figure 00200001
  • 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:
  • Figure 00200002
  • Figure 00210001
  • 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.
  • Figure 00220001
  • 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.
  • Figure 00220002
  • 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:
  • Figure 00230001
  • 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.
  • Figure 00270001
  • 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.

Claims (2)

  1. Verfahren zum Aufbau einer sicheren Verbindung zwischen einer Anwendungskomponente (220) und einem Firmeninformationssystem (212), wobei in dem Verfahren die Anwendungskomponente (220) ein Verbindungsanfrageverfahren auf einem Betriebsmitteladapterelement (204) aufruft, ohne irgendwelche Sicherheitsprüfungen zu durchlaufen, das Betriebsmitteladapterelement (204) auf den Aufruf des Verbindungsanfrageverfahrens antwortet, indem es eine Verbindungsanfrage an einen Anwendungsserver (202) weiterleitet, und der Anwendungsserver (202) auf die von dem Betriebsmitteladapterelement (204) empfangene Verbindungsanfrage antwortet, indem er unter Verwendung der weitergeleiteten Verbindungsanfrage einen gültige Betriebsmittel-Principal und einen Paßwortberechtigungsnachweis von einem Principal-Abbildungsmodul erhält, und eine verwaltete Verbindung zwischen dem Anwendungsserver (202) und dem Firmeninformationssystem (212) unter Verwendung des gültigen Betriebsmittel-Principals und des Paßwortberechtigungsnachweises, die von dem Principal-Abbildungsmodul bereitgestellt werden, aufbaut.
  2. Computersystem zum Aufbauen einer sicheren Verbindung zwischen einer Anwendungskomponente (220) und einem Firmeninformationssystem (212), wobei das Computersystem aufweist: ein Firmeninformationssystem (212), ein Principal-Abbildungsmodul, das dazu betreibbar ist, einen gültige Betriebsmittel-Principal und Berechtigungsnachweise in Reaktion auf die Übermittlung einer Verbindungsanfrage bereitzustellen, eine Anwendungskomponente (220), die dazu betreibbar ist, ein Verbindungsanfrageverfahren auf einem Betriebsmitteladapterelement (204) aufzurufen, ohne irgendwelche Sicherheitsprüfungen zu durchlaufen, ein Betriebsmitteladapterelement (204), das gemäß dem Aufruf des Verbindungsanfrageverfahrens auf dem Betriebsmitteladapterelement (204) die Verbindungsanfrage an den Anwendungsserver (202) weiterleitet, und einen Anwendungsserver (202), der bei Empfang der Verbindungsanfrage von einem Betriebsmitteladapterelement die empfangene Verbindungsanfrage verwendet, um einen gültigen Betriebsmittel-Principal und einen Paßwortberechtigungsnachweis von dem Principal-Abbildungsmodul zu erhalten und eine verwaltete Verbindung zwischen dem Anwendungsserver (202) und dem Firmeninformationssystem (212) unter Verwendung des gültigen Betriebsmittel-Principals und des Paßwortberechtigungsnachweises, die durch das Principal-Abbildungsmodul bereitgestellt wurden, aufzubauen.
DE60127834T 2000-05-24 2001-05-17 Sicherheitsarchitektur zur integration eines betriebsinformationssystems mit einer j2ee plattform Expired - Fee Related DE60127834T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US578346 2000-05-24
US09/578,346 US7089584B1 (en) 2000-05-24 2000-05-24 Security architecture for integration of enterprise information system with J2EE platform
PCT/US2001/016099 WO2001091033A2 (en) 2000-05-24 2001-05-17 Security architecture for integration of enterprise information system with j2ee platform

Publications (2)

Publication Number Publication Date
DE60127834D1 DE60127834D1 (de) 2007-05-24
DE60127834T2 true DE60127834T2 (de) 2007-12-27

Family

ID=24312470

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60127834T Expired - Fee Related DE60127834T2 (de) 2000-05-24 2001-05-17 Sicherheitsarchitektur zur integration eines betriebsinformationssystems mit einer j2ee plattform

Country Status (5)

Country Link
US (1) US7089584B1 (de)
EP (1) EP1290856B1 (de)
AU (1) AU2001266591A1 (de)
DE (1) DE60127834T2 (de)
WO (1) WO2001091033A2 (de)

Families Citing this family (151)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6591278B1 (en) 2000-03-03 2003-07-08 R-Objects, Inc. Project data management system and method
US8443035B2 (en) * 2000-09-01 2013-05-14 OP40 Holding, Inc. System and method for collaboration using web browsers
US20030217333A1 (en) * 2001-04-16 2003-11-20 Greg Smith System and method for rules-based web scenarios and campaigns
US7428752B2 (en) * 2001-06-01 2008-09-23 Applications In Internet Time, Llc Secure data accessing system and method
US7392546B2 (en) * 2001-06-11 2008-06-24 Bea Systems, Inc. System and method for server security and entitlement processing
US7409420B2 (en) 2001-07-16 2008-08-05 Bea Systems, Inc. Method and apparatus for session replication and failover
US20030023898A1 (en) * 2001-07-16 2003-01-30 Jacobs Dean Bernard Layered architecture for data replication
US6918013B2 (en) * 2001-07-16 2005-07-12 Bea Systems, Inc. System and method for flushing bean cache
US7571215B2 (en) 2001-07-16 2009-08-04 Bea Systems, Inc. Data replication protocol
US7702791B2 (en) 2001-07-16 2010-04-20 Bea Systems, Inc. Hardware load-balancing apparatus for session replication
US7028030B2 (en) * 2001-08-30 2006-04-11 Bea Systems, Inc. Cluster caching with concurrency checking
US20030046230A1 (en) * 2001-08-30 2003-03-06 Jacobs Dean Bernard Method for maintaining account consistency
US7113980B2 (en) 2001-09-06 2006-09-26 Bea Systems, Inc. Exactly once JMS communication
US7516440B2 (en) * 2001-10-18 2009-04-07 Bea Systems, Inc. System and method for providing a java interface to an application view component
US7350226B2 (en) * 2001-12-13 2008-03-25 Bea Systems, Inc. System and method for analyzing security policies in a distributed computer network
WO2003063029A1 (en) * 2002-01-18 2003-07-31 Bea Systems, Inc. System and method for using virtual directories to service url requests in application servers
US7020684B2 (en) * 2002-01-18 2006-03-28 Bea Systems, Inc. System and method for optimistic caching
US6978278B2 (en) * 2002-01-18 2005-12-20 Bea Systems, Inc. System and method for heterogeneous caching
US20030140100A1 (en) * 2002-01-18 2003-07-24 Sam Pullara System and method for URL response caching and filtering in servlets and application servers
US6898587B2 (en) * 2002-01-18 2005-05-24 Bea Systems, Inc. System and method for performing commutative operations in data access systems
US7930704B2 (en) * 2002-02-06 2011-04-19 Oracle International Corporation J2EE component extension architecture
US7392302B2 (en) * 2002-02-21 2008-06-24 Bea Systems, Inc. Systems and methods for automated service migration
AU2003216332A1 (en) * 2002-02-21 2003-09-09 Bea Systems, Inc. System and method for message driven bean service migration
US7178050B2 (en) * 2002-02-22 2007-02-13 Bea Systems, Inc. System for highly available transaction recovery for transaction processing systems
US7152181B2 (en) * 2002-02-22 2006-12-19 Bea Systems, Inc. Method for highly available transaction recovery for transaction processing systems
US7552481B2 (en) * 2002-03-18 2009-06-23 Sun Microsystems, Inc. Method of assessing an organization's network identity capability
US7155438B2 (en) 2002-05-01 2006-12-26 Bea Systems, Inc. High availability for event forwarding
US8135772B2 (en) 2002-05-01 2012-03-13 Oracle International Corporation Single servlets for B2B message routing
US7725560B2 (en) 2002-05-01 2010-05-25 Bea Systems Inc. Web service-enabled portlet wizard
US7222148B2 (en) 2002-05-02 2007-05-22 Bea Systems, Inc. System and method for providing highly available processing of asynchronous service requests
US7484224B2 (en) * 2002-05-02 2009-01-27 Bae Systems, Inc. Adapter deployment without recycle
US7676538B2 (en) 2002-05-02 2010-03-09 Bea Systems, Inc. Systems and methods for application view transactions
US7350184B2 (en) * 2002-05-02 2008-03-25 Bea Systems, Inc. System and method for enterprise application interactions
US7313812B2 (en) * 2002-06-05 2007-12-25 Sap Aktiengesellschaft Application level security
US6988099B2 (en) 2002-06-27 2006-01-17 Bea Systems, Inc. Systems and methods for maintaining transactional persistence
US7506342B2 (en) * 2002-07-23 2009-03-17 Bea Systems, Inc. System and method for implementing J2EE connector architecture
US7698434B2 (en) * 2002-08-29 2010-04-13 Bea Systems, Inc. J2EE connector architecture
US7475239B2 (en) * 2002-09-20 2009-01-06 International Business Machines Corporation Pluggable trust adapter architecture, method and program product for processing communications
US20040088563A1 (en) * 2002-11-01 2004-05-06 Hogan Dirk J. Computer access authorization
US7661127B2 (en) 2002-11-12 2010-02-09 Millipore Corporation Instrument access control system
GB0226655D0 (en) * 2002-11-15 2002-12-24 Ibm JMS integration into an application server
US7650591B2 (en) 2003-01-24 2010-01-19 Bea Systems, Inc. Marshaling and un-marshaling data types in XML and Java
US8831966B2 (en) 2003-02-14 2014-09-09 Oracle International Corporation Method for delegated administration
US7653930B2 (en) 2003-02-14 2010-01-26 Bea Systems, Inc. Method for role and resource policy management optimization
US7591000B2 (en) 2003-02-14 2009-09-15 Oracle International Corporation System and method for hierarchical role-based entitlements
US7840614B2 (en) 2003-02-20 2010-11-23 Bea Systems, Inc. Virtual content repository application program interface
US7415478B2 (en) * 2003-02-20 2008-08-19 Bea Systems, Inc. Virtual repository complex content model
US7293286B2 (en) * 2003-02-20 2007-11-06 Bea Systems, Inc. Federated management of content repositories
US7610618B2 (en) * 2003-02-24 2009-10-27 Bea Systems, Inc. System and method for authenticating a subject
US7017051B2 (en) * 2003-02-24 2006-03-21 Bea Systems, Inc. System and method for enterprise authentication
US7774697B2 (en) 2003-02-25 2010-08-10 Bea Systems, Inc. System and method for structuring distributed applications
US20040167915A1 (en) * 2003-02-25 2004-08-26 Bea Systems, Inc. Systems and methods for declaratively transforming data objects between disparate representations
US7752599B2 (en) 2003-02-25 2010-07-06 Bea Systems Inc. Systems and methods extending an existing programming language with constructs
US7293038B2 (en) 2003-02-25 2007-11-06 Bea Systems, Inc. Systems and methods for client-side filtering of subscribed messages
US20040230955A1 (en) * 2003-02-26 2004-11-18 Bea Systems, Inc. System for multi-language debugging
US8032860B2 (en) * 2003-02-26 2011-10-04 Oracle International Corporation Methods for type-independent source code editing
US7707564B2 (en) * 2003-02-26 2010-04-27 Bea Systems, Inc. Systems and methods for creating network-based software services using source code annotations
US7650276B2 (en) 2003-02-26 2010-01-19 Bea Systems, Inc. System and method for dynamic data binding in distributed applications
US7810036B2 (en) 2003-02-28 2010-10-05 Bea Systems, Inc. Systems and methods for personalizing a portal
US7490331B2 (en) * 2003-03-04 2009-02-10 International Business Machines Corporation Mapping to and from native type formats
WO2005008456A2 (en) * 2003-07-07 2005-01-27 Progress Software Corporation Multi-platform single sign-on database driver
US20050154886A1 (en) * 2004-01-12 2005-07-14 International Business Machines Corporation Declarative trust model between reverse proxy server and websphere application server
US7519596B2 (en) * 2004-03-30 2009-04-14 Microsoft Corporation Globally trusted credentials leveraged for server access control
US7774601B2 (en) 2004-04-06 2010-08-10 Bea Systems, Inc. Method for delegated administration
US7606917B1 (en) * 2004-04-30 2009-10-20 Sap Ag Method, apparatus and system for principle mapping within an application container
US7721283B2 (en) * 2004-05-24 2010-05-18 Sap Ag Deploying a variety of containers in a Java 2 enterprise edition-based architecture
US7562341B2 (en) * 2004-05-24 2009-07-14 Sap Ag Deploy callback system with bidirectional containers
US8762981B2 (en) * 2004-05-24 2014-06-24 Sap Ag Application loading and visualization
US7735097B2 (en) * 2004-05-24 2010-06-08 Sap Ag Method and system to implement a deploy service to perform deployment services to extend and enhance functionalities of deployed applications
US7882502B2 (en) * 2004-05-25 2011-02-01 Sap Ag Single file update
US7877735B2 (en) * 2004-05-25 2011-01-25 Sap Ag Application cloning
US7747698B2 (en) * 2004-05-25 2010-06-29 Sap Ag Transaction model for deployment operations
US7509429B2 (en) * 2004-05-28 2009-03-24 Sap Ag Message endpoint activation
US7594237B2 (en) * 2004-06-01 2009-09-22 Sap Ag Program object to support connection generation
US7676810B2 (en) * 2004-06-03 2010-03-09 Sap Ag Identification of execution context
US7657658B2 (en) * 2004-06-07 2010-02-02 Sap Ag Resource adapter deployment
US9626173B1 (en) * 2004-06-08 2017-04-18 Sap Se Non specification supported application deployment descriptors and web application deployment descriptors
US20050283615A1 (en) * 2004-06-22 2005-12-22 Avaya Technology Corp. Method and apparatus for user authentication and authorization
US7617501B2 (en) 2004-07-09 2009-11-10 Quest Software, Inc. Apparatus, system, and method for managing policies on a computer having a foreign operating system
US7669226B2 (en) * 2004-07-30 2010-02-23 International Business Machines Corporation Generic declarative authorization scheme for Java
US8661420B2 (en) * 2004-08-03 2014-02-25 Oracle International Corporation System and method for runtime interface versioning
WO2006042202A2 (en) * 2004-10-08 2006-04-20 Approva Corporation Systems and methods for monitoring business processes of enterprise applications
US7757275B2 (en) * 2005-06-15 2010-07-13 Microsoft Corporation One time password integration with Kerberos
US7730523B1 (en) * 2005-06-17 2010-06-01 Oracle America, Inc. Role-based access using combinatorial inheritance and randomized conjugates in an internet hosted environment
US9418040B2 (en) 2005-07-07 2016-08-16 Sciencelogic, Inc. Dynamically deployable self configuring distributed network management system
US7454492B2 (en) 2005-08-26 2008-11-18 International Business Machines Corporation Method and apparatus for configuring and modeling server information in an enterprise tooling environment
US7953734B2 (en) 2005-09-26 2011-05-31 Oracle International Corporation System and method for providing SPI extensions for content management system
US7818344B2 (en) 2005-09-26 2010-10-19 Bea Systems, Inc. System and method for providing nested types for content management
US7752205B2 (en) 2005-09-26 2010-07-06 Bea Systems, Inc. Method and system for interacting with a virtual content repository
US7917537B2 (en) 2005-09-26 2011-03-29 Oracle International Corporation System and method for providing link property types for content management
CN1744599B (zh) * 2005-09-27 2010-04-28 浪潮电子信息产业股份有限公司 一种基于JAAS和AspectJ的机群管理系统认证和授权的方法
US7882503B2 (en) * 2005-11-17 2011-02-01 Oracle International Corporation Production redeployment
US7788660B2 (en) * 2005-11-17 2010-08-31 Bea Systems, Inc. Resource adapter classloading
US7527192B1 (en) 2005-12-15 2009-05-05 At&T Corp. Network based method of providing access to information
US7904949B2 (en) * 2005-12-19 2011-03-08 Quest Software, Inc. Apparatus, systems and methods to provide authentication services to a legacy application
US8087075B2 (en) 2006-02-13 2011-12-27 Quest Software, Inc. Disconnected credential validation using pre-fetched service tickets
WO2007130975A2 (en) * 2006-05-01 2007-11-15 Approva Corporation Managing controls wtthin a heterogeneous enterprise environment
US7996837B2 (en) * 2006-05-03 2011-08-09 Oracle International Corporation Recovery mechanism for transactions
US8429712B2 (en) 2006-06-08 2013-04-23 Quest Software, Inc. Centralized user authentication system apparatus and method
US7761468B2 (en) * 2006-10-04 2010-07-20 International Business Machines Corporation Supporting multiple security mechanisms in a database driver
US8463852B2 (en) 2006-10-06 2013-06-11 Oracle International Corporation Groupware portlets for integrating a portal with groupware systems
US7895332B2 (en) 2006-10-30 2011-02-22 Quest Software, Inc. Identity migration system apparatus and method
US8086710B2 (en) 2006-10-30 2011-12-27 Quest Software, Inc. Identity migration apparatus and method
US20080114987A1 (en) * 2006-10-31 2008-05-15 Novell, Inc. Multiple security access mechanisms for a single identifier
US20080270974A1 (en) * 2007-04-30 2008-10-30 Krasimir Topchiyski Enterprise JavaBeans Metadata Model
US20090019427A1 (en) * 2007-07-13 2009-01-15 International Business Machines Corporation Method and Apparatus for Providing Requirement Driven Static Analysis of Test Coverage for Web-Based, Distributed Processes
US9160752B2 (en) * 2007-08-31 2015-10-13 International Business Machines Corporation Database authorization rules and component logic authorization rules aggregation
US8510796B2 (en) * 2008-01-25 2013-08-13 Oracle International Corporation Method for application-to-application authentication via delegation
US8073962B2 (en) * 2008-03-03 2011-12-06 Oracle International Corporation Queued transaction processing
US8312033B1 (en) 2008-06-26 2012-11-13 Experian Marketing Solutions, Inc. Systems and methods for providing an integrated identifier
US8099788B2 (en) * 2008-09-16 2012-01-17 Oracle International Corporation Declarative data security for a rapid application development tool component
US8381278B2 (en) * 2008-10-30 2013-02-19 Oracle America, Inc. Method and apparatus for establishing security inflow contracts
US8479256B2 (en) * 2008-11-26 2013-07-02 Red Hat, Inc. Merging mandatory access control (MAC) policies in a system with multiple execution containers
US9767273B2 (en) 2008-11-26 2017-09-19 Red Hat, Inc. Reliably terminating processes in a system with confined execution environments
US8255984B1 (en) 2009-07-01 2012-08-28 Quest Software, Inc. Single sign-on system for shared resource environments
US9292702B2 (en) * 2009-08-20 2016-03-22 International Business Machines Corporation Dynamic switching of security configurations
US8230478B2 (en) 2009-08-27 2012-07-24 International Business Machines Corporation Flexibly assigning security configurations to applications
US9753737B2 (en) 2010-02-03 2017-09-05 Oracle International Corporation Declarative attribute security using custom properties
US9665854B1 (en) 2011-06-16 2017-05-30 Consumerinfo.Com, Inc. Authentication alerts
US8844015B2 (en) * 2012-01-31 2014-09-23 Hewlett-Packard Development Company, L.P. Application-access authentication agent
US9130920B2 (en) 2013-01-07 2015-09-08 Zettaset, Inc. Monitoring of authorization-exceeding activity in distributed networks
US10664936B2 (en) 2013-03-15 2020-05-26 Csidentity Corporation Authentication systems and methods for on-demand products
US9633322B1 (en) 2013-03-15 2017-04-25 Consumerinfo.Com, Inc. Adjustment of knowledge-based authentication
US9721147B1 (en) 2013-05-23 2017-08-01 Consumerinfo.Com, Inc. Digital identity
US10373240B1 (en) 2014-04-25 2019-08-06 Csidentity Corporation Systems, methods and computer-program products for eligibility verification
US20160234343A1 (en) 2015-02-11 2016-08-11 Dell Products L.P. Client side redirection
US10243848B2 (en) 2015-06-27 2019-03-26 Nicira, Inc. Provisioning logical entities in a multi-datacenter environment
US11102188B2 (en) * 2016-02-01 2021-08-24 Red Hat, Inc. Multi-tenant enterprise application management
US10558797B2 (en) * 2016-08-12 2020-02-11 Duo Security, Inc. Methods for identifying compromised credentials and controlling account access
US10510051B2 (en) 2016-10-11 2019-12-17 Ricoh Company, Ltd. Real-time (intra-meeting) processing using artificial intelligence
US10860985B2 (en) 2016-10-11 2020-12-08 Ricoh Company, Ltd. Post-meeting processing using artificial intelligence
US11307735B2 (en) 2016-10-11 2022-04-19 Ricoh Company, Ltd. Creating agendas for electronic meetings using artificial intelligence
US10572858B2 (en) 2016-10-11 2020-02-25 Ricoh Company, Ltd. Managing electronic meetings using artificial intelligence and meeting rules templates
US10298635B2 (en) 2016-12-19 2019-05-21 Ricoh Company, Ltd. Approach for accessing third-party content collaboration services on interactive whiteboard appliances using a wrapper application program interface
US10375130B2 (en) 2016-12-19 2019-08-06 Ricoh Company, Ltd. Approach for accessing third-party content collaboration services on interactive whiteboard appliances by an application using a wrapper application program interface
US10250592B2 (en) 2016-12-19 2019-04-02 Ricoh Company, Ltd. Approach for accessing third-party content collaboration services on interactive whiteboard appliances using cross-license authentication
US10395405B2 (en) 2017-02-28 2019-08-27 Ricoh Company, Ltd. Removing identifying information from image data on computing devices using markers
US10826890B2 (en) 2017-10-06 2020-11-03 Bank Of America Corporation Multi-level authentication system with persistent integration platform
US10553208B2 (en) 2017-10-09 2020-02-04 Ricoh Company, Ltd. Speech-to-text conversion for interactive whiteboard appliances using multiple services
US11062271B2 (en) 2017-10-09 2021-07-13 Ricoh Company, Ltd. Interactive whiteboard appliances with learning capabilities
US10552546B2 (en) 2017-10-09 2020-02-04 Ricoh Company, Ltd. Speech-to-text conversion for interactive whiteboard appliances in multi-language electronic meetings
US11030585B2 (en) 2017-10-09 2021-06-08 Ricoh Company, Ltd. Person detection, person identification and meeting start for interactive whiteboard appliances
US10956875B2 (en) 2017-10-09 2021-03-23 Ricoh Company, Ltd. Attendance tracking, presentation files, meeting services and agenda extraction for interactive whiteboard appliances
US10757148B2 (en) 2018-03-02 2020-08-25 Ricoh Company, Ltd. Conducting electronic meetings over computer networks using interactive whiteboard appliances and mobile devices
US10911234B2 (en) 2018-06-22 2021-02-02 Experian Information Solutions, Inc. System and method for a token gateway environment
US11374850B2 (en) 2020-04-06 2022-06-28 Vmware, Inc. Tunnel endpoint group records
US11799726B2 (en) 2020-04-06 2023-10-24 Vmware, Inc. Multi-site security groups
US11088919B1 (en) 2020-04-06 2021-08-10 Vmware, Inc. Data structure for defining multi-site logical network
US11088902B1 (en) 2020-04-06 2021-08-10 Vmware, Inc. Synchronization of logical network state between global and local managers
US11777793B2 (en) 2020-04-06 2023-10-03 Vmware, Inc. Location criteria for security groups
US11343283B2 (en) 2020-09-28 2022-05-24 Vmware, Inc. Multi-tenant network virtualization infrastructure

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5586260A (en) * 1993-02-12 1996-12-17 Digital Equipment Corporation Method and apparatus for authenticating a client to a server in computer systems which support different security mechanisms

Also Published As

Publication number Publication date
WO2001091033A3 (en) 2002-06-20
AU2001266591A1 (en) 2001-12-03
WO2001091033A2 (en) 2001-11-29
US7089584B1 (en) 2006-08-08
EP1290856A2 (de) 2003-03-12
EP1290856B1 (de) 2007-04-11
DE60127834D1 (de) 2007-05-24

Similar Documents

Publication Publication Date Title
DE60127834T2 (de) Sicherheitsarchitektur zur integration eines betriebsinformationssystems mit einer j2ee plattform
DE69921455T2 (de) System und verfahren zur zugriffssteuerung auf gespeicherte dokumente
DE60218069T2 (de) Bereitstellung von gekoppelten diensten in einer verteilten rechnerumgebung
US6161139A (en) Administrative roles that govern access to administrative functions
US6453353B1 (en) Role-based navigation of information resources
US7603548B2 (en) Security provider development model
DE60029774T2 (de) Videokonferenzsystem
US7644432B2 (en) Policy inheritance through nested groups
DE602005003314T2 (de) Spezialisierung der Unterstützung für eine Verbandsbeziehung
DE60006451T2 (de) Verteilte Authentifizierungsmechanismen zur Behandlung von verschiedenen Authentifizierungssystemen in einem Betriebsrechnersystem
US7062511B1 (en) Method and system for portal web site generation
DE69923503T2 (de) Authentifizierung und Zugriffskontrolle in einem Managementterminalprogramm zur Verwaltung von Diensten in einem Computernetzwerk
US7827598B2 (en) Grouped access control list actions
DE602004012300T2 (de) Verfahren und vorrichtungen für skalierbaren sicheren fern-desktop-zugriff
US20070245013A1 (en) Cross domain provisioning methodology and apparatus
US20050262362A1 (en) Distributed security system policies
AU2001271596A1 (en) System and method for integrating public and private data
EP1311926A2 (de) System und verfahren zum integrieren öffentlicher und privater daten
DE10040213A1 (de) System und Verfahren zur dynamischen, auf dem jeweiligen Aufgabenbereich beruhenden Konfiguration von Benutzerprofilen
CN106411857A (zh) 一种基于虚拟隔离机制的私有云gis服务访问控制方法
US20050097352A1 (en) Embeddable security service module
US6681330B2 (en) Method and system for a heterogeneous computer network system with unobtrusive cross-platform user access
DE112011102224B4 (de) Identitätsvermittlung zwischen Client- und Server-Anwendungen
DE602004012059T2 (de) Techniken zum dynamischen Aufbauen und Handhaben von Authentisierung und Vertrauensverhältnissen
DE19954358A1 (de) Benutzerrollenzugriffssteuerung

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee