Gebruikers en gebruikers groepen in Joomla

1. De basis

1.1 Waarom gebruikers belangrijk zijn

Zonder goed gebruikersbeheer ziet iedere bezoeker dezelfde website. Je kunt geen beheerderstoegang beperken, geen content beschermen, geen ledenomgeving maken en geen onderscheid maken tussen redacteuren en bezoekers. Beveiligingsproblemen liggen dan al snel op de loer.

Met Joomla's gebruikerssysteem kun je publieke, leden-only en staff-only content naast elkaar gebruiken. Je kunt specifieke taken aan specifieke mensen geven, zelfregistratie en wachtwoordherstel aanbieden, en multi-factor authenticatie inschakelen.

1.2 De drie pijlers

Joomla verdeelt gebruikersbeheer in drie onafhankelijke bouwstenen. Als je deze drie pijlers begrijpt, begrijp je de kern van het hele systeem:

De rest van dit artikel gaat over hoe deze drie pijlers samenwerken.

1.3 Waar vind ik gebruikers?

In de Joomla 6-backend beheer je het gebruikerssysteem via het menu Gebruikers:

Gebruikers → Beheren          (alle gebruikersaccounts)
Gebruikers → Groepen          (gebruikersgroepen)
Gebruikers → Toegangsniveaus  (weergavetoegangsniveaus)
Gebruikers → Velden           (aangepaste profielvelden)
Gebruikers → Gebruikersnotities (interne notities per gebruiker)

Rechten staan op een andere plek: het tabblad Rechten in Algemene instellingen, in de opties van elke component, en in categorieën en items.

3. Gebruikersgroepen

3.1 Wat is een gebruikersgroep?

Een gebruikersgroep is een gelabelde verzameling gebruikers. De groep zelf bevat nog geen rechten. Rechten worden later aan de groep toegekend via de ACL.

Drie regels om te onthouden:

• Een gebruiker kan tegelijk tot meerdere groepen behoren.
• Groepen kunnen genest zijn in een ouder-kindstructuur.
• Een childgroep erft de rechten van de parentgroep, tenzij je ze overschrijft.

De groep is het belangrijkste ACL-concept. Zet je groepen goed neer, dan valt de rest van het systeem op zijn plek.

3.2 De standaardgroepen in Joomla 6

Standaard levert Joomla deze groepsstructuur mee:

Public
 ├── Guest
 ├── Manager
 │    └── Administrator
 ├── Registered
 │    └── Author
 │         └── Editor
 │              └── Publisher
 └── Super Users

Elke groep heeft een specifieke rol:

• Public: iedere bezoeker, ingelogd of niet.
• Guest: expliciet niet ingelogd.
• Registered: elke ingelogde frontendgebruiker.
• Author, Editor, Publisher: oplopende contentrechten op de frontend.
• Manager, Administrator: backendtoegang met oplopende bevoegdheden.
• Super Users: onbeperkt, kan alles overal.

3.3 Overerving in de praktijk

Een groep erft rechten, geen gebruikers. Dit zorgt vaak voor verwarring. Een voorbeeld:

• Een gebruiker toevoegen aan Editor voegt die gebruiker niet automatisch toe aan Author.
• Maar de groep Editor erft de rechten van Author, dus een Editor kan alles wat een Author kan.
• Als je "Verwijderen" op Geweigerd zet voor Editor, wordt de overerving voor die ene actie doorbroken.

Kort gezegd: overerving loopt naar beneden door de groepsstructuur, maar gebruikerstoewijzingen gelden alleen voor de gekozen groep.

3.4 Een aangepaste groep aanmaken

Ga naar Gebruikers → Groepen → Nieuw. Er zijn maar twee verplichte velden:

De keuze van de parent bepaalt met welke rechten je begint. Kies de dichtstbijzijnde match, zodat je later minder hoeft te overschrijven.

Veelgebruikte aangepaste groepen in de praktijk:

• Leden (parent: Registered): betalende leden van een community.
• Moderators (parent: Editor): forum- of commentmoderatie.
• Sitebeheerders (parent: Administrator): backendtoegang zonder Super User-rechten.

