Joomla! Documentation - User contributions [en]

J3.x:Developing an MVC Component/Adding an update server

2022-02-13T19:08:36Z

Sieger66:

<noinclude><languages /></noinclude>
{{:J3.1:Developing an MVC Component/<translate>

en</translate>}}

<translate>

This tutorial is part of the [[S:MyLanguage/J3.2:Developing an MVC Component | Developing an MVC Component for Joomla! 3.2]] tutorial. You are encouraged to read the previous parts of the tutorial before reading this.</translate>

<translate>

In this part, we will cover the various aspects of setting up an update server for our helloworld component.</translate>

<translate>

A video accompanying this step is available at [https://youtu.be/nAj-LNep3Rw Adding an Update Server].</translate>

<translate>
== Introduction == </translate>
<translate>

Updating Joomla extensions via an update server is a two step process:
# finding the updates available for the installed extensions
# selecting an update and installing it.
Typically this is done by the administrator via the Extensions / Manage / Update page.
# You click on Find Updates to find the updates available
# You mark the checkbox of each update you want to install and click on Update.
In this step we enable our Helloworld component to be updated in this way.</translate>

<translate>
=== Finding Updates === </translate>
<translate>

Each Joomla extension which is updated via an update server has a URL associated with it which points to an XML file containing details of the updates available. This file could be hosted on the extension developer's own website, for example. If you go to Extensions / Manage / Update Sites you will see this URL in the Update Site column, and you can click on those URLs to see the format of the XML files. (Some of these XML files may be of type "collection" where the first XML element is <tt><extensionset></tt>, and these are described towards the end of this tutorial, but for now we're concentrating on the type "extension" where the first XML element is <tt><updates></tt>).</translate>

<translate>

The XML file (described more fully below) contains details of what updates are available for that extension, including any restrictions (eg you have to be running a certain Joomla version to be able to use it), and the URL of the zip file containing the new version of the extension.
You tell Joomla the URL of the XML file for your extension within the manifest file (helloworld.xml), eg</translate>

<source lang="xml">
<updateservers>
<server type="extension" name="Helloworld Updates">http://myDeveloperSite/helloworld-updates/updates.xml</server>
</updateservers>
</source>

<translate>

Below is a basic update XML file </translate>

<source lang="xml">
<updates>
<update>
<name>Helloworld component</name>
<description>Helloworld component for Joomla MVC tutorial</description>
<element>com_helloworld</element>
<type>component</type>
<version>1.0.0</version>
<client>administrator</client>
<downloads>
<downloadurl type="full" format="zip">http://myDeveloperSite/helloworld-updates/helloworld-1-0-0.zip</downloadurl>
</downloads>
<targetplatform name="joomla" version="3.[23456789]" />
<php_minimum>7.1</php_minimum>
</update>
</updates>
</source>

<translate>

Note that it has
* basic information about the component – eg name, version
* a link to the zip file for that update
* restrictions – for Joomla versions 3.2 to 3.9 only, and at least PHP version 7.1 </translate>
<translate>

Whenever an administrator clicks on the Find Updates button, Joomla sends HTTP requests to each of the URLs of these update servers to retrieve the XML files. It parses each XML file,
# ensures it's properly formed XML
# compares the version of the update with the version of the extension currently running
# checks any restrictions (Joomla versions, PHP versions, database versions) with what is currently running.</translate>
<translate>

If it finds it's a valid update for this website, then it inserts a record into the "updates" table in the database. (You'll find at most 1 update for each extension, because if there are several possible then Joomla will store only the most recent valid version, ie with the highest version number).</translate>

<translate>
=== Installing Updates === </translate>
<translate>

Once an update has been inserted into the "updates" table it is visible to the administrator in the Extension / Manage / Update page. After checking the checkbox and clicking the Update button Joomla will
* once again send an HTTP request to the URL of the update XML file
* parse the XML file and ensure that conditions for installing that version are still met
* send an HTTP request to the URL of the update zip file, storing the file received in the HTTP response in its /tmp directory
* proceed to install the new version from the downloaded zip file.</translate>

<translate>
== Approach == </translate>
<translate>

In this tutorial step we will update our helloworld extension to use an update server.</translate>
<translate>

We'll also set up the server files so that you can verify that the update process works ok.</translate>
<translate>

To do this you'll need to configure part of your development area to act as the update server. This basically means creating a directory below the root directory serviced by your web server, and including the update XML file etc in it.</translate>
<translate>

For example, I have a folder <tt>/helloworld</tt> which contains my Joomla instance, so that to access the site I put the URL <tt>http://localhost/helloworld/index.php</tt> into the browser.</translate>
<translate>

For the update server I created a folder <tt>/helloworld-updates</tt> at the same level as <tt>/helloworld</tt>, and put the <tt>updates.xml</tt> file into that folder. I can then access the XML file by putting the URL <tt>http://localhost/helloworld-updates/updates.xml</tt> into the browser.</translate>
<translate>

You'll need to do something similar in your own environment, and verify that the URL is correct by accessing the XML file through your browser.</translate>

<translate>
== Updated Code == </translate>
<translate>

The only change we need to make to our helloworld component is to include the update server inside the manifest file. Once updated, zip up the component as usual and install it on your Joomla instance. </translate>

<span id="helloworld.xml">
<tt>helloworld.xml</tt>
<source lang="xml" highlight="13,100-103">
<?xml version="1.0" encoding="utf-8"?>
<extension type="component" version="3.0" method="upgrade">

<name>COM_HELLOWORLD</name>

<creationDate>January 2018</creationDate>
<author>John Doe</author>
<authorEmail>john.doe@example.org</authorEmail>
<authorUrl>http://www.example.org</authorUrl>
<copyright>Copyright Info</copyright>
<license>License Info</license>

<version>0.0.33</version>

<description>COM_HELLOWORLD_DESCRIPTION</description>


<scriptfile>script.php</scriptfile>

<install> 
<sql>
<file driver="mysql" charset="utf8">sql/install.mysql.utf8.sql</file>
</sql>
</install>
<uninstall> 
<sql>
<file driver="mysql" charset="utf8">sql/uninstall.mysql.utf8.sql</file>
</sql>
</uninstall>
<update> 
<schemas>
<schemapath type="mysql">sql/updates/mysql</schemapath>
</schemas>
</update>



<files folder="site">
<filename>index.html</filename>
<filename>helloworld.php</filename>
<filename>controller.php</filename>
<filename>router.php</filename>
<folder>controllers</folder>
<folder>views</folder>
<folder>models</folder>
<folder>helpers</folder>
</files>

<languages folder="site/language">
<language tag="en-GB">en-GB/en-GB.com_helloworld.ini</language>
<language tag="fr-FR">fr-FR/fr-FR.com_helloworld.ini</language>
</languages>

<media destination="com_helloworld" folder="media">
<filename>index.html</filename>
<folder>images</folder>
<folder>js</folder>
<folder>css</folder>
</media>

<administration>

<menu link='index.php?option=com_helloworld' img="../media/com_helloworld/images/tux-16x16.png">COM_HELLOWORLD_MENU</menu>


<files folder="admin">

<filename>index.html</filename>
<filename>config.xml</filename>
<filename>helloworld.php</filename>
<filename>controller.php</filename>
<filename>access.xml</filename>

<folder>sql</folder>

<folder>tables</folder>

<folder>models</folder>

<folder>views</folder>

<folder>controllers</folder>

<folder>helpers</folder>

<folder>layouts</folder>
</files>
<languages folder="admin/language">
<language tag="en-GB">en-GB/en-GB.com_helloworld.ini</language>
<language tag="en-GB">en-GB/en-GB.com_helloworld.sys.ini</language>
<language tag="fr-FR">fr-FR/fr-FR.com_helloworld.ini</language>
<language tag="fr-FR">fr-FR/fr-FR.com_helloworld.sys.ini</language>
</languages>
</administration>

<updateservers>

<server type="extension" name="Helloworld Updates">http://localhost/helloworld-updates/updates.xml</server>
</updateservers>
</extension>
</source>
</span>

<translate>
== Update Server Files == </translate>
<translate>

We're going to put 3 files into the directory which we're using to act as the update server, ie into the /helloworld-updates folder, or wherever you have decided to use. The 3 files are:
# the updates.xml file
# an html file which is an information file for the latest version
# a zip file for the update.
For security purposes you should also add the usual blank index.html file as well.</translate>
<translate>

The updates.xml file is below. You should change the infourl and downloadurl to suit your environment, and set values for the targetplatform, php_minimum and supported_databases as you wish.</translate>

<source lang="xml">
<updates>
<update>
<name>Helloworld component</name>
<description>Helloworld component for Joomla MVC tutorial</description>
<element>com_helloworld</element>
<type>component</type>
<version>1.0.0</version>
<client>administrator</client>
<infourl>http://localhost/helloworld-updates/info-1-0-0.html</infourl>
<downloads>
<downloadurl type="full" format="zip">http://localhost/helloworld-updates/helloworld-1-0-0.zip</downloadurl>
</downloads>
<tags>
<tag>stable</tag>
</tags>
<targetplatform name="joomla" version="3.[23456789]" />
<php_minimum>5.3</php_minimum>
<supported_databases mysql="5.6.19"></supported_databases>
</update>
</updates>
</source>
<translate>

You can find definitions of the elements of this XML structure at [[Deploying an Update Server]], but note that the attributes min_dev_level and max_dev_level are marked as deprecated in the current (3.9) Joomla code, to be removed in Joomla 4.</translate>
<translate>

The information file is just a basic html document, which you can modify as you wish. Its filename must match what is specified in the <tt><infourl></tt> tag above.</translate>

<source lang="html">
<!DOCTYPE html>
<html>
<head>
<title>Helloworld update</title>
</head>
<body>
<h1>Update to version 1.0.0</h1>
</body>
</html>
</source>

<translate>

Finally create a store a zip file for the new version. As a minimum you need to update the version in the manifest file, and you may wish to make another change which is visible when you visit the site.
# Update the manifest file (helloworld.xml) to set the version line to <version>1.0.0</version>
# Create a zip file of the helloworld component
# Copy the zip file into your update server directory. Its name must match what is specified in the <downloadurl> tag (helloworld-1-0-0.zip above).</translate>

<translate>
== Testing the Update Server == </translate>
<translate>

To test your update server do the following:
# log in to the backend of your site using an admin account
# go to Extensions / Manage / Update
# click on Find Updates – your helloworld component should appear as an update. (It may already be shown, because when you display the admin control panel it issues an ajax request which initiates the find updates process).
# click on the checkbox next to the helloworld component, and click on Update
# go to Extensions / Manage / Manage and find the helloworld component. Its version should now be 1.0.0 (or whatever version you updated to).</translate>
<translate>

(For info, using phpmyadmin you can change the existing version number of the helloworld component by finding the appropriate record in the extensions table, and updating the version number within the json string in the manifest_cache field.)</translate>

<translate>
== Collections type == </translate>
<translate>

Up to now we've been considering the server type="extension", but Joomla also has a server type="collection". The purpose of this type is to allow you to have a collection of different update XML files. You would use a "collection" type if, for example,
# your extension is a package and you want to allow users to update the package components individually
# you want to have different update XML files for different versions of Joomla.</translate>
<translate>

Joomla languages use a collection type. If you have several languages installed and go to Extensions / Manage / Update Sites then you can see that all the languages have the same update site URL pointing to something like https://update.joomla.org/language/translationlist_3.xml . If you open that XML file then you see all the details URLs which are the update XML files of the individual languages, and which can be installed via the Extensions / Manage / Install Languages page.</translate>

<translate>

Joomla core also uses a collection type. If you go to Update Sites and click on the XML file for Joomla! Core then you will see different update XML files depending upon whether the installed version of Joomla is 2.x or 3.x.</translate>
<translate>

If you wish to try using a collection type, then this is still possible with a single update XML file, by following the steps below.</translate>
<translate>

Firstly delete manually (using phpmyadmin) the records in the database tables update_sites and update_sites_extensions which relate to the helloworld component. Then go into Extensions / Manage / Update and click on Clear Cache. This should have removed all trace of the type="extension" update mechanism.</translate>
<translate>

Secondly replace the updateservers section of the manifest file with the following (changing the URL appropriately)</translate>
<source lang="xml">
<updateservers>
<server type="collection" name="Helloworld Updates">http://localhost/helloworld-updates/list.xml</server>
</updateservers>
</source>
<translate>

Zip up the component and install it in the usual way. (Remember, when you install it in this way the version number in the new install file doesn't need to be greater than the version of the one currently installed).</translate>
<translate>

Thirdly create a list.xml file which points to the update XML file, and store this in your update server folder. Once again, change the URL and version to match your own situation, making sure that the version quoted in the file is greater than the one currently installed.</translate>
<source lang="xml">
<extensionset name="Helloworld Update Collection" description="Helloworld Update as Collection">
<extension name="Helloworld Component" element="com_helloworld" type="component" client="administrator" version="1.0.0" targetplatformversion="3.[23456789]" detailsurl="http://localhost/helloworld-updates/updates.xml"/>
</extensionset>
</source>
<translate>

If you test the update process as above you should find it works just the same. However, note that in this case the updates.xml file is not processed during the Find Updates process, so if you have an incompatible minimum value of PHP say, then it won't report it at that stage.</translate>

<translate>
== Contributors == </translate>
*[[User:Robbiej|Robbie Jackson]]

<div class="row">
<div class="large-6 columns">{{Basic button|S:MyLanguage/J3.x:Developing_an_MVC_Component/Adding a Feed|<translate> Prev: Adding a Feed</translate>|class=expand success}}</div>
<div class="large-6 columns">{{Basic button|
S:MyLanguage/J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|<translate> Next: Adding Custom Fields</translate>|class=expand}}</div>
</div>

__NOTOC__
<noinclude>
<translate>

[[Category:Joomla! 3.x{{#translation:}}]]
[[Category:Joomla! 3.0{{#translation:}}]]
[[Category:Joomla! 3.1{{#translation:}}]]
[[Category:Joomla! 3.2{{#translation:}}]]
[[Category:Joomla! 3.3{{#translation:}}]]
[[Category:Joomla! 3.4{{#translation:}}]]
[[Category:Joomla! 3.5{{#translation:}}]]
[[Category:Joomla! 3.6{{#translation:}}]]
[[Category:Joomla! 3.7{{#translation:}}]]
[[Category:Joomla! 3.8{{#translation:}}]]
[[Category:Joomla! 3.9{{#translation:}}]]
[[Category:Beginner Development{{#translation:}}]]
[[Category:Component Development{{#translation:}}]]
[[Category:Tutorials{{#translation:}}]]
[[Category:Tutorials in a Series{{#translation:}}]]
</translate>
</noinclude>

J3.x:Developing an MVC Component/Adding an update server

2022-02-13T18:56:58Z

Sieger66:

<noinclude><languages /></noinclude>
{{:J3.1:Developing an MVC Component/<translate>

en</translate>}}

<translate>

This tutorial is part of the [[S:MyLanguage/J3.2:Developing an MVC Component | Developing an MVC Component for Joomla! 3.2]] tutorial. You are encouraged to read the previous parts of the tutorial before reading this.</translate>

<translate>

In this part, we will cover the various aspects of setting up an update server for our helloworld component.</translate>

<translate>

A video accompanying this step is available at [https://youtu.be/nAj-LNep3Rw Adding an Update Server].</translate>

<translate>
== Introduction == </translate>
<translate>

Updating Joomla extensions via an update server is a two step process:
# finding the updates available for the installed extensions
# selecting an update and installing it.
Typically this is done by the administrator via the Extensions / Manage / Update page.
# You click on Find Updates to find the updates available
# You mark the checkbox of each update you want to install and click on Update.
In this step we enable our Helloworld component to be updated in this way.</translate>

<translate>
=== Finding Updates === </translate>
<translate>

Each Joomla extension which is updated via an update server has a URL associated with it which points to an XML file containing details of the updates available. This file could be hosted on the extension developer's own website, for example. If you go to Extensions / Manage / Update Sites you will see this URL in the Update Site column, and you can click on those URLs to see the format of the XML files. (Some of these XML files may be of type "collection" where the first XML element is <tt><extensionset></tt>, and these are described towards the end of this tutorial, but for now we're concentrating on the type "extension" where the first XML element is <tt><updates></tt>).</translate>

<translate>

The XML file (described more fully below) contains details of what updates are available for that extension, including any restrictions (eg you have to be running a certain Joomla version to be able to use it), and the URL of the zip file containing the new version of the extension.
You tell Joomla the URL of the XML file for your extension within the manifest file (helloworld.xml), eg</translate>

<source lang="xml">
<updateservers>
<server type="extension" name="Helloworld Updates">http://myDeveloperSite/helloworld-updates/updates.xml</server>
</updateservers>
</source>

<translate>

Below is a basic update XML file </translate>

<source lang="xml">
<updates>
<update>
<name>Helloworld component</name>
<description>Helloworld component for Joomla MVC tutorial</description>
<element>com_helloworld</element>
<type>component</type>
<version>1.0.0</version>
<client>site</client>
<downloads>
<downloadurl type="full" format="zip">http://myDeveloperSite/helloworld-updates/helloworld-1-0-0.zip</downloadurl>
</downloads>
<targetplatform name="joomla" version="3.[23456789]" />
<php_minimum>7.1</php_minimum>
</update>
</updates>
</source>

<translate>

Note that it has
* basic information about the component – eg name, version
* a link to the zip file for that update
* restrictions – for Joomla versions 3.2 to 3.9 only, and at least PHP version 7.1 </translate>
<translate>

Whenever an administrator clicks on the Find Updates button, Joomla sends HTTP requests to each of the URLs of these update servers to retrieve the XML files. It parses each XML file,
# ensures it's properly formed XML
# compares the version of the update with the version of the extension currently running
# checks any restrictions (Joomla versions, PHP versions, database versions) with what is currently running.</translate>
<translate>

If it finds it's a valid update for this website, then it inserts a record into the "updates" table in the database. (You'll find at most 1 update for each extension, because if there are several possible then Joomla will store only the most recent valid version, ie with the highest version number).</translate>

<translate>
=== Installing Updates === </translate>
<translate>

Once an update has been inserted into the "updates" table it is visible to the administrator in the Extension / Manage / Update page. After checking the checkbox and clicking the Update button Joomla will
* once again send an HTTP request to the URL of the update XML file
* parse the XML file and ensure that conditions for installing that version are still met
* send an HTTP request to the URL of the update zip file, storing the file received in the HTTP response in its /tmp directory
* proceed to install the new version from the downloaded zip file.</translate>

<translate>
== Approach == </translate>
<translate>

In this tutorial step we will update our helloworld extension to use an update server.</translate>
<translate>

We'll also set up the server files so that you can verify that the update process works ok.</translate>
<translate>

To do this you'll need to configure part of your development area to act as the update server. This basically means creating a directory below the root directory serviced by your web server, and including the update XML file etc in it.</translate>
<translate>

For example, I have a folder <tt>/helloworld</tt> which contains my Joomla instance, so that to access the site I put the URL <tt>http://localhost/helloworld/index.php</tt> into the browser.</translate>
<translate>

For the update server I created a folder <tt>/helloworld-updates</tt> at the same level as <tt>/helloworld</tt>, and put the <tt>updates.xml</tt> file into that folder. I can then access the XML file by putting the URL <tt>http://localhost/helloworld-updates/updates.xml</tt> into the browser.</translate>
<translate>

You'll need to do something similar in your own environment, and verify that the URL is correct by accessing the XML file through your browser.</translate>

<translate>
== Updated Code == </translate>
<translate>

The only change we need to make to our helloworld component is to include the update server inside the manifest file. Once updated, zip up the component as usual and install it on your Joomla instance. </translate>

<span id="helloworld.xml">
<tt>helloworld.xml</tt>
<source lang="xml" highlight="13,100-103">
<?xml version="1.0" encoding="utf-8"?>
<extension type="component" version="3.0" method="upgrade">

<name>COM_HELLOWORLD</name>

<creationDate>January 2018</creationDate>
<author>John Doe</author>
<authorEmail>john.doe@example.org</authorEmail>
<authorUrl>http://www.example.org</authorUrl>
<copyright>Copyright Info</copyright>
<license>License Info</license>

<version>0.0.33</version>

<description>COM_HELLOWORLD_DESCRIPTION</description>


<scriptfile>script.php</scriptfile>

<install> 
<sql>
<file driver="mysql" charset="utf8">sql/install.mysql.utf8.sql</file>
</sql>
</install>
<uninstall> 
<sql>
<file driver="mysql" charset="utf8">sql/uninstall.mysql.utf8.sql</file>
</sql>
</uninstall>
<update> 
<schemas>
<schemapath type="mysql">sql/updates/mysql</schemapath>
</schemas>
</update>



<files folder="site">
<filename>index.html</filename>
<filename>helloworld.php</filename>
<filename>controller.php</filename>
<filename>router.php</filename>
<folder>controllers</folder>
<folder>views</folder>
<folder>models</folder>
<folder>helpers</folder>
</files>

<languages folder="site/language">
<language tag="en-GB">en-GB/en-GB.com_helloworld.ini</language>
<language tag="fr-FR">fr-FR/fr-FR.com_helloworld.ini</language>
</languages>

<media destination="com_helloworld" folder="media">
<filename>index.html</filename>
<folder>images</folder>
<folder>js</folder>
<folder>css</folder>
</media>

<administration>

<menu link='index.php?option=com_helloworld' img="../media/com_helloworld/images/tux-16x16.png">COM_HELLOWORLD_MENU</menu>


<files folder="admin">

<filename>index.html</filename>
<filename>config.xml</filename>
<filename>helloworld.php</filename>
<filename>controller.php</filename>
<filename>access.xml</filename>

<folder>sql</folder>

<folder>tables</folder>

<folder>models</folder>

<folder>views</folder>

<folder>controllers</folder>

<folder>helpers</folder>

<folder>layouts</folder>
</files>
<languages folder="admin/language">
<language tag="en-GB">en-GB/en-GB.com_helloworld.ini</language>
<language tag="en-GB">en-GB/en-GB.com_helloworld.sys.ini</language>
<language tag="fr-FR">fr-FR/fr-FR.com_helloworld.ini</language>
<language tag="fr-FR">fr-FR/fr-FR.com_helloworld.sys.ini</language>
</languages>
</administration>

<updateservers>

<server type="extension" name="Helloworld Updates">http://localhost/helloworld-updates/updates.xml</server>
</updateservers>
</extension>
</source>
</span>

<translate>
== Update Server Files == </translate>
<translate>

We're going to put 3 files into the directory which we're using to act as the update server, ie into the /helloworld-updates folder, or wherever you have decided to use. The 3 files are:
# the updates.xml file
# an html file which is an information file for the latest version
# a zip file for the update.
For security purposes you should also add the usual blank index.html file as well.</translate>
<translate>

The updates.xml file is below. You should change the infourl and downloadurl to suit your environment, and set values for the targetplatform, php_minimum and supported_databases as you wish.</translate>

<source lang="xml">
<updates>
<update>
<name>Helloworld component</name>
<description>Helloworld component for Joomla MVC tutorial</description>
<element>com_helloworld</element>
<type>component</type>
<version>1.0.0</version>
<client>site</client>
<infourl>http://localhost/helloworld-updates/info-1-0-0.html</infourl>
<downloads>
<downloadurl type="full" format="zip">http://localhost/helloworld-updates/helloworld-1-0-0.zip</downloadurl>
</downloads>
<tags>
<tag>stable</tag>
</tags>
<targetplatform name="joomla" version="3.[23456789]" />
<php_minimum>5.3</php_minimum>
<supported_databases mysql="5.6.19"></supported_databases>
</update>
</updates>
</source>
<translate>

You can find definitions of the elements of this XML structure at [[Deploying an Update Server]], but note that the attributes min_dev_level and max_dev_level are marked as deprecated in the current (3.9) Joomla code, to be removed in Joomla 4.</translate>
<translate>

The information file is just a basic html document, which you can modify as you wish. Its filename must match what is specified in the <tt><infourl></tt> tag above.</translate>

<source lang="html">
<!DOCTYPE html>
<html>
<head>
<title>Helloworld update</title>
</head>
<body>
<h1>Update to version 1.0.0</h1>
</body>
</html>
</source>

<translate>

Finally create a store a zip file for the new version. As a minimum you need to update the version in the manifest file, and you may wish to make another change which is visible when you visit the site.
# Update the manifest file (helloworld.xml) to set the version line to <version>1.0.0</version>
# Create a zip file of the helloworld component
# Copy the zip file into your update server directory. Its name must match what is specified in the <downloadurl> tag (helloworld-1-0-0.zip above).</translate>

<translate>
== Testing the Update Server == </translate>
<translate>

To test your update server do the following:
# log in to the backend of your site using an admin account
# go to Extensions / Manage / Update
# click on Find Updates – your helloworld component should appear as an update. (It may already be shown, because when you display the admin control panel it issues an ajax request which initiates the find updates process).
# click on the checkbox next to the helloworld component, and click on Update
# go to Extensions / Manage / Manage and find the helloworld component. Its version should now be 1.0.0 (or whatever version you updated to).</translate>
<translate>

(For info, using phpmyadmin you can change the existing version number of the helloworld component by finding the appropriate record in the extensions table, and updating the version number within the json string in the manifest_cache field.)</translate>

<translate>
== Collections type == </translate>
<translate>

Up to now we've been considering the server type="extension", but Joomla also has a server type="collection". The purpose of this type is to allow you to have a collection of different update XML files. You would use a "collection" type if, for example,
# your extension is a package and you want to allow users to update the package components individually
# you want to have different update XML files for different versions of Joomla.</translate>
<translate>

Joomla languages use a collection type. If you have several languages installed and go to Extensions / Manage / Update Sites then you can see that all the languages have the same update site URL pointing to something like https://update.joomla.org/language/translationlist_3.xml . If you open that XML file then you see all the details URLs which are the update XML files of the individual languages, and which can be installed via the Extensions / Manage / Install Languages page.</translate>

<translate>

Joomla core also uses a collection type. If you go to Update Sites and click on the XML file for Joomla! Core then you will see different update XML files depending upon whether the installed version of Joomla is 2.x or 3.x.</translate>
<translate>

If you wish to try using a collection type, then this is still possible with a single update XML file, by following the steps below.</translate>
<translate>

Firstly delete manually (using phpmyadmin) the records in the database tables update_sites and update_sites_extensions which relate to the helloworld component. Then go into Extensions / Manage / Update and click on Clear Cache. This should have removed all trace of the type="extension" update mechanism.</translate>
<translate>

Secondly replace the updateservers section of the manifest file with the following (changing the URL appropriately)</translate>
<source lang="xml">
<updateservers>
<server type="collection" name="Helloworld Updates">http://localhost/helloworld-updates/list.xml</server>
</updateservers>
</source>
<translate>

Zip up the component and install it in the usual way. (Remember, when you install it in this way the version number in the new install file doesn't need to be greater than the version of the one currently installed).</translate>
<translate>

Thirdly create a list.xml file which points to the update XML file, and store this in your update server folder. Once again, change the URL and version to match your own situation, making sure that the version quoted in the file is greater than the one currently installed.</translate>
<source lang="xml">
<extensionset name="Helloworld Update Collection" description="Helloworld Update as Collection">
<extension name="Helloworld Component" element="com_helloworld" type="component" client="administrator" version="1.0.0" targetplatformversion="3.[23456789]" detailsurl="http://localhost/helloworld-updates/updates.xml"/>
</extensionset>
</source>
<translate>

If you test the update process as above you should find it works just the same. However, note that in this case the updates.xml file is not processed during the Find Updates process, so if you have an incompatible minimum value of PHP say, then it won't report it at that stage.</translate>

<translate>
== Contributors == </translate>
*[[User:Robbiej|Robbie Jackson]]

<div class="row">
<div class="large-6 columns">{{Basic button|S:MyLanguage/J3.x:Developing_an_MVC_Component/Adding a Feed|<translate> Prev: Adding a Feed</translate>|class=expand success}}</div>
<div class="large-6 columns">{{Basic button|
S:MyLanguage/J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|<translate> Next: Adding Custom Fields</translate>|class=expand}}</div>
</div>

__NOTOC__
<noinclude>
<translate>

[[Category:Joomla! 3.x{{#translation:}}]]
[[Category:Joomla! 3.0{{#translation:}}]]
[[Category:Joomla! 3.1{{#translation:}}]]
[[Category:Joomla! 3.2{{#translation:}}]]
[[Category:Joomla! 3.3{{#translation:}}]]
[[Category:Joomla! 3.4{{#translation:}}]]
[[Category:Joomla! 3.5{{#translation:}}]]
[[Category:Joomla! 3.6{{#translation:}}]]
[[Category:Joomla! 3.7{{#translation:}}]]
[[Category:Joomla! 3.8{{#translation:}}]]
[[Category:Joomla! 3.9{{#translation:}}]]
[[Category:Beginner Development{{#translation:}}]]
[[Category:Component Development{{#translation:}}]]
[[Category:Tutorials{{#translation:}}]]
[[Category:Tutorials in a Series{{#translation:}}]]
</translate>
</noinclude>

J3.x:Developing an MVC Component/Adding an update server

2022-02-13T18:54:12Z

Sieger66:

<noinclude><languages /></noinclude>
{{:J3.1:Developing an MVC Component/<translate>

en</translate>}}

<translate>

This tutorial is part of the [[S:MyLanguage/J3.2:Developing an MVC Component | Developing an MVC Component for Joomla! 3.2]] tutorial. You are encouraged to read the previous parts of the tutorial before reading this.</translate>

<translate>

In this part, we will cover the various aspects of setting up an update server for our helloworld component.</translate>

<translate>

A video accompanying this step is available at [https://youtu.be/nAj-LNep3Rw Adding an Update Server].</translate>

<translate>
== Introduction == </translate>
<translate>

Updating Joomla extensions via an update server is a two step process:
# finding the updates available for the installed extensions
# selecting an update and installing it.
Typically this is done by the administrator via the Extensions / Manage / Update page.
# You click on Find Updates to find the updates available
# You mark the checkbox of each update you want to install and click on Update.
In this step we enable our Helloworld component to be updated in this way.</translate>

<translate>
=== Finding Updates === </translate>
<translate>

Each Joomla extension which is updated via an update server has a URL associated with it which points to an XML file containing details of the updates available. This file could be hosted on the extension developer's own website, for example. If you go to Extensions / Manage / Update Sites you will see this URL in the Update Site column, and you can click on those URLs to see the format of the XML files. (Some of these XML files may be of type "collection" where the first XML element is <tt><extensionset></tt>, and these are described towards the end of this tutorial, but for now we're concentrating on the type "extension" where the first XML element is <tt><updates></tt>).</translate>

<translate>

The XML file (described more fully below) contains details of what updates are available for that extension, including any restrictions (eg you have to be running a certain Joomla version to be able to use it), and the URL of the zip file containing the new version of the extension.
You tell Joomla the URL of the XML file for your extension within the manifest file (helloworld.xml), eg</translate>

<source lang="xml">
<updateservers>
<server type="extension" name="Helloworld Updates">http://myDeveloperSite/helloworld-updates/updates.xml</server>
</updateservers>
</source>

<translate>

Below is a basic update XML file </translate>

<source lang="xml">
<updates>
<update>
<name>Helloworld component</name>
<description>Helloworld component for Joomla MVC tutorial</description>
<element>com_helloworld</element>
<type>component</type>
<version>1.0.0</version>
<client>site</client>
<downloads>
<downloadurl type="full" format="zip">http://myDeveloperSite/helloworld-updates/helloworld-1-0-0.zip</downloadurl>
</downloads>
<targetplatform name="joomla" version="3.[23456789]" />
<php_minimum>7.1</php_minimum>
</update>
</updates>
</source>

<translate>

Note that it has
* basic information about the component – eg name, version
* a link to the zip file for that update
* restrictions – for Joomla versions 3.2 to 3.9 only, and at least PHP version 7.1 </translate>
<translate>

Whenever an administrator clicks on the Find Updates button, Joomla sends HTTP requests to each of the URLs of these update servers to retrieve the XML files. It parses each XML file,
# ensures it's properly formed XML
# compares the version of the update with the version of the extension currently running
# checks any restrictions (Joomla versions, PHP versions, database versions) with what is currently running.</translate>
<translate>

If it finds it's a valid update for this website, then it inserts a record into the "updates" table in the database. (You'll find at most 1 update for each extension, because if there are several possible then Joomla will store only the most recent valid version, ie with the highest version number).</translate>

<translate>
=== Installing Updates === </translate>
<translate>

Once an update has been inserted into the "updates" table it is visible to the administrator in the Extension / Manage / Update page. After checking the checkbox and clicking the Update button Joomla will
* once again send an HTTP request to the URL of the update XML file
* parse the XML file and ensure that conditions for installing that version are still met
* send an HTTP request to the URL of the update zip file, storing the file received in the HTTP response in its /tmp directory
* proceed to install the new version from the downloaded zip file.</translate>

<translate>
== Approach == </translate>
<translate>

In this tutorial step we will update our helloworld extension to use an update server.</translate>
<translate>

We'll also set up the server files so that you can verify that the update process works ok.</translate>
<translate>

To do this you'll need to configure part of your development area to act as the update server. This basically means creating a directory below the root directory serviced by your web server, and including the update XML file etc in it.</translate>
<translate>

For example, I have a folder <tt>/helloworld</tt> which contains my Joomla instance, so that to access the site I put the URL <tt>http://localhost/helloworld/index.php</tt> into the browser.</translate>
<translate>

For the update server I created a folder <tt>/helloworld-updates</tt> at the same level as <tt>/helloworld</tt>, and put the <tt>updates.xml</tt> file into that folder. I can then access the XML file by putting the URL <tt>http://localhost/helloworld-updates/updates.xml</tt> into the browser.</translate>
<translate>

You'll need to do something similar in your own environment, and verify that the URL is correct by accessing the XML file through your browser.</translate>

<translate>
== Updated Code == </translate>
<translate>

The only change we need to make to our helloworld component is to include the update server inside the manifest file. Once updated, zip up the component as usual and install it on your Joomla instance. </translate>

<span id="helloworld.xml">
<tt>helloworld.xml</tt>
<source lang="xml" highlight="13,100-103">
<?xml version="1.0" encoding="utf-8"?>
<extension type="component" version="3.0" method="upgrade">

<name>COM_HELLOWORLD</name>

<creationDate>January 2018</creationDate>
<author>John Doe</author>
<authorEmail>john.doe@example.org</authorEmail>
<authorUrl>http://www.example.org</authorUrl>
<copyright>Copyright Info</copyright>
<license>License Info</license>

<version>0.0.33</version>

<description>COM_HELLOWORLD_DESCRIPTION</description>


<scriptfile>script.php</scriptfile>

<install> 
<sql>
<file driver="mysql" charset="utf8">sql/install.mysql.utf8.sql</file>
</sql>
</install>
<uninstall> 
<sql>
<file driver="mysql" charset="utf8">sql/uninstall.mysql.utf8.sql</file>
</sql>
</uninstall>
<update> 
<schemas>
<schemapath type="mysql">sql/updates/mysql</schemapath>
</schemas>
</update>



<files folder="site">
<filename>index.html</filename>
<filename>helloworld.php</filename>
<filename>controller.php</filename>
<filename>router.php</filename>
<folder>controllers</folder>
<folder>views</folder>
<folder>models</folder>
<folder>helpers</folder>
</files>

<languages folder="site/language">
<language tag="en-GB">en-GB/en-GB.com_helloworld.ini</language>
<language tag="fr-FR">fr-FR/fr-FR.com_helloworld.ini</language>
</languages>

<media destination="com_helloworld" folder="media">
<filename>index.html</filename>
<folder>images</folder>
<folder>js</folder>
<folder>css</folder>
</media>

<administration>

<menu link='index.php?option=com_helloworld' img="../media/com_helloworld/images/tux-16x16.png">COM_HELLOWORLD_MENU</menu>


<files folder="admin">

<filename>index.html</filename>
<filename>config.xml</filename>
<filename>helloworld.php</filename>
<filename>controller.php</filename>
<filename>access.xml</filename>

<folder>sql</folder>

<folder>tables</folder>

<folder>models</folder>

<folder>views</folder>

<folder>controllers</folder>

<folder>helpers</folder>

<folder>layouts</folder>
</files>
<languages folder="admin/language">
<language tag="en-GB">en-GB/en-GB.com_helloworld.ini</language>
<language tag="en-GB">en-GB/en-GB.com_helloworld.sys.ini</language>
<language tag="fr-FR">fr-FR/fr-FR.com_helloworld.ini</language>
<language tag="fr-FR">fr-FR/fr-FR.com_helloworld.sys.ini</language>
</languages>
</administration>

<updateservers>

<server type="extension" name="Helloworld Updates">http://localhost/helloworld-updates/updates.xml</server>
</updateservers>
</extension>
</source>
</span>

<translate>
== Update Server Files == </translate>
<translate>

We're going to put 3 files into the directory which we're using to act as the update server, ie into the /helloworld-updates folder, or wherever you have decided to use. The 3 files are:
# the updates.xml file
# an html file which is an information file for the latest version
# a zip file for the update.
For security purposes you should also add the usual blank index.html file as well.</translate>
<translate>

The updates.xml file is below. You should change the infourl and downloadurl to suit your environment, and set values for the targetplatform, php_minimum and supported_databases as you wish.</translate>

<source lang="xml">
<updates>
<update>
<name>Helloworld component</name>
<description>Helloworld component for Joomla MVC tutorial</description>
<element>com_helloworld</element>
<type>component</type>
<version>1.0.0</version>
<client>site</client>
<infourl>http://localhost/helloworld-updates/info-1-0-0.html</infourl>
<downloads>
<downloadurl type="full" format="zip">http://localhost/helloworld-updates/helloworld-1-0-0.zip</downloadurl>
</downloads>
<tags>
<tag>stable</tag>
</tags>
<targetplatform name="joomla" version="3.[23456789]" />
<php_minimum>5.3</php_minimum>
<supported_databases mysql="5.6.19"></supported_databases>
</update>
</updates>
</source>
<translate>

You can find definitions of the elements of this XML structure at [[Deploying an Update Server]], but note that the attributes min_dev_level and max_dev_level are marked as deprecated in the current (3.9) Joomla code, to be removed in Joomla 4.</translate>
<translate>

The information file is just a basic html document, which you can modify as you wish. Its filename must match what is specified in the <tt><infourl></tt> tag above.</translate>

<source lang="html">
<!DOCTYPE html>
<html>
<head>
<title>Helloworld update</title>
</head>
<body>
<h1>Update to version 1.0.0</h1>
</body>
</html>
</source>

<translate>

Finally create a store a zip file for the new version. As a minimum you need to update the version in the manifest file, and you may wish to make another change which is visible when you visit the site.
# Update the manifest file (helloworld.xml) to set the version line to <version>1.0.0</version>
# Create a zip file of the helloworld component
# Copy the zip file into your update server directory. Its name must match what is specified in the <downloadurl> tag (helloworld-1-0-0.zip above).</translate>

<translate>
== Testing the Update Server == </translate>
<translate>

To test your update server do the following:
# log in to the backend of your site using an admin account
# go to Extensions / Manage / Update
# click on Find Updates – your helloworld component should appear as an update. (It may already be shown, because when you display the admin control panel it issues an ajax request which initiates the find updates process).
# click on the checkbox next to the helloworld component, and click on Update
# go to Extensions / Manage / Manage and find the helloworld component. Its version should now be 1.0.0 (or whatever version you updated to).</translate>
<translate>

(For info, using phpmyadmin you can change the existing version number of the helloworld component by finding the appropriate record in the extensions table, and updating the version number within the json string in the manifest_cache field.)</translate>

<translate>
== Collections type == </translate>
<translate>

Up to now we've been considering the server type="extension", but Joomla also has a server type="collection". The purpose of this type is to allow you to have a collection of different update XML files. You would use a "collection" type if, for example,
# your extension is a package and you want to allow users to update the package components individually
# you want to have different update XML files for different versions of Joomla.</translate>
<translate>

Joomla languages use a collection type. If you have several languages installed and go to Extensions / Manage / Update Sites then you can see that all the languages have the same update site URL pointing to something like https://update.joomla.org/language/translationlist_3.xml . If you open that XML file then you see all the details URLs which are the update XML files of the individual languages, and which can be installed via the Extensions / Manage / Install Languages page.</translate>

<translate>

Joomla core also uses a collection type. If you go to Update Sites and click on the XML file for Joomla! Core then you will see different update XML files depending upon whether the installed version of Joomla is 2.x or 3.x.</translate>
<translate>

If you wish to try using a collection type, then this is still possible with a single update XML file, by following the steps below.</translate>
<translate>

Firstly delete manually (using phpmyadmin) the records in the database tables update_sites and update_sites_extensions which relate to the helloworld component. Then go into Extensions / Manage / Update and click on Clear Cache. This should have removed all trace of the type="extension" update mechanism.</translate>
<translate>

Secondly replace the updateservers section of the manifest file with the following (changing the URL appropriately)</translate>
<source lang="xml">
<updateservers>
<server type="collection" name="Helloworld Updates">http://localhost/helloworld-updates/list.xml</server>
</updateservers>
</source>
<translate>

Zip up the component and install it in the usual way. (Remember, when you install it in this way the version number in the new install file doesn't need to be greater than the version of the one currently installed).</translate>
<translate>

Thirdly create a list.xml file which points to the update XML file, and store this in your update server folder. Once again, change the URL and version to match your own situation, making sure that the version quoted in the file is greater than the one currently installed.</translate>
<source lang="xml">
<extensionset name="Helloworld Update Collection" description="Helloworld Update as Collection">
<extension name="Helloworld Component" element="com_helloworld" type="component" client="administrator" version="1.0.0" targetplatformversion="3.[23456789]" detailsurl="http://localhost/helloworld-updates/updates.xml"/>
</extensionset>
</source>
<translate>

If you test the update process as above you should find it works just the same. However, note that in this case the updates.xml file is not processed during the Find Updates process, so if you have an incompatible minimum value of PHP say, then it won't report it at that stage.</translate>

<translate>
== Contributors == </translate>
*[[User:Robbiej|Robbie Jackson]]

<div class="row">
<div class="large-6 columns">{{Basic button|S:MyLanguage/J3.x:Developing_an_MVC_Component/Adding a Feed|<translate> Prev: Adding a Feed</translate>|class=expand success}}</div>
<div class="large-6 columns">{{Basic button|
S:MyLanguage/J3.x:Developing_an_MVC_Component/Adding_Custom_Fields|<translate> Next: Adding Custom Fields</translate>|class=expand}}</div>
</div>

__NOTOC__
<noinclude>
<translate>

[[Category:Joomla! 3.x{{#translation:}}]]
[[Category:Joomla! 3.0{{#translation:}}]]
[[Category:Joomla! 3.1{{#translation:}}]]
[[Category:Joomla! 3.2{{#translation:}}]]
[[Category:Joomla! 3.3{{#translation:}}]]
[[Category:Joomla! 3.4{{#translation:}}]]
[[Category:Joomla! 3.5{{#translation:}}]]
[[Category:Joomla! 3.6{{#translation:}}]]
[[Category:Joomla! 3.7{{#translation:}}]]
[[Category:Joomla! 3.8{{#translation:}}]]
[[Category:Joomla! 3.9{{#translation:}}]]
[[Category:Beginner Development{{#translation:}}]]
[[Category:Component Development{{#translation:}}]]
[[Category:Tutorials{{#translation:}}]]
[[Category:Tutorials in a Series{{#translation:}}]]
</translate>
</noinclude>

J3.x:Access Control List Tutorial

2019-12-26T20:41:25Z

Sieger66:

<noinclude><languages /></noinclude>
{{Joomla version|version=3.x|comment=<translate>
series</translate>}}
{{-}}
<translate>==Separate ACL for Viewing and Doing== </translate>

<translate>
The Joomla ACL system can be thought of as being divided into two completely separate systems. One system controls what things on the site users can ''view''. The other controls what things users can ''do'' (what actions a user can take). The ACL for each is set up differently.</translate>

<translate>===Controlling What Users Can See=== </translate>

<translate>
The setup for controlling what users can see is done as follows:
* Create a set of Access Levels according to the Categories and/or the combination of categories you wish only logged in users to see. N.B do not assign any user groups to the new Access Levels at this point.</translate>

<translate>
* Create a User Group, with 'Registered' as parent, for each Access Level. Using the same names for the User Groups as the Access Levels will prevent confusion later.</translate>

<translate>
* Edit your new Access Levels and assign the correct (new)User Group to each one. You may also wish to assign the Super User Group(and/or the other default User Groups but not 'Guest' User Group) to all your new Access Levels</translate>

<translate>
* Assign each item to be viewed to one Access Level. Items include content items (articles, contacts, and so on), menu items, and modules.</translate>

<translate>
Any time a user is about to view an item on a Joomla page, the program checks whether the user has access to the item, as follows:</translate>
<translate>
# Creates a list of all the Access Levels that the User has access to, based on all Groups that the User belongs to. Also, if a group has a parent group, access levels for the parent group are also included in the list.</translate>
<translate>
# Checks whether the Access Level for the item (article, module, menu item, and so on) is on that list. If yes, then the item is displayed to the user. If no, then the item is not displayed.</translate>

<translate>
Note that Access Levels are set separately for each Group and are not inherited from a group's parent group.</translate>

<translate>===Controlling What Users Can Do=== </translate>

<translate>
The system for setting up what users in a User Group can do -- what actions they can take on a given item -- is set up with the Permissions tab of Global Configuration and the Permissions tab of the Options screen of each component. Permissions can also be set up at the Category level for core components and at the Article level for articles.</translate>

<translate>
* If you wish logged in users to Create, Delete, Edit State or Edit Own for specific Categories then:</translate>
<translate>
** Create a User Group with the Parent as one of your User Groups that has Access to the Category(or Categories) you wish this new User Group to modify.</translate>
<translate>
**Assign your new User Group to the appropriate Access Level(s). Then change the required permissions for your new user Group either Globally or per Category/Article.</translate>
<translate>
***When creating a User Group it is good practice to select a parent group that has less permissions than needed for the new group. This is because it is easier to elevate permissions per Component/Category/Article that the extra permissions are needed for than it is to remove permissions from the other Components/Categories/Articles.</translate>
<translate>
****''(example: You have 10 Categories but you want Create permissions for just 1. If you set Global permissions to Allow Create for that group you would need to remove Create permission for all those categories. And you would need to remove the Create permission for that group with any new Category that you add at a later date.)''</translate>
<translate>
**Only create a User Group with one of the default User Groups as parent if none of them have the exact permissions that you need and you wish all Categories</translate>

<translate>
Note that this set up is independent of the setup for viewing but a User Group needs to be assigned to the appropriate Access Level(s) in order for the user in that Group to use those Permissions.</translate>

<translate>
When a user wants to initiate a specific action against a component item (for example, edit an article), the system (after checking the Group the user is in has access) checks the permission for this combination of user, item, and action. If it is allowed, then the user can proceed. Otherwise, the action is not allowed.</translate>

<translate>
The remainder of this tutorial discusses how we control what users can do -- what action permissions they have.</translate>

<translate>==Actions, Groups, and Inheritance== </translate>

<translate>
The other side of ACL is granting permissions to users to take actions on objects.</translate>

{| class="wikitable"
!style="width:20%;"|
!<translate>
3.x series</translate>
|-
!<translate>
Groups and Actions</translate>
|<translate>
Actions allowed for each group are defined by site administrator.</translate>
|-
!<translate>
Permission Scope</translate>
|<translate>
Permissions can be set at multiple levels in hierarchy: Site, Component, Category, Object.</translate>
|-
!<translate>
Permission Inheritance</translate>
|<translate>
Permissions can be inherited from parent Groups and parent Categories</translate>
|}

<translate>===How Permissions Work=== </translate>

<translate>
There are four possible permissions for actions, as outlined below:</translate>

<translate>
* '''Not set''': Defaults to "deny" but, unlike the Deny permission, this permission can be overridden by setting a child group or a lower level in the permission hierarchy to "Allow". This permission only applies to the Global Configuration permissions.</translate>
<translate>
* '''Inherit''': Inherits the value from a parent Group or from a higher level in the permission hierarchy. This permission applies to all levels except the Global Configuration level.</translate>
<translate>
* '''Deny''': Denies this action for this level and group. '''IMPORTANT:''' This also denies this action for all child groups and all lower levels in the permission hierarchy. Putting in Allow for a child group or a lower level will not have any effect. The action will always be denied for any child group member and for any lower level in the permission hierarchy.</translate>
<translate>
* '''Allow''': Allows this action for this level and group and for lower levels and child groups. This does not have any effect if a higher group or level is set to Deny or Allow. If a higher group or level is set to Deny, then this permission will always be denied. If a higher group or level is set to Allow, then this permission will already be allowed.</translate>

<translate>===Permission Hierarchy Levels=== </translate>

<translate>
Action permissions in version 2.5+ can be defined at up to four levels, as follows:</translate>
<translate>
# '''Global Configuration''': determines the default permissions for each action and group.</translate>
<translate>
# '''Component Options->Permissions''': can override the default permissions for this component (for example, Articles, Menus, Users, Banners, and so on).</translate>
<translate>
# '''Category''': can override the default permissions for objects in one or more categories. Applies to all components with categories, including Articles, Banners, Contacts, Newsfeeds, and Weblinks.</translate>
<translate>
# '''Article''': Can override the permissions for a specific article. This level only applies to articles. Other components only allow the first three levels.</translate>

<translate>====Global Configuration==== 
This is accessed from System → Global Configuration → Permissions. This screen allows you set the top-level permission for each group for each action, as shown in the screenshot below.</translate>

[[Image:Screenshot_global_acl_J3_tutorial-<translate>
en</translate>.png]]

<translate>
The options for each value are Inherited, Allowed, or Denied. The Calculated Setting column shows you the setting in effect. It is either Not Allowed (the default), Allowed, or Denied.</translate>

<translate>
You work on one Group at a time by opening the slider for that group. You change the permissions in the Select New Settings drop-down list boxes.</translate>

<translate>
Note that the Calculated Setting column is not updated until you press the Save button in the toolbar. To check that the settings are what you want, press the Save button and check the Calculated Settings column.</translate>

<translate>====Component Options->Permissions==== </translate>
<translate>
This is accessed for each component by clicking the Options icon in the toolbar. This screen is similar to the Global Configuration screen above. For example, clicking the Options toolbar icon in the Menu Manager shows the Menus Configuration below.</translate>
[[Image:Screenshot_menu_acl_J3_tutorial-<translate>
en</translate>.jpg]]

<translate>
Access to Options is only available to members of groups who have permission for the Configure action in for each component. In the example above, the Administrator group has Allowed permission for the Configure option, so members of this group can access this screen.</translate>

<translate>====Category==== 
Category permissions are accessed in the Category Manager: Edit Category screen, in a tab at the top of the screen. This screen has five permissions, as shown below.</translate>

[[Image:Screenshot_category_acl_j3_tutorial-<translate>
en</translate>.png]]

<translate>
In these screens, you work on the permissions for one User Group at a time. In the example above, we are editing the permissions for the Administrator group.</translate>

<translate>
Note that the Configure and Access Component actions do not apply at the category level, so those actions are not included.</translate>

<translate>
Note also that Categories can be arranged in a hierarchy. If so, then action permissions in a parent category are inherited automatically by a child category. For example, if you had a category hierarchy of Animals → Pets → Dogs, then the full permission level hierarchy for an article in the Dogs category would be as follows:</translate>
<translate>
* Global Configuration
* Article Manager → Options → Permission
* Animals Category
* Pets Category
* Dogs Category
* specific article</translate>

<translate>====Article==== </translate>
<translate>
Permissions for a single article are access in the Article Manager: Edit Article screen, again in a slider at the bottom of the screen. This screen has three actions, as shown below.</translate>

[[Image:j3x_acl_tutorial_article_manager_article_permissions-<translate>
en</translate>.png]]

<translate>
Again, you edit each group by clicking on it to open the slider for that group. You can then change the permissions under the Select New Setting column. To see the effect of any changes, press the Save button to update the Calculated Setting column.</translate>

<translate>
Note that the Configure, Access Component, and Create actions do not apply at the article level, so these actions are not included. Permission to create an article is set at one of the higher levels in the hierarchy.</translate>

<translate>===Access Levels=== </translate>

<translate>
Access Levels in 3.x series are simple and flexible. The screen below shows the Special Access Level.</translate>
[[Image:j3x_acl_tutorial_viewing_levels-<translate>
en</translate>.png|center]]
<translate>
Simply check the box for each group you want included in that level. The Special Access Level includes the Manager, Author, and Super Users groups. It also includes child groups of those groups. So, Administrator group is included, since it is a child group of the Manager group. The Editor, Publisher, and Shop Suppliers groups are included, since they are child groups of Author. (Note that we could check all of the child groups if we wanted and it wouldn't hurt anything).</translate>

<translate>
Once Access Levels are created, they are used in the same way as in version 1.5. Each object in the front end is assigned an Access Level. If the level is Public, then anyone may access that object. Otherwise, only members of groups assigned to that access level may access that object. Access levels are assigned to Menu Items and to Modules. Each one can only be assigned to one access level.</translate>

<translate>
For example, the screen below shows the Edit Menu Item screen with the list of available access levels.</translate>

[[Image:j3x_acl_tutorial_edit_menu_item_level_dropdown-<translate>
en</translate>.png|center]]

<translate>==Default ACL Setup== </translate>

<translate>
When Joomla! is installed, these are set to their initial default settings. We will discuss these initial settings as a way to understand how the ACL works.</translate>

<translate>===Default Groups=== </translate>

<translate>
Version 3.x allows you to define your own Groups. When you install version 3.x, it includes a set of default groups, shown below are the basic default user groups. (Additional default user groups are installed with sample data)</translate>

[[Image:Screenshot_usergroupsl_acl_J3_tutorial-<translate>
en</translate>.png|center]]

<translate>
The arrows indicate the child-parent relationships. As discussed above, when you set a permission for a parent group, this permission is automatically inherited by all child groups. The Inherited, and Allowed permissions can be overridden for a child group. The Denied permission cannot be overridden and will always deny an action for all child groups.</translate>

<translate>===Global Configuration=== </translate>

<translate>
Joomla! version 2.5 will install with the same familiar back-end permissions as that of version 1.5. However, with 2.5, you can easily change these to suit the needs of your site.</translate>

<translate>
As discussed earlier, the permissions for each action are inherited from the level above in the permission hierarchy and from a group's parent group. Let's see how this works. The top level for this is the entire site. This is set up in the Site->Global Configuration->Permissions, as shown below.</translate>

[[Image:Screenshot_global_acl_J3_tutorial-<translate>
en</translate>.png]]

<translate>
The first thing to notice are the ten Actions: Site Login, Admin Login, Offline Access, Super User, Access Administration Interface, Create, Delete, Edit, Edit State. and Edit Own. These are the actions that a user can perform on an object in Joomla. The specific meaning of each action depends on the context. For the Global Configuration screen, they are defined as follows:</translate>

<translate>
;Site Login : Login to the front end of the site


;Admin Login : Login to the back end of the site</translate>

<translate>
;Offline Access : Login to the front end of the site when the website site is offline (when Global Configuration setting "Site Offline" is set to Yes)</translate>

<translate>
; Super User : Grants the user "super user" status. Users with this permission can do anything on the site. Only users with this permission can change Global Configuration settings (this screen). These permissions cannot be restricted. It is important to understand that, if a user is a member of a Super Admin group, any other permissions assigned to this user are irrelevant. The user can do any action on the site. However, Access Levels can still be assigned to control what this group sees on the site. (Obviously, a Super Admin user can change Access Levels if they want to, so Access Levels do not totally restrict what a Super Admin user can see.)</translate>

<translate>
;Access Component: Open the component manager screens (User Manager, Menu Manager, Article Manager, and so on)</translate>

<translate>
;Create : Create new objects (for example, users, menu items, articles, weblinks, and so on)</translate>

<translate>
;Delete : Delete existing objects</translate>

<translate>
;Edit : Edit existing objects</translate>

<translate>
;Edit State : Change object state (Publish, Unpublish, Archive, and Trash)</translate>

<translate>
;Edit Own : Edit objects that you have created.</translate>

<translate>
Each Group for the site has its own slider which is opened by clicking on the group name. In this case (with the sample data installed), we have the standard 7 groups that we had in version 1.5 plus two additional groups called "Shop Suppliers" and "Customer Group". Notice that our groups are set up with the same permissions as they had in version 1.5. Keep in mind that we can change any of these permissions to make the security work the way we want. Let's go through this to see how it works.</translate>

<translate>
* '''Public''' has everything set to "Not set", as shown below.</translate>{{-}}[[Image:Screenshot_global_acl_public_J3_tutorial-<translate>
en</translate>.png]]
<translate>
**This can be a bit confusing. Basically, "Not Set" is the same as "Inherited". Because Public is our top-level group, and because Global Configuration is the top level of the component hierarchy, there is nothing to inherit from. So "Not Set" is used instead of "Inherit".</translate>
<translate>
**The default in this case is for no permissions. So, as you would expect, the Public group has no special permissions. Also, it is important to note that, since nothing is set to Denied, all of these permissions may be overridden by child groups or by lower levels in the permission hierarchy.</translate>

<translate>
* '''Guest''' is a 'child' group of the Public group has everything set to 'Inherited'</translate> {{-}}[[Image:Screenshot_global_acl_guest_J3_tutorial-<translate>
en</translate>.png]]
<translate>
** This is the default 'Guest User Group' in the User Manager options and the Group that (non logged in) visitors to your site are placed in.</translate>

<translate>
* '''Manager''' is a "child" group of the Public group. It has Allowed permissions for everything except Access Component and Super Admin. So a member of this group can do everything in the front and back end of the site except change Global Permissions and Component Options.</translate> {{-}}[[Image:Screenshot_global_acl_manager_J3_tutorial-<translate>
en</translate>.png]]

<translate>
* '''Administrator''' group members inherit all of the Manager permissions and also have Allowed for Access Component. So members of this group by default can access the Options screens for each component.</translate> {{-}}[[Image:Screenshot_global_acl_administrator_J3_tutorial-<translate>
en</translate>.png]]

<translate>
* '''Registered''' is the same a Public except for the Allow permission for the Site Login action. This means that members of the Registered group can login to the site. Since default permissions are inherited, this means that, unless a child group overrides this permission, all child groups of the Registered group will be able to login as well.</translate> {{-}}[[Image:Screenshot_global_acl_registered_J3_tutorial-<translate>
en</translate>.png]]

<translate>
* '''Author''' is a child of the Registered group and inherits its permissions and also adds Create and Edit Own. Since Author, Editor, and Publisher have no back-end permissions, we will discuss them below, when we discuss front-end permissions.</translate>{{-}}[[Image:Screenshot_global_acl_author_J3_tutorial-<translate>
en</translate>.png]]

<translate>
* '''Editor''' is a child of the Authors group and adds the Edit permission.</translate> {{-}}[[Image:Screenshot_global_acl_editor_J3_tutorial-<translate>
en</translate>.png]]

<translate>
* '''Publisher''' is a child of Editor and adds the Edit State permission.</translate>{{-}}[[Image:Screenshot_global_acl_publisher_J3_tutorial-<translate>
en</translate>.png]]

<translate>
* '''Shop Suppliers''' is an example group that is installed if you install the sample data. It is a child group of Author.</translate>

<translate>
* '''Customer Group''' is an example group that is installed if you install the sample data. It is a child group of Registered.</translate>

<translate>
* '''Super Users''' group has the Allow permission for the Super Admin action. Because of this, members of this group have super user permissions throughout the site. They are the only users who can access and edit values on the Global Configuration screen. Users with permission for the Super Admin action have some special characteristics:</translate>
<translate>
:* If a user has Super Admin permissions, no other permissions for this user matter. The user can perform any action on the site.</translate>
<translate>
:* Only Super Admin users can create, edit, or delete other Super Admin users or groups.</translate>

<translate>
There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.</translate>

<translate>
This provides a lot of flexibility. For example, if you wanted Shop Suppliers to be able to have the ability to login to the back end, you could just change their Admin Login value to "Allowed". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherited (or Denied).</translate>

<translate>
It is also important to understand that the ability to have child groups is completely optional. It allows you to save some time when setting up new groups. However, if you like, you can set up all groups to have Public as the parent and not inherit any permissions from a parent group.</translate>

<translate>===Component Options & Permissions=== </translate>

<translate>
Now, let's continue to see how the default back-end permissions for version 2.5 mimic the permissions for version 1.5. The Super Users group in 2.5 is equivalent to the Super Administrator group in 1.5.</translate>

<translate>
Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 2.5 configuration. Let's see how this is accomplished.</translate>

<translate>
If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:</translate>

[[Image:screenshot_acl_tutorial_20110111-09-<translate>
en</translate>.png|center|]]
[[Image:screenshot_acl_tutorial_20110111-10-<translate>
en</translate>.png|center|]]

<translate>
This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.</translate>

<translate>
First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.</translate>

<translate>
Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.</translate>

<translate>
If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.</translate>

<translate>
In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.</translate>

<translate>
It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.</translate>

<translate>===Front End Permissions=== </translate>

<translate>
Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions. First, let's look at the permissions for Manager, as shown below.</translate>
[[Image:screenshot_acl_tutorial_20110111-11a-<translate>
en</translate>.png|center|frame]]
<translate>
Manager has allowed permission for all actions except Configure. So members of the Manager group can do everything with Articles except open the Options screen.</translate>

<translate>
Now let's look at Administrator, as shown below.</translate>
[[Image:screenshot_acl_tutorial_20110111-12a-<translate>
en</translate>.png|center|frame]]
<translate>
Administrator has Allowed for Configure, so Administrators can edit this Options screen.</translate>

<translate>
Both groups can create, delete, edit, and change the state of articles.</translate>

<translate>
Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set.</translate>

<translate>
Authors only have Create and Edit Own permissions, as shown below.</translate>
[[Image:screenshot_acl_tutorial_20110112-07-<translate>
en</translate>.png|center|frame]]
<translate>
This means that Authors can create articles and can edit articles they have created. They may not delete articles, change the published state of articles, or edit articles created by others.</translate>

<translate>
Editors have the same permissions as Authors with the addition of permission for the Edit action, as shown below.</translate>
[[Image:screenshot_acl_tutorial_20110112-08-<translate>
en</translate>.png|center|frame]]
<translate>
So Editors can edit articles written by anyone.</translate>

<translate>
Publishers can do everything Editors can do plus they have permission for the Edit State action, as shown below.</translate>
[[Image:screenshot_acl_tutorial_20110112-09-<translate>
en</translate>.png|center|frame]]
<translate>
So Publishers can change the published state of an article. The possible states include Published, Unpublished, Archived, and Trashed.</translate>

<translate>
All of these groups have Inherit permission for Configure and Access Component. Remember that Author is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Configure and Access Component, and since Author's permission for these actions is "Inherited", then Author does not have these permissions either. This same permission is passed from Author to Editor and from Editor to Publisher. So, by default, none of these groups are allowed to work with articles in the back end.</translate>

<translate>
It is important to remember that these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.</translate>

<translate>
Also, note that there are no Denied permissions for any actions in the default settings. This allows you to add Allowed permissions at any level. Remember, once you have an action set for Denied, this action will be denied at all lower levels in the hierarchy. For example, if you set the Admin Login for Registered to Denied (instead of Allowed), you could not grant Publishers Allowed permissions for this action.</translate>

<translate>=== Article Manager & Actions Diagram === </translate>

<translate>
The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.</translate>

[[Image:screenshot_acl_tutorial_20110111-16-<translate>
en</translate>.png|center|]]

<translate>
* '''Configure''' allows you to view and change the Options for the component.</translate>
<translate>
* '''Access Component''' allows you to navigate to the Article Manager. Without this permission, no other actions are possible.</translate>
<translate>
* '''Create''' allows you to add new articles.</translate>
<translate>
* '''Delete''' allows you to delete trashed articles. Note that the Delete icon only shows in the toolbar when you have the "Select State" filter set to "Trash".</translate>
<translate>
* '''Edit''' allows you to edit existing articles.</translate>
<translate>
* '''Edit State''' allows to you Publish, Unpublish, Archive, or Trash articles.</translate>
<translate>
* '''Edit Own''' is the same as Edit except that it only applies to articles written by you.</translate>

<translate>==Allowing Guest-Only Access to Menu Items and Modules== </translate>

<translate>
Version 1.6 introduced the ability to create a View Access Level that is only for guests of the site (meaning a user who is not logged in). The example below shows how you can set up this new feature.
''(N.B. Steps 1 to 3 are not needed for Joomla! 3.x as they exist in the default install)''</translate>

<translate>
#Create a new user group called Guest. Make it a child of the Public group as shown below.</translate> [[Image:screenshot_acl_tutorial_20110112-01-<translate>
en</translate>.png|center|frame]]
<translate>
# Create a new access level called Guest and grant only the Guest group access to this level, as shown below.</translate>[[Image:screenshot_acl_tutorial_20110112-02-<translate>
en</translate>.png|center|frame]]
<translate>
# Navigate to User Manager→Options→Component and change the Guest User Group from the default value of "Public" to "Guest", as shown below.</translate>
[[Image:screenshot_acl_tutorial_20110112-04-<translate>
en</translate>.png|center|frame]]
<translate>
Now, if we assign a menu item, module, or other object to the Guest access level, only non-logged in users will have access. For example, if we create a new menu item with access level of Guest, as shown below,</translate>
[[Image:screenshot_acl_tutorial_20110112-05-<translate>
en</translate>.png|center|frame]]
<translate>
this menu item will only be visible to non-logged-in visitors to the site.</translate>

<translate>
If required other user groups like Author can be granted access in the Guest access level, this would allow Authors to view articles in the front end for editing.</translate>

<translate>
'''N.B. Login/logout in front end (''for changing data in session'') to see the change.'''</translate>

<translate>==Using Permission and Group Levels Together== </translate>

<translate>
As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.</translate>

<translate>
This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:</translate>

<translate>
* both groups can create new articles only in the History Assignments category.</translate>

<translate>
* only History Teachers (not Assistant History Teachers) can Publish or otherwise have Edit State permission.</translate>

<translate>
This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.</translate>

[[Image:Acl example diagram1 20091018-<translate>
en</translate>.png|center|]]

<translate>
In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.</translate>

<translate>
To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.</translate>

<translate>
Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.</translate>

[[Image:Acl example diagram2 20091018-<translate>
en</translate>.png|center|]]

<translate>
This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.</translate>

<translate>
Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.</translate>

<translate>==ACL Action Permission Examples== 
Here are some examples of how you might set up the ACL for some specific situations.</translate>

<translate>===Back-end Article Administrator=== </translate>

<translate>
'''Problem:'''</translate>

<translate>
We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.</translate>

<translate>
'''Solution:'''</translate>

<translate>
# Create a new group called Article Administrator and make its parent group Public, as shown below.</translate>[[Image:screenshot_acl_tutorial_20110112-10-<translate>
en</translate>.png|center|frame]] <translate>
Because its parent group is Public, it won't have any permissions by default.</translate>
<translate>
# In Users → Access Levels, edit the Special Access level to add the new group. That way they can get access to the back end menu items and modules (This assumes that the modules for the admin menu and quickicons have the Special Access level assigned to them, which is the default.)</translate> [[Image:screenshot_acl_tutorial_20110112-11-<translate>
en</translate>.png|center|frame]] <translate>
By default, the back-end menu items and modules are set to Special access, so if you forget to add the new group to the Special access level, you won't see any modules or menu items when you log in as a user of the new group.</translate>
<translate>
# In Site → Global Configuration → Permissions, click on the Article Administrator group and change the permissions to Allowed for the following actions: Admin Login, Create, Delete, Edit, Edit State, and Edit Own. The screen below shows what will show before you press Save.</translate> [[Image:screenshot_acl_tutorial_20110112-12-<translate>
en</translate>.png|center|frame]]<translate>
After you save, the Calculated Permissions should show as shown below.</translate>[[Image:screenshot_acl_tutorial_20110112-13-<translate>
en</translate>.png|center|frame]]<translate>
Note that the permission for the Access Component is Inherited, which translates to Not Allowed. This is important. This means that this group will only be able to access components if we give the group "Allowed" permission for Access Component. So we only have to change the one component we want to give them access to and don't have to change any settings for the components where we don't want them to have access. If we had a case where we wanted to give a group access to everything except for one component, we could set the default to Allowed and then set the one component to Denied. Also note that we did not give the group Site Login permission, so users in this group will not be able to log into the front end. (If we wanted to allow that, we would just change the permission to Allowed for Site Login.)</translate>
<translate>
# In Article Manager → Options → Permissions, change permissions to Allowed for this group for the Access Component action, as shown below.</translate>[[Image:screenshot_acl_tutorial_20110112-14-<translate>
en</translate>.png|center|frame]]<translate>
All of the other desired permissions are inherited.</translate>

<translate>
That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end. For example, the screen below shows what a user in the Article Manager will see when they login to the back end.</translate>[[Image:screenshot_acl_tutorial_20110112-15-<translate>
en</translate>.png|center|frame]]

<translate>==ACL View Access Levels Examples== </translate>

<translate>
A basic concept of using Access Levels is that all items with the same Access will be viewable by the same group of users. In other words, if two items have the same Access, you can't have one viewable by one user and not viewable by another user. On the other hand, it is easy to have one Group view any number of items with different Access levels.</translate>

<translate>
Similarly, each Group has exactly the same combination of Access levels, but one User can be a member of more than one group. Depending on the situation, you may want to have users only in one Group or you may need to have a User in more than one Group.</translate>

<translate>
This means that we may need to group our items so that items so that all items in a group have the same level of sensitivity. Here are some examples.</translate>

<translate>===Hierarchical Example=== </translate>
<translate>
In this example, Access levels are hierarchical, for example, like government security clearance codes. Say for example we have the following sets of classified documents: Classified, Secret, and Top Secret. Users have corresponding clearence codes. Users with Classified clearance can only see Classified documents and cannot see Secret or Top Secret. Users with Secret clearance can see Classified and Secret documents but not Top Secret. Users with Top Secret can see all documents.</translate>

<translate>
In this case, you would create three Access levels: Classified, Secret, and Top Secret and the same three Groups. Users would only be members of one group, as follows:</translate>

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
User</translate>
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Group</translate>
| style="border:0.0007in solid #000000;padding:0.0382in;"| <translate>
Access Levels</translate>

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| C1, C2, C3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Classified</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| <translate>
Classified</translate>

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| S1, S2, S3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Secret</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| <translate>
Classified, Secret</translate>

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| TS1, TS2, TS3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Top Secret</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| <translate>
Classified, Secret, Top Secret</translate>

|}

<translate>
In this case, all users are in exactly one group, but some groups have access to more than one Access Level of items. In other words, we have a one-to-one relationship between users and groups, but a one-to-many relationship between Groups and Access Levels.</translate>

<translate>===Team Security Example=== </translate>

<translate>
Another possible use case is a set of non-hierarchical teams. Let's say we have three teams, T1, T2, and T3. Some users are only on one team, but others might be on two or more teams. In this case, we could set up our Access Levels and Groups by team. Documents for each team have the access level for that team, and the Group for the team has only the one access level. When a User is on more than one team, they get added to the group for each team, as follows:</translate>

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
User</translate>
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Description</translate>
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Group</translate>
| style="border:0.0007in solid #000000;padding:0.0382in;"| <translate>
Access Levels</translate>

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Team 1 member</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Team 2 member</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Team 3 member</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Member of teams 1 and 2</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Member of teams 1 and 3</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Member of teams 1,2, and 3</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1,T2, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2, T3

|}

<translate>===Hybrid Example=== </translate>

<translate>
In a real-world situation, you might have a combination of these two arrangements. Say for example we have Managers and Staff. Staff can only see Staff documents and Managers can see Manager and Staff documents. Both types of users can be assigned to teams as well, in which case they can see all of the documents for that team. In addition, say that Managers can access some, but not all, team documents. Staff can only access team documents if they are members of that team.</translate>

<translate>
In this example, we could set up the following Access Levels:</translate>

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Access Level</translate>
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Description</translate>
| style="border:0.0007in solid #000000;padding:0.0382in;"| <translate>
Groups</translate>

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Manager</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Non-team manager documents</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| <translate>
Manager</translate>

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Staff</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Non-team staff documents</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| <translate>
Manager, Staff</translate>

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Team1</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Sensitive Team1 documents (no access outside team)</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| <translate>
Team1</translate>

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Team1-Manager</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Team1 documents that can be accessed by all managers</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| <translate>
Team1, Manager</translate>

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Team2</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Sensitive Team2 documents (no access outside team)</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| <translate>
Team2</translate>

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Team2-Manager</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Team2 documents that can be accessed by all managers</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| <translate>
Team2, Manager</translate>

|}

<translate>
Then, users could be assigned to groups as follows:</translate>

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
User Type</translate>
| style="border:0.0007in solid #000000;padding:0.0382in;"| <translate>
Group</translate>

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Manager on no teams</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| <translate>
Manager</translate>

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Manager on team 1</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| <translate>
Manager, Team1</translate>

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Staff on team 1</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| <translate>
Staff, Team1</translate>

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Manager on teams 1 and 2</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| <translate>
Manager, Team1, Team2</translate>

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Staff on teams 1 and 2</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| <translate>
Staff, Team1, Team2</translate>

|}

<noinclude>
<translate>

[[Category:Joomla! 1.6]]
[[Category:Joomla! 2.5]]
[[Category:Joomla! 3.x]]
[[Category:Tutorials]]
[[Category:Access Control]]
[[Category:Access Management]]
</translate>
</noinclude>

J3.x:Access Control List Tutorial

2019-12-26T20:33:52Z

Sieger66:

<noinclude><languages /></noinclude>
{{Joomla version|version=3.x|comment=<translate>
series</translate>}}

<translate>==Separate ACL for Viewing and Doing== </translate>

<translate>
The Joomla ACL system can be thought of as being divided into two completely separate systems. One system controls what things on the site users can ''view''. The other controls what things users can ''do'' (what actions a user can take). The ACL for each is set up differently.</translate>

<translate>===Controlling What Users Can See=== </translate>

<translate>
The setup for controlling what users can see is done as follows:
* Create a set of Access Levels according to the Categories and/or the combination of categories you wish only logged in users to see. N.B do not assign any user groups to the new Access Levels at this point.</translate>

<translate>
* Create a User Group, with 'Registered' as parent, for each Access Level. Using the same names for the User Groups as the Access Levels will prevent confusion later.</translate>

<translate>
* Edit your new Access Levels and assign the correct (new)User Group to each one. You may also wish to assign the Super User Group(and/or the other default User Groups but not 'Guest' User Group) to all your new Access Levels</translate>

<translate>
* Assign each item to be viewed to one Access Level. Items include content items (articles, contacts, and so on), menu items, and modules.</translate>

<translate>
Any time a user is about to view an item on a Joomla page, the program checks whether the user has access to the item, as follows:</translate>
<translate>
# Creates a list of all the Access Levels that the User has access to, based on all Groups that the User belongs to. Also, if a group has a parent group, access levels for the parent group are also included in the list.</translate>
<translate>
# Checks whether the Access Level for the item (article, module, menu item, and so on) is on that list. If yes, then the item is displayed to the user. If no, then the item is not displayed.</translate>

<translate>
Note that Access Levels are set separately for each Group and are not inherited from a group's parent group.</translate>

<translate>===Controlling What Users Can Do=== </translate>

<translate>
The system for setting up what users in a User Group can do -- what actions they can take on a given item -- is set up with the Permissions tab of Global Configuration and the Permissions tab of the Options screen of each component. Permissions can also be set up at the Category level for core components and at the Article level for articles.</translate>

<translate>
* If you wish logged in users to Create, Delete, Edit State or Edit Own for specific Categories then:</translate>
<translate>
** Create a User Group with the Parent as one of your User Groups that has Access to the Category(or Categories) you wish this new User Group to modify.</translate>
<translate>
**Assign your new User Group to the appropriate Access Level(s). Then change the required permissions for your new user Group either Globally or per Category/Article.</translate>
<translate>
***When creating a User Group it is good practice to select a parent group that has less permissions than needed for the new group. This is because it is easier to elevate permissions per Component/Category/Article that the extra permissions are needed for than it is to remove permissions from the other Components/Categories/Articles.</translate>
<translate>
****''(example: You have 10 Categories but you want Create permissions for just 1. If you set Global permissions to Allow Create for that group you would need to remove Create permission for all those categories. And you would need to remove the Create permission for that group with any new Category that you add at a later date.)''</translate>
<translate>
**Only create a User Group with one of the default User Groups as parent if none of them have the exact permissions that you need and you wish all Categories</translate>

<translate>
Note that this set up is independent of the setup for viewing but a User Group needs to be assigned to the appropriate Access Level(s) in order for the user in that Group to use those Permissions.</translate>

<translate>
When a user wants to initiate a specific action against a component item (for example, edit an article), the system (after checking the Group the user is in has access) checks the permission for this combination of user, item, and action. If it is allowed, then the user can proceed. Otherwise, the action is not allowed.</translate>

<translate>
The remainder of this tutorial discusses how we control what users can do -- what action permissions they have.</translate>

<translate>==Actions, Groups, and Inheritance== </translate>

<translate>
The other side of ACL is granting permissions to users to take actions on objects.</translate>

{| class="wikitable"
!style="width:20%;"|
!<translate>
3.x series</translate>
|-
!<translate>
Groups and Actions</translate>
|<translate>
Actions allowed for each group are defined by site administrator.</translate>
|-
!<translate>
Permission Scope</translate>
|<translate>
Permissions can be set at multiple levels in hierarchy: Site, Component, Category, Object.</translate>
|-
!<translate>
Permission Inheritance</translate>
|<translate>
Permissions can be inherited from parent Groups and parent Categories</translate>
|}

<translate>===How Permissions Work=== </translate>

<translate>
There are four possible permissions for actions, as outlined below:</translate>

<translate>
* '''Not set''': Defaults to "deny" but, unlike the Deny permission, this permission can be overridden by setting a child group or a lower level in the permission hierarchy to "Allow". This permission only applies to the Global Configuration permissions.</translate>
<translate>
* '''Inherit''': Inherits the value from a parent Group or from a higher level in the permission hierarchy. This permission applies to all levels except the Global Configuration level.</translate>
<translate>
* '''Deny''': Denies this action for this level and group. '''IMPORTANT:''' This also denies this action for all child groups and all lower levels in the permission hierarchy. Putting in Allow for a child group or a lower level will not have any effect. The action will always be denied for any child group member and for any lower level in the permission hierarchy.</translate>
<translate>
* '''Allow''': Allows this action for this level and group and for lower levels and child groups. This does not have any effect if a higher group or level is set to Deny or Allow. If a higher group or level is set to Deny, then this permission will always be denied. If a higher group or level is set to Allow, then this permission will already be allowed.</translate>

<translate>===Permission Hierarchy Levels=== </translate>

<translate>
Action permissions in version 2.5+ can be defined at up to four levels, as follows:</translate>
<translate>
# '''Global Configuration''': determines the default permissions for each action and group.</translate>
<translate>
# '''Component Options->Permissions''': can override the default permissions for this component (for example, Articles, Menus, Users, Banners, and so on).</translate>
<translate>
# '''Category''': can override the default permissions for objects in one or more categories. Applies to all components with categories, including Articles, Banners, Contacts, Newsfeeds, and Weblinks.</translate>
<translate>
# '''Article''': Can override the permissions for a specific article. This level only applies to articles. Other components only allow the first three levels.</translate>

<translate>====Global Configuration==== 
This is accessed from System → Global Configuration → Permissions. This screen allows you set the top-level permission for each group for each action, as shown in the screenshot below.</translate>

[[Image:Screenshot_global_acl_J3_tutorial-<translate>
en</translate>.png]]

<translate>
The options for each value are Inherited, Allowed, or Denied. The Calculated Setting column shows you the setting in effect. It is either Not Allowed (the default), Allowed, or Denied.</translate>

<translate>
You work on one Group at a time by opening the slider for that group. You change the permissions in the Select New Settings drop-down list boxes.</translate>

<translate>
Note that the Calculated Setting column is not updated until you press the Save button in the toolbar. To check that the settings are what you want, press the Save button and check the Calculated Settings column.</translate>

<translate>====Component Options->Permissions==== </translate>
<translate>
This is accessed for each component by clicking the Options icon in the toolbar. This screen is similar to the Global Configuration screen above. For example, clicking the Options toolbar icon in the Menu Manager shows the Menus Configuration below.</translate>
[[Image:Screenshot_menu_acl_J3_tutorial-<translate>
en</translate>.jpg]]

<translate>
Access to Options is only available to members of groups who have permission for the Configure action in for each component. In the example above, the Administrator group has Allowed permission for the Configure option, so members of this group can access this screen.</translate>

<translate>====Category==== 
Category permissions are accessed in the Category Manager: Edit Category screen, in a tab at the top of the screen. This screen has five permissions, as shown below.</translate>

[[Image:Screenshot_category_acl_j3_tutorial-<translate>
en</translate>.png]]

<translate>
In these screens, you work on the permissions for one User Group at a time. In the example above, we are editing the permissions for the Administrator group.</translate>

<translate>
Note that the Configure and Access Component actions do not apply at the category level, so those actions are not included.</translate>

<translate>
Note also that Categories can be arranged in a hierarchy. If so, then action permissions in a parent category are inherited automatically by a child category. For example, if you had a category hierarchy of Animals → Pets → Dogs, then the full permission level hierarchy for an article in the Dogs category would be as follows:</translate>
<translate>
* Global Configuration
* Article Manager → Options → Permission
* Animals Category
* Pets Category
* Dogs Category
* specific article</translate>

<translate>====Article==== </translate>
<translate>
Permissions for a single article are access in the Article Manager: Edit Article screen, again in a slider at the bottom of the screen. This screen has three actions, as shown below.</translate>

[[Image:j3x_acl_tutorial_article_manager_article_permissions-<translate>
en</translate>.png]]

<translate>
Again, you edit each group by clicking on it to open the slider for that group. You can then change the permissions under the Select New Setting column. To see the effect of any changes, press the Save button to update the Calculated Setting column.</translate>

<translate>
Note that the Configure, Access Component, and Create actions do not apply at the article level, so these actions are not included. Permission to create an article is set at one of the higher levels in the hierarchy.</translate>

<translate>===Access Levels=== </translate>

<translate>
Access Levels in 3.x series are simple and flexible. The screen below shows the Special Access Level.</translate>
[[Image:j3x_acl_tutorial_viewing_levels-<translate>
en</translate>.png|center]]
<translate>
Simply check the box for each group you want included in that level. The Special Access Level includes the Manager, Author, and Super Users groups. It also includes child groups of those groups. So, Administrator group is included, since it is a child group of the Manager group. The Editor, Publisher, and Shop Suppliers groups are included, since they are child groups of Author. (Note that we could check all of the child groups if we wanted and it wouldn't hurt anything).</translate>

<translate>
Once Access Levels are created, they are used in the same way as in version 1.5. Each object in the front end is assigned an Access Level. If the level is Public, then anyone may access that object. Otherwise, only members of groups assigned to that access level may access that object. Access levels are assigned to Menu Items and to Modules. Each one can only be assigned to one access level.</translate>

<translate>
For example, the screen below shows the Edit Menu Item screen with the list of available access levels.</translate>

[[Image:j3x_acl_tutorial_edit_menu_item_level_dropdown-<translate>
en</translate>.png|center]]

<translate>==Default ACL Setup== </translate>

<translate>
When Joomla! is installed, these are set to their initial default settings. We will discuss these initial settings as a way to understand how the ACL works.</translate>

<translate>===Default Groups=== </translate>

<translate>
Version 3.x allows you to define your own Groups. When you install version 3.x, it includes a set of default groups, shown below are the basic default user groups. (Additional default user groups are installed with sample data)</translate>

[[Image:Screenshot_usergroupsl_acl_J3_tutorial-<translate>
en</translate>.png|center]]

<translate>
The arrows indicate the child-parent relationships. As discussed above, when you set a permission for a parent group, this permission is automatically inherited by all child groups. The Inherited, and Allowed permissions can be overridden for a child group. The Denied permission cannot be overridden and will always deny an action for all child groups.</translate>

<translate>===Global Configuration=== </translate>

<translate>
Joomla! version 2.5 will install with the same familiar back-end permissions as that of version 1.5. However, with 2.5, you can easily change these to suit the needs of your site.</translate>

<translate>
As discussed earlier, the permissions for each action are inherited from the level above in the permission hierarchy and from a group's parent group. Let's see how this works. The top level for this is the entire site. This is set up in the Site->Global Configuration->Permissions, as shown below.</translate>

[[Image:Screenshot_global_acl_J3_tutorial-<translate>
en</translate>.png]]

<translate>
The first thing to notice are the ten Actions: Site Login, Admin Login, Offline Access, Super User, Access Administration Interface, Create, Delete, Edit, Edit State. and Edit Own. These are the actions that a user can perform on an object in Joomla. The specific meaning of each action depends on the context. For the Global Configuration screen, they are defined as follows:</translate>

<translate>
;Site Login : Login to the front end of the site


;Admin Login : Login to the back end of the site</translate>

<translate>
;Offline Access : Login to the front end of the site when the website site is offline (when Global Configuration setting "Site Offline" is set to Yes)</translate>

<translate>
; Super User : Grants the user "super user" status. Users with this permission can do anything on the site. Only users with this permission can change Global Configuration settings (this screen). These permissions cannot be restricted. It is important to understand that, if a user is a member of a Super Admin group, any other permissions assigned to this user are irrelevant. The user can do any action on the site. However, Access Levels can still be assigned to control what this group sees on the site. (Obviously, a Super Admin user can change Access Levels if they want to, so Access Levels do not totally restrict what a Super Admin user can see.)</translate>

<translate>
;Access Component: Open the component manager screens (User Manager, Menu Manager, Article Manager, and so on)</translate>

<translate>
;Create : Create new objects (for example, users, menu items, articles, weblinks, and so on)</translate>

<translate>
;Delete : Delete existing objects</translate>

<translate>
;Edit : Edit existing objects</translate>

<translate>
;Edit State : Change object state (Publish, Unpublish, Archive, and Trash)</translate>

<translate>
;Edit Own : Edit objects that you have created.</translate>

<translate>
Each Group for the site has its own slider which is opened by clicking on the group name. In this case (with the sample data installed), we have the standard 7 groups that we had in version 1.5 plus two additional groups called "Shop Suppliers" and "Customer Group". Notice that our groups are set up with the same permissions as they had in version 1.5. Keep in mind that we can change any of these permissions to make the security work the way we want. Let's go through this to see how it works.</translate>

<translate>
* '''Public''' has everything set to "Not set", as shown below.</translate>{{-}}[[Image:Screenshot_global_acl_public_J3_tutorial-<translate>
en</translate>.png]]
<translate>
**This can be a bit confusing. Basically, "Not Set" is the same as "Inherited". Because Public is our top-level group, and because Global Configuration is the top level of the component hierarchy, there is nothing to inherit from. So "Not Set" is used instead of "Inherit".</translate>
<translate>
**The default in this case is for no permissions. So, as you would expect, the Public group has no special permissions. Also, it is important to note that, since nothing is set to Denied, all of these permissions may be overridden by child groups or by lower levels in the permission hierarchy.</translate>

<translate>
* '''Guest''' is a 'child' group of the Public group has everything set to 'Inherited'</translate> {{-}}[[Image:Screenshot_global_acl_guest_J3_tutorial-<translate>
en</translate>.png]]
<translate>
** This is the default 'Guest User Group' in the User Manager options and the Group that (non logged in) visitors to your site are placed in.</translate>

<translate>
* '''Manager''' is a "child" group of the Public group. It has Allowed permissions for everything except Access Component and Super Admin. So a member of this group can do everything in the front and back end of the site except change Global Permissions and Component Options.</translate> {{-}}[[Image:Screenshot_global_acl_manager_J3_tutorial-<translate>
en</translate>.png]]

<translate>
* '''Administrator''' group members inherit all of the Manager permissions and also have Allowed for Access Component. So members of this group by default can access the Options screens for each component.</translate> {{-}}[[Image:Screenshot_global_acl_administrator_J3_tutorial-<translate>
en</translate>.png]]

<translate>
* '''Registered''' is the same a Public except for the Allow permission for the Site Login action. This means that members of the Registered group can login to the site. Since default permissions are inherited, this means that, unless a child group overrides this permission, all child groups of the Registered group will be able to login as well.</translate> {{-}}[[Image:Screenshot_global_acl_registered_J3_tutorial-<translate>
en</translate>.png]]

<translate>
* '''Author''' is a child of the Registered group and inherits its permissions and also adds Create and Edit Own. Since Author, Editor, and Publisher have no back-end permissions, we will discuss them below, when we discuss front-end permissions.</translate>{{-}}[[Image:Screenshot_global_acl_author_J3_tutorial-<translate>
en</translate>.png]]

<translate>
* '''Editor''' is a child of the Authors group and adds the Edit permission.</translate> {{-}}[[Image:Screenshot_global_acl_editor_J3_tutorial-<translate>
en</translate>.png]]

<translate>
* '''Publisher''' is a child of Editor and adds the Edit State permission.</translate>{{-}}[[Image:Screenshot_global_acl_publisher_J3_tutorial-<translate>
en</translate>.png]]

<translate>
* '''Shop Suppliers''' is an example group that is installed if you install the sample data. It is a child group of Author.</translate>

<translate>
* '''Customer Group''' is an example group that is installed if you install the sample data. It is a child group of Registered.</translate>

<translate>
* '''Super Users''' group has the Allow permission for the Super Admin action. Because of this, members of this group have super user permissions throughout the site. They are the only users who can access and edit values on the Global Configuration screen. Users with permission for the Super Admin action have some special characteristics:</translate>
<translate>
:* If a user has Super Admin permissions, no other permissions for this user matter. The user can perform any action on the site.</translate>
<translate>
:* Only Super Admin users can create, edit, or delete other Super Admin users or groups.</translate>

<translate>
There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.</translate>

<translate>
This provides a lot of flexibility. For example, if you wanted Shop Suppliers to be able to have the ability to login to the back end, you could just change their Admin Login value to "Allowed". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherited (or Denied).</translate>

<translate>
It is also important to understand that the ability to have child groups is completely optional. It allows you to save some time when setting up new groups. However, if you like, you can set up all groups to have Public as the parent and not inherit any permissions from a parent group.</translate>

<translate>===Component Options & Permissions=== </translate>

<translate>
Now, let's continue to see how the default back-end permissions for version 2.5 mimic the permissions for version 1.5. The Super Users group in 2.5 is equivalent to the Super Administrator group in 1.5.</translate>

<translate>
Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 2.5 configuration. Let's see how this is accomplished.</translate>

<translate>
If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:</translate>

[[Image:screenshot_acl_tutorial_20110111-09-<translate>
en</translate>.png|center|]]
[[Image:screenshot_acl_tutorial_20110111-10-<translate>
en</translate>.png|center|]]

<translate>
This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.</translate>

<translate>
First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.</translate>

<translate>
Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.</translate>

<translate>
If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.</translate>

<translate>
In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.</translate>

<translate>
It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.</translate>

<translate>===Front End Permissions=== </translate>

<translate>
Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions. First, let's look at the permissions for Manager, as shown below.</translate>
[[Image:screenshot_acl_tutorial_20110111-11a-<translate>
en</translate>.png|center|frame]]
<translate>
Manager has allowed permission for all actions except Configure. So members of the Manager group can do everything with Articles except open the Options screen.</translate>

<translate>
Now let's look at Administrator, as shown below.</translate>
[[Image:screenshot_acl_tutorial_20110111-12a-<translate>
en</translate>.png|center|frame]]
<translate>
Administrator has Allowed for Configure, so Administrators can edit this Options screen.</translate>

<translate>
Both groups can create, delete, edit, and change the state of articles.</translate>

<translate>
Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set.</translate>

<translate>
Authors only have Create and Edit Own permissions, as shown below.</translate>
[[Image:screenshot_acl_tutorial_20110112-07-<translate>
en</translate>.png|center|frame]]
<translate>
This means that Authors can create articles and can edit articles they have created. They may not delete articles, change the published state of articles, or edit articles created by others.</translate>

<translate>
Editors have the same permissions as Authors with the addition of permission for the Edit action, as shown below.</translate>
[[Image:screenshot_acl_tutorial_20110112-08-<translate>
en</translate>.png|center|frame]]
<translate>
So Editors can edit articles written by anyone.</translate>

<translate>
Publishers can do everything Editors can do plus they have permission for the Edit State action, as shown below.</translate>
[[Image:screenshot_acl_tutorial_20110112-09-<translate>
en</translate>.png|center|frame]]
<translate>
So Publishers can change the published state of an article. The possible states include Published, Unpublished, Archived, and Trashed.</translate>

<translate>
All of these groups have Inherit permission for Configure and Access Component. Remember that Author is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Configure and Access Component, and since Author's permission for these actions is "Inherited", then Author does not have these permissions either. This same permission is passed from Author to Editor and from Editor to Publisher. So, by default, none of these groups are allowed to work with articles in the back end.</translate>

<translate>
It is important to remember that these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.</translate>

<translate>
Also, note that there are no Denied permissions for any actions in the default settings. This allows you to add Allowed permissions at any level. Remember, once you have an action set for Denied, this action will be denied at all lower levels in the hierarchy. For example, if you set the Admin Login for Registered to Denied (instead of Allowed), you could not grant Publishers Allowed permissions for this action.</translate>

<translate>=== Article Manager & Actions Diagram === </translate>

<translate>
The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.</translate>

[[Image:screenshot_acl_tutorial_20110111-16-<translate>
en</translate>.png|center|]]

<translate>
* '''Configure''' allows you to view and change the Options for the component.</translate>
<translate>
* '''Access Component''' allows you to navigate to the Article Manager. Without this permission, no other actions are possible.</translate>
<translate>
* '''Create''' allows you to add new articles.</translate>
<translate>
* '''Delete''' allows you to delete trashed articles. Note that the Delete icon only shows in the toolbar when you have the "Select State" filter set to "Trash".</translate>
<translate>
* '''Edit''' allows you to edit existing articles.</translate>
<translate>
* '''Edit State''' allows to you Publish, Unpublish, Archive, or Trash articles.</translate>
<translate>
* '''Edit Own''' is the same as Edit except that it only applies to articles written by you.</translate>

<translate>==Allowing Guest-Only Access to Menu Items and Modules== </translate>

<translate>
Version 1.6 introduced the ability to create a View Access Level that is only for guests of the site (meaning a user who is not logged in). The example below shows how you can set up this new feature.
''(N.B. Steps 1 to 3 are not needed for Joomla! 3.x as they exist in the default install)''</translate>

<translate>
#Create a new user group called Guest. Make it a child of the Public group as shown below.</translate> [[Image:screenshot_acl_tutorial_20110112-01-<translate>
en</translate>.png|center|frame]]
<translate>
# Create a new access level called Guest and grant only the Guest group access to this level, as shown below.</translate>[[Image:screenshot_acl_tutorial_20110112-02-<translate>
en</translate>.png|center|frame]]
<translate>
# Navigate to User Manager→Options→Component and change the Guest User Group from the default value of "Public" to "Guest", as shown below.</translate>
[[Image:screenshot_acl_tutorial_20110112-04-<translate>
en</translate>.png|center|frame]]
<translate>
Now, if we assign a menu item, module, or other object to the Guest access level, only non-logged in users will have access. For example, if we create a new menu item with access level of Guest, as shown below,</translate>
[[Image:screenshot_acl_tutorial_20110112-05-<translate>
en</translate>.png|center|frame]]
<translate>
this menu item will only be visible to non-logged-in visitors to the site.</translate>

<translate>
If required other user groups like Author can be granted access in the Guest access level, this would allow Authors to view articles in the front end for editing.</translate>

<translate>
'''N.B. Login/logout in front end (''for changing data in session'') to see the change.'''</translate>

<translate>==Using Permission and Group Levels Together== </translate>

<translate>
As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.</translate>

<translate>
This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:</translate>

<translate>
* both groups can create new articles only in the History Assignments category.</translate>

<translate>
* only History Teachers (not Assistant History Teachers) can Publish or otherwise have Edit State permission.</translate>

<translate>
This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.</translate>

[[Image:Acl example diagram1 20091018-<translate>
en</translate>.png|center|]]

<translate>
In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.</translate>

<translate>
To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.</translate>

<translate>
Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.</translate>

[[Image:Acl example diagram2 20091018-<translate>
en</translate>.png|center|]]

<translate>
This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.</translate>

<translate>
Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.</translate>

<translate>==ACL Action Permission Examples== 
Here are some examples of how you might set up the ACL for some specific situations.</translate>

<translate>===Back-end Article Administrator=== </translate>

<translate>
'''Problem:'''</translate>

<translate>
We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.</translate>

<translate>
'''Solution:'''</translate>

<translate>
# Create a new group called Article Administrator and make its parent group Public, as shown below.</translate>[[Image:screenshot_acl_tutorial_20110112-10-<translate>
en</translate>.png|center|frame]] <translate>
Because its parent group is Public, it won't have any permissions by default.</translate>
<translate>
# In Users → Access Levels, edit the Special Access level to add the new group. That way they can get access to the back end menu items and modules (This assumes that the modules for the admin menu and quickicons have the Special Access level assigned to them, which is the default.)</translate> [[Image:screenshot_acl_tutorial_20110112-11-<translate>
en</translate>.png|center|frame]] <translate>
By default, the back-end menu items and modules are set to Special access, so if you forget to add the new group to the Special access level, you won't see any modules or menu items when you log in as a user of the new group.</translate>
<translate>
# In Site → Global Configuration → Permissions, click on the Article Administrator group and change the permissions to Allowed for the following actions: Admin Login, Create, Delete, Edit, Edit State, and Edit Own. The screen below shows what will show before you press Save.</translate> [[Image:screenshot_acl_tutorial_20110112-12-<translate>
en</translate>.png|center|frame]]<translate>
After you save, the Calculated Permissions should show as shown below.</translate>[[Image:screenshot_acl_tutorial_20110112-13-<translate>
en</translate>.png|center|frame]]<translate>
Note that the permission for the Access Component is Inherited, which translates to Not Allowed. This is important. This means that this group will only be able to access components if we give the group "Allowed" permission for Access Component. So we only have to change the one component we want to give them access to and don't have to change any settings for the components where we don't want them to have access. If we had a case where we wanted to give a group access to everything except for one component, we could set the default to Allowed and then set the one component to Denied. Also note that we did not give the group Site Login permission, so users in this group will not be able to log into the front end. (If we wanted to allow that, we would just change the permission to Allowed for Site Login.)</translate>
<translate>
# In Article Manager → Options → Permissions, change permissions to Allowed for this group for the Access Component action, as shown below.</translate>[[Image:screenshot_acl_tutorial_20110112-14-<translate>
en</translate>.png|center|frame]]<translate>
All of the other desired permissions are inherited.</translate>

<translate>
That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end. For example, the screen below shows what a user in the Article Manager will see when they login to the back end.</translate>[[Image:screenshot_acl_tutorial_20110112-15-<translate>
en</translate>.png|center|frame]]

<translate>==ACL View Access Levels Examples== </translate>

<translate>
A basic concept of using Access Levels is that all items with the same Access will be viewable by the same group of users. In other words, if two items have the same Access, you can't have one viewable by one user and not viewable by another user. On the other hand, it is easy to have one Group view any number of items with different Access levels.</translate>

<translate>
Similarly, each Group has exactly the same combination of Access levels, but one User can be a member of more than one group. Depending on the situation, you may want to have users only in one Group or you may need to have a User in more than one Group.</translate>

<translate>
This means that we may need to group our items so that items so that all items in a group have the same level of sensitivity. Here are some examples.</translate>

<translate>===Hierarchical Example=== </translate>
<translate>
In this example, Access levels are hierarchical, for example, like government security clearance codes. Say for example we have the following sets of classified documents: Classified, Secret, and Top Secret. Users have corresponding clearence codes. Users with Classified clearance can only see Classified documents and cannot see Secret or Top Secret. Users with Secret clearance can see Classified and Secret documents but not Top Secret. Users with Top Secret can see all documents.</translate>

<translate>
In this case, you would create three Access levels: Classified, Secret, and Top Secret and the same three Groups. Users would only be members of one group, as follows:</translate>

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
User</translate>
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Group</translate>
| style="border:0.0007in solid #000000;padding:0.0382in;"| <translate>
Access Levels</translate>

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| C1, C2, C3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Classified</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| <translate>
Classified</translate>

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| S1, S2, S3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Secret</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| <translate>
Classified, Secret</translate>

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| TS1, TS2, TS3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Top Secret</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| <translate>
Classified, Secret, Top Secret</translate>

|}

<translate>
In this case, all users are in exactly one group, but some groups have access to more than one Access Level of items. In other words, we have a one-to-one relationship between users and groups, but a one-to-many relationship between Groups and Access Levels.</translate>

<translate>===Team Security Example=== </translate>

<translate>
Another possible use case is a set of non-hierarchical teams. Let's say we have three teams, T1, T2, and T3. Some users are only on one team, but others might be on two or more teams. In this case, we could set up our Access Levels and Groups by team. Documents for each team have the access level for that team, and the Group for the team has only the one access level. When a User is on more than one team, they get added to the group for each team, as follows:</translate>

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
User</translate>
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Description</translate>
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Group</translate>
| style="border:0.0007in solid #000000;padding:0.0382in;"| <translate>
Access Levels</translate>

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Team 1 member</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Team 2 member</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Team 3 member</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Member of teams 1 and 2</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Member of teams 1 and 3</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Member of teams 1,2, and 3</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1,T2, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2, T3

|}

<translate>===Hybrid Example=== </translate>

<translate>
In a real-world situation, you might have a combination of these two arrangements. Say for example we have Managers and Staff. Staff can only see Staff documents and Managers can see Manager and Staff documents. Both types of users can be assigned to teams as well, in which case they can see all of the documents for that team. In addition, say that Managers can access some, but not all, team documents. Staff can only access team documents if they are members of that team.</translate>

<translate>
In this example, we could set up the following Access Levels:</translate>

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Access Level</translate>
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Description</translate>
| style="border:0.0007in solid #000000;padding:0.0382in;"| <translate>
Groups</translate>

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Manager</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Non-team manager documents</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| <translate>
Manager</translate>

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Staff</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Non-team staff documents</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| <translate>
Manager, Staff</translate>

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Team1</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Sensitive Team1 documents (no access outside team)</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| <translate>
Team1</translate>

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Team1-Manager</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Team1 documents that can be accessed by all managers</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| <translate>
Team1, Manager</translate>

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Team2</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Sensitive Team2 documents (no access outside team)</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| <translate>
Team2</translate>

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Team2-Manager</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Team2 documents that can be accessed by all managers</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| <translate>
Team2, Manager</translate>

|}

<translate>
Then, users could be assigned to groups as follows:</translate>

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
User Type</translate>
| style="border:0.0007in solid #000000;padding:0.0382in;"| <translate>
Group</translate>

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Manager on no teams</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| <translate>
Manager</translate>

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Manager on team 1</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| <translate>
Manager, Team1</translate>

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Staff on team 1</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| <translate>
Staff, Team1</translate>

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Manager on teams 1 and 2</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| <translate>
Manager, Team1, Team2</translate>

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| <translate>
Staff on teams 1 and 2</translate>
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| <translate>
Staff, Team1, Team2</translate>

|}

<noinclude>
<translate>

[[Category:Joomla! 1.6]]
[[Category:Joomla! 2.5]]
[[Category:Joomla! 3.x]]
[[Category:Tutorials]]
[[Category:Access Control]]
[[Category:Access Management]]
</translate>
</noinclude>

J3.x:Access Control List Tutorial/de

2019-12-26T19:07:06Z

Sieger66:

<noinclude><languages /></noinclude>
{{Joomla version|version=3.x|comment=Serie}}
{{-}}
{{:J3.1:Access_Control_List/en}}

==Separate ACL für Anzeige und Aktionen==

Das Joomla ACL-System besteht genau genommen aus zwei völlig getrennten Systemen. Das eine System steuert, was Benutzer auf der Website "sehen" können. Das andere steuert, was Benutzer "tun" können (welche Aktionen ein Benutzer durchführen kann). Die ACL wird für jedes dieser Systeme anders eingerichtet.

===Steuern, was Benutzer sehen können===

Das Setup zum Steuern, was Benutzer sehen können, sieht wie folgt aus:
*Eine Reihe von Zugriffsebenen gemäß den Kategorien und/oder der Kombination von Kategorien erstellen, die nur angemeldete Benutzer sehen sollen. Anmerkung: Zu diesem Zeitpunkt werden noch keine Benutzergruppen den neuen Zugriffsebenen zugewiesen.

*Für jede Zugriffsebene eine Benutzergruppe erstellen, die 'Registriert' als übergeordnete Gruppe hat. Indem man für Benutzergruppen und Zugriffsebenen die gleichen Namen verwendet, kann man Verwirrungen zu einem späteren Zeitpunkt vorbeugen.

*Die neuen Zugriffsebenen bearbeiten und jeder die (neue) Benutzergruppe zuweisen. Wahrscheinlich möchten man auch die 'Super Benutzer' Gruppe (und/oder die anderen Standard-Benutzergruppen mit Ausnahme der Benutzergruppe 'Gast') den neuen Zugriffsebenen zuweisen.

*Jedem anzuzeigenden Eintrag eine Zugriffsebene zuweisen. Einträge sind sowohl inhaltliche Einträge (Beiträge, Kontakte, usw.), Menüeinträge als auch Module.

Immer dann, wenn ein Benutzer im Begriff ist, einen Eintrag auf einer Joomla-Seite anzeigen zu lassen, prüft das Programm, ob dieser Benutzer auch Zugriff auf den Eintrag hat. Das geschieht folgendermaßen:
# Zunächst wird eine Liste aller Zugriffsebenen erstellt, auf die der Benutzer zugreifen kann, basierend auf allen Gruppen, denen der Benutzer angehört. Sofern eine Gruppe eine übergeordnete Gruppe besitzt, sind die Zugriffsebenen für die übergeordnete Gruppe ebenfalls in der Liste enthalten.
# Danach wird überprüft, ob die Zugriffsebene für den Eintrag (Beitrag, Modul, Menüeintrag, usw.) in dieser Liste enthalten ist. Wenn dem so ist, wird der Eintrag dem Benutzer angezeigt. Falls der Benutzer die benötigten Zugriffsrechte besitzt, wird ihm der Zugriff verweigert.

Beachten, dass Zugriffsebenen für jede Gruppe separat festgelegt und nicht von der übergeordneten Gruppe einer Gruppe vererbt werden.

===Steuern, was Benutzer tun können===

Das System, das steuert, was Benutzer in einer Benutzergruppe tun können - welche Aktionen sie bei einem bestimmten Eintrag ausführen können - wird über den Tab 'Berechtigungen' in der Konfiguration und den Tab 'Berechtigungen' in den Optionen jeder einzelnen Komponente eingerichtet. Berechtigungen können auch auf Kategorienebene (bei Kernkomponenten) und auf Beitragsebene (bei Beiträgen) gesetzt werden.

* Wenn angemeldete Benutzer in bestimmten Kategorien Erstellen, Löschen, Status bearbeiten oder Eigene Inhalte bearbeiten dürfen, dann:
** Eine Benutzergruppe erstellen und als übergeordnete Gruppe eine der Benutzergruppen angeben, die Zugriff auf die Kategorie (oder Kategorien) haben, die diese neue Benutzergruppe ändern soll.
**Der neuen Benutzergruppe den entsprechenden Zugriffsebenen zuweisen. Dann die erforderlichen Berechtigungen für die neue Benutzergruppe entweder global oder pro Kategorie/Beitrag ändern.
*** Beim Erstellen einer Benutzergruppe ist es ratsam, eine übergeordnete Gruppe zu wählen, die über weniger Berechtigungen verfügt, als für die neue Gruppe erforderlich. Denn es ist einfacher, die Berechtigungen für jede Komponente/Kategorie/Beitrag zu erweitern, für die zusätzliche Berechtigungen nötig sind, als Berechtigungen aus den anderen Komponenten/Kategorien/Beiträgen zu entfernen.
****''(Beispiel: Es gibt 10 Kategorien, man möchte aber nur für eine Erstellen-Berechtigungen. Würde man für diese Gruppe die Berechtigungen global auf Erstellen erlaubt setzen, müsste man für diese Kategorien die Erstellen-Berechtigung entfernen. Und man müsste für diese Gruppe die Erstellen-Berechtigung bei jeder neuen Kategorie, die man zu einem späteren Zeitpunkt hinzufügt, ebenfalls entfernen).''
** Eine Benutzergruppe erstellen, die eine der Standardbenutzergruppen als übergeordnete Gruppe hat, NUR, wenn keine von diesen über die exakten Berechtigungen verfügt, die man benötigt und sich für alle Kategorien wünscht.

Beachten, dass dieses Setup unabhängig vom Setup für die Anzeige ist. Allerdings muss eine Benutzergruppe den entsprechenden Zugriffsebenen zugewiesen werden, damit der Benutzer in dieser Gruppe jene Berechtigungen verwenden kann.

Möchte ein Benutzer eine bestimmte Aktion bei einem Komponenten-Eintrag durchführen (z. B. einen Beitrag bearbeiten), überprüft das System (nachdem es überprüft hat, welcher Gruppe der Benutzer angehört und auf welche er Zugriff hat) die Berechtigung für diese Kombination aus Benutzer, Eintrag und Aktion. Liegt eine Erlaubnis vor, kann der Benutzer fortfahren. Andernfalls ist die Aktion nicht zulässig.

Das restliche Tutorial befasst sich mit der Steuerung, was Benutzer tun können - welche Aktionsberechtigungen sie haben.

==Aktionen, Gruppen und Vererbung==

Andererseits geht es bei der ACL auch darum, Benutzern Berechtigungen zu erteilen, damit diese Aktionen an Objekten durchführen können.

{| class="wikitable"
!style="width:20%;"|
!3.x Serie
|-
!Gruppen und Aktionen
|Aktionen, welche pro Gruppe erlaubt sind, werden durch den Website Administrator festgelegt.
|-
!Umfang von Berechtigungen
|Berechtigungen können auf mehreren Ebenen in der Hierarchie festgelegt werden: Website, Komponente, Kategorie, Objekt.
|-
!Vererbung von Berechtigungen
|Berechtigungen können von übergeordneten Gruppen und übergeordneten Kategorien geerbt werden.
|}

===Wie die Berechtigungen funktionieren===

Es gibt vier mögliche Berechtigungen für Aktionen. Diese sind (kurz skizziert):

* '''Nicht gesetzt''': Fällt standardmäßig auf "Nicht erlaubt" zurück. Aber im Gegensatz zur Berechtigung "Verweigert" kann diese Berechtigung außer Kraft gesetzt werden, wenn eine untergeordnete Gruppe oder eine in der Berechtigungshierarchie untergeordnete Ebene auf "Erlaubt" gesetzt wird. Diese Berechtigung kann nur für globale Berechtigungen der Konfiguration gesetzt werden.
* '''Vererbt''': Erbt den Wert von einer übergeordneten Gruppe oder einer in der Berechtigungshierarchie höheren Ebene. Diese Berechtigung gilt für alle Ebenen mit Ausnahme der obersten Ebene der Konfiguration.
* '''Verweigert''': Verbietet diese Aktion für diese Ebene und Gruppe. '''WICHTIG:''' Dadurch wird diese Aktion auch für alle untergeordneten Gruppen und alle untergeordneten Ebenen in der Berechtigungshierarchie verboten. Wird "Erlaubt" in einer untergeordneten Gruppe oder einer tieferen Ebene gesetzt, hat das keinen Effekt. Die Aktion wird immer für alle Mitglieder einer untergeordneten Gruppe und für alle untergeordneten Ebenen in der Berechtigungshierarchie abgelehnt.
* '''Erlaubt ''': Genehmigt diese Aktion für diese Ebene und Gruppe und für tiefere Ebenen und Untergruppen. Dies hat keine Auswirkungen, wenn eine höhere Gruppe oder Ebene auf "Verweigert" oder "Erlaubt" eingestellt ist. Wenn eine höhere Gruppe oder ein höheres Ebene auf "Verweigert" gesetzt ist, wird diese Berechtigung immer abgelehnt. Wenn eine höhere Gruppe oder Ebene auf Erlaubt eingestellt ist, ist diese Berechtigung bereits erlaubt.

===Hierarchie der Berechtigungsebenen===

Berechtigungen für Aktionen können in Version 2.5+ auf bis zu vier Ebenen festgelegt werden, wie folgt:
# '''Konfiguration''': legt die Standardberechtigungen für jede Aktion und Gruppe fest.
# '''Komponenten-Optionen-> Berechtigungen''': kann die Standardberechtigungen für diese Komponente überschreiben (z. B. Beiträge, Menüs, Benutzer, Banner usw.).
# '''Kategorie''': kann die Standardberechtigungen für Objekte in einer oder mehreren Kategorien überschreiben. Gilt für alle Komponenten mit Kategorien, einschließlich Beiträge, Banner, Kontakte, Newsfeeds und Weblinks.
# '''Beitrag''': kann die Berechtigungen für einen bestimmten Artikel überschreiben. Diese Ebene gilt nur für Beiträge. Alle anderen Komponenten erlauben nur die ersten drei Ebenen.

====Konfiguration====
Diese erreicht man über System → Konfiguration → Berechtigungen. Die nun sichtbare Maske dient dazu, die Berechtigungen auf der obersten Ebene für jede Gruppe und jede Aktion festzulegen, wie auch in der folgenden Abbildung gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Die möglichen Werte sind Vererbt, Erlaubt oder Verweigert. Die Spalte 'Errechnete Einstellung' zeigt die aktuelle Einstellung an. Diese ist entweder Nicht erlaubt (Standard), Erlaubt oder Nicht erlaubt.

Man kann immer nur an einer Gruppe gleichzeitig arbeiten, indem man den Reiter für ebendiese Gruppe anklickt. Die Berechtigungen kann man über die Dropdownlisten unter Neue Einstellung wählen ändern.

Beachten Sie, dass die Spalte "Errechnete Einstellung" erst aktualisiert wird, wenn Sie auf die Schaltfläche "Speichern" in der Werkzeugleiste klicken.

Um zu überprüfen, ob die Einstellungen Ihren Wünschen entsprechen, klicken Sie auf die Schaltfläche Speichern und überprüfen anschließend die Spalte Errechnete Einstellung.

====Komponenten-Optionen->Berechtigungen====
Auf diese wird für jede Komponente durch Klicken auf das Symbol "Optionen" in der Werkzeugleiste zugegriffen. Dieser Bildschirm ist ähnlich wie der Bildschirm "Globale Konfiguration" oben links. Wenn Sie beispielsweise im Menü-Manager auf das Symbol in der Werkzeugleiste Optionen klicken, werden die folgenden Menüs angezeigt.
[[Image:Screenshot_menu_acl_J3_tutorial-en.jpg]]

Der Zugriff auf Optionen ist nur für Mitglieder von Gruppen möglich, die die Berechtigung für die Aktion Konfiguration in für jede Komponente haben. Im obigen Beispiel hat die Gruppe Administrator die Berechtigung Erlaubt für die Option Konfigurieren, so dass Mitglieder dieser Gruppe auf diesen Bildschirm zugreifen können.

===Kategorie===
Auf die Kategorieberechtigungen wird im Category Manager zugegriffen: Bildschirm Kategorie bearbeiten, in einer Registerkarte oben auf dem Bildschirm. Dieser Bildschirm hat fünf Berechtigungen, wie folgt:

[[Image:Screenshot_category_acl_j3_tutorial-en.png]]

In diesen Bildern bearbeiten Sie die Berechtigungen für jeweils eine Benutzergruppe. Im obigen Beispiel bearbeiten Sie die Berechtigungen für die Gruppe Administrator.

Achten Sie darauf, dass die Aktionen "Konfigurieren und Zugriffssteuerung" nicht auf der Kategorieebene angewendet werden, so dass diese Aktionen nicht enthalten sind.

Beachten Sie auch, dass Kategorien in einer Hierarchie angeordnet werden können. Wenn ja, dann werden Aktionsberechtigungen in einer übergeordneten Kategorie automatisch an eine untergeordnete Kategorie vererbt. Wenn Sie beispielsweise eine Kategoriehierarchie von Tieren → Haustiere → Hunde hätten, dann würde die vollständige Berechtigungshierarchie für einen Artikel in der Kategorie Hunde wie folgt aussehen:
* Globale Konfiguration
* Artikel-Manager → Optionen → Genehmigung → Erlaubnis
* Tierkategorie
* Kategorie Haustiere
* Kategorie Hunde
* spezifischer Artikel

====Beitrag====
Berechtigungen für einzelne Beiträge findet man im "Beitrag" unter dem Tab-Reiter "Berechigungen". Dieser Bildschirm hat drei Aktionen, wie unten gezeigt.

[[Image:j3x_acl_tutorial_article_manager_article_permissions-en.png]]

Auch hier bearbeiten Sie jede Gruppe für sich. Um auf die Berechtigungen zuzugreifen wechseln Sie im Artikel auf den Reiter "Berechtigungen" im oberen Reiter. Über das Drop Down Menü wählen Sie die neue Berechtigung im Anschluss speichern Sie den Beitrag ab.

Beachten Sie, dass die Aktionen Configure, Access Component und Create auf Artikelebene nicht gelten, so dass diese Aktionen nicht berücksichtigt werden. Die Berechtigung zum Anlegen eines Artikels wird auf einer der höheren Ebenen der Hierarchie festgelegt.

===Zugriffsebenen===

Die Zugriffsebenen der 3.x-Serie sind einfach und flexibel. Der folgende Bildschirm zeigt die spezielle Zugriffsebene.
[[Image:j3x_acl_tutorial_viewing_levels-en.png|center]]
Aktivieren Sie einfach das Kontrollkästchen für jede Gruppe, die Sie in diesem Level aufnehmen wollen. Die spezielle Zugriffsebene umfasst die Gruppen Manager, Autor und Superuser. Es beinhaltet auch untergeordnete Gruppen dieser Gruppen. Die Gruppe Administrator ist also enthalten, da es sich um eine Untergruppe der Gruppe Manager handelt. Die Gruppen Editor, Publisher und Shop Suppliers sind enthalten, da es sich um Untergruppen des Autors handelt.

Jedem Objekt im Frontend ist eine Zugriffsebene zugeordnet. Wenn die Ebene öffentlich ist, kann jeder auf dieses Objekt zugreifen. Andernfalls dürfen nur Mitglieder von Gruppen, die dieser Zugriffsebene zugeordnet sind, auf dieses Objekt zugreifen.

Die Zugriffsebenen sind den Menüpunkten und den Modulen zugeordnet. Jede kann nur einer Zugriffsebene zugeordnet werden.

Der folgende Bildschirm zeigt beispielsweise den Bildschirm Menüpunkt bearbeiten mit der Liste der verfügbaren Zugriffsebenen....

[[Image:j3x_acl_tutorial_edit_menu_item_level_dropdown-en.png|center]]

==Standard-ACL-Setup==

Wenn Joomla! installiert ist, werden diese auf die ursprünglichen Standardwerte gesetzt. Wir werden diese Grundeinstellungen besprechen, um die Arbeitsweise der ACL zu verstehen.

===Standardgruppen===

Mit der Version 3.x können Sie Ihre individuellen Gruppen definieren. Wenn Sie die Version 3.x installieren, enthält sie eine Reihe von Standardgruppen, die im Folgenden dargestellt werden, sind die grundlegenden Standardbenutzergruppen. (Zusätzliche Standardbenutzergruppen werden mit Beispieldaten installiert)

[[Image:Screenshot_usergroupsl_acl_J3_tutorial-en.png|center]]

Die Pfeile zeigen die untergeordneten Elternbeziehungen an. Wie vorstehend besprochen, wird diese Berechtigung, wenn Sie eine Berechtigung für eine übergeordnete Gruppe festlegen, automatisch an alle Untergruppen vererbt. Die vererbten und zulässigen Berechtigungen können für eine Untergruppe überschrieben werden. Die Berechtigung Verweigert kann nicht überschrieben werden und verweigert immer eine Aktion für alle Untergruppen.

===Konfiguration===

Joomla! Version 3.x wird mit den gleichen bekannten Backend-Rechten wie die Version 1.5 (EOL) installiert. Mit der Version 3.x können Sie diese jedoch leicht an die Bedürfnisse Ihrer Website anpassen.

Wie bereits besprochen, werden die Berechtigungen für jede Aktion von der obigen Ebene in der Berechtigungshierarchie und von der übergeordneten Gruppe einer Gruppe übernommen. Also, wie funktioniert das? Die oberste Ebene dafür ist der gesamte Standort. Dies wird in der Site->Globale Konfiguration->Berechtigungen eingerichtet, wie unten gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Das erste, was man bemerken sollte, sind die zehn Aktionen: Standortlogin, Admin-Login, Offline-Zugriff, Superuser, Access Administration Interface, Erstellen, Löschen, Bearbeiten, Status bearbeiten und Eigenes bearbeiten. Dies sind die Aktionen, die ein Benutzer an einem Objekt in Joomla durchführen kann. Die spezifische Bedeutung jeder Aktion hängt vom Kontext ab. Für das Bild Globale Konfiguration sind sie wie folgt definiert:

Site Login : Login to the front end of the site

;Admin Login : Melden Sie sich am Backend der Website an.

Offline-Zugriff: Melden Sie sich am Frontend der Website an, wenn die Website offline ist (wenn die globale Konfigurationseinstellung "Site Offline" auf Ja gesetzt ist).

Superuser: Gewährt dem Benutzer den Status "Superuser". Benutzer mit dieser Berechtigung dürfen alles auf der Website machen. Nur Benutzer mit dieser Berechtigung können die Einstellungen der globalen Konfiguration ändern. Diese Berechtigungen können nicht eingeschränkt werden. Es ist wichtig zu verstehen, dass, wenn ein Benutzer Mitglied einer Super Admin-Gruppe ist, alle anderen Berechtigungen, die diesem Benutzer zugewiesen sind, irrelevant sind. Der Benutzer kann jede Aktion auf der Website durchführen. Es können jedoch weiterhin Zugriffsebenen zugewiesen werden, um zu steuern, was diese Gruppe auf der Website sieht. (Natürlich kann ein Super-Admin-Benutzer die Zugriffsebenen ändern, wenn er möchte, so dass die Zugriffsebenen nicht vollständig einschränken, was ein Super-Admin-Benutzer sehen kann.)

Zugangskomponente: Öffnen Sie die Bildschirme der Komponentenverwaltung (Benutzerverwaltung, Menüverwaltung, Artikelverwaltung usw.).

;Create : Create new objects (for example, users, menu items, articles, weblinks, and so on)

;Löschen : Löschen eines existienden Objekts

;Ändern : Ändern eines existierenden Objektes

;Ändern eines Objekt Status (Veröffentlicht, nicht Veröffentlicht, Archiviert und Gelöscht)

Eigene Objekte bearbeiten: Bearbeiten Sie Objekte, die Sie erstellt haben.

Each Group for the site has its own slider which is opened by clicking on the group name. In this case (with the sample data installed), we have the standard 7 groups that we had in version 1.5 plus two additional groups called "Shop Suppliers" and "Customer Group". Notice that our groups are set up with the same permissions as they had in version 1.5. Keep in mind that we can change any of these permissions to make the security work the way we want. Let's go through this to see how it works.

* '''Public''' has everything set to "Not set", as shown below.{{-}}[[Image:Screenshot_global_acl_public_J3_tutorial-en.png]]
**This can be a bit confusing. Basically, "Not Set" is the same as "Inherited". Because Public is our top-level group, and because Global Configuration is the top level of the component hierarchy, there is nothing to inherit from. So "Not Set" is used instead of "Inherit".
**The default in this case is for no permissions. So, as you would expect, the Public group has no special permissions. Also, it is important to note that, since nothing is set to Denied, all of these permissions may be overridden by child groups or by lower levels in the permission hierarchy.

* '''Guest''' is a 'child' group of the Public group has everything set to 'Inherited' {{-}}[[Image:Screenshot_global_acl_guest_J3_tutorial-de.png]]
** This is the default 'Guest User Group' in the User Manager options and the Group that (non logged in) visitors to your site are placed in.

* '''Manager''' is a "child" group of the Public group. It has Allowed permissions for everything except Access Component and Super Admin. So a member of this group can do everything in the front and back end of the site except change Global Permissions and Component Options. {{-}}[[Image:Screenshot_global_acl_manager_J3_tutorial-en.png]]

* '''Administrator''' group members inherit all of the Manager permissions and also have Allowed for Access Component. So members of this group by default can access the Options screens for each component. {{-}}[[Image:Screenshot_global_acl_administrator_J3_tutorial-en.png]]

* '''Registered''' is the same a Public except for the Allow permission for the Site Login action. This means that members of the Registered group can login to the site. Since default permissions are inherited, this means that, unless a child group overrides this permission, all child groups of the Registered group will be able to login as well. {{-}}[[Image:Screenshot_global_acl_registered_J3_tutorial-en.png]]

* '''Author''' is a child of the Registered group and inherits its permissions and also adds Create and Edit Own. Since Author, Editor, and Publisher have no back-end permissions, we will discuss them below, when we discuss front-end permissions.{{-}}[[Image:Screenshot_global_acl_author_J3_tutorial-en.png]]

* '''Editor''' is a child of the Authors group and adds the Edit permission. {{-}}[[Image:Screenshot_global_acl_editor_J3_tutorial-en.png]]

* '''Publisher''' is a child of Editor and adds the Edit State permission.{{-}}[[Image:Screenshot_global_acl_publisher_J3_tutorial-en.png]]

* '''Shop Suppliers''' is an example group that is installed if you install the sample data. It is a child group of Author.

* '''Customer Group''' is an example group that is installed if you install the sample data. It is a child group of Registered.

* '''Super Users''' group has the Allow permission for the Super Admin action. Because of this, members of this group have super user permissions throughout the site. They are the only users who can access and edit values on the Global Configuration screen. Users with permission for the Super Admin action have some special characteristics:
:* If a user has Super Admin permissions, no other permissions for this user matter. The user can perform any action on the site.
:* Only Super Admin users can create, edit, or delete other Super Admin users or groups.

There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.

This provides a lot of flexibility. For example, if you wanted Shop Suppliers to be able to have the ability to login to the back end, you could just change their Admin Login value to "Allowed". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherited (or Denied).

It is also important to understand that the ability to have child groups is completely optional. It allows you to save some time when setting up new groups. However, if you like, you can set up all groups to have Public as the parent and not inherit any permissions from a parent group.

===Komponenten-Optionen & Berechtigungen===

Now, let's continue to see how the default back-end permissions for version 2.5 mimic the permissions for version 1.5. The Super Users group in 2.5 is equivalent to the Super Administrator group in 1.5.

Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 2.5 configuration. Let's see how this is accomplished.

If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:

[[Image:screenshot_acl_tutorial_20110111-09-en.png|center|]]
[[Image:screenshot_acl_tutorial_20110111-10-en.png|center|]]

This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.

First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.

Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.

If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.

In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.

It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.

===Frontend Berechtigungen===

Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions. First, let's look at the permissions for Manager, as shown below.
[[Image:screenshot_acl_tutorial_20110111-11a-en.png|center|frame]]
Manager has allowed permission for all actions except Configure. So members of the Manager group can do everything with Articles except open the Options screen.

Now let's look at Administrator, as shown below.
[[Image:screenshot_acl_tutorial_20110111-12a-en.png|center|frame]]
Administrator has Allowed for Configure, so Administrators can edit this Options screen.

Both groups can create, delete, edit, and change the state of articles.

Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set.

Authors only have Create and Edit Own permissions, as shown below.
[[Image:screenshot_acl_tutorial_20110112-07-en.png|center|frame]]
This means that Authors can create articles and can edit articles they have created. They may not delete articles, change the published state of articles, or edit articles created by others.

Editors have the same permissions as Authors with the addition of permission for the Edit action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-08-en.png|center|frame]]
So Editors can edit articles written by anyone.

Publishers can do everything Editors can do plus they have permission for the Edit State action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-09-en.png|center|frame]]
So Publishers can change the published state of an article. The possible states include Published, Unpublished, Archived, and Trashed.

All of these groups have Inherit permission for Configure and Access Component. Remember that Author is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Configure and Access Component, and since Author's permission for these actions is "Inherited", then Author does not have these permissions either. This same permission is passed from Author to Editor and from Editor to Publisher. So, by default, none of these groups are allowed to work with articles in the back end.

It is important to remember that these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.

Beachte auch das in den ursprünglichen Standardwerten keine Berechtigungen auf Verweigert eingestellt sind. Dies ermöglicht in allen Berechtigungsebenen die jeweilige Berechtigung auf Erlaubt einzustellen. Bedenke, wenn eine Aktion auf Verweigert eingestellt ist, das diese Aktion auch in allen untergeordneten Ebenen in der Berechtigungshierarchie verweigert wird. Zum Beispiel, wenn die Seitenameldung für Registered auf Verweigert (anstatt auf Erlaubt) eingestellt wird, kann man Publishers diese Aktion per Berechtigungeinstellung nicht erteilen.

=== Beitrags-Manager & Aktions-Diagramm ===

The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.

[[Image:screenshot_acl_tutorial_20110111-16-en.png|center|]]

* '''Configure''' allows you to view and change the Options for the component.
* '''Access Component''' allows you to navigate to the Article Manager. Without this permission, no other actions are possible.
* '''Create''' allows you to add new articles.
* '''Delete''' allows you to delete trashed articles. Note that the Delete icon only shows in the toolbar when you have the "Select State" filter set to "Trash".
* '''Edit''' allows you to edit existing articles.
* '''Edit State''' allows to you Publish, Unpublish, Archive, or Trash articles.
* '''Edit Own''' is the same as Edit except that it only applies to articles written by you.

==Allowing Guest-Only Access to Menu Items and Modules==

Version 1.6 introduced the ability to create a View Access Level that is only for guests of the site (meaning a user who is not logged in). The example below shows how you can set up this new feature.
''(N.B. Steps 1 to 3 are not needed for Joomla! 3.x as they exist in the default install)''

#Create a new user group called Guest. Make it a child of the Public group as shown below. [[Image:screenshot_acl_tutorial_20110112-01-en.png|center|frame]]
# Create a new access level called Guest and grant only the Guest group access to this level, as shown below.[[Image:screenshot_acl_tutorial_20110112-02-en.png|center|frame]]
# Navigate to User Manager→Options→Component and change the Guest User Group from the default value of "Public" to "Guest", as shown below.
[[Image:screenshot_acl_tutorial_20110112-04-en.png|center|frame]]
Now, if we assign a menu item, module, or other object to the Guest access level, only non-logged in users will have access. For example, if we create a new menu item with access level of Guest, as shown below,
[[Image:screenshot_acl_tutorial_20110112-05-en.png|center|frame]]
this menu item will only be visible to non-logged-in visitors to the site.

If required other user groups like Author can be granted access in the Guest access level, this would allow Authors to view articles in the front end for editing.

'''N.B. Login/logout in front end (''for changing data in session'') to see the change.'''

==Berechtigungen und Gruppenebenen gemeinsam nutzen==

As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.

This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:

* both groups can create new articles only in the History Assignments category.

* only History Teachers (not Assistant History Teachers) can Publish or otherwise have Edit State permission.

This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.

[[Image:Acl example diagram1 20091018-en.png|center|]]

In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.

To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.

Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.

[[Image:Acl example diagram2 20091018-en.png|center|]]

This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.

Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.

==ACL Aktion Berechtigungs-Beispiele==

===Backend Beitrag Administrator===

'''Problem:'''

We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.

'''Lösung:'''

# Create a new group called Article Administrator and make its parent group Public, as shown below.[[Image:screenshot_acl_tutorial_20110112-10-en.png|center|frame]] Because its parent group is Public, it won't have any permissions by default.
# In Users → Access Levels, edit the Special Access level to add the new group. That way they can get access to the back end menu items and modules (This assumes that the modules for the admin menu and quickicons have the Special Access level assigned to them, which is the default.) [[Image:screenshot_acl_tutorial_20110112-11-en.png|center|frame]] By default, the back-end menu items and modules are set to Special access, so if you forget to add the new group to the Special access level, you won't see any modules or menu items when you log in as a user of the new group.
# In Site → Global Configuration → Permissions, click on the Article Administrator group and change the permissions to Allowed for the following actions: Admin Login, Create, Delete, Edit, Edit State, and Edit Own. The screen below shows what will show before you press Save. [[Image:screenshot_acl_tutorial_20110112-12-en.png|center|frame]]After you save, the Calculated Permissions should show as shown below.[[Image:screenshot_acl_tutorial_20110112-13-en.png|center|frame]]Note that the permission for the Access Component is Inherited, which translates to Not Allowed. This is important. This means that this group will only be able to access components if we give the group "Allowed" permission for Access Component. So we only have to change the one component we want to give them access to and don't have to change any settings for the components where we don't want them to have access. If we had a case where we wanted to give a group access to everything except for one component, we could set the default to Allowed and then set the one component to Denied. Also note that we did not give the group Site Login permission, so users in this group will not be able to log into the front end. (If we wanted to allow that, we would just change the permission to Allowed for Site Login.)
# In Article Manager → Options → Permissions, change permissions to Allowed for this group for the Access Component action, as shown below.[[Image:screenshot_acl_tutorial_20110112-14-en.png|center|frame]]All of the other desired permissions are inherited.

That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end. For example, the screen below shows what a user in the Article Manager will see when they login to the back end.[[Image:screenshot_acl_tutorial_20110112-15-en.png|center|frame]]

==ACL Ansicht Zugriffsebenen-Beispiele==

A basic concept of using Access Levels is that all items with the same Access will be viewable by the same group of users. In other words, if two items have the same Access, you can't have one viewable by one user and not viewable by another user. On the other hand, it is easy to have one Group view any number of items with different Access levels.

Similarly, each Group has exactly the same combination of Access levels, but one User can be a member of more than one group. Depending on the situation, you may want to have users only in one Group or you may need to have a User in more than one Group.

This means that we may need to group our items so that items so that all items in a group have the same level of sensitivity. Here are some examples.

===Hierarchisches Beispiel===
In this example, Access levels are hierarchical, for example, like government security clearance codes. Say for example we have the following sets of classified documents: Classified, Secret, and Top Secret. Users have corresponding clearence codes. Users with Classified clearance can only see Classified documents and cannot see Secret or Top Secret. Users with Secret clearance can see Classified and Secret documents but not Top Secret. Users with Top Secret can see all documents.

In this case, you would create three Access levels: Classified, Secret, and Top Secret and the same three Groups. Users would only be members of one group, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| C1, C2, C3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Classified
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| S1, S2, S3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| TS1, TS2, TS3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Top Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret, Top Secret

|}

In this case, all users are in exactly one group, but some groups have access to more than one Access Level of items. In other words, we have a one-to-one relationship between users and groups, but a one-to-many relationship between Groups and Access Levels.

===Teamsicherheit Beispiel===

Another possible use case is a set of non-hierarchical teams. Let's say we have three teams, T1, T2, and T3. Some users are only on one team, but others might be on two or more teams. In this case, we could set up our Access Levels and Groups by team. Documents for each team have the access level for that team, and the Group for the team has only the one access level. When a User is on more than one team, they get added to the group for each team, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Beschreibung
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 1 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 2 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 3 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1, 2 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1,T2, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2, T3

|}

===Hybrid Example===

In a real-world situation, you might have a combination of these two arrangements. Say for example we have Managers and Staff. Staff can only see Staff documents and Managers can see Manager and Staff documents. Both types of users can be assigned to teams as well, in which case they can see all of the documents for that team. In addition, say that Managers can access some, but not all, team documents. Staff can only access team documents if they are members of that team.

In this example, we could set up the following Access Levels:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Access Level
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Description
| style="border:0.0007in solid #000000;padding:0.0382in;"| Groups

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team manager documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team staff documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team1 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1, Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team2 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2, Manager

|}

Then, users could be assigned to groups as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| User Type
| style="border:0.0007in solid #000000;padding:0.0382in;"| Group

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1, Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1, Team2

|}

<noinclude>
[[Category:Joomla! 1.6]]
[[Category:Joomla! 2.5]]
[[Category:Joomla! 3.x/de]]
[[Category:Tutorials/de]]
[[Category:Access Control/de]]
[[Category:Access Management]]
</noinclude>

Translations:J3.x:Access Control List Tutorial/210/de

2019-12-26T19:07:06Z

Sieger66:

J3.x:Access Control List Tutorial/de

2019-12-26T19:06:58Z

Sieger66:

<noinclude><languages /></noinclude>
{{Joomla version|version=3.x|comment=Serie}}
{{-}}
{{:J3.1:Access_Control_List/en}}

==Separate ACL für Anzeige und Aktionen==

Das Joomla ACL-System besteht genau genommen aus zwei völlig getrennten Systemen. Das eine System steuert, was Benutzer auf der Website "sehen" können. Das andere steuert, was Benutzer "tun" können (welche Aktionen ein Benutzer durchführen kann). Die ACL wird für jedes dieser Systeme anders eingerichtet.

===Steuern, was Benutzer sehen können===

Das Setup zum Steuern, was Benutzer sehen können, sieht wie folgt aus:
*Eine Reihe von Zugriffsebenen gemäß den Kategorien und/oder der Kombination von Kategorien erstellen, die nur angemeldete Benutzer sehen sollen. Anmerkung: Zu diesem Zeitpunkt werden noch keine Benutzergruppen den neuen Zugriffsebenen zugewiesen.

*Für jede Zugriffsebene eine Benutzergruppe erstellen, die 'Registriert' als übergeordnete Gruppe hat. Indem man für Benutzergruppen und Zugriffsebenen die gleichen Namen verwendet, kann man Verwirrungen zu einem späteren Zeitpunkt vorbeugen.

*Die neuen Zugriffsebenen bearbeiten und jeder die (neue) Benutzergruppe zuweisen. Wahrscheinlich möchten man auch die 'Super Benutzer' Gruppe (und/oder die anderen Standard-Benutzergruppen mit Ausnahme der Benutzergruppe 'Gast') den neuen Zugriffsebenen zuweisen.

*Jedem anzuzeigenden Eintrag eine Zugriffsebene zuweisen. Einträge sind sowohl inhaltliche Einträge (Beiträge, Kontakte, usw.), Menüeinträge als auch Module.

Immer dann, wenn ein Benutzer im Begriff ist, einen Eintrag auf einer Joomla-Seite anzeigen zu lassen, prüft das Programm, ob dieser Benutzer auch Zugriff auf den Eintrag hat. Das geschieht folgendermaßen:
# Zunächst wird eine Liste aller Zugriffsebenen erstellt, auf die der Benutzer zugreifen kann, basierend auf allen Gruppen, denen der Benutzer angehört. Sofern eine Gruppe eine übergeordnete Gruppe besitzt, sind die Zugriffsebenen für die übergeordnete Gruppe ebenfalls in der Liste enthalten.
# Danach wird überprüft, ob die Zugriffsebene für den Eintrag (Beitrag, Modul, Menüeintrag, usw.) in dieser Liste enthalten ist. Wenn dem so ist, wird der Eintrag dem Benutzer angezeigt. Falls der Benutzer die benötigten Zugriffsrechte besitzt, wird ihm der Zugriff verweigert.

Beachten, dass Zugriffsebenen für jede Gruppe separat festgelegt und nicht von der übergeordneten Gruppe einer Gruppe vererbt werden.

===Steuern, was Benutzer tun können===

Das System, das steuert, was Benutzer in einer Benutzergruppe tun können - welche Aktionen sie bei einem bestimmten Eintrag ausführen können - wird über den Tab 'Berechtigungen' in der Konfiguration und den Tab 'Berechtigungen' in den Optionen jeder einzelnen Komponente eingerichtet. Berechtigungen können auch auf Kategorienebene (bei Kernkomponenten) und auf Beitragsebene (bei Beiträgen) gesetzt werden.

* Wenn angemeldete Benutzer in bestimmten Kategorien Erstellen, Löschen, Status bearbeiten oder Eigene Inhalte bearbeiten dürfen, dann:
** Eine Benutzergruppe erstellen und als übergeordnete Gruppe eine der Benutzergruppen angeben, die Zugriff auf die Kategorie (oder Kategorien) haben, die diese neue Benutzergruppe ändern soll.
**Der neuen Benutzergruppe den entsprechenden Zugriffsebenen zuweisen. Dann die erforderlichen Berechtigungen für die neue Benutzergruppe entweder global oder pro Kategorie/Beitrag ändern.
*** Beim Erstellen einer Benutzergruppe ist es ratsam, eine übergeordnete Gruppe zu wählen, die über weniger Berechtigungen verfügt, als für die neue Gruppe erforderlich. Denn es ist einfacher, die Berechtigungen für jede Komponente/Kategorie/Beitrag zu erweitern, für die zusätzliche Berechtigungen nötig sind, als Berechtigungen aus den anderen Komponenten/Kategorien/Beiträgen zu entfernen.
****''(Beispiel: Es gibt 10 Kategorien, man möchte aber nur für eine Erstellen-Berechtigungen. Würde man für diese Gruppe die Berechtigungen global auf Erstellen erlaubt setzen, müsste man für diese Kategorien die Erstellen-Berechtigung entfernen. Und man müsste für diese Gruppe die Erstellen-Berechtigung bei jeder neuen Kategorie, die man zu einem späteren Zeitpunkt hinzufügt, ebenfalls entfernen).''
** Eine Benutzergruppe erstellen, die eine der Standardbenutzergruppen als übergeordnete Gruppe hat, NUR, wenn keine von diesen über die exakten Berechtigungen verfügt, die man benötigt und sich für alle Kategorien wünscht.

Beachten, dass dieses Setup unabhängig vom Setup für die Anzeige ist. Allerdings muss eine Benutzergruppe den entsprechenden Zugriffsebenen zugewiesen werden, damit der Benutzer in dieser Gruppe jene Berechtigungen verwenden kann.

Möchte ein Benutzer eine bestimmte Aktion bei einem Komponenten-Eintrag durchführen (z. B. einen Beitrag bearbeiten), überprüft das System (nachdem es überprüft hat, welcher Gruppe der Benutzer angehört und auf welche er Zugriff hat) die Berechtigung für diese Kombination aus Benutzer, Eintrag und Aktion. Liegt eine Erlaubnis vor, kann der Benutzer fortfahren. Andernfalls ist die Aktion nicht zulässig.

Das restliche Tutorial befasst sich mit der Steuerung, was Benutzer tun können - welche Aktionsberechtigungen sie haben.

==Aktionen, Gruppen und Vererbung==

Andererseits geht es bei der ACL auch darum, Benutzern Berechtigungen zu erteilen, damit diese Aktionen an Objekten durchführen können.

{| class="wikitable"
!style="width:20%;"|
!3.x Serie
|-
!Gruppen und Aktionen
|Aktionen, welche pro Gruppe erlaubt sind, werden durch den Website Administrator festgelegt.
|-
!Umfang von Berechtigungen
|Berechtigungen können auf mehreren Ebenen in der Hierarchie festgelegt werden: Website, Komponente, Kategorie, Objekt.
|-
!Vererbung von Berechtigungen
|Berechtigungen können von übergeordneten Gruppen und übergeordneten Kategorien geerbt werden.
|}

===Wie die Berechtigungen funktionieren===

Es gibt vier mögliche Berechtigungen für Aktionen. Diese sind (kurz skizziert):

* '''Nicht gesetzt''': Fällt standardmäßig auf "Nicht erlaubt" zurück. Aber im Gegensatz zur Berechtigung "Verweigert" kann diese Berechtigung außer Kraft gesetzt werden, wenn eine untergeordnete Gruppe oder eine in der Berechtigungshierarchie untergeordnete Ebene auf "Erlaubt" gesetzt wird. Diese Berechtigung kann nur für globale Berechtigungen der Konfiguration gesetzt werden.
* '''Vererbt''': Erbt den Wert von einer übergeordneten Gruppe oder einer in der Berechtigungshierarchie höheren Ebene. Diese Berechtigung gilt für alle Ebenen mit Ausnahme der obersten Ebene der Konfiguration.
* '''Verweigert''': Verbietet diese Aktion für diese Ebene und Gruppe. '''WICHTIG:''' Dadurch wird diese Aktion auch für alle untergeordneten Gruppen und alle untergeordneten Ebenen in der Berechtigungshierarchie verboten. Wird "Erlaubt" in einer untergeordneten Gruppe oder einer tieferen Ebene gesetzt, hat das keinen Effekt. Die Aktion wird immer für alle Mitglieder einer untergeordneten Gruppe und für alle untergeordneten Ebenen in der Berechtigungshierarchie abgelehnt.
* '''Erlaubt ''': Genehmigt diese Aktion für diese Ebene und Gruppe und für tiefere Ebenen und Untergruppen. Dies hat keine Auswirkungen, wenn eine höhere Gruppe oder Ebene auf "Verweigert" oder "Erlaubt" eingestellt ist. Wenn eine höhere Gruppe oder ein höheres Ebene auf "Verweigert" gesetzt ist, wird diese Berechtigung immer abgelehnt. Wenn eine höhere Gruppe oder Ebene auf Erlaubt eingestellt ist, ist diese Berechtigung bereits erlaubt.

===Hierarchie der Berechtigungsebenen===

Berechtigungen für Aktionen können in Version 2.5+ auf bis zu vier Ebenen festgelegt werden, wie folgt:
# '''Konfiguration''': legt die Standardberechtigungen für jede Aktion und Gruppe fest.
# '''Komponenten-Optionen-> Berechtigungen''': kann die Standardberechtigungen für diese Komponente überschreiben (z. B. Beiträge, Menüs, Benutzer, Banner usw.).
# '''Kategorie''': kann die Standardberechtigungen für Objekte in einer oder mehreren Kategorien überschreiben. Gilt für alle Komponenten mit Kategorien, einschließlich Beiträge, Banner, Kontakte, Newsfeeds und Weblinks.
# '''Beitrag''': kann die Berechtigungen für einen bestimmten Artikel überschreiben. Diese Ebene gilt nur für Beiträge. Alle anderen Komponenten erlauben nur die ersten drei Ebenen.

====Konfiguration====
Diese erreicht man über System → Konfiguration → Berechtigungen. Die nun sichtbare Maske dient dazu, die Berechtigungen auf der obersten Ebene für jede Gruppe und jede Aktion festzulegen, wie auch in der folgenden Abbildung gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Die möglichen Werte sind Vererbt, Erlaubt oder Verweigert. Die Spalte 'Errechnete Einstellung' zeigt die aktuelle Einstellung an. Diese ist entweder Nicht erlaubt (Standard), Erlaubt oder Nicht erlaubt.

Man kann immer nur an einer Gruppe gleichzeitig arbeiten, indem man den Reiter für ebendiese Gruppe anklickt. Die Berechtigungen kann man über die Dropdownlisten unter Neue Einstellung wählen ändern.

Beachten Sie, dass die Spalte "Errechnete Einstellung" erst aktualisiert wird, wenn Sie auf die Schaltfläche "Speichern" in der Werkzeugleiste klicken.

Um zu überprüfen, ob die Einstellungen Ihren Wünschen entsprechen, klicken Sie auf die Schaltfläche Speichern und überprüfen anschließend die Spalte Errechnete Einstellung.

====Komponenten-Optionen->Berechtigungen====
Auf diese wird für jede Komponente durch Klicken auf das Symbol "Optionen" in der Werkzeugleiste zugegriffen. Dieser Bildschirm ist ähnlich wie der Bildschirm "Globale Konfiguration" oben links. Wenn Sie beispielsweise im Menü-Manager auf das Symbol in der Werkzeugleiste Optionen klicken, werden die folgenden Menüs angezeigt.
[[Image:Screenshot_menu_acl_J3_tutorial-en.jpg]]

Der Zugriff auf Optionen ist nur für Mitglieder von Gruppen möglich, die die Berechtigung für die Aktion Konfiguration in für jede Komponente haben. Im obigen Beispiel hat die Gruppe Administrator die Berechtigung Erlaubt für die Option Konfigurieren, so dass Mitglieder dieser Gruppe auf diesen Bildschirm zugreifen können.

===Kategorie===
Auf die Kategorieberechtigungen wird im Category Manager zugegriffen: Bildschirm Kategorie bearbeiten, in einer Registerkarte oben auf dem Bildschirm. Dieser Bildschirm hat fünf Berechtigungen, wie folgt:

[[Image:Screenshot_category_acl_j3_tutorial-en.png]]

In diesen Bildern bearbeiten Sie die Berechtigungen für jeweils eine Benutzergruppe. Im obigen Beispiel bearbeiten Sie die Berechtigungen für die Gruppe Administrator.

Achten Sie darauf, dass die Aktionen "Konfigurieren und Zugriffssteuerung" nicht auf der Kategorieebene angewendet werden, so dass diese Aktionen nicht enthalten sind.

Beachten Sie auch, dass Kategorien in einer Hierarchie angeordnet werden können. Wenn ja, dann werden Aktionsberechtigungen in einer übergeordneten Kategorie automatisch an eine untergeordnete Kategorie vererbt. Wenn Sie beispielsweise eine Kategoriehierarchie von Tieren → Haustiere → Hunde hätten, dann würde die vollständige Berechtigungshierarchie für einen Artikel in der Kategorie Hunde wie folgt aussehen:
* Globale Konfiguration
* Artikel-Manager → Optionen → Genehmigung → Erlaubnis
* Tierkategorie
* Kategorie Haustiere
* Kategorie Hunde
* spezifischer Artikel

====Beitrag====
Berechtigungen für einzelne Beiträge findet man im "Beitrag" unter dem Tab-Reiter "Berechigungen". Dieser Bildschirm hat drei Aktionen, wie unten gezeigt.

[[Image:j3x_acl_tutorial_article_manager_article_permissions-en.png]]

Auch hier bearbeiten Sie jede Gruppe für sich. Um auf die Berechtigungen zuzugreifen wechseln Sie im Artikel auf den Reiter "Berechtigungen" im oberen Reiter. Über das Drop Down Menü wählen Sie die neue Berechtigung im Anschluss speichern Sie den Beitrag ab.

Beachten Sie, dass die Aktionen Configure, Access Component und Create auf Artikelebene nicht gelten, so dass diese Aktionen nicht berücksichtigt werden. Die Berechtigung zum Anlegen eines Artikels wird auf einer der höheren Ebenen der Hierarchie festgelegt.

===Zugriffsebenen===

Die Zugriffsebenen der 3.x-Serie sind einfach und flexibel. Der folgende Bildschirm zeigt die spezielle Zugriffsebene.
[[Image:j3x_acl_tutorial_viewing_levels-en.png|center]]
Aktivieren Sie einfach das Kontrollkästchen für jede Gruppe, die Sie in diesem Level aufnehmen wollen. Die spezielle Zugriffsebene umfasst die Gruppen Manager, Autor und Superuser. Es beinhaltet auch untergeordnete Gruppen dieser Gruppen. Die Gruppe Administrator ist also enthalten, da es sich um eine Untergruppe der Gruppe Manager handelt. Die Gruppen Editor, Publisher und Shop Suppliers sind enthalten, da es sich um Untergruppen des Autors handelt.

Jedem Objekt im Frontend ist eine Zugriffsebene zugeordnet. Wenn die Ebene öffentlich ist, kann jeder auf dieses Objekt zugreifen. Andernfalls dürfen nur Mitglieder von Gruppen, die dieser Zugriffsebene zugeordnet sind, auf dieses Objekt zugreifen.

Die Zugriffsebenen sind den Menüpunkten und den Modulen zugeordnet. Jede kann nur einer Zugriffsebene zugeordnet werden.

Der folgende Bildschirm zeigt beispielsweise den Bildschirm Menüpunkt bearbeiten mit der Liste der verfügbaren Zugriffsebenen....

[[Image:j3x_acl_tutorial_edit_menu_item_level_dropdown-en.png|center]]

==Standard-ACL-Setup==

Wenn Joomla! installiert ist, werden diese auf die ursprünglichen Standardwerte gesetzt. Wir werden diese Grundeinstellungen besprechen, um die Arbeitsweise der ACL zu verstehen.

===Standardgruppen===

Mit der Version 3.x können Sie Ihre individuellen Gruppen definieren. Wenn Sie die Version 3.x installieren, enthält sie eine Reihe von Standardgruppen, die im Folgenden dargestellt werden, sind die grundlegenden Standardbenutzergruppen. (Zusätzliche Standardbenutzergruppen werden mit Beispieldaten installiert)

[[Image:Screenshot_usergroupsl_acl_J3_tutorial-en.png|center]]

Die Pfeile zeigen die untergeordneten Elternbeziehungen an. Wie vorstehend besprochen, wird diese Berechtigung, wenn Sie eine Berechtigung für eine übergeordnete Gruppe festlegen, automatisch an alle Untergruppen vererbt. Die vererbten und zulässigen Berechtigungen können für eine Untergruppe überschrieben werden. Die Berechtigung Verweigert kann nicht überschrieben werden und verweigert immer eine Aktion für alle Untergruppen.

===Konfiguration===

Joomla! Version 3.x wird mit den gleichen bekannten Backend-Rechten wie die Version 1.5 (EOL) installiert. Mit der Version 3.x können Sie diese jedoch leicht an die Bedürfnisse Ihrer Website anpassen.

Wie bereits besprochen, werden die Berechtigungen für jede Aktion von der obigen Ebene in der Berechtigungshierarchie und von der übergeordneten Gruppe einer Gruppe übernommen. Also, wie funktioniert das? Die oberste Ebene dafür ist der gesamte Standort. Dies wird in der Site->Globale Konfiguration->Berechtigungen eingerichtet, wie unten gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Das erste, was man bemerken sollte, sind die zehn Aktionen: Standortlogin, Admin-Login, Offline-Zugriff, Superuser, Access Administration Interface, Erstellen, Löschen, Bearbeiten, Status bearbeiten und Eigenes bearbeiten. Dies sind die Aktionen, die ein Benutzer an einem Objekt in Joomla durchführen kann. Die spezifische Bedeutung jeder Aktion hängt vom Kontext ab. Für das Bild Globale Konfiguration sind sie wie folgt definiert:

Site Login : Login to the front end of the site

;Admin Login : Melden Sie sich am Backend der Website an.

Offline-Zugriff: Melden Sie sich am Frontend der Website an, wenn die Website offline ist (wenn die globale Konfigurationseinstellung "Site Offline" auf Ja gesetzt ist).

Superuser: Gewährt dem Benutzer den Status "Superuser". Benutzer mit dieser Berechtigung dürfen alles auf der Website machen. Nur Benutzer mit dieser Berechtigung können die Einstellungen der globalen Konfiguration ändern. Diese Berechtigungen können nicht eingeschränkt werden. Es ist wichtig zu verstehen, dass, wenn ein Benutzer Mitglied einer Super Admin-Gruppe ist, alle anderen Berechtigungen, die diesem Benutzer zugewiesen sind, irrelevant sind. Der Benutzer kann jede Aktion auf der Website durchführen. Es können jedoch weiterhin Zugriffsebenen zugewiesen werden, um zu steuern, was diese Gruppe auf der Website sieht. (Natürlich kann ein Super-Admin-Benutzer die Zugriffsebenen ändern, wenn er möchte, so dass die Zugriffsebenen nicht vollständig einschränken, was ein Super-Admin-Benutzer sehen kann.)

Zugangskomponente: Öffnen Sie die Bildschirme der Komponentenverwaltung (Benutzerverwaltung, Menüverwaltung, Artikelverwaltung usw.).

;Create : Create new objects (for example, users, menu items, articles, weblinks, and so on)

;Löschen : Löschen eines existienden Objekts

;Ändern : Ändern eines existierenden Objektes

;Ändern eines Objekt Status (Veröffentlicht, nicht Veröffentlicht, Archiviert und Gelöscht)

Eigene Objekte bearbeiten: Bearbeiten Sie Objekte, die Sie erstellt haben.

Each Group for the site has its own slider which is opened by clicking on the group name. In this case (with the sample data installed), we have the standard 7 groups that we had in version 1.5 plus two additional groups called "Shop Suppliers" and "Customer Group". Notice that our groups are set up with the same permissions as they had in version 1.5. Keep in mind that we can change any of these permissions to make the security work the way we want. Let's go through this to see how it works.

* '''Public''' has everything set to "Not set", as shown below.{{-}}[[Image:Screenshot_global_acl_public_J3_tutorial-en.png]]
**This can be a bit confusing. Basically, "Not Set" is the same as "Inherited". Because Public is our top-level group, and because Global Configuration is the top level of the component hierarchy, there is nothing to inherit from. So "Not Set" is used instead of "Inherit".
**The default in this case is for no permissions. So, as you would expect, the Public group has no special permissions. Also, it is important to note that, since nothing is set to Denied, all of these permissions may be overridden by child groups or by lower levels in the permission hierarchy.

* '''Guest''' is a 'child' group of the Public group has everything set to 'Inherited' {{-}}[[Image:Screenshot_global_acl_guest_J3_tutorial-de.png]]
** This is the default 'Guest User Group' in the User Manager options and the Group that (non logged in) visitors to your site are placed in.

* '''Manager''' is a "child" group of the Public group. It has Allowed permissions for everything except Access Component and Super Admin. So a member of this group can do everything in the front and back end of the site except change Global Permissions and Component Options. {{-}}[[Image:Screenshot_global_acl_manager_J3_tutorial-en.png]]

* '''Administrator''' group members inherit all of the Manager permissions and also have Allowed for Access Component. So members of this group by default can access the Options screens for each component. {{-}}[[Image:Screenshot_global_acl_administrator_J3_tutorial-en.png]]

* '''Registered''' is the same a Public except for the Allow permission for the Site Login action. This means that members of the Registered group can login to the site. Since default permissions are inherited, this means that, unless a child group overrides this permission, all child groups of the Registered group will be able to login as well. {{-}}[[Image:Screenshot_global_acl_registered_J3_tutorial-en.png]]

* '''Author''' is a child of the Registered group and inherits its permissions and also adds Create and Edit Own. Since Author, Editor, and Publisher have no back-end permissions, we will discuss them below, when we discuss front-end permissions.{{-}}[[Image:Screenshot_global_acl_author_J3_tutorial-en.png]]

* '''Editor''' is a child of the Authors group and adds the Edit permission. {{-}}[[Image:Screenshot_global_acl_editor_J3_tutorial-en.png]]

* '''Publisher''' is a child of Editor and adds the Edit State permission.{{-}}[[Image:Screenshot_global_acl_publisher_J3_tutorial-en.png]]

* '''Shop Suppliers''' is an example group that is installed if you install the sample data. It is a child group of Author.

* '''Customer Group''' is an example group that is installed if you install the sample data. It is a child group of Registered.

* '''Super Users''' group has the Allow permission for the Super Admin action. Because of this, members of this group have super user permissions throughout the site. They are the only users who can access and edit values on the Global Configuration screen. Users with permission for the Super Admin action have some special characteristics:
:* If a user has Super Admin permissions, no other permissions for this user matter. The user can perform any action on the site.
:* Only Super Admin users can create, edit, or delete other Super Admin users or groups.

There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.

This provides a lot of flexibility. For example, if you wanted Shop Suppliers to be able to have the ability to login to the back end, you could just change their Admin Login value to "Allowed". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherited (or Denied).

It is also important to understand that the ability to have child groups is completely optional. It allows you to save some time when setting up new groups. However, if you like, you can set up all groups to have Public as the parent and not inherit any permissions from a parent group.

===Komponenten-Optionen & Berechtigungen===

Now, let's continue to see how the default back-end permissions for version 2.5 mimic the permissions for version 1.5. The Super Users group in 2.5 is equivalent to the Super Administrator group in 1.5.

Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 2.5 configuration. Let's see how this is accomplished.

If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:

[[Image:screenshot_acl_tutorial_20110111-09-en.png|center|]]
[[Image:screenshot_acl_tutorial_20110111-10-en.png|center|]]

This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.

First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.

Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.

If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.

In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.

It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.

===Frontend Berechtigungen===

Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions. First, let's look at the permissions for Manager, as shown below.
[[Image:screenshot_acl_tutorial_20110111-11a-en.png|center|frame]]
Manager has allowed permission for all actions except Configure. So members of the Manager group can do everything with Articles except open the Options screen.

Now let's look at Administrator, as shown below.
[[Image:screenshot_acl_tutorial_20110111-12a-en.png|center|frame]]
Administrator has Allowed for Configure, so Administrators can edit this Options screen.

Both groups can create, delete, edit, and change the state of articles.

Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set.

Authors only have Create and Edit Own permissions, as shown below.
[[Image:screenshot_acl_tutorial_20110112-07-en.png|center|frame]]
This means that Authors can create articles and can edit articles they have created. They may not delete articles, change the published state of articles, or edit articles created by others.

Editors have the same permissions as Authors with the addition of permission for the Edit action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-08-en.png|center|frame]]
So Editors can edit articles written by anyone.

Publishers can do everything Editors can do plus they have permission for the Edit State action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-09-en.png|center|frame]]
So Publishers can change the published state of an article. The possible states include Published, Unpublished, Archived, and Trashed.

All of these groups have Inherit permission for Configure and Access Component. Remember that Author is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Configure and Access Component, and since Author's permission for these actions is "Inherited", then Author does not have these permissions either. This same permission is passed from Author to Editor and from Editor to Publisher. So, by default, none of these groups are allowed to work with articles in the back end.

It is important to remember that these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.

Beachte auch das in den ursprünglichen Standardwerten keine Berechtigungen auf Verweigert eingestellt sind. Dies ermöglicht in allen Berechtigungsebenen die jeweilige Berechtigung auf Erlaubt einzustellen. Bedenke, wenn eine Aktion auf Verweigert eingestellt ist, das diese Aktion auch in allen untergeordneten Ebenen in der Berechtigungshierarchie verweigert wird. Zum Beispiel, wenn die Seitenameldung für Registered auf Verweigert (anstatt auf Erlaubt) eingestellt wird, kann man Publishers diese Aktion per Berechtigungeinstellung nicht erteilen.

=== Beitrags-Manager & Aktions-Diagramm ===

The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.

[[Image:screenshot_acl_tutorial_20110111-16-en.png|center|]]

* '''Configure''' allows you to view and change the Options for the component.
* '''Access Component''' allows you to navigate to the Article Manager. Without this permission, no other actions are possible.
* '''Create''' allows you to add new articles.
* '''Delete''' allows you to delete trashed articles. Note that the Delete icon only shows in the toolbar when you have the "Select State" filter set to "Trash".
* '''Edit''' allows you to edit existing articles.
* '''Edit State''' allows to you Publish, Unpublish, Archive, or Trash articles.
* '''Edit Own''' is the same as Edit except that it only applies to articles written by you.

==Allowing Guest-Only Access to Menu Items and Modules==

Version 1.6 introduced the ability to create a View Access Level that is only for guests of the site (meaning a user who is not logged in). The example below shows how you can set up this new feature.
''(N.B. Steps 1 to 3 are not needed for Joomla! 3.x as they exist in the default install)''

#Create a new user group called Guest. Make it a child of the Public group as shown below. [[Image:screenshot_acl_tutorial_20110112-01-en.png|center|frame]]
# Create a new access level called Guest and grant only the Guest group access to this level, as shown below.[[Image:screenshot_acl_tutorial_20110112-02-en.png|center|frame]]
# Navigate to User Manager→Options→Component and change the Guest User Group from the default value of "Public" to "Guest", as shown below.
[[Image:screenshot_acl_tutorial_20110112-04-en.png|center|frame]]
Now, if we assign a menu item, module, or other object to the Guest access level, only non-logged in users will have access. For example, if we create a new menu item with access level of Guest, as shown below,
[[Image:screenshot_acl_tutorial_20110112-05-en.png|center|frame]]
this menu item will only be visible to non-logged-in visitors to the site.

If required other user groups like Author can be granted access in the Guest access level, this would allow Authors to view articles in the front end for editing.

'''N.B. Login/logout in front end (''for changing data in session'') to see the change.'''

==Berechtigungen und Gruppenebenen gemeinsam nutzen==

As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.

This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:

* both groups can create new articles only in the History Assignments category.

* only History Teachers (not Assistant History Teachers) can Publish or otherwise have Edit State permission.

This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.

[[Image:Acl example diagram1 20091018-en.png|center|]]

In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.

To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.

Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.

[[Image:Acl example diagram2 20091018-en.png|center|]]

This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.

Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.

==ACL Aktion Berechtigungs-Beispiele==

===Backend Beitrag Administrator===

'''Problem:'''

We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.

'''Lösung:'''

# Create a new group called Article Administrator and make its parent group Public, as shown below.[[Image:screenshot_acl_tutorial_20110112-10-en.png|center|frame]] Because its parent group is Public, it won't have any permissions by default.
# In Users → Access Levels, edit the Special Access level to add the new group. That way they can get access to the back end menu items and modules (This assumes that the modules for the admin menu and quickicons have the Special Access level assigned to them, which is the default.) [[Image:screenshot_acl_tutorial_20110112-11-en.png|center|frame]] By default, the back-end menu items and modules are set to Special access, so if you forget to add the new group to the Special access level, you won't see any modules or menu items when you log in as a user of the new group.
# In Site → Global Configuration → Permissions, click on the Article Administrator group and change the permissions to Allowed for the following actions: Admin Login, Create, Delete, Edit, Edit State, and Edit Own. The screen below shows what will show before you press Save. [[Image:screenshot_acl_tutorial_20110112-12-en.png|center|frame]]After you save, the Calculated Permissions should show as shown below.[[Image:screenshot_acl_tutorial_20110112-13-en.png|center|frame]]Note that the permission for the Access Component is Inherited, which translates to Not Allowed. This is important. This means that this group will only be able to access components if we give the group "Allowed" permission for Access Component. So we only have to change the one component we want to give them access to and don't have to change any settings for the components where we don't want them to have access. If we had a case where we wanted to give a group access to everything except for one component, we could set the default to Allowed and then set the one component to Denied. Also note that we did not give the group Site Login permission, so users in this group will not be able to log into the front end. (If we wanted to allow that, we would just change the permission to Allowed for Site Login.)
# In Article Manager → Options → Permissions, change permissions to Allowed for this group for the Access Component action, as shown below.[[Image:screenshot_acl_tutorial_20110112-14-en.png|center|frame]]All of the other desired permissions are inherited.

That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end. For example, the screen below shows what a user in the Article Manager will see when they login to the back end.[[Image:screenshot_acl_tutorial_20110112-15-de.png|center|frame]]

==ACL Ansicht Zugriffsebenen-Beispiele==

A basic concept of using Access Levels is that all items with the same Access will be viewable by the same group of users. In other words, if two items have the same Access, you can't have one viewable by one user and not viewable by another user. On the other hand, it is easy to have one Group view any number of items with different Access levels.

Similarly, each Group has exactly the same combination of Access levels, but one User can be a member of more than one group. Depending on the situation, you may want to have users only in one Group or you may need to have a User in more than one Group.

This means that we may need to group our items so that items so that all items in a group have the same level of sensitivity. Here are some examples.

===Hierarchisches Beispiel===
In this example, Access levels are hierarchical, for example, like government security clearance codes. Say for example we have the following sets of classified documents: Classified, Secret, and Top Secret. Users have corresponding clearence codes. Users with Classified clearance can only see Classified documents and cannot see Secret or Top Secret. Users with Secret clearance can see Classified and Secret documents but not Top Secret. Users with Top Secret can see all documents.

In this case, you would create three Access levels: Classified, Secret, and Top Secret and the same three Groups. Users would only be members of one group, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| C1, C2, C3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Classified
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| S1, S2, S3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| TS1, TS2, TS3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Top Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret, Top Secret

|}

In this case, all users are in exactly one group, but some groups have access to more than one Access Level of items. In other words, we have a one-to-one relationship between users and groups, but a one-to-many relationship between Groups and Access Levels.

===Teamsicherheit Beispiel===

Another possible use case is a set of non-hierarchical teams. Let's say we have three teams, T1, T2, and T3. Some users are only on one team, but others might be on two or more teams. In this case, we could set up our Access Levels and Groups by team. Documents for each team have the access level for that team, and the Group for the team has only the one access level. When a User is on more than one team, they get added to the group for each team, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Beschreibung
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 1 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 2 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 3 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1, 2 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1,T2, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2, T3

|}

===Hybrid Example===

In a real-world situation, you might have a combination of these two arrangements. Say for example we have Managers and Staff. Staff can only see Staff documents and Managers can see Manager and Staff documents. Both types of users can be assigned to teams as well, in which case they can see all of the documents for that team. In addition, say that Managers can access some, but not all, team documents. Staff can only access team documents if they are members of that team.

In this example, we could set up the following Access Levels:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Access Level
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Description
| style="border:0.0007in solid #000000;padding:0.0382in;"| Groups

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team manager documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team staff documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team1 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1, Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team2 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2, Manager

|}

Then, users could be assigned to groups as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| User Type
| style="border:0.0007in solid #000000;padding:0.0382in;"| Group

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1, Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1, Team2

|}

<noinclude>
[[Category:Joomla! 1.6]]
[[Category:Joomla! 2.5]]
[[Category:Joomla! 3.x/de]]
[[Category:Tutorials/de]]
[[Category:Access Control/de]]
[[Category:Access Management]]
</noinclude>

Translations:J3.x:Access Control List Tutorial/207/de

2019-12-26T19:06:58Z

Sieger66:

J3.x:Access Control List Tutorial/de

2019-12-26T19:06:50Z

Sieger66:

<noinclude><languages /></noinclude>
{{Joomla version|version=3.x|comment=Serie}}
{{-}}
{{:J3.1:Access_Control_List/en}}

==Separate ACL für Anzeige und Aktionen==

Das Joomla ACL-System besteht genau genommen aus zwei völlig getrennten Systemen. Das eine System steuert, was Benutzer auf der Website "sehen" können. Das andere steuert, was Benutzer "tun" können (welche Aktionen ein Benutzer durchführen kann). Die ACL wird für jedes dieser Systeme anders eingerichtet.

===Steuern, was Benutzer sehen können===

Das Setup zum Steuern, was Benutzer sehen können, sieht wie folgt aus:
*Eine Reihe von Zugriffsebenen gemäß den Kategorien und/oder der Kombination von Kategorien erstellen, die nur angemeldete Benutzer sehen sollen. Anmerkung: Zu diesem Zeitpunkt werden noch keine Benutzergruppen den neuen Zugriffsebenen zugewiesen.

*Für jede Zugriffsebene eine Benutzergruppe erstellen, die 'Registriert' als übergeordnete Gruppe hat. Indem man für Benutzergruppen und Zugriffsebenen die gleichen Namen verwendet, kann man Verwirrungen zu einem späteren Zeitpunkt vorbeugen.

*Die neuen Zugriffsebenen bearbeiten und jeder die (neue) Benutzergruppe zuweisen. Wahrscheinlich möchten man auch die 'Super Benutzer' Gruppe (und/oder die anderen Standard-Benutzergruppen mit Ausnahme der Benutzergruppe 'Gast') den neuen Zugriffsebenen zuweisen.

*Jedem anzuzeigenden Eintrag eine Zugriffsebene zuweisen. Einträge sind sowohl inhaltliche Einträge (Beiträge, Kontakte, usw.), Menüeinträge als auch Module.

Immer dann, wenn ein Benutzer im Begriff ist, einen Eintrag auf einer Joomla-Seite anzeigen zu lassen, prüft das Programm, ob dieser Benutzer auch Zugriff auf den Eintrag hat. Das geschieht folgendermaßen:
# Zunächst wird eine Liste aller Zugriffsebenen erstellt, auf die der Benutzer zugreifen kann, basierend auf allen Gruppen, denen der Benutzer angehört. Sofern eine Gruppe eine übergeordnete Gruppe besitzt, sind die Zugriffsebenen für die übergeordnete Gruppe ebenfalls in der Liste enthalten.
# Danach wird überprüft, ob die Zugriffsebene für den Eintrag (Beitrag, Modul, Menüeintrag, usw.) in dieser Liste enthalten ist. Wenn dem so ist, wird der Eintrag dem Benutzer angezeigt. Falls der Benutzer die benötigten Zugriffsrechte besitzt, wird ihm der Zugriff verweigert.

Beachten, dass Zugriffsebenen für jede Gruppe separat festgelegt und nicht von der übergeordneten Gruppe einer Gruppe vererbt werden.

===Steuern, was Benutzer tun können===

Das System, das steuert, was Benutzer in einer Benutzergruppe tun können - welche Aktionen sie bei einem bestimmten Eintrag ausführen können - wird über den Tab 'Berechtigungen' in der Konfiguration und den Tab 'Berechtigungen' in den Optionen jeder einzelnen Komponente eingerichtet. Berechtigungen können auch auf Kategorienebene (bei Kernkomponenten) und auf Beitragsebene (bei Beiträgen) gesetzt werden.

* Wenn angemeldete Benutzer in bestimmten Kategorien Erstellen, Löschen, Status bearbeiten oder Eigene Inhalte bearbeiten dürfen, dann:
** Eine Benutzergruppe erstellen und als übergeordnete Gruppe eine der Benutzergruppen angeben, die Zugriff auf die Kategorie (oder Kategorien) haben, die diese neue Benutzergruppe ändern soll.
**Der neuen Benutzergruppe den entsprechenden Zugriffsebenen zuweisen. Dann die erforderlichen Berechtigungen für die neue Benutzergruppe entweder global oder pro Kategorie/Beitrag ändern.
*** Beim Erstellen einer Benutzergruppe ist es ratsam, eine übergeordnete Gruppe zu wählen, die über weniger Berechtigungen verfügt, als für die neue Gruppe erforderlich. Denn es ist einfacher, die Berechtigungen für jede Komponente/Kategorie/Beitrag zu erweitern, für die zusätzliche Berechtigungen nötig sind, als Berechtigungen aus den anderen Komponenten/Kategorien/Beiträgen zu entfernen.
****''(Beispiel: Es gibt 10 Kategorien, man möchte aber nur für eine Erstellen-Berechtigungen. Würde man für diese Gruppe die Berechtigungen global auf Erstellen erlaubt setzen, müsste man für diese Kategorien die Erstellen-Berechtigung entfernen. Und man müsste für diese Gruppe die Erstellen-Berechtigung bei jeder neuen Kategorie, die man zu einem späteren Zeitpunkt hinzufügt, ebenfalls entfernen).''
** Eine Benutzergruppe erstellen, die eine der Standardbenutzergruppen als übergeordnete Gruppe hat, NUR, wenn keine von diesen über die exakten Berechtigungen verfügt, die man benötigt und sich für alle Kategorien wünscht.

Beachten, dass dieses Setup unabhängig vom Setup für die Anzeige ist. Allerdings muss eine Benutzergruppe den entsprechenden Zugriffsebenen zugewiesen werden, damit der Benutzer in dieser Gruppe jene Berechtigungen verwenden kann.

Möchte ein Benutzer eine bestimmte Aktion bei einem Komponenten-Eintrag durchführen (z. B. einen Beitrag bearbeiten), überprüft das System (nachdem es überprüft hat, welcher Gruppe der Benutzer angehört und auf welche er Zugriff hat) die Berechtigung für diese Kombination aus Benutzer, Eintrag und Aktion. Liegt eine Erlaubnis vor, kann der Benutzer fortfahren. Andernfalls ist die Aktion nicht zulässig.

Das restliche Tutorial befasst sich mit der Steuerung, was Benutzer tun können - welche Aktionsberechtigungen sie haben.

==Aktionen, Gruppen und Vererbung==

Andererseits geht es bei der ACL auch darum, Benutzern Berechtigungen zu erteilen, damit diese Aktionen an Objekten durchführen können.

{| class="wikitable"
!style="width:20%;"|
!3.x Serie
|-
!Gruppen und Aktionen
|Aktionen, welche pro Gruppe erlaubt sind, werden durch den Website Administrator festgelegt.
|-
!Umfang von Berechtigungen
|Berechtigungen können auf mehreren Ebenen in der Hierarchie festgelegt werden: Website, Komponente, Kategorie, Objekt.
|-
!Vererbung von Berechtigungen
|Berechtigungen können von übergeordneten Gruppen und übergeordneten Kategorien geerbt werden.
|}

===Wie die Berechtigungen funktionieren===

Es gibt vier mögliche Berechtigungen für Aktionen. Diese sind (kurz skizziert):

* '''Nicht gesetzt''': Fällt standardmäßig auf "Nicht erlaubt" zurück. Aber im Gegensatz zur Berechtigung "Verweigert" kann diese Berechtigung außer Kraft gesetzt werden, wenn eine untergeordnete Gruppe oder eine in der Berechtigungshierarchie untergeordnete Ebene auf "Erlaubt" gesetzt wird. Diese Berechtigung kann nur für globale Berechtigungen der Konfiguration gesetzt werden.
* '''Vererbt''': Erbt den Wert von einer übergeordneten Gruppe oder einer in der Berechtigungshierarchie höheren Ebene. Diese Berechtigung gilt für alle Ebenen mit Ausnahme der obersten Ebene der Konfiguration.
* '''Verweigert''': Verbietet diese Aktion für diese Ebene und Gruppe. '''WICHTIG:''' Dadurch wird diese Aktion auch für alle untergeordneten Gruppen und alle untergeordneten Ebenen in der Berechtigungshierarchie verboten. Wird "Erlaubt" in einer untergeordneten Gruppe oder einer tieferen Ebene gesetzt, hat das keinen Effekt. Die Aktion wird immer für alle Mitglieder einer untergeordneten Gruppe und für alle untergeordneten Ebenen in der Berechtigungshierarchie abgelehnt.
* '''Erlaubt ''': Genehmigt diese Aktion für diese Ebene und Gruppe und für tiefere Ebenen und Untergruppen. Dies hat keine Auswirkungen, wenn eine höhere Gruppe oder Ebene auf "Verweigert" oder "Erlaubt" eingestellt ist. Wenn eine höhere Gruppe oder ein höheres Ebene auf "Verweigert" gesetzt ist, wird diese Berechtigung immer abgelehnt. Wenn eine höhere Gruppe oder Ebene auf Erlaubt eingestellt ist, ist diese Berechtigung bereits erlaubt.

===Hierarchie der Berechtigungsebenen===

Berechtigungen für Aktionen können in Version 2.5+ auf bis zu vier Ebenen festgelegt werden, wie folgt:
# '''Konfiguration''': legt die Standardberechtigungen für jede Aktion und Gruppe fest.
# '''Komponenten-Optionen-> Berechtigungen''': kann die Standardberechtigungen für diese Komponente überschreiben (z. B. Beiträge, Menüs, Benutzer, Banner usw.).
# '''Kategorie''': kann die Standardberechtigungen für Objekte in einer oder mehreren Kategorien überschreiben. Gilt für alle Komponenten mit Kategorien, einschließlich Beiträge, Banner, Kontakte, Newsfeeds und Weblinks.
# '''Beitrag''': kann die Berechtigungen für einen bestimmten Artikel überschreiben. Diese Ebene gilt nur für Beiträge. Alle anderen Komponenten erlauben nur die ersten drei Ebenen.

====Konfiguration====
Diese erreicht man über System → Konfiguration → Berechtigungen. Die nun sichtbare Maske dient dazu, die Berechtigungen auf der obersten Ebene für jede Gruppe und jede Aktion festzulegen, wie auch in der folgenden Abbildung gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Die möglichen Werte sind Vererbt, Erlaubt oder Verweigert. Die Spalte 'Errechnete Einstellung' zeigt die aktuelle Einstellung an. Diese ist entweder Nicht erlaubt (Standard), Erlaubt oder Nicht erlaubt.

Man kann immer nur an einer Gruppe gleichzeitig arbeiten, indem man den Reiter für ebendiese Gruppe anklickt. Die Berechtigungen kann man über die Dropdownlisten unter Neue Einstellung wählen ändern.

Beachten Sie, dass die Spalte "Errechnete Einstellung" erst aktualisiert wird, wenn Sie auf die Schaltfläche "Speichern" in der Werkzeugleiste klicken.

Um zu überprüfen, ob die Einstellungen Ihren Wünschen entsprechen, klicken Sie auf die Schaltfläche Speichern und überprüfen anschließend die Spalte Errechnete Einstellung.

====Komponenten-Optionen->Berechtigungen====
Auf diese wird für jede Komponente durch Klicken auf das Symbol "Optionen" in der Werkzeugleiste zugegriffen. Dieser Bildschirm ist ähnlich wie der Bildschirm "Globale Konfiguration" oben links. Wenn Sie beispielsweise im Menü-Manager auf das Symbol in der Werkzeugleiste Optionen klicken, werden die folgenden Menüs angezeigt.
[[Image:Screenshot_menu_acl_J3_tutorial-en.jpg]]

Der Zugriff auf Optionen ist nur für Mitglieder von Gruppen möglich, die die Berechtigung für die Aktion Konfiguration in für jede Komponente haben. Im obigen Beispiel hat die Gruppe Administrator die Berechtigung Erlaubt für die Option Konfigurieren, so dass Mitglieder dieser Gruppe auf diesen Bildschirm zugreifen können.

===Kategorie===
Auf die Kategorieberechtigungen wird im Category Manager zugegriffen: Bildschirm Kategorie bearbeiten, in einer Registerkarte oben auf dem Bildschirm. Dieser Bildschirm hat fünf Berechtigungen, wie folgt:

[[Image:Screenshot_category_acl_j3_tutorial-en.png]]

In diesen Bildern bearbeiten Sie die Berechtigungen für jeweils eine Benutzergruppe. Im obigen Beispiel bearbeiten Sie die Berechtigungen für die Gruppe Administrator.

Achten Sie darauf, dass die Aktionen "Konfigurieren und Zugriffssteuerung" nicht auf der Kategorieebene angewendet werden, so dass diese Aktionen nicht enthalten sind.

Beachten Sie auch, dass Kategorien in einer Hierarchie angeordnet werden können. Wenn ja, dann werden Aktionsberechtigungen in einer übergeordneten Kategorie automatisch an eine untergeordnete Kategorie vererbt. Wenn Sie beispielsweise eine Kategoriehierarchie von Tieren → Haustiere → Hunde hätten, dann würde die vollständige Berechtigungshierarchie für einen Artikel in der Kategorie Hunde wie folgt aussehen:
* Globale Konfiguration
* Artikel-Manager → Optionen → Genehmigung → Erlaubnis
* Tierkategorie
* Kategorie Haustiere
* Kategorie Hunde
* spezifischer Artikel

====Beitrag====
Berechtigungen für einzelne Beiträge findet man im "Beitrag" unter dem Tab-Reiter "Berechigungen". Dieser Bildschirm hat drei Aktionen, wie unten gezeigt.

[[Image:j3x_acl_tutorial_article_manager_article_permissions-en.png]]

Auch hier bearbeiten Sie jede Gruppe für sich. Um auf die Berechtigungen zuzugreifen wechseln Sie im Artikel auf den Reiter "Berechtigungen" im oberen Reiter. Über das Drop Down Menü wählen Sie die neue Berechtigung im Anschluss speichern Sie den Beitrag ab.

Beachten Sie, dass die Aktionen Configure, Access Component und Create auf Artikelebene nicht gelten, so dass diese Aktionen nicht berücksichtigt werden. Die Berechtigung zum Anlegen eines Artikels wird auf einer der höheren Ebenen der Hierarchie festgelegt.

===Zugriffsebenen===

Die Zugriffsebenen der 3.x-Serie sind einfach und flexibel. Der folgende Bildschirm zeigt die spezielle Zugriffsebene.
[[Image:j3x_acl_tutorial_viewing_levels-en.png|center]]
Aktivieren Sie einfach das Kontrollkästchen für jede Gruppe, die Sie in diesem Level aufnehmen wollen. Die spezielle Zugriffsebene umfasst die Gruppen Manager, Autor und Superuser. Es beinhaltet auch untergeordnete Gruppen dieser Gruppen. Die Gruppe Administrator ist also enthalten, da es sich um eine Untergruppe der Gruppe Manager handelt. Die Gruppen Editor, Publisher und Shop Suppliers sind enthalten, da es sich um Untergruppen des Autors handelt.

Jedem Objekt im Frontend ist eine Zugriffsebene zugeordnet. Wenn die Ebene öffentlich ist, kann jeder auf dieses Objekt zugreifen. Andernfalls dürfen nur Mitglieder von Gruppen, die dieser Zugriffsebene zugeordnet sind, auf dieses Objekt zugreifen.

Die Zugriffsebenen sind den Menüpunkten und den Modulen zugeordnet. Jede kann nur einer Zugriffsebene zugeordnet werden.

Der folgende Bildschirm zeigt beispielsweise den Bildschirm Menüpunkt bearbeiten mit der Liste der verfügbaren Zugriffsebenen....

[[Image:j3x_acl_tutorial_edit_menu_item_level_dropdown-en.png|center]]

==Standard-ACL-Setup==

Wenn Joomla! installiert ist, werden diese auf die ursprünglichen Standardwerte gesetzt. Wir werden diese Grundeinstellungen besprechen, um die Arbeitsweise der ACL zu verstehen.

===Standardgruppen===

Mit der Version 3.x können Sie Ihre individuellen Gruppen definieren. Wenn Sie die Version 3.x installieren, enthält sie eine Reihe von Standardgruppen, die im Folgenden dargestellt werden, sind die grundlegenden Standardbenutzergruppen. (Zusätzliche Standardbenutzergruppen werden mit Beispieldaten installiert)

[[Image:Screenshot_usergroupsl_acl_J3_tutorial-en.png|center]]

Die Pfeile zeigen die untergeordneten Elternbeziehungen an. Wie vorstehend besprochen, wird diese Berechtigung, wenn Sie eine Berechtigung für eine übergeordnete Gruppe festlegen, automatisch an alle Untergruppen vererbt. Die vererbten und zulässigen Berechtigungen können für eine Untergruppe überschrieben werden. Die Berechtigung Verweigert kann nicht überschrieben werden und verweigert immer eine Aktion für alle Untergruppen.

===Konfiguration===

Joomla! Version 3.x wird mit den gleichen bekannten Backend-Rechten wie die Version 1.5 (EOL) installiert. Mit der Version 3.x können Sie diese jedoch leicht an die Bedürfnisse Ihrer Website anpassen.

Wie bereits besprochen, werden die Berechtigungen für jede Aktion von der obigen Ebene in der Berechtigungshierarchie und von der übergeordneten Gruppe einer Gruppe übernommen. Also, wie funktioniert das? Die oberste Ebene dafür ist der gesamte Standort. Dies wird in der Site->Globale Konfiguration->Berechtigungen eingerichtet, wie unten gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Das erste, was man bemerken sollte, sind die zehn Aktionen: Standortlogin, Admin-Login, Offline-Zugriff, Superuser, Access Administration Interface, Erstellen, Löschen, Bearbeiten, Status bearbeiten und Eigenes bearbeiten. Dies sind die Aktionen, die ein Benutzer an einem Objekt in Joomla durchführen kann. Die spezifische Bedeutung jeder Aktion hängt vom Kontext ab. Für das Bild Globale Konfiguration sind sie wie folgt definiert:

Site Login : Login to the front end of the site

;Admin Login : Melden Sie sich am Backend der Website an.

Offline-Zugriff: Melden Sie sich am Frontend der Website an, wenn die Website offline ist (wenn die globale Konfigurationseinstellung "Site Offline" auf Ja gesetzt ist).

Superuser: Gewährt dem Benutzer den Status "Superuser". Benutzer mit dieser Berechtigung dürfen alles auf der Website machen. Nur Benutzer mit dieser Berechtigung können die Einstellungen der globalen Konfiguration ändern. Diese Berechtigungen können nicht eingeschränkt werden. Es ist wichtig zu verstehen, dass, wenn ein Benutzer Mitglied einer Super Admin-Gruppe ist, alle anderen Berechtigungen, die diesem Benutzer zugewiesen sind, irrelevant sind. Der Benutzer kann jede Aktion auf der Website durchführen. Es können jedoch weiterhin Zugriffsebenen zugewiesen werden, um zu steuern, was diese Gruppe auf der Website sieht. (Natürlich kann ein Super-Admin-Benutzer die Zugriffsebenen ändern, wenn er möchte, so dass die Zugriffsebenen nicht vollständig einschränken, was ein Super-Admin-Benutzer sehen kann.)

Zugangskomponente: Öffnen Sie die Bildschirme der Komponentenverwaltung (Benutzerverwaltung, Menüverwaltung, Artikelverwaltung usw.).

;Create : Create new objects (for example, users, menu items, articles, weblinks, and so on)

;Löschen : Löschen eines existienden Objekts

;Ändern : Ändern eines existierenden Objektes

;Ändern eines Objekt Status (Veröffentlicht, nicht Veröffentlicht, Archiviert und Gelöscht)

Eigene Objekte bearbeiten: Bearbeiten Sie Objekte, die Sie erstellt haben.

Each Group for the site has its own slider which is opened by clicking on the group name. In this case (with the sample data installed), we have the standard 7 groups that we had in version 1.5 plus two additional groups called "Shop Suppliers" and "Customer Group". Notice that our groups are set up with the same permissions as they had in version 1.5. Keep in mind that we can change any of these permissions to make the security work the way we want. Let's go through this to see how it works.

* '''Public''' has everything set to "Not set", as shown below.{{-}}[[Image:Screenshot_global_acl_public_J3_tutorial-en.png]]
**This can be a bit confusing. Basically, "Not Set" is the same as "Inherited". Because Public is our top-level group, and because Global Configuration is the top level of the component hierarchy, there is nothing to inherit from. So "Not Set" is used instead of "Inherit".
**The default in this case is for no permissions. So, as you would expect, the Public group has no special permissions. Also, it is important to note that, since nothing is set to Denied, all of these permissions may be overridden by child groups or by lower levels in the permission hierarchy.

* '''Guest''' is a 'child' group of the Public group has everything set to 'Inherited' {{-}}[[Image:Screenshot_global_acl_guest_J3_tutorial-de.png]]
** This is the default 'Guest User Group' in the User Manager options and the Group that (non logged in) visitors to your site are placed in.

* '''Manager''' is a "child" group of the Public group. It has Allowed permissions for everything except Access Component and Super Admin. So a member of this group can do everything in the front and back end of the site except change Global Permissions and Component Options. {{-}}[[Image:Screenshot_global_acl_manager_J3_tutorial-en.png]]

* '''Administrator''' group members inherit all of the Manager permissions and also have Allowed for Access Component. So members of this group by default can access the Options screens for each component. {{-}}[[Image:Screenshot_global_acl_administrator_J3_tutorial-en.png]]

* '''Registered''' is the same a Public except for the Allow permission for the Site Login action. This means that members of the Registered group can login to the site. Since default permissions are inherited, this means that, unless a child group overrides this permission, all child groups of the Registered group will be able to login as well. {{-}}[[Image:Screenshot_global_acl_registered_J3_tutorial-en.png]]

* '''Author''' is a child of the Registered group and inherits its permissions and also adds Create and Edit Own. Since Author, Editor, and Publisher have no back-end permissions, we will discuss them below, when we discuss front-end permissions.{{-}}[[Image:Screenshot_global_acl_author_J3_tutorial-en.png]]

* '''Editor''' is a child of the Authors group and adds the Edit permission. {{-}}[[Image:Screenshot_global_acl_editor_J3_tutorial-en.png]]

* '''Publisher''' is a child of Editor and adds the Edit State permission.{{-}}[[Image:Screenshot_global_acl_publisher_J3_tutorial-en.png]]

* '''Shop Suppliers''' is an example group that is installed if you install the sample data. It is a child group of Author.

* '''Customer Group''' is an example group that is installed if you install the sample data. It is a child group of Registered.

* '''Super Users''' group has the Allow permission for the Super Admin action. Because of this, members of this group have super user permissions throughout the site. They are the only users who can access and edit values on the Global Configuration screen. Users with permission for the Super Admin action have some special characteristics:
:* If a user has Super Admin permissions, no other permissions for this user matter. The user can perform any action on the site.
:* Only Super Admin users can create, edit, or delete other Super Admin users or groups.

There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.

This provides a lot of flexibility. For example, if you wanted Shop Suppliers to be able to have the ability to login to the back end, you could just change their Admin Login value to "Allowed". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherited (or Denied).

It is also important to understand that the ability to have child groups is completely optional. It allows you to save some time when setting up new groups. However, if you like, you can set up all groups to have Public as the parent and not inherit any permissions from a parent group.

===Komponenten-Optionen & Berechtigungen===

Now, let's continue to see how the default back-end permissions for version 2.5 mimic the permissions for version 1.5. The Super Users group in 2.5 is equivalent to the Super Administrator group in 1.5.

Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 2.5 configuration. Let's see how this is accomplished.

If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:

[[Image:screenshot_acl_tutorial_20110111-09-en.png|center|]]
[[Image:screenshot_acl_tutorial_20110111-10-en.png|center|]]

This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.

First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.

Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.

If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.

In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.

It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.

===Frontend Berechtigungen===

Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions. First, let's look at the permissions for Manager, as shown below.
[[Image:screenshot_acl_tutorial_20110111-11a-en.png|center|frame]]
Manager has allowed permission for all actions except Configure. So members of the Manager group can do everything with Articles except open the Options screen.

Now let's look at Administrator, as shown below.
[[Image:screenshot_acl_tutorial_20110111-12a-en.png|center|frame]]
Administrator has Allowed for Configure, so Administrators can edit this Options screen.

Both groups can create, delete, edit, and change the state of articles.

Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set.

Authors only have Create and Edit Own permissions, as shown below.
[[Image:screenshot_acl_tutorial_20110112-07-en.png|center|frame]]
This means that Authors can create articles and can edit articles they have created. They may not delete articles, change the published state of articles, or edit articles created by others.

Editors have the same permissions as Authors with the addition of permission for the Edit action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-08-en.png|center|frame]]
So Editors can edit articles written by anyone.

Publishers can do everything Editors can do plus they have permission for the Edit State action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-09-en.png|center|frame]]
So Publishers can change the published state of an article. The possible states include Published, Unpublished, Archived, and Trashed.

All of these groups have Inherit permission for Configure and Access Component. Remember that Author is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Configure and Access Component, and since Author's permission for these actions is "Inherited", then Author does not have these permissions either. This same permission is passed from Author to Editor and from Editor to Publisher. So, by default, none of these groups are allowed to work with articles in the back end.

It is important to remember that these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.

Beachte auch das in den ursprünglichen Standardwerten keine Berechtigungen auf Verweigert eingestellt sind. Dies ermöglicht in allen Berechtigungsebenen die jeweilige Berechtigung auf Erlaubt einzustellen. Bedenke, wenn eine Aktion auf Verweigert eingestellt ist, das diese Aktion auch in allen untergeordneten Ebenen in der Berechtigungshierarchie verweigert wird. Zum Beispiel, wenn die Seitenameldung für Registered auf Verweigert (anstatt auf Erlaubt) eingestellt wird, kann man Publishers diese Aktion per Berechtigungeinstellung nicht erteilen.

=== Beitrags-Manager & Aktions-Diagramm ===

The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.

[[Image:screenshot_acl_tutorial_20110111-16-en.png|center|]]

* '''Configure''' allows you to view and change the Options for the component.
* '''Access Component''' allows you to navigate to the Article Manager. Without this permission, no other actions are possible.
* '''Create''' allows you to add new articles.
* '''Delete''' allows you to delete trashed articles. Note that the Delete icon only shows in the toolbar when you have the "Select State" filter set to "Trash".
* '''Edit''' allows you to edit existing articles.
* '''Edit State''' allows to you Publish, Unpublish, Archive, or Trash articles.
* '''Edit Own''' is the same as Edit except that it only applies to articles written by you.

==Allowing Guest-Only Access to Menu Items and Modules==

Version 1.6 introduced the ability to create a View Access Level that is only for guests of the site (meaning a user who is not logged in). The example below shows how you can set up this new feature.
''(N.B. Steps 1 to 3 are not needed for Joomla! 3.x as they exist in the default install)''

#Create a new user group called Guest. Make it a child of the Public group as shown below. [[Image:screenshot_acl_tutorial_20110112-01-en.png|center|frame]]
# Create a new access level called Guest and grant only the Guest group access to this level, as shown below.[[Image:screenshot_acl_tutorial_20110112-02-en.png|center|frame]]
# Navigate to User Manager→Options→Component and change the Guest User Group from the default value of "Public" to "Guest", as shown below.
[[Image:screenshot_acl_tutorial_20110112-04-en.png|center|frame]]
Now, if we assign a menu item, module, or other object to the Guest access level, only non-logged in users will have access. For example, if we create a new menu item with access level of Guest, as shown below,
[[Image:screenshot_acl_tutorial_20110112-05-en.png|center|frame]]
this menu item will only be visible to non-logged-in visitors to the site.

If required other user groups like Author can be granted access in the Guest access level, this would allow Authors to view articles in the front end for editing.

'''N.B. Login/logout in front end (''for changing data in session'') to see the change.'''

==Berechtigungen und Gruppenebenen gemeinsam nutzen==

As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.

This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:

* both groups can create new articles only in the History Assignments category.

* only History Teachers (not Assistant History Teachers) can Publish or otherwise have Edit State permission.

This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.

[[Image:Acl example diagram1 20091018-en.png|center|]]

In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.

To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.

Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.

[[Image:Acl example diagram2 20091018-en.png|center|]]

This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.

Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.

==ACL Aktion Berechtigungs-Beispiele==

===Backend Beitrag Administrator===

'''Problem:'''

We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.

'''Lösung:'''

# Create a new group called Article Administrator and make its parent group Public, as shown below.[[Image:screenshot_acl_tutorial_20110112-10-en.png|center|frame]] Because its parent group is Public, it won't have any permissions by default.
# In Users → Access Levels, edit the Special Access level to add the new group. That way they can get access to the back end menu items and modules (This assumes that the modules for the admin menu and quickicons have the Special Access level assigned to them, which is the default.) [[Image:screenshot_acl_tutorial_20110112-11-en.png|center|frame]] By default, the back-end menu items and modules are set to Special access, so if you forget to add the new group to the Special access level, you won't see any modules or menu items when you log in as a user of the new group.
# In Site → Global Configuration → Permissions, click on the Article Administrator group and change the permissions to Allowed for the following actions: Admin Login, Create, Delete, Edit, Edit State, and Edit Own. The screen below shows what will show before you press Save. [[Image:screenshot_acl_tutorial_20110112-12-en.png|center|frame]]After you save, the Calculated Permissions should show as shown below.[[Image:screenshot_acl_tutorial_20110112-13-en.png|center|frame]]Note that the permission for the Access Component is Inherited, which translates to Not Allowed. This is important. This means that this group will only be able to access components if we give the group "Allowed" permission for Access Component. So we only have to change the one component we want to give them access to and don't have to change any settings for the components where we don't want them to have access. If we had a case where we wanted to give a group access to everything except for one component, we could set the default to Allowed and then set the one component to Denied. Also note that we did not give the group Site Login permission, so users in this group will not be able to log into the front end. (If we wanted to allow that, we would just change the permission to Allowed for Site Login.)
# In Article Manager → Options → Permissions, change permissions to Allowed for this group for the Access Component action, as shown below.[[Image:screenshot_acl_tutorial_20110112-14-de.png|center|frame]]All of the other desired permissions are inherited.

That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end. For example, the screen below shows what a user in the Article Manager will see when they login to the back end.[[Image:screenshot_acl_tutorial_20110112-15-de.png|center|frame]]

==ACL Ansicht Zugriffsebenen-Beispiele==

A basic concept of using Access Levels is that all items with the same Access will be viewable by the same group of users. In other words, if two items have the same Access, you can't have one viewable by one user and not viewable by another user. On the other hand, it is easy to have one Group view any number of items with different Access levels.

Similarly, each Group has exactly the same combination of Access levels, but one User can be a member of more than one group. Depending on the situation, you may want to have users only in one Group or you may need to have a User in more than one Group.

This means that we may need to group our items so that items so that all items in a group have the same level of sensitivity. Here are some examples.

===Hierarchisches Beispiel===
In this example, Access levels are hierarchical, for example, like government security clearance codes. Say for example we have the following sets of classified documents: Classified, Secret, and Top Secret. Users have corresponding clearence codes. Users with Classified clearance can only see Classified documents and cannot see Secret or Top Secret. Users with Secret clearance can see Classified and Secret documents but not Top Secret. Users with Top Secret can see all documents.

In this case, you would create three Access levels: Classified, Secret, and Top Secret and the same three Groups. Users would only be members of one group, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| C1, C2, C3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Classified
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| S1, S2, S3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| TS1, TS2, TS3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Top Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret, Top Secret

|}

In this case, all users are in exactly one group, but some groups have access to more than one Access Level of items. In other words, we have a one-to-one relationship between users and groups, but a one-to-many relationship between Groups and Access Levels.

===Teamsicherheit Beispiel===

Another possible use case is a set of non-hierarchical teams. Let's say we have three teams, T1, T2, and T3. Some users are only on one team, but others might be on two or more teams. In this case, we could set up our Access Levels and Groups by team. Documents for each team have the access level for that team, and the Group for the team has only the one access level. When a User is on more than one team, they get added to the group for each team, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Beschreibung
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 1 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 2 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 3 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1, 2 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1,T2, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2, T3

|}

===Hybrid Example===

In a real-world situation, you might have a combination of these two arrangements. Say for example we have Managers and Staff. Staff can only see Staff documents and Managers can see Manager and Staff documents. Both types of users can be assigned to teams as well, in which case they can see all of the documents for that team. In addition, say that Managers can access some, but not all, team documents. Staff can only access team documents if they are members of that team.

In this example, we could set up the following Access Levels:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Access Level
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Description
| style="border:0.0007in solid #000000;padding:0.0382in;"| Groups

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team manager documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team staff documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team1 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1, Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team2 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2, Manager

|}

Then, users could be assigned to groups as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| User Type
| style="border:0.0007in solid #000000;padding:0.0382in;"| Group

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1, Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1, Team2

|}

<noinclude>
[[Category:Joomla! 1.6]]
[[Category:Joomla! 2.5]]
[[Category:Joomla! 3.x/de]]
[[Category:Tutorials/de]]
[[Category:Access Control/de]]
[[Category:Access Management]]
</noinclude>

Translations:J3.x:Access Control List Tutorial/204/de

2019-12-26T19:06:49Z

Sieger66:

J3.x:Access Control List Tutorial/de

2019-12-26T19:06:41Z

Sieger66:

<noinclude><languages /></noinclude>
{{Joomla version|version=3.x|comment=Serie}}
{{-}}
{{:J3.1:Access_Control_List/en}}

==Separate ACL für Anzeige und Aktionen==

Das Joomla ACL-System besteht genau genommen aus zwei völlig getrennten Systemen. Das eine System steuert, was Benutzer auf der Website "sehen" können. Das andere steuert, was Benutzer "tun" können (welche Aktionen ein Benutzer durchführen kann). Die ACL wird für jedes dieser Systeme anders eingerichtet.

===Steuern, was Benutzer sehen können===

Das Setup zum Steuern, was Benutzer sehen können, sieht wie folgt aus:
*Eine Reihe von Zugriffsebenen gemäß den Kategorien und/oder der Kombination von Kategorien erstellen, die nur angemeldete Benutzer sehen sollen. Anmerkung: Zu diesem Zeitpunkt werden noch keine Benutzergruppen den neuen Zugriffsebenen zugewiesen.

*Für jede Zugriffsebene eine Benutzergruppe erstellen, die 'Registriert' als übergeordnete Gruppe hat. Indem man für Benutzergruppen und Zugriffsebenen die gleichen Namen verwendet, kann man Verwirrungen zu einem späteren Zeitpunkt vorbeugen.

*Die neuen Zugriffsebenen bearbeiten und jeder die (neue) Benutzergruppe zuweisen. Wahrscheinlich möchten man auch die 'Super Benutzer' Gruppe (und/oder die anderen Standard-Benutzergruppen mit Ausnahme der Benutzergruppe 'Gast') den neuen Zugriffsebenen zuweisen.

*Jedem anzuzeigenden Eintrag eine Zugriffsebene zuweisen. Einträge sind sowohl inhaltliche Einträge (Beiträge, Kontakte, usw.), Menüeinträge als auch Module.

Immer dann, wenn ein Benutzer im Begriff ist, einen Eintrag auf einer Joomla-Seite anzeigen zu lassen, prüft das Programm, ob dieser Benutzer auch Zugriff auf den Eintrag hat. Das geschieht folgendermaßen:
# Zunächst wird eine Liste aller Zugriffsebenen erstellt, auf die der Benutzer zugreifen kann, basierend auf allen Gruppen, denen der Benutzer angehört. Sofern eine Gruppe eine übergeordnete Gruppe besitzt, sind die Zugriffsebenen für die übergeordnete Gruppe ebenfalls in der Liste enthalten.
# Danach wird überprüft, ob die Zugriffsebene für den Eintrag (Beitrag, Modul, Menüeintrag, usw.) in dieser Liste enthalten ist. Wenn dem so ist, wird der Eintrag dem Benutzer angezeigt. Falls der Benutzer die benötigten Zugriffsrechte besitzt, wird ihm der Zugriff verweigert.

Beachten, dass Zugriffsebenen für jede Gruppe separat festgelegt und nicht von der übergeordneten Gruppe einer Gruppe vererbt werden.

===Steuern, was Benutzer tun können===

Das System, das steuert, was Benutzer in einer Benutzergruppe tun können - welche Aktionen sie bei einem bestimmten Eintrag ausführen können - wird über den Tab 'Berechtigungen' in der Konfiguration und den Tab 'Berechtigungen' in den Optionen jeder einzelnen Komponente eingerichtet. Berechtigungen können auch auf Kategorienebene (bei Kernkomponenten) und auf Beitragsebene (bei Beiträgen) gesetzt werden.

* Wenn angemeldete Benutzer in bestimmten Kategorien Erstellen, Löschen, Status bearbeiten oder Eigene Inhalte bearbeiten dürfen, dann:
** Eine Benutzergruppe erstellen und als übergeordnete Gruppe eine der Benutzergruppen angeben, die Zugriff auf die Kategorie (oder Kategorien) haben, die diese neue Benutzergruppe ändern soll.
**Der neuen Benutzergruppe den entsprechenden Zugriffsebenen zuweisen. Dann die erforderlichen Berechtigungen für die neue Benutzergruppe entweder global oder pro Kategorie/Beitrag ändern.
*** Beim Erstellen einer Benutzergruppe ist es ratsam, eine übergeordnete Gruppe zu wählen, die über weniger Berechtigungen verfügt, als für die neue Gruppe erforderlich. Denn es ist einfacher, die Berechtigungen für jede Komponente/Kategorie/Beitrag zu erweitern, für die zusätzliche Berechtigungen nötig sind, als Berechtigungen aus den anderen Komponenten/Kategorien/Beiträgen zu entfernen.
****''(Beispiel: Es gibt 10 Kategorien, man möchte aber nur für eine Erstellen-Berechtigungen. Würde man für diese Gruppe die Berechtigungen global auf Erstellen erlaubt setzen, müsste man für diese Kategorien die Erstellen-Berechtigung entfernen. Und man müsste für diese Gruppe die Erstellen-Berechtigung bei jeder neuen Kategorie, die man zu einem späteren Zeitpunkt hinzufügt, ebenfalls entfernen).''
** Eine Benutzergruppe erstellen, die eine der Standardbenutzergruppen als übergeordnete Gruppe hat, NUR, wenn keine von diesen über die exakten Berechtigungen verfügt, die man benötigt und sich für alle Kategorien wünscht.

Beachten, dass dieses Setup unabhängig vom Setup für die Anzeige ist. Allerdings muss eine Benutzergruppe den entsprechenden Zugriffsebenen zugewiesen werden, damit der Benutzer in dieser Gruppe jene Berechtigungen verwenden kann.

Möchte ein Benutzer eine bestimmte Aktion bei einem Komponenten-Eintrag durchführen (z. B. einen Beitrag bearbeiten), überprüft das System (nachdem es überprüft hat, welcher Gruppe der Benutzer angehört und auf welche er Zugriff hat) die Berechtigung für diese Kombination aus Benutzer, Eintrag und Aktion. Liegt eine Erlaubnis vor, kann der Benutzer fortfahren. Andernfalls ist die Aktion nicht zulässig.

Das restliche Tutorial befasst sich mit der Steuerung, was Benutzer tun können - welche Aktionsberechtigungen sie haben.

==Aktionen, Gruppen und Vererbung==

Andererseits geht es bei der ACL auch darum, Benutzern Berechtigungen zu erteilen, damit diese Aktionen an Objekten durchführen können.

{| class="wikitable"
!style="width:20%;"|
!3.x Serie
|-
!Gruppen und Aktionen
|Aktionen, welche pro Gruppe erlaubt sind, werden durch den Website Administrator festgelegt.
|-
!Umfang von Berechtigungen
|Berechtigungen können auf mehreren Ebenen in der Hierarchie festgelegt werden: Website, Komponente, Kategorie, Objekt.
|-
!Vererbung von Berechtigungen
|Berechtigungen können von übergeordneten Gruppen und übergeordneten Kategorien geerbt werden.
|}

===Wie die Berechtigungen funktionieren===

Es gibt vier mögliche Berechtigungen für Aktionen. Diese sind (kurz skizziert):

* '''Nicht gesetzt''': Fällt standardmäßig auf "Nicht erlaubt" zurück. Aber im Gegensatz zur Berechtigung "Verweigert" kann diese Berechtigung außer Kraft gesetzt werden, wenn eine untergeordnete Gruppe oder eine in der Berechtigungshierarchie untergeordnete Ebene auf "Erlaubt" gesetzt wird. Diese Berechtigung kann nur für globale Berechtigungen der Konfiguration gesetzt werden.
* '''Vererbt''': Erbt den Wert von einer übergeordneten Gruppe oder einer in der Berechtigungshierarchie höheren Ebene. Diese Berechtigung gilt für alle Ebenen mit Ausnahme der obersten Ebene der Konfiguration.
* '''Verweigert''': Verbietet diese Aktion für diese Ebene und Gruppe. '''WICHTIG:''' Dadurch wird diese Aktion auch für alle untergeordneten Gruppen und alle untergeordneten Ebenen in der Berechtigungshierarchie verboten. Wird "Erlaubt" in einer untergeordneten Gruppe oder einer tieferen Ebene gesetzt, hat das keinen Effekt. Die Aktion wird immer für alle Mitglieder einer untergeordneten Gruppe und für alle untergeordneten Ebenen in der Berechtigungshierarchie abgelehnt.
* '''Erlaubt ''': Genehmigt diese Aktion für diese Ebene und Gruppe und für tiefere Ebenen und Untergruppen. Dies hat keine Auswirkungen, wenn eine höhere Gruppe oder Ebene auf "Verweigert" oder "Erlaubt" eingestellt ist. Wenn eine höhere Gruppe oder ein höheres Ebene auf "Verweigert" gesetzt ist, wird diese Berechtigung immer abgelehnt. Wenn eine höhere Gruppe oder Ebene auf Erlaubt eingestellt ist, ist diese Berechtigung bereits erlaubt.

===Hierarchie der Berechtigungsebenen===

Berechtigungen für Aktionen können in Version 2.5+ auf bis zu vier Ebenen festgelegt werden, wie folgt:
# '''Konfiguration''': legt die Standardberechtigungen für jede Aktion und Gruppe fest.
# '''Komponenten-Optionen-> Berechtigungen''': kann die Standardberechtigungen für diese Komponente überschreiben (z. B. Beiträge, Menüs, Benutzer, Banner usw.).
# '''Kategorie''': kann die Standardberechtigungen für Objekte in einer oder mehreren Kategorien überschreiben. Gilt für alle Komponenten mit Kategorien, einschließlich Beiträge, Banner, Kontakte, Newsfeeds und Weblinks.
# '''Beitrag''': kann die Berechtigungen für einen bestimmten Artikel überschreiben. Diese Ebene gilt nur für Beiträge. Alle anderen Komponenten erlauben nur die ersten drei Ebenen.

====Konfiguration====
Diese erreicht man über System → Konfiguration → Berechtigungen. Die nun sichtbare Maske dient dazu, die Berechtigungen auf der obersten Ebene für jede Gruppe und jede Aktion festzulegen, wie auch in der folgenden Abbildung gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Die möglichen Werte sind Vererbt, Erlaubt oder Verweigert. Die Spalte 'Errechnete Einstellung' zeigt die aktuelle Einstellung an. Diese ist entweder Nicht erlaubt (Standard), Erlaubt oder Nicht erlaubt.

Man kann immer nur an einer Gruppe gleichzeitig arbeiten, indem man den Reiter für ebendiese Gruppe anklickt. Die Berechtigungen kann man über die Dropdownlisten unter Neue Einstellung wählen ändern.

Beachten Sie, dass die Spalte "Errechnete Einstellung" erst aktualisiert wird, wenn Sie auf die Schaltfläche "Speichern" in der Werkzeugleiste klicken.

Um zu überprüfen, ob die Einstellungen Ihren Wünschen entsprechen, klicken Sie auf die Schaltfläche Speichern und überprüfen anschließend die Spalte Errechnete Einstellung.

====Komponenten-Optionen->Berechtigungen====
Auf diese wird für jede Komponente durch Klicken auf das Symbol "Optionen" in der Werkzeugleiste zugegriffen. Dieser Bildschirm ist ähnlich wie der Bildschirm "Globale Konfiguration" oben links. Wenn Sie beispielsweise im Menü-Manager auf das Symbol in der Werkzeugleiste Optionen klicken, werden die folgenden Menüs angezeigt.
[[Image:Screenshot_menu_acl_J3_tutorial-en.jpg]]

Der Zugriff auf Optionen ist nur für Mitglieder von Gruppen möglich, die die Berechtigung für die Aktion Konfiguration in für jede Komponente haben. Im obigen Beispiel hat die Gruppe Administrator die Berechtigung Erlaubt für die Option Konfigurieren, so dass Mitglieder dieser Gruppe auf diesen Bildschirm zugreifen können.

===Kategorie===
Auf die Kategorieberechtigungen wird im Category Manager zugegriffen: Bildschirm Kategorie bearbeiten, in einer Registerkarte oben auf dem Bildschirm. Dieser Bildschirm hat fünf Berechtigungen, wie folgt:

[[Image:Screenshot_category_acl_j3_tutorial-en.png]]

In diesen Bildern bearbeiten Sie die Berechtigungen für jeweils eine Benutzergruppe. Im obigen Beispiel bearbeiten Sie die Berechtigungen für die Gruppe Administrator.

Achten Sie darauf, dass die Aktionen "Konfigurieren und Zugriffssteuerung" nicht auf der Kategorieebene angewendet werden, so dass diese Aktionen nicht enthalten sind.

Beachten Sie auch, dass Kategorien in einer Hierarchie angeordnet werden können. Wenn ja, dann werden Aktionsberechtigungen in einer übergeordneten Kategorie automatisch an eine untergeordnete Kategorie vererbt. Wenn Sie beispielsweise eine Kategoriehierarchie von Tieren → Haustiere → Hunde hätten, dann würde die vollständige Berechtigungshierarchie für einen Artikel in der Kategorie Hunde wie folgt aussehen:
* Globale Konfiguration
* Artikel-Manager → Optionen → Genehmigung → Erlaubnis
* Tierkategorie
* Kategorie Haustiere
* Kategorie Hunde
* spezifischer Artikel

====Beitrag====
Berechtigungen für einzelne Beiträge findet man im "Beitrag" unter dem Tab-Reiter "Berechigungen". Dieser Bildschirm hat drei Aktionen, wie unten gezeigt.

[[Image:j3x_acl_tutorial_article_manager_article_permissions-en.png]]

Auch hier bearbeiten Sie jede Gruppe für sich. Um auf die Berechtigungen zuzugreifen wechseln Sie im Artikel auf den Reiter "Berechtigungen" im oberen Reiter. Über das Drop Down Menü wählen Sie die neue Berechtigung im Anschluss speichern Sie den Beitrag ab.

Beachten Sie, dass die Aktionen Configure, Access Component und Create auf Artikelebene nicht gelten, so dass diese Aktionen nicht berücksichtigt werden. Die Berechtigung zum Anlegen eines Artikels wird auf einer der höheren Ebenen der Hierarchie festgelegt.

===Zugriffsebenen===

Die Zugriffsebenen der 3.x-Serie sind einfach und flexibel. Der folgende Bildschirm zeigt die spezielle Zugriffsebene.
[[Image:j3x_acl_tutorial_viewing_levels-en.png|center]]
Aktivieren Sie einfach das Kontrollkästchen für jede Gruppe, die Sie in diesem Level aufnehmen wollen. Die spezielle Zugriffsebene umfasst die Gruppen Manager, Autor und Superuser. Es beinhaltet auch untergeordnete Gruppen dieser Gruppen. Die Gruppe Administrator ist also enthalten, da es sich um eine Untergruppe der Gruppe Manager handelt. Die Gruppen Editor, Publisher und Shop Suppliers sind enthalten, da es sich um Untergruppen des Autors handelt.

Jedem Objekt im Frontend ist eine Zugriffsebene zugeordnet. Wenn die Ebene öffentlich ist, kann jeder auf dieses Objekt zugreifen. Andernfalls dürfen nur Mitglieder von Gruppen, die dieser Zugriffsebene zugeordnet sind, auf dieses Objekt zugreifen.

Die Zugriffsebenen sind den Menüpunkten und den Modulen zugeordnet. Jede kann nur einer Zugriffsebene zugeordnet werden.

Der folgende Bildschirm zeigt beispielsweise den Bildschirm Menüpunkt bearbeiten mit der Liste der verfügbaren Zugriffsebenen....

[[Image:j3x_acl_tutorial_edit_menu_item_level_dropdown-en.png|center]]

==Standard-ACL-Setup==

Wenn Joomla! installiert ist, werden diese auf die ursprünglichen Standardwerte gesetzt. Wir werden diese Grundeinstellungen besprechen, um die Arbeitsweise der ACL zu verstehen.

===Standardgruppen===

Mit der Version 3.x können Sie Ihre individuellen Gruppen definieren. Wenn Sie die Version 3.x installieren, enthält sie eine Reihe von Standardgruppen, die im Folgenden dargestellt werden, sind die grundlegenden Standardbenutzergruppen. (Zusätzliche Standardbenutzergruppen werden mit Beispieldaten installiert)

[[Image:Screenshot_usergroupsl_acl_J3_tutorial-en.png|center]]

Die Pfeile zeigen die untergeordneten Elternbeziehungen an. Wie vorstehend besprochen, wird diese Berechtigung, wenn Sie eine Berechtigung für eine übergeordnete Gruppe festlegen, automatisch an alle Untergruppen vererbt. Die vererbten und zulässigen Berechtigungen können für eine Untergruppe überschrieben werden. Die Berechtigung Verweigert kann nicht überschrieben werden und verweigert immer eine Aktion für alle Untergruppen.

===Konfiguration===

Joomla! Version 3.x wird mit den gleichen bekannten Backend-Rechten wie die Version 1.5 (EOL) installiert. Mit der Version 3.x können Sie diese jedoch leicht an die Bedürfnisse Ihrer Website anpassen.

Wie bereits besprochen, werden die Berechtigungen für jede Aktion von der obigen Ebene in der Berechtigungshierarchie und von der übergeordneten Gruppe einer Gruppe übernommen. Also, wie funktioniert das? Die oberste Ebene dafür ist der gesamte Standort. Dies wird in der Site->Globale Konfiguration->Berechtigungen eingerichtet, wie unten gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Das erste, was man bemerken sollte, sind die zehn Aktionen: Standortlogin, Admin-Login, Offline-Zugriff, Superuser, Access Administration Interface, Erstellen, Löschen, Bearbeiten, Status bearbeiten und Eigenes bearbeiten. Dies sind die Aktionen, die ein Benutzer an einem Objekt in Joomla durchführen kann. Die spezifische Bedeutung jeder Aktion hängt vom Kontext ab. Für das Bild Globale Konfiguration sind sie wie folgt definiert:

Site Login : Login to the front end of the site

;Admin Login : Melden Sie sich am Backend der Website an.

Offline-Zugriff: Melden Sie sich am Frontend der Website an, wenn die Website offline ist (wenn die globale Konfigurationseinstellung "Site Offline" auf Ja gesetzt ist).

Superuser: Gewährt dem Benutzer den Status "Superuser". Benutzer mit dieser Berechtigung dürfen alles auf der Website machen. Nur Benutzer mit dieser Berechtigung können die Einstellungen der globalen Konfiguration ändern. Diese Berechtigungen können nicht eingeschränkt werden. Es ist wichtig zu verstehen, dass, wenn ein Benutzer Mitglied einer Super Admin-Gruppe ist, alle anderen Berechtigungen, die diesem Benutzer zugewiesen sind, irrelevant sind. Der Benutzer kann jede Aktion auf der Website durchführen. Es können jedoch weiterhin Zugriffsebenen zugewiesen werden, um zu steuern, was diese Gruppe auf der Website sieht. (Natürlich kann ein Super-Admin-Benutzer die Zugriffsebenen ändern, wenn er möchte, so dass die Zugriffsebenen nicht vollständig einschränken, was ein Super-Admin-Benutzer sehen kann.)

Zugangskomponente: Öffnen Sie die Bildschirme der Komponentenverwaltung (Benutzerverwaltung, Menüverwaltung, Artikelverwaltung usw.).

;Create : Create new objects (for example, users, menu items, articles, weblinks, and so on)

;Löschen : Löschen eines existienden Objekts

;Ändern : Ändern eines existierenden Objektes

;Ändern eines Objekt Status (Veröffentlicht, nicht Veröffentlicht, Archiviert und Gelöscht)

Eigene Objekte bearbeiten: Bearbeiten Sie Objekte, die Sie erstellt haben.

Each Group for the site has its own slider which is opened by clicking on the group name. In this case (with the sample data installed), we have the standard 7 groups that we had in version 1.5 plus two additional groups called "Shop Suppliers" and "Customer Group". Notice that our groups are set up with the same permissions as they had in version 1.5. Keep in mind that we can change any of these permissions to make the security work the way we want. Let's go through this to see how it works.

* '''Public''' has everything set to "Not set", as shown below.{{-}}[[Image:Screenshot_global_acl_public_J3_tutorial-en.png]]
**This can be a bit confusing. Basically, "Not Set" is the same as "Inherited". Because Public is our top-level group, and because Global Configuration is the top level of the component hierarchy, there is nothing to inherit from. So "Not Set" is used instead of "Inherit".
**The default in this case is for no permissions. So, as you would expect, the Public group has no special permissions. Also, it is important to note that, since nothing is set to Denied, all of these permissions may be overridden by child groups or by lower levels in the permission hierarchy.

* '''Guest''' is a 'child' group of the Public group has everything set to 'Inherited' {{-}}[[Image:Screenshot_global_acl_guest_J3_tutorial-de.png]]
** This is the default 'Guest User Group' in the User Manager options and the Group that (non logged in) visitors to your site are placed in.

* '''Manager''' is a "child" group of the Public group. It has Allowed permissions for everything except Access Component and Super Admin. So a member of this group can do everything in the front and back end of the site except change Global Permissions and Component Options. {{-}}[[Image:Screenshot_global_acl_manager_J3_tutorial-en.png]]

* '''Administrator''' group members inherit all of the Manager permissions and also have Allowed for Access Component. So members of this group by default can access the Options screens for each component. {{-}}[[Image:Screenshot_global_acl_administrator_J3_tutorial-en.png]]

* '''Registered''' is the same a Public except for the Allow permission for the Site Login action. This means that members of the Registered group can login to the site. Since default permissions are inherited, this means that, unless a child group overrides this permission, all child groups of the Registered group will be able to login as well. {{-}}[[Image:Screenshot_global_acl_registered_J3_tutorial-en.png]]

* '''Author''' is a child of the Registered group and inherits its permissions and also adds Create and Edit Own. Since Author, Editor, and Publisher have no back-end permissions, we will discuss them below, when we discuss front-end permissions.{{-}}[[Image:Screenshot_global_acl_author_J3_tutorial-en.png]]

* '''Editor''' is a child of the Authors group and adds the Edit permission. {{-}}[[Image:Screenshot_global_acl_editor_J3_tutorial-en.png]]

* '''Publisher''' is a child of Editor and adds the Edit State permission.{{-}}[[Image:Screenshot_global_acl_publisher_J3_tutorial-en.png]]

* '''Shop Suppliers''' is an example group that is installed if you install the sample data. It is a child group of Author.

* '''Customer Group''' is an example group that is installed if you install the sample data. It is a child group of Registered.

* '''Super Users''' group has the Allow permission for the Super Admin action. Because of this, members of this group have super user permissions throughout the site. They are the only users who can access and edit values on the Global Configuration screen. Users with permission for the Super Admin action have some special characteristics:
:* If a user has Super Admin permissions, no other permissions for this user matter. The user can perform any action on the site.
:* Only Super Admin users can create, edit, or delete other Super Admin users or groups.

There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.

This provides a lot of flexibility. For example, if you wanted Shop Suppliers to be able to have the ability to login to the back end, you could just change their Admin Login value to "Allowed". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherited (or Denied).

It is also important to understand that the ability to have child groups is completely optional. It allows you to save some time when setting up new groups. However, if you like, you can set up all groups to have Public as the parent and not inherit any permissions from a parent group.

===Komponenten-Optionen & Berechtigungen===

Now, let's continue to see how the default back-end permissions for version 2.5 mimic the permissions for version 1.5. The Super Users group in 2.5 is equivalent to the Super Administrator group in 1.5.

Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 2.5 configuration. Let's see how this is accomplished.

If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:

[[Image:screenshot_acl_tutorial_20110111-09-en.png|center|]]
[[Image:screenshot_acl_tutorial_20110111-10-en.png|center|]]

This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.

First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.

Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.

If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.

In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.

It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.

===Frontend Berechtigungen===

Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions. First, let's look at the permissions for Manager, as shown below.
[[Image:screenshot_acl_tutorial_20110111-11a-en.png|center|frame]]
Manager has allowed permission for all actions except Configure. So members of the Manager group can do everything with Articles except open the Options screen.

Now let's look at Administrator, as shown below.
[[Image:screenshot_acl_tutorial_20110111-12a-en.png|center|frame]]
Administrator has Allowed for Configure, so Administrators can edit this Options screen.

Both groups can create, delete, edit, and change the state of articles.

Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set.

Authors only have Create and Edit Own permissions, as shown below.
[[Image:screenshot_acl_tutorial_20110112-07-en.png|center|frame]]
This means that Authors can create articles and can edit articles they have created. They may not delete articles, change the published state of articles, or edit articles created by others.

Editors have the same permissions as Authors with the addition of permission for the Edit action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-08-en.png|center|frame]]
So Editors can edit articles written by anyone.

Publishers can do everything Editors can do plus they have permission for the Edit State action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-09-en.png|center|frame]]
So Publishers can change the published state of an article. The possible states include Published, Unpublished, Archived, and Trashed.

All of these groups have Inherit permission for Configure and Access Component. Remember that Author is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Configure and Access Component, and since Author's permission for these actions is "Inherited", then Author does not have these permissions either. This same permission is passed from Author to Editor and from Editor to Publisher. So, by default, none of these groups are allowed to work with articles in the back end.

It is important to remember that these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.

Beachte auch das in den ursprünglichen Standardwerten keine Berechtigungen auf Verweigert eingestellt sind. Dies ermöglicht in allen Berechtigungsebenen die jeweilige Berechtigung auf Erlaubt einzustellen. Bedenke, wenn eine Aktion auf Verweigert eingestellt ist, das diese Aktion auch in allen untergeordneten Ebenen in der Berechtigungshierarchie verweigert wird. Zum Beispiel, wenn die Seitenameldung für Registered auf Verweigert (anstatt auf Erlaubt) eingestellt wird, kann man Publishers diese Aktion per Berechtigungeinstellung nicht erteilen.

=== Beitrags-Manager & Aktions-Diagramm ===

The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.

[[Image:screenshot_acl_tutorial_20110111-16-en.png|center|]]

* '''Configure''' allows you to view and change the Options for the component.
* '''Access Component''' allows you to navigate to the Article Manager. Without this permission, no other actions are possible.
* '''Create''' allows you to add new articles.
* '''Delete''' allows you to delete trashed articles. Note that the Delete icon only shows in the toolbar when you have the "Select State" filter set to "Trash".
* '''Edit''' allows you to edit existing articles.
* '''Edit State''' allows to you Publish, Unpublish, Archive, or Trash articles.
* '''Edit Own''' is the same as Edit except that it only applies to articles written by you.

==Allowing Guest-Only Access to Menu Items and Modules==

Version 1.6 introduced the ability to create a View Access Level that is only for guests of the site (meaning a user who is not logged in). The example below shows how you can set up this new feature.
''(N.B. Steps 1 to 3 are not needed for Joomla! 3.x as they exist in the default install)''

#Create a new user group called Guest. Make it a child of the Public group as shown below. [[Image:screenshot_acl_tutorial_20110112-01-en.png|center|frame]]
# Create a new access level called Guest and grant only the Guest group access to this level, as shown below.[[Image:screenshot_acl_tutorial_20110112-02-en.png|center|frame]]
# Navigate to User Manager→Options→Component and change the Guest User Group from the default value of "Public" to "Guest", as shown below.
[[Image:screenshot_acl_tutorial_20110112-04-en.png|center|frame]]
Now, if we assign a menu item, module, or other object to the Guest access level, only non-logged in users will have access. For example, if we create a new menu item with access level of Guest, as shown below,
[[Image:screenshot_acl_tutorial_20110112-05-en.png|center|frame]]
this menu item will only be visible to non-logged-in visitors to the site.

If required other user groups like Author can be granted access in the Guest access level, this would allow Authors to view articles in the front end for editing.

'''N.B. Login/logout in front end (''for changing data in session'') to see the change.'''

==Berechtigungen und Gruppenebenen gemeinsam nutzen==

As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.

This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:

* both groups can create new articles only in the History Assignments category.

* only History Teachers (not Assistant History Teachers) can Publish or otherwise have Edit State permission.

This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.

[[Image:Acl example diagram1 20091018-en.png|center|]]

In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.

To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.

Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.

[[Image:Acl example diagram2 20091018-en.png|center|]]

This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.

Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.

==ACL Aktion Berechtigungs-Beispiele==

===Backend Beitrag Administrator===

'''Problem:'''

We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.

'''Lösung:'''

# Create a new group called Article Administrator and make its parent group Public, as shown below.[[Image:screenshot_acl_tutorial_20110112-10-en.png|center|frame]] Because its parent group is Public, it won't have any permissions by default.
# In Users → Access Levels, edit the Special Access level to add the new group. That way they can get access to the back end menu items and modules (This assumes that the modules for the admin menu and quickicons have the Special Access level assigned to them, which is the default.) [[Image:screenshot_acl_tutorial_20110112-11-en.png|center|frame]] By default, the back-end menu items and modules are set to Special access, so if you forget to add the new group to the Special access level, you won't see any modules or menu items when you log in as a user of the new group.
# In Site → Global Configuration → Permissions, click on the Article Administrator group and change the permissions to Allowed for the following actions: Admin Login, Create, Delete, Edit, Edit State, and Edit Own. The screen below shows what will show before you press Save. [[Image:screenshot_acl_tutorial_20110112-12-en.png|center|frame]]After you save, the Calculated Permissions should show as shown below.[[Image:screenshot_acl_tutorial_20110112-13-de.png|center|frame]]Note that the permission for the Access Component is Inherited, which translates to Not Allowed. This is important. This means that this group will only be able to access components if we give the group "Allowed" permission for Access Component. So we only have to change the one component we want to give them access to and don't have to change any settings for the components where we don't want them to have access. If we had a case where we wanted to give a group access to everything except for one component, we could set the default to Allowed and then set the one component to Denied. Also note that we did not give the group Site Login permission, so users in this group will not be able to log into the front end. (If we wanted to allow that, we would just change the permission to Allowed for Site Login.)
# In Article Manager → Options → Permissions, change permissions to Allowed for this group for the Access Component action, as shown below.[[Image:screenshot_acl_tutorial_20110112-14-de.png|center|frame]]All of the other desired permissions are inherited.

That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end. For example, the screen below shows what a user in the Article Manager will see when they login to the back end.[[Image:screenshot_acl_tutorial_20110112-15-de.png|center|frame]]

==ACL Ansicht Zugriffsebenen-Beispiele==

A basic concept of using Access Levels is that all items with the same Access will be viewable by the same group of users. In other words, if two items have the same Access, you can't have one viewable by one user and not viewable by another user. On the other hand, it is easy to have one Group view any number of items with different Access levels.

Similarly, each Group has exactly the same combination of Access levels, but one User can be a member of more than one group. Depending on the situation, you may want to have users only in one Group or you may need to have a User in more than one Group.

This means that we may need to group our items so that items so that all items in a group have the same level of sensitivity. Here are some examples.

===Hierarchisches Beispiel===
In this example, Access levels are hierarchical, for example, like government security clearance codes. Say for example we have the following sets of classified documents: Classified, Secret, and Top Secret. Users have corresponding clearence codes. Users with Classified clearance can only see Classified documents and cannot see Secret or Top Secret. Users with Secret clearance can see Classified and Secret documents but not Top Secret. Users with Top Secret can see all documents.

In this case, you would create three Access levels: Classified, Secret, and Top Secret and the same three Groups. Users would only be members of one group, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| C1, C2, C3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Classified
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| S1, S2, S3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| TS1, TS2, TS3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Top Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret, Top Secret

|}

In this case, all users are in exactly one group, but some groups have access to more than one Access Level of items. In other words, we have a one-to-one relationship between users and groups, but a one-to-many relationship between Groups and Access Levels.

===Teamsicherheit Beispiel===

Another possible use case is a set of non-hierarchical teams. Let's say we have three teams, T1, T2, and T3. Some users are only on one team, but others might be on two or more teams. In this case, we could set up our Access Levels and Groups by team. Documents for each team have the access level for that team, and the Group for the team has only the one access level. When a User is on more than one team, they get added to the group for each team, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Beschreibung
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 1 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 2 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 3 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1, 2 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1,T2, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2, T3

|}

===Hybrid Example===

In a real-world situation, you might have a combination of these two arrangements. Say for example we have Managers and Staff. Staff can only see Staff documents and Managers can see Manager and Staff documents. Both types of users can be assigned to teams as well, in which case they can see all of the documents for that team. In addition, say that Managers can access some, but not all, team documents. Staff can only access team documents if they are members of that team.

In this example, we could set up the following Access Levels:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Access Level
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Description
| style="border:0.0007in solid #000000;padding:0.0382in;"| Groups

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team manager documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team staff documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team1 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1, Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team2 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2, Manager

|}

Then, users could be assigned to groups as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| User Type
| style="border:0.0007in solid #000000;padding:0.0382in;"| Group

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1, Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1, Team2

|}

<noinclude>
[[Category:Joomla! 1.6]]
[[Category:Joomla! 2.5]]
[[Category:Joomla! 3.x/de]]
[[Category:Tutorials/de]]
[[Category:Access Control/de]]
[[Category:Access Management]]
</noinclude>

Translations:J3.x:Access Control List Tutorial/202/de

2019-12-26T19:06:40Z

Sieger66:

J3.x:Access Control List Tutorial/de

2019-12-26T19:06:31Z

Sieger66:

<noinclude><languages /></noinclude>
{{Joomla version|version=3.x|comment=Serie}}
{{-}}
{{:J3.1:Access_Control_List/en}}

==Separate ACL für Anzeige und Aktionen==

Das Joomla ACL-System besteht genau genommen aus zwei völlig getrennten Systemen. Das eine System steuert, was Benutzer auf der Website "sehen" können. Das andere steuert, was Benutzer "tun" können (welche Aktionen ein Benutzer durchführen kann). Die ACL wird für jedes dieser Systeme anders eingerichtet.

===Steuern, was Benutzer sehen können===

Das Setup zum Steuern, was Benutzer sehen können, sieht wie folgt aus:
*Eine Reihe von Zugriffsebenen gemäß den Kategorien und/oder der Kombination von Kategorien erstellen, die nur angemeldete Benutzer sehen sollen. Anmerkung: Zu diesem Zeitpunkt werden noch keine Benutzergruppen den neuen Zugriffsebenen zugewiesen.

*Für jede Zugriffsebene eine Benutzergruppe erstellen, die 'Registriert' als übergeordnete Gruppe hat. Indem man für Benutzergruppen und Zugriffsebenen die gleichen Namen verwendet, kann man Verwirrungen zu einem späteren Zeitpunkt vorbeugen.

*Die neuen Zugriffsebenen bearbeiten und jeder die (neue) Benutzergruppe zuweisen. Wahrscheinlich möchten man auch die 'Super Benutzer' Gruppe (und/oder die anderen Standard-Benutzergruppen mit Ausnahme der Benutzergruppe 'Gast') den neuen Zugriffsebenen zuweisen.

*Jedem anzuzeigenden Eintrag eine Zugriffsebene zuweisen. Einträge sind sowohl inhaltliche Einträge (Beiträge, Kontakte, usw.), Menüeinträge als auch Module.

Immer dann, wenn ein Benutzer im Begriff ist, einen Eintrag auf einer Joomla-Seite anzeigen zu lassen, prüft das Programm, ob dieser Benutzer auch Zugriff auf den Eintrag hat. Das geschieht folgendermaßen:
# Zunächst wird eine Liste aller Zugriffsebenen erstellt, auf die der Benutzer zugreifen kann, basierend auf allen Gruppen, denen der Benutzer angehört. Sofern eine Gruppe eine übergeordnete Gruppe besitzt, sind die Zugriffsebenen für die übergeordnete Gruppe ebenfalls in der Liste enthalten.
# Danach wird überprüft, ob die Zugriffsebene für den Eintrag (Beitrag, Modul, Menüeintrag, usw.) in dieser Liste enthalten ist. Wenn dem so ist, wird der Eintrag dem Benutzer angezeigt. Falls der Benutzer die benötigten Zugriffsrechte besitzt, wird ihm der Zugriff verweigert.

Beachten, dass Zugriffsebenen für jede Gruppe separat festgelegt und nicht von der übergeordneten Gruppe einer Gruppe vererbt werden.

===Steuern, was Benutzer tun können===

Das System, das steuert, was Benutzer in einer Benutzergruppe tun können - welche Aktionen sie bei einem bestimmten Eintrag ausführen können - wird über den Tab 'Berechtigungen' in der Konfiguration und den Tab 'Berechtigungen' in den Optionen jeder einzelnen Komponente eingerichtet. Berechtigungen können auch auf Kategorienebene (bei Kernkomponenten) und auf Beitragsebene (bei Beiträgen) gesetzt werden.

* Wenn angemeldete Benutzer in bestimmten Kategorien Erstellen, Löschen, Status bearbeiten oder Eigene Inhalte bearbeiten dürfen, dann:
** Eine Benutzergruppe erstellen und als übergeordnete Gruppe eine der Benutzergruppen angeben, die Zugriff auf die Kategorie (oder Kategorien) haben, die diese neue Benutzergruppe ändern soll.
**Der neuen Benutzergruppe den entsprechenden Zugriffsebenen zuweisen. Dann die erforderlichen Berechtigungen für die neue Benutzergruppe entweder global oder pro Kategorie/Beitrag ändern.
*** Beim Erstellen einer Benutzergruppe ist es ratsam, eine übergeordnete Gruppe zu wählen, die über weniger Berechtigungen verfügt, als für die neue Gruppe erforderlich. Denn es ist einfacher, die Berechtigungen für jede Komponente/Kategorie/Beitrag zu erweitern, für die zusätzliche Berechtigungen nötig sind, als Berechtigungen aus den anderen Komponenten/Kategorien/Beiträgen zu entfernen.
****''(Beispiel: Es gibt 10 Kategorien, man möchte aber nur für eine Erstellen-Berechtigungen. Würde man für diese Gruppe die Berechtigungen global auf Erstellen erlaubt setzen, müsste man für diese Kategorien die Erstellen-Berechtigung entfernen. Und man müsste für diese Gruppe die Erstellen-Berechtigung bei jeder neuen Kategorie, die man zu einem späteren Zeitpunkt hinzufügt, ebenfalls entfernen).''
** Eine Benutzergruppe erstellen, die eine der Standardbenutzergruppen als übergeordnete Gruppe hat, NUR, wenn keine von diesen über die exakten Berechtigungen verfügt, die man benötigt und sich für alle Kategorien wünscht.

Beachten, dass dieses Setup unabhängig vom Setup für die Anzeige ist. Allerdings muss eine Benutzergruppe den entsprechenden Zugriffsebenen zugewiesen werden, damit der Benutzer in dieser Gruppe jene Berechtigungen verwenden kann.

Möchte ein Benutzer eine bestimmte Aktion bei einem Komponenten-Eintrag durchführen (z. B. einen Beitrag bearbeiten), überprüft das System (nachdem es überprüft hat, welcher Gruppe der Benutzer angehört und auf welche er Zugriff hat) die Berechtigung für diese Kombination aus Benutzer, Eintrag und Aktion. Liegt eine Erlaubnis vor, kann der Benutzer fortfahren. Andernfalls ist die Aktion nicht zulässig.

Das restliche Tutorial befasst sich mit der Steuerung, was Benutzer tun können - welche Aktionsberechtigungen sie haben.

==Aktionen, Gruppen und Vererbung==

Andererseits geht es bei der ACL auch darum, Benutzern Berechtigungen zu erteilen, damit diese Aktionen an Objekten durchführen können.

{| class="wikitable"
!style="width:20%;"|
!3.x Serie
|-
!Gruppen und Aktionen
|Aktionen, welche pro Gruppe erlaubt sind, werden durch den Website Administrator festgelegt.
|-
!Umfang von Berechtigungen
|Berechtigungen können auf mehreren Ebenen in der Hierarchie festgelegt werden: Website, Komponente, Kategorie, Objekt.
|-
!Vererbung von Berechtigungen
|Berechtigungen können von übergeordneten Gruppen und übergeordneten Kategorien geerbt werden.
|}

===Wie die Berechtigungen funktionieren===

Es gibt vier mögliche Berechtigungen für Aktionen. Diese sind (kurz skizziert):

* '''Nicht gesetzt''': Fällt standardmäßig auf "Nicht erlaubt" zurück. Aber im Gegensatz zur Berechtigung "Verweigert" kann diese Berechtigung außer Kraft gesetzt werden, wenn eine untergeordnete Gruppe oder eine in der Berechtigungshierarchie untergeordnete Ebene auf "Erlaubt" gesetzt wird. Diese Berechtigung kann nur für globale Berechtigungen der Konfiguration gesetzt werden.
* '''Vererbt''': Erbt den Wert von einer übergeordneten Gruppe oder einer in der Berechtigungshierarchie höheren Ebene. Diese Berechtigung gilt für alle Ebenen mit Ausnahme der obersten Ebene der Konfiguration.
* '''Verweigert''': Verbietet diese Aktion für diese Ebene und Gruppe. '''WICHTIG:''' Dadurch wird diese Aktion auch für alle untergeordneten Gruppen und alle untergeordneten Ebenen in der Berechtigungshierarchie verboten. Wird "Erlaubt" in einer untergeordneten Gruppe oder einer tieferen Ebene gesetzt, hat das keinen Effekt. Die Aktion wird immer für alle Mitglieder einer untergeordneten Gruppe und für alle untergeordneten Ebenen in der Berechtigungshierarchie abgelehnt.
* '''Erlaubt ''': Genehmigt diese Aktion für diese Ebene und Gruppe und für tiefere Ebenen und Untergruppen. Dies hat keine Auswirkungen, wenn eine höhere Gruppe oder Ebene auf "Verweigert" oder "Erlaubt" eingestellt ist. Wenn eine höhere Gruppe oder ein höheres Ebene auf "Verweigert" gesetzt ist, wird diese Berechtigung immer abgelehnt. Wenn eine höhere Gruppe oder Ebene auf Erlaubt eingestellt ist, ist diese Berechtigung bereits erlaubt.

===Hierarchie der Berechtigungsebenen===

Berechtigungen für Aktionen können in Version 2.5+ auf bis zu vier Ebenen festgelegt werden, wie folgt:
# '''Konfiguration''': legt die Standardberechtigungen für jede Aktion und Gruppe fest.
# '''Komponenten-Optionen-> Berechtigungen''': kann die Standardberechtigungen für diese Komponente überschreiben (z. B. Beiträge, Menüs, Benutzer, Banner usw.).
# '''Kategorie''': kann die Standardberechtigungen für Objekte in einer oder mehreren Kategorien überschreiben. Gilt für alle Komponenten mit Kategorien, einschließlich Beiträge, Banner, Kontakte, Newsfeeds und Weblinks.
# '''Beitrag''': kann die Berechtigungen für einen bestimmten Artikel überschreiben. Diese Ebene gilt nur für Beiträge. Alle anderen Komponenten erlauben nur die ersten drei Ebenen.

====Konfiguration====
Diese erreicht man über System → Konfiguration → Berechtigungen. Die nun sichtbare Maske dient dazu, die Berechtigungen auf der obersten Ebene für jede Gruppe und jede Aktion festzulegen, wie auch in der folgenden Abbildung gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Die möglichen Werte sind Vererbt, Erlaubt oder Verweigert. Die Spalte 'Errechnete Einstellung' zeigt die aktuelle Einstellung an. Diese ist entweder Nicht erlaubt (Standard), Erlaubt oder Nicht erlaubt.

Man kann immer nur an einer Gruppe gleichzeitig arbeiten, indem man den Reiter für ebendiese Gruppe anklickt. Die Berechtigungen kann man über die Dropdownlisten unter Neue Einstellung wählen ändern.

Beachten Sie, dass die Spalte "Errechnete Einstellung" erst aktualisiert wird, wenn Sie auf die Schaltfläche "Speichern" in der Werkzeugleiste klicken.

Um zu überprüfen, ob die Einstellungen Ihren Wünschen entsprechen, klicken Sie auf die Schaltfläche Speichern und überprüfen anschließend die Spalte Errechnete Einstellung.

====Komponenten-Optionen->Berechtigungen====
Auf diese wird für jede Komponente durch Klicken auf das Symbol "Optionen" in der Werkzeugleiste zugegriffen. Dieser Bildschirm ist ähnlich wie der Bildschirm "Globale Konfiguration" oben links. Wenn Sie beispielsweise im Menü-Manager auf das Symbol in der Werkzeugleiste Optionen klicken, werden die folgenden Menüs angezeigt.
[[Image:Screenshot_menu_acl_J3_tutorial-en.jpg]]

Der Zugriff auf Optionen ist nur für Mitglieder von Gruppen möglich, die die Berechtigung für die Aktion Konfiguration in für jede Komponente haben. Im obigen Beispiel hat die Gruppe Administrator die Berechtigung Erlaubt für die Option Konfigurieren, so dass Mitglieder dieser Gruppe auf diesen Bildschirm zugreifen können.

===Kategorie===
Auf die Kategorieberechtigungen wird im Category Manager zugegriffen: Bildschirm Kategorie bearbeiten, in einer Registerkarte oben auf dem Bildschirm. Dieser Bildschirm hat fünf Berechtigungen, wie folgt:

[[Image:Screenshot_category_acl_j3_tutorial-en.png]]

In diesen Bildern bearbeiten Sie die Berechtigungen für jeweils eine Benutzergruppe. Im obigen Beispiel bearbeiten Sie die Berechtigungen für die Gruppe Administrator.

Achten Sie darauf, dass die Aktionen "Konfigurieren und Zugriffssteuerung" nicht auf der Kategorieebene angewendet werden, so dass diese Aktionen nicht enthalten sind.

Beachten Sie auch, dass Kategorien in einer Hierarchie angeordnet werden können. Wenn ja, dann werden Aktionsberechtigungen in einer übergeordneten Kategorie automatisch an eine untergeordnete Kategorie vererbt. Wenn Sie beispielsweise eine Kategoriehierarchie von Tieren → Haustiere → Hunde hätten, dann würde die vollständige Berechtigungshierarchie für einen Artikel in der Kategorie Hunde wie folgt aussehen:
* Globale Konfiguration
* Artikel-Manager → Optionen → Genehmigung → Erlaubnis
* Tierkategorie
* Kategorie Haustiere
* Kategorie Hunde
* spezifischer Artikel

====Beitrag====
Berechtigungen für einzelne Beiträge findet man im "Beitrag" unter dem Tab-Reiter "Berechigungen". Dieser Bildschirm hat drei Aktionen, wie unten gezeigt.

[[Image:j3x_acl_tutorial_article_manager_article_permissions-en.png]]

Auch hier bearbeiten Sie jede Gruppe für sich. Um auf die Berechtigungen zuzugreifen wechseln Sie im Artikel auf den Reiter "Berechtigungen" im oberen Reiter. Über das Drop Down Menü wählen Sie die neue Berechtigung im Anschluss speichern Sie den Beitrag ab.

Beachten Sie, dass die Aktionen Configure, Access Component und Create auf Artikelebene nicht gelten, so dass diese Aktionen nicht berücksichtigt werden. Die Berechtigung zum Anlegen eines Artikels wird auf einer der höheren Ebenen der Hierarchie festgelegt.

===Zugriffsebenen===

Die Zugriffsebenen der 3.x-Serie sind einfach und flexibel. Der folgende Bildschirm zeigt die spezielle Zugriffsebene.
[[Image:j3x_acl_tutorial_viewing_levels-en.png|center]]
Aktivieren Sie einfach das Kontrollkästchen für jede Gruppe, die Sie in diesem Level aufnehmen wollen. Die spezielle Zugriffsebene umfasst die Gruppen Manager, Autor und Superuser. Es beinhaltet auch untergeordnete Gruppen dieser Gruppen. Die Gruppe Administrator ist also enthalten, da es sich um eine Untergruppe der Gruppe Manager handelt. Die Gruppen Editor, Publisher und Shop Suppliers sind enthalten, da es sich um Untergruppen des Autors handelt.

Jedem Objekt im Frontend ist eine Zugriffsebene zugeordnet. Wenn die Ebene öffentlich ist, kann jeder auf dieses Objekt zugreifen. Andernfalls dürfen nur Mitglieder von Gruppen, die dieser Zugriffsebene zugeordnet sind, auf dieses Objekt zugreifen.

Die Zugriffsebenen sind den Menüpunkten und den Modulen zugeordnet. Jede kann nur einer Zugriffsebene zugeordnet werden.

Der folgende Bildschirm zeigt beispielsweise den Bildschirm Menüpunkt bearbeiten mit der Liste der verfügbaren Zugriffsebenen....

[[Image:j3x_acl_tutorial_edit_menu_item_level_dropdown-en.png|center]]

==Standard-ACL-Setup==

Wenn Joomla! installiert ist, werden diese auf die ursprünglichen Standardwerte gesetzt. Wir werden diese Grundeinstellungen besprechen, um die Arbeitsweise der ACL zu verstehen.

===Standardgruppen===

Mit der Version 3.x können Sie Ihre individuellen Gruppen definieren. Wenn Sie die Version 3.x installieren, enthält sie eine Reihe von Standardgruppen, die im Folgenden dargestellt werden, sind die grundlegenden Standardbenutzergruppen. (Zusätzliche Standardbenutzergruppen werden mit Beispieldaten installiert)

[[Image:Screenshot_usergroupsl_acl_J3_tutorial-en.png|center]]

Die Pfeile zeigen die untergeordneten Elternbeziehungen an. Wie vorstehend besprochen, wird diese Berechtigung, wenn Sie eine Berechtigung für eine übergeordnete Gruppe festlegen, automatisch an alle Untergruppen vererbt. Die vererbten und zulässigen Berechtigungen können für eine Untergruppe überschrieben werden. Die Berechtigung Verweigert kann nicht überschrieben werden und verweigert immer eine Aktion für alle Untergruppen.

===Konfiguration===

Joomla! Version 3.x wird mit den gleichen bekannten Backend-Rechten wie die Version 1.5 (EOL) installiert. Mit der Version 3.x können Sie diese jedoch leicht an die Bedürfnisse Ihrer Website anpassen.

Wie bereits besprochen, werden die Berechtigungen für jede Aktion von der obigen Ebene in der Berechtigungshierarchie und von der übergeordneten Gruppe einer Gruppe übernommen. Also, wie funktioniert das? Die oberste Ebene dafür ist der gesamte Standort. Dies wird in der Site->Globale Konfiguration->Berechtigungen eingerichtet, wie unten gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Das erste, was man bemerken sollte, sind die zehn Aktionen: Standortlogin, Admin-Login, Offline-Zugriff, Superuser, Access Administration Interface, Erstellen, Löschen, Bearbeiten, Status bearbeiten und Eigenes bearbeiten. Dies sind die Aktionen, die ein Benutzer an einem Objekt in Joomla durchführen kann. Die spezifische Bedeutung jeder Aktion hängt vom Kontext ab. Für das Bild Globale Konfiguration sind sie wie folgt definiert:

Site Login : Login to the front end of the site

;Admin Login : Melden Sie sich am Backend der Website an.

Offline-Zugriff: Melden Sie sich am Frontend der Website an, wenn die Website offline ist (wenn die globale Konfigurationseinstellung "Site Offline" auf Ja gesetzt ist).

Superuser: Gewährt dem Benutzer den Status "Superuser". Benutzer mit dieser Berechtigung dürfen alles auf der Website machen. Nur Benutzer mit dieser Berechtigung können die Einstellungen der globalen Konfiguration ändern. Diese Berechtigungen können nicht eingeschränkt werden. Es ist wichtig zu verstehen, dass, wenn ein Benutzer Mitglied einer Super Admin-Gruppe ist, alle anderen Berechtigungen, die diesem Benutzer zugewiesen sind, irrelevant sind. Der Benutzer kann jede Aktion auf der Website durchführen. Es können jedoch weiterhin Zugriffsebenen zugewiesen werden, um zu steuern, was diese Gruppe auf der Website sieht. (Natürlich kann ein Super-Admin-Benutzer die Zugriffsebenen ändern, wenn er möchte, so dass die Zugriffsebenen nicht vollständig einschränken, was ein Super-Admin-Benutzer sehen kann.)

Zugangskomponente: Öffnen Sie die Bildschirme der Komponentenverwaltung (Benutzerverwaltung, Menüverwaltung, Artikelverwaltung usw.).

;Create : Create new objects (for example, users, menu items, articles, weblinks, and so on)

;Löschen : Löschen eines existienden Objekts

;Ändern : Ändern eines existierenden Objektes

;Ändern eines Objekt Status (Veröffentlicht, nicht Veröffentlicht, Archiviert und Gelöscht)

Eigene Objekte bearbeiten: Bearbeiten Sie Objekte, die Sie erstellt haben.

Each Group for the site has its own slider which is opened by clicking on the group name. In this case (with the sample data installed), we have the standard 7 groups that we had in version 1.5 plus two additional groups called "Shop Suppliers" and "Customer Group". Notice that our groups are set up with the same permissions as they had in version 1.5. Keep in mind that we can change any of these permissions to make the security work the way we want. Let's go through this to see how it works.

* '''Public''' has everything set to "Not set", as shown below.{{-}}[[Image:Screenshot_global_acl_public_J3_tutorial-en.png]]
**This can be a bit confusing. Basically, "Not Set" is the same as "Inherited". Because Public is our top-level group, and because Global Configuration is the top level of the component hierarchy, there is nothing to inherit from. So "Not Set" is used instead of "Inherit".
**The default in this case is for no permissions. So, as you would expect, the Public group has no special permissions. Also, it is important to note that, since nothing is set to Denied, all of these permissions may be overridden by child groups or by lower levels in the permission hierarchy.

* '''Guest''' is a 'child' group of the Public group has everything set to 'Inherited' {{-}}[[Image:Screenshot_global_acl_guest_J3_tutorial-de.png]]
** This is the default 'Guest User Group' in the User Manager options and the Group that (non logged in) visitors to your site are placed in.

* '''Manager''' is a "child" group of the Public group. It has Allowed permissions for everything except Access Component and Super Admin. So a member of this group can do everything in the front and back end of the site except change Global Permissions and Component Options. {{-}}[[Image:Screenshot_global_acl_manager_J3_tutorial-en.png]]

* '''Administrator''' group members inherit all of the Manager permissions and also have Allowed for Access Component. So members of this group by default can access the Options screens for each component. {{-}}[[Image:Screenshot_global_acl_administrator_J3_tutorial-en.png]]

* '''Registered''' is the same a Public except for the Allow permission for the Site Login action. This means that members of the Registered group can login to the site. Since default permissions are inherited, this means that, unless a child group overrides this permission, all child groups of the Registered group will be able to login as well. {{-}}[[Image:Screenshot_global_acl_registered_J3_tutorial-en.png]]

* '''Author''' is a child of the Registered group and inherits its permissions and also adds Create and Edit Own. Since Author, Editor, and Publisher have no back-end permissions, we will discuss them below, when we discuss front-end permissions.{{-}}[[Image:Screenshot_global_acl_author_J3_tutorial-en.png]]

* '''Editor''' is a child of the Authors group and adds the Edit permission. {{-}}[[Image:Screenshot_global_acl_editor_J3_tutorial-en.png]]

* '''Publisher''' is a child of Editor and adds the Edit State permission.{{-}}[[Image:Screenshot_global_acl_publisher_J3_tutorial-en.png]]

* '''Shop Suppliers''' is an example group that is installed if you install the sample data. It is a child group of Author.

* '''Customer Group''' is an example group that is installed if you install the sample data. It is a child group of Registered.

* '''Super Users''' group has the Allow permission for the Super Admin action. Because of this, members of this group have super user permissions throughout the site. They are the only users who can access and edit values on the Global Configuration screen. Users with permission for the Super Admin action have some special characteristics:
:* If a user has Super Admin permissions, no other permissions for this user matter. The user can perform any action on the site.
:* Only Super Admin users can create, edit, or delete other Super Admin users or groups.

There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.

This provides a lot of flexibility. For example, if you wanted Shop Suppliers to be able to have the ability to login to the back end, you could just change their Admin Login value to "Allowed". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherited (or Denied).

It is also important to understand that the ability to have child groups is completely optional. It allows you to save some time when setting up new groups. However, if you like, you can set up all groups to have Public as the parent and not inherit any permissions from a parent group.

===Komponenten-Optionen & Berechtigungen===

Now, let's continue to see how the default back-end permissions for version 2.5 mimic the permissions for version 1.5. The Super Users group in 2.5 is equivalent to the Super Administrator group in 1.5.

Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 2.5 configuration. Let's see how this is accomplished.

If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:

[[Image:screenshot_acl_tutorial_20110111-09-en.png|center|]]
[[Image:screenshot_acl_tutorial_20110111-10-en.png|center|]]

This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.

First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.

Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.

If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.

In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.

It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.

===Frontend Berechtigungen===

Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions. First, let's look at the permissions for Manager, as shown below.
[[Image:screenshot_acl_tutorial_20110111-11a-en.png|center|frame]]
Manager has allowed permission for all actions except Configure. So members of the Manager group can do everything with Articles except open the Options screen.

Now let's look at Administrator, as shown below.
[[Image:screenshot_acl_tutorial_20110111-12a-en.png|center|frame]]
Administrator has Allowed for Configure, so Administrators can edit this Options screen.

Both groups can create, delete, edit, and change the state of articles.

Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set.

Authors only have Create and Edit Own permissions, as shown below.
[[Image:screenshot_acl_tutorial_20110112-07-en.png|center|frame]]
This means that Authors can create articles and can edit articles they have created. They may not delete articles, change the published state of articles, or edit articles created by others.

Editors have the same permissions as Authors with the addition of permission for the Edit action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-08-en.png|center|frame]]
So Editors can edit articles written by anyone.

Publishers can do everything Editors can do plus they have permission for the Edit State action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-09-en.png|center|frame]]
So Publishers can change the published state of an article. The possible states include Published, Unpublished, Archived, and Trashed.

All of these groups have Inherit permission for Configure and Access Component. Remember that Author is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Configure and Access Component, and since Author's permission for these actions is "Inherited", then Author does not have these permissions either. This same permission is passed from Author to Editor and from Editor to Publisher. So, by default, none of these groups are allowed to work with articles in the back end.

It is important to remember that these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.

Beachte auch das in den ursprünglichen Standardwerten keine Berechtigungen auf Verweigert eingestellt sind. Dies ermöglicht in allen Berechtigungsebenen die jeweilige Berechtigung auf Erlaubt einzustellen. Bedenke, wenn eine Aktion auf Verweigert eingestellt ist, das diese Aktion auch in allen untergeordneten Ebenen in der Berechtigungshierarchie verweigert wird. Zum Beispiel, wenn die Seitenameldung für Registered auf Verweigert (anstatt auf Erlaubt) eingestellt wird, kann man Publishers diese Aktion per Berechtigungeinstellung nicht erteilen.

=== Beitrags-Manager & Aktions-Diagramm ===

The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.

[[Image:screenshot_acl_tutorial_20110111-16-en.png|center|]]

* '''Configure''' allows you to view and change the Options for the component.
* '''Access Component''' allows you to navigate to the Article Manager. Without this permission, no other actions are possible.
* '''Create''' allows you to add new articles.
* '''Delete''' allows you to delete trashed articles. Note that the Delete icon only shows in the toolbar when you have the "Select State" filter set to "Trash".
* '''Edit''' allows you to edit existing articles.
* '''Edit State''' allows to you Publish, Unpublish, Archive, or Trash articles.
* '''Edit Own''' is the same as Edit except that it only applies to articles written by you.

==Allowing Guest-Only Access to Menu Items and Modules==

Version 1.6 introduced the ability to create a View Access Level that is only for guests of the site (meaning a user who is not logged in). The example below shows how you can set up this new feature.
''(N.B. Steps 1 to 3 are not needed for Joomla! 3.x as they exist in the default install)''

#Create a new user group called Guest. Make it a child of the Public group as shown below. [[Image:screenshot_acl_tutorial_20110112-01-en.png|center|frame]]
# Create a new access level called Guest and grant only the Guest group access to this level, as shown below.[[Image:screenshot_acl_tutorial_20110112-02-en.png|center|frame]]
# Navigate to User Manager→Options→Component and change the Guest User Group from the default value of "Public" to "Guest", as shown below.
[[Image:screenshot_acl_tutorial_20110112-04-en.png|center|frame]]
Now, if we assign a menu item, module, or other object to the Guest access level, only non-logged in users will have access. For example, if we create a new menu item with access level of Guest, as shown below,
[[Image:screenshot_acl_tutorial_20110112-05-en.png|center|frame]]
this menu item will only be visible to non-logged-in visitors to the site.

If required other user groups like Author can be granted access in the Guest access level, this would allow Authors to view articles in the front end for editing.

'''N.B. Login/logout in front end (''for changing data in session'') to see the change.'''

==Berechtigungen und Gruppenebenen gemeinsam nutzen==

As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.

This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:

* both groups can create new articles only in the History Assignments category.

* only History Teachers (not Assistant History Teachers) can Publish or otherwise have Edit State permission.

This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.

[[Image:Acl example diagram1 20091018-en.png|center|]]

In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.

To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.

Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.

[[Image:Acl example diagram2 20091018-en.png|center|]]

This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.

Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.

==ACL Aktion Berechtigungs-Beispiele==

===Backend Beitrag Administrator===

'''Problem:'''

We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.

'''Lösung:'''

# Create a new group called Article Administrator and make its parent group Public, as shown below.[[Image:screenshot_acl_tutorial_20110112-10-en.png|center|frame]] Because its parent group is Public, it won't have any permissions by default.
# In Users → Access Levels, edit the Special Access level to add the new group. That way they can get access to the back end menu items and modules (This assumes that the modules for the admin menu and quickicons have the Special Access level assigned to them, which is the default.) [[Image:screenshot_acl_tutorial_20110112-11-en.png|center|frame]] By default, the back-end menu items and modules are set to Special access, so if you forget to add the new group to the Special access level, you won't see any modules or menu items when you log in as a user of the new group.
# In Site → Global Configuration → Permissions, click on the Article Administrator group and change the permissions to Allowed for the following actions: Admin Login, Create, Delete, Edit, Edit State, and Edit Own. The screen below shows what will show before you press Save. [[Image:screenshot_acl_tutorial_20110112-12-de.png|center|frame]]After you save, the Calculated Permissions should show as shown below.[[Image:screenshot_acl_tutorial_20110112-13-de.png|center|frame]]Note that the permission for the Access Component is Inherited, which translates to Not Allowed. This is important. This means that this group will only be able to access components if we give the group "Allowed" permission for Access Component. So we only have to change the one component we want to give them access to and don't have to change any settings for the components where we don't want them to have access. If we had a case where we wanted to give a group access to everything except for one component, we could set the default to Allowed and then set the one component to Denied. Also note that we did not give the group Site Login permission, so users in this group will not be able to log into the front end. (If we wanted to allow that, we would just change the permission to Allowed for Site Login.)
# In Article Manager → Options → Permissions, change permissions to Allowed for this group for the Access Component action, as shown below.[[Image:screenshot_acl_tutorial_20110112-14-de.png|center|frame]]All of the other desired permissions are inherited.

That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end. For example, the screen below shows what a user in the Article Manager will see when they login to the back end.[[Image:screenshot_acl_tutorial_20110112-15-de.png|center|frame]]

==ACL Ansicht Zugriffsebenen-Beispiele==

A basic concept of using Access Levels is that all items with the same Access will be viewable by the same group of users. In other words, if two items have the same Access, you can't have one viewable by one user and not viewable by another user. On the other hand, it is easy to have one Group view any number of items with different Access levels.

Similarly, each Group has exactly the same combination of Access levels, but one User can be a member of more than one group. Depending on the situation, you may want to have users only in one Group or you may need to have a User in more than one Group.

This means that we may need to group our items so that items so that all items in a group have the same level of sensitivity. Here are some examples.

===Hierarchisches Beispiel===
In this example, Access levels are hierarchical, for example, like government security clearance codes. Say for example we have the following sets of classified documents: Classified, Secret, and Top Secret. Users have corresponding clearence codes. Users with Classified clearance can only see Classified documents and cannot see Secret or Top Secret. Users with Secret clearance can see Classified and Secret documents but not Top Secret. Users with Top Secret can see all documents.

In this case, you would create three Access levels: Classified, Secret, and Top Secret and the same three Groups. Users would only be members of one group, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| C1, C2, C3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Classified
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| S1, S2, S3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| TS1, TS2, TS3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Top Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret, Top Secret

|}

In this case, all users are in exactly one group, but some groups have access to more than one Access Level of items. In other words, we have a one-to-one relationship between users and groups, but a one-to-many relationship between Groups and Access Levels.

===Teamsicherheit Beispiel===

Another possible use case is a set of non-hierarchical teams. Let's say we have three teams, T1, T2, and T3. Some users are only on one team, but others might be on two or more teams. In this case, we could set up our Access Levels and Groups by team. Documents for each team have the access level for that team, and the Group for the team has only the one access level. When a User is on more than one team, they get added to the group for each team, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Beschreibung
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 1 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 2 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 3 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1, 2 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1,T2, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2, T3

|}

===Hybrid Example===

In a real-world situation, you might have a combination of these two arrangements. Say for example we have Managers and Staff. Staff can only see Staff documents and Managers can see Manager and Staff documents. Both types of users can be assigned to teams as well, in which case they can see all of the documents for that team. In addition, say that Managers can access some, but not all, team documents. Staff can only access team documents if they are members of that team.

In this example, we could set up the following Access Levels:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Access Level
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Description
| style="border:0.0007in solid #000000;padding:0.0382in;"| Groups

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team manager documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team staff documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team1 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1, Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team2 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2, Manager

|}

Then, users could be assigned to groups as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| User Type
| style="border:0.0007in solid #000000;padding:0.0382in;"| Group

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1, Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1, Team2

|}

<noinclude>
[[Category:Joomla! 1.6]]
[[Category:Joomla! 2.5]]
[[Category:Joomla! 3.x/de]]
[[Category:Tutorials/de]]
[[Category:Access Control/de]]
[[Category:Access Management]]
</noinclude>

Translations:J3.x:Access Control List Tutorial/199/de

2019-12-26T19:06:30Z

Sieger66:

J3.x:Access Control List Tutorial/de

2019-12-26T19:06:21Z

Sieger66:

<noinclude><languages /></noinclude>
{{Joomla version|version=3.x|comment=Serie}}
{{-}}
{{:J3.1:Access_Control_List/en}}

==Separate ACL für Anzeige und Aktionen==

Das Joomla ACL-System besteht genau genommen aus zwei völlig getrennten Systemen. Das eine System steuert, was Benutzer auf der Website "sehen" können. Das andere steuert, was Benutzer "tun" können (welche Aktionen ein Benutzer durchführen kann). Die ACL wird für jedes dieser Systeme anders eingerichtet.

===Steuern, was Benutzer sehen können===

Das Setup zum Steuern, was Benutzer sehen können, sieht wie folgt aus:
*Eine Reihe von Zugriffsebenen gemäß den Kategorien und/oder der Kombination von Kategorien erstellen, die nur angemeldete Benutzer sehen sollen. Anmerkung: Zu diesem Zeitpunkt werden noch keine Benutzergruppen den neuen Zugriffsebenen zugewiesen.

*Für jede Zugriffsebene eine Benutzergruppe erstellen, die 'Registriert' als übergeordnete Gruppe hat. Indem man für Benutzergruppen und Zugriffsebenen die gleichen Namen verwendet, kann man Verwirrungen zu einem späteren Zeitpunkt vorbeugen.

*Die neuen Zugriffsebenen bearbeiten und jeder die (neue) Benutzergruppe zuweisen. Wahrscheinlich möchten man auch die 'Super Benutzer' Gruppe (und/oder die anderen Standard-Benutzergruppen mit Ausnahme der Benutzergruppe 'Gast') den neuen Zugriffsebenen zuweisen.

*Jedem anzuzeigenden Eintrag eine Zugriffsebene zuweisen. Einträge sind sowohl inhaltliche Einträge (Beiträge, Kontakte, usw.), Menüeinträge als auch Module.

Immer dann, wenn ein Benutzer im Begriff ist, einen Eintrag auf einer Joomla-Seite anzeigen zu lassen, prüft das Programm, ob dieser Benutzer auch Zugriff auf den Eintrag hat. Das geschieht folgendermaßen:
# Zunächst wird eine Liste aller Zugriffsebenen erstellt, auf die der Benutzer zugreifen kann, basierend auf allen Gruppen, denen der Benutzer angehört. Sofern eine Gruppe eine übergeordnete Gruppe besitzt, sind die Zugriffsebenen für die übergeordnete Gruppe ebenfalls in der Liste enthalten.
# Danach wird überprüft, ob die Zugriffsebene für den Eintrag (Beitrag, Modul, Menüeintrag, usw.) in dieser Liste enthalten ist. Wenn dem so ist, wird der Eintrag dem Benutzer angezeigt. Falls der Benutzer die benötigten Zugriffsrechte besitzt, wird ihm der Zugriff verweigert.

Beachten, dass Zugriffsebenen für jede Gruppe separat festgelegt und nicht von der übergeordneten Gruppe einer Gruppe vererbt werden.

===Steuern, was Benutzer tun können===

Das System, das steuert, was Benutzer in einer Benutzergruppe tun können - welche Aktionen sie bei einem bestimmten Eintrag ausführen können - wird über den Tab 'Berechtigungen' in der Konfiguration und den Tab 'Berechtigungen' in den Optionen jeder einzelnen Komponente eingerichtet. Berechtigungen können auch auf Kategorienebene (bei Kernkomponenten) und auf Beitragsebene (bei Beiträgen) gesetzt werden.

* Wenn angemeldete Benutzer in bestimmten Kategorien Erstellen, Löschen, Status bearbeiten oder Eigene Inhalte bearbeiten dürfen, dann:
** Eine Benutzergruppe erstellen und als übergeordnete Gruppe eine der Benutzergruppen angeben, die Zugriff auf die Kategorie (oder Kategorien) haben, die diese neue Benutzergruppe ändern soll.
**Der neuen Benutzergruppe den entsprechenden Zugriffsebenen zuweisen. Dann die erforderlichen Berechtigungen für die neue Benutzergruppe entweder global oder pro Kategorie/Beitrag ändern.
*** Beim Erstellen einer Benutzergruppe ist es ratsam, eine übergeordnete Gruppe zu wählen, die über weniger Berechtigungen verfügt, als für die neue Gruppe erforderlich. Denn es ist einfacher, die Berechtigungen für jede Komponente/Kategorie/Beitrag zu erweitern, für die zusätzliche Berechtigungen nötig sind, als Berechtigungen aus den anderen Komponenten/Kategorien/Beiträgen zu entfernen.
****''(Beispiel: Es gibt 10 Kategorien, man möchte aber nur für eine Erstellen-Berechtigungen. Würde man für diese Gruppe die Berechtigungen global auf Erstellen erlaubt setzen, müsste man für diese Kategorien die Erstellen-Berechtigung entfernen. Und man müsste für diese Gruppe die Erstellen-Berechtigung bei jeder neuen Kategorie, die man zu einem späteren Zeitpunkt hinzufügt, ebenfalls entfernen).''
** Eine Benutzergruppe erstellen, die eine der Standardbenutzergruppen als übergeordnete Gruppe hat, NUR, wenn keine von diesen über die exakten Berechtigungen verfügt, die man benötigt und sich für alle Kategorien wünscht.

Beachten, dass dieses Setup unabhängig vom Setup für die Anzeige ist. Allerdings muss eine Benutzergruppe den entsprechenden Zugriffsebenen zugewiesen werden, damit der Benutzer in dieser Gruppe jene Berechtigungen verwenden kann.

Möchte ein Benutzer eine bestimmte Aktion bei einem Komponenten-Eintrag durchführen (z. B. einen Beitrag bearbeiten), überprüft das System (nachdem es überprüft hat, welcher Gruppe der Benutzer angehört und auf welche er Zugriff hat) die Berechtigung für diese Kombination aus Benutzer, Eintrag und Aktion. Liegt eine Erlaubnis vor, kann der Benutzer fortfahren. Andernfalls ist die Aktion nicht zulässig.

Das restliche Tutorial befasst sich mit der Steuerung, was Benutzer tun können - welche Aktionsberechtigungen sie haben.

==Aktionen, Gruppen und Vererbung==

Andererseits geht es bei der ACL auch darum, Benutzern Berechtigungen zu erteilen, damit diese Aktionen an Objekten durchführen können.

{| class="wikitable"
!style="width:20%;"|
!3.x Serie
|-
!Gruppen und Aktionen
|Aktionen, welche pro Gruppe erlaubt sind, werden durch den Website Administrator festgelegt.
|-
!Umfang von Berechtigungen
|Berechtigungen können auf mehreren Ebenen in der Hierarchie festgelegt werden: Website, Komponente, Kategorie, Objekt.
|-
!Vererbung von Berechtigungen
|Berechtigungen können von übergeordneten Gruppen und übergeordneten Kategorien geerbt werden.
|}

===Wie die Berechtigungen funktionieren===

Es gibt vier mögliche Berechtigungen für Aktionen. Diese sind (kurz skizziert):

* '''Nicht gesetzt''': Fällt standardmäßig auf "Nicht erlaubt" zurück. Aber im Gegensatz zur Berechtigung "Verweigert" kann diese Berechtigung außer Kraft gesetzt werden, wenn eine untergeordnete Gruppe oder eine in der Berechtigungshierarchie untergeordnete Ebene auf "Erlaubt" gesetzt wird. Diese Berechtigung kann nur für globale Berechtigungen der Konfiguration gesetzt werden.
* '''Vererbt''': Erbt den Wert von einer übergeordneten Gruppe oder einer in der Berechtigungshierarchie höheren Ebene. Diese Berechtigung gilt für alle Ebenen mit Ausnahme der obersten Ebene der Konfiguration.
* '''Verweigert''': Verbietet diese Aktion für diese Ebene und Gruppe. '''WICHTIG:''' Dadurch wird diese Aktion auch für alle untergeordneten Gruppen und alle untergeordneten Ebenen in der Berechtigungshierarchie verboten. Wird "Erlaubt" in einer untergeordneten Gruppe oder einer tieferen Ebene gesetzt, hat das keinen Effekt. Die Aktion wird immer für alle Mitglieder einer untergeordneten Gruppe und für alle untergeordneten Ebenen in der Berechtigungshierarchie abgelehnt.
* '''Erlaubt ''': Genehmigt diese Aktion für diese Ebene und Gruppe und für tiefere Ebenen und Untergruppen. Dies hat keine Auswirkungen, wenn eine höhere Gruppe oder Ebene auf "Verweigert" oder "Erlaubt" eingestellt ist. Wenn eine höhere Gruppe oder ein höheres Ebene auf "Verweigert" gesetzt ist, wird diese Berechtigung immer abgelehnt. Wenn eine höhere Gruppe oder Ebene auf Erlaubt eingestellt ist, ist diese Berechtigung bereits erlaubt.

===Hierarchie der Berechtigungsebenen===

Berechtigungen für Aktionen können in Version 2.5+ auf bis zu vier Ebenen festgelegt werden, wie folgt:
# '''Konfiguration''': legt die Standardberechtigungen für jede Aktion und Gruppe fest.
# '''Komponenten-Optionen-> Berechtigungen''': kann die Standardberechtigungen für diese Komponente überschreiben (z. B. Beiträge, Menüs, Benutzer, Banner usw.).
# '''Kategorie''': kann die Standardberechtigungen für Objekte in einer oder mehreren Kategorien überschreiben. Gilt für alle Komponenten mit Kategorien, einschließlich Beiträge, Banner, Kontakte, Newsfeeds und Weblinks.
# '''Beitrag''': kann die Berechtigungen für einen bestimmten Artikel überschreiben. Diese Ebene gilt nur für Beiträge. Alle anderen Komponenten erlauben nur die ersten drei Ebenen.

====Konfiguration====
Diese erreicht man über System → Konfiguration → Berechtigungen. Die nun sichtbare Maske dient dazu, die Berechtigungen auf der obersten Ebene für jede Gruppe und jede Aktion festzulegen, wie auch in der folgenden Abbildung gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Die möglichen Werte sind Vererbt, Erlaubt oder Verweigert. Die Spalte 'Errechnete Einstellung' zeigt die aktuelle Einstellung an. Diese ist entweder Nicht erlaubt (Standard), Erlaubt oder Nicht erlaubt.

Man kann immer nur an einer Gruppe gleichzeitig arbeiten, indem man den Reiter für ebendiese Gruppe anklickt. Die Berechtigungen kann man über die Dropdownlisten unter Neue Einstellung wählen ändern.

Beachten Sie, dass die Spalte "Errechnete Einstellung" erst aktualisiert wird, wenn Sie auf die Schaltfläche "Speichern" in der Werkzeugleiste klicken.

Um zu überprüfen, ob die Einstellungen Ihren Wünschen entsprechen, klicken Sie auf die Schaltfläche Speichern und überprüfen anschließend die Spalte Errechnete Einstellung.

====Komponenten-Optionen->Berechtigungen====
Auf diese wird für jede Komponente durch Klicken auf das Symbol "Optionen" in der Werkzeugleiste zugegriffen. Dieser Bildschirm ist ähnlich wie der Bildschirm "Globale Konfiguration" oben links. Wenn Sie beispielsweise im Menü-Manager auf das Symbol in der Werkzeugleiste Optionen klicken, werden die folgenden Menüs angezeigt.
[[Image:Screenshot_menu_acl_J3_tutorial-en.jpg]]

Der Zugriff auf Optionen ist nur für Mitglieder von Gruppen möglich, die die Berechtigung für die Aktion Konfiguration in für jede Komponente haben. Im obigen Beispiel hat die Gruppe Administrator die Berechtigung Erlaubt für die Option Konfigurieren, so dass Mitglieder dieser Gruppe auf diesen Bildschirm zugreifen können.

===Kategorie===
Auf die Kategorieberechtigungen wird im Category Manager zugegriffen: Bildschirm Kategorie bearbeiten, in einer Registerkarte oben auf dem Bildschirm. Dieser Bildschirm hat fünf Berechtigungen, wie folgt:

[[Image:Screenshot_category_acl_j3_tutorial-en.png]]

In diesen Bildern bearbeiten Sie die Berechtigungen für jeweils eine Benutzergruppe. Im obigen Beispiel bearbeiten Sie die Berechtigungen für die Gruppe Administrator.

Achten Sie darauf, dass die Aktionen "Konfigurieren und Zugriffssteuerung" nicht auf der Kategorieebene angewendet werden, so dass diese Aktionen nicht enthalten sind.

Beachten Sie auch, dass Kategorien in einer Hierarchie angeordnet werden können. Wenn ja, dann werden Aktionsberechtigungen in einer übergeordneten Kategorie automatisch an eine untergeordnete Kategorie vererbt. Wenn Sie beispielsweise eine Kategoriehierarchie von Tieren → Haustiere → Hunde hätten, dann würde die vollständige Berechtigungshierarchie für einen Artikel in der Kategorie Hunde wie folgt aussehen:
* Globale Konfiguration
* Artikel-Manager → Optionen → Genehmigung → Erlaubnis
* Tierkategorie
* Kategorie Haustiere
* Kategorie Hunde
* spezifischer Artikel

====Beitrag====
Berechtigungen für einzelne Beiträge findet man im "Beitrag" unter dem Tab-Reiter "Berechigungen". Dieser Bildschirm hat drei Aktionen, wie unten gezeigt.

[[Image:j3x_acl_tutorial_article_manager_article_permissions-en.png]]

Auch hier bearbeiten Sie jede Gruppe für sich. Um auf die Berechtigungen zuzugreifen wechseln Sie im Artikel auf den Reiter "Berechtigungen" im oberen Reiter. Über das Drop Down Menü wählen Sie die neue Berechtigung im Anschluss speichern Sie den Beitrag ab.

Beachten Sie, dass die Aktionen Configure, Access Component und Create auf Artikelebene nicht gelten, so dass diese Aktionen nicht berücksichtigt werden. Die Berechtigung zum Anlegen eines Artikels wird auf einer der höheren Ebenen der Hierarchie festgelegt.

===Zugriffsebenen===

Die Zugriffsebenen der 3.x-Serie sind einfach und flexibel. Der folgende Bildschirm zeigt die spezielle Zugriffsebene.
[[Image:j3x_acl_tutorial_viewing_levels-en.png|center]]
Aktivieren Sie einfach das Kontrollkästchen für jede Gruppe, die Sie in diesem Level aufnehmen wollen. Die spezielle Zugriffsebene umfasst die Gruppen Manager, Autor und Superuser. Es beinhaltet auch untergeordnete Gruppen dieser Gruppen. Die Gruppe Administrator ist also enthalten, da es sich um eine Untergruppe der Gruppe Manager handelt. Die Gruppen Editor, Publisher und Shop Suppliers sind enthalten, da es sich um Untergruppen des Autors handelt.

Jedem Objekt im Frontend ist eine Zugriffsebene zugeordnet. Wenn die Ebene öffentlich ist, kann jeder auf dieses Objekt zugreifen. Andernfalls dürfen nur Mitglieder von Gruppen, die dieser Zugriffsebene zugeordnet sind, auf dieses Objekt zugreifen.

Die Zugriffsebenen sind den Menüpunkten und den Modulen zugeordnet. Jede kann nur einer Zugriffsebene zugeordnet werden.

Der folgende Bildschirm zeigt beispielsweise den Bildschirm Menüpunkt bearbeiten mit der Liste der verfügbaren Zugriffsebenen....

[[Image:j3x_acl_tutorial_edit_menu_item_level_dropdown-en.png|center]]

==Standard-ACL-Setup==

Wenn Joomla! installiert ist, werden diese auf die ursprünglichen Standardwerte gesetzt. Wir werden diese Grundeinstellungen besprechen, um die Arbeitsweise der ACL zu verstehen.

===Standardgruppen===

Mit der Version 3.x können Sie Ihre individuellen Gruppen definieren. Wenn Sie die Version 3.x installieren, enthält sie eine Reihe von Standardgruppen, die im Folgenden dargestellt werden, sind die grundlegenden Standardbenutzergruppen. (Zusätzliche Standardbenutzergruppen werden mit Beispieldaten installiert)

[[Image:Screenshot_usergroupsl_acl_J3_tutorial-en.png|center]]

Die Pfeile zeigen die untergeordneten Elternbeziehungen an. Wie vorstehend besprochen, wird diese Berechtigung, wenn Sie eine Berechtigung für eine übergeordnete Gruppe festlegen, automatisch an alle Untergruppen vererbt. Die vererbten und zulässigen Berechtigungen können für eine Untergruppe überschrieben werden. Die Berechtigung Verweigert kann nicht überschrieben werden und verweigert immer eine Aktion für alle Untergruppen.

===Konfiguration===

Joomla! Version 3.x wird mit den gleichen bekannten Backend-Rechten wie die Version 1.5 (EOL) installiert. Mit der Version 3.x können Sie diese jedoch leicht an die Bedürfnisse Ihrer Website anpassen.

Wie bereits besprochen, werden die Berechtigungen für jede Aktion von der obigen Ebene in der Berechtigungshierarchie und von der übergeordneten Gruppe einer Gruppe übernommen. Also, wie funktioniert das? Die oberste Ebene dafür ist der gesamte Standort. Dies wird in der Site->Globale Konfiguration->Berechtigungen eingerichtet, wie unten gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Das erste, was man bemerken sollte, sind die zehn Aktionen: Standortlogin, Admin-Login, Offline-Zugriff, Superuser, Access Administration Interface, Erstellen, Löschen, Bearbeiten, Status bearbeiten und Eigenes bearbeiten. Dies sind die Aktionen, die ein Benutzer an einem Objekt in Joomla durchführen kann. Die spezifische Bedeutung jeder Aktion hängt vom Kontext ab. Für das Bild Globale Konfiguration sind sie wie folgt definiert:

Site Login : Login to the front end of the site

;Admin Login : Melden Sie sich am Backend der Website an.

Offline-Zugriff: Melden Sie sich am Frontend der Website an, wenn die Website offline ist (wenn die globale Konfigurationseinstellung "Site Offline" auf Ja gesetzt ist).

Superuser: Gewährt dem Benutzer den Status "Superuser". Benutzer mit dieser Berechtigung dürfen alles auf der Website machen. Nur Benutzer mit dieser Berechtigung können die Einstellungen der globalen Konfiguration ändern. Diese Berechtigungen können nicht eingeschränkt werden. Es ist wichtig zu verstehen, dass, wenn ein Benutzer Mitglied einer Super Admin-Gruppe ist, alle anderen Berechtigungen, die diesem Benutzer zugewiesen sind, irrelevant sind. Der Benutzer kann jede Aktion auf der Website durchführen. Es können jedoch weiterhin Zugriffsebenen zugewiesen werden, um zu steuern, was diese Gruppe auf der Website sieht. (Natürlich kann ein Super-Admin-Benutzer die Zugriffsebenen ändern, wenn er möchte, so dass die Zugriffsebenen nicht vollständig einschränken, was ein Super-Admin-Benutzer sehen kann.)

Zugangskomponente: Öffnen Sie die Bildschirme der Komponentenverwaltung (Benutzerverwaltung, Menüverwaltung, Artikelverwaltung usw.).

;Create : Create new objects (for example, users, menu items, articles, weblinks, and so on)

;Löschen : Löschen eines existienden Objekts

;Ändern : Ändern eines existierenden Objektes

;Ändern eines Objekt Status (Veröffentlicht, nicht Veröffentlicht, Archiviert und Gelöscht)

Eigene Objekte bearbeiten: Bearbeiten Sie Objekte, die Sie erstellt haben.

Each Group for the site has its own slider which is opened by clicking on the group name. In this case (with the sample data installed), we have the standard 7 groups that we had in version 1.5 plus two additional groups called "Shop Suppliers" and "Customer Group". Notice that our groups are set up with the same permissions as they had in version 1.5. Keep in mind that we can change any of these permissions to make the security work the way we want. Let's go through this to see how it works.

* '''Public''' has everything set to "Not set", as shown below.{{-}}[[Image:Screenshot_global_acl_public_J3_tutorial-en.png]]
**This can be a bit confusing. Basically, "Not Set" is the same as "Inherited". Because Public is our top-level group, and because Global Configuration is the top level of the component hierarchy, there is nothing to inherit from. So "Not Set" is used instead of "Inherit".
**The default in this case is for no permissions. So, as you would expect, the Public group has no special permissions. Also, it is important to note that, since nothing is set to Denied, all of these permissions may be overridden by child groups or by lower levels in the permission hierarchy.

* '''Guest''' is a 'child' group of the Public group has everything set to 'Inherited' {{-}}[[Image:Screenshot_global_acl_guest_J3_tutorial-de.png]]
** This is the default 'Guest User Group' in the User Manager options and the Group that (non logged in) visitors to your site are placed in.

* '''Manager''' is a "child" group of the Public group. It has Allowed permissions for everything except Access Component and Super Admin. So a member of this group can do everything in the front and back end of the site except change Global Permissions and Component Options. {{-}}[[Image:Screenshot_global_acl_manager_J3_tutorial-en.png]]

* '''Administrator''' group members inherit all of the Manager permissions and also have Allowed for Access Component. So members of this group by default can access the Options screens for each component. {{-}}[[Image:Screenshot_global_acl_administrator_J3_tutorial-en.png]]

* '''Registered''' is the same a Public except for the Allow permission for the Site Login action. This means that members of the Registered group can login to the site. Since default permissions are inherited, this means that, unless a child group overrides this permission, all child groups of the Registered group will be able to login as well. {{-}}[[Image:Screenshot_global_acl_registered_J3_tutorial-en.png]]

* '''Author''' is a child of the Registered group and inherits its permissions and also adds Create and Edit Own. Since Author, Editor, and Publisher have no back-end permissions, we will discuss them below, when we discuss front-end permissions.{{-}}[[Image:Screenshot_global_acl_author_J3_tutorial-en.png]]

* '''Editor''' is a child of the Authors group and adds the Edit permission. {{-}}[[Image:Screenshot_global_acl_editor_J3_tutorial-en.png]]

* '''Publisher''' is a child of Editor and adds the Edit State permission.{{-}}[[Image:Screenshot_global_acl_publisher_J3_tutorial-en.png]]

* '''Shop Suppliers''' is an example group that is installed if you install the sample data. It is a child group of Author.

* '''Customer Group''' is an example group that is installed if you install the sample data. It is a child group of Registered.

* '''Super Users''' group has the Allow permission for the Super Admin action. Because of this, members of this group have super user permissions throughout the site. They are the only users who can access and edit values on the Global Configuration screen. Users with permission for the Super Admin action have some special characteristics:
:* If a user has Super Admin permissions, no other permissions for this user matter. The user can perform any action on the site.
:* Only Super Admin users can create, edit, or delete other Super Admin users or groups.

There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.

This provides a lot of flexibility. For example, if you wanted Shop Suppliers to be able to have the ability to login to the back end, you could just change their Admin Login value to "Allowed". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherited (or Denied).

It is also important to understand that the ability to have child groups is completely optional. It allows you to save some time when setting up new groups. However, if you like, you can set up all groups to have Public as the parent and not inherit any permissions from a parent group.

===Komponenten-Optionen & Berechtigungen===

Now, let's continue to see how the default back-end permissions for version 2.5 mimic the permissions for version 1.5. The Super Users group in 2.5 is equivalent to the Super Administrator group in 1.5.

Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 2.5 configuration. Let's see how this is accomplished.

If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:

[[Image:screenshot_acl_tutorial_20110111-09-en.png|center|]]
[[Image:screenshot_acl_tutorial_20110111-10-en.png|center|]]

This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.

First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.

Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.

If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.

In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.

It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.

===Frontend Berechtigungen===

Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions. First, let's look at the permissions for Manager, as shown below.
[[Image:screenshot_acl_tutorial_20110111-11a-en.png|center|frame]]
Manager has allowed permission for all actions except Configure. So members of the Manager group can do everything with Articles except open the Options screen.

Now let's look at Administrator, as shown below.
[[Image:screenshot_acl_tutorial_20110111-12a-en.png|center|frame]]
Administrator has Allowed for Configure, so Administrators can edit this Options screen.

Both groups can create, delete, edit, and change the state of articles.

Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set.

Authors only have Create and Edit Own permissions, as shown below.
[[Image:screenshot_acl_tutorial_20110112-07-en.png|center|frame]]
This means that Authors can create articles and can edit articles they have created. They may not delete articles, change the published state of articles, or edit articles created by others.

Editors have the same permissions as Authors with the addition of permission for the Edit action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-08-en.png|center|frame]]
So Editors can edit articles written by anyone.

Publishers can do everything Editors can do plus they have permission for the Edit State action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-09-en.png|center|frame]]
So Publishers can change the published state of an article. The possible states include Published, Unpublished, Archived, and Trashed.

All of these groups have Inherit permission for Configure and Access Component. Remember that Author is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Configure and Access Component, and since Author's permission for these actions is "Inherited", then Author does not have these permissions either. This same permission is passed from Author to Editor and from Editor to Publisher. So, by default, none of these groups are allowed to work with articles in the back end.

It is important to remember that these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.

Beachte auch das in den ursprünglichen Standardwerten keine Berechtigungen auf Verweigert eingestellt sind. Dies ermöglicht in allen Berechtigungsebenen die jeweilige Berechtigung auf Erlaubt einzustellen. Bedenke, wenn eine Aktion auf Verweigert eingestellt ist, das diese Aktion auch in allen untergeordneten Ebenen in der Berechtigungshierarchie verweigert wird. Zum Beispiel, wenn die Seitenameldung für Registered auf Verweigert (anstatt auf Erlaubt) eingestellt wird, kann man Publishers diese Aktion per Berechtigungeinstellung nicht erteilen.

=== Beitrags-Manager & Aktions-Diagramm ===

The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.

[[Image:screenshot_acl_tutorial_20110111-16-en.png|center|]]

* '''Configure''' allows you to view and change the Options for the component.
* '''Access Component''' allows you to navigate to the Article Manager. Without this permission, no other actions are possible.
* '''Create''' allows you to add new articles.
* '''Delete''' allows you to delete trashed articles. Note that the Delete icon only shows in the toolbar when you have the "Select State" filter set to "Trash".
* '''Edit''' allows you to edit existing articles.
* '''Edit State''' allows to you Publish, Unpublish, Archive, or Trash articles.
* '''Edit Own''' is the same as Edit except that it only applies to articles written by you.

==Allowing Guest-Only Access to Menu Items and Modules==

Version 1.6 introduced the ability to create a View Access Level that is only for guests of the site (meaning a user who is not logged in). The example below shows how you can set up this new feature.
''(N.B. Steps 1 to 3 are not needed for Joomla! 3.x as they exist in the default install)''

#Create a new user group called Guest. Make it a child of the Public group as shown below. [[Image:screenshot_acl_tutorial_20110112-01-en.png|center|frame]]
# Create a new access level called Guest and grant only the Guest group access to this level, as shown below.[[Image:screenshot_acl_tutorial_20110112-02-en.png|center|frame]]
# Navigate to User Manager→Options→Component and change the Guest User Group from the default value of "Public" to "Guest", as shown below.
[[Image:screenshot_acl_tutorial_20110112-04-en.png|center|frame]]
Now, if we assign a menu item, module, or other object to the Guest access level, only non-logged in users will have access. For example, if we create a new menu item with access level of Guest, as shown below,
[[Image:screenshot_acl_tutorial_20110112-05-en.png|center|frame]]
this menu item will only be visible to non-logged-in visitors to the site.

If required other user groups like Author can be granted access in the Guest access level, this would allow Authors to view articles in the front end for editing.

'''N.B. Login/logout in front end (''for changing data in session'') to see the change.'''

==Berechtigungen und Gruppenebenen gemeinsam nutzen==

As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.

This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:

* both groups can create new articles only in the History Assignments category.

* only History Teachers (not Assistant History Teachers) can Publish or otherwise have Edit State permission.

This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.

[[Image:Acl example diagram1 20091018-en.png|center|]]

In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.

To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.

Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.

[[Image:Acl example diagram2 20091018-en.png|center|]]

This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.

Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.

==ACL Aktion Berechtigungs-Beispiele==

===Backend Beitrag Administrator===

'''Problem:'''

We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.

'''Lösung:'''

# Create a new group called Article Administrator and make its parent group Public, as shown below.[[Image:screenshot_acl_tutorial_20110112-10-en.png|center|frame]] Because its parent group is Public, it won't have any permissions by default.
# In Users → Access Levels, edit the Special Access level to add the new group. That way they can get access to the back end menu items and modules (This assumes that the modules for the admin menu and quickicons have the Special Access level assigned to them, which is the default.) [[Image:screenshot_acl_tutorial_20110112-11-de.png|center|frame]] By default, the back-end menu items and modules are set to Special access, so if you forget to add the new group to the Special access level, you won't see any modules or menu items when you log in as a user of the new group.
# In Site → Global Configuration → Permissions, click on the Article Administrator group and change the permissions to Allowed for the following actions: Admin Login, Create, Delete, Edit, Edit State, and Edit Own. The screen below shows what will show before you press Save. [[Image:screenshot_acl_tutorial_20110112-12-de.png|center|frame]]After you save, the Calculated Permissions should show as shown below.[[Image:screenshot_acl_tutorial_20110112-13-de.png|center|frame]]Note that the permission for the Access Component is Inherited, which translates to Not Allowed. This is important. This means that this group will only be able to access components if we give the group "Allowed" permission for Access Component. So we only have to change the one component we want to give them access to and don't have to change any settings for the components where we don't want them to have access. If we had a case where we wanted to give a group access to everything except for one component, we could set the default to Allowed and then set the one component to Denied. Also note that we did not give the group Site Login permission, so users in this group will not be able to log into the front end. (If we wanted to allow that, we would just change the permission to Allowed for Site Login.)
# In Article Manager → Options → Permissions, change permissions to Allowed for this group for the Access Component action, as shown below.[[Image:screenshot_acl_tutorial_20110112-14-de.png|center|frame]]All of the other desired permissions are inherited.

That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end. For example, the screen below shows what a user in the Article Manager will see when they login to the back end.[[Image:screenshot_acl_tutorial_20110112-15-de.png|center|frame]]

==ACL Ansicht Zugriffsebenen-Beispiele==

A basic concept of using Access Levels is that all items with the same Access will be viewable by the same group of users. In other words, if two items have the same Access, you can't have one viewable by one user and not viewable by another user. On the other hand, it is easy to have one Group view any number of items with different Access levels.

Similarly, each Group has exactly the same combination of Access levels, but one User can be a member of more than one group. Depending on the situation, you may want to have users only in one Group or you may need to have a User in more than one Group.

This means that we may need to group our items so that items so that all items in a group have the same level of sensitivity. Here are some examples.

===Hierarchisches Beispiel===
In this example, Access levels are hierarchical, for example, like government security clearance codes. Say for example we have the following sets of classified documents: Classified, Secret, and Top Secret. Users have corresponding clearence codes. Users with Classified clearance can only see Classified documents and cannot see Secret or Top Secret. Users with Secret clearance can see Classified and Secret documents but not Top Secret. Users with Top Secret can see all documents.

In this case, you would create three Access levels: Classified, Secret, and Top Secret and the same three Groups. Users would only be members of one group, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| C1, C2, C3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Classified
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| S1, S2, S3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| TS1, TS2, TS3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Top Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret, Top Secret

|}

In this case, all users are in exactly one group, but some groups have access to more than one Access Level of items. In other words, we have a one-to-one relationship between users and groups, but a one-to-many relationship between Groups and Access Levels.

===Teamsicherheit Beispiel===

Another possible use case is a set of non-hierarchical teams. Let's say we have three teams, T1, T2, and T3. Some users are only on one team, but others might be on two or more teams. In this case, we could set up our Access Levels and Groups by team. Documents for each team have the access level for that team, and the Group for the team has only the one access level. When a User is on more than one team, they get added to the group for each team, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Beschreibung
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 1 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 2 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 3 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1, 2 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1,T2, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2, T3

|}

===Hybrid Example===

In a real-world situation, you might have a combination of these two arrangements. Say for example we have Managers and Staff. Staff can only see Staff documents and Managers can see Manager and Staff documents. Both types of users can be assigned to teams as well, in which case they can see all of the documents for that team. In addition, say that Managers can access some, but not all, team documents. Staff can only access team documents if they are members of that team.

In this example, we could set up the following Access Levels:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Access Level
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Description
| style="border:0.0007in solid #000000;padding:0.0382in;"| Groups

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team manager documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team staff documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team1 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1, Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team2 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2, Manager

|}

Then, users could be assigned to groups as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| User Type
| style="border:0.0007in solid #000000;padding:0.0382in;"| Group

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1, Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1, Team2

|}

<noinclude>
[[Category:Joomla! 1.6]]
[[Category:Joomla! 2.5]]
[[Category:Joomla! 3.x/de]]
[[Category:Tutorials/de]]
[[Category:Access Control/de]]
[[Category:Access Management]]
</noinclude>

Translations:J3.x:Access Control List Tutorial/196/de

2019-12-26T19:06:20Z

Sieger66:

J3.x:Access Control List Tutorial/de

2019-12-26T19:06:08Z

Sieger66:

<noinclude><languages /></noinclude>
{{Joomla version|version=3.x|comment=Serie}}
{{-}}
{{:J3.1:Access_Control_List/en}}

==Separate ACL für Anzeige und Aktionen==

Das Joomla ACL-System besteht genau genommen aus zwei völlig getrennten Systemen. Das eine System steuert, was Benutzer auf der Website "sehen" können. Das andere steuert, was Benutzer "tun" können (welche Aktionen ein Benutzer durchführen kann). Die ACL wird für jedes dieser Systeme anders eingerichtet.

===Steuern, was Benutzer sehen können===

Das Setup zum Steuern, was Benutzer sehen können, sieht wie folgt aus:
*Eine Reihe von Zugriffsebenen gemäß den Kategorien und/oder der Kombination von Kategorien erstellen, die nur angemeldete Benutzer sehen sollen. Anmerkung: Zu diesem Zeitpunkt werden noch keine Benutzergruppen den neuen Zugriffsebenen zugewiesen.

*Für jede Zugriffsebene eine Benutzergruppe erstellen, die 'Registriert' als übergeordnete Gruppe hat. Indem man für Benutzergruppen und Zugriffsebenen die gleichen Namen verwendet, kann man Verwirrungen zu einem späteren Zeitpunkt vorbeugen.

*Die neuen Zugriffsebenen bearbeiten und jeder die (neue) Benutzergruppe zuweisen. Wahrscheinlich möchten man auch die 'Super Benutzer' Gruppe (und/oder die anderen Standard-Benutzergruppen mit Ausnahme der Benutzergruppe 'Gast') den neuen Zugriffsebenen zuweisen.

*Jedem anzuzeigenden Eintrag eine Zugriffsebene zuweisen. Einträge sind sowohl inhaltliche Einträge (Beiträge, Kontakte, usw.), Menüeinträge als auch Module.

Immer dann, wenn ein Benutzer im Begriff ist, einen Eintrag auf einer Joomla-Seite anzeigen zu lassen, prüft das Programm, ob dieser Benutzer auch Zugriff auf den Eintrag hat. Das geschieht folgendermaßen:
# Zunächst wird eine Liste aller Zugriffsebenen erstellt, auf die der Benutzer zugreifen kann, basierend auf allen Gruppen, denen der Benutzer angehört. Sofern eine Gruppe eine übergeordnete Gruppe besitzt, sind die Zugriffsebenen für die übergeordnete Gruppe ebenfalls in der Liste enthalten.
# Danach wird überprüft, ob die Zugriffsebene für den Eintrag (Beitrag, Modul, Menüeintrag, usw.) in dieser Liste enthalten ist. Wenn dem so ist, wird der Eintrag dem Benutzer angezeigt. Falls der Benutzer die benötigten Zugriffsrechte besitzt, wird ihm der Zugriff verweigert.

Beachten, dass Zugriffsebenen für jede Gruppe separat festgelegt und nicht von der übergeordneten Gruppe einer Gruppe vererbt werden.

===Steuern, was Benutzer tun können===

Das System, das steuert, was Benutzer in einer Benutzergruppe tun können - welche Aktionen sie bei einem bestimmten Eintrag ausführen können - wird über den Tab 'Berechtigungen' in der Konfiguration und den Tab 'Berechtigungen' in den Optionen jeder einzelnen Komponente eingerichtet. Berechtigungen können auch auf Kategorienebene (bei Kernkomponenten) und auf Beitragsebene (bei Beiträgen) gesetzt werden.

* Wenn angemeldete Benutzer in bestimmten Kategorien Erstellen, Löschen, Status bearbeiten oder Eigene Inhalte bearbeiten dürfen, dann:
** Eine Benutzergruppe erstellen und als übergeordnete Gruppe eine der Benutzergruppen angeben, die Zugriff auf die Kategorie (oder Kategorien) haben, die diese neue Benutzergruppe ändern soll.
**Der neuen Benutzergruppe den entsprechenden Zugriffsebenen zuweisen. Dann die erforderlichen Berechtigungen für die neue Benutzergruppe entweder global oder pro Kategorie/Beitrag ändern.
*** Beim Erstellen einer Benutzergruppe ist es ratsam, eine übergeordnete Gruppe zu wählen, die über weniger Berechtigungen verfügt, als für die neue Gruppe erforderlich. Denn es ist einfacher, die Berechtigungen für jede Komponente/Kategorie/Beitrag zu erweitern, für die zusätzliche Berechtigungen nötig sind, als Berechtigungen aus den anderen Komponenten/Kategorien/Beiträgen zu entfernen.
****''(Beispiel: Es gibt 10 Kategorien, man möchte aber nur für eine Erstellen-Berechtigungen. Würde man für diese Gruppe die Berechtigungen global auf Erstellen erlaubt setzen, müsste man für diese Kategorien die Erstellen-Berechtigung entfernen. Und man müsste für diese Gruppe die Erstellen-Berechtigung bei jeder neuen Kategorie, die man zu einem späteren Zeitpunkt hinzufügt, ebenfalls entfernen).''
** Eine Benutzergruppe erstellen, die eine der Standardbenutzergruppen als übergeordnete Gruppe hat, NUR, wenn keine von diesen über die exakten Berechtigungen verfügt, die man benötigt und sich für alle Kategorien wünscht.

Beachten, dass dieses Setup unabhängig vom Setup für die Anzeige ist. Allerdings muss eine Benutzergruppe den entsprechenden Zugriffsebenen zugewiesen werden, damit der Benutzer in dieser Gruppe jene Berechtigungen verwenden kann.

Möchte ein Benutzer eine bestimmte Aktion bei einem Komponenten-Eintrag durchführen (z. B. einen Beitrag bearbeiten), überprüft das System (nachdem es überprüft hat, welcher Gruppe der Benutzer angehört und auf welche er Zugriff hat) die Berechtigung für diese Kombination aus Benutzer, Eintrag und Aktion. Liegt eine Erlaubnis vor, kann der Benutzer fortfahren. Andernfalls ist die Aktion nicht zulässig.

Das restliche Tutorial befasst sich mit der Steuerung, was Benutzer tun können - welche Aktionsberechtigungen sie haben.

==Aktionen, Gruppen und Vererbung==

Andererseits geht es bei der ACL auch darum, Benutzern Berechtigungen zu erteilen, damit diese Aktionen an Objekten durchführen können.

{| class="wikitable"
!style="width:20%;"|
!3.x Serie
|-
!Gruppen und Aktionen
|Aktionen, welche pro Gruppe erlaubt sind, werden durch den Website Administrator festgelegt.
|-
!Umfang von Berechtigungen
|Berechtigungen können auf mehreren Ebenen in der Hierarchie festgelegt werden: Website, Komponente, Kategorie, Objekt.
|-
!Vererbung von Berechtigungen
|Berechtigungen können von übergeordneten Gruppen und übergeordneten Kategorien geerbt werden.
|}

===Wie die Berechtigungen funktionieren===

Es gibt vier mögliche Berechtigungen für Aktionen. Diese sind (kurz skizziert):

* '''Nicht gesetzt''': Fällt standardmäßig auf "Nicht erlaubt" zurück. Aber im Gegensatz zur Berechtigung "Verweigert" kann diese Berechtigung außer Kraft gesetzt werden, wenn eine untergeordnete Gruppe oder eine in der Berechtigungshierarchie untergeordnete Ebene auf "Erlaubt" gesetzt wird. Diese Berechtigung kann nur für globale Berechtigungen der Konfiguration gesetzt werden.
* '''Vererbt''': Erbt den Wert von einer übergeordneten Gruppe oder einer in der Berechtigungshierarchie höheren Ebene. Diese Berechtigung gilt für alle Ebenen mit Ausnahme der obersten Ebene der Konfiguration.
* '''Verweigert''': Verbietet diese Aktion für diese Ebene und Gruppe. '''WICHTIG:''' Dadurch wird diese Aktion auch für alle untergeordneten Gruppen und alle untergeordneten Ebenen in der Berechtigungshierarchie verboten. Wird "Erlaubt" in einer untergeordneten Gruppe oder einer tieferen Ebene gesetzt, hat das keinen Effekt. Die Aktion wird immer für alle Mitglieder einer untergeordneten Gruppe und für alle untergeordneten Ebenen in der Berechtigungshierarchie abgelehnt.
* '''Erlaubt ''': Genehmigt diese Aktion für diese Ebene und Gruppe und für tiefere Ebenen und Untergruppen. Dies hat keine Auswirkungen, wenn eine höhere Gruppe oder Ebene auf "Verweigert" oder "Erlaubt" eingestellt ist. Wenn eine höhere Gruppe oder ein höheres Ebene auf "Verweigert" gesetzt ist, wird diese Berechtigung immer abgelehnt. Wenn eine höhere Gruppe oder Ebene auf Erlaubt eingestellt ist, ist diese Berechtigung bereits erlaubt.

===Hierarchie der Berechtigungsebenen===

Berechtigungen für Aktionen können in Version 2.5+ auf bis zu vier Ebenen festgelegt werden, wie folgt:
# '''Konfiguration''': legt die Standardberechtigungen für jede Aktion und Gruppe fest.
# '''Komponenten-Optionen-> Berechtigungen''': kann die Standardberechtigungen für diese Komponente überschreiben (z. B. Beiträge, Menüs, Benutzer, Banner usw.).
# '''Kategorie''': kann die Standardberechtigungen für Objekte in einer oder mehreren Kategorien überschreiben. Gilt für alle Komponenten mit Kategorien, einschließlich Beiträge, Banner, Kontakte, Newsfeeds und Weblinks.
# '''Beitrag''': kann die Berechtigungen für einen bestimmten Artikel überschreiben. Diese Ebene gilt nur für Beiträge. Alle anderen Komponenten erlauben nur die ersten drei Ebenen.

====Konfiguration====
Diese erreicht man über System → Konfiguration → Berechtigungen. Die nun sichtbare Maske dient dazu, die Berechtigungen auf der obersten Ebene für jede Gruppe und jede Aktion festzulegen, wie auch in der folgenden Abbildung gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Die möglichen Werte sind Vererbt, Erlaubt oder Verweigert. Die Spalte 'Errechnete Einstellung' zeigt die aktuelle Einstellung an. Diese ist entweder Nicht erlaubt (Standard), Erlaubt oder Nicht erlaubt.

Man kann immer nur an einer Gruppe gleichzeitig arbeiten, indem man den Reiter für ebendiese Gruppe anklickt. Die Berechtigungen kann man über die Dropdownlisten unter Neue Einstellung wählen ändern.

Beachten Sie, dass die Spalte "Errechnete Einstellung" erst aktualisiert wird, wenn Sie auf die Schaltfläche "Speichern" in der Werkzeugleiste klicken.

Um zu überprüfen, ob die Einstellungen Ihren Wünschen entsprechen, klicken Sie auf die Schaltfläche Speichern und überprüfen anschließend die Spalte Errechnete Einstellung.

====Komponenten-Optionen->Berechtigungen====
Auf diese wird für jede Komponente durch Klicken auf das Symbol "Optionen" in der Werkzeugleiste zugegriffen. Dieser Bildschirm ist ähnlich wie der Bildschirm "Globale Konfiguration" oben links. Wenn Sie beispielsweise im Menü-Manager auf das Symbol in der Werkzeugleiste Optionen klicken, werden die folgenden Menüs angezeigt.
[[Image:Screenshot_menu_acl_J3_tutorial-en.jpg]]

Der Zugriff auf Optionen ist nur für Mitglieder von Gruppen möglich, die die Berechtigung für die Aktion Konfiguration in für jede Komponente haben. Im obigen Beispiel hat die Gruppe Administrator die Berechtigung Erlaubt für die Option Konfigurieren, so dass Mitglieder dieser Gruppe auf diesen Bildschirm zugreifen können.

===Kategorie===
Auf die Kategorieberechtigungen wird im Category Manager zugegriffen: Bildschirm Kategorie bearbeiten, in einer Registerkarte oben auf dem Bildschirm. Dieser Bildschirm hat fünf Berechtigungen, wie folgt:

[[Image:Screenshot_category_acl_j3_tutorial-en.png]]

In diesen Bildern bearbeiten Sie die Berechtigungen für jeweils eine Benutzergruppe. Im obigen Beispiel bearbeiten Sie die Berechtigungen für die Gruppe Administrator.

Achten Sie darauf, dass die Aktionen "Konfigurieren und Zugriffssteuerung" nicht auf der Kategorieebene angewendet werden, so dass diese Aktionen nicht enthalten sind.

Beachten Sie auch, dass Kategorien in einer Hierarchie angeordnet werden können. Wenn ja, dann werden Aktionsberechtigungen in einer übergeordneten Kategorie automatisch an eine untergeordnete Kategorie vererbt. Wenn Sie beispielsweise eine Kategoriehierarchie von Tieren → Haustiere → Hunde hätten, dann würde die vollständige Berechtigungshierarchie für einen Artikel in der Kategorie Hunde wie folgt aussehen:
* Globale Konfiguration
* Artikel-Manager → Optionen → Genehmigung → Erlaubnis
* Tierkategorie
* Kategorie Haustiere
* Kategorie Hunde
* spezifischer Artikel

====Beitrag====
Berechtigungen für einzelne Beiträge findet man im "Beitrag" unter dem Tab-Reiter "Berechigungen". Dieser Bildschirm hat drei Aktionen, wie unten gezeigt.

[[Image:j3x_acl_tutorial_article_manager_article_permissions-en.png]]

Auch hier bearbeiten Sie jede Gruppe für sich. Um auf die Berechtigungen zuzugreifen wechseln Sie im Artikel auf den Reiter "Berechtigungen" im oberen Reiter. Über das Drop Down Menü wählen Sie die neue Berechtigung im Anschluss speichern Sie den Beitrag ab.

Beachten Sie, dass die Aktionen Configure, Access Component und Create auf Artikelebene nicht gelten, so dass diese Aktionen nicht berücksichtigt werden. Die Berechtigung zum Anlegen eines Artikels wird auf einer der höheren Ebenen der Hierarchie festgelegt.

===Zugriffsebenen===

Die Zugriffsebenen der 3.x-Serie sind einfach und flexibel. Der folgende Bildschirm zeigt die spezielle Zugriffsebene.
[[Image:j3x_acl_tutorial_viewing_levels-en.png|center]]
Aktivieren Sie einfach das Kontrollkästchen für jede Gruppe, die Sie in diesem Level aufnehmen wollen. Die spezielle Zugriffsebene umfasst die Gruppen Manager, Autor und Superuser. Es beinhaltet auch untergeordnete Gruppen dieser Gruppen. Die Gruppe Administrator ist also enthalten, da es sich um eine Untergruppe der Gruppe Manager handelt. Die Gruppen Editor, Publisher und Shop Suppliers sind enthalten, da es sich um Untergruppen des Autors handelt.

Jedem Objekt im Frontend ist eine Zugriffsebene zugeordnet. Wenn die Ebene öffentlich ist, kann jeder auf dieses Objekt zugreifen. Andernfalls dürfen nur Mitglieder von Gruppen, die dieser Zugriffsebene zugeordnet sind, auf dieses Objekt zugreifen.

Die Zugriffsebenen sind den Menüpunkten und den Modulen zugeordnet. Jede kann nur einer Zugriffsebene zugeordnet werden.

Der folgende Bildschirm zeigt beispielsweise den Bildschirm Menüpunkt bearbeiten mit der Liste der verfügbaren Zugriffsebenen....

[[Image:j3x_acl_tutorial_edit_menu_item_level_dropdown-en.png|center]]

==Standard-ACL-Setup==

Wenn Joomla! installiert ist, werden diese auf die ursprünglichen Standardwerte gesetzt. Wir werden diese Grundeinstellungen besprechen, um die Arbeitsweise der ACL zu verstehen.

===Standardgruppen===

Mit der Version 3.x können Sie Ihre individuellen Gruppen definieren. Wenn Sie die Version 3.x installieren, enthält sie eine Reihe von Standardgruppen, die im Folgenden dargestellt werden, sind die grundlegenden Standardbenutzergruppen. (Zusätzliche Standardbenutzergruppen werden mit Beispieldaten installiert)

[[Image:Screenshot_usergroupsl_acl_J3_tutorial-en.png|center]]

Die Pfeile zeigen die untergeordneten Elternbeziehungen an. Wie vorstehend besprochen, wird diese Berechtigung, wenn Sie eine Berechtigung für eine übergeordnete Gruppe festlegen, automatisch an alle Untergruppen vererbt. Die vererbten und zulässigen Berechtigungen können für eine Untergruppe überschrieben werden. Die Berechtigung Verweigert kann nicht überschrieben werden und verweigert immer eine Aktion für alle Untergruppen.

===Konfiguration===

Joomla! Version 3.x wird mit den gleichen bekannten Backend-Rechten wie die Version 1.5 (EOL) installiert. Mit der Version 3.x können Sie diese jedoch leicht an die Bedürfnisse Ihrer Website anpassen.

Wie bereits besprochen, werden die Berechtigungen für jede Aktion von der obigen Ebene in der Berechtigungshierarchie und von der übergeordneten Gruppe einer Gruppe übernommen. Also, wie funktioniert das? Die oberste Ebene dafür ist der gesamte Standort. Dies wird in der Site->Globale Konfiguration->Berechtigungen eingerichtet, wie unten gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Das erste, was man bemerken sollte, sind die zehn Aktionen: Standortlogin, Admin-Login, Offline-Zugriff, Superuser, Access Administration Interface, Erstellen, Löschen, Bearbeiten, Status bearbeiten und Eigenes bearbeiten. Dies sind die Aktionen, die ein Benutzer an einem Objekt in Joomla durchführen kann. Die spezifische Bedeutung jeder Aktion hängt vom Kontext ab. Für das Bild Globale Konfiguration sind sie wie folgt definiert:

Site Login : Login to the front end of the site

;Admin Login : Melden Sie sich am Backend der Website an.

Offline-Zugriff: Melden Sie sich am Frontend der Website an, wenn die Website offline ist (wenn die globale Konfigurationseinstellung "Site Offline" auf Ja gesetzt ist).

Superuser: Gewährt dem Benutzer den Status "Superuser". Benutzer mit dieser Berechtigung dürfen alles auf der Website machen. Nur Benutzer mit dieser Berechtigung können die Einstellungen der globalen Konfiguration ändern. Diese Berechtigungen können nicht eingeschränkt werden. Es ist wichtig zu verstehen, dass, wenn ein Benutzer Mitglied einer Super Admin-Gruppe ist, alle anderen Berechtigungen, die diesem Benutzer zugewiesen sind, irrelevant sind. Der Benutzer kann jede Aktion auf der Website durchführen. Es können jedoch weiterhin Zugriffsebenen zugewiesen werden, um zu steuern, was diese Gruppe auf der Website sieht. (Natürlich kann ein Super-Admin-Benutzer die Zugriffsebenen ändern, wenn er möchte, so dass die Zugriffsebenen nicht vollständig einschränken, was ein Super-Admin-Benutzer sehen kann.)

Zugangskomponente: Öffnen Sie die Bildschirme der Komponentenverwaltung (Benutzerverwaltung, Menüverwaltung, Artikelverwaltung usw.).

;Create : Create new objects (for example, users, menu items, articles, weblinks, and so on)

;Löschen : Löschen eines existienden Objekts

;Ändern : Ändern eines existierenden Objektes

;Ändern eines Objekt Status (Veröffentlicht, nicht Veröffentlicht, Archiviert und Gelöscht)

Eigene Objekte bearbeiten: Bearbeiten Sie Objekte, die Sie erstellt haben.

Each Group for the site has its own slider which is opened by clicking on the group name. In this case (with the sample data installed), we have the standard 7 groups that we had in version 1.5 plus two additional groups called "Shop Suppliers" and "Customer Group". Notice that our groups are set up with the same permissions as they had in version 1.5. Keep in mind that we can change any of these permissions to make the security work the way we want. Let's go through this to see how it works.

* '''Public''' has everything set to "Not set", as shown below.{{-}}[[Image:Screenshot_global_acl_public_J3_tutorial-en.png]]
**This can be a bit confusing. Basically, "Not Set" is the same as "Inherited". Because Public is our top-level group, and because Global Configuration is the top level of the component hierarchy, there is nothing to inherit from. So "Not Set" is used instead of "Inherit".
**The default in this case is for no permissions. So, as you would expect, the Public group has no special permissions. Also, it is important to note that, since nothing is set to Denied, all of these permissions may be overridden by child groups or by lower levels in the permission hierarchy.

* '''Guest''' is a 'child' group of the Public group has everything set to 'Inherited' {{-}}[[Image:Screenshot_global_acl_guest_J3_tutorial-de.png]]
** This is the default 'Guest User Group' in the User Manager options and the Group that (non logged in) visitors to your site are placed in.

* '''Manager''' is a "child" group of the Public group. It has Allowed permissions for everything except Access Component and Super Admin. So a member of this group can do everything in the front and back end of the site except change Global Permissions and Component Options. {{-}}[[Image:Screenshot_global_acl_manager_J3_tutorial-en.png]]

* '''Administrator''' group members inherit all of the Manager permissions and also have Allowed for Access Component. So members of this group by default can access the Options screens for each component. {{-}}[[Image:Screenshot_global_acl_administrator_J3_tutorial-en.png]]

* '''Registered''' is the same a Public except for the Allow permission for the Site Login action. This means that members of the Registered group can login to the site. Since default permissions are inherited, this means that, unless a child group overrides this permission, all child groups of the Registered group will be able to login as well. {{-}}[[Image:Screenshot_global_acl_registered_J3_tutorial-en.png]]

* '''Author''' is a child of the Registered group and inherits its permissions and also adds Create and Edit Own. Since Author, Editor, and Publisher have no back-end permissions, we will discuss them below, when we discuss front-end permissions.{{-}}[[Image:Screenshot_global_acl_author_J3_tutorial-en.png]]

* '''Editor''' is a child of the Authors group and adds the Edit permission. {{-}}[[Image:Screenshot_global_acl_editor_J3_tutorial-en.png]]

* '''Publisher''' is a child of Editor and adds the Edit State permission.{{-}}[[Image:Screenshot_global_acl_publisher_J3_tutorial-en.png]]

* '''Shop Suppliers''' is an example group that is installed if you install the sample data. It is a child group of Author.

* '''Customer Group''' is an example group that is installed if you install the sample data. It is a child group of Registered.

* '''Super Users''' group has the Allow permission for the Super Admin action. Because of this, members of this group have super user permissions throughout the site. They are the only users who can access and edit values on the Global Configuration screen. Users with permission for the Super Admin action have some special characteristics:
:* If a user has Super Admin permissions, no other permissions for this user matter. The user can perform any action on the site.
:* Only Super Admin users can create, edit, or delete other Super Admin users or groups.

There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.

This provides a lot of flexibility. For example, if you wanted Shop Suppliers to be able to have the ability to login to the back end, you could just change their Admin Login value to "Allowed". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherited (or Denied).

It is also important to understand that the ability to have child groups is completely optional. It allows you to save some time when setting up new groups. However, if you like, you can set up all groups to have Public as the parent and not inherit any permissions from a parent group.

===Komponenten-Optionen & Berechtigungen===

Now, let's continue to see how the default back-end permissions for version 2.5 mimic the permissions for version 1.5. The Super Users group in 2.5 is equivalent to the Super Administrator group in 1.5.

Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 2.5 configuration. Let's see how this is accomplished.

If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:

[[Image:screenshot_acl_tutorial_20110111-09-en.png|center|]]
[[Image:screenshot_acl_tutorial_20110111-10-en.png|center|]]

This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.

First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.

Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.

If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.

In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.

It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.

===Frontend Berechtigungen===

Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions. First, let's look at the permissions for Manager, as shown below.
[[Image:screenshot_acl_tutorial_20110111-11a-en.png|center|frame]]
Manager has allowed permission for all actions except Configure. So members of the Manager group can do everything with Articles except open the Options screen.

Now let's look at Administrator, as shown below.
[[Image:screenshot_acl_tutorial_20110111-12a-en.png|center|frame]]
Administrator has Allowed for Configure, so Administrators can edit this Options screen.

Both groups can create, delete, edit, and change the state of articles.

Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set.

Authors only have Create and Edit Own permissions, as shown below.
[[Image:screenshot_acl_tutorial_20110112-07-en.png|center|frame]]
This means that Authors can create articles and can edit articles they have created. They may not delete articles, change the published state of articles, or edit articles created by others.

Editors have the same permissions as Authors with the addition of permission for the Edit action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-08-en.png|center|frame]]
So Editors can edit articles written by anyone.

Publishers can do everything Editors can do plus they have permission for the Edit State action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-09-en.png|center|frame]]
So Publishers can change the published state of an article. The possible states include Published, Unpublished, Archived, and Trashed.

All of these groups have Inherit permission for Configure and Access Component. Remember that Author is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Configure and Access Component, and since Author's permission for these actions is "Inherited", then Author does not have these permissions either. This same permission is passed from Author to Editor and from Editor to Publisher. So, by default, none of these groups are allowed to work with articles in the back end.

It is important to remember that these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.

Beachte auch das in den ursprünglichen Standardwerten keine Berechtigungen auf Verweigert eingestellt sind. Dies ermöglicht in allen Berechtigungsebenen die jeweilige Berechtigung auf Erlaubt einzustellen. Bedenke, wenn eine Aktion auf Verweigert eingestellt ist, das diese Aktion auch in allen untergeordneten Ebenen in der Berechtigungshierarchie verweigert wird. Zum Beispiel, wenn die Seitenameldung für Registered auf Verweigert (anstatt auf Erlaubt) eingestellt wird, kann man Publishers diese Aktion per Berechtigungeinstellung nicht erteilen.

=== Beitrags-Manager & Aktions-Diagramm ===

The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.

[[Image:screenshot_acl_tutorial_20110111-16-en.png|center|]]

* '''Configure''' allows you to view and change the Options for the component.
* '''Access Component''' allows you to navigate to the Article Manager. Without this permission, no other actions are possible.
* '''Create''' allows you to add new articles.
* '''Delete''' allows you to delete trashed articles. Note that the Delete icon only shows in the toolbar when you have the "Select State" filter set to "Trash".
* '''Edit''' allows you to edit existing articles.
* '''Edit State''' allows to you Publish, Unpublish, Archive, or Trash articles.
* '''Edit Own''' is the same as Edit except that it only applies to articles written by you.

==Allowing Guest-Only Access to Menu Items and Modules==

Version 1.6 introduced the ability to create a View Access Level that is only for guests of the site (meaning a user who is not logged in). The example below shows how you can set up this new feature.
''(N.B. Steps 1 to 3 are not needed for Joomla! 3.x as they exist in the default install)''

#Create a new user group called Guest. Make it a child of the Public group as shown below. [[Image:screenshot_acl_tutorial_20110112-01-en.png|center|frame]]
# Create a new access level called Guest and grant only the Guest group access to this level, as shown below.[[Image:screenshot_acl_tutorial_20110112-02-en.png|center|frame]]
# Navigate to User Manager→Options→Component and change the Guest User Group from the default value of "Public" to "Guest", as shown below.
[[Image:screenshot_acl_tutorial_20110112-04-en.png|center|frame]]
Now, if we assign a menu item, module, or other object to the Guest access level, only non-logged in users will have access. For example, if we create a new menu item with access level of Guest, as shown below,
[[Image:screenshot_acl_tutorial_20110112-05-en.png|center|frame]]
this menu item will only be visible to non-logged-in visitors to the site.

If required other user groups like Author can be granted access in the Guest access level, this would allow Authors to view articles in the front end for editing.

'''N.B. Login/logout in front end (''for changing data in session'') to see the change.'''

==Berechtigungen und Gruppenebenen gemeinsam nutzen==

As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.

This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:

* both groups can create new articles only in the History Assignments category.

* only History Teachers (not Assistant History Teachers) can Publish or otherwise have Edit State permission.

This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.

[[Image:Acl example diagram1 20091018-en.png|center|]]

In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.

To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.

Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.

[[Image:Acl example diagram2 20091018-en.png|center|]]

This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.

Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.

==ACL Aktion Berechtigungs-Beispiele==

===Backend Beitrag Administrator===

'''Problem:'''

We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.

'''Lösung:'''

# Create a new group called Article Administrator and make its parent group Public, as shown below.[[Image:screenshot_acl_tutorial_20110112-10-de.png|center|frame]] Because its parent group is Public, it won't have any permissions by default.
# In Users → Access Levels, edit the Special Access level to add the new group. That way they can get access to the back end menu items and modules (This assumes that the modules for the admin menu and quickicons have the Special Access level assigned to them, which is the default.) [[Image:screenshot_acl_tutorial_20110112-11-de.png|center|frame]] By default, the back-end menu items and modules are set to Special access, so if you forget to add the new group to the Special access level, you won't see any modules or menu items when you log in as a user of the new group.
# In Site → Global Configuration → Permissions, click on the Article Administrator group and change the permissions to Allowed for the following actions: Admin Login, Create, Delete, Edit, Edit State, and Edit Own. The screen below shows what will show before you press Save. [[Image:screenshot_acl_tutorial_20110112-12-de.png|center|frame]]After you save, the Calculated Permissions should show as shown below.[[Image:screenshot_acl_tutorial_20110112-13-de.png|center|frame]]Note that the permission for the Access Component is Inherited, which translates to Not Allowed. This is important. This means that this group will only be able to access components if we give the group "Allowed" permission for Access Component. So we only have to change the one component we want to give them access to and don't have to change any settings for the components where we don't want them to have access. If we had a case where we wanted to give a group access to everything except for one component, we could set the default to Allowed and then set the one component to Denied. Also note that we did not give the group Site Login permission, so users in this group will not be able to log into the front end. (If we wanted to allow that, we would just change the permission to Allowed for Site Login.)
# In Article Manager → Options → Permissions, change permissions to Allowed for this group for the Access Component action, as shown below.[[Image:screenshot_acl_tutorial_20110112-14-de.png|center|frame]]All of the other desired permissions are inherited.

That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end. For example, the screen below shows what a user in the Article Manager will see when they login to the back end.[[Image:screenshot_acl_tutorial_20110112-15-de.png|center|frame]]

==ACL Ansicht Zugriffsebenen-Beispiele==

A basic concept of using Access Levels is that all items with the same Access will be viewable by the same group of users. In other words, if two items have the same Access, you can't have one viewable by one user and not viewable by another user. On the other hand, it is easy to have one Group view any number of items with different Access levels.

Similarly, each Group has exactly the same combination of Access levels, but one User can be a member of more than one group. Depending on the situation, you may want to have users only in one Group or you may need to have a User in more than one Group.

This means that we may need to group our items so that items so that all items in a group have the same level of sensitivity. Here are some examples.

===Hierarchisches Beispiel===
In this example, Access levels are hierarchical, for example, like government security clearance codes. Say for example we have the following sets of classified documents: Classified, Secret, and Top Secret. Users have corresponding clearence codes. Users with Classified clearance can only see Classified documents and cannot see Secret or Top Secret. Users with Secret clearance can see Classified and Secret documents but not Top Secret. Users with Top Secret can see all documents.

In this case, you would create three Access levels: Classified, Secret, and Top Secret and the same three Groups. Users would only be members of one group, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| C1, C2, C3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Classified
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| S1, S2, S3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| TS1, TS2, TS3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Top Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret, Top Secret

|}

In this case, all users are in exactly one group, but some groups have access to more than one Access Level of items. In other words, we have a one-to-one relationship between users and groups, but a one-to-many relationship between Groups and Access Levels.

===Teamsicherheit Beispiel===

Another possible use case is a set of non-hierarchical teams. Let's say we have three teams, T1, T2, and T3. Some users are only on one team, but others might be on two or more teams. In this case, we could set up our Access Levels and Groups by team. Documents for each team have the access level for that team, and the Group for the team has only the one access level. When a User is on more than one team, they get added to the group for each team, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Beschreibung
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 1 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 2 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 3 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1, 2 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1,T2, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2, T3

|}

===Hybrid Example===

In a real-world situation, you might have a combination of these two arrangements. Say for example we have Managers and Staff. Staff can only see Staff documents and Managers can see Manager and Staff documents. Both types of users can be assigned to teams as well, in which case they can see all of the documents for that team. In addition, say that Managers can access some, but not all, team documents. Staff can only access team documents if they are members of that team.

In this example, we could set up the following Access Levels:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Access Level
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Description
| style="border:0.0007in solid #000000;padding:0.0382in;"| Groups

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team manager documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team staff documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team1 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1, Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team2 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2, Manager

|}

Then, users could be assigned to groups as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| User Type
| style="border:0.0007in solid #000000;padding:0.0382in;"| Group

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1, Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1, Team2

|}

<noinclude>
[[Category:Joomla! 1.6]]
[[Category:Joomla! 2.5]]
[[Category:Joomla! 3.x/de]]
[[Category:Tutorials/de]]
[[Category:Access Control/de]]
[[Category:Access Management]]
</noinclude>

Translations:J3.x:Access Control List Tutorial/187/de

2019-12-26T19:06:08Z

Sieger66:

J3.x:Access Control List Tutorial/de

2019-12-26T19:05:59Z

Sieger66:

<noinclude><languages /></noinclude>
{{Joomla version|version=3.x|comment=Serie}}
{{-}}
{{:J3.1:Access_Control_List/en}}

==Separate ACL für Anzeige und Aktionen==

Das Joomla ACL-System besteht genau genommen aus zwei völlig getrennten Systemen. Das eine System steuert, was Benutzer auf der Website "sehen" können. Das andere steuert, was Benutzer "tun" können (welche Aktionen ein Benutzer durchführen kann). Die ACL wird für jedes dieser Systeme anders eingerichtet.

===Steuern, was Benutzer sehen können===

Das Setup zum Steuern, was Benutzer sehen können, sieht wie folgt aus:
*Eine Reihe von Zugriffsebenen gemäß den Kategorien und/oder der Kombination von Kategorien erstellen, die nur angemeldete Benutzer sehen sollen. Anmerkung: Zu diesem Zeitpunkt werden noch keine Benutzergruppen den neuen Zugriffsebenen zugewiesen.

*Für jede Zugriffsebene eine Benutzergruppe erstellen, die 'Registriert' als übergeordnete Gruppe hat. Indem man für Benutzergruppen und Zugriffsebenen die gleichen Namen verwendet, kann man Verwirrungen zu einem späteren Zeitpunkt vorbeugen.

*Die neuen Zugriffsebenen bearbeiten und jeder die (neue) Benutzergruppe zuweisen. Wahrscheinlich möchten man auch die 'Super Benutzer' Gruppe (und/oder die anderen Standard-Benutzergruppen mit Ausnahme der Benutzergruppe 'Gast') den neuen Zugriffsebenen zuweisen.

*Jedem anzuzeigenden Eintrag eine Zugriffsebene zuweisen. Einträge sind sowohl inhaltliche Einträge (Beiträge, Kontakte, usw.), Menüeinträge als auch Module.

Immer dann, wenn ein Benutzer im Begriff ist, einen Eintrag auf einer Joomla-Seite anzeigen zu lassen, prüft das Programm, ob dieser Benutzer auch Zugriff auf den Eintrag hat. Das geschieht folgendermaßen:
# Zunächst wird eine Liste aller Zugriffsebenen erstellt, auf die der Benutzer zugreifen kann, basierend auf allen Gruppen, denen der Benutzer angehört. Sofern eine Gruppe eine übergeordnete Gruppe besitzt, sind die Zugriffsebenen für die übergeordnete Gruppe ebenfalls in der Liste enthalten.
# Danach wird überprüft, ob die Zugriffsebene für den Eintrag (Beitrag, Modul, Menüeintrag, usw.) in dieser Liste enthalten ist. Wenn dem so ist, wird der Eintrag dem Benutzer angezeigt. Falls der Benutzer die benötigten Zugriffsrechte besitzt, wird ihm der Zugriff verweigert.

Beachten, dass Zugriffsebenen für jede Gruppe separat festgelegt und nicht von der übergeordneten Gruppe einer Gruppe vererbt werden.

===Steuern, was Benutzer tun können===

Das System, das steuert, was Benutzer in einer Benutzergruppe tun können - welche Aktionen sie bei einem bestimmten Eintrag ausführen können - wird über den Tab 'Berechtigungen' in der Konfiguration und den Tab 'Berechtigungen' in den Optionen jeder einzelnen Komponente eingerichtet. Berechtigungen können auch auf Kategorienebene (bei Kernkomponenten) und auf Beitragsebene (bei Beiträgen) gesetzt werden.

* Wenn angemeldete Benutzer in bestimmten Kategorien Erstellen, Löschen, Status bearbeiten oder Eigene Inhalte bearbeiten dürfen, dann:
** Eine Benutzergruppe erstellen und als übergeordnete Gruppe eine der Benutzergruppen angeben, die Zugriff auf die Kategorie (oder Kategorien) haben, die diese neue Benutzergruppe ändern soll.
**Der neuen Benutzergruppe den entsprechenden Zugriffsebenen zuweisen. Dann die erforderlichen Berechtigungen für die neue Benutzergruppe entweder global oder pro Kategorie/Beitrag ändern.
*** Beim Erstellen einer Benutzergruppe ist es ratsam, eine übergeordnete Gruppe zu wählen, die über weniger Berechtigungen verfügt, als für die neue Gruppe erforderlich. Denn es ist einfacher, die Berechtigungen für jede Komponente/Kategorie/Beitrag zu erweitern, für die zusätzliche Berechtigungen nötig sind, als Berechtigungen aus den anderen Komponenten/Kategorien/Beiträgen zu entfernen.
****''(Beispiel: Es gibt 10 Kategorien, man möchte aber nur für eine Erstellen-Berechtigungen. Würde man für diese Gruppe die Berechtigungen global auf Erstellen erlaubt setzen, müsste man für diese Kategorien die Erstellen-Berechtigung entfernen. Und man müsste für diese Gruppe die Erstellen-Berechtigung bei jeder neuen Kategorie, die man zu einem späteren Zeitpunkt hinzufügt, ebenfalls entfernen).''
** Eine Benutzergruppe erstellen, die eine der Standardbenutzergruppen als übergeordnete Gruppe hat, NUR, wenn keine von diesen über die exakten Berechtigungen verfügt, die man benötigt und sich für alle Kategorien wünscht.

Beachten, dass dieses Setup unabhängig vom Setup für die Anzeige ist. Allerdings muss eine Benutzergruppe den entsprechenden Zugriffsebenen zugewiesen werden, damit der Benutzer in dieser Gruppe jene Berechtigungen verwenden kann.

Möchte ein Benutzer eine bestimmte Aktion bei einem Komponenten-Eintrag durchführen (z. B. einen Beitrag bearbeiten), überprüft das System (nachdem es überprüft hat, welcher Gruppe der Benutzer angehört und auf welche er Zugriff hat) die Berechtigung für diese Kombination aus Benutzer, Eintrag und Aktion. Liegt eine Erlaubnis vor, kann der Benutzer fortfahren. Andernfalls ist die Aktion nicht zulässig.

Das restliche Tutorial befasst sich mit der Steuerung, was Benutzer tun können - welche Aktionsberechtigungen sie haben.

==Aktionen, Gruppen und Vererbung==

Andererseits geht es bei der ACL auch darum, Benutzern Berechtigungen zu erteilen, damit diese Aktionen an Objekten durchführen können.

{| class="wikitable"
!style="width:20%;"|
!3.x Serie
|-
!Gruppen und Aktionen
|Aktionen, welche pro Gruppe erlaubt sind, werden durch den Website Administrator festgelegt.
|-
!Umfang von Berechtigungen
|Berechtigungen können auf mehreren Ebenen in der Hierarchie festgelegt werden: Website, Komponente, Kategorie, Objekt.
|-
!Vererbung von Berechtigungen
|Berechtigungen können von übergeordneten Gruppen und übergeordneten Kategorien geerbt werden.
|}

===Wie die Berechtigungen funktionieren===

Es gibt vier mögliche Berechtigungen für Aktionen. Diese sind (kurz skizziert):

* '''Nicht gesetzt''': Fällt standardmäßig auf "Nicht erlaubt" zurück. Aber im Gegensatz zur Berechtigung "Verweigert" kann diese Berechtigung außer Kraft gesetzt werden, wenn eine untergeordnete Gruppe oder eine in der Berechtigungshierarchie untergeordnete Ebene auf "Erlaubt" gesetzt wird. Diese Berechtigung kann nur für globale Berechtigungen der Konfiguration gesetzt werden.
* '''Vererbt''': Erbt den Wert von einer übergeordneten Gruppe oder einer in der Berechtigungshierarchie höheren Ebene. Diese Berechtigung gilt für alle Ebenen mit Ausnahme der obersten Ebene der Konfiguration.
* '''Verweigert''': Verbietet diese Aktion für diese Ebene und Gruppe. '''WICHTIG:''' Dadurch wird diese Aktion auch für alle untergeordneten Gruppen und alle untergeordneten Ebenen in der Berechtigungshierarchie verboten. Wird "Erlaubt" in einer untergeordneten Gruppe oder einer tieferen Ebene gesetzt, hat das keinen Effekt. Die Aktion wird immer für alle Mitglieder einer untergeordneten Gruppe und für alle untergeordneten Ebenen in der Berechtigungshierarchie abgelehnt.
* '''Erlaubt ''': Genehmigt diese Aktion für diese Ebene und Gruppe und für tiefere Ebenen und Untergruppen. Dies hat keine Auswirkungen, wenn eine höhere Gruppe oder Ebene auf "Verweigert" oder "Erlaubt" eingestellt ist. Wenn eine höhere Gruppe oder ein höheres Ebene auf "Verweigert" gesetzt ist, wird diese Berechtigung immer abgelehnt. Wenn eine höhere Gruppe oder Ebene auf Erlaubt eingestellt ist, ist diese Berechtigung bereits erlaubt.

===Hierarchie der Berechtigungsebenen===

Berechtigungen für Aktionen können in Version 2.5+ auf bis zu vier Ebenen festgelegt werden, wie folgt:
# '''Konfiguration''': legt die Standardberechtigungen für jede Aktion und Gruppe fest.
# '''Komponenten-Optionen-> Berechtigungen''': kann die Standardberechtigungen für diese Komponente überschreiben (z. B. Beiträge, Menüs, Benutzer, Banner usw.).
# '''Kategorie''': kann die Standardberechtigungen für Objekte in einer oder mehreren Kategorien überschreiben. Gilt für alle Komponenten mit Kategorien, einschließlich Beiträge, Banner, Kontakte, Newsfeeds und Weblinks.
# '''Beitrag''': kann die Berechtigungen für einen bestimmten Artikel überschreiben. Diese Ebene gilt nur für Beiträge. Alle anderen Komponenten erlauben nur die ersten drei Ebenen.

====Konfiguration====
Diese erreicht man über System → Konfiguration → Berechtigungen. Die nun sichtbare Maske dient dazu, die Berechtigungen auf der obersten Ebene für jede Gruppe und jede Aktion festzulegen, wie auch in der folgenden Abbildung gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Die möglichen Werte sind Vererbt, Erlaubt oder Verweigert. Die Spalte 'Errechnete Einstellung' zeigt die aktuelle Einstellung an. Diese ist entweder Nicht erlaubt (Standard), Erlaubt oder Nicht erlaubt.

Man kann immer nur an einer Gruppe gleichzeitig arbeiten, indem man den Reiter für ebendiese Gruppe anklickt. Die Berechtigungen kann man über die Dropdownlisten unter Neue Einstellung wählen ändern.

Beachten Sie, dass die Spalte "Errechnete Einstellung" erst aktualisiert wird, wenn Sie auf die Schaltfläche "Speichern" in der Werkzeugleiste klicken.

Um zu überprüfen, ob die Einstellungen Ihren Wünschen entsprechen, klicken Sie auf die Schaltfläche Speichern und überprüfen anschließend die Spalte Errechnete Einstellung.

====Komponenten-Optionen->Berechtigungen====
Auf diese wird für jede Komponente durch Klicken auf das Symbol "Optionen" in der Werkzeugleiste zugegriffen. Dieser Bildschirm ist ähnlich wie der Bildschirm "Globale Konfiguration" oben links. Wenn Sie beispielsweise im Menü-Manager auf das Symbol in der Werkzeugleiste Optionen klicken, werden die folgenden Menüs angezeigt.
[[Image:Screenshot_menu_acl_J3_tutorial-en.jpg]]

Der Zugriff auf Optionen ist nur für Mitglieder von Gruppen möglich, die die Berechtigung für die Aktion Konfiguration in für jede Komponente haben. Im obigen Beispiel hat die Gruppe Administrator die Berechtigung Erlaubt für die Option Konfigurieren, so dass Mitglieder dieser Gruppe auf diesen Bildschirm zugreifen können.

===Kategorie===
Auf die Kategorieberechtigungen wird im Category Manager zugegriffen: Bildschirm Kategorie bearbeiten, in einer Registerkarte oben auf dem Bildschirm. Dieser Bildschirm hat fünf Berechtigungen, wie folgt:

[[Image:Screenshot_category_acl_j3_tutorial-en.png]]

In diesen Bildern bearbeiten Sie die Berechtigungen für jeweils eine Benutzergruppe. Im obigen Beispiel bearbeiten Sie die Berechtigungen für die Gruppe Administrator.

Achten Sie darauf, dass die Aktionen "Konfigurieren und Zugriffssteuerung" nicht auf der Kategorieebene angewendet werden, so dass diese Aktionen nicht enthalten sind.

Beachten Sie auch, dass Kategorien in einer Hierarchie angeordnet werden können. Wenn ja, dann werden Aktionsberechtigungen in einer übergeordneten Kategorie automatisch an eine untergeordnete Kategorie vererbt. Wenn Sie beispielsweise eine Kategoriehierarchie von Tieren → Haustiere → Hunde hätten, dann würde die vollständige Berechtigungshierarchie für einen Artikel in der Kategorie Hunde wie folgt aussehen:
* Globale Konfiguration
* Artikel-Manager → Optionen → Genehmigung → Erlaubnis
* Tierkategorie
* Kategorie Haustiere
* Kategorie Hunde
* spezifischer Artikel

====Beitrag====
Berechtigungen für einzelne Beiträge findet man im "Beitrag" unter dem Tab-Reiter "Berechigungen". Dieser Bildschirm hat drei Aktionen, wie unten gezeigt.

[[Image:j3x_acl_tutorial_article_manager_article_permissions-en.png]]

Auch hier bearbeiten Sie jede Gruppe für sich. Um auf die Berechtigungen zuzugreifen wechseln Sie im Artikel auf den Reiter "Berechtigungen" im oberen Reiter. Über das Drop Down Menü wählen Sie die neue Berechtigung im Anschluss speichern Sie den Beitrag ab.

Beachten Sie, dass die Aktionen Configure, Access Component und Create auf Artikelebene nicht gelten, so dass diese Aktionen nicht berücksichtigt werden. Die Berechtigung zum Anlegen eines Artikels wird auf einer der höheren Ebenen der Hierarchie festgelegt.

===Zugriffsebenen===

Die Zugriffsebenen der 3.x-Serie sind einfach und flexibel. Der folgende Bildschirm zeigt die spezielle Zugriffsebene.
[[Image:j3x_acl_tutorial_viewing_levels-en.png|center]]
Aktivieren Sie einfach das Kontrollkästchen für jede Gruppe, die Sie in diesem Level aufnehmen wollen. Die spezielle Zugriffsebene umfasst die Gruppen Manager, Autor und Superuser. Es beinhaltet auch untergeordnete Gruppen dieser Gruppen. Die Gruppe Administrator ist also enthalten, da es sich um eine Untergruppe der Gruppe Manager handelt. Die Gruppen Editor, Publisher und Shop Suppliers sind enthalten, da es sich um Untergruppen des Autors handelt.

Jedem Objekt im Frontend ist eine Zugriffsebene zugeordnet. Wenn die Ebene öffentlich ist, kann jeder auf dieses Objekt zugreifen. Andernfalls dürfen nur Mitglieder von Gruppen, die dieser Zugriffsebene zugeordnet sind, auf dieses Objekt zugreifen.

Die Zugriffsebenen sind den Menüpunkten und den Modulen zugeordnet. Jede kann nur einer Zugriffsebene zugeordnet werden.

Der folgende Bildschirm zeigt beispielsweise den Bildschirm Menüpunkt bearbeiten mit der Liste der verfügbaren Zugriffsebenen....

[[Image:j3x_acl_tutorial_edit_menu_item_level_dropdown-en.png|center]]

==Standard-ACL-Setup==

Wenn Joomla! installiert ist, werden diese auf die ursprünglichen Standardwerte gesetzt. Wir werden diese Grundeinstellungen besprechen, um die Arbeitsweise der ACL zu verstehen.

===Standardgruppen===

Mit der Version 3.x können Sie Ihre individuellen Gruppen definieren. Wenn Sie die Version 3.x installieren, enthält sie eine Reihe von Standardgruppen, die im Folgenden dargestellt werden, sind die grundlegenden Standardbenutzergruppen. (Zusätzliche Standardbenutzergruppen werden mit Beispieldaten installiert)

[[Image:Screenshot_usergroupsl_acl_J3_tutorial-en.png|center]]

Die Pfeile zeigen die untergeordneten Elternbeziehungen an. Wie vorstehend besprochen, wird diese Berechtigung, wenn Sie eine Berechtigung für eine übergeordnete Gruppe festlegen, automatisch an alle Untergruppen vererbt. Die vererbten und zulässigen Berechtigungen können für eine Untergruppe überschrieben werden. Die Berechtigung Verweigert kann nicht überschrieben werden und verweigert immer eine Aktion für alle Untergruppen.

===Konfiguration===

Joomla! Version 3.x wird mit den gleichen bekannten Backend-Rechten wie die Version 1.5 (EOL) installiert. Mit der Version 3.x können Sie diese jedoch leicht an die Bedürfnisse Ihrer Website anpassen.

Wie bereits besprochen, werden die Berechtigungen für jede Aktion von der obigen Ebene in der Berechtigungshierarchie und von der übergeordneten Gruppe einer Gruppe übernommen. Also, wie funktioniert das? Die oberste Ebene dafür ist der gesamte Standort. Dies wird in der Site->Globale Konfiguration->Berechtigungen eingerichtet, wie unten gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Das erste, was man bemerken sollte, sind die zehn Aktionen: Standortlogin, Admin-Login, Offline-Zugriff, Superuser, Access Administration Interface, Erstellen, Löschen, Bearbeiten, Status bearbeiten und Eigenes bearbeiten. Dies sind die Aktionen, die ein Benutzer an einem Objekt in Joomla durchführen kann. Die spezifische Bedeutung jeder Aktion hängt vom Kontext ab. Für das Bild Globale Konfiguration sind sie wie folgt definiert:

Site Login : Login to the front end of the site

;Admin Login : Melden Sie sich am Backend der Website an.

Offline-Zugriff: Melden Sie sich am Frontend der Website an, wenn die Website offline ist (wenn die globale Konfigurationseinstellung "Site Offline" auf Ja gesetzt ist).

Superuser: Gewährt dem Benutzer den Status "Superuser". Benutzer mit dieser Berechtigung dürfen alles auf der Website machen. Nur Benutzer mit dieser Berechtigung können die Einstellungen der globalen Konfiguration ändern. Diese Berechtigungen können nicht eingeschränkt werden. Es ist wichtig zu verstehen, dass, wenn ein Benutzer Mitglied einer Super Admin-Gruppe ist, alle anderen Berechtigungen, die diesem Benutzer zugewiesen sind, irrelevant sind. Der Benutzer kann jede Aktion auf der Website durchführen. Es können jedoch weiterhin Zugriffsebenen zugewiesen werden, um zu steuern, was diese Gruppe auf der Website sieht. (Natürlich kann ein Super-Admin-Benutzer die Zugriffsebenen ändern, wenn er möchte, so dass die Zugriffsebenen nicht vollständig einschränken, was ein Super-Admin-Benutzer sehen kann.)

Zugangskomponente: Öffnen Sie die Bildschirme der Komponentenverwaltung (Benutzerverwaltung, Menüverwaltung, Artikelverwaltung usw.).

;Create : Create new objects (for example, users, menu items, articles, weblinks, and so on)

;Löschen : Löschen eines existienden Objekts

;Ändern : Ändern eines existierenden Objektes

;Ändern eines Objekt Status (Veröffentlicht, nicht Veröffentlicht, Archiviert und Gelöscht)

Eigene Objekte bearbeiten: Bearbeiten Sie Objekte, die Sie erstellt haben.

Each Group for the site has its own slider which is opened by clicking on the group name. In this case (with the sample data installed), we have the standard 7 groups that we had in version 1.5 plus two additional groups called "Shop Suppliers" and "Customer Group". Notice that our groups are set up with the same permissions as they had in version 1.5. Keep in mind that we can change any of these permissions to make the security work the way we want. Let's go through this to see how it works.

* '''Public''' has everything set to "Not set", as shown below.{{-}}[[Image:Screenshot_global_acl_public_J3_tutorial-en.png]]
**This can be a bit confusing. Basically, "Not Set" is the same as "Inherited". Because Public is our top-level group, and because Global Configuration is the top level of the component hierarchy, there is nothing to inherit from. So "Not Set" is used instead of "Inherit".
**The default in this case is for no permissions. So, as you would expect, the Public group has no special permissions. Also, it is important to note that, since nothing is set to Denied, all of these permissions may be overridden by child groups or by lower levels in the permission hierarchy.

* '''Guest''' is a 'child' group of the Public group has everything set to 'Inherited' {{-}}[[Image:Screenshot_global_acl_guest_J3_tutorial-de.png]]
** This is the default 'Guest User Group' in the User Manager options and the Group that (non logged in) visitors to your site are placed in.

* '''Manager''' is a "child" group of the Public group. It has Allowed permissions for everything except Access Component and Super Admin. So a member of this group can do everything in the front and back end of the site except change Global Permissions and Component Options. {{-}}[[Image:Screenshot_global_acl_manager_J3_tutorial-en.png]]

* '''Administrator''' group members inherit all of the Manager permissions and also have Allowed for Access Component. So members of this group by default can access the Options screens for each component. {{-}}[[Image:Screenshot_global_acl_administrator_J3_tutorial-en.png]]

* '''Registered''' is the same a Public except for the Allow permission for the Site Login action. This means that members of the Registered group can login to the site. Since default permissions are inherited, this means that, unless a child group overrides this permission, all child groups of the Registered group will be able to login as well. {{-}}[[Image:Screenshot_global_acl_registered_J3_tutorial-en.png]]

* '''Author''' is a child of the Registered group and inherits its permissions and also adds Create and Edit Own. Since Author, Editor, and Publisher have no back-end permissions, we will discuss them below, when we discuss front-end permissions.{{-}}[[Image:Screenshot_global_acl_author_J3_tutorial-en.png]]

* '''Editor''' is a child of the Authors group and adds the Edit permission. {{-}}[[Image:Screenshot_global_acl_editor_J3_tutorial-en.png]]

* '''Publisher''' is a child of Editor and adds the Edit State permission.{{-}}[[Image:Screenshot_global_acl_publisher_J3_tutorial-en.png]]

* '''Shop Suppliers''' is an example group that is installed if you install the sample data. It is a child group of Author.

* '''Customer Group''' is an example group that is installed if you install the sample data. It is a child group of Registered.

* '''Super Users''' group has the Allow permission for the Super Admin action. Because of this, members of this group have super user permissions throughout the site. They are the only users who can access and edit values on the Global Configuration screen. Users with permission for the Super Admin action have some special characteristics:
:* If a user has Super Admin permissions, no other permissions for this user matter. The user can perform any action on the site.
:* Only Super Admin users can create, edit, or delete other Super Admin users or groups.

There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.

This provides a lot of flexibility. For example, if you wanted Shop Suppliers to be able to have the ability to login to the back end, you could just change their Admin Login value to "Allowed". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherited (or Denied).

It is also important to understand that the ability to have child groups is completely optional. It allows you to save some time when setting up new groups. However, if you like, you can set up all groups to have Public as the parent and not inherit any permissions from a parent group.

===Komponenten-Optionen & Berechtigungen===

Now, let's continue to see how the default back-end permissions for version 2.5 mimic the permissions for version 1.5. The Super Users group in 2.5 is equivalent to the Super Administrator group in 1.5.

Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 2.5 configuration. Let's see how this is accomplished.

If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:

[[Image:screenshot_acl_tutorial_20110111-09-en.png|center|]]
[[Image:screenshot_acl_tutorial_20110111-10-en.png|center|]]

This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.

First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.

Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.

If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.

In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.

It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.

===Frontend Berechtigungen===

Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions. First, let's look at the permissions for Manager, as shown below.
[[Image:screenshot_acl_tutorial_20110111-11a-en.png|center|frame]]
Manager has allowed permission for all actions except Configure. So members of the Manager group can do everything with Articles except open the Options screen.

Now let's look at Administrator, as shown below.
[[Image:screenshot_acl_tutorial_20110111-12a-en.png|center|frame]]
Administrator has Allowed for Configure, so Administrators can edit this Options screen.

Both groups can create, delete, edit, and change the state of articles.

Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set.

Authors only have Create and Edit Own permissions, as shown below.
[[Image:screenshot_acl_tutorial_20110112-07-en.png|center|frame]]
This means that Authors can create articles and can edit articles they have created. They may not delete articles, change the published state of articles, or edit articles created by others.

Editors have the same permissions as Authors with the addition of permission for the Edit action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-08-en.png|center|frame]]
So Editors can edit articles written by anyone.

Publishers can do everything Editors can do plus they have permission for the Edit State action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-09-en.png|center|frame]]
So Publishers can change the published state of an article. The possible states include Published, Unpublished, Archived, and Trashed.

All of these groups have Inherit permission for Configure and Access Component. Remember that Author is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Configure and Access Component, and since Author's permission for these actions is "Inherited", then Author does not have these permissions either. This same permission is passed from Author to Editor and from Editor to Publisher. So, by default, none of these groups are allowed to work with articles in the back end.

It is important to remember that these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.

Beachte auch das in den ursprünglichen Standardwerten keine Berechtigungen auf Verweigert eingestellt sind. Dies ermöglicht in allen Berechtigungsebenen die jeweilige Berechtigung auf Erlaubt einzustellen. Bedenke, wenn eine Aktion auf Verweigert eingestellt ist, das diese Aktion auch in allen untergeordneten Ebenen in der Berechtigungshierarchie verweigert wird. Zum Beispiel, wenn die Seitenameldung für Registered auf Verweigert (anstatt auf Erlaubt) eingestellt wird, kann man Publishers diese Aktion per Berechtigungeinstellung nicht erteilen.

=== Beitrags-Manager & Aktions-Diagramm ===

The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.

[[Image:screenshot_acl_tutorial_20110111-16-en.png|center|]]

* '''Configure''' allows you to view and change the Options for the component.
* '''Access Component''' allows you to navigate to the Article Manager. Without this permission, no other actions are possible.
* '''Create''' allows you to add new articles.
* '''Delete''' allows you to delete trashed articles. Note that the Delete icon only shows in the toolbar when you have the "Select State" filter set to "Trash".
* '''Edit''' allows you to edit existing articles.
* '''Edit State''' allows to you Publish, Unpublish, Archive, or Trash articles.
* '''Edit Own''' is the same as Edit except that it only applies to articles written by you.

==Allowing Guest-Only Access to Menu Items and Modules==

Version 1.6 introduced the ability to create a View Access Level that is only for guests of the site (meaning a user who is not logged in). The example below shows how you can set up this new feature.
''(N.B. Steps 1 to 3 are not needed for Joomla! 3.x as they exist in the default install)''

#Create a new user group called Guest. Make it a child of the Public group as shown below. [[Image:screenshot_acl_tutorial_20110112-01-en.png|center|frame]]
# Create a new access level called Guest and grant only the Guest group access to this level, as shown below.[[Image:screenshot_acl_tutorial_20110112-02-en.png|center|frame]]
# Navigate to User Manager→Options→Component and change the Guest User Group from the default value of "Public" to "Guest", as shown below.
[[Image:screenshot_acl_tutorial_20110112-04-en.png|center|frame]]
Now, if we assign a menu item, module, or other object to the Guest access level, only non-logged in users will have access. For example, if we create a new menu item with access level of Guest, as shown below,
[[Image:screenshot_acl_tutorial_20110112-05-en.png|center|frame]]
this menu item will only be visible to non-logged-in visitors to the site.

If required other user groups like Author can be granted access in the Guest access level, this would allow Authors to view articles in the front end for editing.

'''N.B. Login/logout in front end (''for changing data in session'') to see the change.'''

==Berechtigungen und Gruppenebenen gemeinsam nutzen==

As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.

This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:

* both groups can create new articles only in the History Assignments category.

* only History Teachers (not Assistant History Teachers) can Publish or otherwise have Edit State permission.

This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.

[[Image:Acl example diagram1 20091018-en.png|center|]]

In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.

To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.

Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.

[[Image:Acl example diagram2 20091018-de.png|center|]]

This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.

Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.

==ACL Aktion Berechtigungs-Beispiele==

===Backend Beitrag Administrator===

'''Problem:'''

We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.

'''Lösung:'''

# Create a new group called Article Administrator and make its parent group Public, as shown below.[[Image:screenshot_acl_tutorial_20110112-10-de.png|center|frame]] Because its parent group is Public, it won't have any permissions by default.
# In Users → Access Levels, edit the Special Access level to add the new group. That way they can get access to the back end menu items and modules (This assumes that the modules for the admin menu and quickicons have the Special Access level assigned to them, which is the default.) [[Image:screenshot_acl_tutorial_20110112-11-de.png|center|frame]] By default, the back-end menu items and modules are set to Special access, so if you forget to add the new group to the Special access level, you won't see any modules or menu items when you log in as a user of the new group.
# In Site → Global Configuration → Permissions, click on the Article Administrator group and change the permissions to Allowed for the following actions: Admin Login, Create, Delete, Edit, Edit State, and Edit Own. The screen below shows what will show before you press Save. [[Image:screenshot_acl_tutorial_20110112-12-de.png|center|frame]]After you save, the Calculated Permissions should show as shown below.[[Image:screenshot_acl_tutorial_20110112-13-de.png|center|frame]]Note that the permission for the Access Component is Inherited, which translates to Not Allowed. This is important. This means that this group will only be able to access components if we give the group "Allowed" permission for Access Component. So we only have to change the one component we want to give them access to and don't have to change any settings for the components where we don't want them to have access. If we had a case where we wanted to give a group access to everything except for one component, we could set the default to Allowed and then set the one component to Denied. Also note that we did not give the group Site Login permission, so users in this group will not be able to log into the front end. (If we wanted to allow that, we would just change the permission to Allowed for Site Login.)
# In Article Manager → Options → Permissions, change permissions to Allowed for this group for the Access Component action, as shown below.[[Image:screenshot_acl_tutorial_20110112-14-de.png|center|frame]]All of the other desired permissions are inherited.

That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end. For example, the screen below shows what a user in the Article Manager will see when they login to the back end.[[Image:screenshot_acl_tutorial_20110112-15-de.png|center|frame]]

==ACL Ansicht Zugriffsebenen-Beispiele==

A basic concept of using Access Levels is that all items with the same Access will be viewable by the same group of users. In other words, if two items have the same Access, you can't have one viewable by one user and not viewable by another user. On the other hand, it is easy to have one Group view any number of items with different Access levels.

Similarly, each Group has exactly the same combination of Access levels, but one User can be a member of more than one group. Depending on the situation, you may want to have users only in one Group or you may need to have a User in more than one Group.

This means that we may need to group our items so that items so that all items in a group have the same level of sensitivity. Here are some examples.

===Hierarchisches Beispiel===
In this example, Access levels are hierarchical, for example, like government security clearance codes. Say for example we have the following sets of classified documents: Classified, Secret, and Top Secret. Users have corresponding clearence codes. Users with Classified clearance can only see Classified documents and cannot see Secret or Top Secret. Users with Secret clearance can see Classified and Secret documents but not Top Secret. Users with Top Secret can see all documents.

In this case, you would create three Access levels: Classified, Secret, and Top Secret and the same three Groups. Users would only be members of one group, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| C1, C2, C3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Classified
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| S1, S2, S3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| TS1, TS2, TS3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Top Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret, Top Secret

|}

In this case, all users are in exactly one group, but some groups have access to more than one Access Level of items. In other words, we have a one-to-one relationship between users and groups, but a one-to-many relationship between Groups and Access Levels.

===Teamsicherheit Beispiel===

Another possible use case is a set of non-hierarchical teams. Let's say we have three teams, T1, T2, and T3. Some users are only on one team, but others might be on two or more teams. In this case, we could set up our Access Levels and Groups by team. Documents for each team have the access level for that team, and the Group for the team has only the one access level. When a User is on more than one team, they get added to the group for each team, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Beschreibung
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 1 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 2 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 3 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1, 2 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1,T2, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2, T3

|}

===Hybrid Example===

In a real-world situation, you might have a combination of these two arrangements. Say for example we have Managers and Staff. Staff can only see Staff documents and Managers can see Manager and Staff documents. Both types of users can be assigned to teams as well, in which case they can see all of the documents for that team. In addition, say that Managers can access some, but not all, team documents. Staff can only access team documents if they are members of that team.

In this example, we could set up the following Access Levels:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Access Level
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Description
| style="border:0.0007in solid #000000;padding:0.0382in;"| Groups

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team manager documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team staff documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team1 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1, Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team2 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2, Manager

|}

Then, users could be assigned to groups as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| User Type
| style="border:0.0007in solid #000000;padding:0.0382in;"| Group

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1, Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1, Team2

|}

<noinclude>
[[Category:Joomla! 1.6]]
[[Category:Joomla! 2.5]]
[[Category:Joomla! 3.x/de]]
[[Category:Tutorials/de]]
[[Category:Access Control/de]]
[[Category:Access Management]]
</noinclude>

Translations:J3.x:Access Control List Tutorial/183/de

2019-12-26T19:05:58Z

Sieger66:

J3.x:Access Control List Tutorial/de

2019-12-26T19:05:44Z

Sieger66:

<noinclude><languages /></noinclude>
{{Joomla version|version=3.x|comment=Serie}}
{{-}}
{{:J3.1:Access_Control_List/en}}

==Separate ACL für Anzeige und Aktionen==

Das Joomla ACL-System besteht genau genommen aus zwei völlig getrennten Systemen. Das eine System steuert, was Benutzer auf der Website "sehen" können. Das andere steuert, was Benutzer "tun" können (welche Aktionen ein Benutzer durchführen kann). Die ACL wird für jedes dieser Systeme anders eingerichtet.

===Steuern, was Benutzer sehen können===

Das Setup zum Steuern, was Benutzer sehen können, sieht wie folgt aus:
*Eine Reihe von Zugriffsebenen gemäß den Kategorien und/oder der Kombination von Kategorien erstellen, die nur angemeldete Benutzer sehen sollen. Anmerkung: Zu diesem Zeitpunkt werden noch keine Benutzergruppen den neuen Zugriffsebenen zugewiesen.

*Für jede Zugriffsebene eine Benutzergruppe erstellen, die 'Registriert' als übergeordnete Gruppe hat. Indem man für Benutzergruppen und Zugriffsebenen die gleichen Namen verwendet, kann man Verwirrungen zu einem späteren Zeitpunkt vorbeugen.

*Die neuen Zugriffsebenen bearbeiten und jeder die (neue) Benutzergruppe zuweisen. Wahrscheinlich möchten man auch die 'Super Benutzer' Gruppe (und/oder die anderen Standard-Benutzergruppen mit Ausnahme der Benutzergruppe 'Gast') den neuen Zugriffsebenen zuweisen.

*Jedem anzuzeigenden Eintrag eine Zugriffsebene zuweisen. Einträge sind sowohl inhaltliche Einträge (Beiträge, Kontakte, usw.), Menüeinträge als auch Module.

Immer dann, wenn ein Benutzer im Begriff ist, einen Eintrag auf einer Joomla-Seite anzeigen zu lassen, prüft das Programm, ob dieser Benutzer auch Zugriff auf den Eintrag hat. Das geschieht folgendermaßen:
# Zunächst wird eine Liste aller Zugriffsebenen erstellt, auf die der Benutzer zugreifen kann, basierend auf allen Gruppen, denen der Benutzer angehört. Sofern eine Gruppe eine übergeordnete Gruppe besitzt, sind die Zugriffsebenen für die übergeordnete Gruppe ebenfalls in der Liste enthalten.
# Danach wird überprüft, ob die Zugriffsebene für den Eintrag (Beitrag, Modul, Menüeintrag, usw.) in dieser Liste enthalten ist. Wenn dem so ist, wird der Eintrag dem Benutzer angezeigt. Falls der Benutzer die benötigten Zugriffsrechte besitzt, wird ihm der Zugriff verweigert.

Beachten, dass Zugriffsebenen für jede Gruppe separat festgelegt und nicht von der übergeordneten Gruppe einer Gruppe vererbt werden.

===Steuern, was Benutzer tun können===

Das System, das steuert, was Benutzer in einer Benutzergruppe tun können - welche Aktionen sie bei einem bestimmten Eintrag ausführen können - wird über den Tab 'Berechtigungen' in der Konfiguration und den Tab 'Berechtigungen' in den Optionen jeder einzelnen Komponente eingerichtet. Berechtigungen können auch auf Kategorienebene (bei Kernkomponenten) und auf Beitragsebene (bei Beiträgen) gesetzt werden.

* Wenn angemeldete Benutzer in bestimmten Kategorien Erstellen, Löschen, Status bearbeiten oder Eigene Inhalte bearbeiten dürfen, dann:
** Eine Benutzergruppe erstellen und als übergeordnete Gruppe eine der Benutzergruppen angeben, die Zugriff auf die Kategorie (oder Kategorien) haben, die diese neue Benutzergruppe ändern soll.
**Der neuen Benutzergruppe den entsprechenden Zugriffsebenen zuweisen. Dann die erforderlichen Berechtigungen für die neue Benutzergruppe entweder global oder pro Kategorie/Beitrag ändern.
*** Beim Erstellen einer Benutzergruppe ist es ratsam, eine übergeordnete Gruppe zu wählen, die über weniger Berechtigungen verfügt, als für die neue Gruppe erforderlich. Denn es ist einfacher, die Berechtigungen für jede Komponente/Kategorie/Beitrag zu erweitern, für die zusätzliche Berechtigungen nötig sind, als Berechtigungen aus den anderen Komponenten/Kategorien/Beiträgen zu entfernen.
****''(Beispiel: Es gibt 10 Kategorien, man möchte aber nur für eine Erstellen-Berechtigungen. Würde man für diese Gruppe die Berechtigungen global auf Erstellen erlaubt setzen, müsste man für diese Kategorien die Erstellen-Berechtigung entfernen. Und man müsste für diese Gruppe die Erstellen-Berechtigung bei jeder neuen Kategorie, die man zu einem späteren Zeitpunkt hinzufügt, ebenfalls entfernen).''
** Eine Benutzergruppe erstellen, die eine der Standardbenutzergruppen als übergeordnete Gruppe hat, NUR, wenn keine von diesen über die exakten Berechtigungen verfügt, die man benötigt und sich für alle Kategorien wünscht.

Beachten, dass dieses Setup unabhängig vom Setup für die Anzeige ist. Allerdings muss eine Benutzergruppe den entsprechenden Zugriffsebenen zugewiesen werden, damit der Benutzer in dieser Gruppe jene Berechtigungen verwenden kann.

Möchte ein Benutzer eine bestimmte Aktion bei einem Komponenten-Eintrag durchführen (z. B. einen Beitrag bearbeiten), überprüft das System (nachdem es überprüft hat, welcher Gruppe der Benutzer angehört und auf welche er Zugriff hat) die Berechtigung für diese Kombination aus Benutzer, Eintrag und Aktion. Liegt eine Erlaubnis vor, kann der Benutzer fortfahren. Andernfalls ist die Aktion nicht zulässig.

Das restliche Tutorial befasst sich mit der Steuerung, was Benutzer tun können - welche Aktionsberechtigungen sie haben.

==Aktionen, Gruppen und Vererbung==

Andererseits geht es bei der ACL auch darum, Benutzern Berechtigungen zu erteilen, damit diese Aktionen an Objekten durchführen können.

{| class="wikitable"
!style="width:20%;"|
!3.x Serie
|-
!Gruppen und Aktionen
|Aktionen, welche pro Gruppe erlaubt sind, werden durch den Website Administrator festgelegt.
|-
!Umfang von Berechtigungen
|Berechtigungen können auf mehreren Ebenen in der Hierarchie festgelegt werden: Website, Komponente, Kategorie, Objekt.
|-
!Vererbung von Berechtigungen
|Berechtigungen können von übergeordneten Gruppen und übergeordneten Kategorien geerbt werden.
|}

===Wie die Berechtigungen funktionieren===

Es gibt vier mögliche Berechtigungen für Aktionen. Diese sind (kurz skizziert):

* '''Nicht gesetzt''': Fällt standardmäßig auf "Nicht erlaubt" zurück. Aber im Gegensatz zur Berechtigung "Verweigert" kann diese Berechtigung außer Kraft gesetzt werden, wenn eine untergeordnete Gruppe oder eine in der Berechtigungshierarchie untergeordnete Ebene auf "Erlaubt" gesetzt wird. Diese Berechtigung kann nur für globale Berechtigungen der Konfiguration gesetzt werden.
* '''Vererbt''': Erbt den Wert von einer übergeordneten Gruppe oder einer in der Berechtigungshierarchie höheren Ebene. Diese Berechtigung gilt für alle Ebenen mit Ausnahme der obersten Ebene der Konfiguration.
* '''Verweigert''': Verbietet diese Aktion für diese Ebene und Gruppe. '''WICHTIG:''' Dadurch wird diese Aktion auch für alle untergeordneten Gruppen und alle untergeordneten Ebenen in der Berechtigungshierarchie verboten. Wird "Erlaubt" in einer untergeordneten Gruppe oder einer tieferen Ebene gesetzt, hat das keinen Effekt. Die Aktion wird immer für alle Mitglieder einer untergeordneten Gruppe und für alle untergeordneten Ebenen in der Berechtigungshierarchie abgelehnt.
* '''Erlaubt ''': Genehmigt diese Aktion für diese Ebene und Gruppe und für tiefere Ebenen und Untergruppen. Dies hat keine Auswirkungen, wenn eine höhere Gruppe oder Ebene auf "Verweigert" oder "Erlaubt" eingestellt ist. Wenn eine höhere Gruppe oder ein höheres Ebene auf "Verweigert" gesetzt ist, wird diese Berechtigung immer abgelehnt. Wenn eine höhere Gruppe oder Ebene auf Erlaubt eingestellt ist, ist diese Berechtigung bereits erlaubt.

===Hierarchie der Berechtigungsebenen===

Berechtigungen für Aktionen können in Version 2.5+ auf bis zu vier Ebenen festgelegt werden, wie folgt:
# '''Konfiguration''': legt die Standardberechtigungen für jede Aktion und Gruppe fest.
# '''Komponenten-Optionen-> Berechtigungen''': kann die Standardberechtigungen für diese Komponente überschreiben (z. B. Beiträge, Menüs, Benutzer, Banner usw.).
# '''Kategorie''': kann die Standardberechtigungen für Objekte in einer oder mehreren Kategorien überschreiben. Gilt für alle Komponenten mit Kategorien, einschließlich Beiträge, Banner, Kontakte, Newsfeeds und Weblinks.
# '''Beitrag''': kann die Berechtigungen für einen bestimmten Artikel überschreiben. Diese Ebene gilt nur für Beiträge. Alle anderen Komponenten erlauben nur die ersten drei Ebenen.

====Konfiguration====
Diese erreicht man über System → Konfiguration → Berechtigungen. Die nun sichtbare Maske dient dazu, die Berechtigungen auf der obersten Ebene für jede Gruppe und jede Aktion festzulegen, wie auch in der folgenden Abbildung gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Die möglichen Werte sind Vererbt, Erlaubt oder Verweigert. Die Spalte 'Errechnete Einstellung' zeigt die aktuelle Einstellung an. Diese ist entweder Nicht erlaubt (Standard), Erlaubt oder Nicht erlaubt.

Man kann immer nur an einer Gruppe gleichzeitig arbeiten, indem man den Reiter für ebendiese Gruppe anklickt. Die Berechtigungen kann man über die Dropdownlisten unter Neue Einstellung wählen ändern.

Beachten Sie, dass die Spalte "Errechnete Einstellung" erst aktualisiert wird, wenn Sie auf die Schaltfläche "Speichern" in der Werkzeugleiste klicken.

Um zu überprüfen, ob die Einstellungen Ihren Wünschen entsprechen, klicken Sie auf die Schaltfläche Speichern und überprüfen anschließend die Spalte Errechnete Einstellung.

====Komponenten-Optionen->Berechtigungen====
Auf diese wird für jede Komponente durch Klicken auf das Symbol "Optionen" in der Werkzeugleiste zugegriffen. Dieser Bildschirm ist ähnlich wie der Bildschirm "Globale Konfiguration" oben links. Wenn Sie beispielsweise im Menü-Manager auf das Symbol in der Werkzeugleiste Optionen klicken, werden die folgenden Menüs angezeigt.
[[Image:Screenshot_menu_acl_J3_tutorial-en.jpg]]

Der Zugriff auf Optionen ist nur für Mitglieder von Gruppen möglich, die die Berechtigung für die Aktion Konfiguration in für jede Komponente haben. Im obigen Beispiel hat die Gruppe Administrator die Berechtigung Erlaubt für die Option Konfigurieren, so dass Mitglieder dieser Gruppe auf diesen Bildschirm zugreifen können.

===Kategorie===
Auf die Kategorieberechtigungen wird im Category Manager zugegriffen: Bildschirm Kategorie bearbeiten, in einer Registerkarte oben auf dem Bildschirm. Dieser Bildschirm hat fünf Berechtigungen, wie folgt:

[[Image:Screenshot_category_acl_j3_tutorial-en.png]]

In diesen Bildern bearbeiten Sie die Berechtigungen für jeweils eine Benutzergruppe. Im obigen Beispiel bearbeiten Sie die Berechtigungen für die Gruppe Administrator.

Achten Sie darauf, dass die Aktionen "Konfigurieren und Zugriffssteuerung" nicht auf der Kategorieebene angewendet werden, so dass diese Aktionen nicht enthalten sind.

Beachten Sie auch, dass Kategorien in einer Hierarchie angeordnet werden können. Wenn ja, dann werden Aktionsberechtigungen in einer übergeordneten Kategorie automatisch an eine untergeordnete Kategorie vererbt. Wenn Sie beispielsweise eine Kategoriehierarchie von Tieren → Haustiere → Hunde hätten, dann würde die vollständige Berechtigungshierarchie für einen Artikel in der Kategorie Hunde wie folgt aussehen:
* Globale Konfiguration
* Artikel-Manager → Optionen → Genehmigung → Erlaubnis
* Tierkategorie
* Kategorie Haustiere
* Kategorie Hunde
* spezifischer Artikel

====Beitrag====
Berechtigungen für einzelne Beiträge findet man im "Beitrag" unter dem Tab-Reiter "Berechigungen". Dieser Bildschirm hat drei Aktionen, wie unten gezeigt.

[[Image:j3x_acl_tutorial_article_manager_article_permissions-en.png]]

Auch hier bearbeiten Sie jede Gruppe für sich. Um auf die Berechtigungen zuzugreifen wechseln Sie im Artikel auf den Reiter "Berechtigungen" im oberen Reiter. Über das Drop Down Menü wählen Sie die neue Berechtigung im Anschluss speichern Sie den Beitrag ab.

Beachten Sie, dass die Aktionen Configure, Access Component und Create auf Artikelebene nicht gelten, so dass diese Aktionen nicht berücksichtigt werden. Die Berechtigung zum Anlegen eines Artikels wird auf einer der höheren Ebenen der Hierarchie festgelegt.

===Zugriffsebenen===

Die Zugriffsebenen der 3.x-Serie sind einfach und flexibel. Der folgende Bildschirm zeigt die spezielle Zugriffsebene.
[[Image:j3x_acl_tutorial_viewing_levels-en.png|center]]
Aktivieren Sie einfach das Kontrollkästchen für jede Gruppe, die Sie in diesem Level aufnehmen wollen. Die spezielle Zugriffsebene umfasst die Gruppen Manager, Autor und Superuser. Es beinhaltet auch untergeordnete Gruppen dieser Gruppen. Die Gruppe Administrator ist also enthalten, da es sich um eine Untergruppe der Gruppe Manager handelt. Die Gruppen Editor, Publisher und Shop Suppliers sind enthalten, da es sich um Untergruppen des Autors handelt.

Jedem Objekt im Frontend ist eine Zugriffsebene zugeordnet. Wenn die Ebene öffentlich ist, kann jeder auf dieses Objekt zugreifen. Andernfalls dürfen nur Mitglieder von Gruppen, die dieser Zugriffsebene zugeordnet sind, auf dieses Objekt zugreifen.

Die Zugriffsebenen sind den Menüpunkten und den Modulen zugeordnet. Jede kann nur einer Zugriffsebene zugeordnet werden.

Der folgende Bildschirm zeigt beispielsweise den Bildschirm Menüpunkt bearbeiten mit der Liste der verfügbaren Zugriffsebenen....

[[Image:j3x_acl_tutorial_edit_menu_item_level_dropdown-en.png|center]]

==Standard-ACL-Setup==

Wenn Joomla! installiert ist, werden diese auf die ursprünglichen Standardwerte gesetzt. Wir werden diese Grundeinstellungen besprechen, um die Arbeitsweise der ACL zu verstehen.

===Standardgruppen===

Mit der Version 3.x können Sie Ihre individuellen Gruppen definieren. Wenn Sie die Version 3.x installieren, enthält sie eine Reihe von Standardgruppen, die im Folgenden dargestellt werden, sind die grundlegenden Standardbenutzergruppen. (Zusätzliche Standardbenutzergruppen werden mit Beispieldaten installiert)

[[Image:Screenshot_usergroupsl_acl_J3_tutorial-en.png|center]]

Die Pfeile zeigen die untergeordneten Elternbeziehungen an. Wie vorstehend besprochen, wird diese Berechtigung, wenn Sie eine Berechtigung für eine übergeordnete Gruppe festlegen, automatisch an alle Untergruppen vererbt. Die vererbten und zulässigen Berechtigungen können für eine Untergruppe überschrieben werden. Die Berechtigung Verweigert kann nicht überschrieben werden und verweigert immer eine Aktion für alle Untergruppen.

===Konfiguration===

Joomla! Version 3.x wird mit den gleichen bekannten Backend-Rechten wie die Version 1.5 (EOL) installiert. Mit der Version 3.x können Sie diese jedoch leicht an die Bedürfnisse Ihrer Website anpassen.

Wie bereits besprochen, werden die Berechtigungen für jede Aktion von der obigen Ebene in der Berechtigungshierarchie und von der übergeordneten Gruppe einer Gruppe übernommen. Also, wie funktioniert das? Die oberste Ebene dafür ist der gesamte Standort. Dies wird in der Site->Globale Konfiguration->Berechtigungen eingerichtet, wie unten gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Das erste, was man bemerken sollte, sind die zehn Aktionen: Standortlogin, Admin-Login, Offline-Zugriff, Superuser, Access Administration Interface, Erstellen, Löschen, Bearbeiten, Status bearbeiten und Eigenes bearbeiten. Dies sind die Aktionen, die ein Benutzer an einem Objekt in Joomla durchführen kann. Die spezifische Bedeutung jeder Aktion hängt vom Kontext ab. Für das Bild Globale Konfiguration sind sie wie folgt definiert:

Site Login : Login to the front end of the site

;Admin Login : Melden Sie sich am Backend der Website an.

Offline-Zugriff: Melden Sie sich am Frontend der Website an, wenn die Website offline ist (wenn die globale Konfigurationseinstellung "Site Offline" auf Ja gesetzt ist).

Superuser: Gewährt dem Benutzer den Status "Superuser". Benutzer mit dieser Berechtigung dürfen alles auf der Website machen. Nur Benutzer mit dieser Berechtigung können die Einstellungen der globalen Konfiguration ändern. Diese Berechtigungen können nicht eingeschränkt werden. Es ist wichtig zu verstehen, dass, wenn ein Benutzer Mitglied einer Super Admin-Gruppe ist, alle anderen Berechtigungen, die diesem Benutzer zugewiesen sind, irrelevant sind. Der Benutzer kann jede Aktion auf der Website durchführen. Es können jedoch weiterhin Zugriffsebenen zugewiesen werden, um zu steuern, was diese Gruppe auf der Website sieht. (Natürlich kann ein Super-Admin-Benutzer die Zugriffsebenen ändern, wenn er möchte, so dass die Zugriffsebenen nicht vollständig einschränken, was ein Super-Admin-Benutzer sehen kann.)

Zugangskomponente: Öffnen Sie die Bildschirme der Komponentenverwaltung (Benutzerverwaltung, Menüverwaltung, Artikelverwaltung usw.).

;Create : Create new objects (for example, users, menu items, articles, weblinks, and so on)

;Löschen : Löschen eines existienden Objekts

;Ändern : Ändern eines existierenden Objektes

;Ändern eines Objekt Status (Veröffentlicht, nicht Veröffentlicht, Archiviert und Gelöscht)

Eigene Objekte bearbeiten: Bearbeiten Sie Objekte, die Sie erstellt haben.

Each Group for the site has its own slider which is opened by clicking on the group name. In this case (with the sample data installed), we have the standard 7 groups that we had in version 1.5 plus two additional groups called "Shop Suppliers" and "Customer Group". Notice that our groups are set up with the same permissions as they had in version 1.5. Keep in mind that we can change any of these permissions to make the security work the way we want. Let's go through this to see how it works.

* '''Public''' has everything set to "Not set", as shown below.{{-}}[[Image:Screenshot_global_acl_public_J3_tutorial-en.png]]
**This can be a bit confusing. Basically, "Not Set" is the same as "Inherited". Because Public is our top-level group, and because Global Configuration is the top level of the component hierarchy, there is nothing to inherit from. So "Not Set" is used instead of "Inherit".
**The default in this case is for no permissions. So, as you would expect, the Public group has no special permissions. Also, it is important to note that, since nothing is set to Denied, all of these permissions may be overridden by child groups or by lower levels in the permission hierarchy.

* '''Guest''' is a 'child' group of the Public group has everything set to 'Inherited' {{-}}[[Image:Screenshot_global_acl_guest_J3_tutorial-de.png]]
** This is the default 'Guest User Group' in the User Manager options and the Group that (non logged in) visitors to your site are placed in.

* '''Manager''' is a "child" group of the Public group. It has Allowed permissions for everything except Access Component and Super Admin. So a member of this group can do everything in the front and back end of the site except change Global Permissions and Component Options. {{-}}[[Image:Screenshot_global_acl_manager_J3_tutorial-en.png]]

* '''Administrator''' group members inherit all of the Manager permissions and also have Allowed for Access Component. So members of this group by default can access the Options screens for each component. {{-}}[[Image:Screenshot_global_acl_administrator_J3_tutorial-en.png]]

* '''Registered''' is the same a Public except for the Allow permission for the Site Login action. This means that members of the Registered group can login to the site. Since default permissions are inherited, this means that, unless a child group overrides this permission, all child groups of the Registered group will be able to login as well. {{-}}[[Image:Screenshot_global_acl_registered_J3_tutorial-en.png]]

* '''Author''' is a child of the Registered group and inherits its permissions and also adds Create and Edit Own. Since Author, Editor, and Publisher have no back-end permissions, we will discuss them below, when we discuss front-end permissions.{{-}}[[Image:Screenshot_global_acl_author_J3_tutorial-en.png]]

* '''Editor''' is a child of the Authors group and adds the Edit permission. {{-}}[[Image:Screenshot_global_acl_editor_J3_tutorial-en.png]]

* '''Publisher''' is a child of Editor and adds the Edit State permission.{{-}}[[Image:Screenshot_global_acl_publisher_J3_tutorial-en.png]]

* '''Shop Suppliers''' is an example group that is installed if you install the sample data. It is a child group of Author.

* '''Customer Group''' is an example group that is installed if you install the sample data. It is a child group of Registered.

* '''Super Users''' group has the Allow permission for the Super Admin action. Because of this, members of this group have super user permissions throughout the site. They are the only users who can access and edit values on the Global Configuration screen. Users with permission for the Super Admin action have some special characteristics:
:* If a user has Super Admin permissions, no other permissions for this user matter. The user can perform any action on the site.
:* Only Super Admin users can create, edit, or delete other Super Admin users or groups.

There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.

This provides a lot of flexibility. For example, if you wanted Shop Suppliers to be able to have the ability to login to the back end, you could just change their Admin Login value to "Allowed". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherited (or Denied).

It is also important to understand that the ability to have child groups is completely optional. It allows you to save some time when setting up new groups. However, if you like, you can set up all groups to have Public as the parent and not inherit any permissions from a parent group.

===Komponenten-Optionen & Berechtigungen===

Now, let's continue to see how the default back-end permissions for version 2.5 mimic the permissions for version 1.5. The Super Users group in 2.5 is equivalent to the Super Administrator group in 1.5.

Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 2.5 configuration. Let's see how this is accomplished.

If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:

[[Image:screenshot_acl_tutorial_20110111-09-en.png|center|]]
[[Image:screenshot_acl_tutorial_20110111-10-en.png|center|]]

This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.

First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.

Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.

If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.

In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.

It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.

===Frontend Berechtigungen===

Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions. First, let's look at the permissions for Manager, as shown below.
[[Image:screenshot_acl_tutorial_20110111-11a-en.png|center|frame]]
Manager has allowed permission for all actions except Configure. So members of the Manager group can do everything with Articles except open the Options screen.

Now let's look at Administrator, as shown below.
[[Image:screenshot_acl_tutorial_20110111-12a-en.png|center|frame]]
Administrator has Allowed for Configure, so Administrators can edit this Options screen.

Both groups can create, delete, edit, and change the state of articles.

Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set.

Authors only have Create and Edit Own permissions, as shown below.
[[Image:screenshot_acl_tutorial_20110112-07-en.png|center|frame]]
This means that Authors can create articles and can edit articles they have created. They may not delete articles, change the published state of articles, or edit articles created by others.

Editors have the same permissions as Authors with the addition of permission for the Edit action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-08-en.png|center|frame]]
So Editors can edit articles written by anyone.

Publishers can do everything Editors can do plus they have permission for the Edit State action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-09-en.png|center|frame]]
So Publishers can change the published state of an article. The possible states include Published, Unpublished, Archived, and Trashed.

All of these groups have Inherit permission for Configure and Access Component. Remember that Author is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Configure and Access Component, and since Author's permission for these actions is "Inherited", then Author does not have these permissions either. This same permission is passed from Author to Editor and from Editor to Publisher. So, by default, none of these groups are allowed to work with articles in the back end.

It is important to remember that these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.

Beachte auch das in den ursprünglichen Standardwerten keine Berechtigungen auf Verweigert eingestellt sind. Dies ermöglicht in allen Berechtigungsebenen die jeweilige Berechtigung auf Erlaubt einzustellen. Bedenke, wenn eine Aktion auf Verweigert eingestellt ist, das diese Aktion auch in allen untergeordneten Ebenen in der Berechtigungshierarchie verweigert wird. Zum Beispiel, wenn die Seitenameldung für Registered auf Verweigert (anstatt auf Erlaubt) eingestellt wird, kann man Publishers diese Aktion per Berechtigungeinstellung nicht erteilen.

=== Beitrags-Manager & Aktions-Diagramm ===

The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.

[[Image:screenshot_acl_tutorial_20110111-16-en.png|center|]]

* '''Configure''' allows you to view and change the Options for the component.
* '''Access Component''' allows you to navigate to the Article Manager. Without this permission, no other actions are possible.
* '''Create''' allows you to add new articles.
* '''Delete''' allows you to delete trashed articles. Note that the Delete icon only shows in the toolbar when you have the "Select State" filter set to "Trash".
* '''Edit''' allows you to edit existing articles.
* '''Edit State''' allows to you Publish, Unpublish, Archive, or Trash articles.
* '''Edit Own''' is the same as Edit except that it only applies to articles written by you.

==Allowing Guest-Only Access to Menu Items and Modules==

Version 1.6 introduced the ability to create a View Access Level that is only for guests of the site (meaning a user who is not logged in). The example below shows how you can set up this new feature.
''(N.B. Steps 1 to 3 are not needed for Joomla! 3.x as they exist in the default install)''

#Create a new user group called Guest. Make it a child of the Public group as shown below. [[Image:screenshot_acl_tutorial_20110112-01-en.png|center|frame]]
# Create a new access level called Guest and grant only the Guest group access to this level, as shown below.[[Image:screenshot_acl_tutorial_20110112-02-en.png|center|frame]]
# Navigate to User Manager→Options→Component and change the Guest User Group from the default value of "Public" to "Guest", as shown below.
[[Image:screenshot_acl_tutorial_20110112-04-en.png|center|frame]]
Now, if we assign a menu item, module, or other object to the Guest access level, only non-logged in users will have access. For example, if we create a new menu item with access level of Guest, as shown below,
[[Image:screenshot_acl_tutorial_20110112-05-en.png|center|frame]]
this menu item will only be visible to non-logged-in visitors to the site.

If required other user groups like Author can be granted access in the Guest access level, this would allow Authors to view articles in the front end for editing.

'''N.B. Login/logout in front end (''for changing data in session'') to see the change.'''

==Berechtigungen und Gruppenebenen gemeinsam nutzen==

As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.

This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:

* both groups can create new articles only in the History Assignments category.

* only History Teachers (not Assistant History Teachers) can Publish or otherwise have Edit State permission.

This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.

[[Image:Acl example diagram1 20091018-de.png|center|]]

In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.

To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.

Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.

[[Image:Acl example diagram2 20091018-de.png|center|]]

This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.

Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.

==ACL Aktion Berechtigungs-Beispiele==

===Backend Beitrag Administrator===

'''Problem:'''

We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.

'''Lösung:'''

# Create a new group called Article Administrator and make its parent group Public, as shown below.[[Image:screenshot_acl_tutorial_20110112-10-de.png|center|frame]] Because its parent group is Public, it won't have any permissions by default.
# In Users → Access Levels, edit the Special Access level to add the new group. That way they can get access to the back end menu items and modules (This assumes that the modules for the admin menu and quickicons have the Special Access level assigned to them, which is the default.) [[Image:screenshot_acl_tutorial_20110112-11-de.png|center|frame]] By default, the back-end menu items and modules are set to Special access, so if you forget to add the new group to the Special access level, you won't see any modules or menu items when you log in as a user of the new group.
# In Site → Global Configuration → Permissions, click on the Article Administrator group and change the permissions to Allowed for the following actions: Admin Login, Create, Delete, Edit, Edit State, and Edit Own. The screen below shows what will show before you press Save. [[Image:screenshot_acl_tutorial_20110112-12-de.png|center|frame]]After you save, the Calculated Permissions should show as shown below.[[Image:screenshot_acl_tutorial_20110112-13-de.png|center|frame]]Note that the permission for the Access Component is Inherited, which translates to Not Allowed. This is important. This means that this group will only be able to access components if we give the group "Allowed" permission for Access Component. So we only have to change the one component we want to give them access to and don't have to change any settings for the components where we don't want them to have access. If we had a case where we wanted to give a group access to everything except for one component, we could set the default to Allowed and then set the one component to Denied. Also note that we did not give the group Site Login permission, so users in this group will not be able to log into the front end. (If we wanted to allow that, we would just change the permission to Allowed for Site Login.)
# In Article Manager → Options → Permissions, change permissions to Allowed for this group for the Access Component action, as shown below.[[Image:screenshot_acl_tutorial_20110112-14-de.png|center|frame]]All of the other desired permissions are inherited.

That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end. For example, the screen below shows what a user in the Article Manager will see when they login to the back end.[[Image:screenshot_acl_tutorial_20110112-15-de.png|center|frame]]

==ACL Ansicht Zugriffsebenen-Beispiele==

A basic concept of using Access Levels is that all items with the same Access will be viewable by the same group of users. In other words, if two items have the same Access, you can't have one viewable by one user and not viewable by another user. On the other hand, it is easy to have one Group view any number of items with different Access levels.

Similarly, each Group has exactly the same combination of Access levels, but one User can be a member of more than one group. Depending on the situation, you may want to have users only in one Group or you may need to have a User in more than one Group.

This means that we may need to group our items so that items so that all items in a group have the same level of sensitivity. Here are some examples.

===Hierarchisches Beispiel===
In this example, Access levels are hierarchical, for example, like government security clearance codes. Say for example we have the following sets of classified documents: Classified, Secret, and Top Secret. Users have corresponding clearence codes. Users with Classified clearance can only see Classified documents and cannot see Secret or Top Secret. Users with Secret clearance can see Classified and Secret documents but not Top Secret. Users with Top Secret can see all documents.

In this case, you would create three Access levels: Classified, Secret, and Top Secret and the same three Groups. Users would only be members of one group, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| C1, C2, C3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Classified
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| S1, S2, S3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| TS1, TS2, TS3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Top Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret, Top Secret

|}

In this case, all users are in exactly one group, but some groups have access to more than one Access Level of items. In other words, we have a one-to-one relationship between users and groups, but a one-to-many relationship between Groups and Access Levels.

===Teamsicherheit Beispiel===

Another possible use case is a set of non-hierarchical teams. Let's say we have three teams, T1, T2, and T3. Some users are only on one team, but others might be on two or more teams. In this case, we could set up our Access Levels and Groups by team. Documents for each team have the access level for that team, and the Group for the team has only the one access level. When a User is on more than one team, they get added to the group for each team, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Beschreibung
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 1 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 2 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 3 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1, 2 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1,T2, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2, T3

|}

===Hybrid Example===

In a real-world situation, you might have a combination of these two arrangements. Say for example we have Managers and Staff. Staff can only see Staff documents and Managers can see Manager and Staff documents. Both types of users can be assigned to teams as well, in which case they can see all of the documents for that team. In addition, say that Managers can access some, but not all, team documents. Staff can only access team documents if they are members of that team.

In this example, we could set up the following Access Levels:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Access Level
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Description
| style="border:0.0007in solid #000000;padding:0.0382in;"| Groups

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team manager documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team staff documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team1 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1, Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team2 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2, Manager

|}

Then, users could be assigned to groups as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| User Type
| style="border:0.0007in solid #000000;padding:0.0382in;"| Group

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1, Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1, Team2

|}

<noinclude>
[[Category:Joomla! 1.6]]
[[Category:Joomla! 2.5]]
[[Category:Joomla! 3.x/de]]
[[Category:Tutorials/de]]
[[Category:Access Control/de]]
[[Category:Access Management]]
</noinclude>

Translations:J3.x:Access Control List Tutorial/173/de

2019-12-26T19:05:44Z

Sieger66:

J3.x:Access Control List Tutorial/de

2019-12-26T19:05:37Z

Sieger66:

<noinclude><languages /></noinclude>
{{Joomla version|version=3.x|comment=Serie}}
{{-}}
{{:J3.1:Access_Control_List/en}}

==Separate ACL für Anzeige und Aktionen==

Das Joomla ACL-System besteht genau genommen aus zwei völlig getrennten Systemen. Das eine System steuert, was Benutzer auf der Website "sehen" können. Das andere steuert, was Benutzer "tun" können (welche Aktionen ein Benutzer durchführen kann). Die ACL wird für jedes dieser Systeme anders eingerichtet.

===Steuern, was Benutzer sehen können===

Das Setup zum Steuern, was Benutzer sehen können, sieht wie folgt aus:
*Eine Reihe von Zugriffsebenen gemäß den Kategorien und/oder der Kombination von Kategorien erstellen, die nur angemeldete Benutzer sehen sollen. Anmerkung: Zu diesem Zeitpunkt werden noch keine Benutzergruppen den neuen Zugriffsebenen zugewiesen.

*Für jede Zugriffsebene eine Benutzergruppe erstellen, die 'Registriert' als übergeordnete Gruppe hat. Indem man für Benutzergruppen und Zugriffsebenen die gleichen Namen verwendet, kann man Verwirrungen zu einem späteren Zeitpunkt vorbeugen.

*Die neuen Zugriffsebenen bearbeiten und jeder die (neue) Benutzergruppe zuweisen. Wahrscheinlich möchten man auch die 'Super Benutzer' Gruppe (und/oder die anderen Standard-Benutzergruppen mit Ausnahme der Benutzergruppe 'Gast') den neuen Zugriffsebenen zuweisen.

*Jedem anzuzeigenden Eintrag eine Zugriffsebene zuweisen. Einträge sind sowohl inhaltliche Einträge (Beiträge, Kontakte, usw.), Menüeinträge als auch Module.

Immer dann, wenn ein Benutzer im Begriff ist, einen Eintrag auf einer Joomla-Seite anzeigen zu lassen, prüft das Programm, ob dieser Benutzer auch Zugriff auf den Eintrag hat. Das geschieht folgendermaßen:
# Zunächst wird eine Liste aller Zugriffsebenen erstellt, auf die der Benutzer zugreifen kann, basierend auf allen Gruppen, denen der Benutzer angehört. Sofern eine Gruppe eine übergeordnete Gruppe besitzt, sind die Zugriffsebenen für die übergeordnete Gruppe ebenfalls in der Liste enthalten.
# Danach wird überprüft, ob die Zugriffsebene für den Eintrag (Beitrag, Modul, Menüeintrag, usw.) in dieser Liste enthalten ist. Wenn dem so ist, wird der Eintrag dem Benutzer angezeigt. Falls der Benutzer die benötigten Zugriffsrechte besitzt, wird ihm der Zugriff verweigert.

Beachten, dass Zugriffsebenen für jede Gruppe separat festgelegt und nicht von der übergeordneten Gruppe einer Gruppe vererbt werden.

===Steuern, was Benutzer tun können===

Das System, das steuert, was Benutzer in einer Benutzergruppe tun können - welche Aktionen sie bei einem bestimmten Eintrag ausführen können - wird über den Tab 'Berechtigungen' in der Konfiguration und den Tab 'Berechtigungen' in den Optionen jeder einzelnen Komponente eingerichtet. Berechtigungen können auch auf Kategorienebene (bei Kernkomponenten) und auf Beitragsebene (bei Beiträgen) gesetzt werden.

* Wenn angemeldete Benutzer in bestimmten Kategorien Erstellen, Löschen, Status bearbeiten oder Eigene Inhalte bearbeiten dürfen, dann:
** Eine Benutzergruppe erstellen und als übergeordnete Gruppe eine der Benutzergruppen angeben, die Zugriff auf die Kategorie (oder Kategorien) haben, die diese neue Benutzergruppe ändern soll.
**Der neuen Benutzergruppe den entsprechenden Zugriffsebenen zuweisen. Dann die erforderlichen Berechtigungen für die neue Benutzergruppe entweder global oder pro Kategorie/Beitrag ändern.
*** Beim Erstellen einer Benutzergruppe ist es ratsam, eine übergeordnete Gruppe zu wählen, die über weniger Berechtigungen verfügt, als für die neue Gruppe erforderlich. Denn es ist einfacher, die Berechtigungen für jede Komponente/Kategorie/Beitrag zu erweitern, für die zusätzliche Berechtigungen nötig sind, als Berechtigungen aus den anderen Komponenten/Kategorien/Beiträgen zu entfernen.
****''(Beispiel: Es gibt 10 Kategorien, man möchte aber nur für eine Erstellen-Berechtigungen. Würde man für diese Gruppe die Berechtigungen global auf Erstellen erlaubt setzen, müsste man für diese Kategorien die Erstellen-Berechtigung entfernen. Und man müsste für diese Gruppe die Erstellen-Berechtigung bei jeder neuen Kategorie, die man zu einem späteren Zeitpunkt hinzufügt, ebenfalls entfernen).''
** Eine Benutzergruppe erstellen, die eine der Standardbenutzergruppen als übergeordnete Gruppe hat, NUR, wenn keine von diesen über die exakten Berechtigungen verfügt, die man benötigt und sich für alle Kategorien wünscht.

Beachten, dass dieses Setup unabhängig vom Setup für die Anzeige ist. Allerdings muss eine Benutzergruppe den entsprechenden Zugriffsebenen zugewiesen werden, damit der Benutzer in dieser Gruppe jene Berechtigungen verwenden kann.

Möchte ein Benutzer eine bestimmte Aktion bei einem Komponenten-Eintrag durchführen (z. B. einen Beitrag bearbeiten), überprüft das System (nachdem es überprüft hat, welcher Gruppe der Benutzer angehört und auf welche er Zugriff hat) die Berechtigung für diese Kombination aus Benutzer, Eintrag und Aktion. Liegt eine Erlaubnis vor, kann der Benutzer fortfahren. Andernfalls ist die Aktion nicht zulässig.

Das restliche Tutorial befasst sich mit der Steuerung, was Benutzer tun können - welche Aktionsberechtigungen sie haben.

==Aktionen, Gruppen und Vererbung==

Andererseits geht es bei der ACL auch darum, Benutzern Berechtigungen zu erteilen, damit diese Aktionen an Objekten durchführen können.

{| class="wikitable"
!style="width:20%;"|
!3.x Serie
|-
!Gruppen und Aktionen
|Aktionen, welche pro Gruppe erlaubt sind, werden durch den Website Administrator festgelegt.
|-
!Umfang von Berechtigungen
|Berechtigungen können auf mehreren Ebenen in der Hierarchie festgelegt werden: Website, Komponente, Kategorie, Objekt.
|-
!Vererbung von Berechtigungen
|Berechtigungen können von übergeordneten Gruppen und übergeordneten Kategorien geerbt werden.
|}

===Wie die Berechtigungen funktionieren===

Es gibt vier mögliche Berechtigungen für Aktionen. Diese sind (kurz skizziert):

* '''Nicht gesetzt''': Fällt standardmäßig auf "Nicht erlaubt" zurück. Aber im Gegensatz zur Berechtigung "Verweigert" kann diese Berechtigung außer Kraft gesetzt werden, wenn eine untergeordnete Gruppe oder eine in der Berechtigungshierarchie untergeordnete Ebene auf "Erlaubt" gesetzt wird. Diese Berechtigung kann nur für globale Berechtigungen der Konfiguration gesetzt werden.
* '''Vererbt''': Erbt den Wert von einer übergeordneten Gruppe oder einer in der Berechtigungshierarchie höheren Ebene. Diese Berechtigung gilt für alle Ebenen mit Ausnahme der obersten Ebene der Konfiguration.
* '''Verweigert''': Verbietet diese Aktion für diese Ebene und Gruppe. '''WICHTIG:''' Dadurch wird diese Aktion auch für alle untergeordneten Gruppen und alle untergeordneten Ebenen in der Berechtigungshierarchie verboten. Wird "Erlaubt" in einer untergeordneten Gruppe oder einer tieferen Ebene gesetzt, hat das keinen Effekt. Die Aktion wird immer für alle Mitglieder einer untergeordneten Gruppe und für alle untergeordneten Ebenen in der Berechtigungshierarchie abgelehnt.
* '''Erlaubt ''': Genehmigt diese Aktion für diese Ebene und Gruppe und für tiefere Ebenen und Untergruppen. Dies hat keine Auswirkungen, wenn eine höhere Gruppe oder Ebene auf "Verweigert" oder "Erlaubt" eingestellt ist. Wenn eine höhere Gruppe oder ein höheres Ebene auf "Verweigert" gesetzt ist, wird diese Berechtigung immer abgelehnt. Wenn eine höhere Gruppe oder Ebene auf Erlaubt eingestellt ist, ist diese Berechtigung bereits erlaubt.

===Hierarchie der Berechtigungsebenen===

Berechtigungen für Aktionen können in Version 2.5+ auf bis zu vier Ebenen festgelegt werden, wie folgt:
# '''Konfiguration''': legt die Standardberechtigungen für jede Aktion und Gruppe fest.
# '''Komponenten-Optionen-> Berechtigungen''': kann die Standardberechtigungen für diese Komponente überschreiben (z. B. Beiträge, Menüs, Benutzer, Banner usw.).
# '''Kategorie''': kann die Standardberechtigungen für Objekte in einer oder mehreren Kategorien überschreiben. Gilt für alle Komponenten mit Kategorien, einschließlich Beiträge, Banner, Kontakte, Newsfeeds und Weblinks.
# '''Beitrag''': kann die Berechtigungen für einen bestimmten Artikel überschreiben. Diese Ebene gilt nur für Beiträge. Alle anderen Komponenten erlauben nur die ersten drei Ebenen.

====Konfiguration====
Diese erreicht man über System → Konfiguration → Berechtigungen. Die nun sichtbare Maske dient dazu, die Berechtigungen auf der obersten Ebene für jede Gruppe und jede Aktion festzulegen, wie auch in der folgenden Abbildung gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Die möglichen Werte sind Vererbt, Erlaubt oder Verweigert. Die Spalte 'Errechnete Einstellung' zeigt die aktuelle Einstellung an. Diese ist entweder Nicht erlaubt (Standard), Erlaubt oder Nicht erlaubt.

Man kann immer nur an einer Gruppe gleichzeitig arbeiten, indem man den Reiter für ebendiese Gruppe anklickt. Die Berechtigungen kann man über die Dropdownlisten unter Neue Einstellung wählen ändern.

Beachten Sie, dass die Spalte "Errechnete Einstellung" erst aktualisiert wird, wenn Sie auf die Schaltfläche "Speichern" in der Werkzeugleiste klicken.

Um zu überprüfen, ob die Einstellungen Ihren Wünschen entsprechen, klicken Sie auf die Schaltfläche Speichern und überprüfen anschließend die Spalte Errechnete Einstellung.

====Komponenten-Optionen->Berechtigungen====
Auf diese wird für jede Komponente durch Klicken auf das Symbol "Optionen" in der Werkzeugleiste zugegriffen. Dieser Bildschirm ist ähnlich wie der Bildschirm "Globale Konfiguration" oben links. Wenn Sie beispielsweise im Menü-Manager auf das Symbol in der Werkzeugleiste Optionen klicken, werden die folgenden Menüs angezeigt.
[[Image:Screenshot_menu_acl_J3_tutorial-en.jpg]]

Der Zugriff auf Optionen ist nur für Mitglieder von Gruppen möglich, die die Berechtigung für die Aktion Konfiguration in für jede Komponente haben. Im obigen Beispiel hat die Gruppe Administrator die Berechtigung Erlaubt für die Option Konfigurieren, so dass Mitglieder dieser Gruppe auf diesen Bildschirm zugreifen können.

===Kategorie===
Auf die Kategorieberechtigungen wird im Category Manager zugegriffen: Bildschirm Kategorie bearbeiten, in einer Registerkarte oben auf dem Bildschirm. Dieser Bildschirm hat fünf Berechtigungen, wie folgt:

[[Image:Screenshot_category_acl_j3_tutorial-en.png]]

In diesen Bildern bearbeiten Sie die Berechtigungen für jeweils eine Benutzergruppe. Im obigen Beispiel bearbeiten Sie die Berechtigungen für die Gruppe Administrator.

Achten Sie darauf, dass die Aktionen "Konfigurieren und Zugriffssteuerung" nicht auf der Kategorieebene angewendet werden, so dass diese Aktionen nicht enthalten sind.

Beachten Sie auch, dass Kategorien in einer Hierarchie angeordnet werden können. Wenn ja, dann werden Aktionsberechtigungen in einer übergeordneten Kategorie automatisch an eine untergeordnete Kategorie vererbt. Wenn Sie beispielsweise eine Kategoriehierarchie von Tieren → Haustiere → Hunde hätten, dann würde die vollständige Berechtigungshierarchie für einen Artikel in der Kategorie Hunde wie folgt aussehen:
* Globale Konfiguration
* Artikel-Manager → Optionen → Genehmigung → Erlaubnis
* Tierkategorie
* Kategorie Haustiere
* Kategorie Hunde
* spezifischer Artikel

====Beitrag====
Berechtigungen für einzelne Beiträge findet man im "Beitrag" unter dem Tab-Reiter "Berechigungen". Dieser Bildschirm hat drei Aktionen, wie unten gezeigt.

[[Image:j3x_acl_tutorial_article_manager_article_permissions-en.png]]

Auch hier bearbeiten Sie jede Gruppe für sich. Um auf die Berechtigungen zuzugreifen wechseln Sie im Artikel auf den Reiter "Berechtigungen" im oberen Reiter. Über das Drop Down Menü wählen Sie die neue Berechtigung im Anschluss speichern Sie den Beitrag ab.

Beachten Sie, dass die Aktionen Configure, Access Component und Create auf Artikelebene nicht gelten, so dass diese Aktionen nicht berücksichtigt werden. Die Berechtigung zum Anlegen eines Artikels wird auf einer der höheren Ebenen der Hierarchie festgelegt.

===Zugriffsebenen===

Die Zugriffsebenen der 3.x-Serie sind einfach und flexibel. Der folgende Bildschirm zeigt die spezielle Zugriffsebene.
[[Image:j3x_acl_tutorial_viewing_levels-en.png|center]]
Aktivieren Sie einfach das Kontrollkästchen für jede Gruppe, die Sie in diesem Level aufnehmen wollen. Die spezielle Zugriffsebene umfasst die Gruppen Manager, Autor und Superuser. Es beinhaltet auch untergeordnete Gruppen dieser Gruppen. Die Gruppe Administrator ist also enthalten, da es sich um eine Untergruppe der Gruppe Manager handelt. Die Gruppen Editor, Publisher und Shop Suppliers sind enthalten, da es sich um Untergruppen des Autors handelt.

Jedem Objekt im Frontend ist eine Zugriffsebene zugeordnet. Wenn die Ebene öffentlich ist, kann jeder auf dieses Objekt zugreifen. Andernfalls dürfen nur Mitglieder von Gruppen, die dieser Zugriffsebene zugeordnet sind, auf dieses Objekt zugreifen.

Die Zugriffsebenen sind den Menüpunkten und den Modulen zugeordnet. Jede kann nur einer Zugriffsebene zugeordnet werden.

Der folgende Bildschirm zeigt beispielsweise den Bildschirm Menüpunkt bearbeiten mit der Liste der verfügbaren Zugriffsebenen....

[[Image:j3x_acl_tutorial_edit_menu_item_level_dropdown-en.png|center]]

==Standard-ACL-Setup==

Wenn Joomla! installiert ist, werden diese auf die ursprünglichen Standardwerte gesetzt. Wir werden diese Grundeinstellungen besprechen, um die Arbeitsweise der ACL zu verstehen.

===Standardgruppen===

Mit der Version 3.x können Sie Ihre individuellen Gruppen definieren. Wenn Sie die Version 3.x installieren, enthält sie eine Reihe von Standardgruppen, die im Folgenden dargestellt werden, sind die grundlegenden Standardbenutzergruppen. (Zusätzliche Standardbenutzergruppen werden mit Beispieldaten installiert)

[[Image:Screenshot_usergroupsl_acl_J3_tutorial-en.png|center]]

Die Pfeile zeigen die untergeordneten Elternbeziehungen an. Wie vorstehend besprochen, wird diese Berechtigung, wenn Sie eine Berechtigung für eine übergeordnete Gruppe festlegen, automatisch an alle Untergruppen vererbt. Die vererbten und zulässigen Berechtigungen können für eine Untergruppe überschrieben werden. Die Berechtigung Verweigert kann nicht überschrieben werden und verweigert immer eine Aktion für alle Untergruppen.

===Konfiguration===

Joomla! Version 3.x wird mit den gleichen bekannten Backend-Rechten wie die Version 1.5 (EOL) installiert. Mit der Version 3.x können Sie diese jedoch leicht an die Bedürfnisse Ihrer Website anpassen.

Wie bereits besprochen, werden die Berechtigungen für jede Aktion von der obigen Ebene in der Berechtigungshierarchie und von der übergeordneten Gruppe einer Gruppe übernommen. Also, wie funktioniert das? Die oberste Ebene dafür ist der gesamte Standort. Dies wird in der Site->Globale Konfiguration->Berechtigungen eingerichtet, wie unten gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Das erste, was man bemerken sollte, sind die zehn Aktionen: Standortlogin, Admin-Login, Offline-Zugriff, Superuser, Access Administration Interface, Erstellen, Löschen, Bearbeiten, Status bearbeiten und Eigenes bearbeiten. Dies sind die Aktionen, die ein Benutzer an einem Objekt in Joomla durchführen kann. Die spezifische Bedeutung jeder Aktion hängt vom Kontext ab. Für das Bild Globale Konfiguration sind sie wie folgt definiert:

Site Login : Login to the front end of the site

;Admin Login : Melden Sie sich am Backend der Website an.

Offline-Zugriff: Melden Sie sich am Frontend der Website an, wenn die Website offline ist (wenn die globale Konfigurationseinstellung "Site Offline" auf Ja gesetzt ist).

Superuser: Gewährt dem Benutzer den Status "Superuser". Benutzer mit dieser Berechtigung dürfen alles auf der Website machen. Nur Benutzer mit dieser Berechtigung können die Einstellungen der globalen Konfiguration ändern. Diese Berechtigungen können nicht eingeschränkt werden. Es ist wichtig zu verstehen, dass, wenn ein Benutzer Mitglied einer Super Admin-Gruppe ist, alle anderen Berechtigungen, die diesem Benutzer zugewiesen sind, irrelevant sind. Der Benutzer kann jede Aktion auf der Website durchführen. Es können jedoch weiterhin Zugriffsebenen zugewiesen werden, um zu steuern, was diese Gruppe auf der Website sieht. (Natürlich kann ein Super-Admin-Benutzer die Zugriffsebenen ändern, wenn er möchte, so dass die Zugriffsebenen nicht vollständig einschränken, was ein Super-Admin-Benutzer sehen kann.)

Zugangskomponente: Öffnen Sie die Bildschirme der Komponentenverwaltung (Benutzerverwaltung, Menüverwaltung, Artikelverwaltung usw.).

;Create : Create new objects (for example, users, menu items, articles, weblinks, and so on)

;Löschen : Löschen eines existienden Objekts

;Ändern : Ändern eines existierenden Objektes

;Ändern eines Objekt Status (Veröffentlicht, nicht Veröffentlicht, Archiviert und Gelöscht)

Eigene Objekte bearbeiten: Bearbeiten Sie Objekte, die Sie erstellt haben.

Each Group for the site has its own slider which is opened by clicking on the group name. In this case (with the sample data installed), we have the standard 7 groups that we had in version 1.5 plus two additional groups called "Shop Suppliers" and "Customer Group". Notice that our groups are set up with the same permissions as they had in version 1.5. Keep in mind that we can change any of these permissions to make the security work the way we want. Let's go through this to see how it works.

* '''Public''' has everything set to "Not set", as shown below.{{-}}[[Image:Screenshot_global_acl_public_J3_tutorial-en.png]]
**This can be a bit confusing. Basically, "Not Set" is the same as "Inherited". Because Public is our top-level group, and because Global Configuration is the top level of the component hierarchy, there is nothing to inherit from. So "Not Set" is used instead of "Inherit".
**The default in this case is for no permissions. So, as you would expect, the Public group has no special permissions. Also, it is important to note that, since nothing is set to Denied, all of these permissions may be overridden by child groups or by lower levels in the permission hierarchy.

* '''Guest''' is a 'child' group of the Public group has everything set to 'Inherited' {{-}}[[Image:Screenshot_global_acl_guest_J3_tutorial-de.png]]
** This is the default 'Guest User Group' in the User Manager options and the Group that (non logged in) visitors to your site are placed in.

* '''Manager''' is a "child" group of the Public group. It has Allowed permissions for everything except Access Component and Super Admin. So a member of this group can do everything in the front and back end of the site except change Global Permissions and Component Options. {{-}}[[Image:Screenshot_global_acl_manager_J3_tutorial-en.png]]

* '''Administrator''' group members inherit all of the Manager permissions and also have Allowed for Access Component. So members of this group by default can access the Options screens for each component. {{-}}[[Image:Screenshot_global_acl_administrator_J3_tutorial-en.png]]

* '''Registered''' is the same a Public except for the Allow permission for the Site Login action. This means that members of the Registered group can login to the site. Since default permissions are inherited, this means that, unless a child group overrides this permission, all child groups of the Registered group will be able to login as well. {{-}}[[Image:Screenshot_global_acl_registered_J3_tutorial-en.png]]

* '''Author''' is a child of the Registered group and inherits its permissions and also adds Create and Edit Own. Since Author, Editor, and Publisher have no back-end permissions, we will discuss them below, when we discuss front-end permissions.{{-}}[[Image:Screenshot_global_acl_author_J3_tutorial-en.png]]

* '''Editor''' is a child of the Authors group and adds the Edit permission. {{-}}[[Image:Screenshot_global_acl_editor_J3_tutorial-en.png]]

* '''Publisher''' is a child of Editor and adds the Edit State permission.{{-}}[[Image:Screenshot_global_acl_publisher_J3_tutorial-en.png]]

* '''Shop Suppliers''' is an example group that is installed if you install the sample data. It is a child group of Author.

* '''Customer Group''' is an example group that is installed if you install the sample data. It is a child group of Registered.

* '''Super Users''' group has the Allow permission for the Super Admin action. Because of this, members of this group have super user permissions throughout the site. They are the only users who can access and edit values on the Global Configuration screen. Users with permission for the Super Admin action have some special characteristics:
:* If a user has Super Admin permissions, no other permissions for this user matter. The user can perform any action on the site.
:* Only Super Admin users can create, edit, or delete other Super Admin users or groups.

There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.

This provides a lot of flexibility. For example, if you wanted Shop Suppliers to be able to have the ability to login to the back end, you could just change their Admin Login value to "Allowed". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherited (or Denied).

It is also important to understand that the ability to have child groups is completely optional. It allows you to save some time when setting up new groups. However, if you like, you can set up all groups to have Public as the parent and not inherit any permissions from a parent group.

===Komponenten-Optionen & Berechtigungen===

Now, let's continue to see how the default back-end permissions for version 2.5 mimic the permissions for version 1.5. The Super Users group in 2.5 is equivalent to the Super Administrator group in 1.5.

Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 2.5 configuration. Let's see how this is accomplished.

If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:

[[Image:screenshot_acl_tutorial_20110111-09-en.png|center|]]
[[Image:screenshot_acl_tutorial_20110111-10-en.png|center|]]

This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.

First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.

Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.

If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.

In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.

It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.

===Frontend Berechtigungen===

Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions. First, let's look at the permissions for Manager, as shown below.
[[Image:screenshot_acl_tutorial_20110111-11a-en.png|center|frame]]
Manager has allowed permission for all actions except Configure. So members of the Manager group can do everything with Articles except open the Options screen.

Now let's look at Administrator, as shown below.
[[Image:screenshot_acl_tutorial_20110111-12a-en.png|center|frame]]
Administrator has Allowed for Configure, so Administrators can edit this Options screen.

Both groups can create, delete, edit, and change the state of articles.

Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set.

Authors only have Create and Edit Own permissions, as shown below.
[[Image:screenshot_acl_tutorial_20110112-07-en.png|center|frame]]
This means that Authors can create articles and can edit articles they have created. They may not delete articles, change the published state of articles, or edit articles created by others.

Editors have the same permissions as Authors with the addition of permission for the Edit action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-08-en.png|center|frame]]
So Editors can edit articles written by anyone.

Publishers can do everything Editors can do plus they have permission for the Edit State action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-09-en.png|center|frame]]
So Publishers can change the published state of an article. The possible states include Published, Unpublished, Archived, and Trashed.

All of these groups have Inherit permission for Configure and Access Component. Remember that Author is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Configure and Access Component, and since Author's permission for these actions is "Inherited", then Author does not have these permissions either. This same permission is passed from Author to Editor and from Editor to Publisher. So, by default, none of these groups are allowed to work with articles in the back end.

It is important to remember that these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.

Beachte auch das in den ursprünglichen Standardwerten keine Berechtigungen auf Verweigert eingestellt sind. Dies ermöglicht in allen Berechtigungsebenen die jeweilige Berechtigung auf Erlaubt einzustellen. Bedenke, wenn eine Aktion auf Verweigert eingestellt ist, das diese Aktion auch in allen untergeordneten Ebenen in der Berechtigungshierarchie verweigert wird. Zum Beispiel, wenn die Seitenameldung für Registered auf Verweigert (anstatt auf Erlaubt) eingestellt wird, kann man Publishers diese Aktion per Berechtigungeinstellung nicht erteilen.

=== Beitrags-Manager & Aktions-Diagramm ===

The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.

[[Image:screenshot_acl_tutorial_20110111-16-en.png|center|]]

* '''Configure''' allows you to view and change the Options for the component.
* '''Access Component''' allows you to navigate to the Article Manager. Without this permission, no other actions are possible.
* '''Create''' allows you to add new articles.
* '''Delete''' allows you to delete trashed articles. Note that the Delete icon only shows in the toolbar when you have the "Select State" filter set to "Trash".
* '''Edit''' allows you to edit existing articles.
* '''Edit State''' allows to you Publish, Unpublish, Archive, or Trash articles.
* '''Edit Own''' is the same as Edit except that it only applies to articles written by you.

==Allowing Guest-Only Access to Menu Items and Modules==

Version 1.6 introduced the ability to create a View Access Level that is only for guests of the site (meaning a user who is not logged in). The example below shows how you can set up this new feature.
''(N.B. Steps 1 to 3 are not needed for Joomla! 3.x as they exist in the default install)''

#Create a new user group called Guest. Make it a child of the Public group as shown below. [[Image:screenshot_acl_tutorial_20110112-01-en.png|center|frame]]
# Create a new access level called Guest and grant only the Guest group access to this level, as shown below.[[Image:screenshot_acl_tutorial_20110112-02-en.png|center|frame]]
# Navigate to User Manager→Options→Component and change the Guest User Group from the default value of "Public" to "Guest", as shown below.
[[Image:screenshot_acl_tutorial_20110112-04-en.png|center|frame]]
Now, if we assign a menu item, module, or other object to the Guest access level, only non-logged in users will have access. For example, if we create a new menu item with access level of Guest, as shown below,
[[Image:screenshot_acl_tutorial_20110112-05-de.png|center|frame]]
this menu item will only be visible to non-logged-in visitors to the site.

If required other user groups like Author can be granted access in the Guest access level, this would allow Authors to view articles in the front end for editing.

'''N.B. Login/logout in front end (''for changing data in session'') to see the change.'''

==Berechtigungen und Gruppenebenen gemeinsam nutzen==

As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.

This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:

* both groups can create new articles only in the History Assignments category.

* only History Teachers (not Assistant History Teachers) can Publish or otherwise have Edit State permission.

This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.

[[Image:Acl example diagram1 20091018-de.png|center|]]

In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.

To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.

Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.

[[Image:Acl example diagram2 20091018-de.png|center|]]

This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.

Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.

==ACL Aktion Berechtigungs-Beispiele==

===Backend Beitrag Administrator===

'''Problem:'''

We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.

'''Lösung:'''

# Create a new group called Article Administrator and make its parent group Public, as shown below.[[Image:screenshot_acl_tutorial_20110112-10-de.png|center|frame]] Because its parent group is Public, it won't have any permissions by default.
# In Users → Access Levels, edit the Special Access level to add the new group. That way they can get access to the back end menu items and modules (This assumes that the modules for the admin menu and quickicons have the Special Access level assigned to them, which is the default.) [[Image:screenshot_acl_tutorial_20110112-11-de.png|center|frame]] By default, the back-end menu items and modules are set to Special access, so if you forget to add the new group to the Special access level, you won't see any modules or menu items when you log in as a user of the new group.
# In Site → Global Configuration → Permissions, click on the Article Administrator group and change the permissions to Allowed for the following actions: Admin Login, Create, Delete, Edit, Edit State, and Edit Own. The screen below shows what will show before you press Save. [[Image:screenshot_acl_tutorial_20110112-12-de.png|center|frame]]After you save, the Calculated Permissions should show as shown below.[[Image:screenshot_acl_tutorial_20110112-13-de.png|center|frame]]Note that the permission for the Access Component is Inherited, which translates to Not Allowed. This is important. This means that this group will only be able to access components if we give the group "Allowed" permission for Access Component. So we only have to change the one component we want to give them access to and don't have to change any settings for the components where we don't want them to have access. If we had a case where we wanted to give a group access to everything except for one component, we could set the default to Allowed and then set the one component to Denied. Also note that we did not give the group Site Login permission, so users in this group will not be able to log into the front end. (If we wanted to allow that, we would just change the permission to Allowed for Site Login.)
# In Article Manager → Options → Permissions, change permissions to Allowed for this group for the Access Component action, as shown below.[[Image:screenshot_acl_tutorial_20110112-14-de.png|center|frame]]All of the other desired permissions are inherited.

That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end. For example, the screen below shows what a user in the Article Manager will see when they login to the back end.[[Image:screenshot_acl_tutorial_20110112-15-de.png|center|frame]]

==ACL Ansicht Zugriffsebenen-Beispiele==

A basic concept of using Access Levels is that all items with the same Access will be viewable by the same group of users. In other words, if two items have the same Access, you can't have one viewable by one user and not viewable by another user. On the other hand, it is easy to have one Group view any number of items with different Access levels.

Similarly, each Group has exactly the same combination of Access levels, but one User can be a member of more than one group. Depending on the situation, you may want to have users only in one Group or you may need to have a User in more than one Group.

This means that we may need to group our items so that items so that all items in a group have the same level of sensitivity. Here are some examples.

===Hierarchisches Beispiel===
In this example, Access levels are hierarchical, for example, like government security clearance codes. Say for example we have the following sets of classified documents: Classified, Secret, and Top Secret. Users have corresponding clearence codes. Users with Classified clearance can only see Classified documents and cannot see Secret or Top Secret. Users with Secret clearance can see Classified and Secret documents but not Top Secret. Users with Top Secret can see all documents.

In this case, you would create three Access levels: Classified, Secret, and Top Secret and the same three Groups. Users would only be members of one group, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| C1, C2, C3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Classified
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| S1, S2, S3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| TS1, TS2, TS3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Top Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret, Top Secret

|}

In this case, all users are in exactly one group, but some groups have access to more than one Access Level of items. In other words, we have a one-to-one relationship between users and groups, but a one-to-many relationship between Groups and Access Levels.

===Teamsicherheit Beispiel===

Another possible use case is a set of non-hierarchical teams. Let's say we have three teams, T1, T2, and T3. Some users are only on one team, but others might be on two or more teams. In this case, we could set up our Access Levels and Groups by team. Documents for each team have the access level for that team, and the Group for the team has only the one access level. When a User is on more than one team, they get added to the group for each team, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Beschreibung
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 1 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 2 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 3 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1, 2 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1,T2, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2, T3

|}

===Hybrid Example===

In a real-world situation, you might have a combination of these two arrangements. Say for example we have Managers and Staff. Staff can only see Staff documents and Managers can see Manager and Staff documents. Both types of users can be assigned to teams as well, in which case they can see all of the documents for that team. In addition, say that Managers can access some, but not all, team documents. Staff can only access team documents if they are members of that team.

In this example, we could set up the following Access Levels:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Access Level
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Description
| style="border:0.0007in solid #000000;padding:0.0382in;"| Groups

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team manager documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team staff documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team1 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1, Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team2 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2, Manager

|}

Then, users could be assigned to groups as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| User Type
| style="border:0.0007in solid #000000;padding:0.0382in;"| Group

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1, Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1, Team2

|}

<noinclude>
[[Category:Joomla! 1.6]]
[[Category:Joomla! 2.5]]
[[Category:Joomla! 3.x/de]]
[[Category:Tutorials/de]]
[[Category:Access Control/de]]
[[Category:Access Management]]
</noinclude>

Translations:J3.x:Access Control List Tutorial/171/de

2019-12-26T19:05:37Z

Sieger66:

J3.x:Access Control List Tutorial/de

2019-12-26T19:05:30Z

Sieger66:

<noinclude><languages /></noinclude>
{{Joomla version|version=3.x|comment=Serie}}
{{-}}
{{:J3.1:Access_Control_List/en}}

==Separate ACL für Anzeige und Aktionen==

Das Joomla ACL-System besteht genau genommen aus zwei völlig getrennten Systemen. Das eine System steuert, was Benutzer auf der Website "sehen" können. Das andere steuert, was Benutzer "tun" können (welche Aktionen ein Benutzer durchführen kann). Die ACL wird für jedes dieser Systeme anders eingerichtet.

===Steuern, was Benutzer sehen können===

Das Setup zum Steuern, was Benutzer sehen können, sieht wie folgt aus:
*Eine Reihe von Zugriffsebenen gemäß den Kategorien und/oder der Kombination von Kategorien erstellen, die nur angemeldete Benutzer sehen sollen. Anmerkung: Zu diesem Zeitpunkt werden noch keine Benutzergruppen den neuen Zugriffsebenen zugewiesen.

*Für jede Zugriffsebene eine Benutzergruppe erstellen, die 'Registriert' als übergeordnete Gruppe hat. Indem man für Benutzergruppen und Zugriffsebenen die gleichen Namen verwendet, kann man Verwirrungen zu einem späteren Zeitpunkt vorbeugen.

*Die neuen Zugriffsebenen bearbeiten und jeder die (neue) Benutzergruppe zuweisen. Wahrscheinlich möchten man auch die 'Super Benutzer' Gruppe (und/oder die anderen Standard-Benutzergruppen mit Ausnahme der Benutzergruppe 'Gast') den neuen Zugriffsebenen zuweisen.

*Jedem anzuzeigenden Eintrag eine Zugriffsebene zuweisen. Einträge sind sowohl inhaltliche Einträge (Beiträge, Kontakte, usw.), Menüeinträge als auch Module.

Immer dann, wenn ein Benutzer im Begriff ist, einen Eintrag auf einer Joomla-Seite anzeigen zu lassen, prüft das Programm, ob dieser Benutzer auch Zugriff auf den Eintrag hat. Das geschieht folgendermaßen:
# Zunächst wird eine Liste aller Zugriffsebenen erstellt, auf die der Benutzer zugreifen kann, basierend auf allen Gruppen, denen der Benutzer angehört. Sofern eine Gruppe eine übergeordnete Gruppe besitzt, sind die Zugriffsebenen für die übergeordnete Gruppe ebenfalls in der Liste enthalten.
# Danach wird überprüft, ob die Zugriffsebene für den Eintrag (Beitrag, Modul, Menüeintrag, usw.) in dieser Liste enthalten ist. Wenn dem so ist, wird der Eintrag dem Benutzer angezeigt. Falls der Benutzer die benötigten Zugriffsrechte besitzt, wird ihm der Zugriff verweigert.

Beachten, dass Zugriffsebenen für jede Gruppe separat festgelegt und nicht von der übergeordneten Gruppe einer Gruppe vererbt werden.

===Steuern, was Benutzer tun können===

Das System, das steuert, was Benutzer in einer Benutzergruppe tun können - welche Aktionen sie bei einem bestimmten Eintrag ausführen können - wird über den Tab 'Berechtigungen' in der Konfiguration und den Tab 'Berechtigungen' in den Optionen jeder einzelnen Komponente eingerichtet. Berechtigungen können auch auf Kategorienebene (bei Kernkomponenten) und auf Beitragsebene (bei Beiträgen) gesetzt werden.

* Wenn angemeldete Benutzer in bestimmten Kategorien Erstellen, Löschen, Status bearbeiten oder Eigene Inhalte bearbeiten dürfen, dann:
** Eine Benutzergruppe erstellen und als übergeordnete Gruppe eine der Benutzergruppen angeben, die Zugriff auf die Kategorie (oder Kategorien) haben, die diese neue Benutzergruppe ändern soll.
**Der neuen Benutzergruppe den entsprechenden Zugriffsebenen zuweisen. Dann die erforderlichen Berechtigungen für die neue Benutzergruppe entweder global oder pro Kategorie/Beitrag ändern.
*** Beim Erstellen einer Benutzergruppe ist es ratsam, eine übergeordnete Gruppe zu wählen, die über weniger Berechtigungen verfügt, als für die neue Gruppe erforderlich. Denn es ist einfacher, die Berechtigungen für jede Komponente/Kategorie/Beitrag zu erweitern, für die zusätzliche Berechtigungen nötig sind, als Berechtigungen aus den anderen Komponenten/Kategorien/Beiträgen zu entfernen.
****''(Beispiel: Es gibt 10 Kategorien, man möchte aber nur für eine Erstellen-Berechtigungen. Würde man für diese Gruppe die Berechtigungen global auf Erstellen erlaubt setzen, müsste man für diese Kategorien die Erstellen-Berechtigung entfernen. Und man müsste für diese Gruppe die Erstellen-Berechtigung bei jeder neuen Kategorie, die man zu einem späteren Zeitpunkt hinzufügt, ebenfalls entfernen).''
** Eine Benutzergruppe erstellen, die eine der Standardbenutzergruppen als übergeordnete Gruppe hat, NUR, wenn keine von diesen über die exakten Berechtigungen verfügt, die man benötigt und sich für alle Kategorien wünscht.

Beachten, dass dieses Setup unabhängig vom Setup für die Anzeige ist. Allerdings muss eine Benutzergruppe den entsprechenden Zugriffsebenen zugewiesen werden, damit der Benutzer in dieser Gruppe jene Berechtigungen verwenden kann.

Möchte ein Benutzer eine bestimmte Aktion bei einem Komponenten-Eintrag durchführen (z. B. einen Beitrag bearbeiten), überprüft das System (nachdem es überprüft hat, welcher Gruppe der Benutzer angehört und auf welche er Zugriff hat) die Berechtigung für diese Kombination aus Benutzer, Eintrag und Aktion. Liegt eine Erlaubnis vor, kann der Benutzer fortfahren. Andernfalls ist die Aktion nicht zulässig.

Das restliche Tutorial befasst sich mit der Steuerung, was Benutzer tun können - welche Aktionsberechtigungen sie haben.

==Aktionen, Gruppen und Vererbung==

Andererseits geht es bei der ACL auch darum, Benutzern Berechtigungen zu erteilen, damit diese Aktionen an Objekten durchführen können.

{| class="wikitable"
!style="width:20%;"|
!3.x Serie
|-
!Gruppen und Aktionen
|Aktionen, welche pro Gruppe erlaubt sind, werden durch den Website Administrator festgelegt.
|-
!Umfang von Berechtigungen
|Berechtigungen können auf mehreren Ebenen in der Hierarchie festgelegt werden: Website, Komponente, Kategorie, Objekt.
|-
!Vererbung von Berechtigungen
|Berechtigungen können von übergeordneten Gruppen und übergeordneten Kategorien geerbt werden.
|}

===Wie die Berechtigungen funktionieren===

Es gibt vier mögliche Berechtigungen für Aktionen. Diese sind (kurz skizziert):

* '''Nicht gesetzt''': Fällt standardmäßig auf "Nicht erlaubt" zurück. Aber im Gegensatz zur Berechtigung "Verweigert" kann diese Berechtigung außer Kraft gesetzt werden, wenn eine untergeordnete Gruppe oder eine in der Berechtigungshierarchie untergeordnete Ebene auf "Erlaubt" gesetzt wird. Diese Berechtigung kann nur für globale Berechtigungen der Konfiguration gesetzt werden.
* '''Vererbt''': Erbt den Wert von einer übergeordneten Gruppe oder einer in der Berechtigungshierarchie höheren Ebene. Diese Berechtigung gilt für alle Ebenen mit Ausnahme der obersten Ebene der Konfiguration.
* '''Verweigert''': Verbietet diese Aktion für diese Ebene und Gruppe. '''WICHTIG:''' Dadurch wird diese Aktion auch für alle untergeordneten Gruppen und alle untergeordneten Ebenen in der Berechtigungshierarchie verboten. Wird "Erlaubt" in einer untergeordneten Gruppe oder einer tieferen Ebene gesetzt, hat das keinen Effekt. Die Aktion wird immer für alle Mitglieder einer untergeordneten Gruppe und für alle untergeordneten Ebenen in der Berechtigungshierarchie abgelehnt.
* '''Erlaubt ''': Genehmigt diese Aktion für diese Ebene und Gruppe und für tiefere Ebenen und Untergruppen. Dies hat keine Auswirkungen, wenn eine höhere Gruppe oder Ebene auf "Verweigert" oder "Erlaubt" eingestellt ist. Wenn eine höhere Gruppe oder ein höheres Ebene auf "Verweigert" gesetzt ist, wird diese Berechtigung immer abgelehnt. Wenn eine höhere Gruppe oder Ebene auf Erlaubt eingestellt ist, ist diese Berechtigung bereits erlaubt.

===Hierarchie der Berechtigungsebenen===

Berechtigungen für Aktionen können in Version 2.5+ auf bis zu vier Ebenen festgelegt werden, wie folgt:
# '''Konfiguration''': legt die Standardberechtigungen für jede Aktion und Gruppe fest.
# '''Komponenten-Optionen-> Berechtigungen''': kann die Standardberechtigungen für diese Komponente überschreiben (z. B. Beiträge, Menüs, Benutzer, Banner usw.).
# '''Kategorie''': kann die Standardberechtigungen für Objekte in einer oder mehreren Kategorien überschreiben. Gilt für alle Komponenten mit Kategorien, einschließlich Beiträge, Banner, Kontakte, Newsfeeds und Weblinks.
# '''Beitrag''': kann die Berechtigungen für einen bestimmten Artikel überschreiben. Diese Ebene gilt nur für Beiträge. Alle anderen Komponenten erlauben nur die ersten drei Ebenen.

====Konfiguration====
Diese erreicht man über System → Konfiguration → Berechtigungen. Die nun sichtbare Maske dient dazu, die Berechtigungen auf der obersten Ebene für jede Gruppe und jede Aktion festzulegen, wie auch in der folgenden Abbildung gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Die möglichen Werte sind Vererbt, Erlaubt oder Verweigert. Die Spalte 'Errechnete Einstellung' zeigt die aktuelle Einstellung an. Diese ist entweder Nicht erlaubt (Standard), Erlaubt oder Nicht erlaubt.

Man kann immer nur an einer Gruppe gleichzeitig arbeiten, indem man den Reiter für ebendiese Gruppe anklickt. Die Berechtigungen kann man über die Dropdownlisten unter Neue Einstellung wählen ändern.

Beachten Sie, dass die Spalte "Errechnete Einstellung" erst aktualisiert wird, wenn Sie auf die Schaltfläche "Speichern" in der Werkzeugleiste klicken.

Um zu überprüfen, ob die Einstellungen Ihren Wünschen entsprechen, klicken Sie auf die Schaltfläche Speichern und überprüfen anschließend die Spalte Errechnete Einstellung.

====Komponenten-Optionen->Berechtigungen====
Auf diese wird für jede Komponente durch Klicken auf das Symbol "Optionen" in der Werkzeugleiste zugegriffen. Dieser Bildschirm ist ähnlich wie der Bildschirm "Globale Konfiguration" oben links. Wenn Sie beispielsweise im Menü-Manager auf das Symbol in der Werkzeugleiste Optionen klicken, werden die folgenden Menüs angezeigt.
[[Image:Screenshot_menu_acl_J3_tutorial-en.jpg]]

Der Zugriff auf Optionen ist nur für Mitglieder von Gruppen möglich, die die Berechtigung für die Aktion Konfiguration in für jede Komponente haben. Im obigen Beispiel hat die Gruppe Administrator die Berechtigung Erlaubt für die Option Konfigurieren, so dass Mitglieder dieser Gruppe auf diesen Bildschirm zugreifen können.

===Kategorie===
Auf die Kategorieberechtigungen wird im Category Manager zugegriffen: Bildschirm Kategorie bearbeiten, in einer Registerkarte oben auf dem Bildschirm. Dieser Bildschirm hat fünf Berechtigungen, wie folgt:

[[Image:Screenshot_category_acl_j3_tutorial-en.png]]

In diesen Bildern bearbeiten Sie die Berechtigungen für jeweils eine Benutzergruppe. Im obigen Beispiel bearbeiten Sie die Berechtigungen für die Gruppe Administrator.

Achten Sie darauf, dass die Aktionen "Konfigurieren und Zugriffssteuerung" nicht auf der Kategorieebene angewendet werden, so dass diese Aktionen nicht enthalten sind.

Beachten Sie auch, dass Kategorien in einer Hierarchie angeordnet werden können. Wenn ja, dann werden Aktionsberechtigungen in einer übergeordneten Kategorie automatisch an eine untergeordnete Kategorie vererbt. Wenn Sie beispielsweise eine Kategoriehierarchie von Tieren → Haustiere → Hunde hätten, dann würde die vollständige Berechtigungshierarchie für einen Artikel in der Kategorie Hunde wie folgt aussehen:
* Globale Konfiguration
* Artikel-Manager → Optionen → Genehmigung → Erlaubnis
* Tierkategorie
* Kategorie Haustiere
* Kategorie Hunde
* spezifischer Artikel

====Beitrag====
Berechtigungen für einzelne Beiträge findet man im "Beitrag" unter dem Tab-Reiter "Berechigungen". Dieser Bildschirm hat drei Aktionen, wie unten gezeigt.

[[Image:j3x_acl_tutorial_article_manager_article_permissions-en.png]]

Auch hier bearbeiten Sie jede Gruppe für sich. Um auf die Berechtigungen zuzugreifen wechseln Sie im Artikel auf den Reiter "Berechtigungen" im oberen Reiter. Über das Drop Down Menü wählen Sie die neue Berechtigung im Anschluss speichern Sie den Beitrag ab.

Beachten Sie, dass die Aktionen Configure, Access Component und Create auf Artikelebene nicht gelten, so dass diese Aktionen nicht berücksichtigt werden. Die Berechtigung zum Anlegen eines Artikels wird auf einer der höheren Ebenen der Hierarchie festgelegt.

===Zugriffsebenen===

Die Zugriffsebenen der 3.x-Serie sind einfach und flexibel. Der folgende Bildschirm zeigt die spezielle Zugriffsebene.
[[Image:j3x_acl_tutorial_viewing_levels-en.png|center]]
Aktivieren Sie einfach das Kontrollkästchen für jede Gruppe, die Sie in diesem Level aufnehmen wollen. Die spezielle Zugriffsebene umfasst die Gruppen Manager, Autor und Superuser. Es beinhaltet auch untergeordnete Gruppen dieser Gruppen. Die Gruppe Administrator ist also enthalten, da es sich um eine Untergruppe der Gruppe Manager handelt. Die Gruppen Editor, Publisher und Shop Suppliers sind enthalten, da es sich um Untergruppen des Autors handelt.

Jedem Objekt im Frontend ist eine Zugriffsebene zugeordnet. Wenn die Ebene öffentlich ist, kann jeder auf dieses Objekt zugreifen. Andernfalls dürfen nur Mitglieder von Gruppen, die dieser Zugriffsebene zugeordnet sind, auf dieses Objekt zugreifen.

Die Zugriffsebenen sind den Menüpunkten und den Modulen zugeordnet. Jede kann nur einer Zugriffsebene zugeordnet werden.

Der folgende Bildschirm zeigt beispielsweise den Bildschirm Menüpunkt bearbeiten mit der Liste der verfügbaren Zugriffsebenen....

[[Image:j3x_acl_tutorial_edit_menu_item_level_dropdown-en.png|center]]

==Standard-ACL-Setup==

Wenn Joomla! installiert ist, werden diese auf die ursprünglichen Standardwerte gesetzt. Wir werden diese Grundeinstellungen besprechen, um die Arbeitsweise der ACL zu verstehen.

===Standardgruppen===

Mit der Version 3.x können Sie Ihre individuellen Gruppen definieren. Wenn Sie die Version 3.x installieren, enthält sie eine Reihe von Standardgruppen, die im Folgenden dargestellt werden, sind die grundlegenden Standardbenutzergruppen. (Zusätzliche Standardbenutzergruppen werden mit Beispieldaten installiert)

[[Image:Screenshot_usergroupsl_acl_J3_tutorial-en.png|center]]

Die Pfeile zeigen die untergeordneten Elternbeziehungen an. Wie vorstehend besprochen, wird diese Berechtigung, wenn Sie eine Berechtigung für eine übergeordnete Gruppe festlegen, automatisch an alle Untergruppen vererbt. Die vererbten und zulässigen Berechtigungen können für eine Untergruppe überschrieben werden. Die Berechtigung Verweigert kann nicht überschrieben werden und verweigert immer eine Aktion für alle Untergruppen.

===Konfiguration===

Joomla! Version 3.x wird mit den gleichen bekannten Backend-Rechten wie die Version 1.5 (EOL) installiert. Mit der Version 3.x können Sie diese jedoch leicht an die Bedürfnisse Ihrer Website anpassen.

Wie bereits besprochen, werden die Berechtigungen für jede Aktion von der obigen Ebene in der Berechtigungshierarchie und von der übergeordneten Gruppe einer Gruppe übernommen. Also, wie funktioniert das? Die oberste Ebene dafür ist der gesamte Standort. Dies wird in der Site->Globale Konfiguration->Berechtigungen eingerichtet, wie unten gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Das erste, was man bemerken sollte, sind die zehn Aktionen: Standortlogin, Admin-Login, Offline-Zugriff, Superuser, Access Administration Interface, Erstellen, Löschen, Bearbeiten, Status bearbeiten und Eigenes bearbeiten. Dies sind die Aktionen, die ein Benutzer an einem Objekt in Joomla durchführen kann. Die spezifische Bedeutung jeder Aktion hängt vom Kontext ab. Für das Bild Globale Konfiguration sind sie wie folgt definiert:

Site Login : Login to the front end of the site

;Admin Login : Melden Sie sich am Backend der Website an.

Offline-Zugriff: Melden Sie sich am Frontend der Website an, wenn die Website offline ist (wenn die globale Konfigurationseinstellung "Site Offline" auf Ja gesetzt ist).

Superuser: Gewährt dem Benutzer den Status "Superuser". Benutzer mit dieser Berechtigung dürfen alles auf der Website machen. Nur Benutzer mit dieser Berechtigung können die Einstellungen der globalen Konfiguration ändern. Diese Berechtigungen können nicht eingeschränkt werden. Es ist wichtig zu verstehen, dass, wenn ein Benutzer Mitglied einer Super Admin-Gruppe ist, alle anderen Berechtigungen, die diesem Benutzer zugewiesen sind, irrelevant sind. Der Benutzer kann jede Aktion auf der Website durchführen. Es können jedoch weiterhin Zugriffsebenen zugewiesen werden, um zu steuern, was diese Gruppe auf der Website sieht. (Natürlich kann ein Super-Admin-Benutzer die Zugriffsebenen ändern, wenn er möchte, so dass die Zugriffsebenen nicht vollständig einschränken, was ein Super-Admin-Benutzer sehen kann.)

Zugangskomponente: Öffnen Sie die Bildschirme der Komponentenverwaltung (Benutzerverwaltung, Menüverwaltung, Artikelverwaltung usw.).

;Create : Create new objects (for example, users, menu items, articles, weblinks, and so on)

;Löschen : Löschen eines existienden Objekts

;Ändern : Ändern eines existierenden Objektes

;Ändern eines Objekt Status (Veröffentlicht, nicht Veröffentlicht, Archiviert und Gelöscht)

Eigene Objekte bearbeiten: Bearbeiten Sie Objekte, die Sie erstellt haben.

Each Group for the site has its own slider which is opened by clicking on the group name. In this case (with the sample data installed), we have the standard 7 groups that we had in version 1.5 plus two additional groups called "Shop Suppliers" and "Customer Group". Notice that our groups are set up with the same permissions as they had in version 1.5. Keep in mind that we can change any of these permissions to make the security work the way we want. Let's go through this to see how it works.

* '''Public''' has everything set to "Not set", as shown below.{{-}}[[Image:Screenshot_global_acl_public_J3_tutorial-en.png]]
**This can be a bit confusing. Basically, "Not Set" is the same as "Inherited". Because Public is our top-level group, and because Global Configuration is the top level of the component hierarchy, there is nothing to inherit from. So "Not Set" is used instead of "Inherit".
**The default in this case is for no permissions. So, as you would expect, the Public group has no special permissions. Also, it is important to note that, since nothing is set to Denied, all of these permissions may be overridden by child groups or by lower levels in the permission hierarchy.

* '''Guest''' is a 'child' group of the Public group has everything set to 'Inherited' {{-}}[[Image:Screenshot_global_acl_guest_J3_tutorial-de.png]]
** This is the default 'Guest User Group' in the User Manager options and the Group that (non logged in) visitors to your site are placed in.

* '''Manager''' is a "child" group of the Public group. It has Allowed permissions for everything except Access Component and Super Admin. So a member of this group can do everything in the front and back end of the site except change Global Permissions and Component Options. {{-}}[[Image:Screenshot_global_acl_manager_J3_tutorial-en.png]]

* '''Administrator''' group members inherit all of the Manager permissions and also have Allowed for Access Component. So members of this group by default can access the Options screens for each component. {{-}}[[Image:Screenshot_global_acl_administrator_J3_tutorial-en.png]]

* '''Registered''' is the same a Public except for the Allow permission for the Site Login action. This means that members of the Registered group can login to the site. Since default permissions are inherited, this means that, unless a child group overrides this permission, all child groups of the Registered group will be able to login as well. {{-}}[[Image:Screenshot_global_acl_registered_J3_tutorial-en.png]]

* '''Author''' is a child of the Registered group and inherits its permissions and also adds Create and Edit Own. Since Author, Editor, and Publisher have no back-end permissions, we will discuss them below, when we discuss front-end permissions.{{-}}[[Image:Screenshot_global_acl_author_J3_tutorial-en.png]]

* '''Editor''' is a child of the Authors group and adds the Edit permission. {{-}}[[Image:Screenshot_global_acl_editor_J3_tutorial-en.png]]

* '''Publisher''' is a child of Editor and adds the Edit State permission.{{-}}[[Image:Screenshot_global_acl_publisher_J3_tutorial-en.png]]

* '''Shop Suppliers''' is an example group that is installed if you install the sample data. It is a child group of Author.

* '''Customer Group''' is an example group that is installed if you install the sample data. It is a child group of Registered.

* '''Super Users''' group has the Allow permission for the Super Admin action. Because of this, members of this group have super user permissions throughout the site. They are the only users who can access and edit values on the Global Configuration screen. Users with permission for the Super Admin action have some special characteristics:
:* If a user has Super Admin permissions, no other permissions for this user matter. The user can perform any action on the site.
:* Only Super Admin users can create, edit, or delete other Super Admin users or groups.

There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.

This provides a lot of flexibility. For example, if you wanted Shop Suppliers to be able to have the ability to login to the back end, you could just change their Admin Login value to "Allowed". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherited (or Denied).

It is also important to understand that the ability to have child groups is completely optional. It allows you to save some time when setting up new groups. However, if you like, you can set up all groups to have Public as the parent and not inherit any permissions from a parent group.

===Komponenten-Optionen & Berechtigungen===

Now, let's continue to see how the default back-end permissions for version 2.5 mimic the permissions for version 1.5. The Super Users group in 2.5 is equivalent to the Super Administrator group in 1.5.

Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 2.5 configuration. Let's see how this is accomplished.

If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:

[[Image:screenshot_acl_tutorial_20110111-09-en.png|center|]]
[[Image:screenshot_acl_tutorial_20110111-10-en.png|center|]]

This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.

First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.

Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.

If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.

In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.

It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.

===Frontend Berechtigungen===

Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions. First, let's look at the permissions for Manager, as shown below.
[[Image:screenshot_acl_tutorial_20110111-11a-en.png|center|frame]]
Manager has allowed permission for all actions except Configure. So members of the Manager group can do everything with Articles except open the Options screen.

Now let's look at Administrator, as shown below.
[[Image:screenshot_acl_tutorial_20110111-12a-en.png|center|frame]]
Administrator has Allowed for Configure, so Administrators can edit this Options screen.

Both groups can create, delete, edit, and change the state of articles.

Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set.

Authors only have Create and Edit Own permissions, as shown below.
[[Image:screenshot_acl_tutorial_20110112-07-en.png|center|frame]]
This means that Authors can create articles and can edit articles they have created. They may not delete articles, change the published state of articles, or edit articles created by others.

Editors have the same permissions as Authors with the addition of permission for the Edit action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-08-en.png|center|frame]]
So Editors can edit articles written by anyone.

Publishers can do everything Editors can do plus they have permission for the Edit State action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-09-en.png|center|frame]]
So Publishers can change the published state of an article. The possible states include Published, Unpublished, Archived, and Trashed.

All of these groups have Inherit permission for Configure and Access Component. Remember that Author is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Configure and Access Component, and since Author's permission for these actions is "Inherited", then Author does not have these permissions either. This same permission is passed from Author to Editor and from Editor to Publisher. So, by default, none of these groups are allowed to work with articles in the back end.

It is important to remember that these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.

Beachte auch das in den ursprünglichen Standardwerten keine Berechtigungen auf Verweigert eingestellt sind. Dies ermöglicht in allen Berechtigungsebenen die jeweilige Berechtigung auf Erlaubt einzustellen. Bedenke, wenn eine Aktion auf Verweigert eingestellt ist, das diese Aktion auch in allen untergeordneten Ebenen in der Berechtigungshierarchie verweigert wird. Zum Beispiel, wenn die Seitenameldung für Registered auf Verweigert (anstatt auf Erlaubt) eingestellt wird, kann man Publishers diese Aktion per Berechtigungeinstellung nicht erteilen.

=== Beitrags-Manager & Aktions-Diagramm ===

The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.

[[Image:screenshot_acl_tutorial_20110111-16-en.png|center|]]

* '''Configure''' allows you to view and change the Options for the component.
* '''Access Component''' allows you to navigate to the Article Manager. Without this permission, no other actions are possible.
* '''Create''' allows you to add new articles.
* '''Delete''' allows you to delete trashed articles. Note that the Delete icon only shows in the toolbar when you have the "Select State" filter set to "Trash".
* '''Edit''' allows you to edit existing articles.
* '''Edit State''' allows to you Publish, Unpublish, Archive, or Trash articles.
* '''Edit Own''' is the same as Edit except that it only applies to articles written by you.

==Allowing Guest-Only Access to Menu Items and Modules==

Version 1.6 introduced the ability to create a View Access Level that is only for guests of the site (meaning a user who is not logged in). The example below shows how you can set up this new feature.
''(N.B. Steps 1 to 3 are not needed for Joomla! 3.x as they exist in the default install)''

#Create a new user group called Guest. Make it a child of the Public group as shown below. [[Image:screenshot_acl_tutorial_20110112-01-en.png|center|frame]]
# Create a new access level called Guest and grant only the Guest group access to this level, as shown below.[[Image:screenshot_acl_tutorial_20110112-02-en.png|center|frame]]
# Navigate to User Manager→Options→Component and change the Guest User Group from the default value of "Public" to "Guest", as shown below.
[[Image:screenshot_acl_tutorial_20110112-04-de.png|center|frame]]
Now, if we assign a menu item, module, or other object to the Guest access level, only non-logged in users will have access. For example, if we create a new menu item with access level of Guest, as shown below,
[[Image:screenshot_acl_tutorial_20110112-05-de.png|center|frame]]
this menu item will only be visible to non-logged-in visitors to the site.

If required other user groups like Author can be granted access in the Guest access level, this would allow Authors to view articles in the front end for editing.

'''N.B. Login/logout in front end (''for changing data in session'') to see the change.'''

==Berechtigungen und Gruppenebenen gemeinsam nutzen==

As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.

This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:

* both groups can create new articles only in the History Assignments category.

* only History Teachers (not Assistant History Teachers) can Publish or otherwise have Edit State permission.

This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.

[[Image:Acl example diagram1 20091018-de.png|center|]]

In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.

To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.

Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.

[[Image:Acl example diagram2 20091018-de.png|center|]]

This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.

Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.

==ACL Aktion Berechtigungs-Beispiele==

===Backend Beitrag Administrator===

'''Problem:'''

We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.

'''Lösung:'''

# Create a new group called Article Administrator and make its parent group Public, as shown below.[[Image:screenshot_acl_tutorial_20110112-10-de.png|center|frame]] Because its parent group is Public, it won't have any permissions by default.
# In Users → Access Levels, edit the Special Access level to add the new group. That way they can get access to the back end menu items and modules (This assumes that the modules for the admin menu and quickicons have the Special Access level assigned to them, which is the default.) [[Image:screenshot_acl_tutorial_20110112-11-de.png|center|frame]] By default, the back-end menu items and modules are set to Special access, so if you forget to add the new group to the Special access level, you won't see any modules or menu items when you log in as a user of the new group.
# In Site → Global Configuration → Permissions, click on the Article Administrator group and change the permissions to Allowed for the following actions: Admin Login, Create, Delete, Edit, Edit State, and Edit Own. The screen below shows what will show before you press Save. [[Image:screenshot_acl_tutorial_20110112-12-de.png|center|frame]]After you save, the Calculated Permissions should show as shown below.[[Image:screenshot_acl_tutorial_20110112-13-de.png|center|frame]]Note that the permission for the Access Component is Inherited, which translates to Not Allowed. This is important. This means that this group will only be able to access components if we give the group "Allowed" permission for Access Component. So we only have to change the one component we want to give them access to and don't have to change any settings for the components where we don't want them to have access. If we had a case where we wanted to give a group access to everything except for one component, we could set the default to Allowed and then set the one component to Denied. Also note that we did not give the group Site Login permission, so users in this group will not be able to log into the front end. (If we wanted to allow that, we would just change the permission to Allowed for Site Login.)
# In Article Manager → Options → Permissions, change permissions to Allowed for this group for the Access Component action, as shown below.[[Image:screenshot_acl_tutorial_20110112-14-de.png|center|frame]]All of the other desired permissions are inherited.

That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end. For example, the screen below shows what a user in the Article Manager will see when they login to the back end.[[Image:screenshot_acl_tutorial_20110112-15-de.png|center|frame]]

==ACL Ansicht Zugriffsebenen-Beispiele==

A basic concept of using Access Levels is that all items with the same Access will be viewable by the same group of users. In other words, if two items have the same Access, you can't have one viewable by one user and not viewable by another user. On the other hand, it is easy to have one Group view any number of items with different Access levels.

Similarly, each Group has exactly the same combination of Access levels, but one User can be a member of more than one group. Depending on the situation, you may want to have users only in one Group or you may need to have a User in more than one Group.

This means that we may need to group our items so that items so that all items in a group have the same level of sensitivity. Here are some examples.

===Hierarchisches Beispiel===
In this example, Access levels are hierarchical, for example, like government security clearance codes. Say for example we have the following sets of classified documents: Classified, Secret, and Top Secret. Users have corresponding clearence codes. Users with Classified clearance can only see Classified documents and cannot see Secret or Top Secret. Users with Secret clearance can see Classified and Secret documents but not Top Secret. Users with Top Secret can see all documents.

In this case, you would create three Access levels: Classified, Secret, and Top Secret and the same three Groups. Users would only be members of one group, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| C1, C2, C3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Classified
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| S1, S2, S3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| TS1, TS2, TS3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Top Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret, Top Secret

|}

In this case, all users are in exactly one group, but some groups have access to more than one Access Level of items. In other words, we have a one-to-one relationship between users and groups, but a one-to-many relationship between Groups and Access Levels.

===Teamsicherheit Beispiel===

Another possible use case is a set of non-hierarchical teams. Let's say we have three teams, T1, T2, and T3. Some users are only on one team, but others might be on two or more teams. In this case, we could set up our Access Levels and Groups by team. Documents for each team have the access level for that team, and the Group for the team has only the one access level. When a User is on more than one team, they get added to the group for each team, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Beschreibung
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 1 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 2 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 3 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1, 2 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1,T2, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2, T3

|}

===Hybrid Example===

In a real-world situation, you might have a combination of these two arrangements. Say for example we have Managers and Staff. Staff can only see Staff documents and Managers can see Manager and Staff documents. Both types of users can be assigned to teams as well, in which case they can see all of the documents for that team. In addition, say that Managers can access some, but not all, team documents. Staff can only access team documents if they are members of that team.

In this example, we could set up the following Access Levels:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Access Level
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Description
| style="border:0.0007in solid #000000;padding:0.0382in;"| Groups

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team manager documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team staff documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team1 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1, Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team2 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2, Manager

|}

Then, users could be assigned to groups as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| User Type
| style="border:0.0007in solid #000000;padding:0.0382in;"| Group

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1, Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1, Team2

|}

<noinclude>
[[Category:Joomla! 1.6]]
[[Category:Joomla! 2.5]]
[[Category:Joomla! 3.x/de]]
[[Category:Tutorials/de]]
[[Category:Access Control/de]]
[[Category:Access Management]]
</noinclude>

Translations:J3.x:Access Control List Tutorial/169/de

2019-12-26T19:05:29Z

Sieger66:

J3.x:Access Control List Tutorial/de

2019-12-26T19:05:16Z

Sieger66:

<noinclude><languages /></noinclude>
{{Joomla version|version=3.x|comment=Serie}}
{{-}}
{{:J3.1:Access_Control_List/en}}

==Separate ACL für Anzeige und Aktionen==

Das Joomla ACL-System besteht genau genommen aus zwei völlig getrennten Systemen. Das eine System steuert, was Benutzer auf der Website "sehen" können. Das andere steuert, was Benutzer "tun" können (welche Aktionen ein Benutzer durchführen kann). Die ACL wird für jedes dieser Systeme anders eingerichtet.

===Steuern, was Benutzer sehen können===

Das Setup zum Steuern, was Benutzer sehen können, sieht wie folgt aus:
*Eine Reihe von Zugriffsebenen gemäß den Kategorien und/oder der Kombination von Kategorien erstellen, die nur angemeldete Benutzer sehen sollen. Anmerkung: Zu diesem Zeitpunkt werden noch keine Benutzergruppen den neuen Zugriffsebenen zugewiesen.

*Für jede Zugriffsebene eine Benutzergruppe erstellen, die 'Registriert' als übergeordnete Gruppe hat. Indem man für Benutzergruppen und Zugriffsebenen die gleichen Namen verwendet, kann man Verwirrungen zu einem späteren Zeitpunkt vorbeugen.

*Die neuen Zugriffsebenen bearbeiten und jeder die (neue) Benutzergruppe zuweisen. Wahrscheinlich möchten man auch die 'Super Benutzer' Gruppe (und/oder die anderen Standard-Benutzergruppen mit Ausnahme der Benutzergruppe 'Gast') den neuen Zugriffsebenen zuweisen.

*Jedem anzuzeigenden Eintrag eine Zugriffsebene zuweisen. Einträge sind sowohl inhaltliche Einträge (Beiträge, Kontakte, usw.), Menüeinträge als auch Module.

Immer dann, wenn ein Benutzer im Begriff ist, einen Eintrag auf einer Joomla-Seite anzeigen zu lassen, prüft das Programm, ob dieser Benutzer auch Zugriff auf den Eintrag hat. Das geschieht folgendermaßen:
# Zunächst wird eine Liste aller Zugriffsebenen erstellt, auf die der Benutzer zugreifen kann, basierend auf allen Gruppen, denen der Benutzer angehört. Sofern eine Gruppe eine übergeordnete Gruppe besitzt, sind die Zugriffsebenen für die übergeordnete Gruppe ebenfalls in der Liste enthalten.
# Danach wird überprüft, ob die Zugriffsebene für den Eintrag (Beitrag, Modul, Menüeintrag, usw.) in dieser Liste enthalten ist. Wenn dem so ist, wird der Eintrag dem Benutzer angezeigt. Falls der Benutzer die benötigten Zugriffsrechte besitzt, wird ihm der Zugriff verweigert.

Beachten, dass Zugriffsebenen für jede Gruppe separat festgelegt und nicht von der übergeordneten Gruppe einer Gruppe vererbt werden.

===Steuern, was Benutzer tun können===

Das System, das steuert, was Benutzer in einer Benutzergruppe tun können - welche Aktionen sie bei einem bestimmten Eintrag ausführen können - wird über den Tab 'Berechtigungen' in der Konfiguration und den Tab 'Berechtigungen' in den Optionen jeder einzelnen Komponente eingerichtet. Berechtigungen können auch auf Kategorienebene (bei Kernkomponenten) und auf Beitragsebene (bei Beiträgen) gesetzt werden.

* Wenn angemeldete Benutzer in bestimmten Kategorien Erstellen, Löschen, Status bearbeiten oder Eigene Inhalte bearbeiten dürfen, dann:
** Eine Benutzergruppe erstellen und als übergeordnete Gruppe eine der Benutzergruppen angeben, die Zugriff auf die Kategorie (oder Kategorien) haben, die diese neue Benutzergruppe ändern soll.
**Der neuen Benutzergruppe den entsprechenden Zugriffsebenen zuweisen. Dann die erforderlichen Berechtigungen für die neue Benutzergruppe entweder global oder pro Kategorie/Beitrag ändern.
*** Beim Erstellen einer Benutzergruppe ist es ratsam, eine übergeordnete Gruppe zu wählen, die über weniger Berechtigungen verfügt, als für die neue Gruppe erforderlich. Denn es ist einfacher, die Berechtigungen für jede Komponente/Kategorie/Beitrag zu erweitern, für die zusätzliche Berechtigungen nötig sind, als Berechtigungen aus den anderen Komponenten/Kategorien/Beiträgen zu entfernen.
****''(Beispiel: Es gibt 10 Kategorien, man möchte aber nur für eine Erstellen-Berechtigungen. Würde man für diese Gruppe die Berechtigungen global auf Erstellen erlaubt setzen, müsste man für diese Kategorien die Erstellen-Berechtigung entfernen. Und man müsste für diese Gruppe die Erstellen-Berechtigung bei jeder neuen Kategorie, die man zu einem späteren Zeitpunkt hinzufügt, ebenfalls entfernen).''
** Eine Benutzergruppe erstellen, die eine der Standardbenutzergruppen als übergeordnete Gruppe hat, NUR, wenn keine von diesen über die exakten Berechtigungen verfügt, die man benötigt und sich für alle Kategorien wünscht.

Beachten, dass dieses Setup unabhängig vom Setup für die Anzeige ist. Allerdings muss eine Benutzergruppe den entsprechenden Zugriffsebenen zugewiesen werden, damit der Benutzer in dieser Gruppe jene Berechtigungen verwenden kann.

Möchte ein Benutzer eine bestimmte Aktion bei einem Komponenten-Eintrag durchführen (z. B. einen Beitrag bearbeiten), überprüft das System (nachdem es überprüft hat, welcher Gruppe der Benutzer angehört und auf welche er Zugriff hat) die Berechtigung für diese Kombination aus Benutzer, Eintrag und Aktion. Liegt eine Erlaubnis vor, kann der Benutzer fortfahren. Andernfalls ist die Aktion nicht zulässig.

Das restliche Tutorial befasst sich mit der Steuerung, was Benutzer tun können - welche Aktionsberechtigungen sie haben.

==Aktionen, Gruppen und Vererbung==

Andererseits geht es bei der ACL auch darum, Benutzern Berechtigungen zu erteilen, damit diese Aktionen an Objekten durchführen können.

{| class="wikitable"
!style="width:20%;"|
!3.x Serie
|-
!Gruppen und Aktionen
|Aktionen, welche pro Gruppe erlaubt sind, werden durch den Website Administrator festgelegt.
|-
!Umfang von Berechtigungen
|Berechtigungen können auf mehreren Ebenen in der Hierarchie festgelegt werden: Website, Komponente, Kategorie, Objekt.
|-
!Vererbung von Berechtigungen
|Berechtigungen können von übergeordneten Gruppen und übergeordneten Kategorien geerbt werden.
|}

===Wie die Berechtigungen funktionieren===

Es gibt vier mögliche Berechtigungen für Aktionen. Diese sind (kurz skizziert):

* '''Nicht gesetzt''': Fällt standardmäßig auf "Nicht erlaubt" zurück. Aber im Gegensatz zur Berechtigung "Verweigert" kann diese Berechtigung außer Kraft gesetzt werden, wenn eine untergeordnete Gruppe oder eine in der Berechtigungshierarchie untergeordnete Ebene auf "Erlaubt" gesetzt wird. Diese Berechtigung kann nur für globale Berechtigungen der Konfiguration gesetzt werden.
* '''Vererbt''': Erbt den Wert von einer übergeordneten Gruppe oder einer in der Berechtigungshierarchie höheren Ebene. Diese Berechtigung gilt für alle Ebenen mit Ausnahme der obersten Ebene der Konfiguration.
* '''Verweigert''': Verbietet diese Aktion für diese Ebene und Gruppe. '''WICHTIG:''' Dadurch wird diese Aktion auch für alle untergeordneten Gruppen und alle untergeordneten Ebenen in der Berechtigungshierarchie verboten. Wird "Erlaubt" in einer untergeordneten Gruppe oder einer tieferen Ebene gesetzt, hat das keinen Effekt. Die Aktion wird immer für alle Mitglieder einer untergeordneten Gruppe und für alle untergeordneten Ebenen in der Berechtigungshierarchie abgelehnt.
* '''Erlaubt ''': Genehmigt diese Aktion für diese Ebene und Gruppe und für tiefere Ebenen und Untergruppen. Dies hat keine Auswirkungen, wenn eine höhere Gruppe oder Ebene auf "Verweigert" oder "Erlaubt" eingestellt ist. Wenn eine höhere Gruppe oder ein höheres Ebene auf "Verweigert" gesetzt ist, wird diese Berechtigung immer abgelehnt. Wenn eine höhere Gruppe oder Ebene auf Erlaubt eingestellt ist, ist diese Berechtigung bereits erlaubt.

===Hierarchie der Berechtigungsebenen===

Berechtigungen für Aktionen können in Version 2.5+ auf bis zu vier Ebenen festgelegt werden, wie folgt:
# '''Konfiguration''': legt die Standardberechtigungen für jede Aktion und Gruppe fest.
# '''Komponenten-Optionen-> Berechtigungen''': kann die Standardberechtigungen für diese Komponente überschreiben (z. B. Beiträge, Menüs, Benutzer, Banner usw.).
# '''Kategorie''': kann die Standardberechtigungen für Objekte in einer oder mehreren Kategorien überschreiben. Gilt für alle Komponenten mit Kategorien, einschließlich Beiträge, Banner, Kontakte, Newsfeeds und Weblinks.
# '''Beitrag''': kann die Berechtigungen für einen bestimmten Artikel überschreiben. Diese Ebene gilt nur für Beiträge. Alle anderen Komponenten erlauben nur die ersten drei Ebenen.

====Konfiguration====
Diese erreicht man über System → Konfiguration → Berechtigungen. Die nun sichtbare Maske dient dazu, die Berechtigungen auf der obersten Ebene für jede Gruppe und jede Aktion festzulegen, wie auch in der folgenden Abbildung gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Die möglichen Werte sind Vererbt, Erlaubt oder Verweigert. Die Spalte 'Errechnete Einstellung' zeigt die aktuelle Einstellung an. Diese ist entweder Nicht erlaubt (Standard), Erlaubt oder Nicht erlaubt.

Man kann immer nur an einer Gruppe gleichzeitig arbeiten, indem man den Reiter für ebendiese Gruppe anklickt. Die Berechtigungen kann man über die Dropdownlisten unter Neue Einstellung wählen ändern.

Beachten Sie, dass die Spalte "Errechnete Einstellung" erst aktualisiert wird, wenn Sie auf die Schaltfläche "Speichern" in der Werkzeugleiste klicken.

Um zu überprüfen, ob die Einstellungen Ihren Wünschen entsprechen, klicken Sie auf die Schaltfläche Speichern und überprüfen anschließend die Spalte Errechnete Einstellung.

====Komponenten-Optionen->Berechtigungen====
Auf diese wird für jede Komponente durch Klicken auf das Symbol "Optionen" in der Werkzeugleiste zugegriffen. Dieser Bildschirm ist ähnlich wie der Bildschirm "Globale Konfiguration" oben links. Wenn Sie beispielsweise im Menü-Manager auf das Symbol in der Werkzeugleiste Optionen klicken, werden die folgenden Menüs angezeigt.
[[Image:Screenshot_menu_acl_J3_tutorial-en.jpg]]

Der Zugriff auf Optionen ist nur für Mitglieder von Gruppen möglich, die die Berechtigung für die Aktion Konfiguration in für jede Komponente haben. Im obigen Beispiel hat die Gruppe Administrator die Berechtigung Erlaubt für die Option Konfigurieren, so dass Mitglieder dieser Gruppe auf diesen Bildschirm zugreifen können.

===Kategorie===
Auf die Kategorieberechtigungen wird im Category Manager zugegriffen: Bildschirm Kategorie bearbeiten, in einer Registerkarte oben auf dem Bildschirm. Dieser Bildschirm hat fünf Berechtigungen, wie folgt:

[[Image:Screenshot_category_acl_j3_tutorial-en.png]]

In diesen Bildern bearbeiten Sie die Berechtigungen für jeweils eine Benutzergruppe. Im obigen Beispiel bearbeiten Sie die Berechtigungen für die Gruppe Administrator.

Achten Sie darauf, dass die Aktionen "Konfigurieren und Zugriffssteuerung" nicht auf der Kategorieebene angewendet werden, so dass diese Aktionen nicht enthalten sind.

Beachten Sie auch, dass Kategorien in einer Hierarchie angeordnet werden können. Wenn ja, dann werden Aktionsberechtigungen in einer übergeordneten Kategorie automatisch an eine untergeordnete Kategorie vererbt. Wenn Sie beispielsweise eine Kategoriehierarchie von Tieren → Haustiere → Hunde hätten, dann würde die vollständige Berechtigungshierarchie für einen Artikel in der Kategorie Hunde wie folgt aussehen:
* Globale Konfiguration
* Artikel-Manager → Optionen → Genehmigung → Erlaubnis
* Tierkategorie
* Kategorie Haustiere
* Kategorie Hunde
* spezifischer Artikel

====Beitrag====
Berechtigungen für einzelne Beiträge findet man im "Beitrag" unter dem Tab-Reiter "Berechigungen". Dieser Bildschirm hat drei Aktionen, wie unten gezeigt.

[[Image:j3x_acl_tutorial_article_manager_article_permissions-en.png]]

Auch hier bearbeiten Sie jede Gruppe für sich. Um auf die Berechtigungen zuzugreifen wechseln Sie im Artikel auf den Reiter "Berechtigungen" im oberen Reiter. Über das Drop Down Menü wählen Sie die neue Berechtigung im Anschluss speichern Sie den Beitrag ab.

Beachten Sie, dass die Aktionen Configure, Access Component und Create auf Artikelebene nicht gelten, so dass diese Aktionen nicht berücksichtigt werden. Die Berechtigung zum Anlegen eines Artikels wird auf einer der höheren Ebenen der Hierarchie festgelegt.

===Zugriffsebenen===

Die Zugriffsebenen der 3.x-Serie sind einfach und flexibel. Der folgende Bildschirm zeigt die spezielle Zugriffsebene.
[[Image:j3x_acl_tutorial_viewing_levels-en.png|center]]
Aktivieren Sie einfach das Kontrollkästchen für jede Gruppe, die Sie in diesem Level aufnehmen wollen. Die spezielle Zugriffsebene umfasst die Gruppen Manager, Autor und Superuser. Es beinhaltet auch untergeordnete Gruppen dieser Gruppen. Die Gruppe Administrator ist also enthalten, da es sich um eine Untergruppe der Gruppe Manager handelt. Die Gruppen Editor, Publisher und Shop Suppliers sind enthalten, da es sich um Untergruppen des Autors handelt.

Jedem Objekt im Frontend ist eine Zugriffsebene zugeordnet. Wenn die Ebene öffentlich ist, kann jeder auf dieses Objekt zugreifen. Andernfalls dürfen nur Mitglieder von Gruppen, die dieser Zugriffsebene zugeordnet sind, auf dieses Objekt zugreifen.

Die Zugriffsebenen sind den Menüpunkten und den Modulen zugeordnet. Jede kann nur einer Zugriffsebene zugeordnet werden.

Der folgende Bildschirm zeigt beispielsweise den Bildschirm Menüpunkt bearbeiten mit der Liste der verfügbaren Zugriffsebenen....

[[Image:j3x_acl_tutorial_edit_menu_item_level_dropdown-en.png|center]]

==Standard-ACL-Setup==

Wenn Joomla! installiert ist, werden diese auf die ursprünglichen Standardwerte gesetzt. Wir werden diese Grundeinstellungen besprechen, um die Arbeitsweise der ACL zu verstehen.

===Standardgruppen===

Mit der Version 3.x können Sie Ihre individuellen Gruppen definieren. Wenn Sie die Version 3.x installieren, enthält sie eine Reihe von Standardgruppen, die im Folgenden dargestellt werden, sind die grundlegenden Standardbenutzergruppen. (Zusätzliche Standardbenutzergruppen werden mit Beispieldaten installiert)

[[Image:Screenshot_usergroupsl_acl_J3_tutorial-en.png|center]]

Die Pfeile zeigen die untergeordneten Elternbeziehungen an. Wie vorstehend besprochen, wird diese Berechtigung, wenn Sie eine Berechtigung für eine übergeordnete Gruppe festlegen, automatisch an alle Untergruppen vererbt. Die vererbten und zulässigen Berechtigungen können für eine Untergruppe überschrieben werden. Die Berechtigung Verweigert kann nicht überschrieben werden und verweigert immer eine Aktion für alle Untergruppen.

===Konfiguration===

Joomla! Version 3.x wird mit den gleichen bekannten Backend-Rechten wie die Version 1.5 (EOL) installiert. Mit der Version 3.x können Sie diese jedoch leicht an die Bedürfnisse Ihrer Website anpassen.

Wie bereits besprochen, werden die Berechtigungen für jede Aktion von der obigen Ebene in der Berechtigungshierarchie und von der übergeordneten Gruppe einer Gruppe übernommen. Also, wie funktioniert das? Die oberste Ebene dafür ist der gesamte Standort. Dies wird in der Site->Globale Konfiguration->Berechtigungen eingerichtet, wie unten gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Das erste, was man bemerken sollte, sind die zehn Aktionen: Standortlogin, Admin-Login, Offline-Zugriff, Superuser, Access Administration Interface, Erstellen, Löschen, Bearbeiten, Status bearbeiten und Eigenes bearbeiten. Dies sind die Aktionen, die ein Benutzer an einem Objekt in Joomla durchführen kann. Die spezifische Bedeutung jeder Aktion hängt vom Kontext ab. Für das Bild Globale Konfiguration sind sie wie folgt definiert:

Site Login : Login to the front end of the site

;Admin Login : Melden Sie sich am Backend der Website an.

Offline-Zugriff: Melden Sie sich am Frontend der Website an, wenn die Website offline ist (wenn die globale Konfigurationseinstellung "Site Offline" auf Ja gesetzt ist).

Superuser: Gewährt dem Benutzer den Status "Superuser". Benutzer mit dieser Berechtigung dürfen alles auf der Website machen. Nur Benutzer mit dieser Berechtigung können die Einstellungen der globalen Konfiguration ändern. Diese Berechtigungen können nicht eingeschränkt werden. Es ist wichtig zu verstehen, dass, wenn ein Benutzer Mitglied einer Super Admin-Gruppe ist, alle anderen Berechtigungen, die diesem Benutzer zugewiesen sind, irrelevant sind. Der Benutzer kann jede Aktion auf der Website durchführen. Es können jedoch weiterhin Zugriffsebenen zugewiesen werden, um zu steuern, was diese Gruppe auf der Website sieht. (Natürlich kann ein Super-Admin-Benutzer die Zugriffsebenen ändern, wenn er möchte, so dass die Zugriffsebenen nicht vollständig einschränken, was ein Super-Admin-Benutzer sehen kann.)

Zugangskomponente: Öffnen Sie die Bildschirme der Komponentenverwaltung (Benutzerverwaltung, Menüverwaltung, Artikelverwaltung usw.).

;Create : Create new objects (for example, users, menu items, articles, weblinks, and so on)

;Löschen : Löschen eines existienden Objekts

;Ändern : Ändern eines existierenden Objektes

;Ändern eines Objekt Status (Veröffentlicht, nicht Veröffentlicht, Archiviert und Gelöscht)

Eigene Objekte bearbeiten: Bearbeiten Sie Objekte, die Sie erstellt haben.

Each Group for the site has its own slider which is opened by clicking on the group name. In this case (with the sample data installed), we have the standard 7 groups that we had in version 1.5 plus two additional groups called "Shop Suppliers" and "Customer Group". Notice that our groups are set up with the same permissions as they had in version 1.5. Keep in mind that we can change any of these permissions to make the security work the way we want. Let's go through this to see how it works.

* '''Public''' has everything set to "Not set", as shown below.{{-}}[[Image:Screenshot_global_acl_public_J3_tutorial-en.png]]
**This can be a bit confusing. Basically, "Not Set" is the same as "Inherited". Because Public is our top-level group, and because Global Configuration is the top level of the component hierarchy, there is nothing to inherit from. So "Not Set" is used instead of "Inherit".
**The default in this case is for no permissions. So, as you would expect, the Public group has no special permissions. Also, it is important to note that, since nothing is set to Denied, all of these permissions may be overridden by child groups or by lower levels in the permission hierarchy.

* '''Guest''' is a 'child' group of the Public group has everything set to 'Inherited' {{-}}[[Image:Screenshot_global_acl_guest_J3_tutorial-de.png]]
** This is the default 'Guest User Group' in the User Manager options and the Group that (non logged in) visitors to your site are placed in.

* '''Manager''' is a "child" group of the Public group. It has Allowed permissions for everything except Access Component and Super Admin. So a member of this group can do everything in the front and back end of the site except change Global Permissions and Component Options. {{-}}[[Image:Screenshot_global_acl_manager_J3_tutorial-en.png]]

* '''Administrator''' group members inherit all of the Manager permissions and also have Allowed for Access Component. So members of this group by default can access the Options screens for each component. {{-}}[[Image:Screenshot_global_acl_administrator_J3_tutorial-en.png]]

* '''Registered''' is the same a Public except for the Allow permission for the Site Login action. This means that members of the Registered group can login to the site. Since default permissions are inherited, this means that, unless a child group overrides this permission, all child groups of the Registered group will be able to login as well. {{-}}[[Image:Screenshot_global_acl_registered_J3_tutorial-en.png]]

* '''Author''' is a child of the Registered group and inherits its permissions and also adds Create and Edit Own. Since Author, Editor, and Publisher have no back-end permissions, we will discuss them below, when we discuss front-end permissions.{{-}}[[Image:Screenshot_global_acl_author_J3_tutorial-en.png]]

* '''Editor''' is a child of the Authors group and adds the Edit permission. {{-}}[[Image:Screenshot_global_acl_editor_J3_tutorial-en.png]]

* '''Publisher''' is a child of Editor and adds the Edit State permission.{{-}}[[Image:Screenshot_global_acl_publisher_J3_tutorial-en.png]]

* '''Shop Suppliers''' is an example group that is installed if you install the sample data. It is a child group of Author.

* '''Customer Group''' is an example group that is installed if you install the sample data. It is a child group of Registered.

* '''Super Users''' group has the Allow permission for the Super Admin action. Because of this, members of this group have super user permissions throughout the site. They are the only users who can access and edit values on the Global Configuration screen. Users with permission for the Super Admin action have some special characteristics:
:* If a user has Super Admin permissions, no other permissions for this user matter. The user can perform any action on the site.
:* Only Super Admin users can create, edit, or delete other Super Admin users or groups.

There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.

This provides a lot of flexibility. For example, if you wanted Shop Suppliers to be able to have the ability to login to the back end, you could just change their Admin Login value to "Allowed". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherited (or Denied).

It is also important to understand that the ability to have child groups is completely optional. It allows you to save some time when setting up new groups. However, if you like, you can set up all groups to have Public as the parent and not inherit any permissions from a parent group.

===Komponenten-Optionen & Berechtigungen===

Now, let's continue to see how the default back-end permissions for version 2.5 mimic the permissions for version 1.5. The Super Users group in 2.5 is equivalent to the Super Administrator group in 1.5.

Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 2.5 configuration. Let's see how this is accomplished.

If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:

[[Image:screenshot_acl_tutorial_20110111-09-en.png|center|]]
[[Image:screenshot_acl_tutorial_20110111-10-en.png|center|]]

This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.

First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.

Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.

If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.

In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.

It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.

===Frontend Berechtigungen===

Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions. First, let's look at the permissions for Manager, as shown below.
[[Image:screenshot_acl_tutorial_20110111-11a-en.png|center|frame]]
Manager has allowed permission for all actions except Configure. So members of the Manager group can do everything with Articles except open the Options screen.

Now let's look at Administrator, as shown below.
[[Image:screenshot_acl_tutorial_20110111-12a-en.png|center|frame]]
Administrator has Allowed for Configure, so Administrators can edit this Options screen.

Both groups can create, delete, edit, and change the state of articles.

Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set.

Authors only have Create and Edit Own permissions, as shown below.
[[Image:screenshot_acl_tutorial_20110112-07-en.png|center|frame]]
This means that Authors can create articles and can edit articles they have created. They may not delete articles, change the published state of articles, or edit articles created by others.

Editors have the same permissions as Authors with the addition of permission for the Edit action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-08-en.png|center|frame]]
So Editors can edit articles written by anyone.

Publishers can do everything Editors can do plus they have permission for the Edit State action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-09-en.png|center|frame]]
So Publishers can change the published state of an article. The possible states include Published, Unpublished, Archived, and Trashed.

All of these groups have Inherit permission for Configure and Access Component. Remember that Author is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Configure and Access Component, and since Author's permission for these actions is "Inherited", then Author does not have these permissions either. This same permission is passed from Author to Editor and from Editor to Publisher. So, by default, none of these groups are allowed to work with articles in the back end.

It is important to remember that these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.

Beachte auch das in den ursprünglichen Standardwerten keine Berechtigungen auf Verweigert eingestellt sind. Dies ermöglicht in allen Berechtigungsebenen die jeweilige Berechtigung auf Erlaubt einzustellen. Bedenke, wenn eine Aktion auf Verweigert eingestellt ist, das diese Aktion auch in allen untergeordneten Ebenen in der Berechtigungshierarchie verweigert wird. Zum Beispiel, wenn die Seitenameldung für Registered auf Verweigert (anstatt auf Erlaubt) eingestellt wird, kann man Publishers diese Aktion per Berechtigungeinstellung nicht erteilen.

=== Beitrags-Manager & Aktions-Diagramm ===

The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.

[[Image:screenshot_acl_tutorial_20110111-16-en.png|center|]]

* '''Configure''' allows you to view and change the Options for the component.
* '''Access Component''' allows you to navigate to the Article Manager. Without this permission, no other actions are possible.
* '''Create''' allows you to add new articles.
* '''Delete''' allows you to delete trashed articles. Note that the Delete icon only shows in the toolbar when you have the "Select State" filter set to "Trash".
* '''Edit''' allows you to edit existing articles.
* '''Edit State''' allows to you Publish, Unpublish, Archive, or Trash articles.
* '''Edit Own''' is the same as Edit except that it only applies to articles written by you.

==Allowing Guest-Only Access to Menu Items and Modules==

Version 1.6 introduced the ability to create a View Access Level that is only for guests of the site (meaning a user who is not logged in). The example below shows how you can set up this new feature.
''(N.B. Steps 1 to 3 are not needed for Joomla! 3.x as they exist in the default install)''

#Create a new user group called Guest. Make it a child of the Public group as shown below. [[Image:screenshot_acl_tutorial_20110112-01-en.png|center|frame]]
# Create a new access level called Guest and grant only the Guest group access to this level, as shown below.[[Image:screenshot_acl_tutorial_20110112-02-de.png|center|frame]]
# Navigate to User Manager→Options→Component and change the Guest User Group from the default value of "Public" to "Guest", as shown below.
[[Image:screenshot_acl_tutorial_20110112-04-de.png|center|frame]]
Now, if we assign a menu item, module, or other object to the Guest access level, only non-logged in users will have access. For example, if we create a new menu item with access level of Guest, as shown below,
[[Image:screenshot_acl_tutorial_20110112-05-de.png|center|frame]]
this menu item will only be visible to non-logged-in visitors to the site.

If required other user groups like Author can be granted access in the Guest access level, this would allow Authors to view articles in the front end for editing.

'''N.B. Login/logout in front end (''for changing data in session'') to see the change.'''

==Berechtigungen und Gruppenebenen gemeinsam nutzen==

As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.

This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:

* both groups can create new articles only in the History Assignments category.

* only History Teachers (not Assistant History Teachers) can Publish or otherwise have Edit State permission.

This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.

[[Image:Acl example diagram1 20091018-de.png|center|]]

In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.

To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.

Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.

[[Image:Acl example diagram2 20091018-de.png|center|]]

This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.

Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.

==ACL Aktion Berechtigungs-Beispiele==

===Backend Beitrag Administrator===

'''Problem:'''

We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.

'''Lösung:'''

# Create a new group called Article Administrator and make its parent group Public, as shown below.[[Image:screenshot_acl_tutorial_20110112-10-de.png|center|frame]] Because its parent group is Public, it won't have any permissions by default.
# In Users → Access Levels, edit the Special Access level to add the new group. That way they can get access to the back end menu items and modules (This assumes that the modules for the admin menu and quickicons have the Special Access level assigned to them, which is the default.) [[Image:screenshot_acl_tutorial_20110112-11-de.png|center|frame]] By default, the back-end menu items and modules are set to Special access, so if you forget to add the new group to the Special access level, you won't see any modules or menu items when you log in as a user of the new group.
# In Site → Global Configuration → Permissions, click on the Article Administrator group and change the permissions to Allowed for the following actions: Admin Login, Create, Delete, Edit, Edit State, and Edit Own. The screen below shows what will show before you press Save. [[Image:screenshot_acl_tutorial_20110112-12-de.png|center|frame]]After you save, the Calculated Permissions should show as shown below.[[Image:screenshot_acl_tutorial_20110112-13-de.png|center|frame]]Note that the permission for the Access Component is Inherited, which translates to Not Allowed. This is important. This means that this group will only be able to access components if we give the group "Allowed" permission for Access Component. So we only have to change the one component we want to give them access to and don't have to change any settings for the components where we don't want them to have access. If we had a case where we wanted to give a group access to everything except for one component, we could set the default to Allowed and then set the one component to Denied. Also note that we did not give the group Site Login permission, so users in this group will not be able to log into the front end. (If we wanted to allow that, we would just change the permission to Allowed for Site Login.)
# In Article Manager → Options → Permissions, change permissions to Allowed for this group for the Access Component action, as shown below.[[Image:screenshot_acl_tutorial_20110112-14-de.png|center|frame]]All of the other desired permissions are inherited.

That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end. For example, the screen below shows what a user in the Article Manager will see when they login to the back end.[[Image:screenshot_acl_tutorial_20110112-15-de.png|center|frame]]

==ACL Ansicht Zugriffsebenen-Beispiele==

A basic concept of using Access Levels is that all items with the same Access will be viewable by the same group of users. In other words, if two items have the same Access, you can't have one viewable by one user and not viewable by another user. On the other hand, it is easy to have one Group view any number of items with different Access levels.

Similarly, each Group has exactly the same combination of Access levels, but one User can be a member of more than one group. Depending on the situation, you may want to have users only in one Group or you may need to have a User in more than one Group.

This means that we may need to group our items so that items so that all items in a group have the same level of sensitivity. Here are some examples.

===Hierarchisches Beispiel===
In this example, Access levels are hierarchical, for example, like government security clearance codes. Say for example we have the following sets of classified documents: Classified, Secret, and Top Secret. Users have corresponding clearence codes. Users with Classified clearance can only see Classified documents and cannot see Secret or Top Secret. Users with Secret clearance can see Classified and Secret documents but not Top Secret. Users with Top Secret can see all documents.

In this case, you would create three Access levels: Classified, Secret, and Top Secret and the same three Groups. Users would only be members of one group, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| C1, C2, C3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Classified
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| S1, S2, S3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| TS1, TS2, TS3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Top Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret, Top Secret

|}

In this case, all users are in exactly one group, but some groups have access to more than one Access Level of items. In other words, we have a one-to-one relationship between users and groups, but a one-to-many relationship between Groups and Access Levels.

===Teamsicherheit Beispiel===

Another possible use case is a set of non-hierarchical teams. Let's say we have three teams, T1, T2, and T3. Some users are only on one team, but others might be on two or more teams. In this case, we could set up our Access Levels and Groups by team. Documents for each team have the access level for that team, and the Group for the team has only the one access level. When a User is on more than one team, they get added to the group for each team, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Beschreibung
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 1 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 2 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 3 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1, 2 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1,T2, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2, T3

|}

===Hybrid Example===

In a real-world situation, you might have a combination of these two arrangements. Say for example we have Managers and Staff. Staff can only see Staff documents and Managers can see Manager and Staff documents. Both types of users can be assigned to teams as well, in which case they can see all of the documents for that team. In addition, say that Managers can access some, but not all, team documents. Staff can only access team documents if they are members of that team.

In this example, we could set up the following Access Levels:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Access Level
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Description
| style="border:0.0007in solid #000000;padding:0.0382in;"| Groups

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team manager documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team staff documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team1 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1, Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team2 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2, Manager

|}

Then, users could be assigned to groups as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| User Type
| style="border:0.0007in solid #000000;padding:0.0382in;"| Group

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1, Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1, Team2

|}

<noinclude>
[[Category:Joomla! 1.6]]
[[Category:Joomla! 2.5]]
[[Category:Joomla! 3.x/de]]
[[Category:Tutorials/de]]
[[Category:Access Control/de]]
[[Category:Access Management]]
</noinclude>

Translations:J3.x:Access Control List Tutorial/156/de

2019-12-26T19:05:16Z

Sieger66:

J3.x:Access Control List Tutorial/de

2019-12-26T19:05:04Z

Sieger66:

<noinclude><languages /></noinclude>
{{Joomla version|version=3.x|comment=Serie}}
{{-}}
{{:J3.1:Access_Control_List/en}}

==Separate ACL für Anzeige und Aktionen==

Das Joomla ACL-System besteht genau genommen aus zwei völlig getrennten Systemen. Das eine System steuert, was Benutzer auf der Website "sehen" können. Das andere steuert, was Benutzer "tun" können (welche Aktionen ein Benutzer durchführen kann). Die ACL wird für jedes dieser Systeme anders eingerichtet.

===Steuern, was Benutzer sehen können===

Das Setup zum Steuern, was Benutzer sehen können, sieht wie folgt aus:
*Eine Reihe von Zugriffsebenen gemäß den Kategorien und/oder der Kombination von Kategorien erstellen, die nur angemeldete Benutzer sehen sollen. Anmerkung: Zu diesem Zeitpunkt werden noch keine Benutzergruppen den neuen Zugriffsebenen zugewiesen.

*Für jede Zugriffsebene eine Benutzergruppe erstellen, die 'Registriert' als übergeordnete Gruppe hat. Indem man für Benutzergruppen und Zugriffsebenen die gleichen Namen verwendet, kann man Verwirrungen zu einem späteren Zeitpunkt vorbeugen.

*Die neuen Zugriffsebenen bearbeiten und jeder die (neue) Benutzergruppe zuweisen. Wahrscheinlich möchten man auch die 'Super Benutzer' Gruppe (und/oder die anderen Standard-Benutzergruppen mit Ausnahme der Benutzergruppe 'Gast') den neuen Zugriffsebenen zuweisen.

*Jedem anzuzeigenden Eintrag eine Zugriffsebene zuweisen. Einträge sind sowohl inhaltliche Einträge (Beiträge, Kontakte, usw.), Menüeinträge als auch Module.

Immer dann, wenn ein Benutzer im Begriff ist, einen Eintrag auf einer Joomla-Seite anzeigen zu lassen, prüft das Programm, ob dieser Benutzer auch Zugriff auf den Eintrag hat. Das geschieht folgendermaßen:
# Zunächst wird eine Liste aller Zugriffsebenen erstellt, auf die der Benutzer zugreifen kann, basierend auf allen Gruppen, denen der Benutzer angehört. Sofern eine Gruppe eine übergeordnete Gruppe besitzt, sind die Zugriffsebenen für die übergeordnete Gruppe ebenfalls in der Liste enthalten.
# Danach wird überprüft, ob die Zugriffsebene für den Eintrag (Beitrag, Modul, Menüeintrag, usw.) in dieser Liste enthalten ist. Wenn dem so ist, wird der Eintrag dem Benutzer angezeigt. Falls der Benutzer die benötigten Zugriffsrechte besitzt, wird ihm der Zugriff verweigert.

Beachten, dass Zugriffsebenen für jede Gruppe separat festgelegt und nicht von der übergeordneten Gruppe einer Gruppe vererbt werden.

===Steuern, was Benutzer tun können===

Das System, das steuert, was Benutzer in einer Benutzergruppe tun können - welche Aktionen sie bei einem bestimmten Eintrag ausführen können - wird über den Tab 'Berechtigungen' in der Konfiguration und den Tab 'Berechtigungen' in den Optionen jeder einzelnen Komponente eingerichtet. Berechtigungen können auch auf Kategorienebene (bei Kernkomponenten) und auf Beitragsebene (bei Beiträgen) gesetzt werden.

* Wenn angemeldete Benutzer in bestimmten Kategorien Erstellen, Löschen, Status bearbeiten oder Eigene Inhalte bearbeiten dürfen, dann:
** Eine Benutzergruppe erstellen und als übergeordnete Gruppe eine der Benutzergruppen angeben, die Zugriff auf die Kategorie (oder Kategorien) haben, die diese neue Benutzergruppe ändern soll.
**Der neuen Benutzergruppe den entsprechenden Zugriffsebenen zuweisen. Dann die erforderlichen Berechtigungen für die neue Benutzergruppe entweder global oder pro Kategorie/Beitrag ändern.
*** Beim Erstellen einer Benutzergruppe ist es ratsam, eine übergeordnete Gruppe zu wählen, die über weniger Berechtigungen verfügt, als für die neue Gruppe erforderlich. Denn es ist einfacher, die Berechtigungen für jede Komponente/Kategorie/Beitrag zu erweitern, für die zusätzliche Berechtigungen nötig sind, als Berechtigungen aus den anderen Komponenten/Kategorien/Beiträgen zu entfernen.
****''(Beispiel: Es gibt 10 Kategorien, man möchte aber nur für eine Erstellen-Berechtigungen. Würde man für diese Gruppe die Berechtigungen global auf Erstellen erlaubt setzen, müsste man für diese Kategorien die Erstellen-Berechtigung entfernen. Und man müsste für diese Gruppe die Erstellen-Berechtigung bei jeder neuen Kategorie, die man zu einem späteren Zeitpunkt hinzufügt, ebenfalls entfernen).''
** Eine Benutzergruppe erstellen, die eine der Standardbenutzergruppen als übergeordnete Gruppe hat, NUR, wenn keine von diesen über die exakten Berechtigungen verfügt, die man benötigt und sich für alle Kategorien wünscht.

Beachten, dass dieses Setup unabhängig vom Setup für die Anzeige ist. Allerdings muss eine Benutzergruppe den entsprechenden Zugriffsebenen zugewiesen werden, damit der Benutzer in dieser Gruppe jene Berechtigungen verwenden kann.

Möchte ein Benutzer eine bestimmte Aktion bei einem Komponenten-Eintrag durchführen (z. B. einen Beitrag bearbeiten), überprüft das System (nachdem es überprüft hat, welcher Gruppe der Benutzer angehört und auf welche er Zugriff hat) die Berechtigung für diese Kombination aus Benutzer, Eintrag und Aktion. Liegt eine Erlaubnis vor, kann der Benutzer fortfahren. Andernfalls ist die Aktion nicht zulässig.

Das restliche Tutorial befasst sich mit der Steuerung, was Benutzer tun können - welche Aktionsberechtigungen sie haben.

==Aktionen, Gruppen und Vererbung==

Andererseits geht es bei der ACL auch darum, Benutzern Berechtigungen zu erteilen, damit diese Aktionen an Objekten durchführen können.

{| class="wikitable"
!style="width:20%;"|
!3.x Serie
|-
!Gruppen und Aktionen
|Aktionen, welche pro Gruppe erlaubt sind, werden durch den Website Administrator festgelegt.
|-
!Umfang von Berechtigungen
|Berechtigungen können auf mehreren Ebenen in der Hierarchie festgelegt werden: Website, Komponente, Kategorie, Objekt.
|-
!Vererbung von Berechtigungen
|Berechtigungen können von übergeordneten Gruppen und übergeordneten Kategorien geerbt werden.
|}

===Wie die Berechtigungen funktionieren===

Es gibt vier mögliche Berechtigungen für Aktionen. Diese sind (kurz skizziert):

* '''Nicht gesetzt''': Fällt standardmäßig auf "Nicht erlaubt" zurück. Aber im Gegensatz zur Berechtigung "Verweigert" kann diese Berechtigung außer Kraft gesetzt werden, wenn eine untergeordnete Gruppe oder eine in der Berechtigungshierarchie untergeordnete Ebene auf "Erlaubt" gesetzt wird. Diese Berechtigung kann nur für globale Berechtigungen der Konfiguration gesetzt werden.
* '''Vererbt''': Erbt den Wert von einer übergeordneten Gruppe oder einer in der Berechtigungshierarchie höheren Ebene. Diese Berechtigung gilt für alle Ebenen mit Ausnahme der obersten Ebene der Konfiguration.
* '''Verweigert''': Verbietet diese Aktion für diese Ebene und Gruppe. '''WICHTIG:''' Dadurch wird diese Aktion auch für alle untergeordneten Gruppen und alle untergeordneten Ebenen in der Berechtigungshierarchie verboten. Wird "Erlaubt" in einer untergeordneten Gruppe oder einer tieferen Ebene gesetzt, hat das keinen Effekt. Die Aktion wird immer für alle Mitglieder einer untergeordneten Gruppe und für alle untergeordneten Ebenen in der Berechtigungshierarchie abgelehnt.
* '''Erlaubt ''': Genehmigt diese Aktion für diese Ebene und Gruppe und für tiefere Ebenen und Untergruppen. Dies hat keine Auswirkungen, wenn eine höhere Gruppe oder Ebene auf "Verweigert" oder "Erlaubt" eingestellt ist. Wenn eine höhere Gruppe oder ein höheres Ebene auf "Verweigert" gesetzt ist, wird diese Berechtigung immer abgelehnt. Wenn eine höhere Gruppe oder Ebene auf Erlaubt eingestellt ist, ist diese Berechtigung bereits erlaubt.

===Hierarchie der Berechtigungsebenen===

Berechtigungen für Aktionen können in Version 2.5+ auf bis zu vier Ebenen festgelegt werden, wie folgt:
# '''Konfiguration''': legt die Standardberechtigungen für jede Aktion und Gruppe fest.
# '''Komponenten-Optionen-> Berechtigungen''': kann die Standardberechtigungen für diese Komponente überschreiben (z. B. Beiträge, Menüs, Benutzer, Banner usw.).
# '''Kategorie''': kann die Standardberechtigungen für Objekte in einer oder mehreren Kategorien überschreiben. Gilt für alle Komponenten mit Kategorien, einschließlich Beiträge, Banner, Kontakte, Newsfeeds und Weblinks.
# '''Beitrag''': kann die Berechtigungen für einen bestimmten Artikel überschreiben. Diese Ebene gilt nur für Beiträge. Alle anderen Komponenten erlauben nur die ersten drei Ebenen.

====Konfiguration====
Diese erreicht man über System → Konfiguration → Berechtigungen. Die nun sichtbare Maske dient dazu, die Berechtigungen auf der obersten Ebene für jede Gruppe und jede Aktion festzulegen, wie auch in der folgenden Abbildung gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Die möglichen Werte sind Vererbt, Erlaubt oder Verweigert. Die Spalte 'Errechnete Einstellung' zeigt die aktuelle Einstellung an. Diese ist entweder Nicht erlaubt (Standard), Erlaubt oder Nicht erlaubt.

Man kann immer nur an einer Gruppe gleichzeitig arbeiten, indem man den Reiter für ebendiese Gruppe anklickt. Die Berechtigungen kann man über die Dropdownlisten unter Neue Einstellung wählen ändern.

Beachten Sie, dass die Spalte "Errechnete Einstellung" erst aktualisiert wird, wenn Sie auf die Schaltfläche "Speichern" in der Werkzeugleiste klicken.

Um zu überprüfen, ob die Einstellungen Ihren Wünschen entsprechen, klicken Sie auf die Schaltfläche Speichern und überprüfen anschließend die Spalte Errechnete Einstellung.

====Komponenten-Optionen->Berechtigungen====
Auf diese wird für jede Komponente durch Klicken auf das Symbol "Optionen" in der Werkzeugleiste zugegriffen. Dieser Bildschirm ist ähnlich wie der Bildschirm "Globale Konfiguration" oben links. Wenn Sie beispielsweise im Menü-Manager auf das Symbol in der Werkzeugleiste Optionen klicken, werden die folgenden Menüs angezeigt.
[[Image:Screenshot_menu_acl_J3_tutorial-en.jpg]]

Der Zugriff auf Optionen ist nur für Mitglieder von Gruppen möglich, die die Berechtigung für die Aktion Konfiguration in für jede Komponente haben. Im obigen Beispiel hat die Gruppe Administrator die Berechtigung Erlaubt für die Option Konfigurieren, so dass Mitglieder dieser Gruppe auf diesen Bildschirm zugreifen können.

===Kategorie===
Auf die Kategorieberechtigungen wird im Category Manager zugegriffen: Bildschirm Kategorie bearbeiten, in einer Registerkarte oben auf dem Bildschirm. Dieser Bildschirm hat fünf Berechtigungen, wie folgt:

[[Image:Screenshot_category_acl_j3_tutorial-en.png]]

In diesen Bildern bearbeiten Sie die Berechtigungen für jeweils eine Benutzergruppe. Im obigen Beispiel bearbeiten Sie die Berechtigungen für die Gruppe Administrator.

Achten Sie darauf, dass die Aktionen "Konfigurieren und Zugriffssteuerung" nicht auf der Kategorieebene angewendet werden, so dass diese Aktionen nicht enthalten sind.

Beachten Sie auch, dass Kategorien in einer Hierarchie angeordnet werden können. Wenn ja, dann werden Aktionsberechtigungen in einer übergeordneten Kategorie automatisch an eine untergeordnete Kategorie vererbt. Wenn Sie beispielsweise eine Kategoriehierarchie von Tieren → Haustiere → Hunde hätten, dann würde die vollständige Berechtigungshierarchie für einen Artikel in der Kategorie Hunde wie folgt aussehen:
* Globale Konfiguration
* Artikel-Manager → Optionen → Genehmigung → Erlaubnis
* Tierkategorie
* Kategorie Haustiere
* Kategorie Hunde
* spezifischer Artikel

====Beitrag====
Berechtigungen für einzelne Beiträge findet man im "Beitrag" unter dem Tab-Reiter "Berechigungen". Dieser Bildschirm hat drei Aktionen, wie unten gezeigt.

[[Image:j3x_acl_tutorial_article_manager_article_permissions-en.png]]

Auch hier bearbeiten Sie jede Gruppe für sich. Um auf die Berechtigungen zuzugreifen wechseln Sie im Artikel auf den Reiter "Berechtigungen" im oberen Reiter. Über das Drop Down Menü wählen Sie die neue Berechtigung im Anschluss speichern Sie den Beitrag ab.

Beachten Sie, dass die Aktionen Configure, Access Component und Create auf Artikelebene nicht gelten, so dass diese Aktionen nicht berücksichtigt werden. Die Berechtigung zum Anlegen eines Artikels wird auf einer der höheren Ebenen der Hierarchie festgelegt.

===Zugriffsebenen===

Die Zugriffsebenen der 3.x-Serie sind einfach und flexibel. Der folgende Bildschirm zeigt die spezielle Zugriffsebene.
[[Image:j3x_acl_tutorial_viewing_levels-en.png|center]]
Aktivieren Sie einfach das Kontrollkästchen für jede Gruppe, die Sie in diesem Level aufnehmen wollen. Die spezielle Zugriffsebene umfasst die Gruppen Manager, Autor und Superuser. Es beinhaltet auch untergeordnete Gruppen dieser Gruppen. Die Gruppe Administrator ist also enthalten, da es sich um eine Untergruppe der Gruppe Manager handelt. Die Gruppen Editor, Publisher und Shop Suppliers sind enthalten, da es sich um Untergruppen des Autors handelt.

Jedem Objekt im Frontend ist eine Zugriffsebene zugeordnet. Wenn die Ebene öffentlich ist, kann jeder auf dieses Objekt zugreifen. Andernfalls dürfen nur Mitglieder von Gruppen, die dieser Zugriffsebene zugeordnet sind, auf dieses Objekt zugreifen.

Die Zugriffsebenen sind den Menüpunkten und den Modulen zugeordnet. Jede kann nur einer Zugriffsebene zugeordnet werden.

Der folgende Bildschirm zeigt beispielsweise den Bildschirm Menüpunkt bearbeiten mit der Liste der verfügbaren Zugriffsebenen....

[[Image:j3x_acl_tutorial_edit_menu_item_level_dropdown-en.png|center]]

==Standard-ACL-Setup==

Wenn Joomla! installiert ist, werden diese auf die ursprünglichen Standardwerte gesetzt. Wir werden diese Grundeinstellungen besprechen, um die Arbeitsweise der ACL zu verstehen.

===Standardgruppen===

Mit der Version 3.x können Sie Ihre individuellen Gruppen definieren. Wenn Sie die Version 3.x installieren, enthält sie eine Reihe von Standardgruppen, die im Folgenden dargestellt werden, sind die grundlegenden Standardbenutzergruppen. (Zusätzliche Standardbenutzergruppen werden mit Beispieldaten installiert)

[[Image:Screenshot_usergroupsl_acl_J3_tutorial-en.png|center]]

Die Pfeile zeigen die untergeordneten Elternbeziehungen an. Wie vorstehend besprochen, wird diese Berechtigung, wenn Sie eine Berechtigung für eine übergeordnete Gruppe festlegen, automatisch an alle Untergruppen vererbt. Die vererbten und zulässigen Berechtigungen können für eine Untergruppe überschrieben werden. Die Berechtigung Verweigert kann nicht überschrieben werden und verweigert immer eine Aktion für alle Untergruppen.

===Konfiguration===

Joomla! Version 3.x wird mit den gleichen bekannten Backend-Rechten wie die Version 1.5 (EOL) installiert. Mit der Version 3.x können Sie diese jedoch leicht an die Bedürfnisse Ihrer Website anpassen.

Wie bereits besprochen, werden die Berechtigungen für jede Aktion von der obigen Ebene in der Berechtigungshierarchie und von der übergeordneten Gruppe einer Gruppe übernommen. Also, wie funktioniert das? Die oberste Ebene dafür ist der gesamte Standort. Dies wird in der Site->Globale Konfiguration->Berechtigungen eingerichtet, wie unten gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Das erste, was man bemerken sollte, sind die zehn Aktionen: Standortlogin, Admin-Login, Offline-Zugriff, Superuser, Access Administration Interface, Erstellen, Löschen, Bearbeiten, Status bearbeiten und Eigenes bearbeiten. Dies sind die Aktionen, die ein Benutzer an einem Objekt in Joomla durchführen kann. Die spezifische Bedeutung jeder Aktion hängt vom Kontext ab. Für das Bild Globale Konfiguration sind sie wie folgt definiert:

Site Login : Login to the front end of the site

;Admin Login : Melden Sie sich am Backend der Website an.

Offline-Zugriff: Melden Sie sich am Frontend der Website an, wenn die Website offline ist (wenn die globale Konfigurationseinstellung "Site Offline" auf Ja gesetzt ist).

Superuser: Gewährt dem Benutzer den Status "Superuser". Benutzer mit dieser Berechtigung dürfen alles auf der Website machen. Nur Benutzer mit dieser Berechtigung können die Einstellungen der globalen Konfiguration ändern. Diese Berechtigungen können nicht eingeschränkt werden. Es ist wichtig zu verstehen, dass, wenn ein Benutzer Mitglied einer Super Admin-Gruppe ist, alle anderen Berechtigungen, die diesem Benutzer zugewiesen sind, irrelevant sind. Der Benutzer kann jede Aktion auf der Website durchführen. Es können jedoch weiterhin Zugriffsebenen zugewiesen werden, um zu steuern, was diese Gruppe auf der Website sieht. (Natürlich kann ein Super-Admin-Benutzer die Zugriffsebenen ändern, wenn er möchte, so dass die Zugriffsebenen nicht vollständig einschränken, was ein Super-Admin-Benutzer sehen kann.)

Zugangskomponente: Öffnen Sie die Bildschirme der Komponentenverwaltung (Benutzerverwaltung, Menüverwaltung, Artikelverwaltung usw.).

;Create : Create new objects (for example, users, menu items, articles, weblinks, and so on)

;Löschen : Löschen eines existienden Objekts

;Ändern : Ändern eines existierenden Objektes

;Ändern eines Objekt Status (Veröffentlicht, nicht Veröffentlicht, Archiviert und Gelöscht)

Eigene Objekte bearbeiten: Bearbeiten Sie Objekte, die Sie erstellt haben.

Each Group for the site has its own slider which is opened by clicking on the group name. In this case (with the sample data installed), we have the standard 7 groups that we had in version 1.5 plus two additional groups called "Shop Suppliers" and "Customer Group". Notice that our groups are set up with the same permissions as they had in version 1.5. Keep in mind that we can change any of these permissions to make the security work the way we want. Let's go through this to see how it works.

* '''Public''' has everything set to "Not set", as shown below.{{-}}[[Image:Screenshot_global_acl_public_J3_tutorial-en.png]]
**This can be a bit confusing. Basically, "Not Set" is the same as "Inherited". Because Public is our top-level group, and because Global Configuration is the top level of the component hierarchy, there is nothing to inherit from. So "Not Set" is used instead of "Inherit".
**The default in this case is for no permissions. So, as you would expect, the Public group has no special permissions. Also, it is important to note that, since nothing is set to Denied, all of these permissions may be overridden by child groups or by lower levels in the permission hierarchy.

* '''Guest''' is a 'child' group of the Public group has everything set to 'Inherited' {{-}}[[Image:Screenshot_global_acl_guest_J3_tutorial-de.png]]
** This is the default 'Guest User Group' in the User Manager options and the Group that (non logged in) visitors to your site are placed in.

* '''Manager''' is a "child" group of the Public group. It has Allowed permissions for everything except Access Component and Super Admin. So a member of this group can do everything in the front and back end of the site except change Global Permissions and Component Options. {{-}}[[Image:Screenshot_global_acl_manager_J3_tutorial-en.png]]

* '''Administrator''' group members inherit all of the Manager permissions and also have Allowed for Access Component. So members of this group by default can access the Options screens for each component. {{-}}[[Image:Screenshot_global_acl_administrator_J3_tutorial-en.png]]

* '''Registered''' is the same a Public except for the Allow permission for the Site Login action. This means that members of the Registered group can login to the site. Since default permissions are inherited, this means that, unless a child group overrides this permission, all child groups of the Registered group will be able to login as well. {{-}}[[Image:Screenshot_global_acl_registered_J3_tutorial-en.png]]

* '''Author''' is a child of the Registered group and inherits its permissions and also adds Create and Edit Own. Since Author, Editor, and Publisher have no back-end permissions, we will discuss them below, when we discuss front-end permissions.{{-}}[[Image:Screenshot_global_acl_author_J3_tutorial-en.png]]

* '''Editor''' is a child of the Authors group and adds the Edit permission. {{-}}[[Image:Screenshot_global_acl_editor_J3_tutorial-en.png]]

* '''Publisher''' is a child of Editor and adds the Edit State permission.{{-}}[[Image:Screenshot_global_acl_publisher_J3_tutorial-en.png]]

* '''Shop Suppliers''' is an example group that is installed if you install the sample data. It is a child group of Author.

* '''Customer Group''' is an example group that is installed if you install the sample data. It is a child group of Registered.

* '''Super Users''' group has the Allow permission for the Super Admin action. Because of this, members of this group have super user permissions throughout the site. They are the only users who can access and edit values on the Global Configuration screen. Users with permission for the Super Admin action have some special characteristics:
:* If a user has Super Admin permissions, no other permissions for this user matter. The user can perform any action on the site.
:* Only Super Admin users can create, edit, or delete other Super Admin users or groups.

There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.

This provides a lot of flexibility. For example, if you wanted Shop Suppliers to be able to have the ability to login to the back end, you could just change their Admin Login value to "Allowed". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherited (or Denied).

It is also important to understand that the ability to have child groups is completely optional. It allows you to save some time when setting up new groups. However, if you like, you can set up all groups to have Public as the parent and not inherit any permissions from a parent group.

===Komponenten-Optionen & Berechtigungen===

Now, let's continue to see how the default back-end permissions for version 2.5 mimic the permissions for version 1.5. The Super Users group in 2.5 is equivalent to the Super Administrator group in 1.5.

Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 2.5 configuration. Let's see how this is accomplished.

If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:

[[Image:screenshot_acl_tutorial_20110111-09-en.png|center|]]
[[Image:screenshot_acl_tutorial_20110111-10-en.png|center|]]

This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.

First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.

Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.

If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.

In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.

It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.

===Frontend Berechtigungen===

Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions. First, let's look at the permissions for Manager, as shown below.
[[Image:screenshot_acl_tutorial_20110111-11a-en.png|center|frame]]
Manager has allowed permission for all actions except Configure. So members of the Manager group can do everything with Articles except open the Options screen.

Now let's look at Administrator, as shown below.
[[Image:screenshot_acl_tutorial_20110111-12a-en.png|center|frame]]
Administrator has Allowed for Configure, so Administrators can edit this Options screen.

Both groups can create, delete, edit, and change the state of articles.

Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set.

Authors only have Create and Edit Own permissions, as shown below.
[[Image:screenshot_acl_tutorial_20110112-07-en.png|center|frame]]
This means that Authors can create articles and can edit articles they have created. They may not delete articles, change the published state of articles, or edit articles created by others.

Editors have the same permissions as Authors with the addition of permission for the Edit action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-08-en.png|center|frame]]
So Editors can edit articles written by anyone.

Publishers can do everything Editors can do plus they have permission for the Edit State action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-09-en.png|center|frame]]
So Publishers can change the published state of an article. The possible states include Published, Unpublished, Archived, and Trashed.

All of these groups have Inherit permission for Configure and Access Component. Remember that Author is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Configure and Access Component, and since Author's permission for these actions is "Inherited", then Author does not have these permissions either. This same permission is passed from Author to Editor and from Editor to Publisher. So, by default, none of these groups are allowed to work with articles in the back end.

It is important to remember that these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.

Beachte auch das in den ursprünglichen Standardwerten keine Berechtigungen auf Verweigert eingestellt sind. Dies ermöglicht in allen Berechtigungsebenen die jeweilige Berechtigung auf Erlaubt einzustellen. Bedenke, wenn eine Aktion auf Verweigert eingestellt ist, das diese Aktion auch in allen untergeordneten Ebenen in der Berechtigungshierarchie verweigert wird. Zum Beispiel, wenn die Seitenameldung für Registered auf Verweigert (anstatt auf Erlaubt) eingestellt wird, kann man Publishers diese Aktion per Berechtigungeinstellung nicht erteilen.

=== Beitrags-Manager & Aktions-Diagramm ===

The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.

[[Image:screenshot_acl_tutorial_20110111-16-de.png|center|]]

* '''Configure''' allows you to view and change the Options for the component.
* '''Access Component''' allows you to navigate to the Article Manager. Without this permission, no other actions are possible.
* '''Create''' allows you to add new articles.
* '''Delete''' allows you to delete trashed articles. Note that the Delete icon only shows in the toolbar when you have the "Select State" filter set to "Trash".
* '''Edit''' allows you to edit existing articles.
* '''Edit State''' allows to you Publish, Unpublish, Archive, or Trash articles.
* '''Edit Own''' is the same as Edit except that it only applies to articles written by you.

==Allowing Guest-Only Access to Menu Items and Modules==

Version 1.6 introduced the ability to create a View Access Level that is only for guests of the site (meaning a user who is not logged in). The example below shows how you can set up this new feature.
''(N.B. Steps 1 to 3 are not needed for Joomla! 3.x as they exist in the default install)''

#Create a new user group called Guest. Make it a child of the Public group as shown below. [[Image:screenshot_acl_tutorial_20110112-01-en.png|center|frame]]
# Create a new access level called Guest and grant only the Guest group access to this level, as shown below.[[Image:screenshot_acl_tutorial_20110112-02-de.png|center|frame]]
# Navigate to User Manager→Options→Component and change the Guest User Group from the default value of "Public" to "Guest", as shown below.
[[Image:screenshot_acl_tutorial_20110112-04-de.png|center|frame]]
Now, if we assign a menu item, module, or other object to the Guest access level, only non-logged in users will have access. For example, if we create a new menu item with access level of Guest, as shown below,
[[Image:screenshot_acl_tutorial_20110112-05-de.png|center|frame]]
this menu item will only be visible to non-logged-in visitors to the site.

If required other user groups like Author can be granted access in the Guest access level, this would allow Authors to view articles in the front end for editing.

'''N.B. Login/logout in front end (''for changing data in session'') to see the change.'''

==Berechtigungen und Gruppenebenen gemeinsam nutzen==

As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.

This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:

* both groups can create new articles only in the History Assignments category.

* only History Teachers (not Assistant History Teachers) can Publish or otherwise have Edit State permission.

This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.

[[Image:Acl example diagram1 20091018-de.png|center|]]

In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.

To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.

Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.

[[Image:Acl example diagram2 20091018-de.png|center|]]

This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.

Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.

==ACL Aktion Berechtigungs-Beispiele==

===Backend Beitrag Administrator===

'''Problem:'''

We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.

'''Lösung:'''

# Create a new group called Article Administrator and make its parent group Public, as shown below.[[Image:screenshot_acl_tutorial_20110112-10-de.png|center|frame]] Because its parent group is Public, it won't have any permissions by default.
# In Users → Access Levels, edit the Special Access level to add the new group. That way they can get access to the back end menu items and modules (This assumes that the modules for the admin menu and quickicons have the Special Access level assigned to them, which is the default.) [[Image:screenshot_acl_tutorial_20110112-11-de.png|center|frame]] By default, the back-end menu items and modules are set to Special access, so if you forget to add the new group to the Special access level, you won't see any modules or menu items when you log in as a user of the new group.
# In Site → Global Configuration → Permissions, click on the Article Administrator group and change the permissions to Allowed for the following actions: Admin Login, Create, Delete, Edit, Edit State, and Edit Own. The screen below shows what will show before you press Save. [[Image:screenshot_acl_tutorial_20110112-12-de.png|center|frame]]After you save, the Calculated Permissions should show as shown below.[[Image:screenshot_acl_tutorial_20110112-13-de.png|center|frame]]Note that the permission for the Access Component is Inherited, which translates to Not Allowed. This is important. This means that this group will only be able to access components if we give the group "Allowed" permission for Access Component. So we only have to change the one component we want to give them access to and don't have to change any settings for the components where we don't want them to have access. If we had a case where we wanted to give a group access to everything except for one component, we could set the default to Allowed and then set the one component to Denied. Also note that we did not give the group Site Login permission, so users in this group will not be able to log into the front end. (If we wanted to allow that, we would just change the permission to Allowed for Site Login.)
# In Article Manager → Options → Permissions, change permissions to Allowed for this group for the Access Component action, as shown below.[[Image:screenshot_acl_tutorial_20110112-14-de.png|center|frame]]All of the other desired permissions are inherited.

That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end. For example, the screen below shows what a user in the Article Manager will see when they login to the back end.[[Image:screenshot_acl_tutorial_20110112-15-de.png|center|frame]]

==ACL Ansicht Zugriffsebenen-Beispiele==

A basic concept of using Access Levels is that all items with the same Access will be viewable by the same group of users. In other words, if two items have the same Access, you can't have one viewable by one user and not viewable by another user. On the other hand, it is easy to have one Group view any number of items with different Access levels.

Similarly, each Group has exactly the same combination of Access levels, but one User can be a member of more than one group. Depending on the situation, you may want to have users only in one Group or you may need to have a User in more than one Group.

This means that we may need to group our items so that items so that all items in a group have the same level of sensitivity. Here are some examples.

===Hierarchisches Beispiel===
In this example, Access levels are hierarchical, for example, like government security clearance codes. Say for example we have the following sets of classified documents: Classified, Secret, and Top Secret. Users have corresponding clearence codes. Users with Classified clearance can only see Classified documents and cannot see Secret or Top Secret. Users with Secret clearance can see Classified and Secret documents but not Top Secret. Users with Top Secret can see all documents.

In this case, you would create three Access levels: Classified, Secret, and Top Secret and the same three Groups. Users would only be members of one group, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| C1, C2, C3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Classified
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| S1, S2, S3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| TS1, TS2, TS3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Top Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret, Top Secret

|}

In this case, all users are in exactly one group, but some groups have access to more than one Access Level of items. In other words, we have a one-to-one relationship between users and groups, but a one-to-many relationship between Groups and Access Levels.

===Teamsicherheit Beispiel===

Another possible use case is a set of non-hierarchical teams. Let's say we have three teams, T1, T2, and T3. Some users are only on one team, but others might be on two or more teams. In this case, we could set up our Access Levels and Groups by team. Documents for each team have the access level for that team, and the Group for the team has only the one access level. When a User is on more than one team, they get added to the group for each team, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Beschreibung
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 1 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 2 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 3 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1, 2 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1,T2, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2, T3

|}

===Hybrid Example===

In a real-world situation, you might have a combination of these two arrangements. Say for example we have Managers and Staff. Staff can only see Staff documents and Managers can see Manager and Staff documents. Both types of users can be assigned to teams as well, in which case they can see all of the documents for that team. In addition, say that Managers can access some, but not all, team documents. Staff can only access team documents if they are members of that team.

In this example, we could set up the following Access Levels:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Access Level
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Description
| style="border:0.0007in solid #000000;padding:0.0382in;"| Groups

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team manager documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team staff documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team1 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1, Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team2 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2, Manager

|}

Then, users could be assigned to groups as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| User Type
| style="border:0.0007in solid #000000;padding:0.0382in;"| Group

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1, Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1, Team2

|}

<noinclude>
[[Category:Joomla! 1.6]]
[[Category:Joomla! 2.5]]
[[Category:Joomla! 3.x/de]]
[[Category:Tutorials/de]]
[[Category:Access Control/de]]
[[Category:Access Management]]
</noinclude>

Translations:J3.x:Access Control List Tutorial/167/de

2019-12-26T19:05:04Z

Sieger66:

J3.x:Access Control List Tutorial/de

2019-12-26T19:01:49Z

Sieger66:

<noinclude><languages /></noinclude>
{{Joomla version|version=3.x|comment=Serie}}
{{-}}
{{:J3.1:Access_Control_List/en}}

==Separate ACL für Anzeige und Aktionen==

Das Joomla ACL-System besteht genau genommen aus zwei völlig getrennten Systemen. Das eine System steuert, was Benutzer auf der Website "sehen" können. Das andere steuert, was Benutzer "tun" können (welche Aktionen ein Benutzer durchführen kann). Die ACL wird für jedes dieser Systeme anders eingerichtet.

===Steuern, was Benutzer sehen können===

Das Setup zum Steuern, was Benutzer sehen können, sieht wie folgt aus:
*Eine Reihe von Zugriffsebenen gemäß den Kategorien und/oder der Kombination von Kategorien erstellen, die nur angemeldete Benutzer sehen sollen. Anmerkung: Zu diesem Zeitpunkt werden noch keine Benutzergruppen den neuen Zugriffsebenen zugewiesen.

*Für jede Zugriffsebene eine Benutzergruppe erstellen, die 'Registriert' als übergeordnete Gruppe hat. Indem man für Benutzergruppen und Zugriffsebenen die gleichen Namen verwendet, kann man Verwirrungen zu einem späteren Zeitpunkt vorbeugen.

*Die neuen Zugriffsebenen bearbeiten und jeder die (neue) Benutzergruppe zuweisen. Wahrscheinlich möchten man auch die 'Super Benutzer' Gruppe (und/oder die anderen Standard-Benutzergruppen mit Ausnahme der Benutzergruppe 'Gast') den neuen Zugriffsebenen zuweisen.

*Jedem anzuzeigenden Eintrag eine Zugriffsebene zuweisen. Einträge sind sowohl inhaltliche Einträge (Beiträge, Kontakte, usw.), Menüeinträge als auch Module.

Immer dann, wenn ein Benutzer im Begriff ist, einen Eintrag auf einer Joomla-Seite anzeigen zu lassen, prüft das Programm, ob dieser Benutzer auch Zugriff auf den Eintrag hat. Das geschieht folgendermaßen:
# Zunächst wird eine Liste aller Zugriffsebenen erstellt, auf die der Benutzer zugreifen kann, basierend auf allen Gruppen, denen der Benutzer angehört. Sofern eine Gruppe eine übergeordnete Gruppe besitzt, sind die Zugriffsebenen für die übergeordnete Gruppe ebenfalls in der Liste enthalten.
# Danach wird überprüft, ob die Zugriffsebene für den Eintrag (Beitrag, Modul, Menüeintrag, usw.) in dieser Liste enthalten ist. Wenn dem so ist, wird der Eintrag dem Benutzer angezeigt. Falls der Benutzer die benötigten Zugriffsrechte besitzt, wird ihm der Zugriff verweigert.

Beachten, dass Zugriffsebenen für jede Gruppe separat festgelegt und nicht von der übergeordneten Gruppe einer Gruppe vererbt werden.

===Steuern, was Benutzer tun können===

Das System, das steuert, was Benutzer in einer Benutzergruppe tun können - welche Aktionen sie bei einem bestimmten Eintrag ausführen können - wird über den Tab 'Berechtigungen' in der Konfiguration und den Tab 'Berechtigungen' in den Optionen jeder einzelnen Komponente eingerichtet. Berechtigungen können auch auf Kategorienebene (bei Kernkomponenten) und auf Beitragsebene (bei Beiträgen) gesetzt werden.

* Wenn angemeldete Benutzer in bestimmten Kategorien Erstellen, Löschen, Status bearbeiten oder Eigene Inhalte bearbeiten dürfen, dann:
** Eine Benutzergruppe erstellen und als übergeordnete Gruppe eine der Benutzergruppen angeben, die Zugriff auf die Kategorie (oder Kategorien) haben, die diese neue Benutzergruppe ändern soll.
**Der neuen Benutzergruppe den entsprechenden Zugriffsebenen zuweisen. Dann die erforderlichen Berechtigungen für die neue Benutzergruppe entweder global oder pro Kategorie/Beitrag ändern.
*** Beim Erstellen einer Benutzergruppe ist es ratsam, eine übergeordnete Gruppe zu wählen, die über weniger Berechtigungen verfügt, als für die neue Gruppe erforderlich. Denn es ist einfacher, die Berechtigungen für jede Komponente/Kategorie/Beitrag zu erweitern, für die zusätzliche Berechtigungen nötig sind, als Berechtigungen aus den anderen Komponenten/Kategorien/Beiträgen zu entfernen.
****''(Beispiel: Es gibt 10 Kategorien, man möchte aber nur für eine Erstellen-Berechtigungen. Würde man für diese Gruppe die Berechtigungen global auf Erstellen erlaubt setzen, müsste man für diese Kategorien die Erstellen-Berechtigung entfernen. Und man müsste für diese Gruppe die Erstellen-Berechtigung bei jeder neuen Kategorie, die man zu einem späteren Zeitpunkt hinzufügt, ebenfalls entfernen).''
** Eine Benutzergruppe erstellen, die eine der Standardbenutzergruppen als übergeordnete Gruppe hat, NUR, wenn keine von diesen über die exakten Berechtigungen verfügt, die man benötigt und sich für alle Kategorien wünscht.

Beachten, dass dieses Setup unabhängig vom Setup für die Anzeige ist. Allerdings muss eine Benutzergruppe den entsprechenden Zugriffsebenen zugewiesen werden, damit der Benutzer in dieser Gruppe jene Berechtigungen verwenden kann.

Möchte ein Benutzer eine bestimmte Aktion bei einem Komponenten-Eintrag durchführen (z. B. einen Beitrag bearbeiten), überprüft das System (nachdem es überprüft hat, welcher Gruppe der Benutzer angehört und auf welche er Zugriff hat) die Berechtigung für diese Kombination aus Benutzer, Eintrag und Aktion. Liegt eine Erlaubnis vor, kann der Benutzer fortfahren. Andernfalls ist die Aktion nicht zulässig.

Das restliche Tutorial befasst sich mit der Steuerung, was Benutzer tun können - welche Aktionsberechtigungen sie haben.

==Aktionen, Gruppen und Vererbung==

Andererseits geht es bei der ACL auch darum, Benutzern Berechtigungen zu erteilen, damit diese Aktionen an Objekten durchführen können.

{| class="wikitable"
!style="width:20%;"|
!3.x Serie
|-
!Gruppen und Aktionen
|Aktionen, welche pro Gruppe erlaubt sind, werden durch den Website Administrator festgelegt.
|-
!Umfang von Berechtigungen
|Berechtigungen können auf mehreren Ebenen in der Hierarchie festgelegt werden: Website, Komponente, Kategorie, Objekt.
|-
!Vererbung von Berechtigungen
|Berechtigungen können von übergeordneten Gruppen und übergeordneten Kategorien geerbt werden.
|}

===Wie die Berechtigungen funktionieren===

Es gibt vier mögliche Berechtigungen für Aktionen. Diese sind (kurz skizziert):

* '''Nicht gesetzt''': Fällt standardmäßig auf "Nicht erlaubt" zurück. Aber im Gegensatz zur Berechtigung "Verweigert" kann diese Berechtigung außer Kraft gesetzt werden, wenn eine untergeordnete Gruppe oder eine in der Berechtigungshierarchie untergeordnete Ebene auf "Erlaubt" gesetzt wird. Diese Berechtigung kann nur für globale Berechtigungen der Konfiguration gesetzt werden.
* '''Vererbt''': Erbt den Wert von einer übergeordneten Gruppe oder einer in der Berechtigungshierarchie höheren Ebene. Diese Berechtigung gilt für alle Ebenen mit Ausnahme der obersten Ebene der Konfiguration.
* '''Verweigert''': Verbietet diese Aktion für diese Ebene und Gruppe. '''WICHTIG:''' Dadurch wird diese Aktion auch für alle untergeordneten Gruppen und alle untergeordneten Ebenen in der Berechtigungshierarchie verboten. Wird "Erlaubt" in einer untergeordneten Gruppe oder einer tieferen Ebene gesetzt, hat das keinen Effekt. Die Aktion wird immer für alle Mitglieder einer untergeordneten Gruppe und für alle untergeordneten Ebenen in der Berechtigungshierarchie abgelehnt.
* '''Erlaubt ''': Genehmigt diese Aktion für diese Ebene und Gruppe und für tiefere Ebenen und Untergruppen. Dies hat keine Auswirkungen, wenn eine höhere Gruppe oder Ebene auf "Verweigert" oder "Erlaubt" eingestellt ist. Wenn eine höhere Gruppe oder ein höheres Ebene auf "Verweigert" gesetzt ist, wird diese Berechtigung immer abgelehnt. Wenn eine höhere Gruppe oder Ebene auf Erlaubt eingestellt ist, ist diese Berechtigung bereits erlaubt.

===Hierarchie der Berechtigungsebenen===

Berechtigungen für Aktionen können in Version 2.5+ auf bis zu vier Ebenen festgelegt werden, wie folgt:
# '''Konfiguration''': legt die Standardberechtigungen für jede Aktion und Gruppe fest.
# '''Komponenten-Optionen-> Berechtigungen''': kann die Standardberechtigungen für diese Komponente überschreiben (z. B. Beiträge, Menüs, Benutzer, Banner usw.).
# '''Kategorie''': kann die Standardberechtigungen für Objekte in einer oder mehreren Kategorien überschreiben. Gilt für alle Komponenten mit Kategorien, einschließlich Beiträge, Banner, Kontakte, Newsfeeds und Weblinks.
# '''Beitrag''': kann die Berechtigungen für einen bestimmten Artikel überschreiben. Diese Ebene gilt nur für Beiträge. Alle anderen Komponenten erlauben nur die ersten drei Ebenen.

====Konfiguration====
Diese erreicht man über System → Konfiguration → Berechtigungen. Die nun sichtbare Maske dient dazu, die Berechtigungen auf der obersten Ebene für jede Gruppe und jede Aktion festzulegen, wie auch in der folgenden Abbildung gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Die möglichen Werte sind Vererbt, Erlaubt oder Verweigert. Die Spalte 'Errechnete Einstellung' zeigt die aktuelle Einstellung an. Diese ist entweder Nicht erlaubt (Standard), Erlaubt oder Nicht erlaubt.

Man kann immer nur an einer Gruppe gleichzeitig arbeiten, indem man den Reiter für ebendiese Gruppe anklickt. Die Berechtigungen kann man über die Dropdownlisten unter Neue Einstellung wählen ändern.

Beachten Sie, dass die Spalte "Errechnete Einstellung" erst aktualisiert wird, wenn Sie auf die Schaltfläche "Speichern" in der Werkzeugleiste klicken.

Um zu überprüfen, ob die Einstellungen Ihren Wünschen entsprechen, klicken Sie auf die Schaltfläche Speichern und überprüfen anschließend die Spalte Errechnete Einstellung.

====Komponenten-Optionen->Berechtigungen====
Auf diese wird für jede Komponente durch Klicken auf das Symbol "Optionen" in der Werkzeugleiste zugegriffen. Dieser Bildschirm ist ähnlich wie der Bildschirm "Globale Konfiguration" oben links. Wenn Sie beispielsweise im Menü-Manager auf das Symbol in der Werkzeugleiste Optionen klicken, werden die folgenden Menüs angezeigt.
[[Image:Screenshot_menu_acl_J3_tutorial-en.jpg]]

Der Zugriff auf Optionen ist nur für Mitglieder von Gruppen möglich, die die Berechtigung für die Aktion Konfiguration in für jede Komponente haben. Im obigen Beispiel hat die Gruppe Administrator die Berechtigung Erlaubt für die Option Konfigurieren, so dass Mitglieder dieser Gruppe auf diesen Bildschirm zugreifen können.

===Kategorie===
Auf die Kategorieberechtigungen wird im Category Manager zugegriffen: Bildschirm Kategorie bearbeiten, in einer Registerkarte oben auf dem Bildschirm. Dieser Bildschirm hat fünf Berechtigungen, wie folgt:

[[Image:Screenshot_category_acl_j3_tutorial-en.png]]

In diesen Bildern bearbeiten Sie die Berechtigungen für jeweils eine Benutzergruppe. Im obigen Beispiel bearbeiten Sie die Berechtigungen für die Gruppe Administrator.

Achten Sie darauf, dass die Aktionen "Konfigurieren und Zugriffssteuerung" nicht auf der Kategorieebene angewendet werden, so dass diese Aktionen nicht enthalten sind.

Beachten Sie auch, dass Kategorien in einer Hierarchie angeordnet werden können. Wenn ja, dann werden Aktionsberechtigungen in einer übergeordneten Kategorie automatisch an eine untergeordnete Kategorie vererbt. Wenn Sie beispielsweise eine Kategoriehierarchie von Tieren → Haustiere → Hunde hätten, dann würde die vollständige Berechtigungshierarchie für einen Artikel in der Kategorie Hunde wie folgt aussehen:
* Globale Konfiguration
* Artikel-Manager → Optionen → Genehmigung → Erlaubnis
* Tierkategorie
* Kategorie Haustiere
* Kategorie Hunde
* spezifischer Artikel

====Beitrag====
Berechtigungen für einzelne Beiträge findet man im "Beitrag" unter dem Tab-Reiter "Berechigungen". Dieser Bildschirm hat drei Aktionen, wie unten gezeigt.

[[Image:j3x_acl_tutorial_article_manager_article_permissions-en.png]]

Auch hier bearbeiten Sie jede Gruppe für sich. Um auf die Berechtigungen zuzugreifen wechseln Sie im Artikel auf den Reiter "Berechtigungen" im oberen Reiter. Über das Drop Down Menü wählen Sie die neue Berechtigung im Anschluss speichern Sie den Beitrag ab.

Beachten Sie, dass die Aktionen Configure, Access Component und Create auf Artikelebene nicht gelten, so dass diese Aktionen nicht berücksichtigt werden. Die Berechtigung zum Anlegen eines Artikels wird auf einer der höheren Ebenen der Hierarchie festgelegt.

===Zugriffsebenen===

Die Zugriffsebenen der 3.x-Serie sind einfach und flexibel. Der folgende Bildschirm zeigt die spezielle Zugriffsebene.
[[Image:j3x_acl_tutorial_viewing_levels-en.png|center]]
Aktivieren Sie einfach das Kontrollkästchen für jede Gruppe, die Sie in diesem Level aufnehmen wollen. Die spezielle Zugriffsebene umfasst die Gruppen Manager, Autor und Superuser. Es beinhaltet auch untergeordnete Gruppen dieser Gruppen. Die Gruppe Administrator ist also enthalten, da es sich um eine Untergruppe der Gruppe Manager handelt. Die Gruppen Editor, Publisher und Shop Suppliers sind enthalten, da es sich um Untergruppen des Autors handelt.

Jedem Objekt im Frontend ist eine Zugriffsebene zugeordnet. Wenn die Ebene öffentlich ist, kann jeder auf dieses Objekt zugreifen. Andernfalls dürfen nur Mitglieder von Gruppen, die dieser Zugriffsebene zugeordnet sind, auf dieses Objekt zugreifen.

Die Zugriffsebenen sind den Menüpunkten und den Modulen zugeordnet. Jede kann nur einer Zugriffsebene zugeordnet werden.

Der folgende Bildschirm zeigt beispielsweise den Bildschirm Menüpunkt bearbeiten mit der Liste der verfügbaren Zugriffsebenen....

[[Image:j3x_acl_tutorial_edit_menu_item_level_dropdown-en.png|center]]

==Standard-ACL-Setup==

Wenn Joomla! installiert ist, werden diese auf die ursprünglichen Standardwerte gesetzt. Wir werden diese Grundeinstellungen besprechen, um die Arbeitsweise der ACL zu verstehen.

===Standardgruppen===

Mit der Version 3.x können Sie Ihre individuellen Gruppen definieren. Wenn Sie die Version 3.x installieren, enthält sie eine Reihe von Standardgruppen, die im Folgenden dargestellt werden, sind die grundlegenden Standardbenutzergruppen. (Zusätzliche Standardbenutzergruppen werden mit Beispieldaten installiert)

[[Image:Screenshot_usergroupsl_acl_J3_tutorial-en.png|center]]

Die Pfeile zeigen die untergeordneten Elternbeziehungen an. Wie vorstehend besprochen, wird diese Berechtigung, wenn Sie eine Berechtigung für eine übergeordnete Gruppe festlegen, automatisch an alle Untergruppen vererbt. Die vererbten und zulässigen Berechtigungen können für eine Untergruppe überschrieben werden. Die Berechtigung Verweigert kann nicht überschrieben werden und verweigert immer eine Aktion für alle Untergruppen.

===Konfiguration===

Joomla! Version 3.x wird mit den gleichen bekannten Backend-Rechten wie die Version 1.5 (EOL) installiert. Mit der Version 3.x können Sie diese jedoch leicht an die Bedürfnisse Ihrer Website anpassen.

Wie bereits besprochen, werden die Berechtigungen für jede Aktion von der obigen Ebene in der Berechtigungshierarchie und von der übergeordneten Gruppe einer Gruppe übernommen. Also, wie funktioniert das? Die oberste Ebene dafür ist der gesamte Standort. Dies wird in der Site->Globale Konfiguration->Berechtigungen eingerichtet, wie unten gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Das erste, was man bemerken sollte, sind die zehn Aktionen: Standortlogin, Admin-Login, Offline-Zugriff, Superuser, Access Administration Interface, Erstellen, Löschen, Bearbeiten, Status bearbeiten und Eigenes bearbeiten. Dies sind die Aktionen, die ein Benutzer an einem Objekt in Joomla durchführen kann. Die spezifische Bedeutung jeder Aktion hängt vom Kontext ab. Für das Bild Globale Konfiguration sind sie wie folgt definiert:

Site Login : Login to the front end of the site

;Admin Login : Melden Sie sich am Backend der Website an.

Offline-Zugriff: Melden Sie sich am Frontend der Website an, wenn die Website offline ist (wenn die globale Konfigurationseinstellung "Site Offline" auf Ja gesetzt ist).

Superuser: Gewährt dem Benutzer den Status "Superuser". Benutzer mit dieser Berechtigung dürfen alles auf der Website machen. Nur Benutzer mit dieser Berechtigung können die Einstellungen der globalen Konfiguration ändern. Diese Berechtigungen können nicht eingeschränkt werden. Es ist wichtig zu verstehen, dass, wenn ein Benutzer Mitglied einer Super Admin-Gruppe ist, alle anderen Berechtigungen, die diesem Benutzer zugewiesen sind, irrelevant sind. Der Benutzer kann jede Aktion auf der Website durchführen. Es können jedoch weiterhin Zugriffsebenen zugewiesen werden, um zu steuern, was diese Gruppe auf der Website sieht. (Natürlich kann ein Super-Admin-Benutzer die Zugriffsebenen ändern, wenn er möchte, so dass die Zugriffsebenen nicht vollständig einschränken, was ein Super-Admin-Benutzer sehen kann.)

Zugangskomponente: Öffnen Sie die Bildschirme der Komponentenverwaltung (Benutzerverwaltung, Menüverwaltung, Artikelverwaltung usw.).

;Create : Create new objects (for example, users, menu items, articles, weblinks, and so on)

;Löschen : Löschen eines existienden Objekts

;Ändern : Ändern eines existierenden Objektes

;Ändern eines Objekt Status (Veröffentlicht, nicht Veröffentlicht, Archiviert und Gelöscht)

Eigene Objekte bearbeiten: Bearbeiten Sie Objekte, die Sie erstellt haben.

Each Group for the site has its own slider which is opened by clicking on the group name. In this case (with the sample data installed), we have the standard 7 groups that we had in version 1.5 plus two additional groups called "Shop Suppliers" and "Customer Group". Notice that our groups are set up with the same permissions as they had in version 1.5. Keep in mind that we can change any of these permissions to make the security work the way we want. Let's go through this to see how it works.

* '''Public''' has everything set to "Not set", as shown below.{{-}}[[Image:Screenshot_global_acl_public_J3_tutorial-en.png]]
**This can be a bit confusing. Basically, "Not Set" is the same as "Inherited". Because Public is our top-level group, and because Global Configuration is the top level of the component hierarchy, there is nothing to inherit from. So "Not Set" is used instead of "Inherit".
**The default in this case is for no permissions. So, as you would expect, the Public group has no special permissions. Also, it is important to note that, since nothing is set to Denied, all of these permissions may be overridden by child groups or by lower levels in the permission hierarchy.

* '''Guest''' is a 'child' group of the Public group has everything set to 'Inherited' {{-}}[[Image:Screenshot_global_acl_guest_J3_tutorial-de.png]]
** This is the default 'Guest User Group' in the User Manager options and the Group that (non logged in) visitors to your site are placed in.

* '''Manager''' is a "child" group of the Public group. It has Allowed permissions for everything except Access Component and Super Admin. So a member of this group can do everything in the front and back end of the site except change Global Permissions and Component Options. {{-}}[[Image:Screenshot_global_acl_manager_J3_tutorial-en.png]]

* '''Administrator''' group members inherit all of the Manager permissions and also have Allowed for Access Component. So members of this group by default can access the Options screens for each component. {{-}}[[Image:Screenshot_global_acl_administrator_J3_tutorial-en.png]]

* '''Registered''' is the same a Public except for the Allow permission for the Site Login action. This means that members of the Registered group can login to the site. Since default permissions are inherited, this means that, unless a child group overrides this permission, all child groups of the Registered group will be able to login as well. {{-}}[[Image:Screenshot_global_acl_registered_J3_tutorial-en.png]]

* '''Author''' is a child of the Registered group and inherits its permissions and also adds Create and Edit Own. Since Author, Editor, and Publisher have no back-end permissions, we will discuss them below, when we discuss front-end permissions.{{-}}[[Image:Screenshot_global_acl_author_J3_tutorial-en.png]]

* '''Editor''' is a child of the Authors group and adds the Edit permission. {{-}}[[Image:Screenshot_global_acl_editor_J3_tutorial-en.png]]

* '''Publisher''' is a child of Editor and adds the Edit State permission.{{-}}[[Image:Screenshot_global_acl_publisher_J3_tutorial-en.png]]

* '''Shop Suppliers''' is an example group that is installed if you install the sample data. It is a child group of Author.

* '''Customer Group''' is an example group that is installed if you install the sample data. It is a child group of Registered.

* '''Super Users''' group has the Allow permission for the Super Admin action. Because of this, members of this group have super user permissions throughout the site. They are the only users who can access and edit values on the Global Configuration screen. Users with permission for the Super Admin action have some special characteristics:
:* If a user has Super Admin permissions, no other permissions for this user matter. The user can perform any action on the site.
:* Only Super Admin users can create, edit, or delete other Super Admin users or groups.

There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.

This provides a lot of flexibility. For example, if you wanted Shop Suppliers to be able to have the ability to login to the back end, you could just change their Admin Login value to "Allowed". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherited (or Denied).

It is also important to understand that the ability to have child groups is completely optional. It allows you to save some time when setting up new groups. However, if you like, you can set up all groups to have Public as the parent and not inherit any permissions from a parent group.

===Komponenten-Optionen & Berechtigungen===

Now, let's continue to see how the default back-end permissions for version 2.5 mimic the permissions for version 1.5. The Super Users group in 2.5 is equivalent to the Super Administrator group in 1.5.

Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 2.5 configuration. Let's see how this is accomplished.

If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:

[[Image:screenshot_acl_tutorial_20110111-09-en.png|center|]]
[[Image:screenshot_acl_tutorial_20110111-10-en.png|center|]]

This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.

First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.

Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.

If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.

In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.

It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.

===Frontend Berechtigungen===

Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions. First, let's look at the permissions for Manager, as shown below.
[[Image:screenshot_acl_tutorial_20110111-11a-en.png|center|frame]]
Manager has allowed permission for all actions except Configure. So members of the Manager group can do everything with Articles except open the Options screen.

Now let's look at Administrator, as shown below.
[[Image:screenshot_acl_tutorial_20110111-12a-en.png|center|frame]]
Administrator has Allowed for Configure, so Administrators can edit this Options screen.

Both groups can create, delete, edit, and change the state of articles.

Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set.

Authors only have Create and Edit Own permissions, as shown below.
[[Image:screenshot_acl_tutorial_20110112-07-en.png|center|frame]]
This means that Authors can create articles and can edit articles they have created. They may not delete articles, change the published state of articles, or edit articles created by others.

Editors have the same permissions as Authors with the addition of permission for the Edit action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-08-en.png|center|frame]]
So Editors can edit articles written by anyone.

Publishers can do everything Editors can do plus they have permission for the Edit State action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-09-en.png|center|frame]]
So Publishers can change the published state of an article. The possible states include Published, Unpublished, Archived, and Trashed.

All of these groups have Inherit permission for Configure and Access Component. Remember that Author is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Configure and Access Component, and since Author's permission for these actions is "Inherited", then Author does not have these permissions either. This same permission is passed from Author to Editor and from Editor to Publisher. So, by default, none of these groups are allowed to work with articles in the back end.

It is important to remember that these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.

Beachte auch das in den ursprünglichen Standardwerten keine Berechtigungen auf Verweigert eingestellt sind. Dies ermöglicht in allen Berechtigungsebenen die jeweilige Berechtigung auf Erlaubt einzustellen. Bedenke, wenn eine Aktion auf Verweigert eingestellt ist, das diese Aktion auch in allen untergeordneten Ebenen in der Berechtigungshierarchie verweigert wird. Zum Beispiel, wenn die Seitenameldung für Registered auf Verweigert (anstatt auf Erlaubt) eingestellt wird, kann man Publishers diese Aktion per Berechtigungeinstellung nicht erteilen.

=== Beitrags-Manager & Aktions-Diagramm ===

The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.

[[Image:screenshot_acl_tutorial_20110111-16-de.png|center|]]

* '''Configure''' allows you to view and change the Options for the component.
* '''Access Component''' allows you to navigate to the Article Manager. Without this permission, no other actions are possible.
* '''Create''' allows you to add new articles.
* '''Delete''' allows you to delete trashed articles. Note that the Delete icon only shows in the toolbar when you have the "Select State" filter set to "Trash".
* '''Edit''' allows you to edit existing articles.
* '''Edit State''' allows to you Publish, Unpublish, Archive, or Trash articles.
* '''Edit Own''' is the same as Edit except that it only applies to articles written by you.

==Allowing Guest-Only Access to Menu Items and Modules==

Version 1.6 introduced the ability to create a View Access Level that is only for guests of the site (meaning a user who is not logged in). The example below shows how you can set up this new feature.
''(N.B. Steps 1 to 3 are not needed for Joomla! 3.x as they exist in the default install)''

#Create a new user group called Guest. Make it a child of the Public group as shown below. [[Image:screenshot_acl_tutorial_20110112-01-de.png|center|frame]]
# Create a new access level called Guest and grant only the Guest group access to this level, as shown below.[[Image:screenshot_acl_tutorial_20110112-02-de.png|center|frame]]
# Navigate to User Manager→Options→Component and change the Guest User Group from the default value of "Public" to "Guest", as shown below.
[[Image:screenshot_acl_tutorial_20110112-04-de.png|center|frame]]
Now, if we assign a menu item, module, or other object to the Guest access level, only non-logged in users will have access. For example, if we create a new menu item with access level of Guest, as shown below,
[[Image:screenshot_acl_tutorial_20110112-05-de.png|center|frame]]
this menu item will only be visible to non-logged-in visitors to the site.

If required other user groups like Author can be granted access in the Guest access level, this would allow Authors to view articles in the front end for editing.

'''N.B. Login/logout in front end (''for changing data in session'') to see the change.'''

==Berechtigungen und Gruppenebenen gemeinsam nutzen==

As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.

This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:

* both groups can create new articles only in the History Assignments category.

* only History Teachers (not Assistant History Teachers) can Publish or otherwise have Edit State permission.

This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.

[[Image:Acl example diagram1 20091018-de.png|center|]]

In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.

To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.

Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.

[[Image:Acl example diagram2 20091018-de.png|center|]]

This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.

Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.

==ACL Aktion Berechtigungs-Beispiele==

===Backend Beitrag Administrator===

'''Problem:'''

We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.

'''Lösung:'''

# Create a new group called Article Administrator and make its parent group Public, as shown below.[[Image:screenshot_acl_tutorial_20110112-10-de.png|center|frame]] Because its parent group is Public, it won't have any permissions by default.
# In Users → Access Levels, edit the Special Access level to add the new group. That way they can get access to the back end menu items and modules (This assumes that the modules for the admin menu and quickicons have the Special Access level assigned to them, which is the default.) [[Image:screenshot_acl_tutorial_20110112-11-de.png|center|frame]] By default, the back-end menu items and modules are set to Special access, so if you forget to add the new group to the Special access level, you won't see any modules or menu items when you log in as a user of the new group.
# In Site → Global Configuration → Permissions, click on the Article Administrator group and change the permissions to Allowed for the following actions: Admin Login, Create, Delete, Edit, Edit State, and Edit Own. The screen below shows what will show before you press Save. [[Image:screenshot_acl_tutorial_20110112-12-de.png|center|frame]]After you save, the Calculated Permissions should show as shown below.[[Image:screenshot_acl_tutorial_20110112-13-de.png|center|frame]]Note that the permission for the Access Component is Inherited, which translates to Not Allowed. This is important. This means that this group will only be able to access components if we give the group "Allowed" permission for Access Component. So we only have to change the one component we want to give them access to and don't have to change any settings for the components where we don't want them to have access. If we had a case where we wanted to give a group access to everything except for one component, we could set the default to Allowed and then set the one component to Denied. Also note that we did not give the group Site Login permission, so users in this group will not be able to log into the front end. (If we wanted to allow that, we would just change the permission to Allowed for Site Login.)
# In Article Manager → Options → Permissions, change permissions to Allowed for this group for the Access Component action, as shown below.[[Image:screenshot_acl_tutorial_20110112-14-de.png|center|frame]]All of the other desired permissions are inherited.

That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end. For example, the screen below shows what a user in the Article Manager will see when they login to the back end.[[Image:screenshot_acl_tutorial_20110112-15-de.png|center|frame]]

==ACL Ansicht Zugriffsebenen-Beispiele==

A basic concept of using Access Levels is that all items with the same Access will be viewable by the same group of users. In other words, if two items have the same Access, you can't have one viewable by one user and not viewable by another user. On the other hand, it is easy to have one Group view any number of items with different Access levels.

Similarly, each Group has exactly the same combination of Access levels, but one User can be a member of more than one group. Depending on the situation, you may want to have users only in one Group or you may need to have a User in more than one Group.

This means that we may need to group our items so that items so that all items in a group have the same level of sensitivity. Here are some examples.

===Hierarchisches Beispiel===
In this example, Access levels are hierarchical, for example, like government security clearance codes. Say for example we have the following sets of classified documents: Classified, Secret, and Top Secret. Users have corresponding clearence codes. Users with Classified clearance can only see Classified documents and cannot see Secret or Top Secret. Users with Secret clearance can see Classified and Secret documents but not Top Secret. Users with Top Secret can see all documents.

In this case, you would create three Access levels: Classified, Secret, and Top Secret and the same three Groups. Users would only be members of one group, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| C1, C2, C3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Classified
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| S1, S2, S3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| TS1, TS2, TS3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Top Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret, Top Secret

|}

In this case, all users are in exactly one group, but some groups have access to more than one Access Level of items. In other words, we have a one-to-one relationship between users and groups, but a one-to-many relationship between Groups and Access Levels.

===Teamsicherheit Beispiel===

Another possible use case is a set of non-hierarchical teams. Let's say we have three teams, T1, T2, and T3. Some users are only on one team, but others might be on two or more teams. In this case, we could set up our Access Levels and Groups by team. Documents for each team have the access level for that team, and the Group for the team has only the one access level. When a User is on more than one team, they get added to the group for each team, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Beschreibung
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 1 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 2 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 3 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1, 2 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1,T2, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2, T3

|}

===Hybrid Example===

In a real-world situation, you might have a combination of these two arrangements. Say for example we have Managers and Staff. Staff can only see Staff documents and Managers can see Manager and Staff documents. Both types of users can be assigned to teams as well, in which case they can see all of the documents for that team. In addition, say that Managers can access some, but not all, team documents. Staff can only access team documents if they are members of that team.

In this example, we could set up the following Access Levels:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Access Level
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Description
| style="border:0.0007in solid #000000;padding:0.0382in;"| Groups

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team manager documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team staff documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team1 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1, Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team2 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2, Manager

|}

Then, users could be assigned to groups as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| User Type
| style="border:0.0007in solid #000000;padding:0.0382in;"| Group

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1, Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1, Team2

|}

<noinclude>
[[Category:Joomla! 1.6]]
[[Category:Joomla! 2.5]]
[[Category:Joomla! 3.x/de]]
[[Category:Tutorials/de]]
[[Category:Access Control/de]]
[[Category:Access Management]]
</noinclude>

Translations:J3.x:Access Control List Tutorial/149/de

2019-12-26T19:01:48Z

Sieger66:

J3.x:Access Control List Tutorial/de

2019-12-26T19:01:38Z

Sieger66:

<noinclude><languages /></noinclude>
{{Joomla version|version=3.x|comment=Serie}}
{{-}}
{{:J3.1:Access_Control_List/en}}

==Separate ACL für Anzeige und Aktionen==

Das Joomla ACL-System besteht genau genommen aus zwei völlig getrennten Systemen. Das eine System steuert, was Benutzer auf der Website "sehen" können. Das andere steuert, was Benutzer "tun" können (welche Aktionen ein Benutzer durchführen kann). Die ACL wird für jedes dieser Systeme anders eingerichtet.

===Steuern, was Benutzer sehen können===

Das Setup zum Steuern, was Benutzer sehen können, sieht wie folgt aus:
*Eine Reihe von Zugriffsebenen gemäß den Kategorien und/oder der Kombination von Kategorien erstellen, die nur angemeldete Benutzer sehen sollen. Anmerkung: Zu diesem Zeitpunkt werden noch keine Benutzergruppen den neuen Zugriffsebenen zugewiesen.

*Für jede Zugriffsebene eine Benutzergruppe erstellen, die 'Registriert' als übergeordnete Gruppe hat. Indem man für Benutzergruppen und Zugriffsebenen die gleichen Namen verwendet, kann man Verwirrungen zu einem späteren Zeitpunkt vorbeugen.

*Die neuen Zugriffsebenen bearbeiten und jeder die (neue) Benutzergruppe zuweisen. Wahrscheinlich möchten man auch die 'Super Benutzer' Gruppe (und/oder die anderen Standard-Benutzergruppen mit Ausnahme der Benutzergruppe 'Gast') den neuen Zugriffsebenen zuweisen.

*Jedem anzuzeigenden Eintrag eine Zugriffsebene zuweisen. Einträge sind sowohl inhaltliche Einträge (Beiträge, Kontakte, usw.), Menüeinträge als auch Module.

Immer dann, wenn ein Benutzer im Begriff ist, einen Eintrag auf einer Joomla-Seite anzeigen zu lassen, prüft das Programm, ob dieser Benutzer auch Zugriff auf den Eintrag hat. Das geschieht folgendermaßen:
# Zunächst wird eine Liste aller Zugriffsebenen erstellt, auf die der Benutzer zugreifen kann, basierend auf allen Gruppen, denen der Benutzer angehört. Sofern eine Gruppe eine übergeordnete Gruppe besitzt, sind die Zugriffsebenen für die übergeordnete Gruppe ebenfalls in der Liste enthalten.
# Danach wird überprüft, ob die Zugriffsebene für den Eintrag (Beitrag, Modul, Menüeintrag, usw.) in dieser Liste enthalten ist. Wenn dem so ist, wird der Eintrag dem Benutzer angezeigt. Falls der Benutzer die benötigten Zugriffsrechte besitzt, wird ihm der Zugriff verweigert.

Beachten, dass Zugriffsebenen für jede Gruppe separat festgelegt und nicht von der übergeordneten Gruppe einer Gruppe vererbt werden.

===Steuern, was Benutzer tun können===

Das System, das steuert, was Benutzer in einer Benutzergruppe tun können - welche Aktionen sie bei einem bestimmten Eintrag ausführen können - wird über den Tab 'Berechtigungen' in der Konfiguration und den Tab 'Berechtigungen' in den Optionen jeder einzelnen Komponente eingerichtet. Berechtigungen können auch auf Kategorienebene (bei Kernkomponenten) und auf Beitragsebene (bei Beiträgen) gesetzt werden.

* Wenn angemeldete Benutzer in bestimmten Kategorien Erstellen, Löschen, Status bearbeiten oder Eigene Inhalte bearbeiten dürfen, dann:
** Eine Benutzergruppe erstellen und als übergeordnete Gruppe eine der Benutzergruppen angeben, die Zugriff auf die Kategorie (oder Kategorien) haben, die diese neue Benutzergruppe ändern soll.
**Der neuen Benutzergruppe den entsprechenden Zugriffsebenen zuweisen. Dann die erforderlichen Berechtigungen für die neue Benutzergruppe entweder global oder pro Kategorie/Beitrag ändern.
*** Beim Erstellen einer Benutzergruppe ist es ratsam, eine übergeordnete Gruppe zu wählen, die über weniger Berechtigungen verfügt, als für die neue Gruppe erforderlich. Denn es ist einfacher, die Berechtigungen für jede Komponente/Kategorie/Beitrag zu erweitern, für die zusätzliche Berechtigungen nötig sind, als Berechtigungen aus den anderen Komponenten/Kategorien/Beiträgen zu entfernen.
****''(Beispiel: Es gibt 10 Kategorien, man möchte aber nur für eine Erstellen-Berechtigungen. Würde man für diese Gruppe die Berechtigungen global auf Erstellen erlaubt setzen, müsste man für diese Kategorien die Erstellen-Berechtigung entfernen. Und man müsste für diese Gruppe die Erstellen-Berechtigung bei jeder neuen Kategorie, die man zu einem späteren Zeitpunkt hinzufügt, ebenfalls entfernen).''
** Eine Benutzergruppe erstellen, die eine der Standardbenutzergruppen als übergeordnete Gruppe hat, NUR, wenn keine von diesen über die exakten Berechtigungen verfügt, die man benötigt und sich für alle Kategorien wünscht.

Beachten, dass dieses Setup unabhängig vom Setup für die Anzeige ist. Allerdings muss eine Benutzergruppe den entsprechenden Zugriffsebenen zugewiesen werden, damit der Benutzer in dieser Gruppe jene Berechtigungen verwenden kann.

Möchte ein Benutzer eine bestimmte Aktion bei einem Komponenten-Eintrag durchführen (z. B. einen Beitrag bearbeiten), überprüft das System (nachdem es überprüft hat, welcher Gruppe der Benutzer angehört und auf welche er Zugriff hat) die Berechtigung für diese Kombination aus Benutzer, Eintrag und Aktion. Liegt eine Erlaubnis vor, kann der Benutzer fortfahren. Andernfalls ist die Aktion nicht zulässig.

Das restliche Tutorial befasst sich mit der Steuerung, was Benutzer tun können - welche Aktionsberechtigungen sie haben.

==Aktionen, Gruppen und Vererbung==

Andererseits geht es bei der ACL auch darum, Benutzern Berechtigungen zu erteilen, damit diese Aktionen an Objekten durchführen können.

{| class="wikitable"
!style="width:20%;"|
!3.x Serie
|-
!Gruppen und Aktionen
|Aktionen, welche pro Gruppe erlaubt sind, werden durch den Website Administrator festgelegt.
|-
!Umfang von Berechtigungen
|Berechtigungen können auf mehreren Ebenen in der Hierarchie festgelegt werden: Website, Komponente, Kategorie, Objekt.
|-
!Vererbung von Berechtigungen
|Berechtigungen können von übergeordneten Gruppen und übergeordneten Kategorien geerbt werden.
|}

===Wie die Berechtigungen funktionieren===

Es gibt vier mögliche Berechtigungen für Aktionen. Diese sind (kurz skizziert):

* '''Nicht gesetzt''': Fällt standardmäßig auf "Nicht erlaubt" zurück. Aber im Gegensatz zur Berechtigung "Verweigert" kann diese Berechtigung außer Kraft gesetzt werden, wenn eine untergeordnete Gruppe oder eine in der Berechtigungshierarchie untergeordnete Ebene auf "Erlaubt" gesetzt wird. Diese Berechtigung kann nur für globale Berechtigungen der Konfiguration gesetzt werden.
* '''Vererbt''': Erbt den Wert von einer übergeordneten Gruppe oder einer in der Berechtigungshierarchie höheren Ebene. Diese Berechtigung gilt für alle Ebenen mit Ausnahme der obersten Ebene der Konfiguration.
* '''Verweigert''': Verbietet diese Aktion für diese Ebene und Gruppe. '''WICHTIG:''' Dadurch wird diese Aktion auch für alle untergeordneten Gruppen und alle untergeordneten Ebenen in der Berechtigungshierarchie verboten. Wird "Erlaubt" in einer untergeordneten Gruppe oder einer tieferen Ebene gesetzt, hat das keinen Effekt. Die Aktion wird immer für alle Mitglieder einer untergeordneten Gruppe und für alle untergeordneten Ebenen in der Berechtigungshierarchie abgelehnt.
* '''Erlaubt ''': Genehmigt diese Aktion für diese Ebene und Gruppe und für tiefere Ebenen und Untergruppen. Dies hat keine Auswirkungen, wenn eine höhere Gruppe oder Ebene auf "Verweigert" oder "Erlaubt" eingestellt ist. Wenn eine höhere Gruppe oder ein höheres Ebene auf "Verweigert" gesetzt ist, wird diese Berechtigung immer abgelehnt. Wenn eine höhere Gruppe oder Ebene auf Erlaubt eingestellt ist, ist diese Berechtigung bereits erlaubt.

===Hierarchie der Berechtigungsebenen===

Berechtigungen für Aktionen können in Version 2.5+ auf bis zu vier Ebenen festgelegt werden, wie folgt:
# '''Konfiguration''': legt die Standardberechtigungen für jede Aktion und Gruppe fest.
# '''Komponenten-Optionen-> Berechtigungen''': kann die Standardberechtigungen für diese Komponente überschreiben (z. B. Beiträge, Menüs, Benutzer, Banner usw.).
# '''Kategorie''': kann die Standardberechtigungen für Objekte in einer oder mehreren Kategorien überschreiben. Gilt für alle Komponenten mit Kategorien, einschließlich Beiträge, Banner, Kontakte, Newsfeeds und Weblinks.
# '''Beitrag''': kann die Berechtigungen für einen bestimmten Artikel überschreiben. Diese Ebene gilt nur für Beiträge. Alle anderen Komponenten erlauben nur die ersten drei Ebenen.

====Konfiguration====
Diese erreicht man über System → Konfiguration → Berechtigungen. Die nun sichtbare Maske dient dazu, die Berechtigungen auf der obersten Ebene für jede Gruppe und jede Aktion festzulegen, wie auch in der folgenden Abbildung gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Die möglichen Werte sind Vererbt, Erlaubt oder Verweigert. Die Spalte 'Errechnete Einstellung' zeigt die aktuelle Einstellung an. Diese ist entweder Nicht erlaubt (Standard), Erlaubt oder Nicht erlaubt.

Man kann immer nur an einer Gruppe gleichzeitig arbeiten, indem man den Reiter für ebendiese Gruppe anklickt. Die Berechtigungen kann man über die Dropdownlisten unter Neue Einstellung wählen ändern.

Beachten Sie, dass die Spalte "Errechnete Einstellung" erst aktualisiert wird, wenn Sie auf die Schaltfläche "Speichern" in der Werkzeugleiste klicken.

Um zu überprüfen, ob die Einstellungen Ihren Wünschen entsprechen, klicken Sie auf die Schaltfläche Speichern und überprüfen anschließend die Spalte Errechnete Einstellung.

====Komponenten-Optionen->Berechtigungen====
Auf diese wird für jede Komponente durch Klicken auf das Symbol "Optionen" in der Werkzeugleiste zugegriffen. Dieser Bildschirm ist ähnlich wie der Bildschirm "Globale Konfiguration" oben links. Wenn Sie beispielsweise im Menü-Manager auf das Symbol in der Werkzeugleiste Optionen klicken, werden die folgenden Menüs angezeigt.
[[Image:Screenshot_menu_acl_J3_tutorial-en.jpg]]

Der Zugriff auf Optionen ist nur für Mitglieder von Gruppen möglich, die die Berechtigung für die Aktion Konfiguration in für jede Komponente haben. Im obigen Beispiel hat die Gruppe Administrator die Berechtigung Erlaubt für die Option Konfigurieren, so dass Mitglieder dieser Gruppe auf diesen Bildschirm zugreifen können.

===Kategorie===
Auf die Kategorieberechtigungen wird im Category Manager zugegriffen: Bildschirm Kategorie bearbeiten, in einer Registerkarte oben auf dem Bildschirm. Dieser Bildschirm hat fünf Berechtigungen, wie folgt:

[[Image:Screenshot_category_acl_j3_tutorial-en.png]]

In diesen Bildern bearbeiten Sie die Berechtigungen für jeweils eine Benutzergruppe. Im obigen Beispiel bearbeiten Sie die Berechtigungen für die Gruppe Administrator.

Achten Sie darauf, dass die Aktionen "Konfigurieren und Zugriffssteuerung" nicht auf der Kategorieebene angewendet werden, so dass diese Aktionen nicht enthalten sind.

Beachten Sie auch, dass Kategorien in einer Hierarchie angeordnet werden können. Wenn ja, dann werden Aktionsberechtigungen in einer übergeordneten Kategorie automatisch an eine untergeordnete Kategorie vererbt. Wenn Sie beispielsweise eine Kategoriehierarchie von Tieren → Haustiere → Hunde hätten, dann würde die vollständige Berechtigungshierarchie für einen Artikel in der Kategorie Hunde wie folgt aussehen:
* Globale Konfiguration
* Artikel-Manager → Optionen → Genehmigung → Erlaubnis
* Tierkategorie
* Kategorie Haustiere
* Kategorie Hunde
* spezifischer Artikel

====Beitrag====
Berechtigungen für einzelne Beiträge findet man im "Beitrag" unter dem Tab-Reiter "Berechigungen". Dieser Bildschirm hat drei Aktionen, wie unten gezeigt.

[[Image:j3x_acl_tutorial_article_manager_article_permissions-en.png]]

Auch hier bearbeiten Sie jede Gruppe für sich. Um auf die Berechtigungen zuzugreifen wechseln Sie im Artikel auf den Reiter "Berechtigungen" im oberen Reiter. Über das Drop Down Menü wählen Sie die neue Berechtigung im Anschluss speichern Sie den Beitrag ab.

Beachten Sie, dass die Aktionen Configure, Access Component und Create auf Artikelebene nicht gelten, so dass diese Aktionen nicht berücksichtigt werden. Die Berechtigung zum Anlegen eines Artikels wird auf einer der höheren Ebenen der Hierarchie festgelegt.

===Zugriffsebenen===

Die Zugriffsebenen der 3.x-Serie sind einfach und flexibel. Der folgende Bildschirm zeigt die spezielle Zugriffsebene.
[[Image:j3x_acl_tutorial_viewing_levels-en.png|center]]
Aktivieren Sie einfach das Kontrollkästchen für jede Gruppe, die Sie in diesem Level aufnehmen wollen. Die spezielle Zugriffsebene umfasst die Gruppen Manager, Autor und Superuser. Es beinhaltet auch untergeordnete Gruppen dieser Gruppen. Die Gruppe Administrator ist also enthalten, da es sich um eine Untergruppe der Gruppe Manager handelt. Die Gruppen Editor, Publisher und Shop Suppliers sind enthalten, da es sich um Untergruppen des Autors handelt.

Jedem Objekt im Frontend ist eine Zugriffsebene zugeordnet. Wenn die Ebene öffentlich ist, kann jeder auf dieses Objekt zugreifen. Andernfalls dürfen nur Mitglieder von Gruppen, die dieser Zugriffsebene zugeordnet sind, auf dieses Objekt zugreifen.

Die Zugriffsebenen sind den Menüpunkten und den Modulen zugeordnet. Jede kann nur einer Zugriffsebene zugeordnet werden.

Der folgende Bildschirm zeigt beispielsweise den Bildschirm Menüpunkt bearbeiten mit der Liste der verfügbaren Zugriffsebenen....

[[Image:j3x_acl_tutorial_edit_menu_item_level_dropdown-en.png|center]]

==Standard-ACL-Setup==

Wenn Joomla! installiert ist, werden diese auf die ursprünglichen Standardwerte gesetzt. Wir werden diese Grundeinstellungen besprechen, um die Arbeitsweise der ACL zu verstehen.

===Standardgruppen===

Mit der Version 3.x können Sie Ihre individuellen Gruppen definieren. Wenn Sie die Version 3.x installieren, enthält sie eine Reihe von Standardgruppen, die im Folgenden dargestellt werden, sind die grundlegenden Standardbenutzergruppen. (Zusätzliche Standardbenutzergruppen werden mit Beispieldaten installiert)

[[Image:Screenshot_usergroupsl_acl_J3_tutorial-en.png|center]]

Die Pfeile zeigen die untergeordneten Elternbeziehungen an. Wie vorstehend besprochen, wird diese Berechtigung, wenn Sie eine Berechtigung für eine übergeordnete Gruppe festlegen, automatisch an alle Untergruppen vererbt. Die vererbten und zulässigen Berechtigungen können für eine Untergruppe überschrieben werden. Die Berechtigung Verweigert kann nicht überschrieben werden und verweigert immer eine Aktion für alle Untergruppen.

===Konfiguration===

Joomla! Version 3.x wird mit den gleichen bekannten Backend-Rechten wie die Version 1.5 (EOL) installiert. Mit der Version 3.x können Sie diese jedoch leicht an die Bedürfnisse Ihrer Website anpassen.

Wie bereits besprochen, werden die Berechtigungen für jede Aktion von der obigen Ebene in der Berechtigungshierarchie und von der übergeordneten Gruppe einer Gruppe übernommen. Also, wie funktioniert das? Die oberste Ebene dafür ist der gesamte Standort. Dies wird in der Site->Globale Konfiguration->Berechtigungen eingerichtet, wie unten gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Das erste, was man bemerken sollte, sind die zehn Aktionen: Standortlogin, Admin-Login, Offline-Zugriff, Superuser, Access Administration Interface, Erstellen, Löschen, Bearbeiten, Status bearbeiten und Eigenes bearbeiten. Dies sind die Aktionen, die ein Benutzer an einem Objekt in Joomla durchführen kann. Die spezifische Bedeutung jeder Aktion hängt vom Kontext ab. Für das Bild Globale Konfiguration sind sie wie folgt definiert:

Site Login : Login to the front end of the site

;Admin Login : Melden Sie sich am Backend der Website an.

Offline-Zugriff: Melden Sie sich am Frontend der Website an, wenn die Website offline ist (wenn die globale Konfigurationseinstellung "Site Offline" auf Ja gesetzt ist).

Superuser: Gewährt dem Benutzer den Status "Superuser". Benutzer mit dieser Berechtigung dürfen alles auf der Website machen. Nur Benutzer mit dieser Berechtigung können die Einstellungen der globalen Konfiguration ändern. Diese Berechtigungen können nicht eingeschränkt werden. Es ist wichtig zu verstehen, dass, wenn ein Benutzer Mitglied einer Super Admin-Gruppe ist, alle anderen Berechtigungen, die diesem Benutzer zugewiesen sind, irrelevant sind. Der Benutzer kann jede Aktion auf der Website durchführen. Es können jedoch weiterhin Zugriffsebenen zugewiesen werden, um zu steuern, was diese Gruppe auf der Website sieht. (Natürlich kann ein Super-Admin-Benutzer die Zugriffsebenen ändern, wenn er möchte, so dass die Zugriffsebenen nicht vollständig einschränken, was ein Super-Admin-Benutzer sehen kann.)

Zugangskomponente: Öffnen Sie die Bildschirme der Komponentenverwaltung (Benutzerverwaltung, Menüverwaltung, Artikelverwaltung usw.).

;Create : Create new objects (for example, users, menu items, articles, weblinks, and so on)

;Löschen : Löschen eines existienden Objekts

;Ändern : Ändern eines existierenden Objektes

;Ändern eines Objekt Status (Veröffentlicht, nicht Veröffentlicht, Archiviert und Gelöscht)

Eigene Objekte bearbeiten: Bearbeiten Sie Objekte, die Sie erstellt haben.

Each Group for the site has its own slider which is opened by clicking on the group name. In this case (with the sample data installed), we have the standard 7 groups that we had in version 1.5 plus two additional groups called "Shop Suppliers" and "Customer Group". Notice that our groups are set up with the same permissions as they had in version 1.5. Keep in mind that we can change any of these permissions to make the security work the way we want. Let's go through this to see how it works.

* '''Public''' has everything set to "Not set", as shown below.{{-}}[[Image:Screenshot_global_acl_public_J3_tutorial-en.png]]
**This can be a bit confusing. Basically, "Not Set" is the same as "Inherited". Because Public is our top-level group, and because Global Configuration is the top level of the component hierarchy, there is nothing to inherit from. So "Not Set" is used instead of "Inherit".
**The default in this case is for no permissions. So, as you would expect, the Public group has no special permissions. Also, it is important to note that, since nothing is set to Denied, all of these permissions may be overridden by child groups or by lower levels in the permission hierarchy.

* '''Guest''' is a 'child' group of the Public group has everything set to 'Inherited' {{-}}[[Image:Screenshot_global_acl_guest_J3_tutorial-de.png]]
** This is the default 'Guest User Group' in the User Manager options and the Group that (non logged in) visitors to your site are placed in.

* '''Manager''' is a "child" group of the Public group. It has Allowed permissions for everything except Access Component and Super Admin. So a member of this group can do everything in the front and back end of the site except change Global Permissions and Component Options. {{-}}[[Image:Screenshot_global_acl_manager_J3_tutorial-en.png]]

* '''Administrator''' group members inherit all of the Manager permissions and also have Allowed for Access Component. So members of this group by default can access the Options screens for each component. {{-}}[[Image:Screenshot_global_acl_administrator_J3_tutorial-en.png]]

* '''Registered''' is the same a Public except for the Allow permission for the Site Login action. This means that members of the Registered group can login to the site. Since default permissions are inherited, this means that, unless a child group overrides this permission, all child groups of the Registered group will be able to login as well. {{-}}[[Image:Screenshot_global_acl_registered_J3_tutorial-en.png]]

* '''Author''' is a child of the Registered group and inherits its permissions and also adds Create and Edit Own. Since Author, Editor, and Publisher have no back-end permissions, we will discuss them below, when we discuss front-end permissions.{{-}}[[Image:Screenshot_global_acl_author_J3_tutorial-en.png]]

* '''Editor''' is a child of the Authors group and adds the Edit permission. {{-}}[[Image:Screenshot_global_acl_editor_J3_tutorial-en.png]]

* '''Publisher''' is a child of Editor and adds the Edit State permission.{{-}}[[Image:Screenshot_global_acl_publisher_J3_tutorial-en.png]]

* '''Shop Suppliers''' is an example group that is installed if you install the sample data. It is a child group of Author.

* '''Customer Group''' is an example group that is installed if you install the sample data. It is a child group of Registered.

* '''Super Users''' group has the Allow permission for the Super Admin action. Because of this, members of this group have super user permissions throughout the site. They are the only users who can access and edit values on the Global Configuration screen. Users with permission for the Super Admin action have some special characteristics:
:* If a user has Super Admin permissions, no other permissions for this user matter. The user can perform any action on the site.
:* Only Super Admin users can create, edit, or delete other Super Admin users or groups.

There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.

This provides a lot of flexibility. For example, if you wanted Shop Suppliers to be able to have the ability to login to the back end, you could just change their Admin Login value to "Allowed". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherited (or Denied).

It is also important to understand that the ability to have child groups is completely optional. It allows you to save some time when setting up new groups. However, if you like, you can set up all groups to have Public as the parent and not inherit any permissions from a parent group.

===Komponenten-Optionen & Berechtigungen===

Now, let's continue to see how the default back-end permissions for version 2.5 mimic the permissions for version 1.5. The Super Users group in 2.5 is equivalent to the Super Administrator group in 1.5.

Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 2.5 configuration. Let's see how this is accomplished.

If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:

[[Image:screenshot_acl_tutorial_20110111-09-en.png|center|]]
[[Image:screenshot_acl_tutorial_20110111-10-en.png|center|]]

This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.

First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.

Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.

If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.

In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.

It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.

===Frontend Berechtigungen===

Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions. First, let's look at the permissions for Manager, as shown below.
[[Image:screenshot_acl_tutorial_20110111-11a-en.png|center|frame]]
Manager has allowed permission for all actions except Configure. So members of the Manager group can do everything with Articles except open the Options screen.

Now let's look at Administrator, as shown below.
[[Image:screenshot_acl_tutorial_20110111-12a-en.png|center|frame]]
Administrator has Allowed for Configure, so Administrators can edit this Options screen.

Both groups can create, delete, edit, and change the state of articles.

Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set.

Authors only have Create and Edit Own permissions, as shown below.
[[Image:screenshot_acl_tutorial_20110112-07-en.png|center|frame]]
This means that Authors can create articles and can edit articles they have created. They may not delete articles, change the published state of articles, or edit articles created by others.

Editors have the same permissions as Authors with the addition of permission for the Edit action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-08-en.png|center|frame]]
So Editors can edit articles written by anyone.

Publishers can do everything Editors can do plus they have permission for the Edit State action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-09-de.png|center|frame]]
So Publishers can change the published state of an article. The possible states include Published, Unpublished, Archived, and Trashed.

All of these groups have Inherit permission for Configure and Access Component. Remember that Author is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Configure and Access Component, and since Author's permission for these actions is "Inherited", then Author does not have these permissions either. This same permission is passed from Author to Editor and from Editor to Publisher. So, by default, none of these groups are allowed to work with articles in the back end.

It is important to remember that these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.

Beachte auch das in den ursprünglichen Standardwerten keine Berechtigungen auf Verweigert eingestellt sind. Dies ermöglicht in allen Berechtigungsebenen die jeweilige Berechtigung auf Erlaubt einzustellen. Bedenke, wenn eine Aktion auf Verweigert eingestellt ist, das diese Aktion auch in allen untergeordneten Ebenen in der Berechtigungshierarchie verweigert wird. Zum Beispiel, wenn die Seitenameldung für Registered auf Verweigert (anstatt auf Erlaubt) eingestellt wird, kann man Publishers diese Aktion per Berechtigungeinstellung nicht erteilen.

=== Beitrags-Manager & Aktions-Diagramm ===

The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.

[[Image:screenshot_acl_tutorial_20110111-16-de.png|center|]]

* '''Configure''' allows you to view and change the Options for the component.
* '''Access Component''' allows you to navigate to the Article Manager. Without this permission, no other actions are possible.
* '''Create''' allows you to add new articles.
* '''Delete''' allows you to delete trashed articles. Note that the Delete icon only shows in the toolbar when you have the "Select State" filter set to "Trash".
* '''Edit''' allows you to edit existing articles.
* '''Edit State''' allows to you Publish, Unpublish, Archive, or Trash articles.
* '''Edit Own''' is the same as Edit except that it only applies to articles written by you.

==Allowing Guest-Only Access to Menu Items and Modules==

Version 1.6 introduced the ability to create a View Access Level that is only for guests of the site (meaning a user who is not logged in). The example below shows how you can set up this new feature.
''(N.B. Steps 1 to 3 are not needed for Joomla! 3.x as they exist in the default install)''

#Create a new user group called Guest. Make it a child of the Public group as shown below. [[Image:screenshot_acl_tutorial_20110112-01-de.png|center|frame]]
# Create a new access level called Guest and grant only the Guest group access to this level, as shown below.[[Image:screenshot_acl_tutorial_20110112-02-de.png|center|frame]]
# Navigate to User Manager→Options→Component and change the Guest User Group from the default value of "Public" to "Guest", as shown below.
[[Image:screenshot_acl_tutorial_20110112-04-de.png|center|frame]]
Now, if we assign a menu item, module, or other object to the Guest access level, only non-logged in users will have access. For example, if we create a new menu item with access level of Guest, as shown below,
[[Image:screenshot_acl_tutorial_20110112-05-de.png|center|frame]]
this menu item will only be visible to non-logged-in visitors to the site.

If required other user groups like Author can be granted access in the Guest access level, this would allow Authors to view articles in the front end for editing.

'''N.B. Login/logout in front end (''for changing data in session'') to see the change.'''

==Berechtigungen und Gruppenebenen gemeinsam nutzen==

As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.

This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:

* both groups can create new articles only in the History Assignments category.

* only History Teachers (not Assistant History Teachers) can Publish or otherwise have Edit State permission.

This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.

[[Image:Acl example diagram1 20091018-de.png|center|]]

In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.

To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.

Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.

[[Image:Acl example diagram2 20091018-de.png|center|]]

This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.

Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.

==ACL Aktion Berechtigungs-Beispiele==

===Backend Beitrag Administrator===

'''Problem:'''

We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.

'''Lösung:'''

# Create a new group called Article Administrator and make its parent group Public, as shown below.[[Image:screenshot_acl_tutorial_20110112-10-de.png|center|frame]] Because its parent group is Public, it won't have any permissions by default.
# In Users → Access Levels, edit the Special Access level to add the new group. That way they can get access to the back end menu items and modules (This assumes that the modules for the admin menu and quickicons have the Special Access level assigned to them, which is the default.) [[Image:screenshot_acl_tutorial_20110112-11-de.png|center|frame]] By default, the back-end menu items and modules are set to Special access, so if you forget to add the new group to the Special access level, you won't see any modules or menu items when you log in as a user of the new group.
# In Site → Global Configuration → Permissions, click on the Article Administrator group and change the permissions to Allowed for the following actions: Admin Login, Create, Delete, Edit, Edit State, and Edit Own. The screen below shows what will show before you press Save. [[Image:screenshot_acl_tutorial_20110112-12-de.png|center|frame]]After you save, the Calculated Permissions should show as shown below.[[Image:screenshot_acl_tutorial_20110112-13-de.png|center|frame]]Note that the permission for the Access Component is Inherited, which translates to Not Allowed. This is important. This means that this group will only be able to access components if we give the group "Allowed" permission for Access Component. So we only have to change the one component we want to give them access to and don't have to change any settings for the components where we don't want them to have access. If we had a case where we wanted to give a group access to everything except for one component, we could set the default to Allowed and then set the one component to Denied. Also note that we did not give the group Site Login permission, so users in this group will not be able to log into the front end. (If we wanted to allow that, we would just change the permission to Allowed for Site Login.)
# In Article Manager → Options → Permissions, change permissions to Allowed for this group for the Access Component action, as shown below.[[Image:screenshot_acl_tutorial_20110112-14-de.png|center|frame]]All of the other desired permissions are inherited.

That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end. For example, the screen below shows what a user in the Article Manager will see when they login to the back end.[[Image:screenshot_acl_tutorial_20110112-15-de.png|center|frame]]

==ACL Ansicht Zugriffsebenen-Beispiele==

A basic concept of using Access Levels is that all items with the same Access will be viewable by the same group of users. In other words, if two items have the same Access, you can't have one viewable by one user and not viewable by another user. On the other hand, it is easy to have one Group view any number of items with different Access levels.

Similarly, each Group has exactly the same combination of Access levels, but one User can be a member of more than one group. Depending on the situation, you may want to have users only in one Group or you may need to have a User in more than one Group.

This means that we may need to group our items so that items so that all items in a group have the same level of sensitivity. Here are some examples.

===Hierarchisches Beispiel===
In this example, Access levels are hierarchical, for example, like government security clearance codes. Say for example we have the following sets of classified documents: Classified, Secret, and Top Secret. Users have corresponding clearence codes. Users with Classified clearance can only see Classified documents and cannot see Secret or Top Secret. Users with Secret clearance can see Classified and Secret documents but not Top Secret. Users with Top Secret can see all documents.

In this case, you would create three Access levels: Classified, Secret, and Top Secret and the same three Groups. Users would only be members of one group, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| C1, C2, C3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Classified
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| S1, S2, S3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| TS1, TS2, TS3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Top Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret, Top Secret

|}

In this case, all users are in exactly one group, but some groups have access to more than one Access Level of items. In other words, we have a one-to-one relationship between users and groups, but a one-to-many relationship between Groups and Access Levels.

===Teamsicherheit Beispiel===

Another possible use case is a set of non-hierarchical teams. Let's say we have three teams, T1, T2, and T3. Some users are only on one team, but others might be on two or more teams. In this case, we could set up our Access Levels and Groups by team. Documents for each team have the access level for that team, and the Group for the team has only the one access level. When a User is on more than one team, they get added to the group for each team, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Beschreibung
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 1 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 2 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 3 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1, 2 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1,T2, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2, T3

|}

===Hybrid Example===

In a real-world situation, you might have a combination of these two arrangements. Say for example we have Managers and Staff. Staff can only see Staff documents and Managers can see Manager and Staff documents. Both types of users can be assigned to teams as well, in which case they can see all of the documents for that team. In addition, say that Managers can access some, but not all, team documents. Staff can only access team documents if they are members of that team.

In this example, we could set up the following Access Levels:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Access Level
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Description
| style="border:0.0007in solid #000000;padding:0.0382in;"| Groups

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team manager documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team staff documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team1 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1, Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team2 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2, Manager

|}

Then, users could be assigned to groups as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| User Type
| style="border:0.0007in solid #000000;padding:0.0382in;"| Group

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1, Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1, Team2

|}

<noinclude>
[[Category:Joomla! 1.6]]
[[Category:Joomla! 2.5]]
[[Category:Joomla! 3.x/de]]
[[Category:Tutorials/de]]
[[Category:Access Control/de]]
[[Category:Access Management]]
</noinclude>

Translations:J3.x:Access Control List Tutorial/146/de

2019-12-26T19:01:38Z

Sieger66:

J3.x:Access Control List Tutorial/de

2019-12-26T19:01:30Z

Sieger66:

<noinclude><languages /></noinclude>
{{Joomla version|version=3.x|comment=Serie}}
{{-}}
{{:J3.1:Access_Control_List/en}}

==Separate ACL für Anzeige und Aktionen==

Das Joomla ACL-System besteht genau genommen aus zwei völlig getrennten Systemen. Das eine System steuert, was Benutzer auf der Website "sehen" können. Das andere steuert, was Benutzer "tun" können (welche Aktionen ein Benutzer durchführen kann). Die ACL wird für jedes dieser Systeme anders eingerichtet.

===Steuern, was Benutzer sehen können===

Das Setup zum Steuern, was Benutzer sehen können, sieht wie folgt aus:
*Eine Reihe von Zugriffsebenen gemäß den Kategorien und/oder der Kombination von Kategorien erstellen, die nur angemeldete Benutzer sehen sollen. Anmerkung: Zu diesem Zeitpunkt werden noch keine Benutzergruppen den neuen Zugriffsebenen zugewiesen.

*Für jede Zugriffsebene eine Benutzergruppe erstellen, die 'Registriert' als übergeordnete Gruppe hat. Indem man für Benutzergruppen und Zugriffsebenen die gleichen Namen verwendet, kann man Verwirrungen zu einem späteren Zeitpunkt vorbeugen.

*Die neuen Zugriffsebenen bearbeiten und jeder die (neue) Benutzergruppe zuweisen. Wahrscheinlich möchten man auch die 'Super Benutzer' Gruppe (und/oder die anderen Standard-Benutzergruppen mit Ausnahme der Benutzergruppe 'Gast') den neuen Zugriffsebenen zuweisen.

*Jedem anzuzeigenden Eintrag eine Zugriffsebene zuweisen. Einträge sind sowohl inhaltliche Einträge (Beiträge, Kontakte, usw.), Menüeinträge als auch Module.

Immer dann, wenn ein Benutzer im Begriff ist, einen Eintrag auf einer Joomla-Seite anzeigen zu lassen, prüft das Programm, ob dieser Benutzer auch Zugriff auf den Eintrag hat. Das geschieht folgendermaßen:
# Zunächst wird eine Liste aller Zugriffsebenen erstellt, auf die der Benutzer zugreifen kann, basierend auf allen Gruppen, denen der Benutzer angehört. Sofern eine Gruppe eine übergeordnete Gruppe besitzt, sind die Zugriffsebenen für die übergeordnete Gruppe ebenfalls in der Liste enthalten.
# Danach wird überprüft, ob die Zugriffsebene für den Eintrag (Beitrag, Modul, Menüeintrag, usw.) in dieser Liste enthalten ist. Wenn dem so ist, wird der Eintrag dem Benutzer angezeigt. Falls der Benutzer die benötigten Zugriffsrechte besitzt, wird ihm der Zugriff verweigert.

Beachten, dass Zugriffsebenen für jede Gruppe separat festgelegt und nicht von der übergeordneten Gruppe einer Gruppe vererbt werden.

===Steuern, was Benutzer tun können===

Das System, das steuert, was Benutzer in einer Benutzergruppe tun können - welche Aktionen sie bei einem bestimmten Eintrag ausführen können - wird über den Tab 'Berechtigungen' in der Konfiguration und den Tab 'Berechtigungen' in den Optionen jeder einzelnen Komponente eingerichtet. Berechtigungen können auch auf Kategorienebene (bei Kernkomponenten) und auf Beitragsebene (bei Beiträgen) gesetzt werden.

* Wenn angemeldete Benutzer in bestimmten Kategorien Erstellen, Löschen, Status bearbeiten oder Eigene Inhalte bearbeiten dürfen, dann:
** Eine Benutzergruppe erstellen und als übergeordnete Gruppe eine der Benutzergruppen angeben, die Zugriff auf die Kategorie (oder Kategorien) haben, die diese neue Benutzergruppe ändern soll.
**Der neuen Benutzergruppe den entsprechenden Zugriffsebenen zuweisen. Dann die erforderlichen Berechtigungen für die neue Benutzergruppe entweder global oder pro Kategorie/Beitrag ändern.
*** Beim Erstellen einer Benutzergruppe ist es ratsam, eine übergeordnete Gruppe zu wählen, die über weniger Berechtigungen verfügt, als für die neue Gruppe erforderlich. Denn es ist einfacher, die Berechtigungen für jede Komponente/Kategorie/Beitrag zu erweitern, für die zusätzliche Berechtigungen nötig sind, als Berechtigungen aus den anderen Komponenten/Kategorien/Beiträgen zu entfernen.
****''(Beispiel: Es gibt 10 Kategorien, man möchte aber nur für eine Erstellen-Berechtigungen. Würde man für diese Gruppe die Berechtigungen global auf Erstellen erlaubt setzen, müsste man für diese Kategorien die Erstellen-Berechtigung entfernen. Und man müsste für diese Gruppe die Erstellen-Berechtigung bei jeder neuen Kategorie, die man zu einem späteren Zeitpunkt hinzufügt, ebenfalls entfernen).''
** Eine Benutzergruppe erstellen, die eine der Standardbenutzergruppen als übergeordnete Gruppe hat, NUR, wenn keine von diesen über die exakten Berechtigungen verfügt, die man benötigt und sich für alle Kategorien wünscht.

Beachten, dass dieses Setup unabhängig vom Setup für die Anzeige ist. Allerdings muss eine Benutzergruppe den entsprechenden Zugriffsebenen zugewiesen werden, damit der Benutzer in dieser Gruppe jene Berechtigungen verwenden kann.

Möchte ein Benutzer eine bestimmte Aktion bei einem Komponenten-Eintrag durchführen (z. B. einen Beitrag bearbeiten), überprüft das System (nachdem es überprüft hat, welcher Gruppe der Benutzer angehört und auf welche er Zugriff hat) die Berechtigung für diese Kombination aus Benutzer, Eintrag und Aktion. Liegt eine Erlaubnis vor, kann der Benutzer fortfahren. Andernfalls ist die Aktion nicht zulässig.

Das restliche Tutorial befasst sich mit der Steuerung, was Benutzer tun können - welche Aktionsberechtigungen sie haben.

==Aktionen, Gruppen und Vererbung==

Andererseits geht es bei der ACL auch darum, Benutzern Berechtigungen zu erteilen, damit diese Aktionen an Objekten durchführen können.

{| class="wikitable"
!style="width:20%;"|
!3.x Serie
|-
!Gruppen und Aktionen
|Aktionen, welche pro Gruppe erlaubt sind, werden durch den Website Administrator festgelegt.
|-
!Umfang von Berechtigungen
|Berechtigungen können auf mehreren Ebenen in der Hierarchie festgelegt werden: Website, Komponente, Kategorie, Objekt.
|-
!Vererbung von Berechtigungen
|Berechtigungen können von übergeordneten Gruppen und übergeordneten Kategorien geerbt werden.
|}

===Wie die Berechtigungen funktionieren===

Es gibt vier mögliche Berechtigungen für Aktionen. Diese sind (kurz skizziert):

* '''Nicht gesetzt''': Fällt standardmäßig auf "Nicht erlaubt" zurück. Aber im Gegensatz zur Berechtigung "Verweigert" kann diese Berechtigung außer Kraft gesetzt werden, wenn eine untergeordnete Gruppe oder eine in der Berechtigungshierarchie untergeordnete Ebene auf "Erlaubt" gesetzt wird. Diese Berechtigung kann nur für globale Berechtigungen der Konfiguration gesetzt werden.
* '''Vererbt''': Erbt den Wert von einer übergeordneten Gruppe oder einer in der Berechtigungshierarchie höheren Ebene. Diese Berechtigung gilt für alle Ebenen mit Ausnahme der obersten Ebene der Konfiguration.
* '''Verweigert''': Verbietet diese Aktion für diese Ebene und Gruppe. '''WICHTIG:''' Dadurch wird diese Aktion auch für alle untergeordneten Gruppen und alle untergeordneten Ebenen in der Berechtigungshierarchie verboten. Wird "Erlaubt" in einer untergeordneten Gruppe oder einer tieferen Ebene gesetzt, hat das keinen Effekt. Die Aktion wird immer für alle Mitglieder einer untergeordneten Gruppe und für alle untergeordneten Ebenen in der Berechtigungshierarchie abgelehnt.
* '''Erlaubt ''': Genehmigt diese Aktion für diese Ebene und Gruppe und für tiefere Ebenen und Untergruppen. Dies hat keine Auswirkungen, wenn eine höhere Gruppe oder Ebene auf "Verweigert" oder "Erlaubt" eingestellt ist. Wenn eine höhere Gruppe oder ein höheres Ebene auf "Verweigert" gesetzt ist, wird diese Berechtigung immer abgelehnt. Wenn eine höhere Gruppe oder Ebene auf Erlaubt eingestellt ist, ist diese Berechtigung bereits erlaubt.

===Hierarchie der Berechtigungsebenen===

Berechtigungen für Aktionen können in Version 2.5+ auf bis zu vier Ebenen festgelegt werden, wie folgt:
# '''Konfiguration''': legt die Standardberechtigungen für jede Aktion und Gruppe fest.
# '''Komponenten-Optionen-> Berechtigungen''': kann die Standardberechtigungen für diese Komponente überschreiben (z. B. Beiträge, Menüs, Benutzer, Banner usw.).
# '''Kategorie''': kann die Standardberechtigungen für Objekte in einer oder mehreren Kategorien überschreiben. Gilt für alle Komponenten mit Kategorien, einschließlich Beiträge, Banner, Kontakte, Newsfeeds und Weblinks.
# '''Beitrag''': kann die Berechtigungen für einen bestimmten Artikel überschreiben. Diese Ebene gilt nur für Beiträge. Alle anderen Komponenten erlauben nur die ersten drei Ebenen.

====Konfiguration====
Diese erreicht man über System → Konfiguration → Berechtigungen. Die nun sichtbare Maske dient dazu, die Berechtigungen auf der obersten Ebene für jede Gruppe und jede Aktion festzulegen, wie auch in der folgenden Abbildung gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Die möglichen Werte sind Vererbt, Erlaubt oder Verweigert. Die Spalte 'Errechnete Einstellung' zeigt die aktuelle Einstellung an. Diese ist entweder Nicht erlaubt (Standard), Erlaubt oder Nicht erlaubt.

Man kann immer nur an einer Gruppe gleichzeitig arbeiten, indem man den Reiter für ebendiese Gruppe anklickt. Die Berechtigungen kann man über die Dropdownlisten unter Neue Einstellung wählen ändern.

Beachten Sie, dass die Spalte "Errechnete Einstellung" erst aktualisiert wird, wenn Sie auf die Schaltfläche "Speichern" in der Werkzeugleiste klicken.

Um zu überprüfen, ob die Einstellungen Ihren Wünschen entsprechen, klicken Sie auf die Schaltfläche Speichern und überprüfen anschließend die Spalte Errechnete Einstellung.

====Komponenten-Optionen->Berechtigungen====
Auf diese wird für jede Komponente durch Klicken auf das Symbol "Optionen" in der Werkzeugleiste zugegriffen. Dieser Bildschirm ist ähnlich wie der Bildschirm "Globale Konfiguration" oben links. Wenn Sie beispielsweise im Menü-Manager auf das Symbol in der Werkzeugleiste Optionen klicken, werden die folgenden Menüs angezeigt.
[[Image:Screenshot_menu_acl_J3_tutorial-en.jpg]]

Der Zugriff auf Optionen ist nur für Mitglieder von Gruppen möglich, die die Berechtigung für die Aktion Konfiguration in für jede Komponente haben. Im obigen Beispiel hat die Gruppe Administrator die Berechtigung Erlaubt für die Option Konfigurieren, so dass Mitglieder dieser Gruppe auf diesen Bildschirm zugreifen können.

===Kategorie===
Auf die Kategorieberechtigungen wird im Category Manager zugegriffen: Bildschirm Kategorie bearbeiten, in einer Registerkarte oben auf dem Bildschirm. Dieser Bildschirm hat fünf Berechtigungen, wie folgt:

[[Image:Screenshot_category_acl_j3_tutorial-en.png]]

In diesen Bildern bearbeiten Sie die Berechtigungen für jeweils eine Benutzergruppe. Im obigen Beispiel bearbeiten Sie die Berechtigungen für die Gruppe Administrator.

Achten Sie darauf, dass die Aktionen "Konfigurieren und Zugriffssteuerung" nicht auf der Kategorieebene angewendet werden, so dass diese Aktionen nicht enthalten sind.

Beachten Sie auch, dass Kategorien in einer Hierarchie angeordnet werden können. Wenn ja, dann werden Aktionsberechtigungen in einer übergeordneten Kategorie automatisch an eine untergeordnete Kategorie vererbt. Wenn Sie beispielsweise eine Kategoriehierarchie von Tieren → Haustiere → Hunde hätten, dann würde die vollständige Berechtigungshierarchie für einen Artikel in der Kategorie Hunde wie folgt aussehen:
* Globale Konfiguration
* Artikel-Manager → Optionen → Genehmigung → Erlaubnis
* Tierkategorie
* Kategorie Haustiere
* Kategorie Hunde
* spezifischer Artikel

====Beitrag====
Berechtigungen für einzelne Beiträge findet man im "Beitrag" unter dem Tab-Reiter "Berechigungen". Dieser Bildschirm hat drei Aktionen, wie unten gezeigt.

[[Image:j3x_acl_tutorial_article_manager_article_permissions-en.png]]

Auch hier bearbeiten Sie jede Gruppe für sich. Um auf die Berechtigungen zuzugreifen wechseln Sie im Artikel auf den Reiter "Berechtigungen" im oberen Reiter. Über das Drop Down Menü wählen Sie die neue Berechtigung im Anschluss speichern Sie den Beitrag ab.

Beachten Sie, dass die Aktionen Configure, Access Component und Create auf Artikelebene nicht gelten, so dass diese Aktionen nicht berücksichtigt werden. Die Berechtigung zum Anlegen eines Artikels wird auf einer der höheren Ebenen der Hierarchie festgelegt.

===Zugriffsebenen===

Die Zugriffsebenen der 3.x-Serie sind einfach und flexibel. Der folgende Bildschirm zeigt die spezielle Zugriffsebene.
[[Image:j3x_acl_tutorial_viewing_levels-en.png|center]]
Aktivieren Sie einfach das Kontrollkästchen für jede Gruppe, die Sie in diesem Level aufnehmen wollen. Die spezielle Zugriffsebene umfasst die Gruppen Manager, Autor und Superuser. Es beinhaltet auch untergeordnete Gruppen dieser Gruppen. Die Gruppe Administrator ist also enthalten, da es sich um eine Untergruppe der Gruppe Manager handelt. Die Gruppen Editor, Publisher und Shop Suppliers sind enthalten, da es sich um Untergruppen des Autors handelt.

Jedem Objekt im Frontend ist eine Zugriffsebene zugeordnet. Wenn die Ebene öffentlich ist, kann jeder auf dieses Objekt zugreifen. Andernfalls dürfen nur Mitglieder von Gruppen, die dieser Zugriffsebene zugeordnet sind, auf dieses Objekt zugreifen.

Die Zugriffsebenen sind den Menüpunkten und den Modulen zugeordnet. Jede kann nur einer Zugriffsebene zugeordnet werden.

Der folgende Bildschirm zeigt beispielsweise den Bildschirm Menüpunkt bearbeiten mit der Liste der verfügbaren Zugriffsebenen....

[[Image:j3x_acl_tutorial_edit_menu_item_level_dropdown-en.png|center]]

==Standard-ACL-Setup==

Wenn Joomla! installiert ist, werden diese auf die ursprünglichen Standardwerte gesetzt. Wir werden diese Grundeinstellungen besprechen, um die Arbeitsweise der ACL zu verstehen.

===Standardgruppen===

Mit der Version 3.x können Sie Ihre individuellen Gruppen definieren. Wenn Sie die Version 3.x installieren, enthält sie eine Reihe von Standardgruppen, die im Folgenden dargestellt werden, sind die grundlegenden Standardbenutzergruppen. (Zusätzliche Standardbenutzergruppen werden mit Beispieldaten installiert)

[[Image:Screenshot_usergroupsl_acl_J3_tutorial-en.png|center]]

Die Pfeile zeigen die untergeordneten Elternbeziehungen an. Wie vorstehend besprochen, wird diese Berechtigung, wenn Sie eine Berechtigung für eine übergeordnete Gruppe festlegen, automatisch an alle Untergruppen vererbt. Die vererbten und zulässigen Berechtigungen können für eine Untergruppe überschrieben werden. Die Berechtigung Verweigert kann nicht überschrieben werden und verweigert immer eine Aktion für alle Untergruppen.

===Konfiguration===

Joomla! Version 3.x wird mit den gleichen bekannten Backend-Rechten wie die Version 1.5 (EOL) installiert. Mit der Version 3.x können Sie diese jedoch leicht an die Bedürfnisse Ihrer Website anpassen.

Wie bereits besprochen, werden die Berechtigungen für jede Aktion von der obigen Ebene in der Berechtigungshierarchie und von der übergeordneten Gruppe einer Gruppe übernommen. Also, wie funktioniert das? Die oberste Ebene dafür ist der gesamte Standort. Dies wird in der Site->Globale Konfiguration->Berechtigungen eingerichtet, wie unten gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Das erste, was man bemerken sollte, sind die zehn Aktionen: Standortlogin, Admin-Login, Offline-Zugriff, Superuser, Access Administration Interface, Erstellen, Löschen, Bearbeiten, Status bearbeiten und Eigenes bearbeiten. Dies sind die Aktionen, die ein Benutzer an einem Objekt in Joomla durchführen kann. Die spezifische Bedeutung jeder Aktion hängt vom Kontext ab. Für das Bild Globale Konfiguration sind sie wie folgt definiert:

Site Login : Login to the front end of the site

;Admin Login : Melden Sie sich am Backend der Website an.

Offline-Zugriff: Melden Sie sich am Frontend der Website an, wenn die Website offline ist (wenn die globale Konfigurationseinstellung "Site Offline" auf Ja gesetzt ist).

Superuser: Gewährt dem Benutzer den Status "Superuser". Benutzer mit dieser Berechtigung dürfen alles auf der Website machen. Nur Benutzer mit dieser Berechtigung können die Einstellungen der globalen Konfiguration ändern. Diese Berechtigungen können nicht eingeschränkt werden. Es ist wichtig zu verstehen, dass, wenn ein Benutzer Mitglied einer Super Admin-Gruppe ist, alle anderen Berechtigungen, die diesem Benutzer zugewiesen sind, irrelevant sind. Der Benutzer kann jede Aktion auf der Website durchführen. Es können jedoch weiterhin Zugriffsebenen zugewiesen werden, um zu steuern, was diese Gruppe auf der Website sieht. (Natürlich kann ein Super-Admin-Benutzer die Zugriffsebenen ändern, wenn er möchte, so dass die Zugriffsebenen nicht vollständig einschränken, was ein Super-Admin-Benutzer sehen kann.)

Zugangskomponente: Öffnen Sie die Bildschirme der Komponentenverwaltung (Benutzerverwaltung, Menüverwaltung, Artikelverwaltung usw.).

;Create : Create new objects (for example, users, menu items, articles, weblinks, and so on)

;Löschen : Löschen eines existienden Objekts

;Ändern : Ändern eines existierenden Objektes

;Ändern eines Objekt Status (Veröffentlicht, nicht Veröffentlicht, Archiviert und Gelöscht)

Eigene Objekte bearbeiten: Bearbeiten Sie Objekte, die Sie erstellt haben.

Each Group for the site has its own slider which is opened by clicking on the group name. In this case (with the sample data installed), we have the standard 7 groups that we had in version 1.5 plus two additional groups called "Shop Suppliers" and "Customer Group". Notice that our groups are set up with the same permissions as they had in version 1.5. Keep in mind that we can change any of these permissions to make the security work the way we want. Let's go through this to see how it works.

* '''Public''' has everything set to "Not set", as shown below.{{-}}[[Image:Screenshot_global_acl_public_J3_tutorial-en.png]]
**This can be a bit confusing. Basically, "Not Set" is the same as "Inherited". Because Public is our top-level group, and because Global Configuration is the top level of the component hierarchy, there is nothing to inherit from. So "Not Set" is used instead of "Inherit".
**The default in this case is for no permissions. So, as you would expect, the Public group has no special permissions. Also, it is important to note that, since nothing is set to Denied, all of these permissions may be overridden by child groups or by lower levels in the permission hierarchy.

* '''Guest''' is a 'child' group of the Public group has everything set to 'Inherited' {{-}}[[Image:Screenshot_global_acl_guest_J3_tutorial-de.png]]
** This is the default 'Guest User Group' in the User Manager options and the Group that (non logged in) visitors to your site are placed in.

* '''Manager''' is a "child" group of the Public group. It has Allowed permissions for everything except Access Component and Super Admin. So a member of this group can do everything in the front and back end of the site except change Global Permissions and Component Options. {{-}}[[Image:Screenshot_global_acl_manager_J3_tutorial-en.png]]

* '''Administrator''' group members inherit all of the Manager permissions and also have Allowed for Access Component. So members of this group by default can access the Options screens for each component. {{-}}[[Image:Screenshot_global_acl_administrator_J3_tutorial-en.png]]

* '''Registered''' is the same a Public except for the Allow permission for the Site Login action. This means that members of the Registered group can login to the site. Since default permissions are inherited, this means that, unless a child group overrides this permission, all child groups of the Registered group will be able to login as well. {{-}}[[Image:Screenshot_global_acl_registered_J3_tutorial-en.png]]

* '''Author''' is a child of the Registered group and inherits its permissions and also adds Create and Edit Own. Since Author, Editor, and Publisher have no back-end permissions, we will discuss them below, when we discuss front-end permissions.{{-}}[[Image:Screenshot_global_acl_author_J3_tutorial-en.png]]

* '''Editor''' is a child of the Authors group and adds the Edit permission. {{-}}[[Image:Screenshot_global_acl_editor_J3_tutorial-en.png]]

* '''Publisher''' is a child of Editor and adds the Edit State permission.{{-}}[[Image:Screenshot_global_acl_publisher_J3_tutorial-en.png]]

* '''Shop Suppliers''' is an example group that is installed if you install the sample data. It is a child group of Author.

* '''Customer Group''' is an example group that is installed if you install the sample data. It is a child group of Registered.

* '''Super Users''' group has the Allow permission for the Super Admin action. Because of this, members of this group have super user permissions throughout the site. They are the only users who can access and edit values on the Global Configuration screen. Users with permission for the Super Admin action have some special characteristics:
:* If a user has Super Admin permissions, no other permissions for this user matter. The user can perform any action on the site.
:* Only Super Admin users can create, edit, or delete other Super Admin users or groups.

There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.

This provides a lot of flexibility. For example, if you wanted Shop Suppliers to be able to have the ability to login to the back end, you could just change their Admin Login value to "Allowed". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherited (or Denied).

It is also important to understand that the ability to have child groups is completely optional. It allows you to save some time when setting up new groups. However, if you like, you can set up all groups to have Public as the parent and not inherit any permissions from a parent group.

===Komponenten-Optionen & Berechtigungen===

Now, let's continue to see how the default back-end permissions for version 2.5 mimic the permissions for version 1.5. The Super Users group in 2.5 is equivalent to the Super Administrator group in 1.5.

Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 2.5 configuration. Let's see how this is accomplished.

If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:

[[Image:screenshot_acl_tutorial_20110111-09-en.png|center|]]
[[Image:screenshot_acl_tutorial_20110111-10-en.png|center|]]

This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.

First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.

Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.

If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.

In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.

It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.

===Frontend Berechtigungen===

Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions. First, let's look at the permissions for Manager, as shown below.
[[Image:screenshot_acl_tutorial_20110111-11a-en.png|center|frame]]
Manager has allowed permission for all actions except Configure. So members of the Manager group can do everything with Articles except open the Options screen.

Now let's look at Administrator, as shown below.
[[Image:screenshot_acl_tutorial_20110111-12a-en.png|center|frame]]
Administrator has Allowed for Configure, so Administrators can edit this Options screen.

Both groups can create, delete, edit, and change the state of articles.

Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set.

Authors only have Create and Edit Own permissions, as shown below.
[[Image:screenshot_acl_tutorial_20110112-07-en.png|center|frame]]
This means that Authors can create articles and can edit articles they have created. They may not delete articles, change the published state of articles, or edit articles created by others.

Editors have the same permissions as Authors with the addition of permission for the Edit action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-08-de.png|center|frame]]
So Editors can edit articles written by anyone.

Publishers can do everything Editors can do plus they have permission for the Edit State action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-09-de.png|center|frame]]
So Publishers can change the published state of an article. The possible states include Published, Unpublished, Archived, and Trashed.

All of these groups have Inherit permission for Configure and Access Component. Remember that Author is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Configure and Access Component, and since Author's permission for these actions is "Inherited", then Author does not have these permissions either. This same permission is passed from Author to Editor and from Editor to Publisher. So, by default, none of these groups are allowed to work with articles in the back end.

It is important to remember that these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.

Beachte auch das in den ursprünglichen Standardwerten keine Berechtigungen auf Verweigert eingestellt sind. Dies ermöglicht in allen Berechtigungsebenen die jeweilige Berechtigung auf Erlaubt einzustellen. Bedenke, wenn eine Aktion auf Verweigert eingestellt ist, das diese Aktion auch in allen untergeordneten Ebenen in der Berechtigungshierarchie verweigert wird. Zum Beispiel, wenn die Seitenameldung für Registered auf Verweigert (anstatt auf Erlaubt) eingestellt wird, kann man Publishers diese Aktion per Berechtigungeinstellung nicht erteilen.

=== Beitrags-Manager & Aktions-Diagramm ===

The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.

[[Image:screenshot_acl_tutorial_20110111-16-de.png|center|]]

* '''Configure''' allows you to view and change the Options for the component.
* '''Access Component''' allows you to navigate to the Article Manager. Without this permission, no other actions are possible.
* '''Create''' allows you to add new articles.
* '''Delete''' allows you to delete trashed articles. Note that the Delete icon only shows in the toolbar when you have the "Select State" filter set to "Trash".
* '''Edit''' allows you to edit existing articles.
* '''Edit State''' allows to you Publish, Unpublish, Archive, or Trash articles.
* '''Edit Own''' is the same as Edit except that it only applies to articles written by you.

==Allowing Guest-Only Access to Menu Items and Modules==

Version 1.6 introduced the ability to create a View Access Level that is only for guests of the site (meaning a user who is not logged in). The example below shows how you can set up this new feature.
''(N.B. Steps 1 to 3 are not needed for Joomla! 3.x as they exist in the default install)''

#Create a new user group called Guest. Make it a child of the Public group as shown below. [[Image:screenshot_acl_tutorial_20110112-01-de.png|center|frame]]
# Create a new access level called Guest and grant only the Guest group access to this level, as shown below.[[Image:screenshot_acl_tutorial_20110112-02-de.png|center|frame]]
# Navigate to User Manager→Options→Component and change the Guest User Group from the default value of "Public" to "Guest", as shown below.
[[Image:screenshot_acl_tutorial_20110112-04-de.png|center|frame]]
Now, if we assign a menu item, module, or other object to the Guest access level, only non-logged in users will have access. For example, if we create a new menu item with access level of Guest, as shown below,
[[Image:screenshot_acl_tutorial_20110112-05-de.png|center|frame]]
this menu item will only be visible to non-logged-in visitors to the site.

If required other user groups like Author can be granted access in the Guest access level, this would allow Authors to view articles in the front end for editing.

'''N.B. Login/logout in front end (''for changing data in session'') to see the change.'''

==Berechtigungen und Gruppenebenen gemeinsam nutzen==

As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.

This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:

* both groups can create new articles only in the History Assignments category.

* only History Teachers (not Assistant History Teachers) can Publish or otherwise have Edit State permission.

This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.

[[Image:Acl example diagram1 20091018-de.png|center|]]

In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.

To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.

Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.

[[Image:Acl example diagram2 20091018-de.png|center|]]

This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.

Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.

==ACL Aktion Berechtigungs-Beispiele==

===Backend Beitrag Administrator===

'''Problem:'''

We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.

'''Lösung:'''

# Create a new group called Article Administrator and make its parent group Public, as shown below.[[Image:screenshot_acl_tutorial_20110112-10-de.png|center|frame]] Because its parent group is Public, it won't have any permissions by default.
# In Users → Access Levels, edit the Special Access level to add the new group. That way they can get access to the back end menu items and modules (This assumes that the modules for the admin menu and quickicons have the Special Access level assigned to them, which is the default.) [[Image:screenshot_acl_tutorial_20110112-11-de.png|center|frame]] By default, the back-end menu items and modules are set to Special access, so if you forget to add the new group to the Special access level, you won't see any modules or menu items when you log in as a user of the new group.
# In Site → Global Configuration → Permissions, click on the Article Administrator group and change the permissions to Allowed for the following actions: Admin Login, Create, Delete, Edit, Edit State, and Edit Own. The screen below shows what will show before you press Save. [[Image:screenshot_acl_tutorial_20110112-12-de.png|center|frame]]After you save, the Calculated Permissions should show as shown below.[[Image:screenshot_acl_tutorial_20110112-13-de.png|center|frame]]Note that the permission for the Access Component is Inherited, which translates to Not Allowed. This is important. This means that this group will only be able to access components if we give the group "Allowed" permission for Access Component. So we only have to change the one component we want to give them access to and don't have to change any settings for the components where we don't want them to have access. If we had a case where we wanted to give a group access to everything except for one component, we could set the default to Allowed and then set the one component to Denied. Also note that we did not give the group Site Login permission, so users in this group will not be able to log into the front end. (If we wanted to allow that, we would just change the permission to Allowed for Site Login.)
# In Article Manager → Options → Permissions, change permissions to Allowed for this group for the Access Component action, as shown below.[[Image:screenshot_acl_tutorial_20110112-14-de.png|center|frame]]All of the other desired permissions are inherited.

That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end. For example, the screen below shows what a user in the Article Manager will see when they login to the back end.[[Image:screenshot_acl_tutorial_20110112-15-de.png|center|frame]]

==ACL Ansicht Zugriffsebenen-Beispiele==

A basic concept of using Access Levels is that all items with the same Access will be viewable by the same group of users. In other words, if two items have the same Access, you can't have one viewable by one user and not viewable by another user. On the other hand, it is easy to have one Group view any number of items with different Access levels.

Similarly, each Group has exactly the same combination of Access levels, but one User can be a member of more than one group. Depending on the situation, you may want to have users only in one Group or you may need to have a User in more than one Group.

This means that we may need to group our items so that items so that all items in a group have the same level of sensitivity. Here are some examples.

===Hierarchisches Beispiel===
In this example, Access levels are hierarchical, for example, like government security clearance codes. Say for example we have the following sets of classified documents: Classified, Secret, and Top Secret. Users have corresponding clearence codes. Users with Classified clearance can only see Classified documents and cannot see Secret or Top Secret. Users with Secret clearance can see Classified and Secret documents but not Top Secret. Users with Top Secret can see all documents.

In this case, you would create three Access levels: Classified, Secret, and Top Secret and the same three Groups. Users would only be members of one group, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| C1, C2, C3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Classified
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| S1, S2, S3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| TS1, TS2, TS3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Top Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret, Top Secret

|}

In this case, all users are in exactly one group, but some groups have access to more than one Access Level of items. In other words, we have a one-to-one relationship between users and groups, but a one-to-many relationship between Groups and Access Levels.

===Teamsicherheit Beispiel===

Another possible use case is a set of non-hierarchical teams. Let's say we have three teams, T1, T2, and T3. Some users are only on one team, but others might be on two or more teams. In this case, we could set up our Access Levels and Groups by team. Documents for each team have the access level for that team, and the Group for the team has only the one access level. When a User is on more than one team, they get added to the group for each team, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Beschreibung
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 1 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 2 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 3 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1, 2 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1,T2, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2, T3

|}

===Hybrid Example===

In a real-world situation, you might have a combination of these two arrangements. Say for example we have Managers and Staff. Staff can only see Staff documents and Managers can see Manager and Staff documents. Both types of users can be assigned to teams as well, in which case they can see all of the documents for that team. In addition, say that Managers can access some, but not all, team documents. Staff can only access team documents if they are members of that team.

In this example, we could set up the following Access Levels:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Access Level
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Description
| style="border:0.0007in solid #000000;padding:0.0382in;"| Groups

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team manager documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team staff documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team1 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1, Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team2 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2, Manager

|}

Then, users could be assigned to groups as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| User Type
| style="border:0.0007in solid #000000;padding:0.0382in;"| Group

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1, Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1, Team2

|}

<noinclude>
[[Category:Joomla! 1.6]]
[[Category:Joomla! 2.5]]
[[Category:Joomla! 3.x/de]]
[[Category:Tutorials/de]]
[[Category:Access Control/de]]
[[Category:Access Management]]
</noinclude>

Translations:J3.x:Access Control List Tutorial/143/de

2019-12-26T19:01:29Z

Sieger66:

J3.x:Access Control List Tutorial/de

2019-12-26T19:01:22Z

Sieger66:

<noinclude><languages /></noinclude>
{{Joomla version|version=3.x|comment=Serie}}
{{-}}
{{:J3.1:Access_Control_List/en}}

==Separate ACL für Anzeige und Aktionen==

Das Joomla ACL-System besteht genau genommen aus zwei völlig getrennten Systemen. Das eine System steuert, was Benutzer auf der Website "sehen" können. Das andere steuert, was Benutzer "tun" können (welche Aktionen ein Benutzer durchführen kann). Die ACL wird für jedes dieser Systeme anders eingerichtet.

===Steuern, was Benutzer sehen können===

Das Setup zum Steuern, was Benutzer sehen können, sieht wie folgt aus:
*Eine Reihe von Zugriffsebenen gemäß den Kategorien und/oder der Kombination von Kategorien erstellen, die nur angemeldete Benutzer sehen sollen. Anmerkung: Zu diesem Zeitpunkt werden noch keine Benutzergruppen den neuen Zugriffsebenen zugewiesen.

*Für jede Zugriffsebene eine Benutzergruppe erstellen, die 'Registriert' als übergeordnete Gruppe hat. Indem man für Benutzergruppen und Zugriffsebenen die gleichen Namen verwendet, kann man Verwirrungen zu einem späteren Zeitpunkt vorbeugen.

*Die neuen Zugriffsebenen bearbeiten und jeder die (neue) Benutzergruppe zuweisen. Wahrscheinlich möchten man auch die 'Super Benutzer' Gruppe (und/oder die anderen Standard-Benutzergruppen mit Ausnahme der Benutzergruppe 'Gast') den neuen Zugriffsebenen zuweisen.

*Jedem anzuzeigenden Eintrag eine Zugriffsebene zuweisen. Einträge sind sowohl inhaltliche Einträge (Beiträge, Kontakte, usw.), Menüeinträge als auch Module.

Immer dann, wenn ein Benutzer im Begriff ist, einen Eintrag auf einer Joomla-Seite anzeigen zu lassen, prüft das Programm, ob dieser Benutzer auch Zugriff auf den Eintrag hat. Das geschieht folgendermaßen:
# Zunächst wird eine Liste aller Zugriffsebenen erstellt, auf die der Benutzer zugreifen kann, basierend auf allen Gruppen, denen der Benutzer angehört. Sofern eine Gruppe eine übergeordnete Gruppe besitzt, sind die Zugriffsebenen für die übergeordnete Gruppe ebenfalls in der Liste enthalten.
# Danach wird überprüft, ob die Zugriffsebene für den Eintrag (Beitrag, Modul, Menüeintrag, usw.) in dieser Liste enthalten ist. Wenn dem so ist, wird der Eintrag dem Benutzer angezeigt. Falls der Benutzer die benötigten Zugriffsrechte besitzt, wird ihm der Zugriff verweigert.

Beachten, dass Zugriffsebenen für jede Gruppe separat festgelegt und nicht von der übergeordneten Gruppe einer Gruppe vererbt werden.

===Steuern, was Benutzer tun können===

Das System, das steuert, was Benutzer in einer Benutzergruppe tun können - welche Aktionen sie bei einem bestimmten Eintrag ausführen können - wird über den Tab 'Berechtigungen' in der Konfiguration und den Tab 'Berechtigungen' in den Optionen jeder einzelnen Komponente eingerichtet. Berechtigungen können auch auf Kategorienebene (bei Kernkomponenten) und auf Beitragsebene (bei Beiträgen) gesetzt werden.

* Wenn angemeldete Benutzer in bestimmten Kategorien Erstellen, Löschen, Status bearbeiten oder Eigene Inhalte bearbeiten dürfen, dann:
** Eine Benutzergruppe erstellen und als übergeordnete Gruppe eine der Benutzergruppen angeben, die Zugriff auf die Kategorie (oder Kategorien) haben, die diese neue Benutzergruppe ändern soll.
**Der neuen Benutzergruppe den entsprechenden Zugriffsebenen zuweisen. Dann die erforderlichen Berechtigungen für die neue Benutzergruppe entweder global oder pro Kategorie/Beitrag ändern.
*** Beim Erstellen einer Benutzergruppe ist es ratsam, eine übergeordnete Gruppe zu wählen, die über weniger Berechtigungen verfügt, als für die neue Gruppe erforderlich. Denn es ist einfacher, die Berechtigungen für jede Komponente/Kategorie/Beitrag zu erweitern, für die zusätzliche Berechtigungen nötig sind, als Berechtigungen aus den anderen Komponenten/Kategorien/Beiträgen zu entfernen.
****''(Beispiel: Es gibt 10 Kategorien, man möchte aber nur für eine Erstellen-Berechtigungen. Würde man für diese Gruppe die Berechtigungen global auf Erstellen erlaubt setzen, müsste man für diese Kategorien die Erstellen-Berechtigung entfernen. Und man müsste für diese Gruppe die Erstellen-Berechtigung bei jeder neuen Kategorie, die man zu einem späteren Zeitpunkt hinzufügt, ebenfalls entfernen).''
** Eine Benutzergruppe erstellen, die eine der Standardbenutzergruppen als übergeordnete Gruppe hat, NUR, wenn keine von diesen über die exakten Berechtigungen verfügt, die man benötigt und sich für alle Kategorien wünscht.

Beachten, dass dieses Setup unabhängig vom Setup für die Anzeige ist. Allerdings muss eine Benutzergruppe den entsprechenden Zugriffsebenen zugewiesen werden, damit der Benutzer in dieser Gruppe jene Berechtigungen verwenden kann.

Möchte ein Benutzer eine bestimmte Aktion bei einem Komponenten-Eintrag durchführen (z. B. einen Beitrag bearbeiten), überprüft das System (nachdem es überprüft hat, welcher Gruppe der Benutzer angehört und auf welche er Zugriff hat) die Berechtigung für diese Kombination aus Benutzer, Eintrag und Aktion. Liegt eine Erlaubnis vor, kann der Benutzer fortfahren. Andernfalls ist die Aktion nicht zulässig.

Das restliche Tutorial befasst sich mit der Steuerung, was Benutzer tun können - welche Aktionsberechtigungen sie haben.

==Aktionen, Gruppen und Vererbung==

Andererseits geht es bei der ACL auch darum, Benutzern Berechtigungen zu erteilen, damit diese Aktionen an Objekten durchführen können.

{| class="wikitable"
!style="width:20%;"|
!3.x Serie
|-
!Gruppen und Aktionen
|Aktionen, welche pro Gruppe erlaubt sind, werden durch den Website Administrator festgelegt.
|-
!Umfang von Berechtigungen
|Berechtigungen können auf mehreren Ebenen in der Hierarchie festgelegt werden: Website, Komponente, Kategorie, Objekt.
|-
!Vererbung von Berechtigungen
|Berechtigungen können von übergeordneten Gruppen und übergeordneten Kategorien geerbt werden.
|}

===Wie die Berechtigungen funktionieren===

Es gibt vier mögliche Berechtigungen für Aktionen. Diese sind (kurz skizziert):

* '''Nicht gesetzt''': Fällt standardmäßig auf "Nicht erlaubt" zurück. Aber im Gegensatz zur Berechtigung "Verweigert" kann diese Berechtigung außer Kraft gesetzt werden, wenn eine untergeordnete Gruppe oder eine in der Berechtigungshierarchie untergeordnete Ebene auf "Erlaubt" gesetzt wird. Diese Berechtigung kann nur für globale Berechtigungen der Konfiguration gesetzt werden.
* '''Vererbt''': Erbt den Wert von einer übergeordneten Gruppe oder einer in der Berechtigungshierarchie höheren Ebene. Diese Berechtigung gilt für alle Ebenen mit Ausnahme der obersten Ebene der Konfiguration.
* '''Verweigert''': Verbietet diese Aktion für diese Ebene und Gruppe. '''WICHTIG:''' Dadurch wird diese Aktion auch für alle untergeordneten Gruppen und alle untergeordneten Ebenen in der Berechtigungshierarchie verboten. Wird "Erlaubt" in einer untergeordneten Gruppe oder einer tieferen Ebene gesetzt, hat das keinen Effekt. Die Aktion wird immer für alle Mitglieder einer untergeordneten Gruppe und für alle untergeordneten Ebenen in der Berechtigungshierarchie abgelehnt.
* '''Erlaubt ''': Genehmigt diese Aktion für diese Ebene und Gruppe und für tiefere Ebenen und Untergruppen. Dies hat keine Auswirkungen, wenn eine höhere Gruppe oder Ebene auf "Verweigert" oder "Erlaubt" eingestellt ist. Wenn eine höhere Gruppe oder ein höheres Ebene auf "Verweigert" gesetzt ist, wird diese Berechtigung immer abgelehnt. Wenn eine höhere Gruppe oder Ebene auf Erlaubt eingestellt ist, ist diese Berechtigung bereits erlaubt.

===Hierarchie der Berechtigungsebenen===

Berechtigungen für Aktionen können in Version 2.5+ auf bis zu vier Ebenen festgelegt werden, wie folgt:
# '''Konfiguration''': legt die Standardberechtigungen für jede Aktion und Gruppe fest.
# '''Komponenten-Optionen-> Berechtigungen''': kann die Standardberechtigungen für diese Komponente überschreiben (z. B. Beiträge, Menüs, Benutzer, Banner usw.).
# '''Kategorie''': kann die Standardberechtigungen für Objekte in einer oder mehreren Kategorien überschreiben. Gilt für alle Komponenten mit Kategorien, einschließlich Beiträge, Banner, Kontakte, Newsfeeds und Weblinks.
# '''Beitrag''': kann die Berechtigungen für einen bestimmten Artikel überschreiben. Diese Ebene gilt nur für Beiträge. Alle anderen Komponenten erlauben nur die ersten drei Ebenen.

====Konfiguration====
Diese erreicht man über System → Konfiguration → Berechtigungen. Die nun sichtbare Maske dient dazu, die Berechtigungen auf der obersten Ebene für jede Gruppe und jede Aktion festzulegen, wie auch in der folgenden Abbildung gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Die möglichen Werte sind Vererbt, Erlaubt oder Verweigert. Die Spalte 'Errechnete Einstellung' zeigt die aktuelle Einstellung an. Diese ist entweder Nicht erlaubt (Standard), Erlaubt oder Nicht erlaubt.

Man kann immer nur an einer Gruppe gleichzeitig arbeiten, indem man den Reiter für ebendiese Gruppe anklickt. Die Berechtigungen kann man über die Dropdownlisten unter Neue Einstellung wählen ändern.

Beachten Sie, dass die Spalte "Errechnete Einstellung" erst aktualisiert wird, wenn Sie auf die Schaltfläche "Speichern" in der Werkzeugleiste klicken.

Um zu überprüfen, ob die Einstellungen Ihren Wünschen entsprechen, klicken Sie auf die Schaltfläche Speichern und überprüfen anschließend die Spalte Errechnete Einstellung.

====Komponenten-Optionen->Berechtigungen====
Auf diese wird für jede Komponente durch Klicken auf das Symbol "Optionen" in der Werkzeugleiste zugegriffen. Dieser Bildschirm ist ähnlich wie der Bildschirm "Globale Konfiguration" oben links. Wenn Sie beispielsweise im Menü-Manager auf das Symbol in der Werkzeugleiste Optionen klicken, werden die folgenden Menüs angezeigt.
[[Image:Screenshot_menu_acl_J3_tutorial-en.jpg]]

Der Zugriff auf Optionen ist nur für Mitglieder von Gruppen möglich, die die Berechtigung für die Aktion Konfiguration in für jede Komponente haben. Im obigen Beispiel hat die Gruppe Administrator die Berechtigung Erlaubt für die Option Konfigurieren, so dass Mitglieder dieser Gruppe auf diesen Bildschirm zugreifen können.

===Kategorie===
Auf die Kategorieberechtigungen wird im Category Manager zugegriffen: Bildschirm Kategorie bearbeiten, in einer Registerkarte oben auf dem Bildschirm. Dieser Bildschirm hat fünf Berechtigungen, wie folgt:

[[Image:Screenshot_category_acl_j3_tutorial-en.png]]

In diesen Bildern bearbeiten Sie die Berechtigungen für jeweils eine Benutzergruppe. Im obigen Beispiel bearbeiten Sie die Berechtigungen für die Gruppe Administrator.

Achten Sie darauf, dass die Aktionen "Konfigurieren und Zugriffssteuerung" nicht auf der Kategorieebene angewendet werden, so dass diese Aktionen nicht enthalten sind.

Beachten Sie auch, dass Kategorien in einer Hierarchie angeordnet werden können. Wenn ja, dann werden Aktionsberechtigungen in einer übergeordneten Kategorie automatisch an eine untergeordnete Kategorie vererbt. Wenn Sie beispielsweise eine Kategoriehierarchie von Tieren → Haustiere → Hunde hätten, dann würde die vollständige Berechtigungshierarchie für einen Artikel in der Kategorie Hunde wie folgt aussehen:
* Globale Konfiguration
* Artikel-Manager → Optionen → Genehmigung → Erlaubnis
* Tierkategorie
* Kategorie Haustiere
* Kategorie Hunde
* spezifischer Artikel

====Beitrag====
Berechtigungen für einzelne Beiträge findet man im "Beitrag" unter dem Tab-Reiter "Berechigungen". Dieser Bildschirm hat drei Aktionen, wie unten gezeigt.

[[Image:j3x_acl_tutorial_article_manager_article_permissions-en.png]]

Auch hier bearbeiten Sie jede Gruppe für sich. Um auf die Berechtigungen zuzugreifen wechseln Sie im Artikel auf den Reiter "Berechtigungen" im oberen Reiter. Über das Drop Down Menü wählen Sie die neue Berechtigung im Anschluss speichern Sie den Beitrag ab.

Beachten Sie, dass die Aktionen Configure, Access Component und Create auf Artikelebene nicht gelten, so dass diese Aktionen nicht berücksichtigt werden. Die Berechtigung zum Anlegen eines Artikels wird auf einer der höheren Ebenen der Hierarchie festgelegt.

===Zugriffsebenen===

Die Zugriffsebenen der 3.x-Serie sind einfach und flexibel. Der folgende Bildschirm zeigt die spezielle Zugriffsebene.
[[Image:j3x_acl_tutorial_viewing_levels-en.png|center]]
Aktivieren Sie einfach das Kontrollkästchen für jede Gruppe, die Sie in diesem Level aufnehmen wollen. Die spezielle Zugriffsebene umfasst die Gruppen Manager, Autor und Superuser. Es beinhaltet auch untergeordnete Gruppen dieser Gruppen. Die Gruppe Administrator ist also enthalten, da es sich um eine Untergruppe der Gruppe Manager handelt. Die Gruppen Editor, Publisher und Shop Suppliers sind enthalten, da es sich um Untergruppen des Autors handelt.

Jedem Objekt im Frontend ist eine Zugriffsebene zugeordnet. Wenn die Ebene öffentlich ist, kann jeder auf dieses Objekt zugreifen. Andernfalls dürfen nur Mitglieder von Gruppen, die dieser Zugriffsebene zugeordnet sind, auf dieses Objekt zugreifen.

Die Zugriffsebenen sind den Menüpunkten und den Modulen zugeordnet. Jede kann nur einer Zugriffsebene zugeordnet werden.

Der folgende Bildschirm zeigt beispielsweise den Bildschirm Menüpunkt bearbeiten mit der Liste der verfügbaren Zugriffsebenen....

[[Image:j3x_acl_tutorial_edit_menu_item_level_dropdown-en.png|center]]

==Standard-ACL-Setup==

Wenn Joomla! installiert ist, werden diese auf die ursprünglichen Standardwerte gesetzt. Wir werden diese Grundeinstellungen besprechen, um die Arbeitsweise der ACL zu verstehen.

===Standardgruppen===

Mit der Version 3.x können Sie Ihre individuellen Gruppen definieren. Wenn Sie die Version 3.x installieren, enthält sie eine Reihe von Standardgruppen, die im Folgenden dargestellt werden, sind die grundlegenden Standardbenutzergruppen. (Zusätzliche Standardbenutzergruppen werden mit Beispieldaten installiert)

[[Image:Screenshot_usergroupsl_acl_J3_tutorial-en.png|center]]

Die Pfeile zeigen die untergeordneten Elternbeziehungen an. Wie vorstehend besprochen, wird diese Berechtigung, wenn Sie eine Berechtigung für eine übergeordnete Gruppe festlegen, automatisch an alle Untergruppen vererbt. Die vererbten und zulässigen Berechtigungen können für eine Untergruppe überschrieben werden. Die Berechtigung Verweigert kann nicht überschrieben werden und verweigert immer eine Aktion für alle Untergruppen.

===Konfiguration===

Joomla! Version 3.x wird mit den gleichen bekannten Backend-Rechten wie die Version 1.5 (EOL) installiert. Mit der Version 3.x können Sie diese jedoch leicht an die Bedürfnisse Ihrer Website anpassen.

Wie bereits besprochen, werden die Berechtigungen für jede Aktion von der obigen Ebene in der Berechtigungshierarchie und von der übergeordneten Gruppe einer Gruppe übernommen. Also, wie funktioniert das? Die oberste Ebene dafür ist der gesamte Standort. Dies wird in der Site->Globale Konfiguration->Berechtigungen eingerichtet, wie unten gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Das erste, was man bemerken sollte, sind die zehn Aktionen: Standortlogin, Admin-Login, Offline-Zugriff, Superuser, Access Administration Interface, Erstellen, Löschen, Bearbeiten, Status bearbeiten und Eigenes bearbeiten. Dies sind die Aktionen, die ein Benutzer an einem Objekt in Joomla durchführen kann. Die spezifische Bedeutung jeder Aktion hängt vom Kontext ab. Für das Bild Globale Konfiguration sind sie wie folgt definiert:

Site Login : Login to the front end of the site

;Admin Login : Melden Sie sich am Backend der Website an.

Offline-Zugriff: Melden Sie sich am Frontend der Website an, wenn die Website offline ist (wenn die globale Konfigurationseinstellung "Site Offline" auf Ja gesetzt ist).

Superuser: Gewährt dem Benutzer den Status "Superuser". Benutzer mit dieser Berechtigung dürfen alles auf der Website machen. Nur Benutzer mit dieser Berechtigung können die Einstellungen der globalen Konfiguration ändern. Diese Berechtigungen können nicht eingeschränkt werden. Es ist wichtig zu verstehen, dass, wenn ein Benutzer Mitglied einer Super Admin-Gruppe ist, alle anderen Berechtigungen, die diesem Benutzer zugewiesen sind, irrelevant sind. Der Benutzer kann jede Aktion auf der Website durchführen. Es können jedoch weiterhin Zugriffsebenen zugewiesen werden, um zu steuern, was diese Gruppe auf der Website sieht. (Natürlich kann ein Super-Admin-Benutzer die Zugriffsebenen ändern, wenn er möchte, so dass die Zugriffsebenen nicht vollständig einschränken, was ein Super-Admin-Benutzer sehen kann.)

Zugangskomponente: Öffnen Sie die Bildschirme der Komponentenverwaltung (Benutzerverwaltung, Menüverwaltung, Artikelverwaltung usw.).

;Create : Create new objects (for example, users, menu items, articles, weblinks, and so on)

;Löschen : Löschen eines existienden Objekts

;Ändern : Ändern eines existierenden Objektes

;Ändern eines Objekt Status (Veröffentlicht, nicht Veröffentlicht, Archiviert und Gelöscht)

Eigene Objekte bearbeiten: Bearbeiten Sie Objekte, die Sie erstellt haben.

Each Group for the site has its own slider which is opened by clicking on the group name. In this case (with the sample data installed), we have the standard 7 groups that we had in version 1.5 plus two additional groups called "Shop Suppliers" and "Customer Group". Notice that our groups are set up with the same permissions as they had in version 1.5. Keep in mind that we can change any of these permissions to make the security work the way we want. Let's go through this to see how it works.

* '''Public''' has everything set to "Not set", as shown below.{{-}}[[Image:Screenshot_global_acl_public_J3_tutorial-en.png]]
**This can be a bit confusing. Basically, "Not Set" is the same as "Inherited". Because Public is our top-level group, and because Global Configuration is the top level of the component hierarchy, there is nothing to inherit from. So "Not Set" is used instead of "Inherit".
**The default in this case is for no permissions. So, as you would expect, the Public group has no special permissions. Also, it is important to note that, since nothing is set to Denied, all of these permissions may be overridden by child groups or by lower levels in the permission hierarchy.

* '''Guest''' is a 'child' group of the Public group has everything set to 'Inherited' {{-}}[[Image:Screenshot_global_acl_guest_J3_tutorial-de.png]]
** This is the default 'Guest User Group' in the User Manager options and the Group that (non logged in) visitors to your site are placed in.

* '''Manager''' is a "child" group of the Public group. It has Allowed permissions for everything except Access Component and Super Admin. So a member of this group can do everything in the front and back end of the site except change Global Permissions and Component Options. {{-}}[[Image:Screenshot_global_acl_manager_J3_tutorial-en.png]]

* '''Administrator''' group members inherit all of the Manager permissions and also have Allowed for Access Component. So members of this group by default can access the Options screens for each component. {{-}}[[Image:Screenshot_global_acl_administrator_J3_tutorial-en.png]]

* '''Registered''' is the same a Public except for the Allow permission for the Site Login action. This means that members of the Registered group can login to the site. Since default permissions are inherited, this means that, unless a child group overrides this permission, all child groups of the Registered group will be able to login as well. {{-}}[[Image:Screenshot_global_acl_registered_J3_tutorial-en.png]]

* '''Author''' is a child of the Registered group and inherits its permissions and also adds Create and Edit Own. Since Author, Editor, and Publisher have no back-end permissions, we will discuss them below, when we discuss front-end permissions.{{-}}[[Image:Screenshot_global_acl_author_J3_tutorial-en.png]]

* '''Editor''' is a child of the Authors group and adds the Edit permission. {{-}}[[Image:Screenshot_global_acl_editor_J3_tutorial-en.png]]

* '''Publisher''' is a child of Editor and adds the Edit State permission.{{-}}[[Image:Screenshot_global_acl_publisher_J3_tutorial-en.png]]

* '''Shop Suppliers''' is an example group that is installed if you install the sample data. It is a child group of Author.

* '''Customer Group''' is an example group that is installed if you install the sample data. It is a child group of Registered.

* '''Super Users''' group has the Allow permission for the Super Admin action. Because of this, members of this group have super user permissions throughout the site. They are the only users who can access and edit values on the Global Configuration screen. Users with permission for the Super Admin action have some special characteristics:
:* If a user has Super Admin permissions, no other permissions for this user matter. The user can perform any action on the site.
:* Only Super Admin users can create, edit, or delete other Super Admin users or groups.

There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.

This provides a lot of flexibility. For example, if you wanted Shop Suppliers to be able to have the ability to login to the back end, you could just change their Admin Login value to "Allowed". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherited (or Denied).

It is also important to understand that the ability to have child groups is completely optional. It allows you to save some time when setting up new groups. However, if you like, you can set up all groups to have Public as the parent and not inherit any permissions from a parent group.

===Komponenten-Optionen & Berechtigungen===

Now, let's continue to see how the default back-end permissions for version 2.5 mimic the permissions for version 1.5. The Super Users group in 2.5 is equivalent to the Super Administrator group in 1.5.

Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 2.5 configuration. Let's see how this is accomplished.

If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:

[[Image:screenshot_acl_tutorial_20110111-09-en.png|center|]]
[[Image:screenshot_acl_tutorial_20110111-10-en.png|center|]]

This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.

First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.

Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.

If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.

In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.

It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.

===Frontend Berechtigungen===

Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions. First, let's look at the permissions for Manager, as shown below.
[[Image:screenshot_acl_tutorial_20110111-11a-en.png|center|frame]]
Manager has allowed permission for all actions except Configure. So members of the Manager group can do everything with Articles except open the Options screen.

Now let's look at Administrator, as shown below.
[[Image:screenshot_acl_tutorial_20110111-12a-en.png|center|frame]]
Administrator has Allowed for Configure, so Administrators can edit this Options screen.

Both groups can create, delete, edit, and change the state of articles.

Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set.

Authors only have Create and Edit Own permissions, as shown below.
[[Image:screenshot_acl_tutorial_20110112-07-de.png|center|frame]]
This means that Authors can create articles and can edit articles they have created. They may not delete articles, change the published state of articles, or edit articles created by others.

Editors have the same permissions as Authors with the addition of permission for the Edit action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-08-de.png|center|frame]]
So Editors can edit articles written by anyone.

Publishers can do everything Editors can do plus they have permission for the Edit State action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-09-de.png|center|frame]]
So Publishers can change the published state of an article. The possible states include Published, Unpublished, Archived, and Trashed.

All of these groups have Inherit permission for Configure and Access Component. Remember that Author is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Configure and Access Component, and since Author's permission for these actions is "Inherited", then Author does not have these permissions either. This same permission is passed from Author to Editor and from Editor to Publisher. So, by default, none of these groups are allowed to work with articles in the back end.

It is important to remember that these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.

Beachte auch das in den ursprünglichen Standardwerten keine Berechtigungen auf Verweigert eingestellt sind. Dies ermöglicht in allen Berechtigungsebenen die jeweilige Berechtigung auf Erlaubt einzustellen. Bedenke, wenn eine Aktion auf Verweigert eingestellt ist, das diese Aktion auch in allen untergeordneten Ebenen in der Berechtigungshierarchie verweigert wird. Zum Beispiel, wenn die Seitenameldung für Registered auf Verweigert (anstatt auf Erlaubt) eingestellt wird, kann man Publishers diese Aktion per Berechtigungeinstellung nicht erteilen.

=== Beitrags-Manager & Aktions-Diagramm ===

The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.

[[Image:screenshot_acl_tutorial_20110111-16-de.png|center|]]

* '''Configure''' allows you to view and change the Options for the component.
* '''Access Component''' allows you to navigate to the Article Manager. Without this permission, no other actions are possible.
* '''Create''' allows you to add new articles.
* '''Delete''' allows you to delete trashed articles. Note that the Delete icon only shows in the toolbar when you have the "Select State" filter set to "Trash".
* '''Edit''' allows you to edit existing articles.
* '''Edit State''' allows to you Publish, Unpublish, Archive, or Trash articles.
* '''Edit Own''' is the same as Edit except that it only applies to articles written by you.

==Allowing Guest-Only Access to Menu Items and Modules==

Version 1.6 introduced the ability to create a View Access Level that is only for guests of the site (meaning a user who is not logged in). The example below shows how you can set up this new feature.
''(N.B. Steps 1 to 3 are not needed for Joomla! 3.x as they exist in the default install)''

#Create a new user group called Guest. Make it a child of the Public group as shown below. [[Image:screenshot_acl_tutorial_20110112-01-de.png|center|frame]]
# Create a new access level called Guest and grant only the Guest group access to this level, as shown below.[[Image:screenshot_acl_tutorial_20110112-02-de.png|center|frame]]
# Navigate to User Manager→Options→Component and change the Guest User Group from the default value of "Public" to "Guest", as shown below.
[[Image:screenshot_acl_tutorial_20110112-04-de.png|center|frame]]
Now, if we assign a menu item, module, or other object to the Guest access level, only non-logged in users will have access. For example, if we create a new menu item with access level of Guest, as shown below,
[[Image:screenshot_acl_tutorial_20110112-05-de.png|center|frame]]
this menu item will only be visible to non-logged-in visitors to the site.

If required other user groups like Author can be granted access in the Guest access level, this would allow Authors to view articles in the front end for editing.

'''N.B. Login/logout in front end (''for changing data in session'') to see the change.'''

==Berechtigungen und Gruppenebenen gemeinsam nutzen==

As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.

This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:

* both groups can create new articles only in the History Assignments category.

* only History Teachers (not Assistant History Teachers) can Publish or otherwise have Edit State permission.

This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.

[[Image:Acl example diagram1 20091018-de.png|center|]]

In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.

To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.

Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.

[[Image:Acl example diagram2 20091018-de.png|center|]]

This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.

Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.

==ACL Aktion Berechtigungs-Beispiele==

===Backend Beitrag Administrator===

'''Problem:'''

We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.

'''Lösung:'''

# Create a new group called Article Administrator and make its parent group Public, as shown below.[[Image:screenshot_acl_tutorial_20110112-10-de.png|center|frame]] Because its parent group is Public, it won't have any permissions by default.
# In Users → Access Levels, edit the Special Access level to add the new group. That way they can get access to the back end menu items and modules (This assumes that the modules for the admin menu and quickicons have the Special Access level assigned to them, which is the default.) [[Image:screenshot_acl_tutorial_20110112-11-de.png|center|frame]] By default, the back-end menu items and modules are set to Special access, so if you forget to add the new group to the Special access level, you won't see any modules or menu items when you log in as a user of the new group.
# In Site → Global Configuration → Permissions, click on the Article Administrator group and change the permissions to Allowed for the following actions: Admin Login, Create, Delete, Edit, Edit State, and Edit Own. The screen below shows what will show before you press Save. [[Image:screenshot_acl_tutorial_20110112-12-de.png|center|frame]]After you save, the Calculated Permissions should show as shown below.[[Image:screenshot_acl_tutorial_20110112-13-de.png|center|frame]]Note that the permission for the Access Component is Inherited, which translates to Not Allowed. This is important. This means that this group will only be able to access components if we give the group "Allowed" permission for Access Component. So we only have to change the one component we want to give them access to and don't have to change any settings for the components where we don't want them to have access. If we had a case where we wanted to give a group access to everything except for one component, we could set the default to Allowed and then set the one component to Denied. Also note that we did not give the group Site Login permission, so users in this group will not be able to log into the front end. (If we wanted to allow that, we would just change the permission to Allowed for Site Login.)
# In Article Manager → Options → Permissions, change permissions to Allowed for this group for the Access Component action, as shown below.[[Image:screenshot_acl_tutorial_20110112-14-de.png|center|frame]]All of the other desired permissions are inherited.

That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end. For example, the screen below shows what a user in the Article Manager will see when they login to the back end.[[Image:screenshot_acl_tutorial_20110112-15-de.png|center|frame]]

==ACL Ansicht Zugriffsebenen-Beispiele==

A basic concept of using Access Levels is that all items with the same Access will be viewable by the same group of users. In other words, if two items have the same Access, you can't have one viewable by one user and not viewable by another user. On the other hand, it is easy to have one Group view any number of items with different Access levels.

Similarly, each Group has exactly the same combination of Access levels, but one User can be a member of more than one group. Depending on the situation, you may want to have users only in one Group or you may need to have a User in more than one Group.

This means that we may need to group our items so that items so that all items in a group have the same level of sensitivity. Here are some examples.

===Hierarchisches Beispiel===
In this example, Access levels are hierarchical, for example, like government security clearance codes. Say for example we have the following sets of classified documents: Classified, Secret, and Top Secret. Users have corresponding clearence codes. Users with Classified clearance can only see Classified documents and cannot see Secret or Top Secret. Users with Secret clearance can see Classified and Secret documents but not Top Secret. Users with Top Secret can see all documents.

In this case, you would create three Access levels: Classified, Secret, and Top Secret and the same three Groups. Users would only be members of one group, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| C1, C2, C3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Classified
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| S1, S2, S3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| TS1, TS2, TS3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Top Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret, Top Secret

|}

In this case, all users are in exactly one group, but some groups have access to more than one Access Level of items. In other words, we have a one-to-one relationship between users and groups, but a one-to-many relationship between Groups and Access Levels.

===Teamsicherheit Beispiel===

Another possible use case is a set of non-hierarchical teams. Let's say we have three teams, T1, T2, and T3. Some users are only on one team, but others might be on two or more teams. In this case, we could set up our Access Levels and Groups by team. Documents for each team have the access level for that team, and the Group for the team has only the one access level. When a User is on more than one team, they get added to the group for each team, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Beschreibung
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 1 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 2 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 3 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1, 2 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1,T2, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2, T3

|}

===Hybrid Example===

In a real-world situation, you might have a combination of these two arrangements. Say for example we have Managers and Staff. Staff can only see Staff documents and Managers can see Manager and Staff documents. Both types of users can be assigned to teams as well, in which case they can see all of the documents for that team. In addition, say that Managers can access some, but not all, team documents. Staff can only access team documents if they are members of that team.

In this example, we could set up the following Access Levels:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Access Level
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Description
| style="border:0.0007in solid #000000;padding:0.0382in;"| Groups

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team manager documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team staff documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team1 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1, Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team2 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2, Manager

|}

Then, users could be assigned to groups as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| User Type
| style="border:0.0007in solid #000000;padding:0.0382in;"| Group

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1, Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1, Team2

|}

<noinclude>
[[Category:Joomla! 1.6]]
[[Category:Joomla! 2.5]]
[[Category:Joomla! 3.x/de]]
[[Category:Tutorials/de]]
[[Category:Access Control/de]]
[[Category:Access Management]]
</noinclude>

Translations:J3.x:Access Control List Tutorial/138/de

2019-12-26T19:01:21Z

Sieger66:

J3.x:Access Control List Tutorial/de

2019-12-26T19:01:13Z

Sieger66:

<noinclude><languages /></noinclude>
{{Joomla version|version=3.x|comment=Serie}}
{{-}}
{{:J3.1:Access_Control_List/en}}

==Separate ACL für Anzeige und Aktionen==

Das Joomla ACL-System besteht genau genommen aus zwei völlig getrennten Systemen. Das eine System steuert, was Benutzer auf der Website "sehen" können. Das andere steuert, was Benutzer "tun" können (welche Aktionen ein Benutzer durchführen kann). Die ACL wird für jedes dieser Systeme anders eingerichtet.

===Steuern, was Benutzer sehen können===

Das Setup zum Steuern, was Benutzer sehen können, sieht wie folgt aus:
*Eine Reihe von Zugriffsebenen gemäß den Kategorien und/oder der Kombination von Kategorien erstellen, die nur angemeldete Benutzer sehen sollen. Anmerkung: Zu diesem Zeitpunkt werden noch keine Benutzergruppen den neuen Zugriffsebenen zugewiesen.

*Für jede Zugriffsebene eine Benutzergruppe erstellen, die 'Registriert' als übergeordnete Gruppe hat. Indem man für Benutzergruppen und Zugriffsebenen die gleichen Namen verwendet, kann man Verwirrungen zu einem späteren Zeitpunkt vorbeugen.

*Die neuen Zugriffsebenen bearbeiten und jeder die (neue) Benutzergruppe zuweisen. Wahrscheinlich möchten man auch die 'Super Benutzer' Gruppe (und/oder die anderen Standard-Benutzergruppen mit Ausnahme der Benutzergruppe 'Gast') den neuen Zugriffsebenen zuweisen.

*Jedem anzuzeigenden Eintrag eine Zugriffsebene zuweisen. Einträge sind sowohl inhaltliche Einträge (Beiträge, Kontakte, usw.), Menüeinträge als auch Module.

Immer dann, wenn ein Benutzer im Begriff ist, einen Eintrag auf einer Joomla-Seite anzeigen zu lassen, prüft das Programm, ob dieser Benutzer auch Zugriff auf den Eintrag hat. Das geschieht folgendermaßen:
# Zunächst wird eine Liste aller Zugriffsebenen erstellt, auf die der Benutzer zugreifen kann, basierend auf allen Gruppen, denen der Benutzer angehört. Sofern eine Gruppe eine übergeordnete Gruppe besitzt, sind die Zugriffsebenen für die übergeordnete Gruppe ebenfalls in der Liste enthalten.
# Danach wird überprüft, ob die Zugriffsebene für den Eintrag (Beitrag, Modul, Menüeintrag, usw.) in dieser Liste enthalten ist. Wenn dem so ist, wird der Eintrag dem Benutzer angezeigt. Falls der Benutzer die benötigten Zugriffsrechte besitzt, wird ihm der Zugriff verweigert.

Beachten, dass Zugriffsebenen für jede Gruppe separat festgelegt und nicht von der übergeordneten Gruppe einer Gruppe vererbt werden.

===Steuern, was Benutzer tun können===

Das System, das steuert, was Benutzer in einer Benutzergruppe tun können - welche Aktionen sie bei einem bestimmten Eintrag ausführen können - wird über den Tab 'Berechtigungen' in der Konfiguration und den Tab 'Berechtigungen' in den Optionen jeder einzelnen Komponente eingerichtet. Berechtigungen können auch auf Kategorienebene (bei Kernkomponenten) und auf Beitragsebene (bei Beiträgen) gesetzt werden.

* Wenn angemeldete Benutzer in bestimmten Kategorien Erstellen, Löschen, Status bearbeiten oder Eigene Inhalte bearbeiten dürfen, dann:
** Eine Benutzergruppe erstellen und als übergeordnete Gruppe eine der Benutzergruppen angeben, die Zugriff auf die Kategorie (oder Kategorien) haben, die diese neue Benutzergruppe ändern soll.
**Der neuen Benutzergruppe den entsprechenden Zugriffsebenen zuweisen. Dann die erforderlichen Berechtigungen für die neue Benutzergruppe entweder global oder pro Kategorie/Beitrag ändern.
*** Beim Erstellen einer Benutzergruppe ist es ratsam, eine übergeordnete Gruppe zu wählen, die über weniger Berechtigungen verfügt, als für die neue Gruppe erforderlich. Denn es ist einfacher, die Berechtigungen für jede Komponente/Kategorie/Beitrag zu erweitern, für die zusätzliche Berechtigungen nötig sind, als Berechtigungen aus den anderen Komponenten/Kategorien/Beiträgen zu entfernen.
****''(Beispiel: Es gibt 10 Kategorien, man möchte aber nur für eine Erstellen-Berechtigungen. Würde man für diese Gruppe die Berechtigungen global auf Erstellen erlaubt setzen, müsste man für diese Kategorien die Erstellen-Berechtigung entfernen. Und man müsste für diese Gruppe die Erstellen-Berechtigung bei jeder neuen Kategorie, die man zu einem späteren Zeitpunkt hinzufügt, ebenfalls entfernen).''
** Eine Benutzergruppe erstellen, die eine der Standardbenutzergruppen als übergeordnete Gruppe hat, NUR, wenn keine von diesen über die exakten Berechtigungen verfügt, die man benötigt und sich für alle Kategorien wünscht.

Beachten, dass dieses Setup unabhängig vom Setup für die Anzeige ist. Allerdings muss eine Benutzergruppe den entsprechenden Zugriffsebenen zugewiesen werden, damit der Benutzer in dieser Gruppe jene Berechtigungen verwenden kann.

Möchte ein Benutzer eine bestimmte Aktion bei einem Komponenten-Eintrag durchführen (z. B. einen Beitrag bearbeiten), überprüft das System (nachdem es überprüft hat, welcher Gruppe der Benutzer angehört und auf welche er Zugriff hat) die Berechtigung für diese Kombination aus Benutzer, Eintrag und Aktion. Liegt eine Erlaubnis vor, kann der Benutzer fortfahren. Andernfalls ist die Aktion nicht zulässig.

Das restliche Tutorial befasst sich mit der Steuerung, was Benutzer tun können - welche Aktionsberechtigungen sie haben.

==Aktionen, Gruppen und Vererbung==

Andererseits geht es bei der ACL auch darum, Benutzern Berechtigungen zu erteilen, damit diese Aktionen an Objekten durchführen können.

{| class="wikitable"
!style="width:20%;"|
!3.x Serie
|-
!Gruppen und Aktionen
|Aktionen, welche pro Gruppe erlaubt sind, werden durch den Website Administrator festgelegt.
|-
!Umfang von Berechtigungen
|Berechtigungen können auf mehreren Ebenen in der Hierarchie festgelegt werden: Website, Komponente, Kategorie, Objekt.
|-
!Vererbung von Berechtigungen
|Berechtigungen können von übergeordneten Gruppen und übergeordneten Kategorien geerbt werden.
|}

===Wie die Berechtigungen funktionieren===

Es gibt vier mögliche Berechtigungen für Aktionen. Diese sind (kurz skizziert):

* '''Nicht gesetzt''': Fällt standardmäßig auf "Nicht erlaubt" zurück. Aber im Gegensatz zur Berechtigung "Verweigert" kann diese Berechtigung außer Kraft gesetzt werden, wenn eine untergeordnete Gruppe oder eine in der Berechtigungshierarchie untergeordnete Ebene auf "Erlaubt" gesetzt wird. Diese Berechtigung kann nur für globale Berechtigungen der Konfiguration gesetzt werden.
* '''Vererbt''': Erbt den Wert von einer übergeordneten Gruppe oder einer in der Berechtigungshierarchie höheren Ebene. Diese Berechtigung gilt für alle Ebenen mit Ausnahme der obersten Ebene der Konfiguration.
* '''Verweigert''': Verbietet diese Aktion für diese Ebene und Gruppe. '''WICHTIG:''' Dadurch wird diese Aktion auch für alle untergeordneten Gruppen und alle untergeordneten Ebenen in der Berechtigungshierarchie verboten. Wird "Erlaubt" in einer untergeordneten Gruppe oder einer tieferen Ebene gesetzt, hat das keinen Effekt. Die Aktion wird immer für alle Mitglieder einer untergeordneten Gruppe und für alle untergeordneten Ebenen in der Berechtigungshierarchie abgelehnt.
* '''Erlaubt ''': Genehmigt diese Aktion für diese Ebene und Gruppe und für tiefere Ebenen und Untergruppen. Dies hat keine Auswirkungen, wenn eine höhere Gruppe oder Ebene auf "Verweigert" oder "Erlaubt" eingestellt ist. Wenn eine höhere Gruppe oder ein höheres Ebene auf "Verweigert" gesetzt ist, wird diese Berechtigung immer abgelehnt. Wenn eine höhere Gruppe oder Ebene auf Erlaubt eingestellt ist, ist diese Berechtigung bereits erlaubt.

===Hierarchie der Berechtigungsebenen===

Berechtigungen für Aktionen können in Version 2.5+ auf bis zu vier Ebenen festgelegt werden, wie folgt:
# '''Konfiguration''': legt die Standardberechtigungen für jede Aktion und Gruppe fest.
# '''Komponenten-Optionen-> Berechtigungen''': kann die Standardberechtigungen für diese Komponente überschreiben (z. B. Beiträge, Menüs, Benutzer, Banner usw.).
# '''Kategorie''': kann die Standardberechtigungen für Objekte in einer oder mehreren Kategorien überschreiben. Gilt für alle Komponenten mit Kategorien, einschließlich Beiträge, Banner, Kontakte, Newsfeeds und Weblinks.
# '''Beitrag''': kann die Berechtigungen für einen bestimmten Artikel überschreiben. Diese Ebene gilt nur für Beiträge. Alle anderen Komponenten erlauben nur die ersten drei Ebenen.

====Konfiguration====
Diese erreicht man über System → Konfiguration → Berechtigungen. Die nun sichtbare Maske dient dazu, die Berechtigungen auf der obersten Ebene für jede Gruppe und jede Aktion festzulegen, wie auch in der folgenden Abbildung gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Die möglichen Werte sind Vererbt, Erlaubt oder Verweigert. Die Spalte 'Errechnete Einstellung' zeigt die aktuelle Einstellung an. Diese ist entweder Nicht erlaubt (Standard), Erlaubt oder Nicht erlaubt.

Man kann immer nur an einer Gruppe gleichzeitig arbeiten, indem man den Reiter für ebendiese Gruppe anklickt. Die Berechtigungen kann man über die Dropdownlisten unter Neue Einstellung wählen ändern.

Beachten Sie, dass die Spalte "Errechnete Einstellung" erst aktualisiert wird, wenn Sie auf die Schaltfläche "Speichern" in der Werkzeugleiste klicken.

Um zu überprüfen, ob die Einstellungen Ihren Wünschen entsprechen, klicken Sie auf die Schaltfläche Speichern und überprüfen anschließend die Spalte Errechnete Einstellung.

====Komponenten-Optionen->Berechtigungen====
Auf diese wird für jede Komponente durch Klicken auf das Symbol "Optionen" in der Werkzeugleiste zugegriffen. Dieser Bildschirm ist ähnlich wie der Bildschirm "Globale Konfiguration" oben links. Wenn Sie beispielsweise im Menü-Manager auf das Symbol in der Werkzeugleiste Optionen klicken, werden die folgenden Menüs angezeigt.
[[Image:Screenshot_menu_acl_J3_tutorial-en.jpg]]

Der Zugriff auf Optionen ist nur für Mitglieder von Gruppen möglich, die die Berechtigung für die Aktion Konfiguration in für jede Komponente haben. Im obigen Beispiel hat die Gruppe Administrator die Berechtigung Erlaubt für die Option Konfigurieren, so dass Mitglieder dieser Gruppe auf diesen Bildschirm zugreifen können.

===Kategorie===
Auf die Kategorieberechtigungen wird im Category Manager zugegriffen: Bildschirm Kategorie bearbeiten, in einer Registerkarte oben auf dem Bildschirm. Dieser Bildschirm hat fünf Berechtigungen, wie folgt:

[[Image:Screenshot_category_acl_j3_tutorial-en.png]]

In diesen Bildern bearbeiten Sie die Berechtigungen für jeweils eine Benutzergruppe. Im obigen Beispiel bearbeiten Sie die Berechtigungen für die Gruppe Administrator.

Achten Sie darauf, dass die Aktionen "Konfigurieren und Zugriffssteuerung" nicht auf der Kategorieebene angewendet werden, so dass diese Aktionen nicht enthalten sind.

Beachten Sie auch, dass Kategorien in einer Hierarchie angeordnet werden können. Wenn ja, dann werden Aktionsberechtigungen in einer übergeordneten Kategorie automatisch an eine untergeordnete Kategorie vererbt. Wenn Sie beispielsweise eine Kategoriehierarchie von Tieren → Haustiere → Hunde hätten, dann würde die vollständige Berechtigungshierarchie für einen Artikel in der Kategorie Hunde wie folgt aussehen:
* Globale Konfiguration
* Artikel-Manager → Optionen → Genehmigung → Erlaubnis
* Tierkategorie
* Kategorie Haustiere
* Kategorie Hunde
* spezifischer Artikel

====Beitrag====
Berechtigungen für einzelne Beiträge findet man im "Beitrag" unter dem Tab-Reiter "Berechigungen". Dieser Bildschirm hat drei Aktionen, wie unten gezeigt.

[[Image:j3x_acl_tutorial_article_manager_article_permissions-en.png]]

Auch hier bearbeiten Sie jede Gruppe für sich. Um auf die Berechtigungen zuzugreifen wechseln Sie im Artikel auf den Reiter "Berechtigungen" im oberen Reiter. Über das Drop Down Menü wählen Sie die neue Berechtigung im Anschluss speichern Sie den Beitrag ab.

Beachten Sie, dass die Aktionen Configure, Access Component und Create auf Artikelebene nicht gelten, so dass diese Aktionen nicht berücksichtigt werden. Die Berechtigung zum Anlegen eines Artikels wird auf einer der höheren Ebenen der Hierarchie festgelegt.

===Zugriffsebenen===

Die Zugriffsebenen der 3.x-Serie sind einfach und flexibel. Der folgende Bildschirm zeigt die spezielle Zugriffsebene.
[[Image:j3x_acl_tutorial_viewing_levels-en.png|center]]
Aktivieren Sie einfach das Kontrollkästchen für jede Gruppe, die Sie in diesem Level aufnehmen wollen. Die spezielle Zugriffsebene umfasst die Gruppen Manager, Autor und Superuser. Es beinhaltet auch untergeordnete Gruppen dieser Gruppen. Die Gruppe Administrator ist also enthalten, da es sich um eine Untergruppe der Gruppe Manager handelt. Die Gruppen Editor, Publisher und Shop Suppliers sind enthalten, da es sich um Untergruppen des Autors handelt.

Jedem Objekt im Frontend ist eine Zugriffsebene zugeordnet. Wenn die Ebene öffentlich ist, kann jeder auf dieses Objekt zugreifen. Andernfalls dürfen nur Mitglieder von Gruppen, die dieser Zugriffsebene zugeordnet sind, auf dieses Objekt zugreifen.

Die Zugriffsebenen sind den Menüpunkten und den Modulen zugeordnet. Jede kann nur einer Zugriffsebene zugeordnet werden.

Der folgende Bildschirm zeigt beispielsweise den Bildschirm Menüpunkt bearbeiten mit der Liste der verfügbaren Zugriffsebenen....

[[Image:j3x_acl_tutorial_edit_menu_item_level_dropdown-en.png|center]]

==Standard-ACL-Setup==

Wenn Joomla! installiert ist, werden diese auf die ursprünglichen Standardwerte gesetzt. Wir werden diese Grundeinstellungen besprechen, um die Arbeitsweise der ACL zu verstehen.

===Standardgruppen===

Mit der Version 3.x können Sie Ihre individuellen Gruppen definieren. Wenn Sie die Version 3.x installieren, enthält sie eine Reihe von Standardgruppen, die im Folgenden dargestellt werden, sind die grundlegenden Standardbenutzergruppen. (Zusätzliche Standardbenutzergruppen werden mit Beispieldaten installiert)

[[Image:Screenshot_usergroupsl_acl_J3_tutorial-en.png|center]]

Die Pfeile zeigen die untergeordneten Elternbeziehungen an. Wie vorstehend besprochen, wird diese Berechtigung, wenn Sie eine Berechtigung für eine übergeordnete Gruppe festlegen, automatisch an alle Untergruppen vererbt. Die vererbten und zulässigen Berechtigungen können für eine Untergruppe überschrieben werden. Die Berechtigung Verweigert kann nicht überschrieben werden und verweigert immer eine Aktion für alle Untergruppen.

===Konfiguration===

Joomla! Version 3.x wird mit den gleichen bekannten Backend-Rechten wie die Version 1.5 (EOL) installiert. Mit der Version 3.x können Sie diese jedoch leicht an die Bedürfnisse Ihrer Website anpassen.

Wie bereits besprochen, werden die Berechtigungen für jede Aktion von der obigen Ebene in der Berechtigungshierarchie und von der übergeordneten Gruppe einer Gruppe übernommen. Also, wie funktioniert das? Die oberste Ebene dafür ist der gesamte Standort. Dies wird in der Site->Globale Konfiguration->Berechtigungen eingerichtet, wie unten gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Das erste, was man bemerken sollte, sind die zehn Aktionen: Standortlogin, Admin-Login, Offline-Zugriff, Superuser, Access Administration Interface, Erstellen, Löschen, Bearbeiten, Status bearbeiten und Eigenes bearbeiten. Dies sind die Aktionen, die ein Benutzer an einem Objekt in Joomla durchführen kann. Die spezifische Bedeutung jeder Aktion hängt vom Kontext ab. Für das Bild Globale Konfiguration sind sie wie folgt definiert:

Site Login : Login to the front end of the site

;Admin Login : Melden Sie sich am Backend der Website an.

Offline-Zugriff: Melden Sie sich am Frontend der Website an, wenn die Website offline ist (wenn die globale Konfigurationseinstellung "Site Offline" auf Ja gesetzt ist).

Superuser: Gewährt dem Benutzer den Status "Superuser". Benutzer mit dieser Berechtigung dürfen alles auf der Website machen. Nur Benutzer mit dieser Berechtigung können die Einstellungen der globalen Konfiguration ändern. Diese Berechtigungen können nicht eingeschränkt werden. Es ist wichtig zu verstehen, dass, wenn ein Benutzer Mitglied einer Super Admin-Gruppe ist, alle anderen Berechtigungen, die diesem Benutzer zugewiesen sind, irrelevant sind. Der Benutzer kann jede Aktion auf der Website durchführen. Es können jedoch weiterhin Zugriffsebenen zugewiesen werden, um zu steuern, was diese Gruppe auf der Website sieht. (Natürlich kann ein Super-Admin-Benutzer die Zugriffsebenen ändern, wenn er möchte, so dass die Zugriffsebenen nicht vollständig einschränken, was ein Super-Admin-Benutzer sehen kann.)

Zugangskomponente: Öffnen Sie die Bildschirme der Komponentenverwaltung (Benutzerverwaltung, Menüverwaltung, Artikelverwaltung usw.).

;Create : Create new objects (for example, users, menu items, articles, weblinks, and so on)

;Löschen : Löschen eines existienden Objekts

;Ändern : Ändern eines existierenden Objektes

;Ändern eines Objekt Status (Veröffentlicht, nicht Veröffentlicht, Archiviert und Gelöscht)

Eigene Objekte bearbeiten: Bearbeiten Sie Objekte, die Sie erstellt haben.

Each Group for the site has its own slider which is opened by clicking on the group name. In this case (with the sample data installed), we have the standard 7 groups that we had in version 1.5 plus two additional groups called "Shop Suppliers" and "Customer Group". Notice that our groups are set up with the same permissions as they had in version 1.5. Keep in mind that we can change any of these permissions to make the security work the way we want. Let's go through this to see how it works.

* '''Public''' has everything set to "Not set", as shown below.{{-}}[[Image:Screenshot_global_acl_public_J3_tutorial-en.png]]
**This can be a bit confusing. Basically, "Not Set" is the same as "Inherited". Because Public is our top-level group, and because Global Configuration is the top level of the component hierarchy, there is nothing to inherit from. So "Not Set" is used instead of "Inherit".
**The default in this case is for no permissions. So, as you would expect, the Public group has no special permissions. Also, it is important to note that, since nothing is set to Denied, all of these permissions may be overridden by child groups or by lower levels in the permission hierarchy.

* '''Guest''' is a 'child' group of the Public group has everything set to 'Inherited' {{-}}[[Image:Screenshot_global_acl_guest_J3_tutorial-de.png]]
** This is the default 'Guest User Group' in the User Manager options and the Group that (non logged in) visitors to your site are placed in.

* '''Manager''' is a "child" group of the Public group. It has Allowed permissions for everything except Access Component and Super Admin. So a member of this group can do everything in the front and back end of the site except change Global Permissions and Component Options. {{-}}[[Image:Screenshot_global_acl_manager_J3_tutorial-en.png]]

* '''Administrator''' group members inherit all of the Manager permissions and also have Allowed for Access Component. So members of this group by default can access the Options screens for each component. {{-}}[[Image:Screenshot_global_acl_administrator_J3_tutorial-en.png]]

* '''Registered''' is the same a Public except for the Allow permission for the Site Login action. This means that members of the Registered group can login to the site. Since default permissions are inherited, this means that, unless a child group overrides this permission, all child groups of the Registered group will be able to login as well. {{-}}[[Image:Screenshot_global_acl_registered_J3_tutorial-en.png]]

* '''Author''' is a child of the Registered group and inherits its permissions and also adds Create and Edit Own. Since Author, Editor, and Publisher have no back-end permissions, we will discuss them below, when we discuss front-end permissions.{{-}}[[Image:Screenshot_global_acl_author_J3_tutorial-en.png]]

* '''Editor''' is a child of the Authors group and adds the Edit permission. {{-}}[[Image:Screenshot_global_acl_editor_J3_tutorial-en.png]]

* '''Publisher''' is a child of Editor and adds the Edit State permission.{{-}}[[Image:Screenshot_global_acl_publisher_J3_tutorial-en.png]]

* '''Shop Suppliers''' is an example group that is installed if you install the sample data. It is a child group of Author.

* '''Customer Group''' is an example group that is installed if you install the sample data. It is a child group of Registered.

* '''Super Users''' group has the Allow permission for the Super Admin action. Because of this, members of this group have super user permissions throughout the site. They are the only users who can access and edit values on the Global Configuration screen. Users with permission for the Super Admin action have some special characteristics:
:* If a user has Super Admin permissions, no other permissions for this user matter. The user can perform any action on the site.
:* Only Super Admin users can create, edit, or delete other Super Admin users or groups.

There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.

This provides a lot of flexibility. For example, if you wanted Shop Suppliers to be able to have the ability to login to the back end, you could just change their Admin Login value to "Allowed". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherited (or Denied).

It is also important to understand that the ability to have child groups is completely optional. It allows you to save some time when setting up new groups. However, if you like, you can set up all groups to have Public as the parent and not inherit any permissions from a parent group.

===Komponenten-Optionen & Berechtigungen===

Now, let's continue to see how the default back-end permissions for version 2.5 mimic the permissions for version 1.5. The Super Users group in 2.5 is equivalent to the Super Administrator group in 1.5.

Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 2.5 configuration. Let's see how this is accomplished.

If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:

[[Image:screenshot_acl_tutorial_20110111-09-en.png|center|]]
[[Image:screenshot_acl_tutorial_20110111-10-en.png|center|]]

This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.

First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.

Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.

If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.

In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.

It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.

===Frontend Berechtigungen===

Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions. First, let's look at the permissions for Manager, as shown below.
[[Image:screenshot_acl_tutorial_20110111-11a-en.png|center|frame]]
Manager has allowed permission for all actions except Configure. So members of the Manager group can do everything with Articles except open the Options screen.

Now let's look at Administrator, as shown below.
[[Image:screenshot_acl_tutorial_20110111-12a-de.png|center|frame]]
Administrator has Allowed for Configure, so Administrators can edit this Options screen.

Both groups can create, delete, edit, and change the state of articles.

Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set.

Authors only have Create and Edit Own permissions, as shown below.
[[Image:screenshot_acl_tutorial_20110112-07-de.png|center|frame]]
This means that Authors can create articles and can edit articles they have created. They may not delete articles, change the published state of articles, or edit articles created by others.

Editors have the same permissions as Authors with the addition of permission for the Edit action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-08-de.png|center|frame]]
So Editors can edit articles written by anyone.

Publishers can do everything Editors can do plus they have permission for the Edit State action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-09-de.png|center|frame]]
So Publishers can change the published state of an article. The possible states include Published, Unpublished, Archived, and Trashed.

All of these groups have Inherit permission for Configure and Access Component. Remember that Author is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Configure and Access Component, and since Author's permission for these actions is "Inherited", then Author does not have these permissions either. This same permission is passed from Author to Editor and from Editor to Publisher. So, by default, none of these groups are allowed to work with articles in the back end.

It is important to remember that these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.

Beachte auch das in den ursprünglichen Standardwerten keine Berechtigungen auf Verweigert eingestellt sind. Dies ermöglicht in allen Berechtigungsebenen die jeweilige Berechtigung auf Erlaubt einzustellen. Bedenke, wenn eine Aktion auf Verweigert eingestellt ist, das diese Aktion auch in allen untergeordneten Ebenen in der Berechtigungshierarchie verweigert wird. Zum Beispiel, wenn die Seitenameldung für Registered auf Verweigert (anstatt auf Erlaubt) eingestellt wird, kann man Publishers diese Aktion per Berechtigungeinstellung nicht erteilen.

=== Beitrags-Manager & Aktions-Diagramm ===

The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.

[[Image:screenshot_acl_tutorial_20110111-16-de.png|center|]]

* '''Configure''' allows you to view and change the Options for the component.
* '''Access Component''' allows you to navigate to the Article Manager. Without this permission, no other actions are possible.
* '''Create''' allows you to add new articles.
* '''Delete''' allows you to delete trashed articles. Note that the Delete icon only shows in the toolbar when you have the "Select State" filter set to "Trash".
* '''Edit''' allows you to edit existing articles.
* '''Edit State''' allows to you Publish, Unpublish, Archive, or Trash articles.
* '''Edit Own''' is the same as Edit except that it only applies to articles written by you.

==Allowing Guest-Only Access to Menu Items and Modules==

Version 1.6 introduced the ability to create a View Access Level that is only for guests of the site (meaning a user who is not logged in). The example below shows how you can set up this new feature.
''(N.B. Steps 1 to 3 are not needed for Joomla! 3.x as they exist in the default install)''

#Create a new user group called Guest. Make it a child of the Public group as shown below. [[Image:screenshot_acl_tutorial_20110112-01-de.png|center|frame]]
# Create a new access level called Guest and grant only the Guest group access to this level, as shown below.[[Image:screenshot_acl_tutorial_20110112-02-de.png|center|frame]]
# Navigate to User Manager→Options→Component and change the Guest User Group from the default value of "Public" to "Guest", as shown below.
[[Image:screenshot_acl_tutorial_20110112-04-de.png|center|frame]]
Now, if we assign a menu item, module, or other object to the Guest access level, only non-logged in users will have access. For example, if we create a new menu item with access level of Guest, as shown below,
[[Image:screenshot_acl_tutorial_20110112-05-de.png|center|frame]]
this menu item will only be visible to non-logged-in visitors to the site.

If required other user groups like Author can be granted access in the Guest access level, this would allow Authors to view articles in the front end for editing.

'''N.B. Login/logout in front end (''for changing data in session'') to see the change.'''

==Berechtigungen und Gruppenebenen gemeinsam nutzen==

As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.

This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:

* both groups can create new articles only in the History Assignments category.

* only History Teachers (not Assistant History Teachers) can Publish or otherwise have Edit State permission.

This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.

[[Image:Acl example diagram1 20091018-de.png|center|]]

In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.

To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.

Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.

[[Image:Acl example diagram2 20091018-de.png|center|]]

This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.

Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.

==ACL Aktion Berechtigungs-Beispiele==

===Backend Beitrag Administrator===

'''Problem:'''

We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.

'''Lösung:'''

# Create a new group called Article Administrator and make its parent group Public, as shown below.[[Image:screenshot_acl_tutorial_20110112-10-de.png|center|frame]] Because its parent group is Public, it won't have any permissions by default.
# In Users → Access Levels, edit the Special Access level to add the new group. That way they can get access to the back end menu items and modules (This assumes that the modules for the admin menu and quickicons have the Special Access level assigned to them, which is the default.) [[Image:screenshot_acl_tutorial_20110112-11-de.png|center|frame]] By default, the back-end menu items and modules are set to Special access, so if you forget to add the new group to the Special access level, you won't see any modules or menu items when you log in as a user of the new group.
# In Site → Global Configuration → Permissions, click on the Article Administrator group and change the permissions to Allowed for the following actions: Admin Login, Create, Delete, Edit, Edit State, and Edit Own. The screen below shows what will show before you press Save. [[Image:screenshot_acl_tutorial_20110112-12-de.png|center|frame]]After you save, the Calculated Permissions should show as shown below.[[Image:screenshot_acl_tutorial_20110112-13-de.png|center|frame]]Note that the permission for the Access Component is Inherited, which translates to Not Allowed. This is important. This means that this group will only be able to access components if we give the group "Allowed" permission for Access Component. So we only have to change the one component we want to give them access to and don't have to change any settings for the components where we don't want them to have access. If we had a case where we wanted to give a group access to everything except for one component, we could set the default to Allowed and then set the one component to Denied. Also note that we did not give the group Site Login permission, so users in this group will not be able to log into the front end. (If we wanted to allow that, we would just change the permission to Allowed for Site Login.)
# In Article Manager → Options → Permissions, change permissions to Allowed for this group for the Access Component action, as shown below.[[Image:screenshot_acl_tutorial_20110112-14-de.png|center|frame]]All of the other desired permissions are inherited.

That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end. For example, the screen below shows what a user in the Article Manager will see when they login to the back end.[[Image:screenshot_acl_tutorial_20110112-15-de.png|center|frame]]

==ACL Ansicht Zugriffsebenen-Beispiele==

A basic concept of using Access Levels is that all items with the same Access will be viewable by the same group of users. In other words, if two items have the same Access, you can't have one viewable by one user and not viewable by another user. On the other hand, it is easy to have one Group view any number of items with different Access levels.

Similarly, each Group has exactly the same combination of Access levels, but one User can be a member of more than one group. Depending on the situation, you may want to have users only in one Group or you may need to have a User in more than one Group.

This means that we may need to group our items so that items so that all items in a group have the same level of sensitivity. Here are some examples.

===Hierarchisches Beispiel===
In this example, Access levels are hierarchical, for example, like government security clearance codes. Say for example we have the following sets of classified documents: Classified, Secret, and Top Secret. Users have corresponding clearence codes. Users with Classified clearance can only see Classified documents and cannot see Secret or Top Secret. Users with Secret clearance can see Classified and Secret documents but not Top Secret. Users with Top Secret can see all documents.

In this case, you would create three Access levels: Classified, Secret, and Top Secret and the same three Groups. Users would only be members of one group, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| C1, C2, C3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Classified
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| S1, S2, S3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| TS1, TS2, TS3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Top Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret, Top Secret

|}

In this case, all users are in exactly one group, but some groups have access to more than one Access Level of items. In other words, we have a one-to-one relationship between users and groups, but a one-to-many relationship between Groups and Access Levels.

===Teamsicherheit Beispiel===

Another possible use case is a set of non-hierarchical teams. Let's say we have three teams, T1, T2, and T3. Some users are only on one team, but others might be on two or more teams. In this case, we could set up our Access Levels and Groups by team. Documents for each team have the access level for that team, and the Group for the team has only the one access level. When a User is on more than one team, they get added to the group for each team, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Beschreibung
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 1 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 2 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 3 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1, 2 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1,T2, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2, T3

|}

===Hybrid Example===

In a real-world situation, you might have a combination of these two arrangements. Say for example we have Managers and Staff. Staff can only see Staff documents and Managers can see Manager and Staff documents. Both types of users can be assigned to teams as well, in which case they can see all of the documents for that team. In addition, say that Managers can access some, but not all, team documents. Staff can only access team documents if they are members of that team.

In this example, we could set up the following Access Levels:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Access Level
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Description
| style="border:0.0007in solid #000000;padding:0.0382in;"| Groups

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team manager documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team staff documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team1 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1, Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team2 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2, Manager

|}

Then, users could be assigned to groups as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| User Type
| style="border:0.0007in solid #000000;padding:0.0382in;"| Group

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1, Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1, Team2

|}

<noinclude>
[[Category:Joomla! 1.6]]
[[Category:Joomla! 2.5]]
[[Category:Joomla! 3.x/de]]
[[Category:Tutorials/de]]
[[Category:Access Control/de]]
[[Category:Access Management]]
</noinclude>

Translations:J3.x:Access Control List Tutorial/135/de

2019-12-26T19:01:13Z

Sieger66:

J3.x:Access Control List Tutorial/de

2019-12-26T19:01:04Z

Sieger66:

<noinclude><languages /></noinclude>
{{Joomla version|version=3.x|comment=Serie}}
{{-}}
{{:J3.1:Access_Control_List/en}}

==Separate ACL für Anzeige und Aktionen==

Das Joomla ACL-System besteht genau genommen aus zwei völlig getrennten Systemen. Das eine System steuert, was Benutzer auf der Website "sehen" können. Das andere steuert, was Benutzer "tun" können (welche Aktionen ein Benutzer durchführen kann). Die ACL wird für jedes dieser Systeme anders eingerichtet.

===Steuern, was Benutzer sehen können===

Das Setup zum Steuern, was Benutzer sehen können, sieht wie folgt aus:
*Eine Reihe von Zugriffsebenen gemäß den Kategorien und/oder der Kombination von Kategorien erstellen, die nur angemeldete Benutzer sehen sollen. Anmerkung: Zu diesem Zeitpunkt werden noch keine Benutzergruppen den neuen Zugriffsebenen zugewiesen.

*Für jede Zugriffsebene eine Benutzergruppe erstellen, die 'Registriert' als übergeordnete Gruppe hat. Indem man für Benutzergruppen und Zugriffsebenen die gleichen Namen verwendet, kann man Verwirrungen zu einem späteren Zeitpunkt vorbeugen.

*Die neuen Zugriffsebenen bearbeiten und jeder die (neue) Benutzergruppe zuweisen. Wahrscheinlich möchten man auch die 'Super Benutzer' Gruppe (und/oder die anderen Standard-Benutzergruppen mit Ausnahme der Benutzergruppe 'Gast') den neuen Zugriffsebenen zuweisen.

*Jedem anzuzeigenden Eintrag eine Zugriffsebene zuweisen. Einträge sind sowohl inhaltliche Einträge (Beiträge, Kontakte, usw.), Menüeinträge als auch Module.

Immer dann, wenn ein Benutzer im Begriff ist, einen Eintrag auf einer Joomla-Seite anzeigen zu lassen, prüft das Programm, ob dieser Benutzer auch Zugriff auf den Eintrag hat. Das geschieht folgendermaßen:
# Zunächst wird eine Liste aller Zugriffsebenen erstellt, auf die der Benutzer zugreifen kann, basierend auf allen Gruppen, denen der Benutzer angehört. Sofern eine Gruppe eine übergeordnete Gruppe besitzt, sind die Zugriffsebenen für die übergeordnete Gruppe ebenfalls in der Liste enthalten.
# Danach wird überprüft, ob die Zugriffsebene für den Eintrag (Beitrag, Modul, Menüeintrag, usw.) in dieser Liste enthalten ist. Wenn dem so ist, wird der Eintrag dem Benutzer angezeigt. Falls der Benutzer die benötigten Zugriffsrechte besitzt, wird ihm der Zugriff verweigert.

Beachten, dass Zugriffsebenen für jede Gruppe separat festgelegt und nicht von der übergeordneten Gruppe einer Gruppe vererbt werden.

===Steuern, was Benutzer tun können===

Das System, das steuert, was Benutzer in einer Benutzergruppe tun können - welche Aktionen sie bei einem bestimmten Eintrag ausführen können - wird über den Tab 'Berechtigungen' in der Konfiguration und den Tab 'Berechtigungen' in den Optionen jeder einzelnen Komponente eingerichtet. Berechtigungen können auch auf Kategorienebene (bei Kernkomponenten) und auf Beitragsebene (bei Beiträgen) gesetzt werden.

* Wenn angemeldete Benutzer in bestimmten Kategorien Erstellen, Löschen, Status bearbeiten oder Eigene Inhalte bearbeiten dürfen, dann:
** Eine Benutzergruppe erstellen und als übergeordnete Gruppe eine der Benutzergruppen angeben, die Zugriff auf die Kategorie (oder Kategorien) haben, die diese neue Benutzergruppe ändern soll.
**Der neuen Benutzergruppe den entsprechenden Zugriffsebenen zuweisen. Dann die erforderlichen Berechtigungen für die neue Benutzergruppe entweder global oder pro Kategorie/Beitrag ändern.
*** Beim Erstellen einer Benutzergruppe ist es ratsam, eine übergeordnete Gruppe zu wählen, die über weniger Berechtigungen verfügt, als für die neue Gruppe erforderlich. Denn es ist einfacher, die Berechtigungen für jede Komponente/Kategorie/Beitrag zu erweitern, für die zusätzliche Berechtigungen nötig sind, als Berechtigungen aus den anderen Komponenten/Kategorien/Beiträgen zu entfernen.
****''(Beispiel: Es gibt 10 Kategorien, man möchte aber nur für eine Erstellen-Berechtigungen. Würde man für diese Gruppe die Berechtigungen global auf Erstellen erlaubt setzen, müsste man für diese Kategorien die Erstellen-Berechtigung entfernen. Und man müsste für diese Gruppe die Erstellen-Berechtigung bei jeder neuen Kategorie, die man zu einem späteren Zeitpunkt hinzufügt, ebenfalls entfernen).''
** Eine Benutzergruppe erstellen, die eine der Standardbenutzergruppen als übergeordnete Gruppe hat, NUR, wenn keine von diesen über die exakten Berechtigungen verfügt, die man benötigt und sich für alle Kategorien wünscht.

Beachten, dass dieses Setup unabhängig vom Setup für die Anzeige ist. Allerdings muss eine Benutzergruppe den entsprechenden Zugriffsebenen zugewiesen werden, damit der Benutzer in dieser Gruppe jene Berechtigungen verwenden kann.

Möchte ein Benutzer eine bestimmte Aktion bei einem Komponenten-Eintrag durchführen (z. B. einen Beitrag bearbeiten), überprüft das System (nachdem es überprüft hat, welcher Gruppe der Benutzer angehört und auf welche er Zugriff hat) die Berechtigung für diese Kombination aus Benutzer, Eintrag und Aktion. Liegt eine Erlaubnis vor, kann der Benutzer fortfahren. Andernfalls ist die Aktion nicht zulässig.

Das restliche Tutorial befasst sich mit der Steuerung, was Benutzer tun können - welche Aktionsberechtigungen sie haben.

==Aktionen, Gruppen und Vererbung==

Andererseits geht es bei der ACL auch darum, Benutzern Berechtigungen zu erteilen, damit diese Aktionen an Objekten durchführen können.

{| class="wikitable"
!style="width:20%;"|
!3.x Serie
|-
!Gruppen und Aktionen
|Aktionen, welche pro Gruppe erlaubt sind, werden durch den Website Administrator festgelegt.
|-
!Umfang von Berechtigungen
|Berechtigungen können auf mehreren Ebenen in der Hierarchie festgelegt werden: Website, Komponente, Kategorie, Objekt.
|-
!Vererbung von Berechtigungen
|Berechtigungen können von übergeordneten Gruppen und übergeordneten Kategorien geerbt werden.
|}

===Wie die Berechtigungen funktionieren===

Es gibt vier mögliche Berechtigungen für Aktionen. Diese sind (kurz skizziert):

* '''Nicht gesetzt''': Fällt standardmäßig auf "Nicht erlaubt" zurück. Aber im Gegensatz zur Berechtigung "Verweigert" kann diese Berechtigung außer Kraft gesetzt werden, wenn eine untergeordnete Gruppe oder eine in der Berechtigungshierarchie untergeordnete Ebene auf "Erlaubt" gesetzt wird. Diese Berechtigung kann nur für globale Berechtigungen der Konfiguration gesetzt werden.
* '''Vererbt''': Erbt den Wert von einer übergeordneten Gruppe oder einer in der Berechtigungshierarchie höheren Ebene. Diese Berechtigung gilt für alle Ebenen mit Ausnahme der obersten Ebene der Konfiguration.
* '''Verweigert''': Verbietet diese Aktion für diese Ebene und Gruppe. '''WICHTIG:''' Dadurch wird diese Aktion auch für alle untergeordneten Gruppen und alle untergeordneten Ebenen in der Berechtigungshierarchie verboten. Wird "Erlaubt" in einer untergeordneten Gruppe oder einer tieferen Ebene gesetzt, hat das keinen Effekt. Die Aktion wird immer für alle Mitglieder einer untergeordneten Gruppe und für alle untergeordneten Ebenen in der Berechtigungshierarchie abgelehnt.
* '''Erlaubt ''': Genehmigt diese Aktion für diese Ebene und Gruppe und für tiefere Ebenen und Untergruppen. Dies hat keine Auswirkungen, wenn eine höhere Gruppe oder Ebene auf "Verweigert" oder "Erlaubt" eingestellt ist. Wenn eine höhere Gruppe oder ein höheres Ebene auf "Verweigert" gesetzt ist, wird diese Berechtigung immer abgelehnt. Wenn eine höhere Gruppe oder Ebene auf Erlaubt eingestellt ist, ist diese Berechtigung bereits erlaubt.

===Hierarchie der Berechtigungsebenen===

Berechtigungen für Aktionen können in Version 2.5+ auf bis zu vier Ebenen festgelegt werden, wie folgt:
# '''Konfiguration''': legt die Standardberechtigungen für jede Aktion und Gruppe fest.
# '''Komponenten-Optionen-> Berechtigungen''': kann die Standardberechtigungen für diese Komponente überschreiben (z. B. Beiträge, Menüs, Benutzer, Banner usw.).
# '''Kategorie''': kann die Standardberechtigungen für Objekte in einer oder mehreren Kategorien überschreiben. Gilt für alle Komponenten mit Kategorien, einschließlich Beiträge, Banner, Kontakte, Newsfeeds und Weblinks.
# '''Beitrag''': kann die Berechtigungen für einen bestimmten Artikel überschreiben. Diese Ebene gilt nur für Beiträge. Alle anderen Komponenten erlauben nur die ersten drei Ebenen.

====Konfiguration====
Diese erreicht man über System → Konfiguration → Berechtigungen. Die nun sichtbare Maske dient dazu, die Berechtigungen auf der obersten Ebene für jede Gruppe und jede Aktion festzulegen, wie auch in der folgenden Abbildung gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Die möglichen Werte sind Vererbt, Erlaubt oder Verweigert. Die Spalte 'Errechnete Einstellung' zeigt die aktuelle Einstellung an. Diese ist entweder Nicht erlaubt (Standard), Erlaubt oder Nicht erlaubt.

Man kann immer nur an einer Gruppe gleichzeitig arbeiten, indem man den Reiter für ebendiese Gruppe anklickt. Die Berechtigungen kann man über die Dropdownlisten unter Neue Einstellung wählen ändern.

Beachten Sie, dass die Spalte "Errechnete Einstellung" erst aktualisiert wird, wenn Sie auf die Schaltfläche "Speichern" in der Werkzeugleiste klicken.

Um zu überprüfen, ob die Einstellungen Ihren Wünschen entsprechen, klicken Sie auf die Schaltfläche Speichern und überprüfen anschließend die Spalte Errechnete Einstellung.

====Komponenten-Optionen->Berechtigungen====
Auf diese wird für jede Komponente durch Klicken auf das Symbol "Optionen" in der Werkzeugleiste zugegriffen. Dieser Bildschirm ist ähnlich wie der Bildschirm "Globale Konfiguration" oben links. Wenn Sie beispielsweise im Menü-Manager auf das Symbol in der Werkzeugleiste Optionen klicken, werden die folgenden Menüs angezeigt.
[[Image:Screenshot_menu_acl_J3_tutorial-en.jpg]]

Der Zugriff auf Optionen ist nur für Mitglieder von Gruppen möglich, die die Berechtigung für die Aktion Konfiguration in für jede Komponente haben. Im obigen Beispiel hat die Gruppe Administrator die Berechtigung Erlaubt für die Option Konfigurieren, so dass Mitglieder dieser Gruppe auf diesen Bildschirm zugreifen können.

===Kategorie===
Auf die Kategorieberechtigungen wird im Category Manager zugegriffen: Bildschirm Kategorie bearbeiten, in einer Registerkarte oben auf dem Bildschirm. Dieser Bildschirm hat fünf Berechtigungen, wie folgt:

[[Image:Screenshot_category_acl_j3_tutorial-en.png]]

In diesen Bildern bearbeiten Sie die Berechtigungen für jeweils eine Benutzergruppe. Im obigen Beispiel bearbeiten Sie die Berechtigungen für die Gruppe Administrator.

Achten Sie darauf, dass die Aktionen "Konfigurieren und Zugriffssteuerung" nicht auf der Kategorieebene angewendet werden, so dass diese Aktionen nicht enthalten sind.

Beachten Sie auch, dass Kategorien in einer Hierarchie angeordnet werden können. Wenn ja, dann werden Aktionsberechtigungen in einer übergeordneten Kategorie automatisch an eine untergeordnete Kategorie vererbt. Wenn Sie beispielsweise eine Kategoriehierarchie von Tieren → Haustiere → Hunde hätten, dann würde die vollständige Berechtigungshierarchie für einen Artikel in der Kategorie Hunde wie folgt aussehen:
* Globale Konfiguration
* Artikel-Manager → Optionen → Genehmigung → Erlaubnis
* Tierkategorie
* Kategorie Haustiere
* Kategorie Hunde
* spezifischer Artikel

====Beitrag====
Berechtigungen für einzelne Beiträge findet man im "Beitrag" unter dem Tab-Reiter "Berechigungen". Dieser Bildschirm hat drei Aktionen, wie unten gezeigt.

[[Image:j3x_acl_tutorial_article_manager_article_permissions-en.png]]

Auch hier bearbeiten Sie jede Gruppe für sich. Um auf die Berechtigungen zuzugreifen wechseln Sie im Artikel auf den Reiter "Berechtigungen" im oberen Reiter. Über das Drop Down Menü wählen Sie die neue Berechtigung im Anschluss speichern Sie den Beitrag ab.

Beachten Sie, dass die Aktionen Configure, Access Component und Create auf Artikelebene nicht gelten, so dass diese Aktionen nicht berücksichtigt werden. Die Berechtigung zum Anlegen eines Artikels wird auf einer der höheren Ebenen der Hierarchie festgelegt.

===Zugriffsebenen===

Die Zugriffsebenen der 3.x-Serie sind einfach und flexibel. Der folgende Bildschirm zeigt die spezielle Zugriffsebene.
[[Image:j3x_acl_tutorial_viewing_levels-en.png|center]]
Aktivieren Sie einfach das Kontrollkästchen für jede Gruppe, die Sie in diesem Level aufnehmen wollen. Die spezielle Zugriffsebene umfasst die Gruppen Manager, Autor und Superuser. Es beinhaltet auch untergeordnete Gruppen dieser Gruppen. Die Gruppe Administrator ist also enthalten, da es sich um eine Untergruppe der Gruppe Manager handelt. Die Gruppen Editor, Publisher und Shop Suppliers sind enthalten, da es sich um Untergruppen des Autors handelt.

Jedem Objekt im Frontend ist eine Zugriffsebene zugeordnet. Wenn die Ebene öffentlich ist, kann jeder auf dieses Objekt zugreifen. Andernfalls dürfen nur Mitglieder von Gruppen, die dieser Zugriffsebene zugeordnet sind, auf dieses Objekt zugreifen.

Die Zugriffsebenen sind den Menüpunkten und den Modulen zugeordnet. Jede kann nur einer Zugriffsebene zugeordnet werden.

Der folgende Bildschirm zeigt beispielsweise den Bildschirm Menüpunkt bearbeiten mit der Liste der verfügbaren Zugriffsebenen....

[[Image:j3x_acl_tutorial_edit_menu_item_level_dropdown-en.png|center]]

==Standard-ACL-Setup==

Wenn Joomla! installiert ist, werden diese auf die ursprünglichen Standardwerte gesetzt. Wir werden diese Grundeinstellungen besprechen, um die Arbeitsweise der ACL zu verstehen.

===Standardgruppen===

Mit der Version 3.x können Sie Ihre individuellen Gruppen definieren. Wenn Sie die Version 3.x installieren, enthält sie eine Reihe von Standardgruppen, die im Folgenden dargestellt werden, sind die grundlegenden Standardbenutzergruppen. (Zusätzliche Standardbenutzergruppen werden mit Beispieldaten installiert)

[[Image:Screenshot_usergroupsl_acl_J3_tutorial-en.png|center]]

Die Pfeile zeigen die untergeordneten Elternbeziehungen an. Wie vorstehend besprochen, wird diese Berechtigung, wenn Sie eine Berechtigung für eine übergeordnete Gruppe festlegen, automatisch an alle Untergruppen vererbt. Die vererbten und zulässigen Berechtigungen können für eine Untergruppe überschrieben werden. Die Berechtigung Verweigert kann nicht überschrieben werden und verweigert immer eine Aktion für alle Untergruppen.

===Konfiguration===

Joomla! Version 3.x wird mit den gleichen bekannten Backend-Rechten wie die Version 1.5 (EOL) installiert. Mit der Version 3.x können Sie diese jedoch leicht an die Bedürfnisse Ihrer Website anpassen.

Wie bereits besprochen, werden die Berechtigungen für jede Aktion von der obigen Ebene in der Berechtigungshierarchie und von der übergeordneten Gruppe einer Gruppe übernommen. Also, wie funktioniert das? Die oberste Ebene dafür ist der gesamte Standort. Dies wird in der Site->Globale Konfiguration->Berechtigungen eingerichtet, wie unten gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Das erste, was man bemerken sollte, sind die zehn Aktionen: Standortlogin, Admin-Login, Offline-Zugriff, Superuser, Access Administration Interface, Erstellen, Löschen, Bearbeiten, Status bearbeiten und Eigenes bearbeiten. Dies sind die Aktionen, die ein Benutzer an einem Objekt in Joomla durchführen kann. Die spezifische Bedeutung jeder Aktion hängt vom Kontext ab. Für das Bild Globale Konfiguration sind sie wie folgt definiert:

Site Login : Login to the front end of the site

;Admin Login : Melden Sie sich am Backend der Website an.

Offline-Zugriff: Melden Sie sich am Frontend der Website an, wenn die Website offline ist (wenn die globale Konfigurationseinstellung "Site Offline" auf Ja gesetzt ist).

Superuser: Gewährt dem Benutzer den Status "Superuser". Benutzer mit dieser Berechtigung dürfen alles auf der Website machen. Nur Benutzer mit dieser Berechtigung können die Einstellungen der globalen Konfiguration ändern. Diese Berechtigungen können nicht eingeschränkt werden. Es ist wichtig zu verstehen, dass, wenn ein Benutzer Mitglied einer Super Admin-Gruppe ist, alle anderen Berechtigungen, die diesem Benutzer zugewiesen sind, irrelevant sind. Der Benutzer kann jede Aktion auf der Website durchführen. Es können jedoch weiterhin Zugriffsebenen zugewiesen werden, um zu steuern, was diese Gruppe auf der Website sieht. (Natürlich kann ein Super-Admin-Benutzer die Zugriffsebenen ändern, wenn er möchte, so dass die Zugriffsebenen nicht vollständig einschränken, was ein Super-Admin-Benutzer sehen kann.)

Zugangskomponente: Öffnen Sie die Bildschirme der Komponentenverwaltung (Benutzerverwaltung, Menüverwaltung, Artikelverwaltung usw.).

;Create : Create new objects (for example, users, menu items, articles, weblinks, and so on)

;Löschen : Löschen eines existienden Objekts

;Ändern : Ändern eines existierenden Objektes

;Ändern eines Objekt Status (Veröffentlicht, nicht Veröffentlicht, Archiviert und Gelöscht)

Eigene Objekte bearbeiten: Bearbeiten Sie Objekte, die Sie erstellt haben.

Each Group for the site has its own slider which is opened by clicking on the group name. In this case (with the sample data installed), we have the standard 7 groups that we had in version 1.5 plus two additional groups called "Shop Suppliers" and "Customer Group". Notice that our groups are set up with the same permissions as they had in version 1.5. Keep in mind that we can change any of these permissions to make the security work the way we want. Let's go through this to see how it works.

* '''Public''' has everything set to "Not set", as shown below.{{-}}[[Image:Screenshot_global_acl_public_J3_tutorial-en.png]]
**This can be a bit confusing. Basically, "Not Set" is the same as "Inherited". Because Public is our top-level group, and because Global Configuration is the top level of the component hierarchy, there is nothing to inherit from. So "Not Set" is used instead of "Inherit".
**The default in this case is for no permissions. So, as you would expect, the Public group has no special permissions. Also, it is important to note that, since nothing is set to Denied, all of these permissions may be overridden by child groups or by lower levels in the permission hierarchy.

* '''Guest''' is a 'child' group of the Public group has everything set to 'Inherited' {{-}}[[Image:Screenshot_global_acl_guest_J3_tutorial-de.png]]
** This is the default 'Guest User Group' in the User Manager options and the Group that (non logged in) visitors to your site are placed in.

* '''Manager''' is a "child" group of the Public group. It has Allowed permissions for everything except Access Component and Super Admin. So a member of this group can do everything in the front and back end of the site except change Global Permissions and Component Options. {{-}}[[Image:Screenshot_global_acl_manager_J3_tutorial-en.png]]

* '''Administrator''' group members inherit all of the Manager permissions and also have Allowed for Access Component. So members of this group by default can access the Options screens for each component. {{-}}[[Image:Screenshot_global_acl_administrator_J3_tutorial-en.png]]

* '''Registered''' is the same a Public except for the Allow permission for the Site Login action. This means that members of the Registered group can login to the site. Since default permissions are inherited, this means that, unless a child group overrides this permission, all child groups of the Registered group will be able to login as well. {{-}}[[Image:Screenshot_global_acl_registered_J3_tutorial-en.png]]

* '''Author''' is a child of the Registered group and inherits its permissions and also adds Create and Edit Own. Since Author, Editor, and Publisher have no back-end permissions, we will discuss them below, when we discuss front-end permissions.{{-}}[[Image:Screenshot_global_acl_author_J3_tutorial-en.png]]

* '''Editor''' is a child of the Authors group and adds the Edit permission. {{-}}[[Image:Screenshot_global_acl_editor_J3_tutorial-en.png]]

* '''Publisher''' is a child of Editor and adds the Edit State permission.{{-}}[[Image:Screenshot_global_acl_publisher_J3_tutorial-en.png]]

* '''Shop Suppliers''' is an example group that is installed if you install the sample data. It is a child group of Author.

* '''Customer Group''' is an example group that is installed if you install the sample data. It is a child group of Registered.

* '''Super Users''' group has the Allow permission for the Super Admin action. Because of this, members of this group have super user permissions throughout the site. They are the only users who can access and edit values on the Global Configuration screen. Users with permission for the Super Admin action have some special characteristics:
:* If a user has Super Admin permissions, no other permissions for this user matter. The user can perform any action on the site.
:* Only Super Admin users can create, edit, or delete other Super Admin users or groups.

There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.

This provides a lot of flexibility. For example, if you wanted Shop Suppliers to be able to have the ability to login to the back end, you could just change their Admin Login value to "Allowed". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherited (or Denied).

It is also important to understand that the ability to have child groups is completely optional. It allows you to save some time when setting up new groups. However, if you like, you can set up all groups to have Public as the parent and not inherit any permissions from a parent group.

===Komponenten-Optionen & Berechtigungen===

Now, let's continue to see how the default back-end permissions for version 2.5 mimic the permissions for version 1.5. The Super Users group in 2.5 is equivalent to the Super Administrator group in 1.5.

Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 2.5 configuration. Let's see how this is accomplished.

If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:

[[Image:screenshot_acl_tutorial_20110111-09-en.png|center|]]
[[Image:screenshot_acl_tutorial_20110111-10-en.png|center|]]

This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.

First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.

Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.

If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.

In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.

It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.

===Frontend Berechtigungen===

Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions. First, let's look at the permissions for Manager, as shown below.
[[Image:screenshot_acl_tutorial_20110111-11a-de.png|center|frame]]
Manager has allowed permission for all actions except Configure. So members of the Manager group can do everything with Articles except open the Options screen.

Now let's look at Administrator, as shown below.
[[Image:screenshot_acl_tutorial_20110111-12a-de.png|center|frame]]
Administrator has Allowed for Configure, so Administrators can edit this Options screen.

Both groups can create, delete, edit, and change the state of articles.

Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set.

Authors only have Create and Edit Own permissions, as shown below.
[[Image:screenshot_acl_tutorial_20110112-07-de.png|center|frame]]
This means that Authors can create articles and can edit articles they have created. They may not delete articles, change the published state of articles, or edit articles created by others.

Editors have the same permissions as Authors with the addition of permission for the Edit action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-08-de.png|center|frame]]
So Editors can edit articles written by anyone.

Publishers can do everything Editors can do plus they have permission for the Edit State action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-09-de.png|center|frame]]
So Publishers can change the published state of an article. The possible states include Published, Unpublished, Archived, and Trashed.

All of these groups have Inherit permission for Configure and Access Component. Remember that Author is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Configure and Access Component, and since Author's permission for these actions is "Inherited", then Author does not have these permissions either. This same permission is passed from Author to Editor and from Editor to Publisher. So, by default, none of these groups are allowed to work with articles in the back end.

It is important to remember that these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.

Beachte auch das in den ursprünglichen Standardwerten keine Berechtigungen auf Verweigert eingestellt sind. Dies ermöglicht in allen Berechtigungsebenen die jeweilige Berechtigung auf Erlaubt einzustellen. Bedenke, wenn eine Aktion auf Verweigert eingestellt ist, das diese Aktion auch in allen untergeordneten Ebenen in der Berechtigungshierarchie verweigert wird. Zum Beispiel, wenn die Seitenameldung für Registered auf Verweigert (anstatt auf Erlaubt) eingestellt wird, kann man Publishers diese Aktion per Berechtigungeinstellung nicht erteilen.

=== Beitrags-Manager & Aktions-Diagramm ===

The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.

[[Image:screenshot_acl_tutorial_20110111-16-de.png|center|]]

* '''Configure''' allows you to view and change the Options for the component.
* '''Access Component''' allows you to navigate to the Article Manager. Without this permission, no other actions are possible.
* '''Create''' allows you to add new articles.
* '''Delete''' allows you to delete trashed articles. Note that the Delete icon only shows in the toolbar when you have the "Select State" filter set to "Trash".
* '''Edit''' allows you to edit existing articles.
* '''Edit State''' allows to you Publish, Unpublish, Archive, or Trash articles.
* '''Edit Own''' is the same as Edit except that it only applies to articles written by you.

==Allowing Guest-Only Access to Menu Items and Modules==

Version 1.6 introduced the ability to create a View Access Level that is only for guests of the site (meaning a user who is not logged in). The example below shows how you can set up this new feature.
''(N.B. Steps 1 to 3 are not needed for Joomla! 3.x as they exist in the default install)''

#Create a new user group called Guest. Make it a child of the Public group as shown below. [[Image:screenshot_acl_tutorial_20110112-01-de.png|center|frame]]
# Create a new access level called Guest and grant only the Guest group access to this level, as shown below.[[Image:screenshot_acl_tutorial_20110112-02-de.png|center|frame]]
# Navigate to User Manager→Options→Component and change the Guest User Group from the default value of "Public" to "Guest", as shown below.
[[Image:screenshot_acl_tutorial_20110112-04-de.png|center|frame]]
Now, if we assign a menu item, module, or other object to the Guest access level, only non-logged in users will have access. For example, if we create a new menu item with access level of Guest, as shown below,
[[Image:screenshot_acl_tutorial_20110112-05-de.png|center|frame]]
this menu item will only be visible to non-logged-in visitors to the site.

If required other user groups like Author can be granted access in the Guest access level, this would allow Authors to view articles in the front end for editing.

'''N.B. Login/logout in front end (''for changing data in session'') to see the change.'''

==Berechtigungen und Gruppenebenen gemeinsam nutzen==

As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.

This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:

* both groups can create new articles only in the History Assignments category.

* only History Teachers (not Assistant History Teachers) can Publish or otherwise have Edit State permission.

This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.

[[Image:Acl example diagram1 20091018-de.png|center|]]

In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.

To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.

Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.

[[Image:Acl example diagram2 20091018-de.png|center|]]

This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.

Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.

==ACL Aktion Berechtigungs-Beispiele==

===Backend Beitrag Administrator===

'''Problem:'''

We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.

'''Lösung:'''

# Create a new group called Article Administrator and make its parent group Public, as shown below.[[Image:screenshot_acl_tutorial_20110112-10-de.png|center|frame]] Because its parent group is Public, it won't have any permissions by default.
# In Users → Access Levels, edit the Special Access level to add the new group. That way they can get access to the back end menu items and modules (This assumes that the modules for the admin menu and quickicons have the Special Access level assigned to them, which is the default.) [[Image:screenshot_acl_tutorial_20110112-11-de.png|center|frame]] By default, the back-end menu items and modules are set to Special access, so if you forget to add the new group to the Special access level, you won't see any modules or menu items when you log in as a user of the new group.
# In Site → Global Configuration → Permissions, click on the Article Administrator group and change the permissions to Allowed for the following actions: Admin Login, Create, Delete, Edit, Edit State, and Edit Own. The screen below shows what will show before you press Save. [[Image:screenshot_acl_tutorial_20110112-12-de.png|center|frame]]After you save, the Calculated Permissions should show as shown below.[[Image:screenshot_acl_tutorial_20110112-13-de.png|center|frame]]Note that the permission for the Access Component is Inherited, which translates to Not Allowed. This is important. This means that this group will only be able to access components if we give the group "Allowed" permission for Access Component. So we only have to change the one component we want to give them access to and don't have to change any settings for the components where we don't want them to have access. If we had a case where we wanted to give a group access to everything except for one component, we could set the default to Allowed and then set the one component to Denied. Also note that we did not give the group Site Login permission, so users in this group will not be able to log into the front end. (If we wanted to allow that, we would just change the permission to Allowed for Site Login.)
# In Article Manager → Options → Permissions, change permissions to Allowed for this group for the Access Component action, as shown below.[[Image:screenshot_acl_tutorial_20110112-14-de.png|center|frame]]All of the other desired permissions are inherited.

That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end. For example, the screen below shows what a user in the Article Manager will see when they login to the back end.[[Image:screenshot_acl_tutorial_20110112-15-de.png|center|frame]]

==ACL Ansicht Zugriffsebenen-Beispiele==

A basic concept of using Access Levels is that all items with the same Access will be viewable by the same group of users. In other words, if two items have the same Access, you can't have one viewable by one user and not viewable by another user. On the other hand, it is easy to have one Group view any number of items with different Access levels.

Similarly, each Group has exactly the same combination of Access levels, but one User can be a member of more than one group. Depending on the situation, you may want to have users only in one Group or you may need to have a User in more than one Group.

This means that we may need to group our items so that items so that all items in a group have the same level of sensitivity. Here are some examples.

===Hierarchisches Beispiel===
In this example, Access levels are hierarchical, for example, like government security clearance codes. Say for example we have the following sets of classified documents: Classified, Secret, and Top Secret. Users have corresponding clearence codes. Users with Classified clearance can only see Classified documents and cannot see Secret or Top Secret. Users with Secret clearance can see Classified and Secret documents but not Top Secret. Users with Top Secret can see all documents.

In this case, you would create three Access levels: Classified, Secret, and Top Secret and the same three Groups. Users would only be members of one group, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| C1, C2, C3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Classified
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| S1, S2, S3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| TS1, TS2, TS3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Top Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret, Top Secret

|}

In this case, all users are in exactly one group, but some groups have access to more than one Access Level of items. In other words, we have a one-to-one relationship between users and groups, but a one-to-many relationship between Groups and Access Levels.

===Teamsicherheit Beispiel===

Another possible use case is a set of non-hierarchical teams. Let's say we have three teams, T1, T2, and T3. Some users are only on one team, but others might be on two or more teams. In this case, we could set up our Access Levels and Groups by team. Documents for each team have the access level for that team, and the Group for the team has only the one access level. When a User is on more than one team, they get added to the group for each team, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Beschreibung
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 1 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 2 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 3 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1, 2 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1,T2, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2, T3

|}

===Hybrid Example===

In a real-world situation, you might have a combination of these two arrangements. Say for example we have Managers and Staff. Staff can only see Staff documents and Managers can see Manager and Staff documents. Both types of users can be assigned to teams as well, in which case they can see all of the documents for that team. In addition, say that Managers can access some, but not all, team documents. Staff can only access team documents if they are members of that team.

In this example, we could set up the following Access Levels:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Access Level
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Description
| style="border:0.0007in solid #000000;padding:0.0382in;"| Groups

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team manager documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team staff documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team1 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1, Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team2 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2, Manager

|}

Then, users could be assigned to groups as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| User Type
| style="border:0.0007in solid #000000;padding:0.0382in;"| Group

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1, Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1, Team2

|}

<noinclude>
[[Category:Joomla! 1.6]]
[[Category:Joomla! 2.5]]
[[Category:Joomla! 3.x/de]]
[[Category:Tutorials/de]]
[[Category:Access Control/de]]
[[Category:Access Management]]
</noinclude>

Translations:J3.x:Access Control List Tutorial/126/de

2019-12-26T19:01:03Z

Sieger66:

J3.x:Access Control List Tutorial/de

2019-12-26T19:00:57Z

Sieger66:

<noinclude><languages /></noinclude>
{{Joomla version|version=3.x|comment=Serie}}
{{-}}
{{:J3.1:Access_Control_List/en}}

==Separate ACL für Anzeige und Aktionen==

Das Joomla ACL-System besteht genau genommen aus zwei völlig getrennten Systemen. Das eine System steuert, was Benutzer auf der Website "sehen" können. Das andere steuert, was Benutzer "tun" können (welche Aktionen ein Benutzer durchführen kann). Die ACL wird für jedes dieser Systeme anders eingerichtet.

===Steuern, was Benutzer sehen können===

Das Setup zum Steuern, was Benutzer sehen können, sieht wie folgt aus:
*Eine Reihe von Zugriffsebenen gemäß den Kategorien und/oder der Kombination von Kategorien erstellen, die nur angemeldete Benutzer sehen sollen. Anmerkung: Zu diesem Zeitpunkt werden noch keine Benutzergruppen den neuen Zugriffsebenen zugewiesen.

*Für jede Zugriffsebene eine Benutzergruppe erstellen, die 'Registriert' als übergeordnete Gruppe hat. Indem man für Benutzergruppen und Zugriffsebenen die gleichen Namen verwendet, kann man Verwirrungen zu einem späteren Zeitpunkt vorbeugen.

*Die neuen Zugriffsebenen bearbeiten und jeder die (neue) Benutzergruppe zuweisen. Wahrscheinlich möchten man auch die 'Super Benutzer' Gruppe (und/oder die anderen Standard-Benutzergruppen mit Ausnahme der Benutzergruppe 'Gast') den neuen Zugriffsebenen zuweisen.

*Jedem anzuzeigenden Eintrag eine Zugriffsebene zuweisen. Einträge sind sowohl inhaltliche Einträge (Beiträge, Kontakte, usw.), Menüeinträge als auch Module.

Immer dann, wenn ein Benutzer im Begriff ist, einen Eintrag auf einer Joomla-Seite anzeigen zu lassen, prüft das Programm, ob dieser Benutzer auch Zugriff auf den Eintrag hat. Das geschieht folgendermaßen:
# Zunächst wird eine Liste aller Zugriffsebenen erstellt, auf die der Benutzer zugreifen kann, basierend auf allen Gruppen, denen der Benutzer angehört. Sofern eine Gruppe eine übergeordnete Gruppe besitzt, sind die Zugriffsebenen für die übergeordnete Gruppe ebenfalls in der Liste enthalten.
# Danach wird überprüft, ob die Zugriffsebene für den Eintrag (Beitrag, Modul, Menüeintrag, usw.) in dieser Liste enthalten ist. Wenn dem so ist, wird der Eintrag dem Benutzer angezeigt. Falls der Benutzer die benötigten Zugriffsrechte besitzt, wird ihm der Zugriff verweigert.

Beachten, dass Zugriffsebenen für jede Gruppe separat festgelegt und nicht von der übergeordneten Gruppe einer Gruppe vererbt werden.

===Steuern, was Benutzer tun können===

Das System, das steuert, was Benutzer in einer Benutzergruppe tun können - welche Aktionen sie bei einem bestimmten Eintrag ausführen können - wird über den Tab 'Berechtigungen' in der Konfiguration und den Tab 'Berechtigungen' in den Optionen jeder einzelnen Komponente eingerichtet. Berechtigungen können auch auf Kategorienebene (bei Kernkomponenten) und auf Beitragsebene (bei Beiträgen) gesetzt werden.

* Wenn angemeldete Benutzer in bestimmten Kategorien Erstellen, Löschen, Status bearbeiten oder Eigene Inhalte bearbeiten dürfen, dann:
** Eine Benutzergruppe erstellen und als übergeordnete Gruppe eine der Benutzergruppen angeben, die Zugriff auf die Kategorie (oder Kategorien) haben, die diese neue Benutzergruppe ändern soll.
**Der neuen Benutzergruppe den entsprechenden Zugriffsebenen zuweisen. Dann die erforderlichen Berechtigungen für die neue Benutzergruppe entweder global oder pro Kategorie/Beitrag ändern.
*** Beim Erstellen einer Benutzergruppe ist es ratsam, eine übergeordnete Gruppe zu wählen, die über weniger Berechtigungen verfügt, als für die neue Gruppe erforderlich. Denn es ist einfacher, die Berechtigungen für jede Komponente/Kategorie/Beitrag zu erweitern, für die zusätzliche Berechtigungen nötig sind, als Berechtigungen aus den anderen Komponenten/Kategorien/Beiträgen zu entfernen.
****''(Beispiel: Es gibt 10 Kategorien, man möchte aber nur für eine Erstellen-Berechtigungen. Würde man für diese Gruppe die Berechtigungen global auf Erstellen erlaubt setzen, müsste man für diese Kategorien die Erstellen-Berechtigung entfernen. Und man müsste für diese Gruppe die Erstellen-Berechtigung bei jeder neuen Kategorie, die man zu einem späteren Zeitpunkt hinzufügt, ebenfalls entfernen).''
** Eine Benutzergruppe erstellen, die eine der Standardbenutzergruppen als übergeordnete Gruppe hat, NUR, wenn keine von diesen über die exakten Berechtigungen verfügt, die man benötigt und sich für alle Kategorien wünscht.

Beachten, dass dieses Setup unabhängig vom Setup für die Anzeige ist. Allerdings muss eine Benutzergruppe den entsprechenden Zugriffsebenen zugewiesen werden, damit der Benutzer in dieser Gruppe jene Berechtigungen verwenden kann.

Möchte ein Benutzer eine bestimmte Aktion bei einem Komponenten-Eintrag durchführen (z. B. einen Beitrag bearbeiten), überprüft das System (nachdem es überprüft hat, welcher Gruppe der Benutzer angehört und auf welche er Zugriff hat) die Berechtigung für diese Kombination aus Benutzer, Eintrag und Aktion. Liegt eine Erlaubnis vor, kann der Benutzer fortfahren. Andernfalls ist die Aktion nicht zulässig.

Das restliche Tutorial befasst sich mit der Steuerung, was Benutzer tun können - welche Aktionsberechtigungen sie haben.

==Aktionen, Gruppen und Vererbung==

Andererseits geht es bei der ACL auch darum, Benutzern Berechtigungen zu erteilen, damit diese Aktionen an Objekten durchführen können.

{| class="wikitable"
!style="width:20%;"|
!3.x Serie
|-
!Gruppen und Aktionen
|Aktionen, welche pro Gruppe erlaubt sind, werden durch den Website Administrator festgelegt.
|-
!Umfang von Berechtigungen
|Berechtigungen können auf mehreren Ebenen in der Hierarchie festgelegt werden: Website, Komponente, Kategorie, Objekt.
|-
!Vererbung von Berechtigungen
|Berechtigungen können von übergeordneten Gruppen und übergeordneten Kategorien geerbt werden.
|}

===Wie die Berechtigungen funktionieren===

Es gibt vier mögliche Berechtigungen für Aktionen. Diese sind (kurz skizziert):

* '''Nicht gesetzt''': Fällt standardmäßig auf "Nicht erlaubt" zurück. Aber im Gegensatz zur Berechtigung "Verweigert" kann diese Berechtigung außer Kraft gesetzt werden, wenn eine untergeordnete Gruppe oder eine in der Berechtigungshierarchie untergeordnete Ebene auf "Erlaubt" gesetzt wird. Diese Berechtigung kann nur für globale Berechtigungen der Konfiguration gesetzt werden.
* '''Vererbt''': Erbt den Wert von einer übergeordneten Gruppe oder einer in der Berechtigungshierarchie höheren Ebene. Diese Berechtigung gilt für alle Ebenen mit Ausnahme der obersten Ebene der Konfiguration.
* '''Verweigert''': Verbietet diese Aktion für diese Ebene und Gruppe. '''WICHTIG:''' Dadurch wird diese Aktion auch für alle untergeordneten Gruppen und alle untergeordneten Ebenen in der Berechtigungshierarchie verboten. Wird "Erlaubt" in einer untergeordneten Gruppe oder einer tieferen Ebene gesetzt, hat das keinen Effekt. Die Aktion wird immer für alle Mitglieder einer untergeordneten Gruppe und für alle untergeordneten Ebenen in der Berechtigungshierarchie abgelehnt.
* '''Erlaubt ''': Genehmigt diese Aktion für diese Ebene und Gruppe und für tiefere Ebenen und Untergruppen. Dies hat keine Auswirkungen, wenn eine höhere Gruppe oder Ebene auf "Verweigert" oder "Erlaubt" eingestellt ist. Wenn eine höhere Gruppe oder ein höheres Ebene auf "Verweigert" gesetzt ist, wird diese Berechtigung immer abgelehnt. Wenn eine höhere Gruppe oder Ebene auf Erlaubt eingestellt ist, ist diese Berechtigung bereits erlaubt.

===Hierarchie der Berechtigungsebenen===

Berechtigungen für Aktionen können in Version 2.5+ auf bis zu vier Ebenen festgelegt werden, wie folgt:
# '''Konfiguration''': legt die Standardberechtigungen für jede Aktion und Gruppe fest.
# '''Komponenten-Optionen-> Berechtigungen''': kann die Standardberechtigungen für diese Komponente überschreiben (z. B. Beiträge, Menüs, Benutzer, Banner usw.).
# '''Kategorie''': kann die Standardberechtigungen für Objekte in einer oder mehreren Kategorien überschreiben. Gilt für alle Komponenten mit Kategorien, einschließlich Beiträge, Banner, Kontakte, Newsfeeds und Weblinks.
# '''Beitrag''': kann die Berechtigungen für einen bestimmten Artikel überschreiben. Diese Ebene gilt nur für Beiträge. Alle anderen Komponenten erlauben nur die ersten drei Ebenen.

====Konfiguration====
Diese erreicht man über System → Konfiguration → Berechtigungen. Die nun sichtbare Maske dient dazu, die Berechtigungen auf der obersten Ebene für jede Gruppe und jede Aktion festzulegen, wie auch in der folgenden Abbildung gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Die möglichen Werte sind Vererbt, Erlaubt oder Verweigert. Die Spalte 'Errechnete Einstellung' zeigt die aktuelle Einstellung an. Diese ist entweder Nicht erlaubt (Standard), Erlaubt oder Nicht erlaubt.

Man kann immer nur an einer Gruppe gleichzeitig arbeiten, indem man den Reiter für ebendiese Gruppe anklickt. Die Berechtigungen kann man über die Dropdownlisten unter Neue Einstellung wählen ändern.

Beachten Sie, dass die Spalte "Errechnete Einstellung" erst aktualisiert wird, wenn Sie auf die Schaltfläche "Speichern" in der Werkzeugleiste klicken.

Um zu überprüfen, ob die Einstellungen Ihren Wünschen entsprechen, klicken Sie auf die Schaltfläche Speichern und überprüfen anschließend die Spalte Errechnete Einstellung.

====Komponenten-Optionen->Berechtigungen====
Auf diese wird für jede Komponente durch Klicken auf das Symbol "Optionen" in der Werkzeugleiste zugegriffen. Dieser Bildschirm ist ähnlich wie der Bildschirm "Globale Konfiguration" oben links. Wenn Sie beispielsweise im Menü-Manager auf das Symbol in der Werkzeugleiste Optionen klicken, werden die folgenden Menüs angezeigt.
[[Image:Screenshot_menu_acl_J3_tutorial-en.jpg]]

Der Zugriff auf Optionen ist nur für Mitglieder von Gruppen möglich, die die Berechtigung für die Aktion Konfiguration in für jede Komponente haben. Im obigen Beispiel hat die Gruppe Administrator die Berechtigung Erlaubt für die Option Konfigurieren, so dass Mitglieder dieser Gruppe auf diesen Bildschirm zugreifen können.

===Kategorie===
Auf die Kategorieberechtigungen wird im Category Manager zugegriffen: Bildschirm Kategorie bearbeiten, in einer Registerkarte oben auf dem Bildschirm. Dieser Bildschirm hat fünf Berechtigungen, wie folgt:

[[Image:Screenshot_category_acl_j3_tutorial-en.png]]

In diesen Bildern bearbeiten Sie die Berechtigungen für jeweils eine Benutzergruppe. Im obigen Beispiel bearbeiten Sie die Berechtigungen für die Gruppe Administrator.

Achten Sie darauf, dass die Aktionen "Konfigurieren und Zugriffssteuerung" nicht auf der Kategorieebene angewendet werden, so dass diese Aktionen nicht enthalten sind.

Beachten Sie auch, dass Kategorien in einer Hierarchie angeordnet werden können. Wenn ja, dann werden Aktionsberechtigungen in einer übergeordneten Kategorie automatisch an eine untergeordnete Kategorie vererbt. Wenn Sie beispielsweise eine Kategoriehierarchie von Tieren → Haustiere → Hunde hätten, dann würde die vollständige Berechtigungshierarchie für einen Artikel in der Kategorie Hunde wie folgt aussehen:
* Globale Konfiguration
* Artikel-Manager → Optionen → Genehmigung → Erlaubnis
* Tierkategorie
* Kategorie Haustiere
* Kategorie Hunde
* spezifischer Artikel

====Beitrag====
Berechtigungen für einzelne Beiträge findet man im "Beitrag" unter dem Tab-Reiter "Berechigungen". Dieser Bildschirm hat drei Aktionen, wie unten gezeigt.

[[Image:j3x_acl_tutorial_article_manager_article_permissions-en.png]]

Auch hier bearbeiten Sie jede Gruppe für sich. Um auf die Berechtigungen zuzugreifen wechseln Sie im Artikel auf den Reiter "Berechtigungen" im oberen Reiter. Über das Drop Down Menü wählen Sie die neue Berechtigung im Anschluss speichern Sie den Beitrag ab.

Beachten Sie, dass die Aktionen Configure, Access Component und Create auf Artikelebene nicht gelten, so dass diese Aktionen nicht berücksichtigt werden. Die Berechtigung zum Anlegen eines Artikels wird auf einer der höheren Ebenen der Hierarchie festgelegt.

===Zugriffsebenen===

Die Zugriffsebenen der 3.x-Serie sind einfach und flexibel. Der folgende Bildschirm zeigt die spezielle Zugriffsebene.
[[Image:j3x_acl_tutorial_viewing_levels-en.png|center]]
Aktivieren Sie einfach das Kontrollkästchen für jede Gruppe, die Sie in diesem Level aufnehmen wollen. Die spezielle Zugriffsebene umfasst die Gruppen Manager, Autor und Superuser. Es beinhaltet auch untergeordnete Gruppen dieser Gruppen. Die Gruppe Administrator ist also enthalten, da es sich um eine Untergruppe der Gruppe Manager handelt. Die Gruppen Editor, Publisher und Shop Suppliers sind enthalten, da es sich um Untergruppen des Autors handelt.

Jedem Objekt im Frontend ist eine Zugriffsebene zugeordnet. Wenn die Ebene öffentlich ist, kann jeder auf dieses Objekt zugreifen. Andernfalls dürfen nur Mitglieder von Gruppen, die dieser Zugriffsebene zugeordnet sind, auf dieses Objekt zugreifen.

Die Zugriffsebenen sind den Menüpunkten und den Modulen zugeordnet. Jede kann nur einer Zugriffsebene zugeordnet werden.

Der folgende Bildschirm zeigt beispielsweise den Bildschirm Menüpunkt bearbeiten mit der Liste der verfügbaren Zugriffsebenen....

[[Image:j3x_acl_tutorial_edit_menu_item_level_dropdown-en.png|center]]

==Standard-ACL-Setup==

Wenn Joomla! installiert ist, werden diese auf die ursprünglichen Standardwerte gesetzt. Wir werden diese Grundeinstellungen besprechen, um die Arbeitsweise der ACL zu verstehen.

===Standardgruppen===

Mit der Version 3.x können Sie Ihre individuellen Gruppen definieren. Wenn Sie die Version 3.x installieren, enthält sie eine Reihe von Standardgruppen, die im Folgenden dargestellt werden, sind die grundlegenden Standardbenutzergruppen. (Zusätzliche Standardbenutzergruppen werden mit Beispieldaten installiert)

[[Image:Screenshot_usergroupsl_acl_J3_tutorial-en.png|center]]

Die Pfeile zeigen die untergeordneten Elternbeziehungen an. Wie vorstehend besprochen, wird diese Berechtigung, wenn Sie eine Berechtigung für eine übergeordnete Gruppe festlegen, automatisch an alle Untergruppen vererbt. Die vererbten und zulässigen Berechtigungen können für eine Untergruppe überschrieben werden. Die Berechtigung Verweigert kann nicht überschrieben werden und verweigert immer eine Aktion für alle Untergruppen.

===Konfiguration===

Joomla! Version 3.x wird mit den gleichen bekannten Backend-Rechten wie die Version 1.5 (EOL) installiert. Mit der Version 3.x können Sie diese jedoch leicht an die Bedürfnisse Ihrer Website anpassen.

Wie bereits besprochen, werden die Berechtigungen für jede Aktion von der obigen Ebene in der Berechtigungshierarchie und von der übergeordneten Gruppe einer Gruppe übernommen. Also, wie funktioniert das? Die oberste Ebene dafür ist der gesamte Standort. Dies wird in der Site->Globale Konfiguration->Berechtigungen eingerichtet, wie unten gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Das erste, was man bemerken sollte, sind die zehn Aktionen: Standortlogin, Admin-Login, Offline-Zugriff, Superuser, Access Administration Interface, Erstellen, Löschen, Bearbeiten, Status bearbeiten und Eigenes bearbeiten. Dies sind die Aktionen, die ein Benutzer an einem Objekt in Joomla durchführen kann. Die spezifische Bedeutung jeder Aktion hängt vom Kontext ab. Für das Bild Globale Konfiguration sind sie wie folgt definiert:

Site Login : Login to the front end of the site

;Admin Login : Melden Sie sich am Backend der Website an.

Offline-Zugriff: Melden Sie sich am Frontend der Website an, wenn die Website offline ist (wenn die globale Konfigurationseinstellung "Site Offline" auf Ja gesetzt ist).

Superuser: Gewährt dem Benutzer den Status "Superuser". Benutzer mit dieser Berechtigung dürfen alles auf der Website machen. Nur Benutzer mit dieser Berechtigung können die Einstellungen der globalen Konfiguration ändern. Diese Berechtigungen können nicht eingeschränkt werden. Es ist wichtig zu verstehen, dass, wenn ein Benutzer Mitglied einer Super Admin-Gruppe ist, alle anderen Berechtigungen, die diesem Benutzer zugewiesen sind, irrelevant sind. Der Benutzer kann jede Aktion auf der Website durchführen. Es können jedoch weiterhin Zugriffsebenen zugewiesen werden, um zu steuern, was diese Gruppe auf der Website sieht. (Natürlich kann ein Super-Admin-Benutzer die Zugriffsebenen ändern, wenn er möchte, so dass die Zugriffsebenen nicht vollständig einschränken, was ein Super-Admin-Benutzer sehen kann.)

Zugangskomponente: Öffnen Sie die Bildschirme der Komponentenverwaltung (Benutzerverwaltung, Menüverwaltung, Artikelverwaltung usw.).

;Create : Create new objects (for example, users, menu items, articles, weblinks, and so on)

;Löschen : Löschen eines existienden Objekts

;Ändern : Ändern eines existierenden Objektes

;Ändern eines Objekt Status (Veröffentlicht, nicht Veröffentlicht, Archiviert und Gelöscht)

Eigene Objekte bearbeiten: Bearbeiten Sie Objekte, die Sie erstellt haben.

Each Group for the site has its own slider which is opened by clicking on the group name. In this case (with the sample data installed), we have the standard 7 groups that we had in version 1.5 plus two additional groups called "Shop Suppliers" and "Customer Group". Notice that our groups are set up with the same permissions as they had in version 1.5. Keep in mind that we can change any of these permissions to make the security work the way we want. Let's go through this to see how it works.

* '''Public''' has everything set to "Not set", as shown below.{{-}}[[Image:Screenshot_global_acl_public_J3_tutorial-en.png]]
**This can be a bit confusing. Basically, "Not Set" is the same as "Inherited". Because Public is our top-level group, and because Global Configuration is the top level of the component hierarchy, there is nothing to inherit from. So "Not Set" is used instead of "Inherit".
**The default in this case is for no permissions. So, as you would expect, the Public group has no special permissions. Also, it is important to note that, since nothing is set to Denied, all of these permissions may be overridden by child groups or by lower levels in the permission hierarchy.

* '''Guest''' is a 'child' group of the Public group has everything set to 'Inherited' {{-}}[[Image:Screenshot_global_acl_guest_J3_tutorial-de.png]]
** This is the default 'Guest User Group' in the User Manager options and the Group that (non logged in) visitors to your site are placed in.

* '''Manager''' is a "child" group of the Public group. It has Allowed permissions for everything except Access Component and Super Admin. So a member of this group can do everything in the front and back end of the site except change Global Permissions and Component Options. {{-}}[[Image:Screenshot_global_acl_manager_J3_tutorial-en.png]]

* '''Administrator''' group members inherit all of the Manager permissions and also have Allowed for Access Component. So members of this group by default can access the Options screens for each component. {{-}}[[Image:Screenshot_global_acl_administrator_J3_tutorial-en.png]]

* '''Registered''' is the same a Public except for the Allow permission for the Site Login action. This means that members of the Registered group can login to the site. Since default permissions are inherited, this means that, unless a child group overrides this permission, all child groups of the Registered group will be able to login as well. {{-}}[[Image:Screenshot_global_acl_registered_J3_tutorial-en.png]]

* '''Author''' is a child of the Registered group and inherits its permissions and also adds Create and Edit Own. Since Author, Editor, and Publisher have no back-end permissions, we will discuss them below, when we discuss front-end permissions.{{-}}[[Image:Screenshot_global_acl_author_J3_tutorial-en.png]]

* '''Editor''' is a child of the Authors group and adds the Edit permission. {{-}}[[Image:Screenshot_global_acl_editor_J3_tutorial-en.png]]

* '''Publisher''' is a child of Editor and adds the Edit State permission.{{-}}[[Image:Screenshot_global_acl_publisher_J3_tutorial-en.png]]

* '''Shop Suppliers''' is an example group that is installed if you install the sample data. It is a child group of Author.

* '''Customer Group''' is an example group that is installed if you install the sample data. It is a child group of Registered.

* '''Super Users''' group has the Allow permission for the Super Admin action. Because of this, members of this group have super user permissions throughout the site. They are the only users who can access and edit values on the Global Configuration screen. Users with permission for the Super Admin action have some special characteristics:
:* If a user has Super Admin permissions, no other permissions for this user matter. The user can perform any action on the site.
:* Only Super Admin users can create, edit, or delete other Super Admin users or groups.

There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.

This provides a lot of flexibility. For example, if you wanted Shop Suppliers to be able to have the ability to login to the back end, you could just change their Admin Login value to "Allowed". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherited (or Denied).

It is also important to understand that the ability to have child groups is completely optional. It allows you to save some time when setting up new groups. However, if you like, you can set up all groups to have Public as the parent and not inherit any permissions from a parent group.

===Komponenten-Optionen & Berechtigungen===

Now, let's continue to see how the default back-end permissions for version 2.5 mimic the permissions for version 1.5. The Super Users group in 2.5 is equivalent to the Super Administrator group in 1.5.

Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 2.5 configuration. Let's see how this is accomplished.

If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:

[[Image:screenshot_acl_tutorial_20110111-09-en.png|center|]]
[[Image:screenshot_acl_tutorial_20110111-10-de.png|center|]]

This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.

First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.

Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.

If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.

In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.

It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.

===Frontend Berechtigungen===

Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions. First, let's look at the permissions for Manager, as shown below.
[[Image:screenshot_acl_tutorial_20110111-11a-de.png|center|frame]]
Manager has allowed permission for all actions except Configure. So members of the Manager group can do everything with Articles except open the Options screen.

Now let's look at Administrator, as shown below.
[[Image:screenshot_acl_tutorial_20110111-12a-de.png|center|frame]]
Administrator has Allowed for Configure, so Administrators can edit this Options screen.

Both groups can create, delete, edit, and change the state of articles.

Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set.

Authors only have Create and Edit Own permissions, as shown below.
[[Image:screenshot_acl_tutorial_20110112-07-de.png|center|frame]]
This means that Authors can create articles and can edit articles they have created. They may not delete articles, change the published state of articles, or edit articles created by others.

Editors have the same permissions as Authors with the addition of permission for the Edit action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-08-de.png|center|frame]]
So Editors can edit articles written by anyone.

Publishers can do everything Editors can do plus they have permission for the Edit State action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-09-de.png|center|frame]]
So Publishers can change the published state of an article. The possible states include Published, Unpublished, Archived, and Trashed.

All of these groups have Inherit permission for Configure and Access Component. Remember that Author is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Configure and Access Component, and since Author's permission for these actions is "Inherited", then Author does not have these permissions either. This same permission is passed from Author to Editor and from Editor to Publisher. So, by default, none of these groups are allowed to work with articles in the back end.

It is important to remember that these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.

Beachte auch das in den ursprünglichen Standardwerten keine Berechtigungen auf Verweigert eingestellt sind. Dies ermöglicht in allen Berechtigungsebenen die jeweilige Berechtigung auf Erlaubt einzustellen. Bedenke, wenn eine Aktion auf Verweigert eingestellt ist, das diese Aktion auch in allen untergeordneten Ebenen in der Berechtigungshierarchie verweigert wird. Zum Beispiel, wenn die Seitenameldung für Registered auf Verweigert (anstatt auf Erlaubt) eingestellt wird, kann man Publishers diese Aktion per Berechtigungeinstellung nicht erteilen.

=== Beitrags-Manager & Aktions-Diagramm ===

The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.

[[Image:screenshot_acl_tutorial_20110111-16-de.png|center|]]

* '''Configure''' allows you to view and change the Options for the component.
* '''Access Component''' allows you to navigate to the Article Manager. Without this permission, no other actions are possible.
* '''Create''' allows you to add new articles.
* '''Delete''' allows you to delete trashed articles. Note that the Delete icon only shows in the toolbar when you have the "Select State" filter set to "Trash".
* '''Edit''' allows you to edit existing articles.
* '''Edit State''' allows to you Publish, Unpublish, Archive, or Trash articles.
* '''Edit Own''' is the same as Edit except that it only applies to articles written by you.

==Allowing Guest-Only Access to Menu Items and Modules==

Version 1.6 introduced the ability to create a View Access Level that is only for guests of the site (meaning a user who is not logged in). The example below shows how you can set up this new feature.
''(N.B. Steps 1 to 3 are not needed for Joomla! 3.x as they exist in the default install)''

#Create a new user group called Guest. Make it a child of the Public group as shown below. [[Image:screenshot_acl_tutorial_20110112-01-de.png|center|frame]]
# Create a new access level called Guest and grant only the Guest group access to this level, as shown below.[[Image:screenshot_acl_tutorial_20110112-02-de.png|center|frame]]
# Navigate to User Manager→Options→Component and change the Guest User Group from the default value of "Public" to "Guest", as shown below.
[[Image:screenshot_acl_tutorial_20110112-04-de.png|center|frame]]
Now, if we assign a menu item, module, or other object to the Guest access level, only non-logged in users will have access. For example, if we create a new menu item with access level of Guest, as shown below,
[[Image:screenshot_acl_tutorial_20110112-05-de.png|center|frame]]
this menu item will only be visible to non-logged-in visitors to the site.

If required other user groups like Author can be granted access in the Guest access level, this would allow Authors to view articles in the front end for editing.

'''N.B. Login/logout in front end (''for changing data in session'') to see the change.'''

==Berechtigungen und Gruppenebenen gemeinsam nutzen==

As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.

This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:

* both groups can create new articles only in the History Assignments category.

* only History Teachers (not Assistant History Teachers) can Publish or otherwise have Edit State permission.

This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.

[[Image:Acl example diagram1 20091018-de.png|center|]]

In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.

To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.

Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.

[[Image:Acl example diagram2 20091018-de.png|center|]]

This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.

Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.

==ACL Aktion Berechtigungs-Beispiele==

===Backend Beitrag Administrator===

'''Problem:'''

We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.

'''Lösung:'''

# Create a new group called Article Administrator and make its parent group Public, as shown below.[[Image:screenshot_acl_tutorial_20110112-10-de.png|center|frame]] Because its parent group is Public, it won't have any permissions by default.
# In Users → Access Levels, edit the Special Access level to add the new group. That way they can get access to the back end menu items and modules (This assumes that the modules for the admin menu and quickicons have the Special Access level assigned to them, which is the default.) [[Image:screenshot_acl_tutorial_20110112-11-de.png|center|frame]] By default, the back-end menu items and modules are set to Special access, so if you forget to add the new group to the Special access level, you won't see any modules or menu items when you log in as a user of the new group.
# In Site → Global Configuration → Permissions, click on the Article Administrator group and change the permissions to Allowed for the following actions: Admin Login, Create, Delete, Edit, Edit State, and Edit Own. The screen below shows what will show before you press Save. [[Image:screenshot_acl_tutorial_20110112-12-de.png|center|frame]]After you save, the Calculated Permissions should show as shown below.[[Image:screenshot_acl_tutorial_20110112-13-de.png|center|frame]]Note that the permission for the Access Component is Inherited, which translates to Not Allowed. This is important. This means that this group will only be able to access components if we give the group "Allowed" permission for Access Component. So we only have to change the one component we want to give them access to and don't have to change any settings for the components where we don't want them to have access. If we had a case where we wanted to give a group access to everything except for one component, we could set the default to Allowed and then set the one component to Denied. Also note that we did not give the group Site Login permission, so users in this group will not be able to log into the front end. (If we wanted to allow that, we would just change the permission to Allowed for Site Login.)
# In Article Manager → Options → Permissions, change permissions to Allowed for this group for the Access Component action, as shown below.[[Image:screenshot_acl_tutorial_20110112-14-de.png|center|frame]]All of the other desired permissions are inherited.

That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end. For example, the screen below shows what a user in the Article Manager will see when they login to the back end.[[Image:screenshot_acl_tutorial_20110112-15-de.png|center|frame]]

==ACL Ansicht Zugriffsebenen-Beispiele==

A basic concept of using Access Levels is that all items with the same Access will be viewable by the same group of users. In other words, if two items have the same Access, you can't have one viewable by one user and not viewable by another user. On the other hand, it is easy to have one Group view any number of items with different Access levels.

Similarly, each Group has exactly the same combination of Access levels, but one User can be a member of more than one group. Depending on the situation, you may want to have users only in one Group or you may need to have a User in more than one Group.

This means that we may need to group our items so that items so that all items in a group have the same level of sensitivity. Here are some examples.

===Hierarchisches Beispiel===
In this example, Access levels are hierarchical, for example, like government security clearance codes. Say for example we have the following sets of classified documents: Classified, Secret, and Top Secret. Users have corresponding clearence codes. Users with Classified clearance can only see Classified documents and cannot see Secret or Top Secret. Users with Secret clearance can see Classified and Secret documents but not Top Secret. Users with Top Secret can see all documents.

In this case, you would create three Access levels: Classified, Secret, and Top Secret and the same three Groups. Users would only be members of one group, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| C1, C2, C3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Classified
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| S1, S2, S3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| TS1, TS2, TS3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Top Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret, Top Secret

|}

In this case, all users are in exactly one group, but some groups have access to more than one Access Level of items. In other words, we have a one-to-one relationship between users and groups, but a one-to-many relationship between Groups and Access Levels.

===Teamsicherheit Beispiel===

Another possible use case is a set of non-hierarchical teams. Let's say we have three teams, T1, T2, and T3. Some users are only on one team, but others might be on two or more teams. In this case, we could set up our Access Levels and Groups by team. Documents for each team have the access level for that team, and the Group for the team has only the one access level. When a User is on more than one team, they get added to the group for each team, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Beschreibung
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 1 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 2 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 3 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1, 2 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1,T2, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2, T3

|}

===Hybrid Example===

In a real-world situation, you might have a combination of these two arrangements. Say for example we have Managers and Staff. Staff can only see Staff documents and Managers can see Manager and Staff documents. Both types of users can be assigned to teams as well, in which case they can see all of the documents for that team. In addition, say that Managers can access some, but not all, team documents. Staff can only access team documents if they are members of that team.

In this example, we could set up the following Access Levels:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Access Level
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Description
| style="border:0.0007in solid #000000;padding:0.0382in;"| Groups

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team manager documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team staff documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team1 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1, Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team2 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2, Manager

|}

Then, users could be assigned to groups as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| User Type
| style="border:0.0007in solid #000000;padding:0.0382in;"| Group

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1, Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1, Team2

|}

<noinclude>
[[Category:Joomla! 1.6]]
[[Category:Joomla! 2.5]]
[[Category:Joomla! 3.x/de]]
[[Category:Tutorials/de]]
[[Category:Access Control/de]]
[[Category:Access Management]]
</noinclude>

Translations:J3.x:Access Control List Tutorial/125/de

2019-12-26T19:00:57Z

Sieger66:

J3.x:Access Control List Tutorial/de

2019-12-26T19:00:44Z

Sieger66:

<noinclude><languages /></noinclude>
{{Joomla version|version=3.x|comment=Serie}}
{{-}}
{{:J3.1:Access_Control_List/en}}

==Separate ACL für Anzeige und Aktionen==

Das Joomla ACL-System besteht genau genommen aus zwei völlig getrennten Systemen. Das eine System steuert, was Benutzer auf der Website "sehen" können. Das andere steuert, was Benutzer "tun" können (welche Aktionen ein Benutzer durchführen kann). Die ACL wird für jedes dieser Systeme anders eingerichtet.

===Steuern, was Benutzer sehen können===

Das Setup zum Steuern, was Benutzer sehen können, sieht wie folgt aus:
*Eine Reihe von Zugriffsebenen gemäß den Kategorien und/oder der Kombination von Kategorien erstellen, die nur angemeldete Benutzer sehen sollen. Anmerkung: Zu diesem Zeitpunkt werden noch keine Benutzergruppen den neuen Zugriffsebenen zugewiesen.

*Für jede Zugriffsebene eine Benutzergruppe erstellen, die 'Registriert' als übergeordnete Gruppe hat. Indem man für Benutzergruppen und Zugriffsebenen die gleichen Namen verwendet, kann man Verwirrungen zu einem späteren Zeitpunkt vorbeugen.

*Die neuen Zugriffsebenen bearbeiten und jeder die (neue) Benutzergruppe zuweisen. Wahrscheinlich möchten man auch die 'Super Benutzer' Gruppe (und/oder die anderen Standard-Benutzergruppen mit Ausnahme der Benutzergruppe 'Gast') den neuen Zugriffsebenen zuweisen.

*Jedem anzuzeigenden Eintrag eine Zugriffsebene zuweisen. Einträge sind sowohl inhaltliche Einträge (Beiträge, Kontakte, usw.), Menüeinträge als auch Module.

Immer dann, wenn ein Benutzer im Begriff ist, einen Eintrag auf einer Joomla-Seite anzeigen zu lassen, prüft das Programm, ob dieser Benutzer auch Zugriff auf den Eintrag hat. Das geschieht folgendermaßen:
# Zunächst wird eine Liste aller Zugriffsebenen erstellt, auf die der Benutzer zugreifen kann, basierend auf allen Gruppen, denen der Benutzer angehört. Sofern eine Gruppe eine übergeordnete Gruppe besitzt, sind die Zugriffsebenen für die übergeordnete Gruppe ebenfalls in der Liste enthalten.
# Danach wird überprüft, ob die Zugriffsebene für den Eintrag (Beitrag, Modul, Menüeintrag, usw.) in dieser Liste enthalten ist. Wenn dem so ist, wird der Eintrag dem Benutzer angezeigt. Falls der Benutzer die benötigten Zugriffsrechte besitzt, wird ihm der Zugriff verweigert.

Beachten, dass Zugriffsebenen für jede Gruppe separat festgelegt und nicht von der übergeordneten Gruppe einer Gruppe vererbt werden.

===Steuern, was Benutzer tun können===

Das System, das steuert, was Benutzer in einer Benutzergruppe tun können - welche Aktionen sie bei einem bestimmten Eintrag ausführen können - wird über den Tab 'Berechtigungen' in der Konfiguration und den Tab 'Berechtigungen' in den Optionen jeder einzelnen Komponente eingerichtet. Berechtigungen können auch auf Kategorienebene (bei Kernkomponenten) und auf Beitragsebene (bei Beiträgen) gesetzt werden.

* Wenn angemeldete Benutzer in bestimmten Kategorien Erstellen, Löschen, Status bearbeiten oder Eigene Inhalte bearbeiten dürfen, dann:
** Eine Benutzergruppe erstellen und als übergeordnete Gruppe eine der Benutzergruppen angeben, die Zugriff auf die Kategorie (oder Kategorien) haben, die diese neue Benutzergruppe ändern soll.
**Der neuen Benutzergruppe den entsprechenden Zugriffsebenen zuweisen. Dann die erforderlichen Berechtigungen für die neue Benutzergruppe entweder global oder pro Kategorie/Beitrag ändern.
*** Beim Erstellen einer Benutzergruppe ist es ratsam, eine übergeordnete Gruppe zu wählen, die über weniger Berechtigungen verfügt, als für die neue Gruppe erforderlich. Denn es ist einfacher, die Berechtigungen für jede Komponente/Kategorie/Beitrag zu erweitern, für die zusätzliche Berechtigungen nötig sind, als Berechtigungen aus den anderen Komponenten/Kategorien/Beiträgen zu entfernen.
****''(Beispiel: Es gibt 10 Kategorien, man möchte aber nur für eine Erstellen-Berechtigungen. Würde man für diese Gruppe die Berechtigungen global auf Erstellen erlaubt setzen, müsste man für diese Kategorien die Erstellen-Berechtigung entfernen. Und man müsste für diese Gruppe die Erstellen-Berechtigung bei jeder neuen Kategorie, die man zu einem späteren Zeitpunkt hinzufügt, ebenfalls entfernen).''
** Eine Benutzergruppe erstellen, die eine der Standardbenutzergruppen als übergeordnete Gruppe hat, NUR, wenn keine von diesen über die exakten Berechtigungen verfügt, die man benötigt und sich für alle Kategorien wünscht.

Beachten, dass dieses Setup unabhängig vom Setup für die Anzeige ist. Allerdings muss eine Benutzergruppe den entsprechenden Zugriffsebenen zugewiesen werden, damit der Benutzer in dieser Gruppe jene Berechtigungen verwenden kann.

Möchte ein Benutzer eine bestimmte Aktion bei einem Komponenten-Eintrag durchführen (z. B. einen Beitrag bearbeiten), überprüft das System (nachdem es überprüft hat, welcher Gruppe der Benutzer angehört und auf welche er Zugriff hat) die Berechtigung für diese Kombination aus Benutzer, Eintrag und Aktion. Liegt eine Erlaubnis vor, kann der Benutzer fortfahren. Andernfalls ist die Aktion nicht zulässig.

Das restliche Tutorial befasst sich mit der Steuerung, was Benutzer tun können - welche Aktionsberechtigungen sie haben.

==Aktionen, Gruppen und Vererbung==

Andererseits geht es bei der ACL auch darum, Benutzern Berechtigungen zu erteilen, damit diese Aktionen an Objekten durchführen können.

{| class="wikitable"
!style="width:20%;"|
!3.x Serie
|-
!Gruppen und Aktionen
|Aktionen, welche pro Gruppe erlaubt sind, werden durch den Website Administrator festgelegt.
|-
!Umfang von Berechtigungen
|Berechtigungen können auf mehreren Ebenen in der Hierarchie festgelegt werden: Website, Komponente, Kategorie, Objekt.
|-
!Vererbung von Berechtigungen
|Berechtigungen können von übergeordneten Gruppen und übergeordneten Kategorien geerbt werden.
|}

===Wie die Berechtigungen funktionieren===

Es gibt vier mögliche Berechtigungen für Aktionen. Diese sind (kurz skizziert):

* '''Nicht gesetzt''': Fällt standardmäßig auf "Nicht erlaubt" zurück. Aber im Gegensatz zur Berechtigung "Verweigert" kann diese Berechtigung außer Kraft gesetzt werden, wenn eine untergeordnete Gruppe oder eine in der Berechtigungshierarchie untergeordnete Ebene auf "Erlaubt" gesetzt wird. Diese Berechtigung kann nur für globale Berechtigungen der Konfiguration gesetzt werden.
* '''Vererbt''': Erbt den Wert von einer übergeordneten Gruppe oder einer in der Berechtigungshierarchie höheren Ebene. Diese Berechtigung gilt für alle Ebenen mit Ausnahme der obersten Ebene der Konfiguration.
* '''Verweigert''': Verbietet diese Aktion für diese Ebene und Gruppe. '''WICHTIG:''' Dadurch wird diese Aktion auch für alle untergeordneten Gruppen und alle untergeordneten Ebenen in der Berechtigungshierarchie verboten. Wird "Erlaubt" in einer untergeordneten Gruppe oder einer tieferen Ebene gesetzt, hat das keinen Effekt. Die Aktion wird immer für alle Mitglieder einer untergeordneten Gruppe und für alle untergeordneten Ebenen in der Berechtigungshierarchie abgelehnt.
* '''Erlaubt ''': Genehmigt diese Aktion für diese Ebene und Gruppe und für tiefere Ebenen und Untergruppen. Dies hat keine Auswirkungen, wenn eine höhere Gruppe oder Ebene auf "Verweigert" oder "Erlaubt" eingestellt ist. Wenn eine höhere Gruppe oder ein höheres Ebene auf "Verweigert" gesetzt ist, wird diese Berechtigung immer abgelehnt. Wenn eine höhere Gruppe oder Ebene auf Erlaubt eingestellt ist, ist diese Berechtigung bereits erlaubt.

===Hierarchie der Berechtigungsebenen===

Berechtigungen für Aktionen können in Version 2.5+ auf bis zu vier Ebenen festgelegt werden, wie folgt:
# '''Konfiguration''': legt die Standardberechtigungen für jede Aktion und Gruppe fest.
# '''Komponenten-Optionen-> Berechtigungen''': kann die Standardberechtigungen für diese Komponente überschreiben (z. B. Beiträge, Menüs, Benutzer, Banner usw.).
# '''Kategorie''': kann die Standardberechtigungen für Objekte in einer oder mehreren Kategorien überschreiben. Gilt für alle Komponenten mit Kategorien, einschließlich Beiträge, Banner, Kontakte, Newsfeeds und Weblinks.
# '''Beitrag''': kann die Berechtigungen für einen bestimmten Artikel überschreiben. Diese Ebene gilt nur für Beiträge. Alle anderen Komponenten erlauben nur die ersten drei Ebenen.

====Konfiguration====
Diese erreicht man über System → Konfiguration → Berechtigungen. Die nun sichtbare Maske dient dazu, die Berechtigungen auf der obersten Ebene für jede Gruppe und jede Aktion festzulegen, wie auch in der folgenden Abbildung gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Die möglichen Werte sind Vererbt, Erlaubt oder Verweigert. Die Spalte 'Errechnete Einstellung' zeigt die aktuelle Einstellung an. Diese ist entweder Nicht erlaubt (Standard), Erlaubt oder Nicht erlaubt.

Man kann immer nur an einer Gruppe gleichzeitig arbeiten, indem man den Reiter für ebendiese Gruppe anklickt. Die Berechtigungen kann man über die Dropdownlisten unter Neue Einstellung wählen ändern.

Beachten Sie, dass die Spalte "Errechnete Einstellung" erst aktualisiert wird, wenn Sie auf die Schaltfläche "Speichern" in der Werkzeugleiste klicken.

Um zu überprüfen, ob die Einstellungen Ihren Wünschen entsprechen, klicken Sie auf die Schaltfläche Speichern und überprüfen anschließend die Spalte Errechnete Einstellung.

====Komponenten-Optionen->Berechtigungen====
Auf diese wird für jede Komponente durch Klicken auf das Symbol "Optionen" in der Werkzeugleiste zugegriffen. Dieser Bildschirm ist ähnlich wie der Bildschirm "Globale Konfiguration" oben links. Wenn Sie beispielsweise im Menü-Manager auf das Symbol in der Werkzeugleiste Optionen klicken, werden die folgenden Menüs angezeigt.
[[Image:Screenshot_menu_acl_J3_tutorial-en.jpg]]

Der Zugriff auf Optionen ist nur für Mitglieder von Gruppen möglich, die die Berechtigung für die Aktion Konfiguration in für jede Komponente haben. Im obigen Beispiel hat die Gruppe Administrator die Berechtigung Erlaubt für die Option Konfigurieren, so dass Mitglieder dieser Gruppe auf diesen Bildschirm zugreifen können.

===Kategorie===
Auf die Kategorieberechtigungen wird im Category Manager zugegriffen: Bildschirm Kategorie bearbeiten, in einer Registerkarte oben auf dem Bildschirm. Dieser Bildschirm hat fünf Berechtigungen, wie folgt:

[[Image:Screenshot_category_acl_j3_tutorial-en.png]]

In diesen Bildern bearbeiten Sie die Berechtigungen für jeweils eine Benutzergruppe. Im obigen Beispiel bearbeiten Sie die Berechtigungen für die Gruppe Administrator.

Achten Sie darauf, dass die Aktionen "Konfigurieren und Zugriffssteuerung" nicht auf der Kategorieebene angewendet werden, so dass diese Aktionen nicht enthalten sind.

Beachten Sie auch, dass Kategorien in einer Hierarchie angeordnet werden können. Wenn ja, dann werden Aktionsberechtigungen in einer übergeordneten Kategorie automatisch an eine untergeordnete Kategorie vererbt. Wenn Sie beispielsweise eine Kategoriehierarchie von Tieren → Haustiere → Hunde hätten, dann würde die vollständige Berechtigungshierarchie für einen Artikel in der Kategorie Hunde wie folgt aussehen:
* Globale Konfiguration
* Artikel-Manager → Optionen → Genehmigung → Erlaubnis
* Tierkategorie
* Kategorie Haustiere
* Kategorie Hunde
* spezifischer Artikel

====Beitrag====
Berechtigungen für einzelne Beiträge findet man im "Beitrag" unter dem Tab-Reiter "Berechigungen". Dieser Bildschirm hat drei Aktionen, wie unten gezeigt.

[[Image:j3x_acl_tutorial_article_manager_article_permissions-en.png]]

Auch hier bearbeiten Sie jede Gruppe für sich. Um auf die Berechtigungen zuzugreifen wechseln Sie im Artikel auf den Reiter "Berechtigungen" im oberen Reiter. Über das Drop Down Menü wählen Sie die neue Berechtigung im Anschluss speichern Sie den Beitrag ab.

Beachten Sie, dass die Aktionen Configure, Access Component und Create auf Artikelebene nicht gelten, so dass diese Aktionen nicht berücksichtigt werden. Die Berechtigung zum Anlegen eines Artikels wird auf einer der höheren Ebenen der Hierarchie festgelegt.

===Zugriffsebenen===

Die Zugriffsebenen der 3.x-Serie sind einfach und flexibel. Der folgende Bildschirm zeigt die spezielle Zugriffsebene.
[[Image:j3x_acl_tutorial_viewing_levels-en.png|center]]
Aktivieren Sie einfach das Kontrollkästchen für jede Gruppe, die Sie in diesem Level aufnehmen wollen. Die spezielle Zugriffsebene umfasst die Gruppen Manager, Autor und Superuser. Es beinhaltet auch untergeordnete Gruppen dieser Gruppen. Die Gruppe Administrator ist also enthalten, da es sich um eine Untergruppe der Gruppe Manager handelt. Die Gruppen Editor, Publisher und Shop Suppliers sind enthalten, da es sich um Untergruppen des Autors handelt.

Jedem Objekt im Frontend ist eine Zugriffsebene zugeordnet. Wenn die Ebene öffentlich ist, kann jeder auf dieses Objekt zugreifen. Andernfalls dürfen nur Mitglieder von Gruppen, die dieser Zugriffsebene zugeordnet sind, auf dieses Objekt zugreifen.

Die Zugriffsebenen sind den Menüpunkten und den Modulen zugeordnet. Jede kann nur einer Zugriffsebene zugeordnet werden.

Der folgende Bildschirm zeigt beispielsweise den Bildschirm Menüpunkt bearbeiten mit der Liste der verfügbaren Zugriffsebenen....

[[Image:j3x_acl_tutorial_edit_menu_item_level_dropdown-en.png|center]]

==Standard-ACL-Setup==

Wenn Joomla! installiert ist, werden diese auf die ursprünglichen Standardwerte gesetzt. Wir werden diese Grundeinstellungen besprechen, um die Arbeitsweise der ACL zu verstehen.

===Standardgruppen===

Mit der Version 3.x können Sie Ihre individuellen Gruppen definieren. Wenn Sie die Version 3.x installieren, enthält sie eine Reihe von Standardgruppen, die im Folgenden dargestellt werden, sind die grundlegenden Standardbenutzergruppen. (Zusätzliche Standardbenutzergruppen werden mit Beispieldaten installiert)

[[Image:Screenshot_usergroupsl_acl_J3_tutorial-en.png|center]]

Die Pfeile zeigen die untergeordneten Elternbeziehungen an. Wie vorstehend besprochen, wird diese Berechtigung, wenn Sie eine Berechtigung für eine übergeordnete Gruppe festlegen, automatisch an alle Untergruppen vererbt. Die vererbten und zulässigen Berechtigungen können für eine Untergruppe überschrieben werden. Die Berechtigung Verweigert kann nicht überschrieben werden und verweigert immer eine Aktion für alle Untergruppen.

===Konfiguration===

Joomla! Version 3.x wird mit den gleichen bekannten Backend-Rechten wie die Version 1.5 (EOL) installiert. Mit der Version 3.x können Sie diese jedoch leicht an die Bedürfnisse Ihrer Website anpassen.

Wie bereits besprochen, werden die Berechtigungen für jede Aktion von der obigen Ebene in der Berechtigungshierarchie und von der übergeordneten Gruppe einer Gruppe übernommen. Also, wie funktioniert das? Die oberste Ebene dafür ist der gesamte Standort. Dies wird in der Site->Globale Konfiguration->Berechtigungen eingerichtet, wie unten gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Das erste, was man bemerken sollte, sind die zehn Aktionen: Standortlogin, Admin-Login, Offline-Zugriff, Superuser, Access Administration Interface, Erstellen, Löschen, Bearbeiten, Status bearbeiten und Eigenes bearbeiten. Dies sind die Aktionen, die ein Benutzer an einem Objekt in Joomla durchführen kann. Die spezifische Bedeutung jeder Aktion hängt vom Kontext ab. Für das Bild Globale Konfiguration sind sie wie folgt definiert:

Site Login : Login to the front end of the site

;Admin Login : Melden Sie sich am Backend der Website an.

Offline-Zugriff: Melden Sie sich am Frontend der Website an, wenn die Website offline ist (wenn die globale Konfigurationseinstellung "Site Offline" auf Ja gesetzt ist).

Superuser: Gewährt dem Benutzer den Status "Superuser". Benutzer mit dieser Berechtigung dürfen alles auf der Website machen. Nur Benutzer mit dieser Berechtigung können die Einstellungen der globalen Konfiguration ändern. Diese Berechtigungen können nicht eingeschränkt werden. Es ist wichtig zu verstehen, dass, wenn ein Benutzer Mitglied einer Super Admin-Gruppe ist, alle anderen Berechtigungen, die diesem Benutzer zugewiesen sind, irrelevant sind. Der Benutzer kann jede Aktion auf der Website durchführen. Es können jedoch weiterhin Zugriffsebenen zugewiesen werden, um zu steuern, was diese Gruppe auf der Website sieht. (Natürlich kann ein Super-Admin-Benutzer die Zugriffsebenen ändern, wenn er möchte, so dass die Zugriffsebenen nicht vollständig einschränken, was ein Super-Admin-Benutzer sehen kann.)

Zugangskomponente: Öffnen Sie die Bildschirme der Komponentenverwaltung (Benutzerverwaltung, Menüverwaltung, Artikelverwaltung usw.).

;Create : Create new objects (for example, users, menu items, articles, weblinks, and so on)

;Löschen : Löschen eines existienden Objekts

;Ändern : Ändern eines existierenden Objektes

;Ändern eines Objekt Status (Veröffentlicht, nicht Veröffentlicht, Archiviert und Gelöscht)

Eigene Objekte bearbeiten: Bearbeiten Sie Objekte, die Sie erstellt haben.

Each Group for the site has its own slider which is opened by clicking on the group name. In this case (with the sample data installed), we have the standard 7 groups that we had in version 1.5 plus two additional groups called "Shop Suppliers" and "Customer Group". Notice that our groups are set up with the same permissions as they had in version 1.5. Keep in mind that we can change any of these permissions to make the security work the way we want. Let's go through this to see how it works.

* '''Public''' has everything set to "Not set", as shown below.{{-}}[[Image:Screenshot_global_acl_public_J3_tutorial-en.png]]
**This can be a bit confusing. Basically, "Not Set" is the same as "Inherited". Because Public is our top-level group, and because Global Configuration is the top level of the component hierarchy, there is nothing to inherit from. So "Not Set" is used instead of "Inherit".
**The default in this case is for no permissions. So, as you would expect, the Public group has no special permissions. Also, it is important to note that, since nothing is set to Denied, all of these permissions may be overridden by child groups or by lower levels in the permission hierarchy.

* '''Guest''' is a 'child' group of the Public group has everything set to 'Inherited' {{-}}[[Image:Screenshot_global_acl_guest_J3_tutorial-de.png]]
** This is the default 'Guest User Group' in the User Manager options and the Group that (non logged in) visitors to your site are placed in.

* '''Manager''' is a "child" group of the Public group. It has Allowed permissions for everything except Access Component and Super Admin. So a member of this group can do everything in the front and back end of the site except change Global Permissions and Component Options. {{-}}[[Image:Screenshot_global_acl_manager_J3_tutorial-en.png]]

* '''Administrator''' group members inherit all of the Manager permissions and also have Allowed for Access Component. So members of this group by default can access the Options screens for each component. {{-}}[[Image:Screenshot_global_acl_administrator_J3_tutorial-en.png]]

* '''Registered''' is the same a Public except for the Allow permission for the Site Login action. This means that members of the Registered group can login to the site. Since default permissions are inherited, this means that, unless a child group overrides this permission, all child groups of the Registered group will be able to login as well. {{-}}[[Image:Screenshot_global_acl_registered_J3_tutorial-en.png]]

* '''Author''' is a child of the Registered group and inherits its permissions and also adds Create and Edit Own. Since Author, Editor, and Publisher have no back-end permissions, we will discuss them below, when we discuss front-end permissions.{{-}}[[Image:Screenshot_global_acl_author_J3_tutorial-en.png]]

* '''Editor''' is a child of the Authors group and adds the Edit permission. {{-}}[[Image:Screenshot_global_acl_editor_J3_tutorial-en.png]]

* '''Publisher''' is a child of Editor and adds the Edit State permission.{{-}}[[Image:Screenshot_global_acl_publisher_J3_tutorial-en.png]]

* '''Shop Suppliers''' is an example group that is installed if you install the sample data. It is a child group of Author.

* '''Customer Group''' is an example group that is installed if you install the sample data. It is a child group of Registered.

* '''Super Users''' group has the Allow permission for the Super Admin action. Because of this, members of this group have super user permissions throughout the site. They are the only users who can access and edit values on the Global Configuration screen. Users with permission for the Super Admin action have some special characteristics:
:* If a user has Super Admin permissions, no other permissions for this user matter. The user can perform any action on the site.
:* Only Super Admin users can create, edit, or delete other Super Admin users or groups.

There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.

This provides a lot of flexibility. For example, if you wanted Shop Suppliers to be able to have the ability to login to the back end, you could just change their Admin Login value to "Allowed". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherited (or Denied).

It is also important to understand that the ability to have child groups is completely optional. It allows you to save some time when setting up new groups. However, if you like, you can set up all groups to have Public as the parent and not inherit any permissions from a parent group.

===Komponenten-Optionen & Berechtigungen===

Now, let's continue to see how the default back-end permissions for version 2.5 mimic the permissions for version 1.5. The Super Users group in 2.5 is equivalent to the Super Administrator group in 1.5.

Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 2.5 configuration. Let's see how this is accomplished.

If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:

[[Image:screenshot_acl_tutorial_20110111-09-de.png|center|]]
[[Image:screenshot_acl_tutorial_20110111-10-de.png|center|]]

This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.

First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.

Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.

If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.

In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.

It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.

===Frontend Berechtigungen===

Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions. First, let's look at the permissions for Manager, as shown below.
[[Image:screenshot_acl_tutorial_20110111-11a-de.png|center|frame]]
Manager has allowed permission for all actions except Configure. So members of the Manager group can do everything with Articles except open the Options screen.

Now let's look at Administrator, as shown below.
[[Image:screenshot_acl_tutorial_20110111-12a-de.png|center|frame]]
Administrator has Allowed for Configure, so Administrators can edit this Options screen.

Both groups can create, delete, edit, and change the state of articles.

Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set.

Authors only have Create and Edit Own permissions, as shown below.
[[Image:screenshot_acl_tutorial_20110112-07-de.png|center|frame]]
This means that Authors can create articles and can edit articles they have created. They may not delete articles, change the published state of articles, or edit articles created by others.

Editors have the same permissions as Authors with the addition of permission for the Edit action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-08-de.png|center|frame]]
So Editors can edit articles written by anyone.

Publishers can do everything Editors can do plus they have permission for the Edit State action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-09-de.png|center|frame]]
So Publishers can change the published state of an article. The possible states include Published, Unpublished, Archived, and Trashed.

All of these groups have Inherit permission for Configure and Access Component. Remember that Author is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Configure and Access Component, and since Author's permission for these actions is "Inherited", then Author does not have these permissions either. This same permission is passed from Author to Editor and from Editor to Publisher. So, by default, none of these groups are allowed to work with articles in the back end.

It is important to remember that these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.

Beachte auch das in den ursprünglichen Standardwerten keine Berechtigungen auf Verweigert eingestellt sind. Dies ermöglicht in allen Berechtigungsebenen die jeweilige Berechtigung auf Erlaubt einzustellen. Bedenke, wenn eine Aktion auf Verweigert eingestellt ist, das diese Aktion auch in allen untergeordneten Ebenen in der Berechtigungshierarchie verweigert wird. Zum Beispiel, wenn die Seitenameldung für Registered auf Verweigert (anstatt auf Erlaubt) eingestellt wird, kann man Publishers diese Aktion per Berechtigungeinstellung nicht erteilen.

=== Beitrags-Manager & Aktions-Diagramm ===

The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.

[[Image:screenshot_acl_tutorial_20110111-16-de.png|center|]]

* '''Configure''' allows you to view and change the Options for the component.
* '''Access Component''' allows you to navigate to the Article Manager. Without this permission, no other actions are possible.
* '''Create''' allows you to add new articles.
* '''Delete''' allows you to delete trashed articles. Note that the Delete icon only shows in the toolbar when you have the "Select State" filter set to "Trash".
* '''Edit''' allows you to edit existing articles.
* '''Edit State''' allows to you Publish, Unpublish, Archive, or Trash articles.
* '''Edit Own''' is the same as Edit except that it only applies to articles written by you.

==Allowing Guest-Only Access to Menu Items and Modules==

Version 1.6 introduced the ability to create a View Access Level that is only for guests of the site (meaning a user who is not logged in). The example below shows how you can set up this new feature.
''(N.B. Steps 1 to 3 are not needed for Joomla! 3.x as they exist in the default install)''

#Create a new user group called Guest. Make it a child of the Public group as shown below. [[Image:screenshot_acl_tutorial_20110112-01-de.png|center|frame]]
# Create a new access level called Guest and grant only the Guest group access to this level, as shown below.[[Image:screenshot_acl_tutorial_20110112-02-de.png|center|frame]]
# Navigate to User Manager→Options→Component and change the Guest User Group from the default value of "Public" to "Guest", as shown below.
[[Image:screenshot_acl_tutorial_20110112-04-de.png|center|frame]]
Now, if we assign a menu item, module, or other object to the Guest access level, only non-logged in users will have access. For example, if we create a new menu item with access level of Guest, as shown below,
[[Image:screenshot_acl_tutorial_20110112-05-de.png|center|frame]]
this menu item will only be visible to non-logged-in visitors to the site.

If required other user groups like Author can be granted access in the Guest access level, this would allow Authors to view articles in the front end for editing.

'''N.B. Login/logout in front end (''for changing data in session'') to see the change.'''

==Berechtigungen und Gruppenebenen gemeinsam nutzen==

As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.

This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:

* both groups can create new articles only in the History Assignments category.

* only History Teachers (not Assistant History Teachers) can Publish or otherwise have Edit State permission.

This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.

[[Image:Acl example diagram1 20091018-de.png|center|]]

In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.

To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.

Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.

[[Image:Acl example diagram2 20091018-de.png|center|]]

This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.

Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.

==ACL Aktion Berechtigungs-Beispiele==

===Backend Beitrag Administrator===

'''Problem:'''

We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.

'''Lösung:'''

# Create a new group called Article Administrator and make its parent group Public, as shown below.[[Image:screenshot_acl_tutorial_20110112-10-de.png|center|frame]] Because its parent group is Public, it won't have any permissions by default.
# In Users → Access Levels, edit the Special Access level to add the new group. That way they can get access to the back end menu items and modules (This assumes that the modules for the admin menu and quickicons have the Special Access level assigned to them, which is the default.) [[Image:screenshot_acl_tutorial_20110112-11-de.png|center|frame]] By default, the back-end menu items and modules are set to Special access, so if you forget to add the new group to the Special access level, you won't see any modules or menu items when you log in as a user of the new group.
# In Site → Global Configuration → Permissions, click on the Article Administrator group and change the permissions to Allowed for the following actions: Admin Login, Create, Delete, Edit, Edit State, and Edit Own. The screen below shows what will show before you press Save. [[Image:screenshot_acl_tutorial_20110112-12-de.png|center|frame]]After you save, the Calculated Permissions should show as shown below.[[Image:screenshot_acl_tutorial_20110112-13-de.png|center|frame]]Note that the permission for the Access Component is Inherited, which translates to Not Allowed. This is important. This means that this group will only be able to access components if we give the group "Allowed" permission for Access Component. So we only have to change the one component we want to give them access to and don't have to change any settings for the components where we don't want them to have access. If we had a case where we wanted to give a group access to everything except for one component, we could set the default to Allowed and then set the one component to Denied. Also note that we did not give the group Site Login permission, so users in this group will not be able to log into the front end. (If we wanted to allow that, we would just change the permission to Allowed for Site Login.)
# In Article Manager → Options → Permissions, change permissions to Allowed for this group for the Access Component action, as shown below.[[Image:screenshot_acl_tutorial_20110112-14-de.png|center|frame]]All of the other desired permissions are inherited.

That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end. For example, the screen below shows what a user in the Article Manager will see when they login to the back end.[[Image:screenshot_acl_tutorial_20110112-15-de.png|center|frame]]

==ACL Ansicht Zugriffsebenen-Beispiele==

A basic concept of using Access Levels is that all items with the same Access will be viewable by the same group of users. In other words, if two items have the same Access, you can't have one viewable by one user and not viewable by another user. On the other hand, it is easy to have one Group view any number of items with different Access levels.

Similarly, each Group has exactly the same combination of Access levels, but one User can be a member of more than one group. Depending on the situation, you may want to have users only in one Group or you may need to have a User in more than one Group.

This means that we may need to group our items so that items so that all items in a group have the same level of sensitivity. Here are some examples.

===Hierarchisches Beispiel===
In this example, Access levels are hierarchical, for example, like government security clearance codes. Say for example we have the following sets of classified documents: Classified, Secret, and Top Secret. Users have corresponding clearence codes. Users with Classified clearance can only see Classified documents and cannot see Secret or Top Secret. Users with Secret clearance can see Classified and Secret documents but not Top Secret. Users with Top Secret can see all documents.

In this case, you would create three Access levels: Classified, Secret, and Top Secret and the same three Groups. Users would only be members of one group, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| C1, C2, C3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Classified
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| S1, S2, S3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| TS1, TS2, TS3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Top Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret, Top Secret

|}

In this case, all users are in exactly one group, but some groups have access to more than one Access Level of items. In other words, we have a one-to-one relationship between users and groups, but a one-to-many relationship between Groups and Access Levels.

===Teamsicherheit Beispiel===

Another possible use case is a set of non-hierarchical teams. Let's say we have three teams, T1, T2, and T3. Some users are only on one team, but others might be on two or more teams. In this case, we could set up our Access Levels and Groups by team. Documents for each team have the access level for that team, and the Group for the team has only the one access level. When a User is on more than one team, they get added to the group for each team, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Beschreibung
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 1 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 2 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 3 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1, 2 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1,T2, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2, T3

|}

===Hybrid Example===

In a real-world situation, you might have a combination of these two arrangements. Say for example we have Managers and Staff. Staff can only see Staff documents and Managers can see Manager and Staff documents. Both types of users can be assigned to teams as well, in which case they can see all of the documents for that team. In addition, say that Managers can access some, but not all, team documents. Staff can only access team documents if they are members of that team.

In this example, we could set up the following Access Levels:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Access Level
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Description
| style="border:0.0007in solid #000000;padding:0.0382in;"| Groups

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team manager documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team staff documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team1 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1, Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team2 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2, Manager

|}

Then, users could be assigned to groups as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| User Type
| style="border:0.0007in solid #000000;padding:0.0382in;"| Group

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1, Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1, Team2

|}

<noinclude>
[[Category:Joomla! 1.6]]
[[Category:Joomla! 2.5]]
[[Category:Joomla! 3.x/de]]
[[Category:Tutorials/de]]
[[Category:Access Control/de]]
[[Category:Access Management]]
</noinclude>

Translations:J3.x:Access Control List Tutorial/112/de

2019-12-26T19:00:44Z

Sieger66:

J3.x:Access Control List Tutorial/de

2019-12-26T19:00:37Z

Sieger66:

<noinclude><languages /></noinclude>
{{Joomla version|version=3.x|comment=Serie}}
{{-}}
{{:J3.1:Access_Control_List/en}}

==Separate ACL für Anzeige und Aktionen==

Das Joomla ACL-System besteht genau genommen aus zwei völlig getrennten Systemen. Das eine System steuert, was Benutzer auf der Website "sehen" können. Das andere steuert, was Benutzer "tun" können (welche Aktionen ein Benutzer durchführen kann). Die ACL wird für jedes dieser Systeme anders eingerichtet.

===Steuern, was Benutzer sehen können===

Das Setup zum Steuern, was Benutzer sehen können, sieht wie folgt aus:
*Eine Reihe von Zugriffsebenen gemäß den Kategorien und/oder der Kombination von Kategorien erstellen, die nur angemeldete Benutzer sehen sollen. Anmerkung: Zu diesem Zeitpunkt werden noch keine Benutzergruppen den neuen Zugriffsebenen zugewiesen.

*Für jede Zugriffsebene eine Benutzergruppe erstellen, die 'Registriert' als übergeordnete Gruppe hat. Indem man für Benutzergruppen und Zugriffsebenen die gleichen Namen verwendet, kann man Verwirrungen zu einem späteren Zeitpunkt vorbeugen.

*Die neuen Zugriffsebenen bearbeiten und jeder die (neue) Benutzergruppe zuweisen. Wahrscheinlich möchten man auch die 'Super Benutzer' Gruppe (und/oder die anderen Standard-Benutzergruppen mit Ausnahme der Benutzergruppe 'Gast') den neuen Zugriffsebenen zuweisen.

*Jedem anzuzeigenden Eintrag eine Zugriffsebene zuweisen. Einträge sind sowohl inhaltliche Einträge (Beiträge, Kontakte, usw.), Menüeinträge als auch Module.

Immer dann, wenn ein Benutzer im Begriff ist, einen Eintrag auf einer Joomla-Seite anzeigen zu lassen, prüft das Programm, ob dieser Benutzer auch Zugriff auf den Eintrag hat. Das geschieht folgendermaßen:
# Zunächst wird eine Liste aller Zugriffsebenen erstellt, auf die der Benutzer zugreifen kann, basierend auf allen Gruppen, denen der Benutzer angehört. Sofern eine Gruppe eine übergeordnete Gruppe besitzt, sind die Zugriffsebenen für die übergeordnete Gruppe ebenfalls in der Liste enthalten.
# Danach wird überprüft, ob die Zugriffsebene für den Eintrag (Beitrag, Modul, Menüeintrag, usw.) in dieser Liste enthalten ist. Wenn dem so ist, wird der Eintrag dem Benutzer angezeigt. Falls der Benutzer die benötigten Zugriffsrechte besitzt, wird ihm der Zugriff verweigert.

Beachten, dass Zugriffsebenen für jede Gruppe separat festgelegt und nicht von der übergeordneten Gruppe einer Gruppe vererbt werden.

===Steuern, was Benutzer tun können===

Das System, das steuert, was Benutzer in einer Benutzergruppe tun können - welche Aktionen sie bei einem bestimmten Eintrag ausführen können - wird über den Tab 'Berechtigungen' in der Konfiguration und den Tab 'Berechtigungen' in den Optionen jeder einzelnen Komponente eingerichtet. Berechtigungen können auch auf Kategorienebene (bei Kernkomponenten) und auf Beitragsebene (bei Beiträgen) gesetzt werden.

* Wenn angemeldete Benutzer in bestimmten Kategorien Erstellen, Löschen, Status bearbeiten oder Eigene Inhalte bearbeiten dürfen, dann:
** Eine Benutzergruppe erstellen und als übergeordnete Gruppe eine der Benutzergruppen angeben, die Zugriff auf die Kategorie (oder Kategorien) haben, die diese neue Benutzergruppe ändern soll.
**Der neuen Benutzergruppe den entsprechenden Zugriffsebenen zuweisen. Dann die erforderlichen Berechtigungen für die neue Benutzergruppe entweder global oder pro Kategorie/Beitrag ändern.
*** Beim Erstellen einer Benutzergruppe ist es ratsam, eine übergeordnete Gruppe zu wählen, die über weniger Berechtigungen verfügt, als für die neue Gruppe erforderlich. Denn es ist einfacher, die Berechtigungen für jede Komponente/Kategorie/Beitrag zu erweitern, für die zusätzliche Berechtigungen nötig sind, als Berechtigungen aus den anderen Komponenten/Kategorien/Beiträgen zu entfernen.
****''(Beispiel: Es gibt 10 Kategorien, man möchte aber nur für eine Erstellen-Berechtigungen. Würde man für diese Gruppe die Berechtigungen global auf Erstellen erlaubt setzen, müsste man für diese Kategorien die Erstellen-Berechtigung entfernen. Und man müsste für diese Gruppe die Erstellen-Berechtigung bei jeder neuen Kategorie, die man zu einem späteren Zeitpunkt hinzufügt, ebenfalls entfernen).''
** Eine Benutzergruppe erstellen, die eine der Standardbenutzergruppen als übergeordnete Gruppe hat, NUR, wenn keine von diesen über die exakten Berechtigungen verfügt, die man benötigt und sich für alle Kategorien wünscht.

Beachten, dass dieses Setup unabhängig vom Setup für die Anzeige ist. Allerdings muss eine Benutzergruppe den entsprechenden Zugriffsebenen zugewiesen werden, damit der Benutzer in dieser Gruppe jene Berechtigungen verwenden kann.

Möchte ein Benutzer eine bestimmte Aktion bei einem Komponenten-Eintrag durchführen (z. B. einen Beitrag bearbeiten), überprüft das System (nachdem es überprüft hat, welcher Gruppe der Benutzer angehört und auf welche er Zugriff hat) die Berechtigung für diese Kombination aus Benutzer, Eintrag und Aktion. Liegt eine Erlaubnis vor, kann der Benutzer fortfahren. Andernfalls ist die Aktion nicht zulässig.

Das restliche Tutorial befasst sich mit der Steuerung, was Benutzer tun können - welche Aktionsberechtigungen sie haben.

==Aktionen, Gruppen und Vererbung==

Andererseits geht es bei der ACL auch darum, Benutzern Berechtigungen zu erteilen, damit diese Aktionen an Objekten durchführen können.

{| class="wikitable"
!style="width:20%;"|
!3.x Serie
|-
!Gruppen und Aktionen
|Aktionen, welche pro Gruppe erlaubt sind, werden durch den Website Administrator festgelegt.
|-
!Umfang von Berechtigungen
|Berechtigungen können auf mehreren Ebenen in der Hierarchie festgelegt werden: Website, Komponente, Kategorie, Objekt.
|-
!Vererbung von Berechtigungen
|Berechtigungen können von übergeordneten Gruppen und übergeordneten Kategorien geerbt werden.
|}

===Wie die Berechtigungen funktionieren===

Es gibt vier mögliche Berechtigungen für Aktionen. Diese sind (kurz skizziert):

* '''Nicht gesetzt''': Fällt standardmäßig auf "Nicht erlaubt" zurück. Aber im Gegensatz zur Berechtigung "Verweigert" kann diese Berechtigung außer Kraft gesetzt werden, wenn eine untergeordnete Gruppe oder eine in der Berechtigungshierarchie untergeordnete Ebene auf "Erlaubt" gesetzt wird. Diese Berechtigung kann nur für globale Berechtigungen der Konfiguration gesetzt werden.
* '''Vererbt''': Erbt den Wert von einer übergeordneten Gruppe oder einer in der Berechtigungshierarchie höheren Ebene. Diese Berechtigung gilt für alle Ebenen mit Ausnahme der obersten Ebene der Konfiguration.
* '''Verweigert''': Verbietet diese Aktion für diese Ebene und Gruppe. '''WICHTIG:''' Dadurch wird diese Aktion auch für alle untergeordneten Gruppen und alle untergeordneten Ebenen in der Berechtigungshierarchie verboten. Wird "Erlaubt" in einer untergeordneten Gruppe oder einer tieferen Ebene gesetzt, hat das keinen Effekt. Die Aktion wird immer für alle Mitglieder einer untergeordneten Gruppe und für alle untergeordneten Ebenen in der Berechtigungshierarchie abgelehnt.
* '''Erlaubt ''': Genehmigt diese Aktion für diese Ebene und Gruppe und für tiefere Ebenen und Untergruppen. Dies hat keine Auswirkungen, wenn eine höhere Gruppe oder Ebene auf "Verweigert" oder "Erlaubt" eingestellt ist. Wenn eine höhere Gruppe oder ein höheres Ebene auf "Verweigert" gesetzt ist, wird diese Berechtigung immer abgelehnt. Wenn eine höhere Gruppe oder Ebene auf Erlaubt eingestellt ist, ist diese Berechtigung bereits erlaubt.

===Hierarchie der Berechtigungsebenen===

Berechtigungen für Aktionen können in Version 2.5+ auf bis zu vier Ebenen festgelegt werden, wie folgt:
# '''Konfiguration''': legt die Standardberechtigungen für jede Aktion und Gruppe fest.
# '''Komponenten-Optionen-> Berechtigungen''': kann die Standardberechtigungen für diese Komponente überschreiben (z. B. Beiträge, Menüs, Benutzer, Banner usw.).
# '''Kategorie''': kann die Standardberechtigungen für Objekte in einer oder mehreren Kategorien überschreiben. Gilt für alle Komponenten mit Kategorien, einschließlich Beiträge, Banner, Kontakte, Newsfeeds und Weblinks.
# '''Beitrag''': kann die Berechtigungen für einen bestimmten Artikel überschreiben. Diese Ebene gilt nur für Beiträge. Alle anderen Komponenten erlauben nur die ersten drei Ebenen.

====Konfiguration====
Diese erreicht man über System → Konfiguration → Berechtigungen. Die nun sichtbare Maske dient dazu, die Berechtigungen auf der obersten Ebene für jede Gruppe und jede Aktion festzulegen, wie auch in der folgenden Abbildung gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Die möglichen Werte sind Vererbt, Erlaubt oder Verweigert. Die Spalte 'Errechnete Einstellung' zeigt die aktuelle Einstellung an. Diese ist entweder Nicht erlaubt (Standard), Erlaubt oder Nicht erlaubt.

Man kann immer nur an einer Gruppe gleichzeitig arbeiten, indem man den Reiter für ebendiese Gruppe anklickt. Die Berechtigungen kann man über die Dropdownlisten unter Neue Einstellung wählen ändern.

Beachten Sie, dass die Spalte "Errechnete Einstellung" erst aktualisiert wird, wenn Sie auf die Schaltfläche "Speichern" in der Werkzeugleiste klicken.

Um zu überprüfen, ob die Einstellungen Ihren Wünschen entsprechen, klicken Sie auf die Schaltfläche Speichern und überprüfen anschließend die Spalte Errechnete Einstellung.

====Komponenten-Optionen->Berechtigungen====
Auf diese wird für jede Komponente durch Klicken auf das Symbol "Optionen" in der Werkzeugleiste zugegriffen. Dieser Bildschirm ist ähnlich wie der Bildschirm "Globale Konfiguration" oben links. Wenn Sie beispielsweise im Menü-Manager auf das Symbol in der Werkzeugleiste Optionen klicken, werden die folgenden Menüs angezeigt.
[[Image:Screenshot_menu_acl_J3_tutorial-en.jpg]]

Der Zugriff auf Optionen ist nur für Mitglieder von Gruppen möglich, die die Berechtigung für die Aktion Konfiguration in für jede Komponente haben. Im obigen Beispiel hat die Gruppe Administrator die Berechtigung Erlaubt für die Option Konfigurieren, so dass Mitglieder dieser Gruppe auf diesen Bildschirm zugreifen können.

===Kategorie===
Auf die Kategorieberechtigungen wird im Category Manager zugegriffen: Bildschirm Kategorie bearbeiten, in einer Registerkarte oben auf dem Bildschirm. Dieser Bildschirm hat fünf Berechtigungen, wie folgt:

[[Image:Screenshot_category_acl_j3_tutorial-en.png]]

In diesen Bildern bearbeiten Sie die Berechtigungen für jeweils eine Benutzergruppe. Im obigen Beispiel bearbeiten Sie die Berechtigungen für die Gruppe Administrator.

Achten Sie darauf, dass die Aktionen "Konfigurieren und Zugriffssteuerung" nicht auf der Kategorieebene angewendet werden, so dass diese Aktionen nicht enthalten sind.

Beachten Sie auch, dass Kategorien in einer Hierarchie angeordnet werden können. Wenn ja, dann werden Aktionsberechtigungen in einer übergeordneten Kategorie automatisch an eine untergeordnete Kategorie vererbt. Wenn Sie beispielsweise eine Kategoriehierarchie von Tieren → Haustiere → Hunde hätten, dann würde die vollständige Berechtigungshierarchie für einen Artikel in der Kategorie Hunde wie folgt aussehen:
* Globale Konfiguration
* Artikel-Manager → Optionen → Genehmigung → Erlaubnis
* Tierkategorie
* Kategorie Haustiere
* Kategorie Hunde
* spezifischer Artikel

====Beitrag====
Berechtigungen für einzelne Beiträge findet man im "Beitrag" unter dem Tab-Reiter "Berechigungen". Dieser Bildschirm hat drei Aktionen, wie unten gezeigt.

[[Image:j3x_acl_tutorial_article_manager_article_permissions-en.png]]

Auch hier bearbeiten Sie jede Gruppe für sich. Um auf die Berechtigungen zuzugreifen wechseln Sie im Artikel auf den Reiter "Berechtigungen" im oberen Reiter. Über das Drop Down Menü wählen Sie die neue Berechtigung im Anschluss speichern Sie den Beitrag ab.

Beachten Sie, dass die Aktionen Configure, Access Component und Create auf Artikelebene nicht gelten, so dass diese Aktionen nicht berücksichtigt werden. Die Berechtigung zum Anlegen eines Artikels wird auf einer der höheren Ebenen der Hierarchie festgelegt.

===Zugriffsebenen===

Die Zugriffsebenen der 3.x-Serie sind einfach und flexibel. Der folgende Bildschirm zeigt die spezielle Zugriffsebene.
[[Image:j3x_acl_tutorial_viewing_levels-en.png|center]]
Aktivieren Sie einfach das Kontrollkästchen für jede Gruppe, die Sie in diesem Level aufnehmen wollen. Die spezielle Zugriffsebene umfasst die Gruppen Manager, Autor und Superuser. Es beinhaltet auch untergeordnete Gruppen dieser Gruppen. Die Gruppe Administrator ist also enthalten, da es sich um eine Untergruppe der Gruppe Manager handelt. Die Gruppen Editor, Publisher und Shop Suppliers sind enthalten, da es sich um Untergruppen des Autors handelt.

Jedem Objekt im Frontend ist eine Zugriffsebene zugeordnet. Wenn die Ebene öffentlich ist, kann jeder auf dieses Objekt zugreifen. Andernfalls dürfen nur Mitglieder von Gruppen, die dieser Zugriffsebene zugeordnet sind, auf dieses Objekt zugreifen.

Die Zugriffsebenen sind den Menüpunkten und den Modulen zugeordnet. Jede kann nur einer Zugriffsebene zugeordnet werden.

Der folgende Bildschirm zeigt beispielsweise den Bildschirm Menüpunkt bearbeiten mit der Liste der verfügbaren Zugriffsebenen....

[[Image:j3x_acl_tutorial_edit_menu_item_level_dropdown-en.png|center]]

==Standard-ACL-Setup==

Wenn Joomla! installiert ist, werden diese auf die ursprünglichen Standardwerte gesetzt. Wir werden diese Grundeinstellungen besprechen, um die Arbeitsweise der ACL zu verstehen.

===Standardgruppen===

Mit der Version 3.x können Sie Ihre individuellen Gruppen definieren. Wenn Sie die Version 3.x installieren, enthält sie eine Reihe von Standardgruppen, die im Folgenden dargestellt werden, sind die grundlegenden Standardbenutzergruppen. (Zusätzliche Standardbenutzergruppen werden mit Beispieldaten installiert)

[[Image:Screenshot_usergroupsl_acl_J3_tutorial-en.png|center]]

Die Pfeile zeigen die untergeordneten Elternbeziehungen an. Wie vorstehend besprochen, wird diese Berechtigung, wenn Sie eine Berechtigung für eine übergeordnete Gruppe festlegen, automatisch an alle Untergruppen vererbt. Die vererbten und zulässigen Berechtigungen können für eine Untergruppe überschrieben werden. Die Berechtigung Verweigert kann nicht überschrieben werden und verweigert immer eine Aktion für alle Untergruppen.

===Konfiguration===

Joomla! Version 3.x wird mit den gleichen bekannten Backend-Rechten wie die Version 1.5 (EOL) installiert. Mit der Version 3.x können Sie diese jedoch leicht an die Bedürfnisse Ihrer Website anpassen.

Wie bereits besprochen, werden die Berechtigungen für jede Aktion von der obigen Ebene in der Berechtigungshierarchie und von der übergeordneten Gruppe einer Gruppe übernommen. Also, wie funktioniert das? Die oberste Ebene dafür ist der gesamte Standort. Dies wird in der Site->Globale Konfiguration->Berechtigungen eingerichtet, wie unten gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Das erste, was man bemerken sollte, sind die zehn Aktionen: Standortlogin, Admin-Login, Offline-Zugriff, Superuser, Access Administration Interface, Erstellen, Löschen, Bearbeiten, Status bearbeiten und Eigenes bearbeiten. Dies sind die Aktionen, die ein Benutzer an einem Objekt in Joomla durchführen kann. Die spezifische Bedeutung jeder Aktion hängt vom Kontext ab. Für das Bild Globale Konfiguration sind sie wie folgt definiert:

Site Login : Login to the front end of the site

;Admin Login : Melden Sie sich am Backend der Website an.

Offline-Zugriff: Melden Sie sich am Frontend der Website an, wenn die Website offline ist (wenn die globale Konfigurationseinstellung "Site Offline" auf Ja gesetzt ist).

Superuser: Gewährt dem Benutzer den Status "Superuser". Benutzer mit dieser Berechtigung dürfen alles auf der Website machen. Nur Benutzer mit dieser Berechtigung können die Einstellungen der globalen Konfiguration ändern. Diese Berechtigungen können nicht eingeschränkt werden. Es ist wichtig zu verstehen, dass, wenn ein Benutzer Mitglied einer Super Admin-Gruppe ist, alle anderen Berechtigungen, die diesem Benutzer zugewiesen sind, irrelevant sind. Der Benutzer kann jede Aktion auf der Website durchführen. Es können jedoch weiterhin Zugriffsebenen zugewiesen werden, um zu steuern, was diese Gruppe auf der Website sieht. (Natürlich kann ein Super-Admin-Benutzer die Zugriffsebenen ändern, wenn er möchte, so dass die Zugriffsebenen nicht vollständig einschränken, was ein Super-Admin-Benutzer sehen kann.)

Zugangskomponente: Öffnen Sie die Bildschirme der Komponentenverwaltung (Benutzerverwaltung, Menüverwaltung, Artikelverwaltung usw.).

;Create : Create new objects (for example, users, menu items, articles, weblinks, and so on)

;Löschen : Löschen eines existienden Objekts

;Ändern : Ändern eines existierenden Objektes

;Ändern eines Objekt Status (Veröffentlicht, nicht Veröffentlicht, Archiviert und Gelöscht)

Eigene Objekte bearbeiten: Bearbeiten Sie Objekte, die Sie erstellt haben.

Each Group for the site has its own slider which is opened by clicking on the group name. In this case (with the sample data installed), we have the standard 7 groups that we had in version 1.5 plus two additional groups called "Shop Suppliers" and "Customer Group". Notice that our groups are set up with the same permissions as they had in version 1.5. Keep in mind that we can change any of these permissions to make the security work the way we want. Let's go through this to see how it works.

* '''Public''' has everything set to "Not set", as shown below.{{-}}[[Image:Screenshot_global_acl_public_J3_tutorial-en.png]]
**This can be a bit confusing. Basically, "Not Set" is the same as "Inherited". Because Public is our top-level group, and because Global Configuration is the top level of the component hierarchy, there is nothing to inherit from. So "Not Set" is used instead of "Inherit".
**The default in this case is for no permissions. So, as you would expect, the Public group has no special permissions. Also, it is important to note that, since nothing is set to Denied, all of these permissions may be overridden by child groups or by lower levels in the permission hierarchy.

* '''Guest''' is a 'child' group of the Public group has everything set to 'Inherited' {{-}}[[Image:Screenshot_global_acl_guest_J3_tutorial-de.png]]
** This is the default 'Guest User Group' in the User Manager options and the Group that (non logged in) visitors to your site are placed in.

* '''Manager''' is a "child" group of the Public group. It has Allowed permissions for everything except Access Component and Super Admin. So a member of this group can do everything in the front and back end of the site except change Global Permissions and Component Options. {{-}}[[Image:Screenshot_global_acl_manager_J3_tutorial-en.png]]

* '''Administrator''' group members inherit all of the Manager permissions and also have Allowed for Access Component. So members of this group by default can access the Options screens for each component. {{-}}[[Image:Screenshot_global_acl_administrator_J3_tutorial-en.png]]

* '''Registered''' is the same a Public except for the Allow permission for the Site Login action. This means that members of the Registered group can login to the site. Since default permissions are inherited, this means that, unless a child group overrides this permission, all child groups of the Registered group will be able to login as well. {{-}}[[Image:Screenshot_global_acl_registered_J3_tutorial-en.png]]

* '''Author''' is a child of the Registered group and inherits its permissions and also adds Create and Edit Own. Since Author, Editor, and Publisher have no back-end permissions, we will discuss them below, when we discuss front-end permissions.{{-}}[[Image:Screenshot_global_acl_author_J3_tutorial-en.png]]

* '''Editor''' is a child of the Authors group and adds the Edit permission. {{-}}[[Image:Screenshot_global_acl_editor_J3_tutorial-en.png]]

* '''Publisher''' is a child of Editor and adds the Edit State permission.{{-}}[[Image:Screenshot_global_acl_publisher_J3_tutorial-de.png]]

* '''Shop Suppliers''' is an example group that is installed if you install the sample data. It is a child group of Author.

* '''Customer Group''' is an example group that is installed if you install the sample data. It is a child group of Registered.

* '''Super Users''' group has the Allow permission for the Super Admin action. Because of this, members of this group have super user permissions throughout the site. They are the only users who can access and edit values on the Global Configuration screen. Users with permission for the Super Admin action have some special characteristics:
:* If a user has Super Admin permissions, no other permissions for this user matter. The user can perform any action on the site.
:* Only Super Admin users can create, edit, or delete other Super Admin users or groups.

There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.

This provides a lot of flexibility. For example, if you wanted Shop Suppliers to be able to have the ability to login to the back end, you could just change their Admin Login value to "Allowed". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherited (or Denied).

It is also important to understand that the ability to have child groups is completely optional. It allows you to save some time when setting up new groups. However, if you like, you can set up all groups to have Public as the parent and not inherit any permissions from a parent group.

===Komponenten-Optionen & Berechtigungen===

Now, let's continue to see how the default back-end permissions for version 2.5 mimic the permissions for version 1.5. The Super Users group in 2.5 is equivalent to the Super Administrator group in 1.5.

Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 2.5 configuration. Let's see how this is accomplished.

If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:

[[Image:screenshot_acl_tutorial_20110111-09-de.png|center|]]
[[Image:screenshot_acl_tutorial_20110111-10-de.png|center|]]

This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.

First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.

Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.

If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.

In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.

It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.

===Frontend Berechtigungen===

Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions. First, let's look at the permissions for Manager, as shown below.
[[Image:screenshot_acl_tutorial_20110111-11a-de.png|center|frame]]
Manager has allowed permission for all actions except Configure. So members of the Manager group can do everything with Articles except open the Options screen.

Now let's look at Administrator, as shown below.
[[Image:screenshot_acl_tutorial_20110111-12a-de.png|center|frame]]
Administrator has Allowed for Configure, so Administrators can edit this Options screen.

Both groups can create, delete, edit, and change the state of articles.

Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set.

Authors only have Create and Edit Own permissions, as shown below.
[[Image:screenshot_acl_tutorial_20110112-07-de.png|center|frame]]
This means that Authors can create articles and can edit articles they have created. They may not delete articles, change the published state of articles, or edit articles created by others.

Editors have the same permissions as Authors with the addition of permission for the Edit action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-08-de.png|center|frame]]
So Editors can edit articles written by anyone.

Publishers can do everything Editors can do plus they have permission for the Edit State action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-09-de.png|center|frame]]
So Publishers can change the published state of an article. The possible states include Published, Unpublished, Archived, and Trashed.

All of these groups have Inherit permission for Configure and Access Component. Remember that Author is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Configure and Access Component, and since Author's permission for these actions is "Inherited", then Author does not have these permissions either. This same permission is passed from Author to Editor and from Editor to Publisher. So, by default, none of these groups are allowed to work with articles in the back end.

It is important to remember that these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.

Beachte auch das in den ursprünglichen Standardwerten keine Berechtigungen auf Verweigert eingestellt sind. Dies ermöglicht in allen Berechtigungsebenen die jeweilige Berechtigung auf Erlaubt einzustellen. Bedenke, wenn eine Aktion auf Verweigert eingestellt ist, das diese Aktion auch in allen untergeordneten Ebenen in der Berechtigungshierarchie verweigert wird. Zum Beispiel, wenn die Seitenameldung für Registered auf Verweigert (anstatt auf Erlaubt) eingestellt wird, kann man Publishers diese Aktion per Berechtigungeinstellung nicht erteilen.

=== Beitrags-Manager & Aktions-Diagramm ===

The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.

[[Image:screenshot_acl_tutorial_20110111-16-de.png|center|]]

* '''Configure''' allows you to view and change the Options for the component.
* '''Access Component''' allows you to navigate to the Article Manager. Without this permission, no other actions are possible.
* '''Create''' allows you to add new articles.
* '''Delete''' allows you to delete trashed articles. Note that the Delete icon only shows in the toolbar when you have the "Select State" filter set to "Trash".
* '''Edit''' allows you to edit existing articles.
* '''Edit State''' allows to you Publish, Unpublish, Archive, or Trash articles.
* '''Edit Own''' is the same as Edit except that it only applies to articles written by you.

==Allowing Guest-Only Access to Menu Items and Modules==

Version 1.6 introduced the ability to create a View Access Level that is only for guests of the site (meaning a user who is not logged in). The example below shows how you can set up this new feature.
''(N.B. Steps 1 to 3 are not needed for Joomla! 3.x as they exist in the default install)''

#Create a new user group called Guest. Make it a child of the Public group as shown below. [[Image:screenshot_acl_tutorial_20110112-01-de.png|center|frame]]
# Create a new access level called Guest and grant only the Guest group access to this level, as shown below.[[Image:screenshot_acl_tutorial_20110112-02-de.png|center|frame]]
# Navigate to User Manager→Options→Component and change the Guest User Group from the default value of "Public" to "Guest", as shown below.
[[Image:screenshot_acl_tutorial_20110112-04-de.png|center|frame]]
Now, if we assign a menu item, module, or other object to the Guest access level, only non-logged in users will have access. For example, if we create a new menu item with access level of Guest, as shown below,
[[Image:screenshot_acl_tutorial_20110112-05-de.png|center|frame]]
this menu item will only be visible to non-logged-in visitors to the site.

If required other user groups like Author can be granted access in the Guest access level, this would allow Authors to view articles in the front end for editing.

'''N.B. Login/logout in front end (''for changing data in session'') to see the change.'''

==Berechtigungen und Gruppenebenen gemeinsam nutzen==

As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.

This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:

* both groups can create new articles only in the History Assignments category.

* only History Teachers (not Assistant History Teachers) can Publish or otherwise have Edit State permission.

This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.

[[Image:Acl example diagram1 20091018-de.png|center|]]

In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.

To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.

Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.

[[Image:Acl example diagram2 20091018-de.png|center|]]

This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.

Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.

==ACL Aktion Berechtigungs-Beispiele==

===Backend Beitrag Administrator===

'''Problem:'''

We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.

'''Lösung:'''

# Create a new group called Article Administrator and make its parent group Public, as shown below.[[Image:screenshot_acl_tutorial_20110112-10-de.png|center|frame]] Because its parent group is Public, it won't have any permissions by default.
# In Users → Access Levels, edit the Special Access level to add the new group. That way they can get access to the back end menu items and modules (This assumes that the modules for the admin menu and quickicons have the Special Access level assigned to them, which is the default.) [[Image:screenshot_acl_tutorial_20110112-11-de.png|center|frame]] By default, the back-end menu items and modules are set to Special access, so if you forget to add the new group to the Special access level, you won't see any modules or menu items when you log in as a user of the new group.
# In Site → Global Configuration → Permissions, click on the Article Administrator group and change the permissions to Allowed for the following actions: Admin Login, Create, Delete, Edit, Edit State, and Edit Own. The screen below shows what will show before you press Save. [[Image:screenshot_acl_tutorial_20110112-12-de.png|center|frame]]After you save, the Calculated Permissions should show as shown below.[[Image:screenshot_acl_tutorial_20110112-13-de.png|center|frame]]Note that the permission for the Access Component is Inherited, which translates to Not Allowed. This is important. This means that this group will only be able to access components if we give the group "Allowed" permission for Access Component. So we only have to change the one component we want to give them access to and don't have to change any settings for the components where we don't want them to have access. If we had a case where we wanted to give a group access to everything except for one component, we could set the default to Allowed and then set the one component to Denied. Also note that we did not give the group Site Login permission, so users in this group will not be able to log into the front end. (If we wanted to allow that, we would just change the permission to Allowed for Site Login.)
# In Article Manager → Options → Permissions, change permissions to Allowed for this group for the Access Component action, as shown below.[[Image:screenshot_acl_tutorial_20110112-14-de.png|center|frame]]All of the other desired permissions are inherited.

That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end. For example, the screen below shows what a user in the Article Manager will see when they login to the back end.[[Image:screenshot_acl_tutorial_20110112-15-de.png|center|frame]]

==ACL Ansicht Zugriffsebenen-Beispiele==

A basic concept of using Access Levels is that all items with the same Access will be viewable by the same group of users. In other words, if two items have the same Access, you can't have one viewable by one user and not viewable by another user. On the other hand, it is easy to have one Group view any number of items with different Access levels.

Similarly, each Group has exactly the same combination of Access levels, but one User can be a member of more than one group. Depending on the situation, you may want to have users only in one Group or you may need to have a User in more than one Group.

This means that we may need to group our items so that items so that all items in a group have the same level of sensitivity. Here are some examples.

===Hierarchisches Beispiel===
In this example, Access levels are hierarchical, for example, like government security clearance codes. Say for example we have the following sets of classified documents: Classified, Secret, and Top Secret. Users have corresponding clearence codes. Users with Classified clearance can only see Classified documents and cannot see Secret or Top Secret. Users with Secret clearance can see Classified and Secret documents but not Top Secret. Users with Top Secret can see all documents.

In this case, you would create three Access levels: Classified, Secret, and Top Secret and the same three Groups. Users would only be members of one group, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| C1, C2, C3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Classified
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| S1, S2, S3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| TS1, TS2, TS3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Top Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret, Top Secret

|}

In this case, all users are in exactly one group, but some groups have access to more than one Access Level of items. In other words, we have a one-to-one relationship between users and groups, but a one-to-many relationship between Groups and Access Levels.

===Teamsicherheit Beispiel===

Another possible use case is a set of non-hierarchical teams. Let's say we have three teams, T1, T2, and T3. Some users are only on one team, but others might be on two or more teams. In this case, we could set up our Access Levels and Groups by team. Documents for each team have the access level for that team, and the Group for the team has only the one access level. When a User is on more than one team, they get added to the group for each team, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Beschreibung
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 1 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 2 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 3 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1, 2 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1,T2, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2, T3

|}

===Hybrid Example===

In a real-world situation, you might have a combination of these two arrangements. Say for example we have Managers and Staff. Staff can only see Staff documents and Managers can see Manager and Staff documents. Both types of users can be assigned to teams as well, in which case they can see all of the documents for that team. In addition, say that Managers can access some, but not all, team documents. Staff can only access team documents if they are members of that team.

In this example, we could set up the following Access Levels:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Access Level
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Description
| style="border:0.0007in solid #000000;padding:0.0382in;"| Groups

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team manager documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team staff documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team1 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1, Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team2 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2, Manager

|}

Then, users could be assigned to groups as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| User Type
| style="border:0.0007in solid #000000;padding:0.0382in;"| Group

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1, Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1, Team2

|}

<noinclude>
[[Category:Joomla! 1.6]]
[[Category:Joomla! 2.5]]
[[Category:Joomla! 3.x/de]]
[[Category:Tutorials/de]]
[[Category:Access Control/de]]
[[Category:Access Management]]
</noinclude>

Translations:J3.x:Access Control List Tutorial/110/de

2019-12-26T19:00:37Z

Sieger66:

J3.x:Access Control List Tutorial/de

2019-12-26T19:00:31Z

Sieger66:

<noinclude><languages /></noinclude>
{{Joomla version|version=3.x|comment=Serie}}
{{-}}
{{:J3.1:Access_Control_List/en}}

==Separate ACL für Anzeige und Aktionen==

Das Joomla ACL-System besteht genau genommen aus zwei völlig getrennten Systemen. Das eine System steuert, was Benutzer auf der Website "sehen" können. Das andere steuert, was Benutzer "tun" können (welche Aktionen ein Benutzer durchführen kann). Die ACL wird für jedes dieser Systeme anders eingerichtet.

===Steuern, was Benutzer sehen können===

Das Setup zum Steuern, was Benutzer sehen können, sieht wie folgt aus:
*Eine Reihe von Zugriffsebenen gemäß den Kategorien und/oder der Kombination von Kategorien erstellen, die nur angemeldete Benutzer sehen sollen. Anmerkung: Zu diesem Zeitpunkt werden noch keine Benutzergruppen den neuen Zugriffsebenen zugewiesen.

*Für jede Zugriffsebene eine Benutzergruppe erstellen, die 'Registriert' als übergeordnete Gruppe hat. Indem man für Benutzergruppen und Zugriffsebenen die gleichen Namen verwendet, kann man Verwirrungen zu einem späteren Zeitpunkt vorbeugen.

*Die neuen Zugriffsebenen bearbeiten und jeder die (neue) Benutzergruppe zuweisen. Wahrscheinlich möchten man auch die 'Super Benutzer' Gruppe (und/oder die anderen Standard-Benutzergruppen mit Ausnahme der Benutzergruppe 'Gast') den neuen Zugriffsebenen zuweisen.

*Jedem anzuzeigenden Eintrag eine Zugriffsebene zuweisen. Einträge sind sowohl inhaltliche Einträge (Beiträge, Kontakte, usw.), Menüeinträge als auch Module.

Immer dann, wenn ein Benutzer im Begriff ist, einen Eintrag auf einer Joomla-Seite anzeigen zu lassen, prüft das Programm, ob dieser Benutzer auch Zugriff auf den Eintrag hat. Das geschieht folgendermaßen:
# Zunächst wird eine Liste aller Zugriffsebenen erstellt, auf die der Benutzer zugreifen kann, basierend auf allen Gruppen, denen der Benutzer angehört. Sofern eine Gruppe eine übergeordnete Gruppe besitzt, sind die Zugriffsebenen für die übergeordnete Gruppe ebenfalls in der Liste enthalten.
# Danach wird überprüft, ob die Zugriffsebene für den Eintrag (Beitrag, Modul, Menüeintrag, usw.) in dieser Liste enthalten ist. Wenn dem so ist, wird der Eintrag dem Benutzer angezeigt. Falls der Benutzer die benötigten Zugriffsrechte besitzt, wird ihm der Zugriff verweigert.

Beachten, dass Zugriffsebenen für jede Gruppe separat festgelegt und nicht von der übergeordneten Gruppe einer Gruppe vererbt werden.

===Steuern, was Benutzer tun können===

Das System, das steuert, was Benutzer in einer Benutzergruppe tun können - welche Aktionen sie bei einem bestimmten Eintrag ausführen können - wird über den Tab 'Berechtigungen' in der Konfiguration und den Tab 'Berechtigungen' in den Optionen jeder einzelnen Komponente eingerichtet. Berechtigungen können auch auf Kategorienebene (bei Kernkomponenten) und auf Beitragsebene (bei Beiträgen) gesetzt werden.

* Wenn angemeldete Benutzer in bestimmten Kategorien Erstellen, Löschen, Status bearbeiten oder Eigene Inhalte bearbeiten dürfen, dann:
** Eine Benutzergruppe erstellen und als übergeordnete Gruppe eine der Benutzergruppen angeben, die Zugriff auf die Kategorie (oder Kategorien) haben, die diese neue Benutzergruppe ändern soll.
**Der neuen Benutzergruppe den entsprechenden Zugriffsebenen zuweisen. Dann die erforderlichen Berechtigungen für die neue Benutzergruppe entweder global oder pro Kategorie/Beitrag ändern.
*** Beim Erstellen einer Benutzergruppe ist es ratsam, eine übergeordnete Gruppe zu wählen, die über weniger Berechtigungen verfügt, als für die neue Gruppe erforderlich. Denn es ist einfacher, die Berechtigungen für jede Komponente/Kategorie/Beitrag zu erweitern, für die zusätzliche Berechtigungen nötig sind, als Berechtigungen aus den anderen Komponenten/Kategorien/Beiträgen zu entfernen.
****''(Beispiel: Es gibt 10 Kategorien, man möchte aber nur für eine Erstellen-Berechtigungen. Würde man für diese Gruppe die Berechtigungen global auf Erstellen erlaubt setzen, müsste man für diese Kategorien die Erstellen-Berechtigung entfernen. Und man müsste für diese Gruppe die Erstellen-Berechtigung bei jeder neuen Kategorie, die man zu einem späteren Zeitpunkt hinzufügt, ebenfalls entfernen).''
** Eine Benutzergruppe erstellen, die eine der Standardbenutzergruppen als übergeordnete Gruppe hat, NUR, wenn keine von diesen über die exakten Berechtigungen verfügt, die man benötigt und sich für alle Kategorien wünscht.

Beachten, dass dieses Setup unabhängig vom Setup für die Anzeige ist. Allerdings muss eine Benutzergruppe den entsprechenden Zugriffsebenen zugewiesen werden, damit der Benutzer in dieser Gruppe jene Berechtigungen verwenden kann.

Möchte ein Benutzer eine bestimmte Aktion bei einem Komponenten-Eintrag durchführen (z. B. einen Beitrag bearbeiten), überprüft das System (nachdem es überprüft hat, welcher Gruppe der Benutzer angehört und auf welche er Zugriff hat) die Berechtigung für diese Kombination aus Benutzer, Eintrag und Aktion. Liegt eine Erlaubnis vor, kann der Benutzer fortfahren. Andernfalls ist die Aktion nicht zulässig.

Das restliche Tutorial befasst sich mit der Steuerung, was Benutzer tun können - welche Aktionsberechtigungen sie haben.

==Aktionen, Gruppen und Vererbung==

Andererseits geht es bei der ACL auch darum, Benutzern Berechtigungen zu erteilen, damit diese Aktionen an Objekten durchführen können.

{| class="wikitable"
!style="width:20%;"|
!3.x Serie
|-
!Gruppen und Aktionen
|Aktionen, welche pro Gruppe erlaubt sind, werden durch den Website Administrator festgelegt.
|-
!Umfang von Berechtigungen
|Berechtigungen können auf mehreren Ebenen in der Hierarchie festgelegt werden: Website, Komponente, Kategorie, Objekt.
|-
!Vererbung von Berechtigungen
|Berechtigungen können von übergeordneten Gruppen und übergeordneten Kategorien geerbt werden.
|}

===Wie die Berechtigungen funktionieren===

Es gibt vier mögliche Berechtigungen für Aktionen. Diese sind (kurz skizziert):

* '''Nicht gesetzt''': Fällt standardmäßig auf "Nicht erlaubt" zurück. Aber im Gegensatz zur Berechtigung "Verweigert" kann diese Berechtigung außer Kraft gesetzt werden, wenn eine untergeordnete Gruppe oder eine in der Berechtigungshierarchie untergeordnete Ebene auf "Erlaubt" gesetzt wird. Diese Berechtigung kann nur für globale Berechtigungen der Konfiguration gesetzt werden.
* '''Vererbt''': Erbt den Wert von einer übergeordneten Gruppe oder einer in der Berechtigungshierarchie höheren Ebene. Diese Berechtigung gilt für alle Ebenen mit Ausnahme der obersten Ebene der Konfiguration.
* '''Verweigert''': Verbietet diese Aktion für diese Ebene und Gruppe. '''WICHTIG:''' Dadurch wird diese Aktion auch für alle untergeordneten Gruppen und alle untergeordneten Ebenen in der Berechtigungshierarchie verboten. Wird "Erlaubt" in einer untergeordneten Gruppe oder einer tieferen Ebene gesetzt, hat das keinen Effekt. Die Aktion wird immer für alle Mitglieder einer untergeordneten Gruppe und für alle untergeordneten Ebenen in der Berechtigungshierarchie abgelehnt.
* '''Erlaubt ''': Genehmigt diese Aktion für diese Ebene und Gruppe und für tiefere Ebenen und Untergruppen. Dies hat keine Auswirkungen, wenn eine höhere Gruppe oder Ebene auf "Verweigert" oder "Erlaubt" eingestellt ist. Wenn eine höhere Gruppe oder ein höheres Ebene auf "Verweigert" gesetzt ist, wird diese Berechtigung immer abgelehnt. Wenn eine höhere Gruppe oder Ebene auf Erlaubt eingestellt ist, ist diese Berechtigung bereits erlaubt.

===Hierarchie der Berechtigungsebenen===

Berechtigungen für Aktionen können in Version 2.5+ auf bis zu vier Ebenen festgelegt werden, wie folgt:
# '''Konfiguration''': legt die Standardberechtigungen für jede Aktion und Gruppe fest.
# '''Komponenten-Optionen-> Berechtigungen''': kann die Standardberechtigungen für diese Komponente überschreiben (z. B. Beiträge, Menüs, Benutzer, Banner usw.).
# '''Kategorie''': kann die Standardberechtigungen für Objekte in einer oder mehreren Kategorien überschreiben. Gilt für alle Komponenten mit Kategorien, einschließlich Beiträge, Banner, Kontakte, Newsfeeds und Weblinks.
# '''Beitrag''': kann die Berechtigungen für einen bestimmten Artikel überschreiben. Diese Ebene gilt nur für Beiträge. Alle anderen Komponenten erlauben nur die ersten drei Ebenen.

====Konfiguration====
Diese erreicht man über System → Konfiguration → Berechtigungen. Die nun sichtbare Maske dient dazu, die Berechtigungen auf der obersten Ebene für jede Gruppe und jede Aktion festzulegen, wie auch in der folgenden Abbildung gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Die möglichen Werte sind Vererbt, Erlaubt oder Verweigert. Die Spalte 'Errechnete Einstellung' zeigt die aktuelle Einstellung an. Diese ist entweder Nicht erlaubt (Standard), Erlaubt oder Nicht erlaubt.

Man kann immer nur an einer Gruppe gleichzeitig arbeiten, indem man den Reiter für ebendiese Gruppe anklickt. Die Berechtigungen kann man über die Dropdownlisten unter Neue Einstellung wählen ändern.

Beachten Sie, dass die Spalte "Errechnete Einstellung" erst aktualisiert wird, wenn Sie auf die Schaltfläche "Speichern" in der Werkzeugleiste klicken.

Um zu überprüfen, ob die Einstellungen Ihren Wünschen entsprechen, klicken Sie auf die Schaltfläche Speichern und überprüfen anschließend die Spalte Errechnete Einstellung.

====Komponenten-Optionen->Berechtigungen====
Auf diese wird für jede Komponente durch Klicken auf das Symbol "Optionen" in der Werkzeugleiste zugegriffen. Dieser Bildschirm ist ähnlich wie der Bildschirm "Globale Konfiguration" oben links. Wenn Sie beispielsweise im Menü-Manager auf das Symbol in der Werkzeugleiste Optionen klicken, werden die folgenden Menüs angezeigt.
[[Image:Screenshot_menu_acl_J3_tutorial-en.jpg]]

Der Zugriff auf Optionen ist nur für Mitglieder von Gruppen möglich, die die Berechtigung für die Aktion Konfiguration in für jede Komponente haben. Im obigen Beispiel hat die Gruppe Administrator die Berechtigung Erlaubt für die Option Konfigurieren, so dass Mitglieder dieser Gruppe auf diesen Bildschirm zugreifen können.

===Kategorie===
Auf die Kategorieberechtigungen wird im Category Manager zugegriffen: Bildschirm Kategorie bearbeiten, in einer Registerkarte oben auf dem Bildschirm. Dieser Bildschirm hat fünf Berechtigungen, wie folgt:

[[Image:Screenshot_category_acl_j3_tutorial-en.png]]

In diesen Bildern bearbeiten Sie die Berechtigungen für jeweils eine Benutzergruppe. Im obigen Beispiel bearbeiten Sie die Berechtigungen für die Gruppe Administrator.

Achten Sie darauf, dass die Aktionen "Konfigurieren und Zugriffssteuerung" nicht auf der Kategorieebene angewendet werden, so dass diese Aktionen nicht enthalten sind.

Beachten Sie auch, dass Kategorien in einer Hierarchie angeordnet werden können. Wenn ja, dann werden Aktionsberechtigungen in einer übergeordneten Kategorie automatisch an eine untergeordnete Kategorie vererbt. Wenn Sie beispielsweise eine Kategoriehierarchie von Tieren → Haustiere → Hunde hätten, dann würde die vollständige Berechtigungshierarchie für einen Artikel in der Kategorie Hunde wie folgt aussehen:
* Globale Konfiguration
* Artikel-Manager → Optionen → Genehmigung → Erlaubnis
* Tierkategorie
* Kategorie Haustiere
* Kategorie Hunde
* spezifischer Artikel

====Beitrag====
Berechtigungen für einzelne Beiträge findet man im "Beitrag" unter dem Tab-Reiter "Berechigungen". Dieser Bildschirm hat drei Aktionen, wie unten gezeigt.

[[Image:j3x_acl_tutorial_article_manager_article_permissions-en.png]]

Auch hier bearbeiten Sie jede Gruppe für sich. Um auf die Berechtigungen zuzugreifen wechseln Sie im Artikel auf den Reiter "Berechtigungen" im oberen Reiter. Über das Drop Down Menü wählen Sie die neue Berechtigung im Anschluss speichern Sie den Beitrag ab.

Beachten Sie, dass die Aktionen Configure, Access Component und Create auf Artikelebene nicht gelten, so dass diese Aktionen nicht berücksichtigt werden. Die Berechtigung zum Anlegen eines Artikels wird auf einer der höheren Ebenen der Hierarchie festgelegt.

===Zugriffsebenen===

Die Zugriffsebenen der 3.x-Serie sind einfach und flexibel. Der folgende Bildschirm zeigt die spezielle Zugriffsebene.
[[Image:j3x_acl_tutorial_viewing_levels-en.png|center]]
Aktivieren Sie einfach das Kontrollkästchen für jede Gruppe, die Sie in diesem Level aufnehmen wollen. Die spezielle Zugriffsebene umfasst die Gruppen Manager, Autor und Superuser. Es beinhaltet auch untergeordnete Gruppen dieser Gruppen. Die Gruppe Administrator ist also enthalten, da es sich um eine Untergruppe der Gruppe Manager handelt. Die Gruppen Editor, Publisher und Shop Suppliers sind enthalten, da es sich um Untergruppen des Autors handelt.

Jedem Objekt im Frontend ist eine Zugriffsebene zugeordnet. Wenn die Ebene öffentlich ist, kann jeder auf dieses Objekt zugreifen. Andernfalls dürfen nur Mitglieder von Gruppen, die dieser Zugriffsebene zugeordnet sind, auf dieses Objekt zugreifen.

Die Zugriffsebenen sind den Menüpunkten und den Modulen zugeordnet. Jede kann nur einer Zugriffsebene zugeordnet werden.

Der folgende Bildschirm zeigt beispielsweise den Bildschirm Menüpunkt bearbeiten mit der Liste der verfügbaren Zugriffsebenen....

[[Image:j3x_acl_tutorial_edit_menu_item_level_dropdown-en.png|center]]

==Standard-ACL-Setup==

Wenn Joomla! installiert ist, werden diese auf die ursprünglichen Standardwerte gesetzt. Wir werden diese Grundeinstellungen besprechen, um die Arbeitsweise der ACL zu verstehen.

===Standardgruppen===

Mit der Version 3.x können Sie Ihre individuellen Gruppen definieren. Wenn Sie die Version 3.x installieren, enthält sie eine Reihe von Standardgruppen, die im Folgenden dargestellt werden, sind die grundlegenden Standardbenutzergruppen. (Zusätzliche Standardbenutzergruppen werden mit Beispieldaten installiert)

[[Image:Screenshot_usergroupsl_acl_J3_tutorial-en.png|center]]

Die Pfeile zeigen die untergeordneten Elternbeziehungen an. Wie vorstehend besprochen, wird diese Berechtigung, wenn Sie eine Berechtigung für eine übergeordnete Gruppe festlegen, automatisch an alle Untergruppen vererbt. Die vererbten und zulässigen Berechtigungen können für eine Untergruppe überschrieben werden. Die Berechtigung Verweigert kann nicht überschrieben werden und verweigert immer eine Aktion für alle Untergruppen.

===Konfiguration===

Joomla! Version 3.x wird mit den gleichen bekannten Backend-Rechten wie die Version 1.5 (EOL) installiert. Mit der Version 3.x können Sie diese jedoch leicht an die Bedürfnisse Ihrer Website anpassen.

Wie bereits besprochen, werden die Berechtigungen für jede Aktion von der obigen Ebene in der Berechtigungshierarchie und von der übergeordneten Gruppe einer Gruppe übernommen. Also, wie funktioniert das? Die oberste Ebene dafür ist der gesamte Standort. Dies wird in der Site->Globale Konfiguration->Berechtigungen eingerichtet, wie unten gezeigt.

[[Image:Screenshot_global_acl_J3_tutorial-en.png]]

Das erste, was man bemerken sollte, sind die zehn Aktionen: Standortlogin, Admin-Login, Offline-Zugriff, Superuser, Access Administration Interface, Erstellen, Löschen, Bearbeiten, Status bearbeiten und Eigenes bearbeiten. Dies sind die Aktionen, die ein Benutzer an einem Objekt in Joomla durchführen kann. Die spezifische Bedeutung jeder Aktion hängt vom Kontext ab. Für das Bild Globale Konfiguration sind sie wie folgt definiert:

Site Login : Login to the front end of the site

;Admin Login : Melden Sie sich am Backend der Website an.

Offline-Zugriff: Melden Sie sich am Frontend der Website an, wenn die Website offline ist (wenn die globale Konfigurationseinstellung "Site Offline" auf Ja gesetzt ist).

Superuser: Gewährt dem Benutzer den Status "Superuser". Benutzer mit dieser Berechtigung dürfen alles auf der Website machen. Nur Benutzer mit dieser Berechtigung können die Einstellungen der globalen Konfiguration ändern. Diese Berechtigungen können nicht eingeschränkt werden. Es ist wichtig zu verstehen, dass, wenn ein Benutzer Mitglied einer Super Admin-Gruppe ist, alle anderen Berechtigungen, die diesem Benutzer zugewiesen sind, irrelevant sind. Der Benutzer kann jede Aktion auf der Website durchführen. Es können jedoch weiterhin Zugriffsebenen zugewiesen werden, um zu steuern, was diese Gruppe auf der Website sieht. (Natürlich kann ein Super-Admin-Benutzer die Zugriffsebenen ändern, wenn er möchte, so dass die Zugriffsebenen nicht vollständig einschränken, was ein Super-Admin-Benutzer sehen kann.)

Zugangskomponente: Öffnen Sie die Bildschirme der Komponentenverwaltung (Benutzerverwaltung, Menüverwaltung, Artikelverwaltung usw.).

;Create : Create new objects (for example, users, menu items, articles, weblinks, and so on)

;Löschen : Löschen eines existienden Objekts

;Ändern : Ändern eines existierenden Objektes

;Ändern eines Objekt Status (Veröffentlicht, nicht Veröffentlicht, Archiviert und Gelöscht)

Eigene Objekte bearbeiten: Bearbeiten Sie Objekte, die Sie erstellt haben.

Each Group for the site has its own slider which is opened by clicking on the group name. In this case (with the sample data installed), we have the standard 7 groups that we had in version 1.5 plus two additional groups called "Shop Suppliers" and "Customer Group". Notice that our groups are set up with the same permissions as they had in version 1.5. Keep in mind that we can change any of these permissions to make the security work the way we want. Let's go through this to see how it works.

* '''Public''' has everything set to "Not set", as shown below.{{-}}[[Image:Screenshot_global_acl_public_J3_tutorial-en.png]]
**This can be a bit confusing. Basically, "Not Set" is the same as "Inherited". Because Public is our top-level group, and because Global Configuration is the top level of the component hierarchy, there is nothing to inherit from. So "Not Set" is used instead of "Inherit".
**The default in this case is for no permissions. So, as you would expect, the Public group has no special permissions. Also, it is important to note that, since nothing is set to Denied, all of these permissions may be overridden by child groups or by lower levels in the permission hierarchy.

* '''Guest''' is a 'child' group of the Public group has everything set to 'Inherited' {{-}}[[Image:Screenshot_global_acl_guest_J3_tutorial-de.png]]
** This is the default 'Guest User Group' in the User Manager options and the Group that (non logged in) visitors to your site are placed in.

* '''Manager''' is a "child" group of the Public group. It has Allowed permissions for everything except Access Component and Super Admin. So a member of this group can do everything in the front and back end of the site except change Global Permissions and Component Options. {{-}}[[Image:Screenshot_global_acl_manager_J3_tutorial-en.png]]

* '''Administrator''' group members inherit all of the Manager permissions and also have Allowed for Access Component. So members of this group by default can access the Options screens for each component. {{-}}[[Image:Screenshot_global_acl_administrator_J3_tutorial-en.png]]

* '''Registered''' is the same a Public except for the Allow permission for the Site Login action. This means that members of the Registered group can login to the site. Since default permissions are inherited, this means that, unless a child group overrides this permission, all child groups of the Registered group will be able to login as well. {{-}}[[Image:Screenshot_global_acl_registered_J3_tutorial-en.png]]

* '''Author''' is a child of the Registered group and inherits its permissions and also adds Create and Edit Own. Since Author, Editor, and Publisher have no back-end permissions, we will discuss them below, when we discuss front-end permissions.{{-}}[[Image:Screenshot_global_acl_author_J3_tutorial-en.png]]

* '''Editor''' is a child of the Authors group and adds the Edit permission. {{-}}[[Image:Screenshot_global_acl_editor_J3_tutorial-de.png]]

* '''Publisher''' is a child of Editor and adds the Edit State permission.{{-}}[[Image:Screenshot_global_acl_publisher_J3_tutorial-de.png]]

* '''Shop Suppliers''' is an example group that is installed if you install the sample data. It is a child group of Author.

* '''Customer Group''' is an example group that is installed if you install the sample data. It is a child group of Registered.

* '''Super Users''' group has the Allow permission for the Super Admin action. Because of this, members of this group have super user permissions throughout the site. They are the only users who can access and edit values on the Global Configuration screen. Users with permission for the Super Admin action have some special characteristics:
:* If a user has Super Admin permissions, no other permissions for this user matter. The user can perform any action on the site.
:* Only Super Admin users can create, edit, or delete other Super Admin users or groups.

There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.

This provides a lot of flexibility. For example, if you wanted Shop Suppliers to be able to have the ability to login to the back end, you could just change their Admin Login value to "Allowed". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherited (or Denied).

It is also important to understand that the ability to have child groups is completely optional. It allows you to save some time when setting up new groups. However, if you like, you can set up all groups to have Public as the parent and not inherit any permissions from a parent group.

===Komponenten-Optionen & Berechtigungen===

Now, let's continue to see how the default back-end permissions for version 2.5 mimic the permissions for version 1.5. The Super Users group in 2.5 is equivalent to the Super Administrator group in 1.5.

Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 2.5 configuration. Let's see how this is accomplished.

If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:

[[Image:screenshot_acl_tutorial_20110111-09-de.png|center|]]
[[Image:screenshot_acl_tutorial_20110111-10-de.png|center|]]

This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.

First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.

Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.

If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.

In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.

It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.

===Frontend Berechtigungen===

Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions. First, let's look at the permissions for Manager, as shown below.
[[Image:screenshot_acl_tutorial_20110111-11a-de.png|center|frame]]
Manager has allowed permission for all actions except Configure. So members of the Manager group can do everything with Articles except open the Options screen.

Now let's look at Administrator, as shown below.
[[Image:screenshot_acl_tutorial_20110111-12a-de.png|center|frame]]
Administrator has Allowed for Configure, so Administrators can edit this Options screen.

Both groups can create, delete, edit, and change the state of articles.

Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set.

Authors only have Create and Edit Own permissions, as shown below.
[[Image:screenshot_acl_tutorial_20110112-07-de.png|center|frame]]
This means that Authors can create articles and can edit articles they have created. They may not delete articles, change the published state of articles, or edit articles created by others.

Editors have the same permissions as Authors with the addition of permission for the Edit action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-08-de.png|center|frame]]
So Editors can edit articles written by anyone.

Publishers can do everything Editors can do plus they have permission for the Edit State action, as shown below.
[[Image:screenshot_acl_tutorial_20110112-09-de.png|center|frame]]
So Publishers can change the published state of an article. The possible states include Published, Unpublished, Archived, and Trashed.

All of these groups have Inherit permission for Configure and Access Component. Remember that Author is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Configure and Access Component, and since Author's permission for these actions is "Inherited", then Author does not have these permissions either. This same permission is passed from Author to Editor and from Editor to Publisher. So, by default, none of these groups are allowed to work with articles in the back end.

It is important to remember that these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.

Beachte auch das in den ursprünglichen Standardwerten keine Berechtigungen auf Verweigert eingestellt sind. Dies ermöglicht in allen Berechtigungsebenen die jeweilige Berechtigung auf Erlaubt einzustellen. Bedenke, wenn eine Aktion auf Verweigert eingestellt ist, das diese Aktion auch in allen untergeordneten Ebenen in der Berechtigungshierarchie verweigert wird. Zum Beispiel, wenn die Seitenameldung für Registered auf Verweigert (anstatt auf Erlaubt) eingestellt wird, kann man Publishers diese Aktion per Berechtigungeinstellung nicht erteilen.

=== Beitrags-Manager & Aktions-Diagramm ===

The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.

[[Image:screenshot_acl_tutorial_20110111-16-de.png|center|]]

* '''Configure''' allows you to view and change the Options for the component.
* '''Access Component''' allows you to navigate to the Article Manager. Without this permission, no other actions are possible.
* '''Create''' allows you to add new articles.
* '''Delete''' allows you to delete trashed articles. Note that the Delete icon only shows in the toolbar when you have the "Select State" filter set to "Trash".
* '''Edit''' allows you to edit existing articles.
* '''Edit State''' allows to you Publish, Unpublish, Archive, or Trash articles.
* '''Edit Own''' is the same as Edit except that it only applies to articles written by you.

==Allowing Guest-Only Access to Menu Items and Modules==

Version 1.6 introduced the ability to create a View Access Level that is only for guests of the site (meaning a user who is not logged in). The example below shows how you can set up this new feature.
''(N.B. Steps 1 to 3 are not needed for Joomla! 3.x as they exist in the default install)''

#Create a new user group called Guest. Make it a child of the Public group as shown below. [[Image:screenshot_acl_tutorial_20110112-01-de.png|center|frame]]
# Create a new access level called Guest and grant only the Guest group access to this level, as shown below.[[Image:screenshot_acl_tutorial_20110112-02-de.png|center|frame]]
# Navigate to User Manager→Options→Component and change the Guest User Group from the default value of "Public" to "Guest", as shown below.
[[Image:screenshot_acl_tutorial_20110112-04-de.png|center|frame]]
Now, if we assign a menu item, module, or other object to the Guest access level, only non-logged in users will have access. For example, if we create a new menu item with access level of Guest, as shown below,
[[Image:screenshot_acl_tutorial_20110112-05-de.png|center|frame]]
this menu item will only be visible to non-logged-in visitors to the site.

If required other user groups like Author can be granted access in the Guest access level, this would allow Authors to view articles in the front end for editing.

'''N.B. Login/logout in front end (''for changing data in session'') to see the change.'''

==Berechtigungen und Gruppenebenen gemeinsam nutzen==

As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.

This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:

* both groups can create new articles only in the History Assignments category.

* only History Teachers (not Assistant History Teachers) can Publish or otherwise have Edit State permission.

This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.

[[Image:Acl example diagram1 20091018-de.png|center|]]

In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.

To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.

Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.

[[Image:Acl example diagram2 20091018-de.png|center|]]

This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.

Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.

==ACL Aktion Berechtigungs-Beispiele==

===Backend Beitrag Administrator===

'''Problem:'''

We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.

'''Lösung:'''

# Create a new group called Article Administrator and make its parent group Public, as shown below.[[Image:screenshot_acl_tutorial_20110112-10-de.png|center|frame]] Because its parent group is Public, it won't have any permissions by default.
# In Users → Access Levels, edit the Special Access level to add the new group. That way they can get access to the back end menu items and modules (This assumes that the modules for the admin menu and quickicons have the Special Access level assigned to them, which is the default.) [[Image:screenshot_acl_tutorial_20110112-11-de.png|center|frame]] By default, the back-end menu items and modules are set to Special access, so if you forget to add the new group to the Special access level, you won't see any modules or menu items when you log in as a user of the new group.
# In Site → Global Configuration → Permissions, click on the Article Administrator group and change the permissions to Allowed for the following actions: Admin Login, Create, Delete, Edit, Edit State, and Edit Own. The screen below shows what will show before you press Save. [[Image:screenshot_acl_tutorial_20110112-12-de.png|center|frame]]After you save, the Calculated Permissions should show as shown below.[[Image:screenshot_acl_tutorial_20110112-13-de.png|center|frame]]Note that the permission for the Access Component is Inherited, which translates to Not Allowed. This is important. This means that this group will only be able to access components if we give the group "Allowed" permission for Access Component. So we only have to change the one component we want to give them access to and don't have to change any settings for the components where we don't want them to have access. If we had a case where we wanted to give a group access to everything except for one component, we could set the default to Allowed and then set the one component to Denied. Also note that we did not give the group Site Login permission, so users in this group will not be able to log into the front end. (If we wanted to allow that, we would just change the permission to Allowed for Site Login.)
# In Article Manager → Options → Permissions, change permissions to Allowed for this group for the Access Component action, as shown below.[[Image:screenshot_acl_tutorial_20110112-14-de.png|center|frame]]All of the other desired permissions are inherited.

That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end. For example, the screen below shows what a user in the Article Manager will see when they login to the back end.[[Image:screenshot_acl_tutorial_20110112-15-de.png|center|frame]]

==ACL Ansicht Zugriffsebenen-Beispiele==

A basic concept of using Access Levels is that all items with the same Access will be viewable by the same group of users. In other words, if two items have the same Access, you can't have one viewable by one user and not viewable by another user. On the other hand, it is easy to have one Group view any number of items with different Access levels.

Similarly, each Group has exactly the same combination of Access levels, but one User can be a member of more than one group. Depending on the situation, you may want to have users only in one Group or you may need to have a User in more than one Group.

This means that we may need to group our items so that items so that all items in a group have the same level of sensitivity. Here are some examples.

===Hierarchisches Beispiel===
In this example, Access levels are hierarchical, for example, like government security clearance codes. Say for example we have the following sets of classified documents: Classified, Secret, and Top Secret. Users have corresponding clearence codes. Users with Classified clearance can only see Classified documents and cannot see Secret or Top Secret. Users with Secret clearance can see Classified and Secret documents but not Top Secret. Users with Top Secret can see all documents.

In this case, you would create three Access levels: Classified, Secret, and Top Secret and the same three Groups. Users would only be members of one group, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| C1, C2, C3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Classified
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| S1, S2, S3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| TS1, TS2, TS3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Top Secret
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Classified, Secret, Top Secret

|}

In this case, all users are in exactly one group, but some groups have access to more than one Access Level of items. In other words, we have a one-to-one relationship between users and groups, but a one-to-many relationship between Groups and Access Levels.

===Teamsicherheit Beispiel===

Another possible use case is a set of non-hierarchical teams. Let's say we have three teams, T1, T2, and T3. Some users are only on one team, but others might be on two or more teams. In this case, we could set up our Access Levels and Groups by team. Documents for each team have the access level for that team, and the Group for the team has only the one access level. When a User is on more than one team, they get added to the group for each team, as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Benutzer
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Beschreibung
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Gruppe
| style="border:0.0007in solid #000000;padding:0.0382in;"| Zugriffsebenen

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 1 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 2 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team 3 Mitglied
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T3

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| U1-2-3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Mitglied aus Team 1, 2 und 3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| T1,T2, T3
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| T1, T2, T3

|}

===Hybrid Example===

In a real-world situation, you might have a combination of these two arrangements. Say for example we have Managers and Staff. Staff can only see Staff documents and Managers can see Manager and Staff documents. Both types of users can be assigned to teams as well, in which case they can see all of the documents for that team. In addition, say that Managers can access some, but not all, team documents. Staff can only access team documents if they are members of that team.

In this example, we could set up the following Access Levels:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Access Level
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Description
| style="border:0.0007in solid #000000;padding:0.0382in;"| Groups

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team manager documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Non-team staff documents
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team1 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team1 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team1, Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Sensitive Team2 documents (no access outside team)
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2-Manager
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Team2 documents that can be accessed by all managers
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Team2, Manager

|}

Then, users could be assigned to groups as follows:

{| style="border-spacing:0;"
| style="border-top:0.0007in solid #000000;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| User Type
| style="border:0.0007in solid #000000;padding:0.0382in;"| Group

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on no teams
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on team 1
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Manager on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Manager, Team1, Team2

|-
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:none;padding:0.0382in;"| Staff on teams 1 and 2
| style="border-top:none;border-bottom:0.0007in solid #000000;border-left:0.0007in solid #000000;border-right:0.0007in solid #000000;padding:0.0382in;"| Staff, Team1, Team2

|}

<noinclude>
[[Category:Joomla! 1.6]]
[[Category:Joomla! 2.5]]
[[Category:Joomla! 3.x/de]]
[[Category:Tutorials/de]]
[[Category:Access Control/de]]
[[Category:Access Management]]
</noinclude>