Datenbank-gestützte Authentifizierung und Autorisierung von Web … › docs › WEBauthentication.pdf · 2008-12-16 · Version 10-2005 ©Database Consult GmbH - Jachenau Folie

Datenbank-gestützte Authentifizierung und Autorisierung

von Web-Applikationen

Dr. Günter UnbescheidDatabase Consult GmbH - Jachenau

Version 10-2005 Folie 2 von 31 ©Database Consult GmbH - Jachenau

Authentifizierung und A

utorisierung von Web-A

pplikationenDatabase Consult GmbH

• Gegründet 1996• Kompetenzen im Umfeld von ORACLE-basierten Systemen• Tätigkeitsbereiche

– Tuning, Installation, Konfiguration– Support, Troubleshooting, DBA-Aufgaben – Datenmodellierung und –design– Datenbankdesign, Systemanalysen– Programmierung: SQL,PL/SQL,JSP, ADF UIX, BC4J– Schulungen– Expertise– www.database-consult.de




pplikationenProlog

Internetprogramme, auch Webanwendungen genannt, sind Anwendungen, die auf einem Webserver ausgeführt werden und dann in einem Browser dargestellt werden.

Kategorien von WA u.a.: Transaktionale Webanwendungen(Erweiterung um den Bereich Datenbanken)

Wikipedia

- Datenbanken steuern immer häufiger die Aufbereitung dynamischer Web-Seiten

- Die intensive Eingabe und Modifikation von Daten stellt zusätzliche Anforderungen an Authentifizierung und Autorisierung

- Durch multiple Nutzungskontexte sollte AA auch über DBabgesichert werden

- Das Datenmodell ist i.d.R. dauerhafter als die Präsentationsschichten




pplikationenAgenda

• Einführung: Application Server und Datenbanken• Connection – Session – Authentifizierung• Secure Application Roles und Client Identifier• Proxy Authentication• Virtual Private Database• Auditing

Stand der Technik: Oracle 10g Release 2




pplikationenEinführung

Datenbank

++

Einheit von Session und Connection





Stateless Requests über HTTP(S)

+

ApplicationServer





DatenbankApplicationServer

Stateless Requests

„Permanente“ Verbindung

+




pplikationenConnection Pool

• Wiederverwendung physischer Datenbankverbindungen• Konfigurierbarer Aufbau

– Minimale und maximale Anzahl physischer Verbindungen– Maximale Idle-Zeiten zum Abbau der Verbindung

• Ähnelt Multithreaded Server der Datenbank

DatenbankApplicationServer




pplikationenGrundmodell

• Zentraler, fest codierter Applikationsbenutzer auf Seiten des App-Server

• Unterschiedliche Endbenutzer mit diversen Privilegienanforderungen

• Größtmöglicher Querschnitt aus allen erforderlichen Objektprivilegien für App-Benutzer

• ggf. Filterung der erforderlichen Privilegien durch Mittelschicht

• Gefahr des Mißbrauchs bei „Quereinstieg“, z.b. Client-Server Applikation




pplikationenEinflussfaktoren

Session Connection

Authentication

Authorization

Auditing

+




pplikationenApplicationUser

Was – Wo?

DatenbankApplication

Server

Strukturelle „Stabilität“Zentralität

„Präsentationsdynamik“„Pluralität“

Authentication AuthenticationAuthorization Authorization

Auditing Auditing

EndUser




pplikationenIntermezzo: JDBC

• Java Database Connectivity– Java Standard zur Verbindung zwischen Java-

Programmen/Applicationserver und relationalen Datenbanken– kompatibel mit SQL92 entry level

• Implementiert über Standard java.sql Interfaces• Komponenten

– Standard JDBC APIs– Oracle Treiber mit spezifischen Erweiterungen zur

Unterstützung von Oracle-Datentypen und Performance-Verbesserungen

• Spezifische Erweiterungen über oracle.jdbcPackage




pplikationenIntermezzo: JDBC

• 3 Ausprägungen– Thin driver: „reiner“ Java-Treiber auf Clientseite ohne Oracle-

Client-Installation für Applets und Anwendungen.Implementiert SQL*Net über Java Sockets mit TCP/IP

– OCI-Treiber (thick driver): Treiber auf Clientseite mit Oracle-Client-Installation für AnwendungenKonvertiert in OCI-Calls

• breitere Funktionalität: OCI Connection Pool, TAF– Server-side thin driver: wie thin driver jedoch für Java-Code auf

dem Datenbankserver für Zugriffe auf andere Session bzw. Server

– Server-side internal driver: Java-Code für Zugriffe innerhalb einer Session




pplikationenConnection Modelle (1)

• Implicit Connection Cache– JDBC 3.0 kompatible Implementierung des DataSource Interface– Logische Verbindungen (Anforderungen) und physische Verbindungen

• Verfügbar für thin und thick (OCI) Treiber• Ein Cache pro DataSource Instance möglich mit unterschiedlichen

