Re: [A2open-diskussion] A2Open

[b1sp <b1...@he...>]

Hallo Liste,

On Tue, 13 Jun 2006 13:55:57 +0200, Gottwalt Thiersch wrote
> [Zugriffskontrolle und Zugriffsbeschraenkungen]

Von der Grundidee her nicht übel. Da kann ich ein paar Gedanken
zu beisteuern:

Wir haben von der Firma her vor kurzem eine vgl. gesicherte Appli-
kation auf ein neues System migriert: Das ganze läuft als Webappli-
kation mit Client-SSL-Zertifikaten, die auf Smart-Cards gespeichert
werden. Die primäre Authentifizierung erfolgt dabei über einen 
Apache Webserver, der primär die verschlüsselte Anbindung und
sekundär die erste Authentifizierung der Client-Zertifikate auf
ihre Gültigkeit und die richtige Zertifizierungsstelle hin bereit-
stellt.
Die eigentliche Applikationslogik und Zuordnung der Rechte erfolgt
bei dem Projekt über einen Java-Applikationserver, der sich die
Rechte des jeweiligen Users aus einem LDAP-Server zieht.
Aktuell erfordert dieses Projekt, daß die User sich selbst ein
Zertifikat erstellen müssen und dieses bei der Zertifizierungs-
stelle des Betreibers zum Signieren einreichen. Anschließend muß
das signierte Zertifikat per Smart-Card-Writer auf die Karte
des Nutzers übertragen werden.

Aus A2open übertragen könnte es so aussehen, daß z.B. die Master-
Zertifikate zentral erstellt und via Kurier übermittelt werden.
Die 'normalen' Client-Zertifikate können dann mittels der Master-
Zertifikate erstellt und beantragt werden. Somit wäre jedes Client-
Zertifikat der jeweiligen Stelle direkt zuzuordnen, die hierzu
auch über einen entpsr. Smart-Card-Writer verfügen müsste.
Der Vorteil der SSL-Zertifikats/LDAP-Architektur würde darin liegen,
daß Zugriffe durch zwei verschiedene Systeme eingeschränkt und bei
Bedarf entspr. unterbunden (Durch widerrufen eines/aller einem
Master-Zertifikat untergeordneten Client-Zertifikate und zusätzlich
durch Änderung der Rechte im LDAP) werden können.

Die von euch beschriebene Zugriffskontrolle dürfte also am sinn-
vollsten über LDAP zu realisieren sein.
Die heiligen Kühe des Projekts wären somit der LDAP-Server, der
Zertifizierungsserver und das zentrale DB-System.
Aus Sicherheitsgründen wird wohl kein Projektverantwortlicher einer
Kommunikationsmatrix zustimmen, die einen direkten Zugriff der
Clients auf den LDAP-Server und davon weitergehend auf den/die
DB-Server vorsieht.
Hier müsste also ein entspr. Frontend her, daß die Validierung der
Zulässigkeit und auch die Protokollierung des Zugriffs der Clients
übernimmt. Dies hätte auch den Vorteil, daß sich kein manipulierter
Client auf Daten zugreifen könnte, die ihn nichts angehen. 

Dies könnte z.B. so aussehen:
1. Client verbindet sich mit dem Frontend 
    -> Prüfung des Zertifikats durch den SSL-Server
2. Das Frontend holt sich anhand der Seriennummer des Zertifikats
die UID um auf die Datenbank zuzugreifen - Anhand der UID könnte
auch die Schreibberechtigung und der Umfang der Leseberechtigung
gewährt werden.

> [Backend]
> Die Verwaltung der Zielvereinbarungen, 1-EUR-Jobs,  
> Vermittlungstaetigkeit etc. erfolgt in separaten Loesungen. Das kann 
>  man zwar Schritt fuer Schritt mit uebernehmen, theoretisch. Aber 
> hier  gehts erstmal nur um den Funktionsumfang von A2LL.

Soweit ACK. Alles andere würde für den Anfang auch mehr als den
Rahmen sprengen... ;-)

> Ich bin der zuversichtlichen Ansicht, dass Guidos Idee, ein  
> Grundprogramm zu erstellen, das seine konkrete Erscheinungsform 
> durch  definierende Konfigurationsfiles erhaelt, voellig richtig 
> ist. Und  diese Files koennen meinetwegen als .xml-Files oder in 
> einem anderen  sinnvollen Format vorliegen. Das muss man nur 
> einmalig festlegen.

Klingt soweit gut und würde SW-Updates auch erleichtern.
Zusätzlich sollte vor dem Zugriff eines Clients zentral eine
Versionsüberprüfung durchgeführt werden, die u.U. (zu alte Version)
den schreibenden/lesenden Zugriff verweigert.

> Das  Programm an sich laeuft und rechnet dann 
> lokal, die Ergebnisse werden  zentral gespeichert und zentral verwaltet.

Klingt vernünftig und dürfte die zentralen Server deutlich ent-
lasten. Der Nachteil an reinen Webapplikationen ist ja, daß dort
auch i.d.R. die gesamte Rechenpower liegen muß. Zur Übertragung
der abgefragten Daten wäre XML wahrscheinlich auch hervorragend
geeignet, da ja alle vorhandenen Parameter definiert sind und 
durch ein SW-Update des Clients/der DB ggf. nachgepflegt werden
können.

Gruß,
Burkhardt