Das Notes Forum
Domino 9 und frühere Versionen => ND6: Entwicklung => Thema gestartet von: Simon Dotschuweit am 13.07.05 - 10:11:12
-
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
-
Evtl. auch noch Leser- bzw. / und Autorenfelder in Betracht ziehen.
-
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
-
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.
-
kann ich den zugriff von außen unterbinden, so dass keine andere DB meine öffnen kann?
-
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
-
(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 ;)
-
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.
-
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
-
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
-
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 :D
-
Ausser wenn die Agenten via Run.onServer gestartet werden mit onbehalfOf, aber das wäre jetzt auch ein Handstand...
gruss
umi
-
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.
-
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 ;)
-
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)
-
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
-
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.
-
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!!!
-
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.
-
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) :-\
-
Ich denke, Markus meint genau das gleiche wie Semeaphoros: Gewichtungen sind eigene, anhängende Dokumente.
Bernhard
-
Das ist so ähnlich, wie ich es vorgeschlagen habe. Wenn mans geschickt anlegt, brauchts keinen Auswertungsagenten.
-
Ich glaub, wenn du von Anfang an die best practice "Autoren-Leserfelder" im Kopf gehabt hättest, wäre das viel einfacher zu designen/coden gewesen.
Das ist übrigens meine Kritik an vielen Objekt Analysten, die ich in Projekten erlebt habe. Ich sag jetzt nicht, dass alle so sind. Die Leute bauen ein Objekt-System zusammen, berücksichtigen dann aber viele Dinge der Plattform sowie Details der Anforderungen nicht mit.
Die OOA Artefakte sehen dann zwar gut aus und lassen sich gut präsentieren. Sie sind aber für die Praxis nicht unbedingt besonders wertvoll.
Auch - was ich in den letzten Jahren zumindest 3 mal gemacht habe - wenn ich ein wirklich größeres Notes-Projekt übergeben bekomme. Die sind teilweise natürlich problematisch (nicht unbedingt Notes-spezifisch) . Aber bis man da dann durchblickt, wo die Probleme sind, was gut ist, was die Anwender eigentlich wollen. Da kann eine Menge Zeit ins Land gehen. Und es hängt oft an Details. Wie man effektiv eingreifen kann. Es war dann oft so, dass ich plötzlich den Durchblick bekommen habe. Für Projektleiter ist das natürlich dann potentiell problematisch, wenn da einer wochenlang analysiert. Aber es ist wirklich keine Selbstpropaganda. Irgendwann kann ich dann oft mehrere "große" Probleme in sehr kurzer Zeit lösen. Und zwar auf kontrollierte Art und Weise.
Aber nimm so best practices ernst. Wir haben sonst keinen festen Boden. Und da hat Erfahrung eben wirklich schon einen Wert. Mag für dich jetzt wie Dogmatik klingen. Aber ich merke z.B. in einem privaten Forschungsprojekt auch gerade, dass ich eine bestimmte Sache viel sinnvoller mit rdbms-storedProcedures lösen kann als mit den dollsten Object SQL Mapping Tools und IOC-Containern. Ex post weiss ich, dass ich das auch hätte ex-ante wissen können. Aber man macht eben Fehler.
-
Ja die Idee mit einem eigenen Gewichtungsdokument ist mir auch schon gekommen, war aber nicht sicher, ob das nicht aufwendiger wäre und ob zusätzliche Dokumente nicht die DBgröße zu sehr beeinflussen, aber ich glaub, ich werd meinem Auftraggeber die ENtscheidung überlassen, er hat dann ja auch das evetuelle Sicherheitsrisiko zu tragen ;)
-
Über die DB-Grösse und Performance würde ich mir jetzt weniger Gedanken machen. Diese "Gewichtungs-Dokumente" sind sehr klein und beeinflussen (wenn Du nicht gigantische Datenmengen verwalten willst) die Datenbank an sich kaum. Die dadurch erforderlich Ansicht würde sich da schon eher auswirken, aber auch hier gilt: Wenn Du keine gigantischen Datenmengen hast ...
Du darfst auch nicht vergessen, dass permanent geänderte Dokumente (bei Verzicht auf die "Gewichtungs-Dokumente") viel eher zu white spaces beitragen können und somit evtl. eher die Performance beeinträchtigen können.
... aber ich glaub, ich werd meinem Auftraggeber die ENtscheidung überlassen, er hat dann ja auch das evetuelle Sicherheitsrisiko zu tragen ;)
Ich befürchte, hier bist Du auf dem Holzweg. Ein Dir bekanntes oder Dir bekannt sein könnendes Sicherheitsrisiko müsste er Dir schon schriftlich abnehmen. Wenn Du einen Auftraggeber hast (egal, ob intern oder extern), dann gehst Du Verpflichtungen ein, denen man sich nicht so leicht entledigen kann.
Bernhard
-
Die nächtliche Standardantwort.
Du spekulierst auch über Performance.
Das soll man nicht machen.
Ohne Last Tests (was in Notes ein bischen schwierig ist), kannst du da oft keine Aussagen treffen. Ausser du hast wirklich Erfahrung.
In dem genannten Fall dürfte die Performance nicht spürbar schlechter werden.
Dieses Gewichtungsdokument ist ja nur 1 Dokument was geladen werden muß.
Problematisch sind remote calls. (agent.runOnServer, auf andere DB zugreifen oder wenn sich Dinge aufadieren (viele Lookups)).
Es gibt da eigentlich keine festen einfachen Regeln ausser ausprobieren.
-
Das mit den Gewichtungsdokumenten geht auch aus meiner Sicht wesentlich einfacher, wenn du in die Gewichtungsdokumente die ID des Dokuments, auf das es sich bezieht speicherst und dann schreibst du alle 30 Minuten Gewichtungsinfos in das übergeordnete Dokument.
Der einzige Nachteil ist ein leichter Zeitverzug. Darüber kann man aber den Ersteller des Gewichtungsdokuments informieren.
Mit runOnServer hab ich aus Performance-Gesichtspunkten schlechte Erfahrung gemacht.
Axel
-
Das Problem des RunOnServer ist, dass hierbei eine Anforderung an die AgentManager-Task des Domino-Servers abgesetzt wird. Und der Amgr nimmt generell auf die aktuelle Gesamtperformance des Servers Rücksicht als auch auf die eigene Belastung. Der angeforderte Agent wird also so gut wie nie sofort laufen. Da RunOnServer zusätzlich eine Rückmeldung an den Client gibt, spürt der Anwender dieses Verhalten auch sehr deutlich.
Die Gewichtungsdokumente sollten als Antwortdokumente zu den eigentlichen Bewertungsdokumenten gestaltet werden. So ist ein sehr schneller Zugriff vom Parent auf die Children möglich. Die Frage ist, ob man die Informationen der Children überhaupt in das ParentDoc schreiben muss - wenn man diese Informationen nicht in Ansichten benötigt, kann man sich das sparen und die Gewichtungsdokumente jeweils beim Öffnen des Hauptdokumentes auswerten.
Bernhard