Benutzer-Authentifikationen.• Cache Properties: MinLimit, MaxLimit, InitialLimit,Timout-Properties

+




pplikationenConnection Modelle (2)

• OCI Connection Pooling• Verfügbar nur für JDBC OCI Treiber (thick JDBC)• Session Mulitplexing von logischen Verbindungen über (wenige)

physische Verbindungen• Call-Basis• Trennung von Session und Connection• Codebeispiel siehe Artikel

+




pplikationenSchema-Trennung

App-User

Owner

Internal Ux

Uy

Rollen / current_schema




pplikationenProxy-Authentifizierung

• Proxy Authentication– Connection/Benutzer A agiert als Proxy für Benutzer B, C, D …..– Verfügbar für thin und thick JDBC– Proxy-Connections nutzen Caching

• Prinzip– Application-Benutzer wird authentifiziert– Datenbank-Endbenutzer gibt Privilegiesierung vor

+





• Zu beachten:• Datenbank „kennt“ Endbenutzer• Datenbank privilegiesiert Endbenutzer• App-Benutzer benötigt kein Passwort von Endbenutzer• Auditing und Logging kennen Proxy

– proxy_sessionid in Tabelle aud$

• Unterschiedliche Möglichkeiten der Authentifizierung (s.u.)

• Untermenge von Privilegien ist möglich





-- App-User anlegenCREATE USER application1 IDENTIFIED BY apppwd;-- andere Authentifizierungen sind machbar-- App-User minimal privilegierenGRANT CREATE SESSION TO application1;-- Enduser anlegen und privilegierenCREATE USER enduser1 IDENTIFIED BY endpwd;GRANT r1, r2, r3 TO enduser1;-- (anonymes) Proxy einrichten und privilegisierenALTER USER client1

GRANT CONNECT THROUGH applikation1 WITH ROLE r2;

-- Eingaben überprüfen über ViewSELECT * FROM DBA_PROXIES;





-- Alternativen der Authentifizierung für Enduser-- (a) anonym (ohne Angabe eines PW für Enduser)ALTER USER <usr> GRANT CONNECT THROUGH <appusr>;-- (b) unter Angabe des PW von EnduserALTER USER <usr> GRANT CONNECT THROUGH <appusr>

AUTHENTICATED USING PASSWORD;-- (c) unter Angabe von Distinguished Name (noch) CREATE USER gu IDENTIFIED GLOBALLY AS'CN=gu,OU=Europe,O=dbconsult,L=jachenau,ST=by,C=de';ALTER USER <usr> GRANT CONNECT THROUGH <appusr>

AUTHENTICATED USING DISTINGUISHED NAME;-- (d) unter Nutzung eines DN über ZertifikatALTER USER <usr> GRANT CONNECT THROUGH <appusr>

AUTHENTICATED USING CERTIFICATE TYPE 'X.509' VERSION '3';





SELECT schemaname, status, username, type, serverFROM v$sessionWHERE username IS NOT NULL;

SCHEMANAME STATUS USERNAME TYPE SERVER------------ ------------ ------------ --------- -----------

CLIENT1 INACTIVE CLIENT1 USER PSEUDOAPPLICATION1 INACTIVE APPLICATION1 USER DEDICATED

SYSTEM ACTIVE SYSTEM USER DEDICATED




pplikationenEnterprise User

shared schema

LDAPenterprise user

global roles

enterprise roles

enterprise user




pplikationenEnterprise User Proxy

schema

LDAPenterprise userproxy permissions

enterprise user

ALTER USER local_database_user_name GRANT CONNECT THROUGH ENTERPRISE USERS;




pplikationenClient Identifier

• Beliebige, freibleibende „Markierung“ einer Session– Z.B. mit Namen des Endusers– Nicht zu verwechseln mit „Client Info“– Zur Sicherheit entsprechende Plausis einbauen

• Protokolliert in aud$• Enduser müssen nicht in DB eingerichtet sein• Authorisierung z.B. über Secure Application Roles

+





-- Fragment eines Startpakets von AppuserCREATE OR REPLACE PROCEDURE app (user_in IN VARCHAR2)AUTHID CURRENT_USERIS -- diverse DeklarationenBEGIN

-- .. je mehr kombiniert wird, desto sichererIF SYS_CONTEXT ('userenv', 'ip_address') = valid_ip

AND SYS_CONTEXT ('userenv', 'host') = valid_hostAND SYS_CONTEXT ('userenv', 'external_name') = valid_ext

THEN-- Client Identifier wie authentifizierter BenutzerDBMS_SESSION.set_identifier (user_in);-- Rolle AktivierenDBMS_SESSION.set_role ('DEMO_ENDUSER');

-- etc.





-- Zugriff auf gesetzten Client IdentifierSELECT * FROM my_view WHERE benutzer = SYS_CONTEXT('userenv', 'client_identifier');-- Löschen…BEGIN

