Home 
ORDIX News 4/2004
ORDIX News 4/2004
ORDIX News 4/2004
Das IT-Magazin der ORDIX AG mit Fachbeiträgen zu Datenbanken, Unix und Java/XML.
Dieser Beitrag beschreibt, wie zwei Benutzer auf eine Oracle 9i Datenbank zugreifen können, ohne sie auf der Datenbank mittels CREATE USER anzulegen. Die Benutzer werden nur als Objekte im OID angelegt und dort administriert. Die Benutzer werden sich über den OID an der Datenbank identifizieren.
Die Datenbank mit dem OID läuft auf einem Linux Server. Die Benutzer melden sich also an derselben Instanz an, in der auch OID installiert wurde. Die beispielhafte Anmeldung geschieht über die Kommandozeile mittels sqlplus. Wir gehen davon aus, dass das OID eingerichtet und konfiguriert wurde, wie in den vorigen beiden Ausgaben der ORDIX News beschrieben.
Die Verwaltung von Enterprise Benutzern und Enterprise Rollen sowie deren Verwaltung im OID und spätere Authentifizierung der Benutzer an der Datenbank wird mit dem Begriff "Enterprise Security" bezeichnet.
Enterprise Security kann nur über sichere, d. h. in diesem Fall SSL-verschlüsselte Verbindungen realisiert werden. Die Datenbank, an der sich die Benutzer anmelden sollen, muss über einen sicheren Listener erreichbar sein. Der Verzeichnisdienst ist ebenfalls dahingehend zu konfigurieren.
Für eine SSL-verschlüsselte Verbindung zwischen dem Listener und der Datenbank ist ein sogenanntes X.509 Zertifikat zu erstellen. Diese Art der Zertifikate nutzt man z. B. auch bei geschützten Webseiten (HTTPS). Damit kann eine verschlüsselte Verbindung vom Client zum Server aufgebaut werden.
Die Zertifikate werden von einer Certification Authority (CA, Zertifizierungsstelle) ausgestellt. Man geht davon aus, dass Client und Server den von der CA ausgegebenen Zertifikaten bedenkenlos vertrauen können.
Bei Oracle werden auch Zertifikate zur sicheren Kommunikation eingesetzt. Jedes Zertifikat wird in einem sogenannten Wallet verwaltet. Das Wallet ist durch ein Passwort geschützt. In einem Wallet können mehrere Zertifikate für verschiedene Kommunikationspartner gespeichert und verwaltet werden. Zur Verwaltung wird der Oracle Wallet Manager (OWM) benutzt. Dazu später mehr.
In unserem Beispielfall werden wir selbst eine CA erstellen, unsere Zertifikate signieren und in einem Wallet verwalten. In größeren Unternehmen existiert in der Regel eine CA. Bei dieser müssen die Zertifikate beglaubigt werden, bevor sie eingesetzt werden können.
Die Erstellung einer eigenen Certification Authority geschieht über ein Skript, welches als ein Wrapper für den Enterprise Security Manager (ESM) dient. Über das Wrapper-Skript $ORACLE_HOME/bin/esm wird das grafische Werkzeug gestartet, mit dem wir viele Schritte der nötigen Konfiguration durchführen werden. Unter anderem erstellen wir die Zertifikate für die Datenbank und die Benutzer damit.
Wird dem Wrapper-Skript die Option –genca mitgegeben, so ruft dieses Skript den Befehl $ORACLE_HOME/sysman/admin/mkRootCert auf, welcher die für unsere CA benötigten Dateien erstellt.
Wir führen also den Befehl esm –genca an der Kommandozeile aus. Dabei wird die Eingabe eines Passwortes verlangt, welches zum Beglaubigen der Zertifikate benötigt wird. Die Dateien der CA werden im Dateisystem standardmäßig unter /etc/ORACLE/WALLETS/CA abgelegt.
Nach dem Start des ESM und der Anmeldung an der OID-Instanz muss die Datenbank, an der sich die Benutzer anmelden wollen, in einem Oracle Kontext registriert werden. Dazu wird unter Vorgänge "Datenbank registrieren" ausgewählt.
 |