3.5 Many-to-many in actie

Eén gebruiker kan tegelijk in meerdere groepen zitten. Voorbeeld: Jane is Newsroom Editor voor content en Forum Moderator.

• Open Gebruikers → Beheren → Jane → Toegewezen gebruikersgroepen.
• Vink beide groepen aan.
• Jane krijgt nu de combinatie van de rechten van beide groepen.

Als de ene groep een actie Toestaat en een andere groep niet, wint Toestaan, tenzij een derde groep dezelfde actie expliciet Weigert. De regel "Weigeren wint altijd" maakt deze combinatie veilig.

5. Rechten (ACL)

5.1 Van zichtbaarheid naar actie

Toegangsniveaus bepalen wie iets kan zien. Rechten bepalen wie iets kan doen. De Joomla ACL beantwoordt vragen zoals:

• Mag deze groep artikelen aanmaken?
• Mogen ze alleen hun eigen artikelen bewerken, of elk artikel?
• Mogen ze publiceren?
• Mogen ze artikelen verwijderen binnen een specifieke categorie?
• Mogen ze überhaupt inloggen op de backend?

5.2 De standaard actieset

De meeste componenten tonen dezelfde acties. Sommige voegen daar eigen acties aan toe:

5.3 De vier rechtentoestanden

Voor elke combinatie van actie en groep kies je één van deze toestanden:

Na opslaan toont Joomla het berekende resultaat naast je instelling: Toegestaan, Niet toegestaan of het gevreesde Niet toegestaan (vergrendeld).

5.4 De rechtenhiërarchie

Rechten lopen via vier niveaus, waarbij elk niveau het niveau erboven kan overschrijven:

Algemene instellingen
 └── Componentopties (bijvoorbeeld com_content)
       └── Categorierechten
             └── Itemrechten (per artikel)

De praktische aanpak is:

• Zet een basislijn in Algemene instellingen.
• Versoepel of verscherp per component.
• Overschrijf per categorie voor onderdelen zoals "Persberichten, alleen staff".
• Gebruik het itemniveau alleen als laatste redmiddel.

5.5 De Deny-valkuil

De belangrijkste ACL-regel in Joomla is kort: Weigeren wint altijd.

Als een groep in Algemene instellingen op Geweigerd staat, kan geen Toestaan lager in de structuur dat herstellen. De lagere niveaus tonen letterlijk Niet toegestaan (vergrendeld) en maken de dropdown grijs.

Praktische richtlijnen:

1. Gebruik standaard overal Overgenomen.
2. Gebruik Toegestaan om rechten naar beneden toe te verlenen.
3. Gebruik Geweigerd alleen wanneer je wilt dat de regel permanent en absoluut is, meestal op globaal niveau voor veiligheid.
4. Als je een recht kwijt bent en niet snapt waarom, loop dan omhoog in de boom en zoek naar een Weigering.

5.6 Algemene instellingen: tabblad Rechten

Open Systeem → Algemene instellingen → Rechten. Dit bepaalt de standaard voor de hele website. Een typische basislijn ziet er zo uit:

Zet deze laag goed neer, en ongeveer 80% van de ACL-"vreemdheden" verdwijnt.

5.7 Rechten op componentniveau

Elke component heeft een knop Opties in de toolbar met een eigen tabblad Rechten. Voor com_content (Artikelen) kun je bijvoorbeeld:

• Aanmaken aanscherpen, zodat alleen Authors en hoger artikelen kunnen schrijven.
• Status bewerken toestaan voor Publishers, maar niet voor Authors en Editors.
• Toegang tot beheerinterface geven aan een groep Newsroom zonder ze Manager te maken.

Hier vindt de meeste dagelijkse ACL-configuratie plaats.

5.8 Rechten op categorieniveau

Open een categorie en kies het tabblad Rechten. Hier verfijn je rechten voor een specifieke sectie:

• Leden mogen artikelen Aanmaken in de categorie Ledenverhalen.
• Leden mogen Eigen items bewerken, maar niet Bewerken van items van anderen.
• Newsroom mag Status bewerken in Persberichten, maar nergens anders.

