Frontend-Security - Eigene Agenten/Masken/etc = Sicher?

[Simon Dotschuweit]

Hi,

Wenn ich alle eigenen Designelemente der Benutzer verbiete und dann das Sicherheitskonzept komplett auf dem Frontend mit Rollen aufsetzte (Hatte ich so ähnlich geplant wie das hier: http://www.atnotes.de/index.php?topic=20449.0) ist das ganze dann einigermaßen sicher? Dazu kommt noch, dass lokale Repliken möglich sein sollen (Reicht hier dann konsistente ACL erzwingen?) Es sei dazu gesagt dass das ganze für eine Feedbackdatenbank gedacht ist, also keine unternehmenskritische Anwendung

thx

[klaussal]

Evtl. auch noch Leser- bzw. / und Autorenfelder in Betracht ziehen.

[Simon Dotschuweit]

Das Problem ist, dass meine Skripte bei allen Dokumenten Schreibrechte brauchen, auch dann wenn der Benutzer, der sie ausführt, keine Schreibrechte für das Dokument über das Frontend haben darf. Das brauche ich um z.B. Statusfelder zu setzten, deswegen fallen Autorfelder weg

[Mandalor]

in welcher form fängst du die möglihkeit ab, dass der Nutzer die Doks nicht händisch beschreiben darf? mit Maskenformeln? Wenn ja, dann kann einer mit programmierkenntnissen die DB über eine ander anzapfen und ändern.

[Simon Dotschuweit]

kann ich den zugriff von außen unterbinden, so dass keine andere DB meine öffnen kann?

[flaite]

kann ich den zugriff von außen unterbinden, so dass keine andere DB meine öffnen kann?

In einem Notes System ist Authentifizierung/Autorisierung immer an die ID gebunden. Eine "Datenbank" selbst hat eigentlich keine Authenzität. Serverseitige Agenten laufen unter der Authentizität des Unterzeichners des Agenten. Clientseitige Operationen aus der Datenbank unter der ID des Anwenders.

(nicht persönlich nehmen): Ich find du solltest in diesem Thread ein bischen genauer herausarbeiten, was du eigentlich willst. Die Begrifflichkeit ist schon so vage, dass es für potentielle Adressaten deiner Nachricht schwierig ist herauszufinden, was du willst.
Was heisst Sicherheitskonzept auf Frontend mit Rollen?
Was sind "meine Skripte"? Serverseitige Skripte oder vom Anwender getriggerte Skripte?
Müssen diese Skripte auch auf dem Server laufen?

Ich stimme absolut damit überein, dass die Bedeutung von Definitionen z.T. überschätzt werden. Einen gewissen Sinn haben sie aber eben oft doch.

Axel

[Simon Dotschuweit]

(nicht persönlich nehmen): Ich find du solltest in diesem Thread ein bischen genauer herausarbeiten

Ok ist ne gute Idee

Also ich möchte auf dem Frontend(auf z.B. auf der Maske) die Rollen der Nutzer prüfen, z.B. beim OnQueryChangeMode wird überprüft, ob der Nutzer der Ersteller des Dokumentes ist oder ob die Rolle Admin hat, wenn nicht wird abgebrochen. Das Ganze hat den Hintergrund, dass vom Nutzer getriggerte Skripte trotzdem Schreibzugriff auf Dokumente benötigen, die der Nutzer im Frontend nicht bearbeiten darf, mit Autorenfelder wäre das nicht möglich, richtig? Und ja ein Agent in regelmäßigen Abständen auf dem Server läuft braucht auch vollen Zugriff, da er Reponsedokument "umhängen" muss.

Wie gesagt, wenn das Ganze nicht 100% Wasserdicht ist, ist es nicht so kritisch, da es nur eine Feedbackdatenbank ist, wo ich keinen Vorteil sehen würde, der den Aufwand lohnen würde, sie zu hacken, wenn es allerdings irgentwie möglich sein sollte den "Fernzugriff" zu unterbinden, wäre schon nicht schlecht

[Semeaphoros]

Also, den Zugriff ohne Autorenfelder zu unterbinden, ist mühsam, aufwendig und sehr fehleranfällig (bin grad am Durchtesten von Zugriffssteuerungen MIT Autorenfeldern, schon das ist mühsam, wenn man das dann noch selber programmieren will, dann wirds echt abenteuerlich).

"Fernzugriff", was immer Du damit meinst, wenn jemand aus einer anderen DB per Script zugreift, greift er auf die Backend-Dokumente, und da kannst Du schlicht und ergreifend so ohne weiteres nichts unterbinden, ausser mit Autorenfeldern oder mit C-API Erweiterungen.

[flaite]

Also ich möchte auf dem Frontend(auf z.B. auf der Maske) die Rollen der Nutzer prüfen, z.B. beim OnQueryChangeMode wird überprüft, ob der Nutzer der Ersteller des Dokumentes ist oder ob die Rolle Admin hat, wenn nicht wird abgebrochen.

Bedenkenswert (aus meiner Sicht):
-> code muss auch im Postopen sein (wenn user Dokument im Editiermodus öffnet). Oder du verhinderst das öffnen im Editiermodus im Postopen ganz (also wieder zusätzlicher Code). Ob das wirklich so notwendig ist, ist eine gute Frage und hängt von der Anwendung ab. Ich würde Leser/Autorenfelder in aller Regel immer präferieren. 
Ich würde das als sicher genug ansehen. Benötigst aber auf jeden Fall Konsistente ACL, da sonst lokal die Rollen nicht funktionieren.

wo ich keinen Vorteil sehen würde, der den Aufwand lohnen würde, sie zu hacken, wenn es allerdings irgentwie möglich sein sollte den "Fernzugriff" zu unterbinden, wäre schon nicht schlecht

LASS ES
Notes-Datenbanken bekommen eigentlich ihr "Remote-Interface" (um es in J2EE Lingua auszudrücken) von der Plattform, ohne dass man da als Entwickler eingreifen könnte.
Da kann man nicht abfragen, von wo der Call kam. Allenfalls als was dieser Call authentifiziert ist (und das sind keine Anwendungen sondern User- oder Server-IDs). Falls jemand auf deine Datenbank zugreift, ist es nicht dein Problem.
Selbst wenn es möglich wäre, sollte immer gefragt werden, ob sich der Aufwand (inklusive zusätzliche Komplexität in der Anwendung für die Zukunft) lohnt.

mein schlimmstes Security/Datenkonsistenz-Problem der letzten 18 Monate:
Ich hab schon Leute erlebt, die sich stundenlang über notes-security ereifern konnten und dann habe ich in der ihren Anwendungen Stellen gefunden, wo User fröhlich über einen technischen DB2-User Datensätze in einer DB2 Datenbank löschen konnten, ohne dass dies irgendwo auch nur geloggt wurde oder der User benachrichtigt wurde.
Wenn der Progger dann noch so nachlässig war, dass die From-clause einfach wegfiehl, wenn ein bestimmter bug auftrat, so dass Delete From xxxxx gegen die RDBMS gesendet wurde, dann hast du ein *ernsthaftes* Security/Datenkonsistenz-Problem. Vor allem wenn auch noch andere Anwendungen von dieser DB2-Tabelle abhängig sind wie Keith Richard von Heroin in den 70ern.
Zum Glück standen in der Tabelle "nur" ca 15 Tupel mit Konfigurationsdaten.

Ansonsten würde ich strikt die Basics einhalten und die Möglichkeiten von Notes-Security nicht überladen mit kreativen, anstrengenden Ideen, die keinen wirklichen praktischen Mehrwert bieten. Irgendjemand hat mal gesungen "Ich hol dir keine Sterne mehr vom Himmel. Die liegen ja dann doch nur bei uns rum".

Axel

[flaite]

Simon,

wenn auf die Felder eh nur Agenten schreiben drauf zugreifen, dann kannst du die einfach auf sich selbst berechnet machen (d.h. computed und Feldname in Formel).
Ansonsten dürfte das mit Autorenfeldern machbar sein. Bedenke, dass du die Autoren-Felder ja auch dynamisch verändern kannst (am besten mit NotesItem-Klasse).
Nimm einfach immer das einfache. Und Reader/Autoren-Felder ist der einfachere Mechanismus.
Das wichtige ist wirklich, dass die basics sitzen. Egal jetzt ob LotusNotes Programmierung, Java Programmierung, Datenbank Programmierung oder Go spielen.

Axel

[Simon Dotschuweit]

Den Zahn hab ich mir eh schon selbst gezogen, für alles eigene Lösungen entwickeln zu wollen
Glaub mir mit "Einfach" rennst du bei mir offene Türen ein, da ich eh unter irrem Zeitdruck steh und jede
Vereinfachung begrüße.

Nur in diesem Fall geht's einfach ned mit Autorenfeldern, weil nicht nur Agenten auf die Dokumente
zugreifen müssen, sondern auch von den Nutzern ausgeführte Skripte. Und die laufen, wenn ich mich
nicht irre, mit den Berechtigungen des Nutzers, der sie ausgeführt hat. Damit sind Autorfelder auch
schon aus dem Rennen, oder? Aber ich lass mich gerne eines Besseren belehren

[umi]

Ausser wenn die Agenten via Run.onServer gestartet werden mit onbehalfOf, aber das wäre jetzt auch ein Handstand...

gruss
umi

[flaite]

Ich kapiere das immer noch nicht.
In den user-getriggerten Skripten fragst du nach Rollen. Du kannst diese gleichen Rollen aber in  das Autorenfeld setzen. Schliesslich ist das ja auch editierbar.

Bsp: Unter bestimmten Stati des Dokuments dürfen User mit der Rolle Controlling ein Dokument bearbeiten. Diese Bearbeitungs-Constraints können entweder in QueryModeChange stehen oder die Rolle wird im vorherigen Schritt ins Autorenfeld geschrieben. Es ist nicht leicht auszudrücken, aber aus meiner Erfahrung lässt sich alles, was über Rollenabfrage in Skripts geregelt wird, auch über Autorenfelder steuern.

Du glaubst nicht in wievielen Datenbanken ich in den letzten Jahren allgemeinen Editorzugriff auf Autorzugriff geändert habe. In wirklich sehr vielen.   

Ist eine absolute best practice:
Der Standardzugriff für Anwender in einem Notes-System ist Autor.

[Simon Dotschuweit]

Ok ich versuchs nochmal zu erklären 

Die User-getriggerten Skripte brauchen Schreibzugriff AUCH DANN wenn der Nutzer über das Frontend das Dokument nicht bearbeiten darf, mit Autorfeldern, kann ich aber nur entweder Zugriff für Front und Backend freigeben, oder nicht, aber ich kann es nicht mixen oder?

Ich werd mal mein konkretes Problem erläutern:

Ich hab eine Kursdatenbank, wo die Kurse von Teilnehmern bewertet werden können. Jetzt darf natürlich jeder Teilnehmer nur Schreibzugriff auf seine eigene Bewertung haben, damit er nicht einfach die der anderen verändern kann. ABER! jeder Teilnehmer kann jede andere Bewertung gewichten, wie bei Amazon z.B. kann er sagen: war hilfreich/nicht hilfreich, und die Anzahl der Gewichtungen stehen in einem Counterfeld in dem Bewertungsdokument. Die Gewichtung wird natürlich nicht direkt im Dokument über das Frontend verändert sondern über eine Backend Funktion,
aber um den Counter zusetzen brauche ich Schreibzugriff auf das Dokument und da das Skript unter
den Rechten desjenigen läuft, der es ausgeführt hat, braucht der Teilnehmer also Schreibzugriff.

Meines Wissens ist unter diesen Voraussetzungen kein Autorfeld möglich, aber ich lasse mich gerne eines besseren belehren 

[Mandalor]

dann geh über Autorenfelder und schreib die gewichtungen in das dok rein, welches im Frontend offen ist (die auswertungsroutine müsse dann natürlich angepasst werden)

[umi]

Wie wärs mit folgendem Szenario:

Der Benutzer führt einen Agenten auf dem Server aus.
Der Agent auf dem Server hat entsprechende Rechte, das Dokment zu Ändern, via Signierung oder RunOnBehalf of.

D.h. Der Benutzer braucht nicht direkt Schreibzugriff auf das Dokument.

gruss

umi

[Semeaphoros]

Mandalor, das beisst sich in den Schwanz.

Eine Lösung ist das, was Umi beschreibt, eine andere wäre die, dass die Gewichtungen nicht in die Bewertung hineingeschrieben werden, sondern in ein zusätzliches, eigenes Dokument "Gewichtung". So kann das Bewertungsdokument mit einem Autorfeld geschützt werden. Will man die Gewichtung mit anzeigen, wird das über einen DBLookup aus dem Gewichtungsdokument ausgelesen.

[Mandalor]

Wieso?

Wenn die gewichtung in das Doc geschrieben wird, ich welches die Person schreiben kann, ist ersteinmal der Schreibvorgang gesichert. die docs werden mit autorenfeldern gesichert und lesen kann doch jeder jedes Dokument? mann muss dann nur die anderen Documente zum auswertungszeitraum auslesen.

OK --> wenn ich es mir recht überlege wäre es unnötig langsam! Aber gehen müsste es doch!?

Ihr habe aber recht: eure Lösungen sind besser!!!

[Semeaphoros]

Markus, das ist jetzt für mich völlig undurchsichtig, was Du da schreibst.

Schreibrechte sind unabhängig vom Frontend bzw. Backend. Wenn Du nicht Autor im betreffenden Dokument bist, kannst Du weder via UI noch via Backenddokument reinschreiben.

[Mandalor]

Nein, das verstehst du falsch:

Person A darf in doc A1 schreiben, aber auch doc B1 lesen
Person A macht seine Eintragungen in Doc A1
Simon hätte nun gern die Gewichtung in doc B1 eingetragen. Da darf aber Person A nicht hineinschreiben, also wird die Gewichtung auch in doc A1 eingetragen

--> Die Auswertungsroutine muss dann eben im doc A1 und nicht im doc B1 die Gewichtung auslesen.

Ich weiß das der andere Vorschlag von euch besser ist, wollte diesen nur noch mal erklären (Es ist Freitag und sau warm, da fällt die Aussprache schon mal undeutlich aus)