| Abb. 1: Datenbank im ESM registrieren. |
Im folgenden Dialog (siehe Abbildung 1) werden die nötigen Informationen eingetragen, das Häkchen "Wallet generieren" gewählt und ein Passwort vergeben. Im aufkommenden Dialog muss das Passwort der eben eingerichteten CA eingegeben werden, um das Datenbank-Zertifikat zu beglaubigen.
Es wurde nun ein Wallet mit gültigem Zertifikat für die Datenbank erstellt. Das Wallet wurde direkt im OID abgelegt. Zum Aufbau einer verschlüsselten Verbindung über einen sicheren Listener benötigen wir es allerdings auch im Dateisystem des Linux Servers, damit der Listener es zur verschlüsselten Verbindung zur Datenbank nutzen kann.
Um das erstellte Wallet aus dem OID ins Dateisystem herunterzuladen, starten wir den Oracle Wallet Manager (owm), ein grafisches Werkzeug zur Bearbeitung von Oracle Wallets (siehe Abbildung 2) und darin enthaltenen Zertifikaten. Mit dem OWM laden wir das eben erstellte Wallet aus dem OID herunter. Dazu wird das Passwort benötigt, welches im Dialog aus Abbildung 1 eingegeben wurde.
 |
| Abb. 2: Walletverwaltung mit dem Oracle Wallet Manager. |
Nun speichern wir das Wallet im Verzeichnis /etc/ORACLE/WALLETS/oracle. Hier kann prinzipiell jedes beliebige Verzeichnis angegeben werden, allerdings konnte in unseren Tests der sichere Listener nur gestartet werden, wenn das Wallet sich im o. g. Verzeichnis befand.
 |
| Abb. 3: SSL-Listener und andere Einträge des Net Managers. |
Um die Datenbank über eine sichere Verbindung anzusprechen, muss ein Listener eingerichtet werden, mit dem wir die Datenbank über ein sicheres Protokoll erreichen können. Mittels des Oracle Net Managers richten wir einen Listener ein, der über das TCPS Protokoll und den Port 1575 angesprochen wird. Die daraus resultierenden Einträge für die listener.ora sind in Abbildung 3 zu sehen.
Der SSL-Listener muss nun nur noch wissen, wo das Wallet für die Datenbank liegt. Dazu nutzen wir wieder den Oracle Net Manager. Für die Konfiguration des Servers wird der Pfad zu dem Datenbankwallet, welches der Listener benutzen soll, angegeben (siehe Abbildung 4).
 |
| Abb. 4: Konfiguration eines SSL-Listeners mit dem Oracle Net Manager. |
In unserem Beispiel sind Client und Server identisch, so dass noch die Einstellung für den Client erfasst werden muss. Hierzu ist der Pfad zum Wallet wieder zu entfernen und nur der Radiobutton "Client" auszuwählen. Die Konfiguration muss in beiden Fällen gespeichert werden. Die resultierenden Änderungen an der sqlnet.ora werden in Abbildung 5 dargestellt. Sind Client und Server nicht identisch, d. h. sollen sich die Benutzer von einem anderen Computer aus mittels sqlplus anmelden, so sind die Einstellungen im Oracle Net Manager auf diesem Client zu tätigen.
 |
| Abb. 5: Einträge des Net Managers in der sqlnet.ora. |
Der SSL-Listener muss für die Datenbank als local_listener in der init.ora eingetragen werden. Damit der Name aufgelöst werden kann, ist er zudem in der tnsnames.ora einzutragen (siehe Abbildung 6). Zudem ist in der init.ora ein Eintrag für den Parameter rdbms_server_dn hinzuzufügen.
 |
| Abb. 6: Einträge der init.ora und tnsnames.ora. |
In unserem Fall lautet der Eintrag:
rdbms_server_dn="cn=oiddb,cn=OracleContext,dc=ordix,dc=de"
Dieser muss dem Distinguished Name (DN) entsprechen, auf den das Zertifikat im Enterprise Security Manager ausgestellt wurde. Dieser Eintrag wurde vom ESM auch im OID angelegt. Damit ist eine Zuordnung der Datenbank zu genau diesem Eintrag im Verzeichnisdienst möglich, um dort später globale Rollen und Enterprise Rollen miteinander verknüpfen zu können.
Damit die Änderungen in der init.ora wirksam werden, müssen die Instanz und der Listener neu gestartet werden.
Für die Bereitstellung eines SSL-Zugangs zum Verzeichnisdienst muss jetzt der OID-Listener konfiguriert werden, um einen sicheren Kanal zwischen Client und Datenbank bereitzustellen.
Hierzu wird der Oracle Directory Manager verwendet, in dem ein zusätzliches Configset definiert wird. Dies geschieht am besten durch die Bearbeitung einer Kopie des bestehenden Haupt-Configsets. Die Option "SSL aktivieren" muss ausgewählt werden. Weitere Parameter wie der Pfad zum Datenbankwallet, der SSL Port des OID-Listeners und die Berechtigungsprüfungsart müssen eingestellt werden (siehe Abbildung 7).
 |
| Abb. 7: Erstellung eines SSL-Configsets mit dem oidadmin. |
Zum Abschluss muss der OID-Server mit diesem Configset neu gestartet werden.
oracle@linux:~> oidctl \
connect=oiddb server=oidldapd \
instance=1 configset=1 start
Wir haben einen DB-Listener eingerichtet, mit dem wir über das TCPS Protokoll auf eine Datenbank zugreifen können. Für diese DB haben wir ein Zertifikat erstellt, das sowohl im OID als auch im Dateisystem in einem Wallet vorliegt. Der SSL-DB-Listener mit TCPS auf Port 1575 sowie der SSL-OID-Listener auf Port 636 benutzen dieses Wallet, um die Kommunikation mit der Datenbank zu verschlüsseln.
Alle Einstellungen für die sqlnet.ora, listener.ora und tnsnames.ora wurden beschrieben und die grundlegende Konfiguration ist damit abgeschlossen.
Jetzt werden nur noch die Benutzer und Rollen im OID und in der Datenbank eingerichtet.
Zum weiteren Verständnis werden nun einige Begriffe erläutert, die im Zusammenhang mit Enterprise Security eine Rolle spielen:
Als Shared Schema wird ein Schema in der Datenbank bezeichnet, welches ohne einen DN als Identifizierungskriterium angelegt wurde. Wird ein Benutzer mit einem DN angelegt, so wäre lediglich eine 1-zu-1 Beziehung zwischen einem Zertifikat und einem Benutzer in der Datenbank möglich. Ein derartiger Benutzer wird auch "globaler Benutzer" genannt und existiert direkt in der DB und nicht als Objekt im OID. Das Shared Schema wird mit folgendem Kommando erstellt.
CREATE USER \ s_schema identified globally as ’’;
Auf diese Weise besteht später die Möglichkeit, dem Shared Schema über den ESM einen oder mehrere Enterprise Benutzer zuzuweisen, die mit diesem Schema auf der Datenbank arbeiten. Dem Schema können mittels GRANT Zugriffsrechte innerhalb der Datenbank erteilt werden. Es ist sinnvoll, dieses Schema mit einer sehr geringen Anzahl von Rechten auszustatten und alle weiteren Rechte über die globalen Rollen zu vergeben.
grant create session to s_schema;
Globale Rollen ähneln in einer Oracle Datenbank normalen Rollen. Ihnen werden auf üblichem Weg Rechte zugewiesen. Der Unterschied zu einer herkömmlichen Rolle ist, dass globale Rollen nur durch Zuordnungen mit dem OID genutzt werden können. Sie können nicht an Datenbank Benutzer vergeben werden.
create role g_roleA identified globally; create role g_roleB identified globally; grant create table to g_roleA; grant create view to g_roleB;
Enterprise Rollen sind nicht in der Datenbank definiert, sondern sind Objekte im OID. Dort werden sie mit globalen Rollen aus einer oder aus mehreren Datenbanken verknüpft. Hier findet auch die Zuweisung von Enterprise Benutzern an Enterprise Rollen statt.
 |
| Abb. 8: Hinzufügen einer Enterprise Rolle im ESM. |
 |
| Abb. 9: Hinzufügen eines Enterprise-Benutzers im ESM. |
Enterprise Benutzer existieren nicht in der Datenbank, sondern werden als Einträge im OID angelegt. Sie sind dort einem Shared Schema zugeordnet und bekommen eine oder mehreren Enterprise Rollen zugewiesen.
Enterprise Rollen und -Benutzer werden über den Enterprise Security Manager angelegt. Er erstellt dabei automatisch die entsprechenden Einträge im OID. Auf diese Weise werden nun die Enterprise Rollen e_role1 und e_role2 sowie die beiden Enterprise Benutzer lk und ml in der OracleDefaultDomain angelegt.
Beim Anlegen der Benutzer sind Angaben, wie z. B. der vollständige Name der Person, die E-Mail-Adresse und natürlich ein Passwort für die spätere Anmeldung an der Datenbank zu machen.
Beim Anlegen des Benutzers ordnen wir ihm auch gleich eine der eben erstellten Enterprise Rollen zu. Das geschieht über den Reiter "Enterprise-Rollen" im Dialog "Benutzer erstellen". Der Benutzer lk wird der e_role1 und ml wird der e_role2 zugeordnet (siehe Abbildungen 8 und 9).
Als nächstes muss unserem benutzten Oracle Context unter dc=ordix,dc=de eine sogenannte Benutzersuchbasis zugeordnet werden. Unter dieser sucht der OID die Enterprise Benutzer. Unsere Enterprise Benutzer wurden unter cn=Users,dc=ordix,dc=de (siehe Abbildung 10) angelegt. Somit ist dieser DN als Benutzersuchbasis im Reiter "Allgemein" unseres Oracle Contextes hinzuzufügen.
 |
| Abb. 10: Zuordnung einer Benutzersuchbasis zu einem Oracle Context. |
Alle unsere Enterprise Benutzer sollen auf der Datenbank mit demselben Shared Schema (s_schema) arbeiten. Die Einträge für die Enterprise Benutzer müssen dazu dem Shared Schema zugeordnet werden. Wir wählen in unserem Context unter dem Punkt "Datenbanken" unsere oradb aus und wählen unter dem Reiter "Datenbankschema-Zuordnung" die Benutzer aus und tragen das Schema ein.
Die endgültigen Privilegien, die die Benutzer später in der Datenbank haben werden, ergeben sich aus den erstellten globalen Rollen in der Datenbank. Im ESM werden die globalen Rollen unseren Enterprise Rollen zugeordnet. Die jeweilige Enterprise Rolle wird unter der OracleDefaultDomain ausgewählt. Unter dem Reiter "Globale Datenbankrollen" nehmen wir die Zuordnung zu den globalen Rollen vor.
Auf diese Weise richten wir es ein, dass g_roleA den beiden Rollen e_role1 und e_role2 zugeordnet wird, während g_roleB nur der Rolle e_role2 zugeordnet wird. Daraus ergibt sich die in Abbildung 11 gezeigte Zuordnung.
 |
| Abb. 11: Zuordnungen zwischen Enterprise Benutzern, Enterprise Rollen, globalen Rollen und einem Shared Schema. |
Nun sind alle Konfigurationen und Zuordnungen durchgeführt. Die Benutzer können sich jetzt über den OID an der Datenbank anmelden, ohne darin mit einem CREATE USER Befehl angelegt worden zu sein. Es wird das Passwort benutzt, welches beim Erstellen des Enterprise Benutzers angegeben wurde. Dies ist in unserem Fall das Standardpasswort welcome1, welches der ESM beim Anlegen eines Enterprise Benutzers vorgibt. Dieses kann natürlich beliebig geändert werden kann.
Der Benutzer lk meldet sich an der Datenbank z. B. mit dem Befehl sqlplus lk/welcome1@oradb mit dem Netservicenamen oradb an.
In dieser Artikelreihe haben wir Ihnen zwei Haupteinsatzgebiete für das Oracle Internet Directory beschrieben. Zum einen wurde eine Möglichkeit aufgezeigt, die Auflösung von Netservicenamen vom Oracle Names zu trennen, indem diese nun im OID abgelegt und damit von einer zentralen Stelle aus im Netzwerk genutzt und gepflegt werden können.
Zum anderen haben wir Ihnen in diesem Artikel die Benutzer- und Rollenverwaltung mit dem OID vorgestellt. Benutzer müssen nicht mehr in einer Instanz angelegt werden, sondern liegen als Objekte im LDAP-Verzeichnisdienst. Dies erleichtert den Administrationsaufwand ungemein. Die Installation und Konfiguration des OID und die Einbindung von SSL für die Absicherung von Verbindungen ist mit Sicherheit nicht ganz trivial, allerdings sind dies einmalige Schritte und die im Nachhinein gesparte Zeit ist sehr groß.
Michael Lindermann, Lars Hendrik Korte (info@ordix.de).