Richtlinien für Zugriffsgruppen (Namen)

[machineslave]

Hallo,

ich habe die "schöne" Aufgabe bekommen, ein Konzept zu erstellen, welches Richtlinien für ACL Gruppen und deren Namen beinhaltet.

Soll heissen: in den ACLs von Anwendungen dürfen keine Benutzer mehr eingetragen werden, sondern nur noch Gruppen.

Die eigentliche Frage nun: Wie stellt man sowas am besten an, vor allem mit der Benennung der Gruppen?

Nimmt man da z.B. ein Sonderzeichen, z.B. "$Anwendung1Gruppe"
Erstellt man für jede Rolle je Anwendung eine Gruppe?

Gruß

Stefan

[mcilly]

Ja, wir verwenden vorab ein Sonderzeichen, damit stehen sie ganz unten. Wir haben je nach Berechtigung eine eigene Gruppe z.B.:

#-Helpdesk-Manager
#-Helpdesk-Reader

Die dann in die ACL reinklatschen. Wenn zukünftig was zu ändern ist, dann einfach in der Gruppe ändern.

[machineslave]

Wie sieht's denn damit aus, wenn ich z.B. folgendes Szenario habe:

Rolle: [Dokumententyp-1], Gruppe: #Anwendung-Dokumententyp-1
Rolle: [Dokumententyp-2], Gruppe: #Anwendung-Dokumententyp-2

Wenn ich in beiden Gruppen stehe, habe ich doch beide Rollen, oder schliessen die sich irgendwie gegenseitig aus?

Gruß

Stefan

[mcilly]

Steht ein Benutzer in mehreren Gruppen und diese Gruppen wiederrum in einer ACL, dann gilt die höhere Berechtigung.

[koehlerbv]

Was die Frage von Stefan angeht: Wer in beiden Gruppen Mitglied ist, hat dann auch beide Rollen - da schliesst sich nichts gegenseitig aus.

Bernhard

[mcilly]

Was die Frage von Stefan angeht...

Ja richtig, da gehts ja um Rollen. Ich war mit den Gedanken beim Zugriff.

[machineslave]

vielen Dank für die Antworten. Das hilft mir auf jeden Fall schonmal einiges weiter.

Gruß

Stefan

[Peter S.]

Das hängt aber sehr vom Workflow für die Zugriffsbeantragung ab, und wieviele DBs mit wievielen Rollen ihr habt.
Bei 100 DBs mit im Schnitt 3 Rollen und 4 gängigen Rechten (Manager, Editor, Autor, Leser) seid ihr im Extremfall bei 1200 Gruppen.
Wir haben viele DBs ( > 2000), und davon viele mit mehr als 6 Rollen. Darum steuern wir nichts über Gruppen.

Unser Workflow ist auf Einzelbeantragung von Usern ausgelegt und man kann dann sehr simpel die beantragten Rechte in die DB übernehmen. Aus diesem Grund haben wir explizite Userrechte in den DBs (ohne Gruppen).

[machineslave]

Wir haben uns gestern nochmal ein paar Beispiele hervorgenommen und sind dann darauf gekommen, dass das über Gruppen nicht wirklich Sinn macht.
Alleine eine Anwendung davon hat 20 Rollen. Und das macht dann nicht wirklich Sinn, da es natürlich einfacher ist, eine Person direkt in eine ACL einzutragen, als in 20 Gruppen (wenn er alle Rollen bekommt)

[Peter S.]

Ich empfehle ein Vorgehen wie wir es gemacht haben.

1. für jede DB wird ein Verantwortlicher benannt (jemand der entscheiden soll ob ein User Zugriff bekommt oder nicht)
2. in der Catalog - Db oder einer ähnlichen Anwendung wird der DB-Verantwortliche hinterlegt. Außerdem kommt da eine Schaltfläche für die User rein um Zugriffe zu beantragen
3. Der Zugriffsnatrag des Users wandert in eine separate DB und der dB-Verantwortliche bekommt eine Mail mit Doclink darauf
4. Der DB-Verantwortliche genehmigt oder lehtn den Antrag ab
5. Ggf bekommt die administration ein Mail mit link auf den genehmigten Antrag und ändert die ACL entsprechend

Wir machen das allerdings nicht über die Catalog-DB sondern einen selbstentwickelte Anwendung.

[Wolfgang]

Wir haben uns gestern nochmal ein paar Beispiele hervorgenommen und sind dann darauf gekommen, dass das über Gruppen nicht wirklich Sinn macht.
Alleine eine Anwendung davon hat 20 Rollen. Und das macht dann nicht wirklich Sinn, da es natürlich einfacher ist, eine Person direkt in eine ACL einzutragen, als in 20 Gruppen (wenn er alle Rollen bekommt)

