EJB: Transaktionen und Persistenz, Sicherheitsaspekte

Realisierung verteilter Anwendungen: Teil 8

Beim vorigen Mal:

 Multitier-Architekturen: Transaktionen

 Inhalt heute:

 Fortsetzung der Einführung zu Multitier-Architekturen

Transaktionen und Persistenz

 Sicherheitsaspekte

 Lernziele:

 Grundverständnis für die EJB-Architektur, insbesondere Persistenz und Sicherheit

Ralf Möller, FH-Wedel

Rückblick: Transaktionen

 ACID-Bedingungen

 Serialisierbarkeit trotz Nebenläufigkeit

 Notwendig: Verwaltung von Sperren (Locks)

 Notwendig: Zwei-Phasen-Sperr-Protokoll (2PL)

 Verklemmungserkennung und -auflösung

 Timeouts für "Ressourcenblockierer"

 Software-Architektur J2EE

Transaktionen in J2EE

Namensraumverwaltung in J2EE

Nebenläufigkeit und Transaktionen

Der erste Teil dieser Vorlesung (5 Präsentationen)

baut auf der Vorlesung "P3"

von Bernd Neumann

an der Universität Hamburg auf.

Für eine Vertiefung des Themas verteilte

Transaktionen

siehe Kapitel 13 aus:

Verteilte Datenbanksysteme

Die zunehmende Vernetzung von Datenbanken führt zum Konzept der

"verteilten Datenbank".

Eine verteilte Datenbank ist eine Sammlung von Informationseinheiten, die auf mehrere über ein Kommunikationsnetz miteinander verbundene Rechner verteilt sind.

Station S₂

Kommunikations-

Station S₁ netz Station S₄

Station S₃

Transaktionskontrolle in verteilten Datenbanksystemen

Verteilte Datenbankverwaltungssysteme (VDBMS) verwalten Transaktionen, die sich über mehrere Stationen (Rechner) erstrecken.

Beispiel: Umbuchung eines Betrags von Konto A auf Station S_A nach Konto B auf Station S_B

BOT

read (A, a) a := a - 300 write (A, a) read (B, b) b := b + 300 write (B, b) BOT

read (A, a) a := a - 300 write (A, a)

BOT

read (B, b) b := b + 300 write (B, b)

Station S_A Station S_B

Beendigung der globalen

Transaktion erfordert commit oder abort für alle lokalen Stationen

Zweiphasen-Commit-Protokoll

2PC-Protokoll zur EOT-Behandlung in verteilten Datenbanksystemen K Koordinator

A₁ ... A_n Agenten (Stationen des verteilten Datenbanksystems)

1. K sendet PREPARE-Nachricht an alle Agenten, um abzufragen, ob diese ihre Transaktion festschreiben können

2. Jeder Agent A_i antwortet mit einer der zwei Nachrichten:

- READY, falls A_i lokale Transaktion festschreiben kann

- FAILED, falls A_i lokale Transaktion nicht festschreiben kann

3. Wenn K READY von allen Agenten empfangen hat, sendet K COMMIT an alle Agenten und fordert damit zum Festschreiben auf. Falls nicht alle READY innerhalb Timeout-Frist empfangen wurden oder mindestens ein FAILED empfangen wurde, sendet K ABORT an alle Agenten und fordert damit zum Abbruch auf.

4. Agenten quittieren den Erhalt von Nachricht 3 mit ACK

(Acknowledgement, Bestätigung) und führen entsprechende EOT- Behandlung durch.

Nachrichtenaustausch beim 2PC-Protokoll

K Koordinator

A₁ ... A_n Agenten (Stationen des verteilten Datenbanksystems)

K K K

PREPARE FAILED / READY COMMIT / ABORT ACK A₁

A₂

••

•

A_n

A₁

A₂

••

•

A_n

Zustandsübergänge beim 2PC-Protokoll

Start

bereit

abge- brochen

fest- schreibend

fertig

EOT:Sende PREPARE an alle Agenten

READY von allen Agenten empfangen:

• commit ins Log

• sende COMMIT Timeout oder FAILED

empfangen:

• abort ins Log

• sende ABORT

von allen ACK empfangen von allen ACK

empfangen

Koordinator ^wartend

bereit

abge- brochen

festge- schrieben

PREPARE empfangen und lokal alles ok:

• Log ausschreiben

• ready ins LOG

• sende READY

COMMIT empfangen:

• commit ins Log

• sende ACK ABORT

empfangen:

• abort ins Log

• sende ACK Timeout oder

lokaler Fehler entdeckt:

• abort ins Log

• sende FAILED

Agent

Transaktionen in der J2EE-Architektur

 Erleichterung der Anwendungsprogrammierung

 Aufsetzen einer Transaktion: Was ist zu tun?

 Deklaration des Transaktionsanfangs (begin)

 Ausführung von Ressource-Anfragen und -Updates

 Deklaration des Transaktionsendes (commit)

 Transaktionen können durch Bean oder durch Container aufgesetzt werden

 "Aufsetzen" wird auch Demarkation genannt

 J2EE bietet nur sog. "flache Transaktionen"

Nachteile von Bean-Managed-Transactions

 Häufig: Bei "Programmierungenauigkeiten"

wird Commit-Anweisung "versehentlich" nicht ausgeführt (etwa bei Exceptions)

 Locks werden nicht zurückgegeben

 Ressourcen werden blockiert

 Performanz sinkt

Container-Managed Transactions

 Aufsetzen des Transaktionskontextes pro Nachricht an Bean

 Steuerung durch Bean-Kontext (Container)

 Der Ablauf einer ganzen Methode ist als Transaktion (de)markiert

 "Commit" bzw. "abort" folgt automatisch durch Container

Aufsetzen einer Transaktion durch Container

 Anforderung der Bean muß deklariert werden

 Anforderung wird beim Deployment berücksichtigt

 Transaktionskontext wird automatisch pro Methodenaufruf durch

Container aufgesetzt

 "Wie kriegt denn der

Container

einen Methodenaufruf mit?"

Lifecycle-Methoden

 Home-Interface

 create(...), remove(...), ...

 findByPrimaryKey(...), ...

 Bean-Interface

 ejbCreate(...), ejbRemove(...), ...

 ejbFindByPrimaryKey(...), ...

 Aufruf der Home-Interface durch Servlet

 Automatisch erzeugter Code ruft entsprechende Bean- Interface-Methoden auf

 Signatur von entsprechenden Methoden muß gleich sein

Bean-Methoden, vom Container aufgerufen

 ejbPostCreate(...)

 ejbActivate()

 ejbPassivate()

 ejbLoad()

 ejbStore()

 setEntityContext(EntityContext ctx)

 unsetEntityContext()

Bean-Methoden, vom Container aufgerufen

 ejbLoad kann so programmiert werden, daß auf mehrere Datenbasen zugegriffen wird, um die Komponente zu initialisieren

 Transaktionen können sich auf mehrere Datenbasen (Ressourcen) beziehen

 Container muß entsprechende Verwaltung bereitstellen (2PC)

Verteilte Transaktionen

Context Client Transactional

Client

T.

Object

Recoverable Server

R.S.

T.

Object begin,

commit abort

2PC Tr.-

Service

Grundidee der Persistenz bei EJB

 ACID - Eigenschaften von Transaktionen werden

genutzt

 Innerhalb einer

Transaktion kann mit genau einer Kopie

gearbeitet werden

 Diese muß vor einem Commit gespeichert werden

 Eine Kopie je Transaktion

DBMS Beans

Persistenz: Alternativen bei EJB

Bean-managed

 Datenzugriff muß

programmiert werden

 Routinen:

ejbFind, ejbLoad,

ejbStore, ejbRemove, ejbCreate

Container-managed

 Datenzugriff wird vom Container beim

Deployment erzeugt

 Automatisches Mapping nur bei

einfacher Abbildung

 Keine Implementierung der Methoden,

sondern Beschreibung

Container-Managed Persistence am Beispiel

 Einträge im Deployment Descriptor

 Persistente Felder:

price, stock,

description, vendor

 Key-Felder

 Transaktions- management:

Angabe der

Methoden, die als Transaktion

ablaufen sollen

 Angaben

im Deployment- Management- Fenster

Container-Managed Persistence am Beispiel

 ejbCreate(...): "insert into CatTable Values (...)"

 ejbFindLike(keyword):

"select ... where ID = $name";

 ejbLoad(): "select ... where ID = $name";

price = resultset.get(" price ") ...

 ejbStore(): "update ... where ID = $name" ;

 ejbRemove(): "delete ... where ID = $name"

Container-Managed-Persistence: Nachteile

 Kein Standard für OO-zu-Relational-Abbildung

 Finder-Methoden nur informell beschrieben, daher nur semiautomatsiches Deployment

 Keine Standard-Anpassung an bestehende Datenbank-Schemata

 Eager loading: Gesamter Zustand wird geladen

 Kein dirty-flag, eager writing

Security

 Security Attacks

 Encryption

 Higher-level Security Services

 Firewalls

 Authentication

 Access Control

 Non-Repudiation

 Security Auditing

 Security Services in Object-Oriented Middleware

Security Attacks

 More vital/secret data handled by distributed components.

 Security: protecting data stored in and

transferred between distributed components from unauthorised access.

 Security is a non-functional requirement that cannot be added as a component but has to be built into all components.

Why are Distrib. Systems insecure?

 Distributed components rely on messages sent and received from network

 Public networks are insecure!

 Is client component secure?

 Is client component who it claims to be?

 Are users of calling components really who they claim to be?

Effects of Insecurity

 Confidential Data may be stolen, e.g.:

 corporate plans

 new product designs

 medical/financial records (e.g. access bills....)

 Data may be altered, e.g.:

 finances made to seem better than they are

 results of tests, e.g. on drugs, altered

 examination results amended (up or down)

Need for Security

 Loss of confidence: above effects may reduce confidence in systems

 Claims for damages: legal developments may allow someone to sue if data on computer has not been guarded according to best practice

 Loss of privacy: data legally stored on a computer may well be private to the person concerned (e.g.

medical/personnel) record

Threats

 Categorisation of attacks (and goals of attacks) that may be made on a system

 Four main areas:

 leakage: information leaving system

 tampering: unauthorised information altering

 resource stealing: illegal use of resources

 vandalism: disturbing correct system operation

 Used to specify what the system is proof, or secure, against

Methods of Attack

 Eavesdropping: Obtaining message copies without authority

 Masquerading: Using identity of another principle without authority

 Message tampering: Intercepting and altering messages

 Replaying: Storing messages and sending them later

Infiltration

 Launch of attack requires access to the system

 Launched by legitimate users

 Launched after obtaining passwords of known users

 Subtle ways of infiltration:

 Virus

 An unwanted program which places itself into other programs, which are shared among computer systems, and replicates itself

 Worm

 A computer virus capable of disrupting a computer program.

 Trojan horse

 An apparently harmless program containing malicious logic that allows the unauthorized collection, falsification, or destruction of data

Security im J2EE-Kontext

 Verschiedene Techniken zur Herstellung bzw.

Gewährleistung von Sicherheit im Einsatz

 Programmcode von Komponenten (Beans) sollte Anwendungsfunktionalität realisieren aber nicht Sicherheitsaspekte beinhalten

 Sicherheitsaspekte sind nicht-trivial

 Portabilität von Komponenten nur gewährleistet, wenn Sicherheit durch Kontext (Container) unterstützt

Sicherheit und verschiedene EJB-Rollen

 Application Programmer (Bean provider)

 Programming Style, APIs

 Application Assembler (Bean composer)

 Security View, Method Permissions

 Deployer

 Security domain, principal delegation

 Container-Provider

 Tools

 System Administrator

 Accounts (principals)

Diskussion

 Transaktionen im J2EE-Kontext

 Sicherheit im J2EE-Kontext

 Es wurde in dieser Vorlesung ein grober Eindruck der Ziele und wesentlichen Ideen vermittelt

Beim nächsten Mal ...

 ... Encryption, Security Services und

 Bezahlung im Internet