Gesicherte Verbindungen mit DB2
Gesicherte Verbindungen ermöglichen dem Anwendungsserver die Verwendung gesicherter DB2-Kontextobjekte zum Aufbau von Verbindungen mit einem Benutzer, dessen Berechtigungsnachweise vom DB2-Server für das Öffnen einer Verbindung anerkannt werden. Durch das Erstellen eines gesicherten Kontextes wird dieser Benutzer anschließend als vertrauenswürdig anerkannt und kann andere Benutzeridentitäten im DB2-Server ohne erneute Authentifizierung zusichern. Dieser Prozess erhöht außerdem die Sicherheit Ihrer DB2-Datenbank, da es nicht mehr erforderlich ist, alle Berechtigungen einem einzelnen Benutzer zuzuordnen. Die Implementierung gesicherter Verbindungen führt zur Weitergabe der Clientidentität. Gleichzeitig wird das Verbindungspooling verwendet, um Leistungseinbußen zu vermeiden, die dann entstehen, wenn Verbindungen geschlossen und mit einer anderen Identität erneut geöffnet werden.
Damit der erhebliche Aufwand verringert wird, der zum Aufbau neuer Verbindungen erforderlich ist, verwaltet der Verbindungsmanager einen Verbindungspool, in dem jede Verbindung über den Berechtigungsnachweis verfolgt wird, unter dem sie ursprünglich geöffnet wurde. Wenn eine Anwendung eine Verbindung benötigt, verwendet der Verbindungsmanager das Berechtigungsnachweisobjekt, um eine freie Verbindung aus dem Verbindungspool zuzuordnen. Wenn keine freie Verbindung verfügbar ist und die maximale Anzahl an Verbindungen noch nicht erreicht wurde, öffnet der Verbindungspoolmanager unter Verwendung des betreffenden Berechtigungsnachweisobjekts eine neue Verbindung. Diese Verbindungszuordnung ist die Standardverbindungszuordnung, die der Anwendungsserver verwendet, und sie wird als N:1-Zuordnung des Berechtigungsnachweises bezeichnet, da die Verbindung unter Verwendung des Berechtigungsnachweisobjekts im Subjekt geöffnet wird, das normalerweise nicht der RunAs-Identität entspricht. Diese einfache Zuordnung unterstützt ein einfaches Verbindungspooling, aber die Identität des Callers (Aufrufenden) wird niemals an den Datenbankserver weitergegeben.
Damit die Identität des Callers an den Datenbankserver weitergegeben wird, können Sie ein JAAS-Anmeldemodul (Java™ Authentication and Authorization Service) integrieren. Mit dieser Methode kann der Benutzerberechtigungsnachweis im Anwendungsserver dem Benutzerberechtigungsnachweis zugeordnet werden, der für den Sicherheitsrealm des Datenbankservers geeignet ist. Diese Strategie behält die Identität des Callers bei, verwendet jedoch kein Verbindungspooling.
Gesicherte Verbindungen werden anstelle der Standardzuordnung oder einer JAAS-Zuordnung verwendet, um eine Verbindung zur Datenquelle herzustellen. Gesicherte Verbindungen unterstützen die Weitergabe der Clientidentität und können das Verbindungspooling verwenden, um Leistungseinbußen zu vermeiden, die entstehen, wenn Verbindungen geschlossen und mit einer anderen Identität erneut geöffnet werden. Gesicherte Verbindungen nutzen das gesicherte DB2-Kontextobjekt.
![[z/OS]](../images/ngzos.gif)
Die Verwendung der gesicherten Verbindung stellt die Plug-in-Punkte bereit, die erforderlich sind, damit Sie Ihre eigene gesicherte Implementierung des gesichertenDB2-Kontextes hinzufügen können. Gesicherte Verbindungen trennen die Identität, die zum Erstellen der Verbindung verwendet wurde, von der Identität, die die Services des Back-End-Servers aufruft. Die Verbindung wird von einem Benutzer aufgebaut, dessen Berechtigungsnachweise für das Öffnen der Verbindung vom DB2-Server anerkannt sind. Derselbe Benutzer wird dann auch für die Zusicherung der Identität der anderen Benutzer anerkannt. Diese Zusicherung erhöht auch die Datenbanksicherheit, weil es in diesem Fall nicht mehr erforderlich ist, alle Berechtigungen einem einzelnen Benutzer zu erteilen.
Wenn die Anwendung eine Verbindung zur Datenbank anfordert, kann der Datenbankmanager eine inaktive gesicherte Verbindung ermitteln und die Benutzeridentität gegenüber dem Back-End-Server zusichern. Alle auf dem Back-End-Server ausgeführten Operationen werden von der zugesicherten Benutzeridentität ausgeführt. Möglicherweise muss dennoch eine Identitätszuordnung ausgeführt werden, wenn der Back-End-Server ein anderes Benutzerrepository verwendet als der Anwendungsserver.
- ein Ressourcen-Principal-Objekt, das dieses Ressourcenobjekt darstellt
- ein PasswordCredential-Objekt in der Gruppe der privaten Berechtigungsnachweise
- ein IdentityPrincipal-Objekt in der Principal-Gruppe