Datenbank-gestützte Authentifizierung und Autorisierung von Web-Applikationen

Transkript

1 Mittwoch, 9. November h00, Variohalle 4 Datenbank-gestützte Authentifizierung und Autorisierung von Web-Applikationen Dr. Günter Unbescheid Database Consult GmbH, Jachenau Schlüsselworte: Web-Applikation, Authorisierung, Authentifizierung, Proxy-Authentifizierung, Secure Application Roles, Client Identifier, lightweight sessions, Connection Pool, Einleitung Vor dem Hintergrund des unaufhörlichen Wachstums des Internet werden Oracle-Datenbanken immer häufiger für die dynamische Aufbereitung von Web-Seiten eingesetzt. Neben dynamisch aufbereiteten Informationsseiten, die verhältnismäßig geringe Anforderungen an die Sicherheit stellen, gibt es mittlerweile zahllose Web-Applikationen, welche über Browser und Application Server mit (Oracle-)Datenbanken arbeiten. Diese Anwendungen sind gekennzeichnet durch die intensive Eingabe und Modifikation von Daten, deren Persistenz darüber hinaus im Kontext von Transaktionen zu sichern ist. In einem solchen Umfeld ist in den meisten Fällen die genaue Authentifizierung und die darauf aufbauende Autorisierung der agierenden Benutzer unerlässlich. Eine rundum gutes Applikationsdesign stützt sich hierbei nicht nur auf die technologischen Möglichkeiten der jeweiligen Application Server und der in ihrem Kontext implementierten Business Logik, sondern bindet vielmehr auch die Datenbank in diesen Sicherheitsprozess mit ein. Durch die in Web-Applikationen eingesetzten, statuslosen HTTP-Protokolle und die großen Benutzerzahlen kommen auf die Datenbank auch in diesem Bereich verglichen mit herkömmlichen Client-Verbindungen völlig neue Anforderungen zu. Der vorliegende Beitrag zeigt die in den Oracle-Versionen 9i und 10g geschaffenen Datenbanktechnologien, um mit diesen Anforderungen an die Authentifizierung, Autorisierung und die Connect-Strategie optimal umzugehen. Einführung: Connection Session Authentifizierung In der Welt des Client Server Computing sind die drei in der Überschrift genannten Begriffe eng miteinander verzahnt: Beim Start einer Anwendung wird der Benutzer bekanntermaßen aufgefordert seinen Namen und in den meisten Fällen sein Passwort und das betreffende Zielsystem einzugeben. Es wird dann eine physische Verbindung zwischen dem Client-Prozess und der Oracle-Instanz auf dem Zielsystem aufgebaut, der Benutzer wird in der Regel über die Datenbank authentifiziert und autorisiert und auf diese Weise in eine Session eingebettet. Die physische Verbindung und mit ihr die Session werden ununterbrochen aufrechterhalten, bis der Betreffende durch ein Disconnect die Arbeit mit der Datenbank beendet. Die Kommunikation zwischen den Browsern und ihren Benutzern und dem Applikation Server wird dagegen über das statuslose HTTP-Protokoll geregelt, bei dem jede Aktion als separater Call über das Netzwerk geschickt wird. Die Verbindung zur Datenbank wird in diesem Modell einzig durch den Application Server geregelt. Aufgabe des Application Server ist es, die einzelnen Calls, die darüber hinaus auch noch von einer Vielzahl von Endbenutzern stammen, logisch zu bündeln und sie in dieser Form an die Datenbank weiterzuleiten, so dass diese die eingegebenen und modifizierten Daten im Kontext von Transaktionen sicher verwalten kann. Speziell in Web-Anwendungen kommt hinzu, dass jeder Endbenutzer auch innerhalb der Datenbank einen eindeutigen Sicherheitskontext erhalten muss, der vorgibt, welche Daten er lesen und schreiben darf. Darüber hinaus sind häufig die von der Anwendung verwalteten Endbenutzer der Datenbank als user unbekannt. Aus diesem Grund kommt zu der erwähnten logischen Bündelung der Calls für den Application Server auch noch die Aufgabe hinzu, die Verknüpfung von Endbenutzern zu den vorhandenen Datenbankbenutzern zu regeln. Die Statuslosigkeit des HTTP-Protokolls bedingt ebenfalls, dass es kein Ende einer Sitzung geben kann die Calls eines bestimmten Benutzers bleiben irgendwann einfach aus. Aus den genannten Gründen würde der im Client Server Umfeld übliche, individuelle Verbindungsauf- und -abbau zu untragbaren Belastungen der Ressourcen und daher auch zu nicht akzeptablen Antwortzeiten führen.