Categorierechten zijn het juiste gereedschap voor redactionele workflows met meerdere teams. Je kunt newsroom, blog en ledencontent scheiden zonder iemand globaal "Bewerken" te geven.

5.9 Rechten op itemniveau

Elk artikel, en veel andere items, heeft een eigen tabblad Rechten. Gebruik dit spaarzaam: zet één gevoelig artikel dicht, of open één item als uitzondering voor een bredere groep. Als je veel individuele items moet overschrijven, is een nieuwe categorie meestal de betere oplossing.

5.10 Praktijkvoorbeeld: Newsroom Editors

Het doel is een groep Newsroom Editors die de categorie Persberichten volledig kan beheren, en verder niets. De stappen:

1. Groep: maak Newsroom Editors aan met parent Registered.
2. Algemene instellingen → Rechten: geef Newsroom Editors zowel Site Login als Administrator Login als Toegestaan.
3. Artikelopties → Rechten: geef Newsroom Editors Toegang tot beheerinterface als Toegestaan. Laat de rest op Overgenomen.
4. Categorie Persberichten → Rechten: geef Newsroom Editors Aanmaken, Bewerken, Status bewerken en Verwijderen als Toegestaan.
5. Alle andere categorieën: laat alles overgenomen. De newsroom kan andere categorieën zien, maar niet aanpassen.

Klaar. Geen Super User, geen overbodige privileges.

7. Multi-factor authenticatie en beveiliging

7.1 Native MFA in Joomla 6

Joomla 4 introduceerde native multi-factor authenticatie, en Joomla 6 verfijnt dit verder. De ondersteunde methoden zijn:

• TOTP: tijdgebaseerde eenmalige wachtwoorden, gebruikt door Google Authenticator en vergelijkbare apps.
• WebAuthn: passkeys en hardwarebeveiligingssleutels.
• YubiKey: een hardwaretoken.
• E-mail OTP: een code die per e-mail wordt verzonden.
• Vaste code: alleen nuttig voor testen.

Elke gebruiker kan MFA zelf inschakelen, of je kunt het afdwingen voor volledige groepen via de plugin Captive MFA. Back-upcodes worden automatisch gegenereerd, en je moet gebruikers altijd eraan herinneren die veilig op te slaan.

7.2 De captive login-flow

Joomla gebruikt een captive model: een ingelogde gebruiker die nog niet voldoet aan de MFA-eis blijft vast op de MFA-instelpagina totdat dit is afgerond. De gebruiker kan niet weg navigeren.

Je configureert dit via Gebruikers → Beheren → Opties → Multi-factor authenticatie. Het is een krachtige manier om een organisatiebrede beveiligingsregel af te dwingen zonder één regel code te schrijven.

7.3 Nuttige gebruikersgerelateerde plugins

Verschillende plugins breiden Joomla's gebruikerssysteem uit. Je vindt ze onder Systeem → Beheren → Plugins, gefilterd op Gebruiker en Authenticatie:

• User - Joomla: core profilsynchronisatie, schakel deze niet uit.
• User - Profile: extra profielvelden, zoals geboortedatum of akkoord met voorwaarden. Je kunt hiervoor ook Joomla's aangepaste velden bij Gebruikers gebruiken.
• User - Contact Creator: maakt automatisch een Contact-item aan voor elke nieuwe gebruiker. Synchroniseert gegevens niet meer nadat gebruiker/contact zijn aangemaakt.
• Authentication - Joomla / LDAP / Cookie: verschillende loginmethoden.
• Multi-factor Authentication - ...: één plugin per MFA-methode.

Voor aangepaste logica kun je je eigen User-plugin schrijven die reageert op events zoals onUserBeforeSave, onUserAfterSave, onUserLogin en onUserLogout.

7.4 Aangepaste profielvelden

Er zijn twee manieren om aangepaste profieldata aan gebruikers toe te voegen:

1. Aangepaste velden onder Gebruikers → Velden: een point-and-click manier om tekst, lijst, kalender, media en andere veldtypes toe te voegen. Elk veld kan een eigen toegangsniveau hebben, zodat alleen specifieke groepen het zien.
2. User Profile-plugin: een codegedreven aanpak, ideaal voor verplichte gestructureerde data zoals geboortedatum of akkoord met voorwaarden.

In Joomla 6 zijn aangepaste velden meestal de juiste keuze. Gebruik de plugin alleen wanneer je server-side validatielogica nodig hebt.

9. Veelgemaakte fouten en valkuilen

9.1 Weigeren is definitief

Een Weigering in Algemene instellingen kan lager in de structuur niet meer worden Toegestaan. De lagere niveaus tonen Niet toegestaan (vergrendeld) en maken de dropdown grijs. Gebruik Weigeren alleen wanneer je een regel absoluut wilt maken.

9.2 Groepsovererving verwarren met gebruikersovererving

Overerving geldt voor rechten, niet voor gebruikers. Een gebruiker toevoegen aan Editor voegt die gebruiker niet ook toe aan Author. Maar de Editor-groep erft wel de rechten van Author voor elke actie.

9.3 Super User te vaak gebruiken

Super User overschrijft elke Weigering en elke beperking. Het is verleidelijk om Super User te geven "om het werkend te krijgen", maar daarmee haal je alle vangrails weg. Beperk de Super Users-groep tot één of twee volledig vertrouwde personen.

9.4 Super Users vergeten in een aangepast toegangsniveau

Wanneer je een nieuw toegangsniveau maakt, neem dan altijd Super Users op in de groepslijst. Anders kun je jezelf buitensluiten van content die alleen je aangepaste groep mag zien.

9.5 Guest en Public door elkaar halen

Deze twee lijken op elkaar, maar betekenen iets anders:

• Public: iedereen, ingelogd of niet.
• Guest: expliciet niet ingelogd.

Een Public-module wordt aan alle bezoekers getoond. Een Guest-module verdwijnt zodra een gebruiker inlogt.

9.6 Een gebruiker verwijderen behoudt de content

Als je een gebruiker verwijdert, blijven de artikelen, contacten en andere items in de database staan met een created_by-veld dat naar een niet-bestaande gebruiker verwijst. Wijs auteurschap eerst opnieuw toe en verwijder daarna het account.

9.7 Public opnemen in aangepaste toegangsniveaus

Als je de Public-groep aanvinkt in een aangepast toegangsniveau, wordt dat niveau in feite gelijk aan "Public". Iedereen kan de content zien, en daarmee is het doel van het aangepaste niveau weg.

9.8 Rebuild overslaan na directe databasewijzigingen

Als je regels direct in #__assets bulk-bewerkt of gebruikers via SQL importeert, moet je mogelijk de assetboom opnieuw opbouwen en de cache legen. Anders blijft de interface oude resultaten tonen.

11. Samenvatting

In Joomla is het gebruikerssysteem veel meer dan een loginformulier. Het beheert bijna elke laag van de website:

• Identiteit: wie kan inloggen en hoe.
• Zichtbaarheid: welke content aan wie wordt getoond.
• Bevoegdheid: wie mag aanmaken, bewerken, publiceren en verwijderen.
• Beveiliging: multi-factor authenticatie en groepsgebaseerde hardening.
• Workflow: redactionele teams met duidelijke grenzen.
• Developer-integratie: een gedeelde API voor gebruikers, groepen en ACL.
• Compliance: AVG, audittrails en toegangscontrole.

Een goed gepland gebruikerssysteem maakt een Joomla-website veilig, voorspelbaar en jarenlang makkelijk te onderhouden. Een slechte inrichting leidt tot beveiligingsrisico's, gefrustreerde redacteuren en ACL-puzzels die steeds groter worden.

Als je een nieuwe Joomla-site plant, migreert vanaf een oudere versie of een rechtenknoop op een bestaande site wilt oplossen, kijk dan eerst naar gebruikersgroepen, toegangsniveaus en rechten. Beheer je die drie pijlers, dan werkt Joomla met je mee in plaats van tegen je.