diff --git a/de/functions/backend/FOM/acl.rst b/de/functions/backend/FOM/acl.rst index affeb9f30..5f07036b6 100644 --- a/de/functions/backend/FOM/acl.rst +++ b/de/functions/backend/FOM/acl.rst @@ -4,47 +4,15 @@ Access Control Lists (ACL) ========================== -Die Absicherung von Domain-Objekten (generell Datenbank Entities) wird über -Access Control Lists (ACL) implementiert. ACLs ermöglichen eine flexible -Genehmigung für individuelle Objekte. +Die Absicherung von Domain-Objekten wird in Mapbender über Access Control Lists (ACLs) implementiert. ACLs ermöglichen in Mapbender eine flexible Rechtezuweisung auf Applikationen, Dienste und die Benutzer- und Gruppenverwaltung selbst. -Für jede Domain-Objektklasse können bis zu 30 verschiedene Rechte -gewährleistet werden. Generell reichen die folgenden 7 aus: +Mapbender bietet zur Absicherung dieser Bereiche die folgenden Rechte- und Rollenzuweisungen an: -- View : Objekt lesen +- View : Ein existierendes Objekt lesen - Create : Ein neues Objekt erstellen - Edit : Ein existierendes Objekt bearbeiten - Delete : Ein existierendes Objekt löschen -- Operator : Die Rechte zu Lesen, Erstellen, Editieren und zu Löschen -- Master : Die Operator Rechte, kann alle Rechte bis zum Operator Level verwalten -- Owner : Master Rechte. Kann Master Rechte selbst verwalten +- Operator : Rollenbezeichnung für die Rolle "Operator", dieser hat die Rechte View, Edit und Delete. +- Master : Rollenbezeichnung für die Rolle "Master", dieser hat Operator-Rechte und kann zusätzlich alle oberen Rechte anderen zuweisen. +- Owner : Rollenbezeichnung für die Rolle "Owner", dieser kann sowohl Operator als auch Master-Rechte zuweisen. -Jedes ACL baut sich aus einer Objekt Identity und bestimmten Access Control Entries (ACE) auf. - - -Objekt Identität ----------------- - -ACLs werden nicht direkt den Objekten zugeordnet sondern den sogenannten -Objekt Identities. Diese repräsentieren individuelle Objekte oder Klassen -(das Create Recht ist zum Beispiel ein Recht auf eine Klasse). - - -Access Control Entries ----------------------- - -Jedes ACE enthält die Rechte für einen Benutzer oder eine Rolle. Die Rechte -werden als Interger Bit abgelegt, daher können 32 Rechte verwaltet -werden. Da einige PHP Implementationen 30 bit große Integers verwalten, hat -sich die Zahl 30 als plattformübergreifender Höchstwert etabliert. Wie schon -erwähnt reichen 7 Rechte aus, um einen umfangreichen CRUD Workflow zu -modellieren und die restlichen 23 für Eigenentwicklungen vorzuhalten. - - -Security Identität ------------------- - -ACEs können entweder mit Benutzern oder Rollen assoziiert werden, um damit -beide mit einer Security Identität zu kapseln. - -.. image:: ../../../../en/functions/backend/FOM/acl.png diff --git a/de/functions/backend/FOM/edit_user_activated.png b/de/functions/backend/FOM/edit_user_activated.png new file mode 100644 index 000000000..2c0a7d818 Binary files /dev/null and b/de/functions/backend/FOM/edit_user_activated.png differ diff --git a/de/functions/backend/FOM/element_security_key_popup.png b/de/functions/backend/FOM/element_security_key_popup.png new file mode 100644 index 000000000..7741ad074 Binary files /dev/null and b/de/functions/backend/FOM/element_security_key_popup.png differ diff --git a/de/functions/backend/FOM/examples.rst b/de/functions/backend/FOM/examples.rst index 78af3eb19..cb09e1b3a 100644 --- a/de/functions/backend/FOM/examples.rst +++ b/de/functions/backend/FOM/examples.rst @@ -10,7 +10,7 @@ Der Befehl ``app/console fom:user:resetroot`` setzt den User mit der ID 1 zurüc .. code-block:: bash $ app/console fom:user:resetroot - Welcome to the Mapbender3 root account management command + Welcome to the Mapbender root account management command Enter the username to use for the root account. Username [root]: root Enter the e-mail adress to use for the root account. @@ -21,7 +21,7 @@ Der Befehl ``app/console fom:user:resetroot`` setzt den User mit der ID 1 zurüc The root is now usable. Have fun! -Neuen Benutzer anlegen +Neue Benutzer anlegen ---------------------- Der root Benutzer (ID 1) kann neue Benutzer anlegen. Dies ist auch für andere Benutzer möglich, wenn sie im ACL "Users" als Owner eingetragen sind. Diese Ausnahmeberechtigung wurde gewählt, damit nicht jeder Nutzer seinen Benutzernamen ändern kann. @@ -30,20 +30,24 @@ Der root Benutzer (ID 1) kann neue Benutzer anlegen. Dies ist auch für andere B Neue Anwendungen anlegen ------------------------ -Ein Benutzer, der neue Anwendungen erzeugen soll, muss im ACL "Applications" das Create Recht besitzen. Sobald er dieses Recht hat, kann er auch Anwendungen exportieren und importieren. +Ein Benutzer, der neue Anwendungen erzeugen soll, muss im ACL "Anwendungen" das *Create* Recht besitzen. Sobald er dieses Recht hat, kann er auch Anwendungen exportieren und importieren. -Um Layerset Instanzen einzubauen, muss er im ACL "Service Source" das Edit Recht besitzen. + +Datenquellen konfigurieren +-------------------------- + +Um den Aufruf auf den Tab ``Datenquellen`` zu erhalten und anschließend Dienste einbinden, konfigurieren oder aktualisieren zu können, muss ein Benutzer/eine Gruppe im ACL "Datenquellen" mindestens das *Edit* Recht zugewiesen bekommen. Anwendungen kopieren -------------------- -Ein Benutzer kann Anwendungen kopieren, wenn er im ACL "Applications" oder in der Anwendung mindestens das Edit Recht hat. Dabei überschreibt das Recht der Anwendung das globale ACL Recht. +Ein Benutzer kann Anwendungen kopieren, wenn er im ACL ``Applications`` oder in der Anwendung selbst mindestens das *Edit* Recht hat. Dabei überschreibt das individuelle Recht der Anwendung das globale ACL Recht. -Dabei wird der Benutzer automatisch Owner seiner kopierten Anwendung. +Wenn ein Benutzer eine Anwendung kopiert, dann wird er automatisch ihr Owner. Anwendungen löschen ------------------- -Ein Benutzer kann Anwendungen löschen, wenn er im ACL "Applications" oder er in der Anwendung mindestens das Delete Recht hat. Dabei überschreibt das Recht der Anwendung das globale ACL Recht. +Ein Benutzer kann Anwendungen löschen, wenn er im ACL ``Anwendungen`` oder er in der Anwendung selbst mindestens das *Delete* Recht hat. Dabei überschreibt das individuelle Recht der Anwendung das globale ACL Recht. diff --git a/de/functions/backend/FOM/index.rst b/de/functions/backend/FOM/index.rst index 61c2dd825..6dfd0e46a 100644 --- a/de/functions/backend/FOM/index.rst +++ b/de/functions/backend/FOM/index.rst @@ -1,14 +1,13 @@ .. _fom_de: -FOMUserBundle - Benutzer und Absicherung -======================================== +FOM UserBundle - Benutzer und Absicherung +========================================= .. toctree:: :maxdepth: 1 + security acl users roles_groups - security examples - diff --git a/de/functions/backend/FOM/roles_groups.rst b/de/functions/backend/FOM/roles_groups.rst index 46ae4c839..4a69f27b4 100644 --- a/de/functions/backend/FOM/roles_groups.rst +++ b/de/functions/backend/FOM/roles_groups.rst @@ -3,29 +3,11 @@ Rollen und Gruppen ================== -Rollen sind definiert über Instanzen von -FOM\\ManagerBundle\\Component\\Bundle und nutzen die getRoles Methode. +Rollen werden in Mapbender für globale Zugriffe auf Domänen-Objekte verwendet, wenn kein anderes Domänen-Objekt involviert ist. -Die Benennung der Rollen folgt dem Standard Symfony Role Naming Schema, in -dem Rollen mit dem Präfix "ROLE\_" benannt werden. +Die folgenden Rollen sind für eine übergreifende Rechtevergabe auf bestimmte Domänen-Objekte verfügbar: -Rollen können für globale Rechteüberprüfungen benutzt werden, wenn kein -Domänen-Objekt involviert ist und können als Sicherheits-Identitäten von ACE -in ACL genutzt werden. +* Alle angemeldeten Benutzer: Rechtevergabe betrifft alle Benutzer mit einem Account und keinen individuellen Rechtezuschreibungen. +* Anonyme Nutzer: Rechtevergabe betrifft alle unangemeldeten Besucher von Mapbender-URLs. -Gruppen sind Datenbank-Entitäten, die zu Benutzern auf einer individuellen -Basis zugewiesen werden können. Sie können auch mehreren Rollen zugewiesen -werden. Daher liegt ihr Nutzen in der Sammlung von Rollen, die jedem Nutzer -einer Gruppe zugeordnet werden sollen. - -.. image:: users.png - - - -Zukunft -------- - -Später ist es möglich, individuelle Rollen direkt einem Nutzer zuzuordnen. - -Symfony bietet zusätzlich eine API für hierarchische Rollen an, die bisher -noch nicht Teil des FOMUserBundles ist. +Gruppen sind im Gegensatz dazu selbst erstellte Datenbank-Entitäten. Benutzer können ihnen individuell zugewiesen werden. Gemeinsame Gruppenmitglieder besitzen die gleichen Rechte, sofern diese auf Domänen-Objekten zentral für die Gruppe konfiguriert wurden. diff --git a/de/functions/backend/FOM/security.rst b/de/functions/backend/FOM/security.rst index e9d422080..283a1f15b 100644 --- a/de/functions/backend/FOM/security.rst +++ b/de/functions/backend/FOM/security.rst @@ -3,9 +3,70 @@ Sicherheitskonzepte =================== -Sicherheit wird im FOMUserBundle bereitgestellt und basiert auf diesen -Konzepten: +Sicherheit wird im FOM User Bundle bereitgestellt und basiert auf diesen Konzepten: - :doc:`Benutzer ` - :doc:`Rollen und Gruppen ` - :doc:`Access Control Lists (ACL) ` + + +Rechte +======== + +Mapbender bietet verschiedene Rechte an, die Sie vergeben können. Sie basieren auf :doc:`Access Control Lists (ACL) `. + +* view - anzeigen +* edit - editieren +* delete - löschen +* operator - kann anzeigen, editieren und löschen +* master - kann anzeigen, editieren, löschen und diese Rechte außerdem weitergeben +* owner - Besitzer, darf alles (inkl. Vergabe von master und owner Recht) + +Weisen Sie einem Benutzer über ``Benutzer --> Benutzer bearbeiten --> Sicherheit`` die gewünschten Rechte zu. + + .. image:: /figures/mapbender_roles.png + :scale: 80 + + +Zuweisen einer Anwendung zu einem Benutzer/einer Gruppe +======================================================= + +#. Bearbeiten Sie Ihre Anwendung über ``Anwendungen --> Bearbeiten``. + +#. Wählen Sie ``Sicherheit``. + +#. Veröffentlichen oder verbergen Sie Ihre Anwendung für alle über die Auswahl **Öffentlicher Zugriff** unter ``Sicherheit`` (oder alternativ über den **Anwendung publizieren/verbergen**-Button in der Anwendungsübersicht). + +#. Fügen Sie für individuelle Einstellungen alternativ Benutzer oder Gruppen über den Plus-Button hinzu. Setzen Sie anschließend individuelle Berechtigungen über die Rechtetabelle. So weisen Sie eine Anwendung einem oder mehreren Benutzer(n)/Gruppe(n) zu. + +#. Melden Sie sich erneut unter der ausgewählten Benutzerbezeichnung an, um die Rechtevergabe zu testen. + +#. Alternativ können Sie auch unter ``Sicherheit --> Globale Zugriffssteuerungsliste (ACL) --> Anwendungen`` schnell Berechtigungen von Benutzern/Gruppen für alle Anwendungen festlegen. + + +Zuweisen einzelner Elemente zu Benutzern/Gruppen +================================================ + +Standardmäßig stehen alle Elemente den Benutzern/Gruppen zur Verfügung, die Zugriff auf eine Anwendung haben. Für einzelne Elemente kann der Zugriff noch genauer definiert werden, so dass diese nur bestimmten Benutzern/Gruppen zur Verfügung stehen. + +#. Bearbeiten Sie Ihre Anwendung über ``Anwendungen --> Bearbeiten``. + +#. Wählen Sie ``Layouts``. + +#. Jedes Element verfügt über einen eigenen ``AcL-Element``-Button (Schlüssel). Wählen Sie den Button zu dem Element, das nur ausgewählten Benutzern/Gruppen zur Verfügung stehen soll. + +#. Fügen Sie Benutzer oder Gruppen über den Plus-Button hinzu. Setzen Sie anschließend individuelle Berechtigungen über die Rechtetabelle. Das Element wird so innerhalb der Anwendung abgesichert und nur bestimmten Benutzer(n)/Gruppe(n) zugänglich. + +#. Testen Sie die Konfiguration, indem Sie die Anwendung mit Benutzern aufrufen, die (keine) Berechtigungen zum Element erhalten haben. + + +Zuweisen von Benutzern zu einem Benutzer/einer Gruppe +===================================================== + +#. Bearbeiten Sie Ihre Benutzer über ``Sicherheit --> Benutzer``. + +#. Wählen Sie ``Sicherheit``. + +#. Weisen Sie Benutzern/Gruppen individuelle Berechtigungen auf den individuellen Benutzer zu. Fügen Sie Benutzer oder Gruppen über den Plus-Button hinzu. Setzen Sie anschließend individuelle Berechtigungen über die Rechtetabelle. So weisen Sie Benutzer(n)/Gruppe(n) einen Benutzer zu. + +#. Melden Sie sich unter dem Benutzer bzw. der Gruppe mit neuen Rechten an, um die Rechtevergabe zu testen. Je nach Konfiguration ist es so z.B. möglich, dass alle Teilnehmer einer Gruppe Berechtigungen über einen bestimmten Benutzer haben und dessen Account bearbeiten oder löschen können. diff --git a/de/functions/backend/FOM/user_account_selfregister.png b/de/functions/backend/FOM/user_account_selfregister.png new file mode 100644 index 000000000..2f1549d5c Binary files /dev/null and b/de/functions/backend/FOM/user_account_selfregister.png differ diff --git a/de/functions/backend/FOM/user_forgot_password.png b/de/functions/backend/FOM/user_forgot_password.png new file mode 100644 index 000000000..b6186edeb Binary files /dev/null and b/de/functions/backend/FOM/user_forgot_password.png differ diff --git a/de/functions/backend/FOM/users.png b/de/functions/backend/FOM/users.png deleted file mode 100644 index 0c49b7b70..000000000 Binary files a/de/functions/backend/FOM/users.png and /dev/null differ diff --git a/de/functions/backend/FOM/users.rst b/de/functions/backend/FOM/users.rst index c58a45137..b5aa5caa0 100644 --- a/de/functions/backend/FOM/users.rst +++ b/de/functions/backend/FOM/users.rst @@ -3,36 +3,25 @@ Benutzer ======== -Benutzer werden als FOM\\UserBundle\\Entity\\User implementiert und im -Datenbank Repository gespeichert. Die Entität hält nur die notwendigen -Informationen über einen Nutzer vor, komplexere Benutzerdaten sollten in -Benutzerprofilen hinterlegt werden (TBD). +Benutzer werden als FOM\\UserBundle\\Entity\\User implementiert und im Datenbank Repository gespeichert. Die Entität hält nur die notwendigen Informationen über einen Nutzer vor. -Das Bundle enthält alle Mittel, um Benutzer durch einen Administrator zu -verwalten als auch das eigene Registrieren eines Nutzers sowie das -Zurücksetzen des eigenen Passwortes. +Das Bundle enthält Möglichkeiten für folgende Optionen: -Der Benutzer mit der ID 1 ist besonders, da dieser Benutzer bei der -Installation erstellt wird und immer alle Rechte hat. Falls alle Stricke -reißen, können Sie mit diesem Benutzer alles verwalten. Und falls Sie gar -die Anmeldedaten vergessen haben sollten, können Sie über ein app/console -Kommando den Benutzer zurücksetzen: fom:user:resetroot. +* Benutzerverwaltung durch einen Administrator +* Registierung eines Benutzers +* Zurücksetzung des eigenen Passworts + +Der Benutzer mit der ID 1 (root) ist besonders, da dieser Benutzer bei der Installation erstellt wird und immer alle Rechte hat. Falls alle Stricke reißen, können Sie mit diesem Benutzer alles verwalten. Und falls Sie gar die Anmeldedaten vergessen haben sollten, können Sie über ein app/console Kommando den Benutzer zurücksetzen: *fom:user:resetroot*. -.. note:: **Hinweis:** Um die Funktionen unterhalb nutzen zu können, muss der Symfony Swiftmailer korrekt eingerichtet sein. Bitte überprüfen Sie Ihre lokale Symfony-Version und nutzen Sie die offizielle Symfony-Dokumentation zur Einrichtung des Tools: https://symfony.com/doc/current/mailer.html Passwort vergessen ------------------ -Falls ein Benutzer sein Passwort vergessen hat, kann er in der Login-Maske -über den Link "Passwort vergessen" ein neues Passwort anfordern. Dazu gibt -er dann seinen Benutzernamen oder seine E-Mail Adresse an. +Falls ein Benutzer sein Passwort vergessen hat, kann er in der Login-Maske über den Link "Passwort vergessen" ein neues Passwort anfordern. Dazu gibt er dann seinen Benutzernamen oder seine E-Mail Adresse an. -.. image:: ../../../../en/functions/backend/FOM/user_forgot_password.png +.. image:: ../../../../de/functions/backend/FOM/user_forgot_password.png -Danach bekommt der Benutzer eine E-Mail mit einem Link, die zu der Seite -führt, um das Passwort zurückzusetzen. Der Link ist danach nicht mehr -gültig. Der Text der Mail kann in der Datei -/FOM/UserBundle/Resources/translations/messages.de.xlf angepasst werden. +Danach bekommt der Benutzer eine E-Mail mit einem Link zur Zurücksetzung des Passworts. Der Link ist nach der Nutzung nicht mehr gültig. Der Text der Mail kann in der Datei /FOM/UserBundle/Resources/translations/messages.de.xlf angepasst werden. Die Funktionalität kann in der config.yml ausgeschaltet werden. @@ -42,76 +31,55 @@ Die Funktionalität kann in der config.yml ausgeschaltet werden. reset_password: true # true/false - Registrierung ------------- -Benutzer können sich an Mapbender selbst registrieren. Dafür stellt man in -der config.yml die Einstellung fom_user:selfregister auf true. +Benutzer können sich in Mapbender selbst registrieren. Dafür stellt man in der config.yml die Einstellung *fom_user:selfregister* auf true. .. code-block:: yaml fom_user: selfregister: false # true/false -Im Login-Dialog erscheint der "Register" Link. Der Benutzer wird zu einer -Maske geführt, in der er seinen Namen, sein Passwort und seine E-Mail -Adresse angeben kann. +Im Login-Dialog erscheint der "Register" Link. Der Benutzer wird zu einer Maske geführt, in der er Name, Passwort und E-Mail Adresse angeben kann. -.. image:: ../../../../en/functions/backend/FOM/user_self_register.png +.. image:: ../../../../de/functions/backend/FOM/user_self_register.png -Danach erhält er eine Bestätigungsmail, mit der er seine Anmeldung -abschließen kann. Bis zu diesem Zeitpunkt ist er als inaktiver Nutzer in -Mapbender hinterlegt. +Danach erhält er eine Bestätigungsmail, mit der er seine Anmeldung abschließen kann. Bis zu diesem Zeitpunkt ist er als inaktiver Nutzer in Mapbender hinterlegt. -Die Texte der Bestätigungsmail können unter -/FOM/UserBundle/Resources/translations/messages.de.xlf angepasst werden. +Die Texte der Bestätigungsmail können unter /FOM/UserBundle/Resources/translations/messages.de.xlf angepasst werden. Aktivieren von Nutzern ---------------------- -Seit Mapbender 3.0.5.3. können Benutzer von Administratoren mit mindestens -der Benutzer ACL-Rolle "edit" aktiviert oder deaktiviert werden. Dazu dient -der Schalter im Edit User Dialog. - -Ein Benutzer mit Administrationsrechten kann sich selbst nicht aktivieren -oder deaktivieren. - -.. image:: ../../../../en/functions/backend/FOM/edit_user_activated.png +Benutzer können von Administratoren mit der ACL-Rolle *edit* aktiviert oder deaktiviert werden. Ein Benutzer mit Administrationsrechten kann sich selbst nicht aktivieren oder deaktivieren. -Ein Benutzer, der deaktiviert ist, kann sich so lange nicht mehr im Mapbender -anmelden, bis er wieder aktiviert wird. +.. image:: ../../../../de/functions/backend/FOM/edit_user_activated.png -.. image:: ../../../../en/functions/backend/FOM/user_account_is_disabled.png +Ein Benutzer, der deaktiviert ist, kann sich so lange nicht mehr im Mapbender anmelden, bis er wieder aktiviert wird. -Benutzer, die sich selbst registriert haben, aber die Freischaltungsmail -noch nicht bestätigt haben, können so von einem Administrator per Hand -freigeschaltet werden. +Benutzer, die sich selbst registriert haben, aber die Freischaltungsmail noch nicht bestätigt haben, können so von einem Administrator per Hand freigeschaltet werden. -Usermanagement über Sicherheitsschlüsselabfrage +User-Management per Sicherheitsschlüsselabfrage ----------------------------------------------- -Innerhalb jeder Mapbender-Applikation besteht zusätzlich die Möglichkeit der Rechtevergabeanpassung. Im Tab "Layouts" findet sich diese Einstellung in Form eines Schlüssels neben jedem Element. +Die Möglichkeit der Rechtevergabe kann in jeder Mapbender-Applikation anpasst werden. Im Tab "Layouts" findet sich diese Einstellung in Form eines Schlüssels neben jedem Element. -Um anzupassen, ob jemand Zugriff auf das Element hat, muss zunächst auf den Schlüssel geklickt werden. Im Anschluss kann ein Nutzer hinzugefügt werden. Dies geschieht über das "+"-Symbol. +Mit einem Klick auf den Schlüssel wird der Benutzerzugriff auf ein Element angepasst. Im Anschluss kann ein Nutzer hinzugefügt werden. Dies geschieht über das "+"-Symbol. -Ein gesetzter Haken neben dem entsprechenden Nutzeraccount erlaubt dem jeweiligen Nutzer den Zugriff. Der Schlüssel wird nach erfolgreicher Rechtevergabe rot. Wenn Sie nun den Cursor über den Schlüssel halten, sehen Sie die Namen der berechtigten Nutzer in einem Pop-Up Fenster. +Ein gesetzter Haken neben dem entsprechenden Nutzer-Account erlaubt dem jeweiligen Nutzer den Zugriff. Der Schlüssel wird nach erfolgreicher Rechtevergabe rot. Wenn Sie nun den Cursor über den Schlüssel halten, sehen Sie die Namen der berechtigten Nutzer in einem Pop-Up Fenster. -.. image:: ../../../../en/functions/backend/FOM/element_security_key_popup.png +.. image:: ../../../../de/functions/backend/FOM/element_security_key_popup.png Login Fehler ------------ -Fehlerhafte Logins werden mit der Meldung "Login fehlerhaft" -kommentiert. Aus Sicherheitsgründen wird nicht genannt, ob es am falschen -Loginnamen oder falschen Passwort liegt. Login Fehler schließen den Account -nicht dauerhaft aus. Vielmehr wird der Account für eine bestimmte Zeit -ausgeschlossen (gelockt). +Fehlerhafte Logins werden mit der Meldung "Login fehlerhaft" kommentiert. Loginfehler schließen den Account nicht dauerhaft aus. Vielmehr wird der Account für eine bestimmte Zeit ausgeschlossen (gelockt). -Die config.yml ermöglicht die Anpassung des Verhaltens: +Die config.yml ermöglicht die Anpassung dieses Verhaltens: .. code-block:: yaml diff --git a/de/quickstart.rst b/de/quickstart.rst index 6741e0112..fb9d33b5a 100644 --- a/de/quickstart.rst +++ b/de/quickstart.rst @@ -374,7 +374,7 @@ http://osm-demo.wheregroup.com/service 5. Benutzer- und Gruppenverwaltung ================================== -Der Zugriff auf eine Anwendung benötigt eine entsprechende Authentifizierung. Nur öffentliche Anwendungen können von allen Anwendern genutzt werden. Benutzer oder Gruppen können Berechtigungen bekommen, um auf eine oder mehrere Anwendungen und Dienste zuzugreifen. +Der Zugriff auf eine Anwendung benötigt eine entsprechende Authentifizierung. Nur öffentliche Anwendungen können von allen Anwendern genutzt werden. Benutzer oder Gruppen können Berechtigungen bekommen, um auf eine oder mehrere Anwendungen oder Dienste zuzugreifen. .. NOCH NICHT IMPLEMENTIERT Es gibt keinen vorgegebenen Unterschied zwischen Rollen wie ``guest``, ``operator`` oder ``administrator``. Die ``role`` eines Benutzers beruht auf den Funktionen und den Diensten, auf die der Benutzer durch diese Anwendung Zugriff hat. diff --git a/en/functions/backend/FOM/acl.png b/en/functions/backend/FOM/acl.png deleted file mode 100644 index 99a592556..000000000 Binary files a/en/functions/backend/FOM/acl.png and /dev/null differ diff --git a/en/functions/backend/FOM/acl.rst b/en/functions/backend/FOM/acl.rst index f177b0594..81e811f0e 100644 --- a/en/functions/backend/FOM/acl.rst +++ b/en/functions/backend/FOM/acl.rst @@ -4,41 +4,15 @@ Access Control Lists ==================== -Security for domain objects (generally database entities) is implemented using -Access Control Lists (ACL). ACLs provide flexible permissions for individual -objects. +The security for domain objects is implemented in Mapbender using Access Control Lists. ACLs provide flexible permissions for individual objects like applications, services or user- and group management. -For each domain object class up to 30 individual permissions can be given. In -general, 7 are used most often: +Mapbender offers these rights to create individual permissions and secure the domain objects: -- View : View object +- View : View an existing object - Create : Create a new object - Edit : Edit an existing object - Delete : Delete an existing object -- Operator : View, Create, Edit, and Delete permission +- Operator : View, Edit, and Delete permission. - Master : Operator permission, can manage all permissions up to operator level. - Owner : Master permission, can grant master permission as well. -Each ACL is composed by an object identity and several Access Control Entries -(ACE). - -Object identites ----------------- -ACLs are not assigned to objects directly, but to so-called object identities. -They represent individual objects or classes (the create permission is a -class-based permission for example). - -Access Control Entries ----------------------- -Each ACE holds the permissions for a single user or role. The permissions are -stored as an integer bitmask, therefore 32 permissions can be used - as some -PHP implementations use 30 bit long integers, 30 is the cross-platform maximum -number of permissions. But as laid out above, 7 are already enough to model -an enhanced CRUD workflow, leaving 23 for custom-tailored permission if needed. - -Security Identities -------------------- -ACEs can be associated with either users or roles by means of encapsulating both -with an security identity. - -.. image:: acl.png diff --git a/en/functions/backend/FOM/edit_user_activated.png b/en/functions/backend/FOM/edit_user_activated.png index 40dcaa534..feeb2d96d 100644 Binary files a/en/functions/backend/FOM/edit_user_activated.png and b/en/functions/backend/FOM/edit_user_activated.png differ diff --git a/en/functions/backend/FOM/element_security_key_popup.png b/en/functions/backend/FOM/element_security_key_popup.png index e69e74a6e..9b01e2f51 100644 Binary files a/en/functions/backend/FOM/element_security_key_popup.png and b/en/functions/backend/FOM/element_security_key_popup.png differ diff --git a/en/functions/backend/FOM/examples.rst b/en/functions/backend/FOM/examples.rst index 6f0e3e38f..0f109e463 100644 --- a/en/functions/backend/FOM/examples.rst +++ b/en/functions/backend/FOM/examples.rst @@ -6,11 +6,11 @@ Examples Reset User with ID 1 -------------------- -The command ``app/console fom:user:resetroot`` resets the user with ID 1. This user owns generally all rights. +The command ``app/console fom:user:resetroot`` resets the user with ID 1 (root). This user generally owns all rights. .. code-block:: bash $ app/console fom:user:resetroot - Welcome to the Mapbender3 root account management command + Welcome to the Mapbender root account management command Enter the username to use for the root account. Username [root]: root Enter the e-mail adress to use for the root account. @@ -23,26 +23,30 @@ The command ``app/console fom:user:resetroot`` resets the user with ID 1. This u Create new user --------------- -The root user (ID 1) can create new users. A user itself can create a new user if he owns the Owner role in the ACL "users". We chose this exception of the rules to avoid other users changing their user-name. +The root user (ID 1) can create new users. A user itself can create a new user if he has the *Owner* role in the ACL "users". We chose this exception of the rules to avoid other users changing their username. Create new applications ----------------------- -A user who would like to create new applications has to have the Create right in the ACL "Applications". Once he has this right, the user can also import and export applications. +Users can create new applications if they have the *create* right in the ACL "Applications". Once that right is permitted, the user can also import and export applications. -To create Layerset Instances, he has to have the right Edit in ACL "Service Source". + +Configure sources +----------------- + +To get permission to the ``Sources`` tab and work with sources in the Mapbender backend, a specified user (or group member) needs the *edit* right in the Global Access Control Lists. Copy applications ----------------- -A user can copy applications if he has the right Edit in ACL "Applications" or within the application itself. The right of the application overwrites the global ACL right. +A user can copy applications if he has the *edit* right in ACL "Applications" or within the application itself. The right of the application overwrites the global ACL right. -Thereby the user is automatically owner of his copied application. +Thereby, the user automatically becomes the owner of the copied application. Delete applications ------------------- -A user can delete applications if he has the right Delete in the ACL "Applications" or within the application itself. The right of the applications overwriters the global ACL right. +A user can delete applications if he has the *delete* right in the ACL "Applications" or within the application itself. The right of the applications overwrites the global ACL right. diff --git a/en/functions/backend/FOM/index.rst b/en/functions/backend/FOM/index.rst index 90fc3b075..508aef3c3 100644 --- a/en/functions/backend/FOM/index.rst +++ b/en/functions/backend/FOM/index.rst @@ -6,8 +6,8 @@ FOMUserBundle - Users and Security .. toctree:: :maxdepth: 1 + security acl users roles_groups - security examples diff --git a/en/functions/backend/FOM/roles_groups.rst b/en/functions/backend/FOM/roles_groups.rst index 299723329..a66cf509a 100644 --- a/en/functions/backend/FOM/roles_groups.rst +++ b/en/functions/backend/FOM/roles_groups.rst @@ -3,24 +3,11 @@ Roles and Groups ================ -Roles are defined by instances of FOM\\ManagerBundle\\Component\\Bundle using -the getRoles method. The naming of roles follows the standard Symfony role -naming scheme, where roles have to be prefixed with "ROLE\_". +Roles are used for global permission checks when no domain object is involved and can be used as security identities of Access Control Entries in Access Control Lists of domain objects. -Roles are used for global permission checks when no domain object is involved -and can be used as security identities of Access Control Entries in Access -Control Lists of domain objects. +In Mapbender, there are currently two roles for rights allocation in the backend available: -Groups are database entities which can be assigned to users on an individual -base. They also are assigned multiple roles. Therefore their primary use is to -collect roles which are assigned to every user of that group. +* All authenticated users: Gives global set permissions for one or more domain object to all users that are logged in while working with Mapbender. +* Anonymous users: Sets global permissions for users which are browsing Mapbender without an individual account. -.. image:: users.png - -Future ------- -At a later point the possibility to assign individual roles directly to an user -will also be implemented. - -Also Symfony provides an API for hierarchical roles which has not yet been -employed by the FOMUserBundle. +Groups are individually created database entities which can be assigned to one or more users. Therefore their primary use is to collect rights which are assigned to every user of that group. diff --git a/en/functions/backend/FOM/security.rst b/en/functions/backend/FOM/security.rst index 6bf3dab75..ec9853d94 100644 --- a/en/functions/backend/FOM/security.rst +++ b/en/functions/backend/FOM/security.rst @@ -8,3 +8,65 @@ Security as provided by the FOMUserBundle is anchored on these base concepts: - :doc:`Users ` - :doc:`Roles and Groups ` - :doc:`ACL ` + + +Rights management +================= + +Mapbender provides different rights. They refer to the :doc:`Access Control Lists (ACL) `. + +* view - Whether someone is allowed to view the object. +* edit - Whether someone is allowed to make changes to the object. +* delete - Whether someone is allowed to delete the object. +* operator - Whether someone is allowed to perform all of the above actions. +* master - Whether someone is allowed to perform all of the above actions and in addition is allowed to grant any of the above mentioned permissions to others. +* owner - Whether someone owns the object. An owner can perform any of the above actions and grant master and owner permissions. + +Assign roles to a user by ``Users --> Edit your User --> Security``. + + .. image:: ../figures/mapbender_roles.png + :scale: 80 + + +Assign an Application to a User/Group +===================================== + +#. Edit your application by ``Application --> Edit-Button``. + +#. Choose ``Security``. + +#. Publish or hide your application for everyone by clicking ``Security --> public access`` or in the application overview by clicking the ``Publish`` button. + +#. Alternatively and for an individual configuration, click the ``Add users and groups`` button and configure your selection. Then, set permissions like view, edit, delete, operator, master or owner via the rights table. + +#. Logout from Mapbender by ``Logout`` and log in again with a configured account to test the configuration. + +#. Another method would be to choose ``Security --> Global Access Control Lists --> Applications`` to quickly set permissions for several users/groups to all applications. + + +Assign single elements to a User/Group +====================================== + +Per default, all elements are available to all users/groups that have permission to an application. It is possible to hide single elements from individual users/groups like this: + +#. Edit your application by clicking ``Application --> Edit``. + +#. Choose ``Layouts``. + +#. Every element has a ``ACL element`` button (key). Choose the ``ACL element`` button from the element that should be only availale for selected users/groups. + +#. Now, add the users/groups via the ``Add users and groups`` button. Then, set permissions like view, edit, delete, operator, master or owner via the rights table. + +#. Test your configuration. For example, open the application with a user account that has (no) rights to a previously configured element. + + +Assign a user to another User/Group +=================================== + +#. Edit a user by clicking ``Security --> Users``. + +#. In the user administration, choose ``Security``. + +#. Give users/groups individual rights on the selected user: Add users/groups via the ``Add users and groups`` button. Thereafter, set permissions within the rights table. + +#. You have now assigned a user/group controlling options over another user account. Test your configuration with the entitled user accounts. diff --git a/en/functions/backend/FOM/user_account_is_disabled.png b/en/functions/backend/FOM/user_account_is_disabled.png deleted file mode 100644 index 27a1e1217..000000000 Binary files a/en/functions/backend/FOM/user_account_is_disabled.png and /dev/null differ diff --git a/en/functions/backend/FOM/user_forgot_password.png b/en/functions/backend/FOM/user_forgot_password.png index 4dca7368e..ee9e70783 100644 Binary files a/en/functions/backend/FOM/user_forgot_password.png and b/en/functions/backend/FOM/user_forgot_password.png differ diff --git a/en/functions/backend/FOM/user_self_register.png b/en/functions/backend/FOM/user_self_register.png index c58d4cf7f..b6dfb3fea 100644 Binary files a/en/functions/backend/FOM/user_self_register.png and b/en/functions/backend/FOM/user_self_register.png differ diff --git a/en/functions/backend/FOM/users.png b/en/functions/backend/FOM/users.png deleted file mode 100644 index 0c49b7b70..000000000 Binary files a/en/functions/backend/FOM/users.png and /dev/null differ diff --git a/en/functions/backend/FOM/users.rst b/en/functions/backend/FOM/users.rst index fae45c9d9..440d5796b 100644 --- a/en/functions/backend/FOM/users.rst +++ b/en/functions/backend/FOM/users.rst @@ -3,32 +3,21 @@ Users ===== -User are implemented as FOM\\UserBundle\\Entity\\User and stored in the database. -The entity has only some basic information about the user itself, more complex -user data will have to be implemented by user profiles (yet to be done). +User are implemented as FOM\\UserBundle\\Entity\\User and stored in the database. The entity has only some basic information about the user itself, more complex user data will have to be implemented by user profiles (yet to be done). -The bundles provides all means to administrate users by admin as well as self-registration and password recovery. +The bundle provides all means to administrate users by admin as well as self-registration and password recovery. -The user with the id 1 is special, as this user is created during installation -and will always be given full access. If all is lost, you can use this user -to manage everything. And in the event that the credentials for this user are -also lost, a console command (fom:user:resetroot) is available for resetting. +The user with the id 1 (root) is special, as this user is created during installation and will always be given full access. If all is lost, you can use this user to manage everything. And in the event that the credentials for this user are also lost, a console command (fom:user:resetroot) is available for resetting. -.. note:: **Notice:** To use the features below, Symfony Switfmailer needs to be set up correctly. Please check your local Symfony verion and adjust the Symfony documentation accordingly before setting up Swiftmailer. An in-depth configuration can be found in the official Symfony docs: https://symfony.com/doc/current/mailer.html Forgot Password --------------- -If a user has forgotten his/her password, he can use the "Forgot password?" -link in the Login-screen to request a new one. For that he types in his -username or e-mail-adress. +If a user has forgotten his/her password, he can use the "Forgot password?" link in the Login screen to request a new one. For that he types in his username or email address. .. image:: ../../../../en/functions/backend/FOM/user_forgot_password.png -After that he gets an e-mail with a link, which leads him to a site where he -can reset his password. The link isn't valid anymore after this -operation. The text of the mail can be customized in the -/FOM/UserBundle/Resources/translations/messages.en.xlf file. +After that, the user should receive an e-mail with a link which leads to a page where a password reset is possible. The link is not valid anymore after this operation. The text of the mail can be customized in the /FOM/UserBundle/Resources/translations/messages.en.xlf file. The functionality can be switched off in the config.yml. @@ -38,49 +27,35 @@ The functionality can be switched off in the config.yml. reset_password: true # true/false +Registration +------------ -Registering ------------ - -Users can self-register themselves in Mapbender. For this you have to adjust -the setting fom_user:selfregister in the config.yml to true. +Users can self-register themselves in Mapbender. For this you have to adjust the setting fom_user:selfregister in the config.yml to true. .. code-block:: yaml fom_user: selfregister: false # true/false -The Login-dialog contains a "Register" link. This opens a page where the -user can type in his/her name, password and e-mail adresss. +The Login-dialog contains a "Register" link. This opens a page where the user can type in his/her name, password and e-mail adresss. .. image:: ../../../../en/functions/backend/FOM/user_self_register.png +After that he gets a confirmation mail to complete the registration. Until that time he is only managed as an inactive user in Mapbender. -After that he gets a confirmation mail to complete the registration. Until -that time he is only managed as an inactive user in Mapbender. - -The text of the confirmation mail can be customized in the -/FOM/UserBundle/Resources/translations/messages.en.xlf file. +The text of the confirmation mail can be customized in the /FOM/UserBundle/Resources/translations/messages.en.xlf file. Activation of users ------------------- -Users can be set activated or deactivated by -Administrators with the User-ACL-right of at least "edit". For this purpose, -a checkbox exists in the Edit User dialog. - -A user with administration rights cannot activate or deactivate himself. +Users can be set activated or deactivated by Administrators with the User-ACL-Right of at least *edit*. For this purpose, a checkbox exists in the Edit User dialog. A user with administration rights cannot activate or deactivate himself. .. image:: ../../../../en/functions/backend/FOM/edit_user_activated.png -A user who is deactivated cannot login into Mapbender anymore until he gets -activated again. - -.. image:: ../../../../en/functions/backend/FOM/user_account_is_disabled.png +A user who is deactivated cannot login into Mapbender anymore until he gets activated again. -Users which have self-registered themselves but have not approved the -activation mail can now be activated by an administrator. +Users which have self-registered themselves but have not approved the activation mail can now be activated by an administrator. Managing users with the security key feature @@ -88,7 +63,7 @@ Managing users with the security key feature Inside every Mapbender application, there is a possibility to adjust the rights of certain users and maintain visibility of what they are allowed to do. You can set these preferences in the "Layouts"-tab. -Next to every element is a security key. If you click on the key, you can adjust the certain rights of each user. Just add users who should gain access to the element with the "+" symbol in the pop-up window. A set checkmark next to the user account provides the essential rights for the respective user. +Next to every element is a security key. If you click on the key, you can adjust the specific element rights of a user. Just add users who should gain access to the element with the "+" symbol in the pop-up window. A set checkmark next to the user account provides the essential rights for the respective user. After setting specific access rights, the security key turns red. If you hover over the key with the cursor, you will see the names of the users who have rights to the element. @@ -98,13 +73,9 @@ After setting specific access rights, the security key turns red. If you hover o Login Failures -------------- -Login failures are responded with the Message "Bad credentials". For -security reasons it is not shown if the error is based on a wrong -username or a wrong password. Login failures will not lock the account -indefinitely after four attempts. Rather the account will be locked for a -given period of time. +Login failures are responded with the Message "Bad credentials". For security reasons it is not shown if the error is based on a wrong username or a wrong password. Login failures will not lock the account indefinitely after four attempts. Rather the account will be locked for a given period of time. -The config.yml allows to adjust the behaviour: +The config.yml allows to adjust this behaviour: .. code-block:: yaml diff --git a/en/quickstart.rst b/en/quickstart.rst index 2a1922380..faec2e864 100644 --- a/en/quickstart.rst +++ b/en/quickstart.rst @@ -376,7 +376,7 @@ http://osm-demo.wheregroup.com/service Access to Mapbender requires authentication. Only public applications can be used by everyone. -A user has permissions to access one or a set of applications and services. +A user can get permissions to access one or a set of applications and services. .. NOT IMPLEMENTED YET There is no inherent difference between roles like :``guest``, ``operator`` or ``administrator``. The ``role`` of a user depends on the functionality and services the user has access through his applications.