2 Application Server verwalten aus diesen Gründen sogenannte Connection Pools. Dies sind benannte Datenbankverbindungen, die beim Start der Applikation initialisiert werden. Durch entsprechendende Parametrierungen lassen sich die minimale und maximale Anzahl dieser Verbindungen, sowie die Idle- Zeiten für den Verbindungsabbau konfigurieren. Im Umfeld von Oracle s ADF Framework werden beispielsweise die Connection Pools von sogenannten Application Module Pools genutzt. Die Instanzen dieser Pools können nun in Folge von unterschiedlichen Endbenutzern rekrutiert werden, um die Verbindung mit der betreffenden Datenbank aufzunehmen. Ein Pool Monitor prüft die Pools in konfigurierbaren Zeitintervallen und sorgt dafür, dass Verbindungen, die den Grenzwert der Untätigkeit überschritten haben, physisch abgebaut werden. Auf diese Weise wird erreicht, dass Verbindungen trotzt des statuslosen HTTP- Protokolls, dauerhaft erhalten bleiben und von diversen Endbenutzern genutzt werden können. Connection-Modelle Aus Sicht des Application Server die hier nur am Rande betrachtet werden soll ergeben sich die folgenden technischen Möglichkeiten zur Nutzung von Connection Pools: Beim sogenannten impliziten Connection Cache, der über JDBC realisierbar ist, werden physische Verbindungen und in ihrem Kontext Sessions angelegt und in einem Pool verwaltet, der wie bereits erwähnt wurde über Minimal- und Maximal-Parameter verwaltet werden kann. Neue Verbindungsanforderungen nutzen dann bereits bestehende, aber nicht mehr genutzte Verbindungen, solange der Benutzername der geforderten Verbindung mit dem der bereits bestehenden identisch ist. Neue physische Verbindungen werden immer dann eröffnet, wenn die Anforderung unter einem neuen Benutzernamen abgegeben wird. Hält der Pool beispielsweise drei ungenutzte physische Verbindungen unter dem Benutzer scott1 und wird eine Session unter scott2 angefordert, initialisiert der Server eine neue physische Verbindung zur Datenbank. Eine Anforderung von für scott1 dagegen könnte eine der bereits bestehenden, inaktiven Verbindungen für sich aktivieren. In diesem Modell sind mit anderen Worten die physische Verbindung und die Datenbank Session untrennbar miteinander verbunden. Beim OCI Connection Pool der im Rahmen des dicken JDBC-Treibers verfügbar ist wird die Verzahnung von physischer Verbindung und Session aufgebrochen. In diesem Modell kann eine physische Verbindung nacheinander für Sessions unterschiedlicher Benutzer aktiviert werden sogenannte lightweight sessions entstehen. Auf diese Weise kann der Pool auch dann überschaubar gehalten werden, wenn unterschiedlichste Datenbankbenutzer sich über die Verbindungen in die Datenbank einwählen. Authentifizierungsmodelle Die im vorangehenden Abschnitt dargestellten Möglichkeiten der Nutzung und Realisierung von physischen Verbindungsmodellen muss einhergehen mit einer sicheren Authentifizierung der betreffenden Benutzer in der jeweiligen Datenbank. Auch hierfür sind unterschiedliche Modelle denkbar. Die wichtigsten werden in den folgenden Abschnitten skizziert: Die Verbindungen des Connection Pools werden über einen fest konfigurierten zentralen Anwendungsbenutzer abgewickelt. Dieser Benutzer ist getrennt von dem jeweiligen Schema Owner zu halten, dem die notwendigen Tabellen und Prozeduren der betreffenden Anwendung gehören. Der Anwendungsbenutzer selbst hat nur minimale Default-Rechte (create session). Seine Autorisierung wird vielmehr über secure application roles (s.u.) geregelt, die über ein autorisiertes Paket aktiviert werden können. Dieses Paket kann diverse Prüfroutinen für die Plausibilisierung der Autorisierung nutzen und kann auch wenn erforderlich Applikations Kontexte für die Aktivierung von virtual private database einschalten. Um die Identität des vom Application Server authentifizierten Endbenutzers transparent zu machen, können zusätzlich Client Identifier genutzt werden (s.u.), die auch von den Auditing-Routinen der Datenbank ausgewertet werden können. Auch in diesem zweiten Modell existiert ein fest konfigurierter Anwendungsbenutzer. Diese Benutzer wird jedoch nur als Proxy verwendet (s.u.) und erhält seine Rechte stellvertretend für andere, in der Datenbank eingerichtete Benutzer. Secure Application Roles und Client Identifier Secure Application Roles werden so angelegt, dass eine namentlich genannte PL/SQL-Programmeinheit für ihre Aktivierung verantwortlich zeichnet. Innerhalb dieser Prozedur lassen sich dann sinnvolle Plausibilitäten einbauen, bevor die genannte Rolle aktiviert wird. Es versteht sich, dass die genannte Programmeinheit weder im Schema des Begünstigten liegen sollte, noch der Betreffende Ausführungsrechte für diese Programmeinheit haben sollte. Gleichfalls sollte die Rolle nicht als Default-Rolle an die Begünstigten vergeben werden. In der Regel wird ein separates Schema beispielsweise ein Applikationsbenutzer geschaffen, in dessen Kontext die entsprechende Programmeinheit angelegt wird.

