Handleiding voor functioneel beheerders TU/e-website. Bas v.d. Wiel. 7 juli Inleiding 3

Transcriptie

1 Handleiding voor functioneel beheerders TU/e-website Bas v.d. Wiel 7 juli 2010 Inhoudsopgave Inhoudsopgave 1 1 Inleiding 3 2 Rechtenstructuur backend Alles is een pagina behalve de bestandenboom Owner, Group, Everybody Soorten rechten Permissiemodel TU/e-site Aanwezige functionele rollen Rechten toekennen aan een nieuwe gebruiker Gebruikersaccount simuleren Index 15 1

2

3 HOOFDSTUK 1 Inleiding Dit document omschrijft alle technische aspecten van de TU/e-website die noodzakelijk zijn om goed functioneel beheer uit te voeren. Dit is een levend document dat gedurende de eerste ontwikkelstadia van de TU/e-website nog regelmatig zal veranderen. Zorg er dan ook voor altijd de actuele versie te gebruiken! 3

4

5 HOOFDSTUK 2 Rechtenstructuur backend TYPO3 heeft voor de basisprincipes van toegangsbeheer een bladzijde uit het ontwerp van UNIX geleend. Dit betekent dat iedereen die enige kennis van UNIX heeft, veel zal herkennen in de manier waarop toegangsrechten in de backend van TYPO3 worden toegekend. Voor wie deze achtergrond niet heeft, volgt hier een korte toelichting. 2.1 Alles is een pagina TYPO3 maakt voor vrijwel alle vormen van informatieopslag gebruik van de paginaboom, vaak ook wanneer de opgeslagen objecten conceptueel helemaal geen pagina in traditionele betekenis van bladzijde zijn. Voor succesvol rechtenbeheer is het belangrijk te beseffen dat alle knooppunten in de paginaboom uiteindelijk, in de onderliggende database, allemaal records van het type page zijn 1. Dus ook alle mapjes (sysfolders), CCT-pagina s, shortcuts, redirects, mountpoints etc. Het enige verschil zit m in de weergave van afwijkende ikoontjes in de zichtbare boomstructuur. Elke pagina heeft een vaste verzameling van tientallen afzonderlijke eigenschappen. Enerzijds worden die door TYPO3 zelf automatisch aangemaakt en beheerd, anderzijds zijn er eigenschappen, zoals de naam, die beheerders en redacteuren zelf kunnen kiezen. Om rechtenbeheer gestalte te kunnen geven, is het noodzakelijk dat TYPO3 van elke individuele pagina kan beoordelen wie er precies welke handelingen op mag uitvoeren. Om dat te kunnen doen, houdt TYPO3 van elke pagina onder meer de volgende eigenschappen bij: Eigenaar Backend-gebruikersgroep Permissies van de eigenaar Permissies van de backend-gebruikersgroep 1 Het principe alles is een pagina komt rechtstreeks uit UNIX, waar alles zich als een bestand gedraagt. 5

6 2. RECHTENSTRUCTUUR BACKEND Permissies voor alle andere gebruikers Door bovenstaande eigenschappen (met name de gebruikersgroepen) slim te combineren, kun je verrassend complexe toegangscontrole toepassen zonder per pagina grote hoeveelheden beveiligingsinformatie te hoeven administreren behalve de bestandenboom Van oudsher maakt TYPO3 onderscheid tussen pagina s in de database en fysieke bestanden op de schijf van de server. Gelukkig voor ons zijn zowel pagina s als bestanden in boomstructuren geordend en kunnen de rechten daarop volledig parallel lopen. In het geval van bestanden geldt dat er alleen sprake is van het al dan niet hebben van schrijftoegang 2. De schrijftoegang wordt geregeld via file mounts. Backendgebruikers krijgen d.m.v. file mounts een startpunt ergens in de bestandenboom toegewezen en hebben schrijftoegang tot die plek en alle mappen erbinnen. 2.3 Owner, Group, Everybody Vanuit de beheerder bezien heb je per individuele pagina te maken met dezelfde vaste combinatie van: Een individuele backendgebruiker als eigenaar; Een verzameling backendgebruikers in een enkele backendgroep; Everybody oftewel alle andere backendgebruikers die niet in één van de twee bovenstaande categorieën passen; In de backend van TYPO3 zelf is dit overzichtelijk weergegeven in de Access-module 3 (figuur 2.1). In deze afbeelding is duidelijk de huidige eigenaar (martijn) te zien, de toegewezen backendgroep (access corporate), en een permissietabel met daarin drie rijen voor Owner, Group en Everybody. 2.4 Soorten rechten In figuur 2.1 is niet alleen te zien wie rechten heeft, maar ook precies welke rechten dat zijn. In de praktijk betekent elk van de getoonde opties het volgende: Show page De betreffende pagina is zichtbaar in de paginaboomweergave in de backend, en niet meer dan dat. Wie een pagina mag zien, kan er ook op de TYPO3-interne manier naar linken. Zoals te zien in de figuur hebben zowel Owner, Group als Everybody dit recht op de geselecteerde pagina. Dit betekent dat letterlijk alle backendgebruikers deze pagina in de boom kunnen zien. 2 Leestoegang heeft sowieso iedereen omdat bestanden anders niet aan onze anoniem toegankelijke frontend gebruikt zouden kunnen worden. 3 De Access-module is alleen toegankelijk voor gebruikers met adminrechten. 6

7 2.4. Soorten rechten Figuur 2.1: Weergave van de verschillende toegangsrechten in TYPO3. Edit content Wie dit recht heeft, mag binnen deze pagina nieuwe content-elementen aanmaken en bestaande content op deze pagina wijzigen. In het voorbeeld is dit recht voorbehouden aan Owner en Group. Wie dus niet ofwel de Owner zelf is, ofwel lid is van de backendgroep access corporate, mag de pagina wel zien maar niet de aanwezige content aanpassen. Edit page Wie dit recht heeft, mag de redactionele eigenschappen van deze pagina zelf wijzigen. Zaken als de titel, metadata, verbergen of niet etc. zijn toegestaan. In het voorbeeld geldt ook hier weer dat je ofwel Owner moet zijn, of lid van access corporate om dit recht te hebben. Dit recht is nadrukkelijk anders dan Edit content maar deze worden in de praktijk meestal toch samen toegekend zodat redacteuren zowel de pagina zelf als de inhoud ervan kunnen wijzigen. Delete page Het recht om de pagina in kwestie te verwijderen 4. New pages Gebruikers met dit recht mogen zelf nieuwe pagina s aanmaken op het niveau direct onder de pagina in kwestie. De installatie van TYPO3 bij de TU/e is zo ingericht dat die nieuwe pagina s automatisch precies dezelfde eigenaar, groep en rechten krijgen als de bovenliggende pagina. Alleen admins kunnen deze rechten vervolgens nog veranderen. Buiten rechten op pagina s kent TYPO3 ook nog instelingen voor Access lists en TSConfig. Dit zijn elkaar aanvullende mechanismen die onafhankelijk van de pagina s per gebrui- 4 TYPO3 verwijdert in de prakijk nooit iets onherroepelijk. Er wordt alleen een vinkje deleted=1 geplaatst in de database. Dit maakt het (beperkt) mogelijk voor admins en databasebeheerders om verwijderde pagina s terug te halen. 7

8 2. RECHTENSTRUCTUUR BACKEND ker of groep bepalen hoe de gebruikersinterface van de backend eruit ziet, welke functionaliteiten al dan niet beschikbaar zijn, en welke velden in de onderliggende database getoond danwel gewijzigd mogen worden. In het dagelijks beheer is het zelden of nooit nodig om deze rechten aan te passen omdat ze eigenlijk alleen aan de orde komen bij het toevoegen van nieuwe functionaliteit. 2.5 Permissiemodel TU/e-site De instrumenten die TYPO3 biedt, maken permissiebeheer extreem flexibel. Om er toch greep op te houden, is voor de TU/e specifiek een permissiemodel ontworpen. In het kort komt dat erop neer dat backendgebruikers vrijwel zonder rechten beginnen. De rechten die ze nodig hebben (niet minder dan dat, maar ook niet meer!), krijgen ze vervolgens via hun lidmaatschap van een aantal backendgroepen. Omgekeerd volgt hieruit dat de functionaliteit voor het toekennen van rechten aan individuen nadrukkelijk niet gebruikt mag worden. Gebeurt dit wel, dan kan dit tot problemen leiden door onverwachte combinaties van instellingen 5. Soorten backendgroepen Het rechtenbeheer binnen de TU/e-site is gefundeerd op een drietal soorten van backendgroepen: Accessgroepen Lidmaatschap van deze groepen bepaalt op welke delen van de paginaboom een gebruiker schrijfrechten heeft (alle gebruikers hebben leesrechten op de volledige contentboom 6 ). Wie bijvoorbeeld lid is van de backendgroep access BWK, heeft schrijfrechten op de pagina s van de faculteit Bouwkunde. De naam van een Accessgroep begint altijd met access en heeft een voor beheerders begrijpelijk achtervoegsel zoals de afkorting van een faculteit of een site-onderdeel zoals studeren. Toegang tot de bestandenboom wordt ook via de accessgroepen geregeld. Functionele groepen Direct na het aanmaken van een gebruikersaccount heeft deze nog geen rechten op de paginaboom en er is ook geen functionaliteit beschikbaar in de gebruikersinterface. Door gebruikers lid te maken van functionele groepen ontsluit je specifieke backendfuncties voor die persoon. Zo kunnen leden van de groep func filelist gebruik maken van de traditionele bestandenstructuur zoals die van oudsher in TYPO3 zit, terwijl leden van func dam de nieuwe Digital Asset Manager te zien krijgen. Functionele groepen beginnen altijd met het voorvoegsel func en hebben een achtervoegsel dat hun functie aangeeft. Rollen Omdat grote groepen gebruikers vaak dezelfde functionaliteiten nodig hebben, afhankelijk van hun functie of rol binnen de content-organisatie, zijn veelvoorkomende combinaties van lidmaatschappen van verschillende func -groepen bij elkaar gebracht 5 Een ander gevolg van het exclusieve gebruik van backendgroepen is dat de Owner helemaal irrelevant is geworden binnen de context van rechtenbeheer. Deze mág gewijzigd worden, maar het heeft geen enkel effect op toegangsrechten. 6 Er zijn ook pagina s die geen contentbeheer behoeven. Deze vallen buiten de rechten van reguliere redacteuren. 8

9 2.6. Aanwezige functionele rollen Redacteur access_corporate role_editor func_cctcontent func_contacts func_dam func_rtebasic role_defaults Figuur 2.2: Schematische weergave van de groepslidmaatschapen van backendgebruiker Redacteur. in rollen. Deze groepen hebben allemaal het voorvoegsel role en een achtervoegsel dat de functie van de leden binnen de content-organisatie van de site aangeeft. Zo is er een role editor, waar alle redacteuren lid van zijn. De groep role editor heeft zelf als subgroepen bijvoorbeeld func cctcontent, func contacts, func dam, role defaults en func rtebasic (zie ook figuur 2.2). In figuur 2.2 is een schematische weergave te zien van de groepslidmaatschappen van een fictieve backendgebruiker Redacteur. Via role editor is deze gebruiker indirect lid van vijf functionele groepen en één accessgroep (corporate). Hieruit volgt dat deze persoon in de backend alle standaardgereedschappen van een reguliere redacteur heeft, plus schrijftoegang tot de corporate pagina s van de universiteit. 2.6 Aanwezige functionele rollen [LET OP: DIT DEEL MOET NOG DOOR PROJECTGROEP!] Editor De rol Editor is die van een reguliere redacteur die (delen van) de site inhoudelijk mag wijzigen. Hij of zij krijgt deze rol door lidmaatschap van de backendgroep role editor. Functioneel mag deze rol het volgende: De Rich Text Editor heeft een minimale basisconfiguratie; Geen gebruik van workspaces; Toegang tot het maken van alle soorten CCT-contenttypes; Mogelijkheid contactpersonen te beheren; Toegang tot bestanden via de DAM-module; 9