DBMS_SESSION.clear_identifier;END;/-- Absicherung der Logik des Startpakets durch Wrap-- SQL-Syntax in Datei, dann auf BS-Ebene:wrap iname=pack.sql-- Verbesserungen unter 10g (siehe nächste Folie)-- … oder in R2:begin dbms_ddl.create_wrapped('create or replace procedure p1 as

begin null; end;') end; /





abcd731d 223abmdzXjvd7hFJQbws1ew0M8o9rQwg/DxzPYVfI4C/mgPUprlymWkSnkGhDxxF2fr8Rr8QebqahsRpHmNzZq7yU1Z31JrqHkpOrmtxHjMUkZ6XOdWoQ73J8MrWg72l8Mh4OUFdFQnYKyEicUCJVS1Lsr1pqY/0LCfl9SsuvfdOOktd0Chx0ZnjL9VRgf7RpD4SJjHErG5M4OQ/y60tQKIlYNx

1APP:1USER_IN:1VARCHAR2:1AUTHID:1CURRENT_USER:1LV_VALID_IP:1CONSTANT:150:1192.168.13.113:1LV_VALID_HOST:1myserver:1LV_VALID_EXTERNAL:1cn=guenter,cn=users,dc=dbconsult,dc=de:1SYS_CONTEXT:




pplikationenAutorisierung

• Anforderungen– Zentrale App-Accounts mit wechselnden Identitäten/Endbenutzern– Individuelle Privilegisierung (need to know- und least privilege-Prinzip)

• Konsequenzen– Keine fest gegranteten Objektprivilegien möglich– Flexible und sichere Schaltung von Rollen: Secure Application Roles

+




pplikationenSecure Application Roles

• Rollenaktivierung über prädestinierte Programmeinheiten– Programme sollten Plausibilitäten prüfen

• Zuteilung der Rollen an App-Benutzer nicht als Default!

-- Die Rollen werden geschaltet über das Schema SECUSER (Locking)CREATE ROLE demo_enduser IDENTIFIED USING secuser.setpriv;-- Aufbau der Programmeinheit-- Kontrolle der angelegten Application RolesSELECT ROLE, SCHEMA, PACKAGE

FROM dba_application_roles WHERE SCHEMA = 'SECUSER'; -- Zuteilung der Application Roles an den APP-BenutzerGRANT demo_enduser TO appuser;GRANT EXCUTE ON secuser.setpriv TO appuser;-- Application Roles sollen keine Default Rollen sein:ALTER USER appuser DEFAULT ROLE NONE;




pplikationenSecure Application Roles

• Programmeinheit– Implementiert in separatem Security Schema ohne create session Privileg (account lock)

• Diverse Plausbilitäten einbauen:– Hierzu sys_context('userenv ', '…') oder v$session– Z.B. authentication_type, ip_address, terminal, programm etc.

• Code schützen durch „wrapping“




pplikationenVirtual Private Database

• VPD = fine grain access control– Kontext-abhängige, automatische Generierung von where-Klauseln

• Eingeführt unter Version 8, unter 9 und 10 erweitert• Komponenten

– Anwendungskontexte – kennen name-value-Paare– Policy-Funktionen – erzeugen Where-Klauseln– Policies – verbinden Funktionen, DB-Objekte und Operationen

User A> SELECT * FROM x;

User B> SELECT * FROM x;

where col = 'x'

where col = 'y'





• Anforderungen bei Webanwendungen– Sessions mit wechselnden Identitäten– Dadurch schnelle und effiziente Anpassung der Kontexte

• Technologien– Globale Applikationskontexte

• Gespeichert in SGA, d.h. für alle Sessions verfügbar• Können gekoppelt sein an User und Client-Identifier

– Funktions, Policies und Policy Groups wie gehabt





-- Anlegen und autorisieren des globalen ContextsCREATE CONTEXT test_ctx USING secusr.secprocACCESSED GLOBALLY;-- pauschales aktivieren (für alle) in SECPROCDBMS_SESSION.SET_CONTEXT(namespace => 'test_ctx' ,attribute => ' name1',value => ' wert1');

-- AusschaltenDBMS_SESSION.CLEAR_ALL_CONTEXT ('test_ctx');-- Aktivieren für alle unter Schema USRDBMS_SESSION.SET_CONTEXT(namespace => 'test_ctx' ,attribute => ' name1',value => ' wert1' , username => ' USR');

-- zusätzliche Kopplung an Client IdentifierDBMS_SESSION.SET_CONTEXT(namespace => 'test_ctx' ,attribute => ' name1'

,value => ' wert1' , username => ' USR',client_id => 'U');




pplikationenAuditing

• Erweiterte Attribute, zB. DBA_COMMON_AUDIT_TRAIL– AUDIT_TYPE– Session_id– Proxy_sessionid– Global_uid– Db_user– Client_id– Ext_name– Comment_text (enthält Authentication_Type)– Priv_used




pplikationen

Danke für´s Zuhören

Documents

Datenbank-gestützte Authentifizierung und Autorisierung von Web … › docs › WEBauthentication.pdf · 2008-12-16 · Version 10-2005 ©Database Consult GmbH - Jachenau Folie