3 Im folgenden Beispiel wird die Rolle demo_enduser angelegt, die über die Programmeinheit app des Schemas appuser aktiviert werden soll. Für das Anlegen der Rolle ist es nicht notwendig, dass die Programmeinheit und der Benutzer bereits existieren: CREATE ROLE demo_enduser IDENTIFIED USING appuser.app; Existierende Application Roles können über die View dba_application_roles selektiert werden. Zur Aktivierung der neuen Rolle ist nun im Schema appuser die Prozedur oder das Paket app anzulegen. Die Aktivierung erfolgt dann letztendlich über den Aufruf der set_role Prozedur des Paketes DBMS_SESSION. Damit dies gelingt, muss die Prozedur app als invokers right Code deklariert worden sein. Gleichzeitig stehen alle möglichen Mechanismen zur Verfügung, vor der Aktivierung diverse Plausibilitätsprüfungen durchzuführen. Darüber hinaus kann die Prozedur auch gewrapped werden, um die Logik der Plausibilitätsprüfungen zu verschleiern. Schließlich sollte der Applikationsbenutzer in unserem Beispiel appuser durch starke Authentifizierungsmaßnahmen zusätzlich vor Missbrauch geschützt werden. Das folgende Codebeispiel zeigt Fragmente einer möglichen Aktivierungsprozedur: CREATE OR REPLACE PROCEDURE app (user_in IN VARCHAR2) AUTHID CURRENT_USER IS -- hier z.b. IP-Adresse des Application Server, der sich einwählt lv_valid_ip CONSTANT VARCHAR2 (50) := ' '; -- Hostname des App-Server Rechners lv_valid_host CONSTANT VARCHAR2 (50) := 'myserver'; -- Externer Name bei einer Authentifizierung über Enterprise Benutzer lv_valid_external CONSTANT VARCHAR2 (50) := 'cn=guenter,cn=users,dc=dbconsult,dc=de'; BEGIN --.. je mehr kombiniert wird, desto sicherer IF SYS_CONTEXT ('userenv', 'ip_address') = lv_valid_ip AND SYS_CONTEXT ('userenv', 'host') = lv_valid_host AND SYS_CONTEXT ('userenv', 'external_name') = lv_valid_external THEN -- Rolle Aktivieren DBMS_SESSION.set_role ('DEMO_ENDUSER'); -- Client Identifier für authentifizierten Benutzer DBMS_SESSION.set_identifier (user_in); und Schema auf den Owner schalten spart Synonyme EXECUTE IMMEDIATE ('alter session set current_schema = APP_OWNER'); -- ggf. weitere Einstellungen: Client Identifier/Client Info etc. END IF; EXCEPTION WHEN OTHERS THEN -- hier entsprechende Routinen RAISE; END app; / Um die Logik der oben dargestellten Prozedur weitergehend zu schützen, bietet es sich an, den Code zu wrappen. In der Version 10g wurde dieses Feature dahingehend verbessert, dass nun sämtliche Zeichenketten in unleserlicher Form auftauchen und damit Rückschlüsse auf den Programmablauf nicht mehr möglich sind. Um die Prozedur app zu wrappen, wird im ersten Schritt der Code in eine Datei geschrieben in unserem Beispiel die Datei app.sql. Auf der Kommandozeile kann dann das Hilfsprogramm wrap in folgender Form aufgerufen werden: wrap iname=app.sql Der gesetzte Client-Identifier kann dann beliebig im SQL-Kontext genutzt werden select * FROM my_view WHERE benutzer = sys_context('userenv', 'client_identifier');