10 2. RECHTENSTRUCTUUR BACKEND Figuur 2.3: Backendgebruikers kunnen alleen worden toegevoegd aan de root van de site. 2.7 Rechten toekennen aan een nieuwe gebruiker De voorgaande delen van dit hoofdstuk waren nogal theoretisch. In dit deel een praktisch voorbeeld dat stap voor stap illustreert hoe een nieuwe webredacteur voor de faculteit Scheikundige Technologie toegang krijgt. Hoewel dit voorbeeld een faculteit veronderstelt, geldt het principe voor alle onderdelen van de site. Deze stappen werken alleen wanneer de beheerder met adminrechten is ingelogd. 1. Selecteer de List-module in het linkermenu; 2. Selecteer de root van de website (wereldbolletje, zie ook figuur 2.3); 3. Maak op dit niveau een nieuw record van het type Backend User aan; 4. De username is in principe 7 identiek aan de Windows-usercode van de persoon, password mag willekeurig gekozen worden 8. Zorg bij persoonsgebonden users dat het adres klopt. 5. Maak de gebruiker lid van tenminste één rol (role editor in figuur 2.4); 6. Maak de gebruiker lid van teminste één accessgroep; 7 Accounts die niet in Active Directory voorkomen, kunnen wel bestaan maar de TYPO3-beheerorganisatie moet deze zelf administreren. 8 Zodra de koppeling met Active Directory gereed is, wordt het TYPO3-interne password bij Windowsaccounts niet meer gebruikt. Bij TYPO3-exclusieve accounts wél, dus zorg dat dit sterke wachtwoorden zijn! 10

11 2.7. Rechten toekennen aan een nieuwe gebruiker Figuur 2.4: Bij het aanmaken van een nieuwe gebruiker hoeft alleen de tab General te worden gevuld. 11

12 2. RECHTENSTRUCTUUR BACKEND De beheerder dient een aantal zaken in het oog te houden bij het aanmaken van nieuwe gebruikers: Accounts buiten Active Directory Dit kan wel, maar is alleen raadzaam voor accounts waarvan we zeker weten dat ze nooit buiten de context van TYPO3 gebruikt zullen worden. Een niet aan Active Directory gebonden admingebruiker voor geval van calamiteiten is een goed voorbeeld van een TYPO3-exclusieve user. In te vullen eigenschappen Bij een reguliere redacteur hoeven alleen de eigenschappen username, password, groepen, naam, en taalvoorkeur te worden ingevuld. De inhoud van alle overige velden wordt overgenomen uit de groepslidmaatschappen. Alle overige tabbladen die in figuur 2.4 zichtbaar zijn, hebben correcte standaardinstellingen. Tijdelijke accounts Wanneer een medewerker uit dienst treedt, vervalt automatisch de Windowsaccount en daarmee ook de mogelijkheid om in de backend van TYPO3 in te loggen. Bij accounts die voor TYPO3 tijdelijk zijn, maar voor Active Directory niet, moeten we zelf een afloopdatum meegeven. Dit gebeurt bijvoorbeeld voor studentassistenten die tijdelijk aan projecten zijn verbonden of redacteuren die van functie veranderen. 2.8 Gebruikersaccount simuleren TYPO3 biedt beheerders van oudsher de mogelijkheid om de werkomgeving van andere accounts in de backend te simuleren. Dit kan handig zijn bij het controleren of rechten correct zijn toegekend. Deze mogelijkheid is in de backend toegankelijk via de module User Admin onder Admin tools (zie figuur 2.5). In de lijst met gebruikersaccounts kies je voor het ikoontje uiterst rechts naast een account (switch back mode) om de betreffende gebruikersaccount te simuleren. Deze modus is praktischer dan de Change-to-mode, die een volledige login op naam van de gekozen gebruiker doorvoert. De switch back modus maakt het eenvoudig mogelijk om uit de gesimuleerde omgeving terug te keren naar de eigen admin-account. 12

13 2.8. Gebruikersaccount simuleren Figuur 2.5: De optie om accounts te simuleren is toegankelijk via User Admin. 13

14

15 Index Access lists, 7 Active Directory, 12 Backendgroepen Accessgroep, 8 Functionele groep, 8 Rol, 8 CCT-content, 9 Digital Asset Manager, 9 Everybody, 6 file mount, 6 Group, 6 Owner, 6 pagina, 5 Permissies Delete page, 7 Edit content, 7 Edit page, 7 New pages, 7 Show page, 6 site root, 10 tijdelijke account, 12 TSConfig, 7 Windows-usercode, 10 workspaces, 9 15