1 Applikations-Sicherheit

Sicherer Betrieb von Oracle Forms-Applikationen
TSBU Middleware
J. Menge
März 2008
Version 1.1
Oracle Deutschland GmbH
Riesstr. 25
80992 München
www.oracle.com
Sicherer Betrieb von Oracle Forms-Applikationen
Inhaltsverzeichnis
1
APPLIKATIONS-SICHERHEIT
2
1.1
Traditionelle Authentifizierung
2
1.2
Autorisierung
3
1.3
Authentifizierung (Single Sign-On)
1.3.1
Verwendung alternativer LDAP-Verzeichnisse
1.3.2
Verwendung des Oracle Virtual Directory
3
5
7
1.4
Ausblick
7
1.5
Strong Authentication
7
2
DATENBANK-SICHERHEIT
8
2.1
Traditionelle Authentifizierung
8
2.2
Autorisierung
8
2.3
Authentifizierung (Single Sign-On)
8
2.4
Ausblick
9
2.5
Forms und Virtual Private Database (VPD)
3
10
VERSCHLÜSSELUNG (SSL)
10
1 Applikations-Sicherheit
1.1 Traditionelle Authentifizierung
In einer traditionellen Forms-Umgebung erfolgt die Authentifizierung beim Aufruf des Forms-Moduls
durch ein Login an der Datenbank (Username, Password, Connect String).
Als Benutzer ist der Eigentümer des Schemas anzugeben, in dem sich die Basis-Tabellen bzw. -Views
des aufgerufenen Forms-Moduls befinden. Diese Authentifizierung kann durch Programmierung des
ON-LOGON-Triggers in Forms modifiziert, z.B. durch ein Null-Statement ausgeschaltet werden.
Version 1.1
Seite 2
Sicherer Betrieb von Oracle Forms-Applikationen
1.2 Autorisierung
Die Autorisierung, d.h. welche Funktionen der Benutzer aufrufen darf, erfolgt traditionell in Oracle
Forms durch die sogenannte ‚Menu Security’, mit der bestimmte Menü-Optionen der Form in
Abhängigkeit vom angemeldeten Benutzer aktiviert oder deaktiviert sind. Diese ‚Menu Security’ basiert
auf tools-spezifischen Rollen, die in älteren Forms-Versionen in den sogenannten Tools-Tabellen im
Schema SYSTEM in der Datenbank gespeichert wurden. Die Existenz und Benutzung dieser Rollen ist
optional.
In der Forms-Version 10g werden statt der spezifischen Tools-Tabellen und der Forms Menu Roles
ganz normale Datenbank-Rollen benutzt, um die Menu Security zu implementieren.
Dazu ist es erforderlich eine View in der Datenbank zu erzeugen. Die Beschreibung der notwendigen
Schritte findet man unter:
Note 28933.1
Implementing and Troubleshooting Menu Security in Forms
1.3 Authentifizierung (Single Sign-On)
Oracle Forms bietet bereits seit vielen Versionen die Möglichkeit, die Authentifizierung über den Single
Sign-On-Server (SSO-Server) des Oracle Application Servers (OracleAS) durchzuführen. Dazu muss
allerdings der OraclAS mit Infrastruktur, d.h. incl. SSO-Server und Oracle Internet Directory (OID)
installiert werden. Das Oracle Internet Directory (OID) ist ein Directory Service, der auf dem Standard
LDAP v3 basiert, und Informationen über SSO-Benutzer und ihre Anmeldeinformationen
(Credentials) speichert.
Forms benötigt zwei Arten von Benutzerinformationen im OID:
- Applikations-User (SSO User)
- Datenbank-User (Resource Access Descriptor)
Eine gesonderte Konfiguration des SSO-Service ist für Oracle Forms ab der Version 10g nicht mehr
notwendig.
Wird Oracle Forms zusammen mit der Infrastruktur des OracleAS installiert oder nachträglich bei einer
existierenden Infrastruktur registriert, wird in der Datei formsweb.cfg ein Eintrag
oid_formsid=%OID_FORMSID% erzeugt, der auf die OID-Instanz verweist.
Kann die Verbindung zum OID nicht hergestellt werden (500 Internal Error), stimmt der eingetragene
Wert oid_formsid für die Mid-Tier-Instanz nicht mit dem im OID eingetragenen Wert formsApp_ überein.
Note 279707.1
500 Internal Server Error With 10g Forms in SSO Mode
Seit Oracle Forms 10g besteht die Möglichkeit, durch dynamische SSO-Direktiven für jede FormsApplikation differenziert den SSO-Service zu aktivieren (Parameter sso_mode=true).
Version 1.1
Seite 3
Sicherer Betrieb von Oracle Forms-Applikationen
Die folgende Abbildung zeigt, wie Forms-Anwendungen mit Hilfe des OracleAS SSO-fähig gemacht
werden können:
1. Der Benutzer ruft die URL einer Forms-Anwendung auf.
2. Das Forms Servlet leitet den Aufruf an den OracleAS SSO-Server weiter.
3. Der Benutzer liefert Benutzername und Passwort durch die Eingabe über die SSO LoginForm. Der Benutzer erkennt dies daran, dass er anstelle des Forms-Login-Fensters die SSOAnmeldemaske des OracleAS präsentiert bekommt und keinen Connect String zur
Datenbank angeben muss.
4. Das Passwort wird durch das Oracle Internet Directory (LDAP v3 Server) verifiziert.
Bei erfolgreicher Anmeldung wird ein SSO-Cookie gesetzt, der für die Dauer der BrowserSession gültig ist.
5. Der Benutzer wird zur Forms-Anwendung mit den SSO-Informationen (UserID)
weitergeleitet.
6. Das Forms Servlet erhält die Datenbank-Credentials vom Oracle Internet Directory (siehe
2.3).
7. Das Forms Servlet setzt den Parameter UserID in der Runform-Session und das Applet
verbindet sich zum Forms Listener Servlet.
8. Das Forms Servlet startet den Forms Runtime-Prozess.
Version 1.1
Seite 4
Sicherer Betrieb von Oracle Forms-Applikationen
Innerhalb der Form kann programmatisch auf folgende SSO-Informationen zugegriffen werden:
authenticated_username := get_application_property('sso_userid') ;
userDistinguishedName := get_application_property('sso_usrdn') ;
subscriberName := get_application_property('sso_subdn')
Damit ist es z.B. möglich, aus Forms-Applikationen über Java (Java Bean bzw. Java-Klasse) oder
PL/SQL auf das Oracle Internet Directory (OID) zuzugreifen, um weitere Informationen zu einem
Benutzer abzufragen. Unternehmen können auf diesem Weg ihre Anwenderverwaltung auf Basis des
OID konsolidieren und diese Informationen innerhalb der Forms-Applikation u.a. zur Autorisierung
verwenden.
Weitere Informationen, u.a. zur Konfiguration des Single Sign-On können in dem White Paper „Oracle
Application Server 10g (9.0.4) - Forms Single Sign-On“ nachgelesen werden.
Version 1.1
Seite 5
Sicherer Betrieb von Oracle Forms-Applikationen
1.3.1 Verwendung alternativer LDAP-Verzeichnisse
Für die Nutzung des SSO-Service in Forms-Anwendungen ist das OID in Verbindung mit dem Oracle
Single Sign-On-Server zwingend erforderlich. Werden im Unternehmen andere LDAPVerzeichnisdienste eingesetzt, können die User Credentials über das DIP (Directory Integration
Platform) mit dem OID synchronisiert werden. Der Oracle SSO-Server kann ebenfalls mit einem
anderen SSO-Service integriert werden.
Damit ist auch eine Nutzung von Windows Native Authentication möglich. Das Microsoft Active
Directory wird über die Directory Integration Platform (DIP) mit dem Oracle OID synchronisiert.
Über ein Kerberos-Token kann eine einmalige Authentifizierung beim Windows-Betriebssystem
erreicht werden.
Version 1.1
Seite 6
Sicherer Betrieb von Oracle Forms-Applikationen
1.3.2 Verwendung des Oracle Virtual Directory
Das Oracle Virtual Directory (OVD) ist ein virtueller Verzeichnisdienst, der eine Konsolidierung
verschiedener Verzeichnisse erlaubt. Dabei kann es sich um LDAP-Verzeichnisse (z.B. OID), aber
auch um Benutzerinformationen in einer Datenbank handeln.
Gegenüber Metadaten-Directories müssen die bestehenden Verzeichnisse physisch nicht
zusammengefasst werden. Die Integration wird über eine zusätzliche Schicht ermöglicht, die eine
einheitliche Sicht auf fragmentierte Identitätsdaten in verschiedenen Systemen bietet. Dies hat den
Vorteil, dass in einem heterogenen Umfeld bestehende Verzeichnisse weiterhin genutzt werden können
und gleichzeitig eine ganzheitliche Sicht auf die Verzeichnisdaten möglich ist.
Weitere Informationen zum Oracle Virtual Directory können im OTN nachgelesen werden.
1.4 Ausblick
Eine direkte Benutzung des Oracle Access Managers aus der Oracle Identity Management Suite ist
derzeit nicht möglich. Der Access Manager kann jedoch als führendes System in Kombination mit dem
SSO-Server genutzt werden.
Alternativ kann der gegenwärtige Prozess der Authentifizierung des Forms Servlets durch einen zu
entwickelnden Servlet-Filter modifiziert werden, der Header-Variablen im HTTP-Response des Access
Manager Webgate akzeptiert.
Version 1.1
Seite 7
Sicherer Betrieb von Oracle Forms-Applikationen
1.5 Strong Authentication
Eine Authentifizierung mit Smartcard und/oder biometrischen Merkmalen ist für Oracle Forms
transparent.
In der Praxis existieren zwei Architektur-Modelle:
- CryptoAPI für die Windows-Welt
- Java Cryptographic Architecture für die Java-Welt.
Beide Welten können miteinander integriert werden.
2 Datenbank-Sicherheit
2.1 Traditionelle Authentifizierung
Die Authentifizierung gegenüber der Datenbank erfolgt bei der traditonellen Anmeldung automatisch
mit dem Login gegenüber der Forms-Anwendung (1.1).
2.2 Autorisierung
Die Autorisierung erfolgt datenbank-seitig auf Basis der Datenbank-Privilegien und Rollen des
angemeldeten DB-Users.
2.3 Authentifizierung (Single Sign-On)
Da beim Single Sign-On (SSO) sich der Benutzer nur gegenüber der Anwendung als SSO-User
authentifiziert wird für die Datenbank eine zusätzliche Anmeldung als DB-User benötigt.
Dies geschieht für Forms und Reports durch die Benutzung der Resource Access Descriptoren (RAD) im
OID. RADs sind spezielle Objekte im OID, die nur in Verbindung mit Oracle Forms und Reports zum
Einsatz kommen. Ein Resource Acces Descriptor (RAD) besteht aus dem Namen und Passwort eines
Datenbank-Benutzers sowie der Connect-Information zur Datenbank-Instanz.
Forms-Applikationen können im Web durch eine benannte Sektion innerhalb der formsweb.cfg
konfiguriert werden. Der Aufruf einer Forms-Applikation erfolgt dann über den Parameter config in der
URL, der die benannte Sektion referenziert (http://host:port/forms/frmservlet?config=test).
Die Verbindung zwischen RAD und der Forms-Applikation erfolgt über die Identität des Names, d.h.
der Name der Forms-Applikation (formsweb.cfg: config=<application>) muss mit dem Resource Name
Version 1.1
Seite 8
Sicherer Betrieb von Oracle Forms-Applikationen
übereinstimmen. Das Forms Servlet liest den passenden RAD-Eintrag aus dem OID und verbindet
sich mit der Datenbank.
Existiert kein gleichnamiger RAD-Eintrag, besteht die Möglichkeit des Erzeugens einer Ressource beim
ersten Connect durch den Anwender selbst (ssoDynamicResourceCreate=True).
Verwenden alle Benutzer den gleichen Connect zur Datenbank, kann in einer speziellen Sektion ein
Default RAD angelegt werden (Note 262686.1). Diese Verbindung steht allen Benutzern der
entsprechenden Forms-Anwendung zur Verfügung.
Für ein künftiges Release von Oracle Forms sind RAD Groups geplant.
Man kann RAD-Einträge programmatisch erzeugen. Beschreibungen dazu finden sich in
Note 334343.1
How To Create Resource Access Descriptor (RAD) For A Group?
And How to Create A RAD Programmatically?
Note 244526.1
How To Create and Copy SSO User Resources (RADs)
Im OTN findet man ein Beispiel, wie man mit dem DB Package DBMS_LDAP mittels PL/SQL RADEinträge erzeugen kann. Das Beispiel basiert auf Forms 9i, sollte aber auch auf die aktuelle Version 10g
anwendbar sein.
Ab Forms 10.1.2 erfolgt ein automatisches Update der RAD, wenn das DB-Passwort über die FormsAnwendung geändert wird.
2.4 Ausblick
Für Oracle Forms 11g ist die Unterstützung von Database Proxy Usern und Enterprise User Security
(EUS) geplant.
DB Proxy User werden in der Datenbank mit folgendem Befehl angelegt
ALTER USER mary
GRANT CONNECT THROUGH midtier
AUTHENTICATED USING ...;
Der Zugriff des Benutzers auf die DB ist nur über den Application Server möglich. Der Benutzer muss
sich dazu gegenüber dem Application Server authentifizieren. Der Application Server hat eine
sogenannte Vertrauensstellung gegenüber der Datenbank. Einer der Vorteile der DB Proxy
Authentication besteht darin, dass sich viele Benutzer denselben DB Account teilen können (Konzept
des Shared Schema), wobei die originale Identität des Benutzers bekannt ist und seine Aktivitäten
protokolliert werden können. Für den DB-Account reicht das Privileg Create Session aus.
Das verwendete Passwort kann sehr kompliziert sein, da es nicht explizit vom Benutzer eingegeben
werden muss.
Version 1.1
Seite 9
Sicherer Betrieb von Oracle Forms-Applikationen
Die Authentifizierung über einen DB Proxy User erfolgt in folgenden Schritten:
- SSO-Anmeldung des Users beim OID über Username/Password des OID Users
- der Forms Service verbindet sich mit der Datenbank als Proxy User mit oder ohne Passwort und gibt
den Benutzernamen des Users aus dem OID mit
- Datenbank akzeptiert den Benutzer und benutzt den OID-Username für Audits
Das Konzept des Database Proxy User kann zweckmäßig mit der Enterprise User Security (EUS)
verbunden werden. Beim Einsatz von EUS werden die Informationen zu Privilegien und Rollen aus der
Datenbank ausgelagert und in einem LDAP-Verzeichnis gespeichert. Neben dem Oracle Internet
Directory (OID) kann auch das Oracle Virtual Directory (OVD) zum Einsatz kommen.
Ein Vorteil der Enterprise User Security besteht darin, dass die Benutzerrechte zentral an einer Stelle
(im LDAP-Verzeichnis) gepflegt werden. Dieses zentrale Verzeichnis kann von mehreren Datenbanken
genutzt werden. Eine aufwändige Mehrfachpflege von Benutzerinformationen in den Datenbanken
entfällt.
Note 272196.1
Step By Step Guide To Configuring 10g Password Authenticated Enterprise User Security
2.5 Forms und Virtual Private Database (VPD)
Die Verwendung der Oracle Virtual private Database (VPD) ist transparent für Forms-Applikationen.
Allerdings gibt es bestimmte Einschränkungen.
So wird z.B. die Zahl der von einer DML-Operation betroffenen Datensätze beim Commit nicht
korrekt wiedergegeben, sofern bestimmte Änderungen durch die VPD Policy zurückgewiesen werden.
3 Verschlüsselung (SSL)
Die Verschlüsselung mittels SSL ist für Oracle Forms transparent
Als Zertifikatsstelle kann entweder eine professionelle Zertifikatsstelle (CA), wie Baltimore oder
Verisign, oder OpenSSL genutzt werden. Neben dem Einsatz von SSL für die Enterprise User Security
kann auch eine Kerberos-Authentifizierung genutzt werden. Nähere Informationen zur Integration von
Kerberos in die Enterprise User Security sind in der Note 458219.1 (How To Configure Enterprise User
Security for Kerberos Authentication) zu finden.
White Paper Oracle Forms Services 10g: Configuring Transport Layer Security with SSL
Note 466662.1
Step by Step Guide To Configure 10g Enterprise User Security (EUS) - SSL Authentication
Note.341904.1
Configuring HTTP Server to use SSL in Oracle Application Server 10g (10.1.2 - 10.1.3)
Note 147836.1
How to make Jinitiator work with Apache with SSL (HTTPS)
Version 1.1
Seite 10