... Du könntest stattdessen auch eine Gruppe in die ACL eintragen, die alle Rollen bekommt.
Gruppen in der ACL bieten einige Vorteile, z.B. können sie über einen Agenten aus anderen Anwendungen automatisch erstellt und aktualisiert werden.
Viele Gruppen kann man in der gleichen Zusammensetzung u.U. in etlichen Datenbanken verwenden, wenn z.B. der Zugriff von der Zugehörigkeit zu einer Abteilung X abhängt. Einmal die Gruppe korrigiert und schon klappt der Zugriff auf 20 Datenbanken. 
Zugriffe auf Datenbanken können auch von Mitarbeitern verwaltet werden, die selbst gar keinen Zugriff auf die entsprechende DB haben (wenn die Gruppe erstmal in der ACL ist). Es reicht dann das Recht, Gruppen in der names.nsf ändern zu dürfen.
Wenn Du alle betroffenen Mitarbeiter über eine Änderung innerhalb einer Anwendung informieren willst, kannst Du die Gruppe per Mail addressieren statt 150 Leute einzeln rauszusuchen.
Namensänderungen (z.B. Heirat) wirken sich nur in der names.nsf aus und werden von AdminP erledigt. Stehen die Personen einzeln in den ACLs, muß man genau drauf achten, daß der korrekte Administrationsserver eingetragen ist, sonst kann man die Änderungen manuell nachziehen.
Bei häufigen Änderungen von Anwendungen ist vielleicht plötzlich Editorrecht statt Autor erforderlich oder es kommen neue Rollen hinzu. Stehen die Leute einzeln in der ACL, klickst Du 150 mal 'ne neue Rolle dazu statt nur einmal.
Das solltest Du alles mal überdenken und natürlich hängts von der konkreten Umgebung ab, wofür Du dich dann entscheidest. Ich wäre ohne die Verwendung von Gruppen schon längst wahnsinnig geworden ...   

Gruß
Wolfgang

[smoki]

Man sollte immer Gruppen nehmen.

Eine Gruppe kann natürlich mehrere Rolllen gleichzeitig haben.

Zum Beispiel:

Eine Gruppe Mitarbeiter die Rolle "[Mitarbeiter]".
Eine Gruppe Vorgesetzter die Rolle "[Mitarbeiter]" und "[Vorgesetzter]".

Oder komplexer ja nach Konstellation. Es macht auf jedenfall meistens keinen Sinn 20 Gruppen wegen 20 Rollen anzulegen. (Natürlich kann eine komplexe Anwendung 20 Gruppen haben, aber das ist selten... Meist reichen 4 bis 5 Gruppen. Plus eine Admingruppe und Servergruppe, aber das ist ja logisch...)

Gruss
Chris

[Peter S.]

Eine Aussage wie "Man sollte immer Gruppen nehmen" ist mindestens diskussionswürdig.

Unser sehr ausgefeilter Workflow funktioniert mit gruppen NICHT, aber mit Einzelnamen ganz hervorragend.

Also bitte nicht solche merkwürdigen unreflektierten statements abgeben.

[smoki]

Ok, ich nehme es zurück.

In der Regel ist das Verwenden von Gruppen vorzuziehen. Natürlich gibt es Anwendungen, bei denen andere Lösungen besser sind. (Wenn die Anwendung beispielsweise, die ACL selbst Pflegt.)

Klassisches Beispiel: Die Mailschablone, hier mit Gruppen zu handieren, ist in den meisten Fällen nicht zielführend.

Ich hoffe das diese Aussage besser ist?

Gruss
Chris

[koehlerbv]

Eine Aussage wie "Man sollte immer Gruppen nehmen" ist mindestens diskussionswürdig.

Unser sehr ausgefeilter Workflow funktioniert mit gruppen NICHT, aber mit Einzelnamen ganz hervorragend.
....

Zu ersterem: Ich denke, hier ist keinerlei Verallgemeinerung möglich: Gruppen können Sinn- und Unsinn machen, für einzelne Namen gilt gleiches.

Zu zweitem: Sooo ausgefeilt scheint Euer Workflow dann aber nicht zu sein. Mein Workflow-Kernel ist es egal, ob er mit einzelnen Namen, mit Gruppen oder gar mit Rollen der DB gefüttert wird ... Selbst im Anlassfall zu versendende Mails können mit Rollen konfrontiert werden - das wird einfach aufgelöst.

Bernhard