4 Proxy Authentifizierung Bei der Proxy Authentifizierung wird ebenfalls ein Applikationsbenutzer angelegt, der selbst nur minimale Privilegien erhält und über den sich der Application Server einwählt. Die Authentifizierung dieses Benutzers in der Datenbank kann über ein Passwort oder über ein Zertifikat per SSL erfolgen: CREATE USER application1 IDENTIFIED BY...; GRANT... TO applikation1; Die für die Anwendung nötigen Endbenutzer sind ebenfalls in der Datenbank angelegt worden und haben die für ihre Aufgaben nötigen Datenbankrollen erhalten. Für den Fall, dass sie außerhalb der Anwendung keine separaten Aktivitäten durchführen sollen, kann ihnen das create session Privileg vorenthalten werden: CREATE USER client1 IDENTIFIED...; GRANT rolle1,rolle2 TO client1; Im nächsten Schritt erhält nun der Anwendungsbenutzer das Recht, client1 für den Sitzungsaufbau als Proxy zu nutzen: WITH ROLE rolle2; Zusätzlich wird in diesem Beispiel für client1, wenn er über die den Applikationsbenutzer applikation1 mit der Datenbank verbunden wird, nur die Rolle rolle2 aktiviert. Die Mittelschicht ist nun in der Lage die Session von applikation1 im Namen und mit den Privilegien von client1 zu nutzen, unter der Voraussetzung, dass die Verbindung über den dicken JDBC-Treiber aufgebaut wird. Im angegebenen Beispiel wird die Session ohne weitere Authentifizierung im Namen von client1 eröffnet. Alternativ sind jedoch Varianten denkbar, bei denen der Applikationsbenutzer zum Verbindungsaufbau im Namen des Clients zusätzliche Authentifizierungsmethoden einsetzten muss: -- (a) Passwort von CLIENT1 muss mit angegeben werden AUTHENTICATED USING PASSWORD; -- (b) Zertifikat von CLIENT1 muss geliefert werden AUTHENTICATED USING CERTIFICATE; -- (c) Distinguished Name von CLIENT1 muss mit angegeben werden AUTHENTICATED USING DISTINGUISHED NAME; Proxy-Einstellungen dieser Art lassen sich über die View dba_proxies selektieren. Die Vorteile der Proxy Authentifizierung wurden eingangs bereits dargestellt. Das folgende. kurze Codebeispiel illustriert das Vorgehen im Kontext eines Java-Client-programms. Da wie bereits erwähnt zur Nutzung der Proxy-Authentifizierung der dicke JDBC-Treiber benötigt wird, ist es wichtig, den Klassenpfad vor der Ausführung des Programms auf $ORACLE_HOME/jdbc/lib zu setzen. Dieses Verzeichnis enthält die dicken JDBC-Treiber. Wenn dieser Test mit Hilfe vom JDeveloper ausgeführt wird, lässt sich der Pfad einstellen über: <Project> Project Properties Profiles _ Development Libraries. package mypackage1; import java.sql.*; import java.util.*; // Pfad muss auf DICKES JDBC zeigen import oracle.jdbc.*; import oracle.jdbc.pool.oracleociconnectionpool; import oracle.jdbc.oci.oracleociconnection; public class ProxConn public static void main (String [] args)

5 String aliasname = "(DESCRIPTION = (ADDRESS_LIST = (ADDRESS = " + " (PROTOCOL = TCP) (HOST = myserver) (PORT = 1521)))" + " (CONNECT_DATA = (SERVICE_NAME = TEST10.DBCONSULT.DE)))"; try OracleOCIConnectionPool db = new OracleOCIConnectionPool(); db.seturl("jdbc:oracle:oci:@"+aliasname); // Benutzer für Applikationsidentität db.setuser("application1"); db.setpassword("apppwd"); Properties pr = new Properties(); // OCI Connection-Pool:Initiale + maxim. Anzahl physischer Connects pr.setproperty(oracleociconnectionpool.connpool_min_limit,"1"); pr.setproperty(oracleociconnectionpool.connpool_increment,"1"); pr.setproperty(oracleociconnectionpool.connpool_max_limit,"10"); db.setpoolconfig(pr); // Einstellungen fuer Proxy-User Properties proxyuser = new Properties(); proxyuser.setproperty(oracleociconnectionpool.proxy_user_name, "client1"); Connection co = db.getproxyconnection(oracleociconnectionpool.proxytype_user_name, proxyuser); System.out.println("Erfolgreich!"); // Abwarten um ueber v$session zu beobachten Thread.sleep(15000); co.close(); catch (Exception ex) System.out.println(ex.toString()); Auf Seiten der Datenbank lässt sich über die View v$session der Verbindungsaufbau gut verfolgen: SELECT schemaname, status, username, type, server FROM v$session WHERE username IS NOT NULL; 01 SCHEMANAME STATUS USERNAME TYPE SERVER CLIENT1 INACTIVE CLIENT1 USER PSEUDO 04 APPLICATION1 INACTIVE APPLICATION1 USER DEDICATED 05 SYSTEM ACTIVE SYSTEM USER DEDICATED Zeile 4 zeigt die dedizierte Verbindung über den Benutzer application1, die der OCI Connection Poolminimal initiiert. Durch den Proxy-Connect wird eine Session unter client1 erzeugt (Zeile 3), welche die physische Verbindung von application1 nutzt, jedoch in der View als Pseudo-Server angezeigt wird. Die Session in Zeile 5 hat die Abfrage abgesetzt. Die Übergabe des Passwortes für den Applikationsbenutzers application1 erfolgt in unserem Beispielprogramm hart codiert. Alternativ könnten Verfahren, beispielsweise über SSL, zum Einsatz kommen, bei denen kein Passwort explizit übergeben werden muss oder bei denen durch die Verschlüsselung und Integritätsprüfung die übertragenen Daten entsprechend abgesichert werden. Für Verbindungen aus dem OCI-Kontext stehen in diesem Zusammenhang grundsätzlich die gleichen Mechanismen wie für Oracle Net bereit. Kontaktadresse: Dr. Günter Unbescheid Database Consult GmbH Laich 9 D Jachenau Telefon: +49(0) Fax: +49(0) g.unbescheid@database-consult.de Internet: