Liam van den Akker

Ik ben

Over mij

Ontdek meer over mijn achtergrond, passies en de weg die ik bewandel als developer.

Liam van den Akker

Liam van den Akker

Student Software Developer

Persoonlijke Gegevens

Geboortedatum 7 November 2006
Leeftijd 19
Opleiding Software Developer MBO 4
Telefoon +31 6 13970577
Email liamvandenakker@gmail.com
Woonplaats Maastricht, Nederland

Biografie

Mijn naam is Liam van den Akker, geboren in Maastricht, Limburg, Nederland. Momenteel ben ik 19 jaar oud en volg ik de opleiding mbo 4 Software Developer aan het Vista College in Maastricht, in een versneld traject. Ik verwacht binnenkort af te studeren na het succesvol afronden van mijn examens en stageperiode.

Tijdens mijn opleiding heb ik gewerkt met verschillende technieken en programmeertalen, waaronder HTML, CSS, PHP en hier en daar wat JavaScript. In mijn derde leerjaar ben ik gestart met een stage bij Bergstein Digital B.V., waar ik veel ervaring heb opgedaan met C#, Blazor en .NET. Binnen dit bedrijf werk ik in een Scrum-omgeving met wekelijkse meetings, feedbackmomenten en een sprintbord via Teamwork. Daarnaast heb ik hier leren werken met versiebeheer via Git en Azure DevOps.

Technologie en softwareontwikkeling zijn voor mij meer dan alleen een studie; het is iets waar ik oprecht enthousiast van word. Ik vind het interessant om te zien hoe een idee stap voor stap kan uitgroeien tot een werkende applicatie die daadwerkelijk problemen oplossen voor gebruikers. Tijdens mijn stage leer ik nog iedere dag nieuwe dingen en ontwikkel ik mezelf steeds verder als developer.

Na het behalen van mijn diploma wil ik verder studeren aan Zuyd Hogeschool, waar ik wil starten met de opleiding AD ICT. Mijn interesse ligt vooral bij cybersecurity en mogelijk wil ik daarna nog verder doorstuderen voor een bacheloropleiding in ICT.

Wie ben ik als developer en persoon?

Van jongs af aan heb ik altijd al een sterke affiniteit gehad met techniek en ICT. Ik was vroeger al nieuwsgierig naar hoe computers, systemen en software precies werkten en wilde altijd begrijpen wat er “achter de schermen” gebeurde. Die nieuwsgierigheid is in de loop der jaren alleen maar groter geworden.

Niet alleen binnen softwareontwikkeling, maar ook daarbuiten houd ik ervan om dingen tot in detail uit te zoeken. Zo sleutel ik graag aan motoren en bouw ik ook wel eens pc’s, simpelweg omdat ik het interessant vind om te begrijpen hoe alles in elkaar zit en optimaal werkt. Dat technische en analytische denken neem ik ook mee in mijn werk als developer.

Als persoon ben ik zeer doelgericht, leergierig en gemotiveerd. Wanneer ik ergens mijn focus op zet, ga ik er volledig voor en blijf ik mezelf uitdagen om beter te worden. Ik geloof dat je binnen de IT-wereld nooit bent uitgeleerd. Daarom probeer ik mezelf continu verder te ontwikkelen door nieuwe technieken te ontdekken, praktijkervaring op te doen en steeds meer kennis op te bouwen.

Mijn interesses liggen vooral bij cybersecurity en digitale opsporing. In de toekomst zie ik mezelf het liefst werken bij organisaties zoals de Politie, Defensie of de Koninklijke Marechaussee, bijvoorbeeld als digitaal rechercheur of ethical hacker. Het lijkt mij mooi om mijn technische kennis later in te zetten om mensen en organisaties digitaal veiliger te maken.

Examen

Een overzicht van mijn examenproject en de bijbehorende werkprocessen, gestructureerd per kerntaak.

Algemene informatie RBAC website

Stage-context & Examenkeuze: Tijdens mijn stage bij Bergstein Digital heb ik met succes aan meerdere projecten gewerkt. Voor het vormgeven van deze examenbewijslast heb ik specifiek gekozen voor het RBAC-systeem (Role-Based Access Control), omdat dit project alle facetten en complexiteiten van softwareontwikkeling (van analyse tot realisatie en testen) perfect weerspiegelt. Mocht u interesse hebben in of vragen hebben over de overige projecten waaraan ik tijdens mijn stage heb bijgedragen, dan licht ik dat uiteraard graag toe!

Opbouw Kerntaken

De kerntaken “B1-K1” en “B1-K2” bevatten alle genummerde werkprocessen (1-5 en 1-3) met alle benodigde informatie en documentatie.

Planning & Voortgang

Onder de tab “Planning” vindt u de globale Gantt chart. Specifieke planningen per werkproces zijn direct bij het betreffende onderdeel terug te vinden.

Logboek & Bewijslast

Mijn volledige “Logboek” is in te zien via de eigen tab. Bewijslast kan per werkproces worden gedownload via de knoppen rechtsboven.

Gebruik & Tips

Gebruik de Dark/Light mode rechtsboven voor optimaal leesgemak. Afbeeldingen kunnen uit het venster gesleept worden voor een grotere weergave.

Bronnen & Projectomgevingen

Hieronder vindt u de directe links naar de externe systemen en projectomgevingen die zijn gebruikt tijdens de ontwikkeling van het RBAC-systeem.

Teamwork Takenbord & Voortgang
Azure DevOps Git Repository & Code
Microsoft Teams Communicatie & Overleg
Opmerking over de bewijslast

Bepaalde bewijslast of documenten kunnen binnen de verschillende werkprocessen vaker terugkomen. Dit is bewust gedaan omdat dezelfde bewijslast in een andere context of met een aanvullend specifiek doel of intentie wordt toegelicht. Mocht u specifieke, aanvullende documenten of bewijzen nodig hebben, dan kan daar uiteraard altijd naar gevraagd worden.

RBAC-project (Role Based Access Control)

Tijdens mijn stage heb ik gewerkt aan het ontwerpen en ontwikkelen van een Role Based Access Control (RBAC) systeem binnen de Print Manager applicatie.

Het doel van dit project was om onderscheid te maken tussen verschillende gebruikersgroepen en de beveiliging van de applicatie te verbeteren. Voor dit ticket was door de Scrum Master een planning van 80 uur opgesteld.

RBAC staat voor Role Based Access Control. Dit betekent dat gebruikers rechten krijgen op basis van rollen en permissies.

Voorbeelden:

  • Een Administrator heeft volledige toegang tot alle functionaliteiten binnen de applicatie.
  • Een Productiemedewerker mag alleen printopdrachten uitvoeren en bewerken. Wanneer deze gebruiker probeert een andere pagina te openen, ontvangt hij een 403 Unauthorized foutmelding.

Door rechten te groeperen in rollen en permissies blijft het systeem overzichtelijk en schaalbaar.

Permissies zijn losse rechten die aan gebruikers kunnen worden toegekend. Rollen bestaan uit een verzameling permissies voor een bepaalde gebruikersgroep.

Daarnaast kunnen rollen en permissies gecombineerd worden. Bijvoorbeeld: een gebruiker met de rol Operator én de permissie ReadProfilePermission kan alles uitvoeren wat een Operator mag, én daarnaast profielen bekijken.

Binnen het project heb ik een systeem ontwikkeld waarin:

  • Rollen aangemaakt kunnen worden
  • Permissies gekoppeld kunnen worden aan rollen
  • Gebruikers één of meerdere rollen kunnen krijgen
  • Rechten automatisch gecontroleerd worden bij iedere actie

Daarnaast heb ik gebruikgemaakt van een JWT (JSON Web Token) waarin de rechten van een gebruiker worden opgeslagen. Hierdoor kan bij iedere aanvraag gecontroleerd worden of een gebruiker toegang heeft tot een bepaalde functionaliteit.

Door deze implementatie:

  • Zien gebruikers alleen onderdelen waarvoor zij rechten hebben
  • Worden acties zonder toestemming automatisch geblokkeerd
  • Is het beheer van gebruikers en rechten overzichtelijker geworden
  • Is de applicatie beter beveiligd tegen ongeautoriseerd gebruik
  • Hebben klanten een veiligere omgeving waarin medewerkers geen ongepaste acties kunnen uitvoeren
  • Is de applicatie toekomstbestendig geworden doordat nieuwe rollen en permissies eenvoudig toegevoegd kunnen worden
  • Kan Bergstein eenvoudiger klantgegevens seeden bij het afleveren van printers, doordat vooraf ingestelde rollen en permissies kunnen worden meegeleverd

Tijdens dit project heb ik ervaring opgedaan met:

  • Werken binnen een ontwikkelteam
  • Deelnemen aan Scrum meetings
  • Werken in een bestaande codebase en lopend project
  • Versiebeheer met Git en Azure DevOps
  • Het nemen van verantwoordelijkheid binnen een softwareproject

Voor een gedetailleerde zelfreflectie en teamreflectie verwijs ik naar: B1-K2-W3 Feedbackproces.

Logboek

B1-K1-W1

Plant werkzaamheden en bewaakt de voortgang.

Download W1 Compleet (ZIP)

"De uitgangspunten, technische en functionele eisen en wensen zijn bepaald en gedocumenteerd."

Eisen en wensen RBAC systeem
Functionele eisen
Eis / wens MoSCoW
• In de applicatie zijn verschillende soorten gebruikers actief, zoals Administrator, SupportAdmin en Operator, en zij hebben niet allemaal dezelfde rechten nodig. Must
• Een Administrator kan meer handelingen uitvoeren dan een Operator, bijvoorbeeld instellingen aanpassen of rechten beheren. Must
• Toegangsrechten worden niet los per gebruiker ingesteld maar ondergebracht in rollen. Must
• Een rol bestaat uit meerdere permissies die samen bepalen wat iemand binnen het systeem mag doen. Must
• Eén gebruiker kan meerdere rollen hebben als dat nodig is voor zijn werkzaamheden. Should
• In sommige situaties kan een gebruiker een extra recht krijgen zonder dat daar een nieuwe rol voor aangemaakt hoeft te worden. Should
• Bij iedere actie checkt het systeem eerst of de gebruiker daar toestemming voor heeft. Must
• Na het inloggen ontvangt de gebruiker een JWT token waarin zijn rechten zijn vastgelegd via claims. Must
• In dat token staan de permissies opgeslagen als claims. Must
• Bij elke aanvraag richting de API wordt gecontroleerd of het juiste recht in het token aanwezig is. Must
• Als het benodigde recht ontbreekt, wordt de actie niet uitgevoerd. Must
• De gebruikersinterface laat alleen onderdelen zien waarvoor de gebruiker rechten heeft. Should
• Functionaliteiten waarvoor geen toegang is, worden niet getoond of zijn niet klikbaar. Should
Niet-functionele eisen
Eis / wens MoSCoW
• Toegang is standaard uitgeschakeld en wordt alleen actief wanneer rechten zijn toegekend. Must
• Beveiliging mag niet afhankelijk zijn van alleen de interface maar moet technisch worden afgedwongen. Must
• Het systeem moet stabiel blijven werken ook wanneer meerdere klanten het gebruiken. Should
• Wachtwoorden worden niet leesbaar opgeslagen in de database. Must
• Wachtwoorden worden veilig gehasht met een methode zoals PBKDF2. Must
• De oplossing moet passen binnen de huidige opzet van de Print Manager en mag geen compleet nieuwe structuur introduceren. Must
• Het systeem moet later eenvoudig aan te passen of uit te breiden zijn. Should
• De autorisatiecontrole moet altijd aan de serverzijde plaatsvinden. Must

Uitgangspunten RBAC systeem
  • Het RBAC-systeem wordt geïntegreerd in de bestaande Print Manager applicatie en mag geen losstaand beveiligingssysteem worden.
  • De bestaande drie-lagenarchitectuur (Database, Core en API) blijft behouden en wordt uitgebreid met RBAC-functionaliteit.
  • We blijven gebruikmaken van JWT voor het inloggen, maar breiden dit uit zodat ook de rollen en rechten van een gebruiker worden meegenomen in de controle.
  • De bestaande User-tabel blijft gewoon bestaan en wordt gekoppeld aan rollen en permissies.
  • Rollen, permissies en de verbindingen daartussen worden apart opgeslagen zodat we ze later makkelijk kunnen aanpassen of hergebruiken.
  • Omdat gebruikers meerdere rollen kunnen hebben en rollen meerdere permissies kunnen bevatten, regelen we dit via koppeltabellen zodat de database logisch en overzichtelijk blijft.
  • Autorisatie moet altijd server-side worden afgedwongen zodat beveiliging niet afhankelijk is van alleen de gebruikersinterface.
  • De gebruikersinterface moet aansluiten op de bestaande Blazor/Radzen-structuur en dezelfde componentopbouw blijven gebruiken.
  • Het systeem moet passen binnen de bestaande codeconventies en naamgevingsregels van Bergstein.
  • De implementatie moet gebruikmaken van Dependency Injection zoals al toegepast in het huidige systeem.
  • De oplossing moet geschikt zijn voor on-premise installaties bij klanten en mag geen externe afhankelijkheden introduceren.
  • Het systeem moet uitbreidbaar zijn zodat later nieuwe rollen, permissies of modules eenvoudig toegevoegd kunnen worden.
  • Het systeem moet beheerbaar blijven zodat toekomstige software developers de structuur kunnen begrijpen.
  • De oplossing moet passen binnen de bestaande sprint- en ticketstructuur binnen Teamwork.
  • Beveiligingscontroles mogen niet uitsluitend via de UI gebeuren maar moeten technisch worden afgedwongen via API-beveiliging.

User Stories RBAC systeem
Als administrator wil ik rollen kunnen aanmaken zodat ik gebruikersrechten kan structureren.
Acceptatiecriteria:
  1. Een administrator kan een nieuwe rol invoeren.
  2. Een rolnaam moet uniek zijn.
  3. De nieuwe rol wordt opgeslagen in de database.
Als administrator wil ik rollen kunnen bewerken zodat rechten aangepast kunnen worden wanneer functies veranderen.
Acceptatiecriteria:
  1. Een administrator kan bestaande rollen wijzigen.
  2. Wijzigingen worden direct opgeslagen.
  3. Aangepaste rechten zijn zichtbaar na opnieuw laden.
Als administrator wil ik rollen kunnen verwijderen zodat verouderde rechtenstructuren opgeschoond kunnen worden.
Acceptatiecriteria:
  1. Een administrator kan een rol verwijderen.
  2. Verwijderde rollen zijn niet meer beschikbaar.
  3. Gekoppelde rechten worden correct afgehandeld.
Als administrator wil ik permissies aan rollen kunnen koppelen zodat toegangsrechten centraal beheerd kunnen worden.
Acceptatiecriteria:
  1. Een administrator kan permissies selecteren voor een rol.
  2. De koppeling wordt opgeslagen.
  3. Gebruikers met de rol krijgen de gekoppelde rechten.
Als administrator wil ik permissies van rollen kunnen verwijderen zodat rechten aangepast kunnen worden zonder de rol te verwijderen.
Acceptatiecriteria:
  1. Een administrator kan permissies ontkoppelen van een rol.
  2. De wijziging wordt opgeslagen.
  3. Gebruikers verliezen de verwijderde rechten direct na tokenvernieuwing.
Als administrator wil ik gebruikers aan één of meerdere rollen kunnen koppelen zodat toegang efficiënt toegekend kan worden.
Acceptatiecriteria:
  1. Een administrator kan meerdere rollen aan een gebruiker koppelen.
  2. De koppeling wordt opgeslagen in de database.
Als administrator wil ik rollen van gebruikers kunnen verwijderen zodat rechten direct aangepast kunnen worden.
Acceptatiecriteria:
  1. Een administrator kan rollen verwijderen van een gebruiker.
  2. De wijziging wordt opgeslagen.
  3. Verwijderde rechten zijn niet meer actief na tokenvernieuwing.
Als administrator wil ik directe permissies aan een gebruiker kunnen toekennen zodat uitzonderingen mogelijk zijn zonder een rol aan te passen.
Acceptatiecriteria:
  1. Een administrator kan een directe permissie aan een gebruiker toevoegen.
  2. De permissie wordt opgeslagen.
  3. De gebruiker ontvangt de permissie in het token.
Als administrator wil ik directe permissies kunnen intrekken zodat tijdelijke rechten weer verwijderd kunnen worden.
Acceptatiecriteria:
  1. Een administrator kan directe permissies verwijderen.
  2. De wijziging wordt opgeslagen.
  3. De gebruiker verliest de permissie na tokenvernieuwing.
Als systeem wil ik permissies opslaan in een JWT-token zodat bij iedere aanvraag gecontroleerd kan worden of een gebruiker bevoegd is.
Acceptatiecriteria:
  1. Permissies worden opgeslagen als claims in het JWT-token.
  2. Bij API-aanvragen wordt het token gecontroleerd.
  3. Aanvragen zonder juiste permissie worden geweigerd.
Als systeem wil ik standaard alle toegang blokkeren tenzij rechten expliciet zijn toegekend zodat beveiliging altijd voorop staat.
Acceptatiecriteria:
  1. Gebruikers zonder permissies hebben geen toegang.
  2. Nieuwe functionaliteiten zijn standaard afgeschermd.
  3. Toegang wordt alleen verleend bij expliciete permissies.
Als gebruiker wil ik alleen de onderdelen zien waarvoor ik rechten heb zodat het systeem overzichtelijk blijft.
Acceptatiecriteria:
  1. De interface toont alleen toegestane onderdelen.
  2. Niet-geautoriseerde functies zijn verborgen.
  3. De gebruiker ziet alleen relevante acties.
Als gebruiker wil ik geen foutmeldingen krijgen voor functies waarvoor ik geen rechten heb maar deze simpelweg niet zien.
Acceptatiecriteria:
  1. Niet-toegestane functies worden niet weergegeven.
  2. De gebruiker krijgt geen toegangsfouten via de interface.
  3. De gebruikerservaring blijft overzichtelijk.
Als beheerder wil ik via de gebruikersinterface rollen en permissies kunnen beheren zodat technische codewijzigingen niet nodig zijn.
Acceptatiecriteria:
  1. Rollen kunnen via de UI beheerd worden.
  2. Permissies kunnen via de UI gekoppeld worden.
  3. Er zijn geen codewijzigingen nodig voor standaard beheeracties.
Als systeem wil ik bij het vernieuwen van een token de rechten opnieuw berekenen zodat wijzigingen direct actief worden.
Acceptatiecriteria:
  1. Bij tokenvernieuwing worden rechten opnieuw opgehaald.
  2. Nieuwe rechten zijn direct actief.
  3. Verwijderde rechten zijn direct niet meer geldig.

"Op basis van de functionaliteit is een complete en realistische planning gemaakt."

Onderbouwing planning RBAC systeem

Dit document vormt een aanvullende onderbouwing op de bijgevoegde Gantt-planning van het RBAC-systeem. De planning is opgesteld op basis van de verschillende projectfases binnen de implementatie van Role Based Access Control binnen de bestaande Print Manager applicatie. Per onderdeel is aangegeven welke prioriteit het onderdeel had, welke tijdsinschatting hiervoor gemaakt is en waarom deze inschatting is gekozen.

Prioritering

Voor de planning is gebruikgemaakt van prioritering op basis van het belang van de functionaliteit binnen het RBAC-systeem:

  • Must = essentieel voor een werkend RBAC-systeem
  • Should = belangrijk voor beheerbaarheid en gebruiksvriendelijkheid
  • Could = aanvullende functionaliteit of optimalisatie

Onderbouwing van planning en tijdsinschatting
Onderdeel Prioriteit Tijdsindicatie Onderbouwing
Analyse van huidige authentication Must 2 dagen Nodig om de bestaande login-, authenticatie- en JWT-structuur van de applicatie te begrijpen voordat RBAC geïntegreerd kon worden.
Rollen en permissiemodel bepalen Must 4 dagen Dit vormt de basis van het gehele RBAC-systeem en moest eerst uitgewerkt worden voordat verdere implementatie mogelijk was.
Database structuur uitwerken Must 2 dagen Voor het opslaan van rollen, permissies en koppelingen waren nieuwe databasestructuren noodzakelijk.
ERD en klassendiagram maken Should 2 dagen Diagrammen zijn gebruikt om de structuren overzichtelijk te maken voor implementatie en toekomstige uitbreidingen.
Afstemmen over database aanpak Must 7 dagen Tijdens meerdere overlegmomenten is de database-aanpak besproken om aan te sluiten op de bestaande architectuur en codeconventies.
Aanmaken role/permission tabel Must 3 dagen De basis-tabellen waren noodzakelijk voor de opslag van rollen en permissies binnen het systeem.
Aanmaken van UserRole koppeltabel Must 2 dagen Benodigd om meerdere rollen aan één gebruiker te kunnen koppelen.
Aanmaken van RolePermission koppeltabel Must 2 dagen Benodigd om meerdere permissies aan rollen te koppelen.
Aanmaken van UserPermission koppeltabel Should 2 dagen Ondersteunt uitzonderingssituaties waarbij gebruikers directe permissies kunnen krijgen.
Migrations runnen en testen of relaties kloppen Must 2 dagen Nodig om te controleren of alle database-relaties correct werkten.
Core modellen uitbreiden Must 2 dagen De bestaande modellen moesten worden uitgebreid zodat RBAC geïntegreerd kon worden in de huidige structuur.
Implementeren van services Must 3 dagen Services waren nodig voor het verwerken van rollen, permissies en autorisatiecontroles.
CRUD endpoints voor alle tabellen maken Must 13 dagen Dit onderdeel bevatte meerdere endpoints en beheerfunctionaliteiten en vergde daarom meer ontwikkeltijd.
JSON Web Token uitbreiden met claims Must 4 dagen JWT moest uitgebreid worden zodat permissies opgeslagen en gecontroleerd konden worden.
Server side authorization implementeren Must 2 dagen Autorisatie moest technisch worden afgedwongen op serverniveau.
Beheerpagina's voor alle tabellen maken Should 4 dagen Beheerpagina’s waren nodig voor het beheren van rollen en permissies via de gebruikersinterface.
Condition based rendering implementeren Should 4 dagen Gebruikers moesten alleen functionaliteiten zien waarvoor zij rechten hebben.
Testen met meerdere gebruikers Must 4 dagen Het systeem moest getest worden met verschillende rollen en permissies om correcte werking te controleren.
Pull request maken en reviewen Must 10 dagen De Pull Request bleef langere tijd open zodat reviewcomments verwerkt konden worden en de kwaliteit bewaakt bleef.
Sprint closing en implementatie van het systeem Must 1 dag Tijdens de sprint closing is gecontroleerd of alles correct gemerged en geïntegreerd was.

Tijdens het project is de planning actief bewaakt en waar nodig aangepast. Door gebruik te maken van sprintplanningen, stand-ups, reviewmomenten en urenregistratie kon de voortgang gecontroleerd worden en zijn werkzaamheden waar nodig verdeeld over meerdere sprints. De prioriteiten en tijdsinschattingen zijn gebaseerd op de complexiteit, afhankelijkheden en het belang van de functionaliteiten binnen het RBAC-systeem.

"De gestelde doelen en planning zijn bewaakt."

Voortgangsbewaking

Tijdens mijn stage bij Bergstein Digital B.V. heb ik de voortgang op verschillende manieren bewaakt. Binnen het team werd gewerkt met vaste stand-upmomenten en sprintplanningen per sprint. Tijdens deze momenten werd besproken waar iedereen mee bezig was, welke onderdelen afgerond waren en waar eventueel knelpunten zaten.

Daarnaast werd het project bijgehouden in Teamwork. Hier stond het ticket met de oorspronkelijke scope van 80 uur en kon de voortgang per sprint worden gevolgd.

Voor dit project is de Pull Request gedurende het ontwikkelproces open blijven staan, zodat mijn begeleider en andere developers actief konden meekijken en bijsturen. Hier heb ik uitgebreide feedback op gekregen (ongeveer 70 reviewcomments), die ik heb verwerkt om de kwaliteit te verbeteren.

Bij de sprint closing is gecontroleerd of alles correct was gemerged, of er geen merge-conflicten waren en of de wijzigingen goed in de applicatie waren geïntegreerd.

Aanpassing van de planning

Gedurende het project bleek dat de implementatie meer tijd kostte dan verwacht. Dit was zichtbaar in de urenregistratie en heb ik besproken met mijn begeleider en andere developers.

Tijdens de uitvoering bleek dat de oorspronkelijke inschatting of opstelling van 80 uur niet voldoende was voor de volledige implementatie. Op basis van de voortgang, urenregistratie en overlegmomenten is besloten de werkzaamheden over meerdere sprints te verdelen. Hierdoor bleef de planning realistisch en beheersbaar.

Communicatie met betrokkenen

De voortgang en eventuele problemen zijn tijdig besproken met mijn begeleider en andere developers. Tijdens stand-ups, sprintplanningen en sprint closings werd de status van het project besproken en werden eventuele knelpunten gedeeld.

Uit mijn logboek blijkt daarnaast dat ik tijdens een merge per ongeluk een deel van de fixes had overschreven. Dit is direct besproken en samen met een developer opgelost. Ook dit moment laat zien dat de voortgang en kwaliteit actief werden bewaakt.

Bewijsstukken / Bijlages

Hieronder vind je de bewijslast en bijlages horende bij het bewaken van de voortgang van dit werkproces. Klik op een afbeelding voor een vergrootte weergave of download het bestand direct.

Bijlage 1

Screenshot Teamwork-ticket met scope

Bijlage 1
Download
Bijlage 2

Urenregistratie (Deel 1)

Bijlage 2
Download
Bijlage 3

Urenregistratie (Deel 2)

Bijlage 3
Download
Bijlage 4

Pull Request overzicht in Azure DevOps

Bijlage 4
Download
Bijlage 5

Screenshot Azure DevOps pull request comment (Deel 1)

Bijlage 5
Download
Bijlage 6

Screenshot Azure DevOps pull request comment (Deel 2)

Bijlage 6
Download
Bijlage 7

Screenshot Azure DevOps pull request comment (Deel 3)

Bijlage 7
Download
Bijlage 8

Screenshot van de sprint closing meeting

Bijlage 8
Download
Bijlage 9

Sprint planning verslag

Bijlage 9.docx
Download
Bijlage 10

Sprint standup verslag

Bijlage 10.docx
Download
Bijlage 11

Sprint standup verslag

Bijlage 11.docx
Download
Bijlage 12

Logboek

Bijlage 12.docx
Download

B1-K1-W2

Ontwerpt software.

Download W2 Compleet (ZIP)

"De eisen en wensen zijn vertaald naar een passend, eenduidig en volledig ontwerp."

"De gemaakte keuzes in het ontwerp zijn onderbouwd met steekhoudende argumenten, waarbij rekening is gehouden met haalbaarheid, privacy en security."

Vertaling van functionele eisen

Onderstaand ontwerp vertaalt de functionele eisen en wensen van het RBAC-systeem naar concrete ontwerpkeuzes binnen de bestaande Print Manager applicatie. Per eis is aangegeven welke ontwerpkeuze is gemaakt, waarom hiervoor gekozen is en waar dit terug te vinden is binnen het ontwerp of de implementatie.

Eis / wens Ontwerpkeuze Onderbouwing Terug te vinden in
Verschillende typen gebruikers ondersteunen Role-entiteit + UserRole koppeltabel Door rollen los te modelleren kunnen gebruikers verschillende rechten krijgen zonder duplicatie van permissies. ERD – Role / UserRole
Administrator meer rechten dan Operator Rollen bevatten verschillende sets permissies Door permissies per rol te definiëren kan hiërarchie in rechten worden aangebracht. ERD – RolePermission
Toegangsrechten groeperen in rollen RolePermission koppeltabel Hiermee kunnen meerdere permissies aan één rol worden gekoppeld, wat beheer vereenvoudigt. ERD – RolePermission
Rol bevat meerdere permissies Many-to-many relatie via koppeltabel Dit voorkomt redundantie en maakt uitbreiding mogelijk. ERD
Gebruiker aan meerdere rollen koppelen UserRole koppeltabel Hiermee kan één gebruiker meerdere functies hebben. ERD
Directe permissies mogelijk UserPermission koppeltabel Hiermee kunnen uitzonderingen worden ondersteund zonder rolstructuur te wijzigen. ERD
Controle per actie JWT met permissieclaims Permissies worden na login vastgelegd zodat elke actie gecontroleerd kan worden. Activiteitendiagram – API flow
JWT bevat permissies als claims Claims in SecurityTokenDescriptor Hierdoor kan server-side gecontroleerd worden zonder extra databasequery per request. Klassendiagram
Controle bij elke API-aanroep [Authorize(Roles="...")] attributen Autorisatie wordt afgedwongen op endpointniveau. Activiteitendiagram
Actie blokkeren bij ontbrekend recht Standaard server-side afwijzing Dit voorkomt dat ongeautoriseerde acties uitgevoerd kunnen worden. Activiteitendiagram
Onderdelen niet zichtbaar zonder toestemming AuthorizeView / custom checks Voorkomt dat gebruikers functies zien waarvoor zij geen rechten hebben. UI ontwerp
Functionaliteiten zonder rechten niet klikbaar Conditional rendering + disabled states Gebruikers kunnen functionaliteiten zonder permissies niet gebruiken of activeren. UI ontwerp
Beheer van rollen en permissies via gebruikersinterface Blazor/Radzen beheerpagina’s Administrators kunnen rollen en permissies beheren zonder codewijzigingen. UI ontwerp
Rechten opnieuw berekenen bij tokenvernieuwing JWT regeneratie tijdens authenticatieflow Wijzigingen in rollen of permissies worden direct actief na vernieuwen van het token. Activiteitendiagram – API flow

Vertaling van niet-functionele eisen

Onderstaand ontwerp vertaalt de niet-functionele eisen en wensen naar concrete ontwerpkeuzes binnen de bestaande Print Manager applicatie.

Eis / wens Ontwerpkeuze Onderbouwing Terug te vinden in
Toegang standaard geblokkeerd Deny-by-default principe Alleen expliciet toegekende permissies geven toegang. UI ontwerp & Activiteitendiagram
Systeem moet veilig zijn Server-side autorisatie + JWT signing Voorkomt manipulatie via client-side aanpassingen. Activiteitendiagram
Autorisatie server-side Gebruik van middleware + attributen Veiligheid is niet afhankelijk van UI. Activiteitendiagram
Wachtwoorden worden niet leesbaar opgeslagen Password hashing in authenticatieservice Voorkomt opslag van gevoelige gegevens in platte tekst. Authenticatieflow
Wachtwoorden veilig hashen met PBKDF2 PBKDF2 password hashing Hierdoor worden wachtwoorden veilig opgeslagen volgens gangbare beveiligingsrichtlijnen. Authenticatieflow
Aansluiten op bestaande architectuur Integratie binnen Database-, Core- en API-laag Voorkomt extra complexiteit en houdt systeem onderhoudbaar. Klassendiagram
Gebruik van Dependency Injection Services registreren via DI container Sluit aan op de bestaande architectuur en maakt componenten onderhoudbaar en testbaar. Klassendiagram
Onderhoudbaar en uitbreidbaar Entiteiten gescheiden gemodelleerd Nieuwe rollen/permissies kunnen worden toegevoegd zonder structuurwijziging. ERD
Schaalbaar voor meerdere klanten Generieke rol- en permissiestructuur Geen hardcoded rechten; systeem is klantonafhankelijk. ERD
Frontend in Blazor UI gebouwd in Blazor + Radzen Consistent met bestaande applicatie. UI ontwerp
Geen externe afhankelijkheden introduceren RBAC geïntegreerd binnen bestaande applicatie Hierdoor blijft het systeem geschikt voor on-premise installaties. Architectuuroverzicht
Beveiligingscontroles niet alleen via UI Server-side validatie van permissies Voorkomt toegang via directe API-aanroepen zonder permissies. Activiteitendiagram

Bestaande Architectuur Integratie

Het RBAC-systeem is geïntegreerd binnen de bestaande drie-lagenarchitectuur van de Print Manager applicatie. De database-laag bevat de entiteiten en koppeltabellen voor rollen en permissies. Binnen de Core-laag bevinden zich de businesslogica en services voor autorisatie en tokenverwerking. De API-laag checkt permissies via de JWT claims en autorisatie-attributen. De gebruikersinterface is gerealiseerd in Blazor en Radzen en toont functionaliteiten op basis van de rechten van de gebruiker.

Onderbouwing en Ontwerpkeuzes
Haalbaarheid

Het ontwerp sluit aan op de Print Manager architectuur en gebruikt bestaande technieken zoals Blazor, JWT en Dependency Injection. Hierdoor kon het RBAC-systeem gerealiseerd worden zonder een nieuwe structuur te maken. Dit maakte de implementatie en uitvoering technisch haalbaar binnen de tijd en bestaande infrastructuur.

Privacy

In het ontwerp is rekening gehouden met privacy door gebruikersgegevens en wachtwoorden veilig te verwerken. Wachtwoorden worden niet als normale tekst opgeslagen maar gehasht met PBKDF2. Daarnaast worden alleen noodzakelijke rechten opgeslagen binnen JWT claims zodat geen onnodige persoonsgegevens verwerkt worden.

Security

Security speelde een belangrijke rol binnen het ontwerp. Autorisatie wordt server-side afgedwongen zodat beveiliging niet afhankelijk is van de UI. Permissies worden gecontroleerd via JWT claims en beveiligde API endpoints. Daarnaast geldt een deny-by-default principe waarbij gebruikers standaard geen toegang hebben tenzij rechten zijn toegekend.

Relatie met eisen en wensen

De ontwerpkeuzes zijn direct gebaseerd op de eerder opgestelde functionele en niet-functionele eisen en wensen. Door gebruik te maken van rollen, permissies, koppeltabellen, JWT claims en server-side autorisatie sluit het ontwerp aan op de eisen rondom beveiliging, beheerbaarheid, uitbreidbaarheid en gebruikersgemak.

Conclusie

Door de combinatie van databaseontwerp, JWT autorisatie, server-side beveiliging en UI controles dekt het ontwerp alle benodigde onderdelen van het RBAC-systeem. Het ontwerp sluit aan op de bestaande architectuur van de applicatie en ondersteunt onderhoudbaarheid, uitbreidbaarheid en veilige autorisatie.

"Er is gebruikgemaakt van relevante of toepasselijke schematechnieken (bijvoorbeeld een activiteitendiagram, een klassendiagram, een ERD of een usecasediagram)."

Schematechnieken RBAC Systeem

Hieronder vind je de schematechnieken die zijn gebruikt om de datastructuren en processen van het RBAC-systeem te modelleren. Klik op een afbeelding voor een vergrootte weergave of download het bestand.

Entity-Relationship Diagram (ERD)

Entity-Relationship Diagram met de tabellen en relaties voor rollen en permissies.

Entity-Relationship Diagram (ERD)
Download
Klassendiagram

Klassendiagram van de RBAC services, controller en modellen binnen de Core- en API-laag.

Klassendiagram
Download
Activiteitendiagram (Swimlane)

Swimlane activiteitendiagram van de login- en autorisatieflow met JWT tokenclaims.

Activiteitendiagram (Swimlane)
Download
Figma UI-ontwerpen

Hieronder vind je de interactieve UI-ontwerpen gemaakt in Figma ter voorbereiding op het beheer en de werking van het RBAC-systeem.

Figma - CRUD beheerpagina

Ontwerp van de beheerdersinterface voor het aanmaken, wijzigen en verwijderen van rollen en permissies.

Figma - CRUD beheerpagina
Download
Figma - Conditional rendering

Ontwerp voor het verbergen of uitschakelen van specifieke acties of menu-opties op basis van rechten.

Figma - Conditional rendering
Download
Figma - Toegang geweigerd

Ontwerp van de foutpagina of melding wanneer een gebruiker een niet-geautoriseerde actie probeert uit te voeren.

Figma - Toegang geweigerd
Download

B1-K1-W3

Realiseert (onderdelen van) software.

Download W3 Compleet (ZIP)

"Er is voldoende inhoud van de functionaliteiten gerealiseerd binnen de gestelde/geplande tijd."

Gerealiseerde functionaliteiten RBAC-systeem

Examen Bewijslast B1-K1-W3

Status: Volledig Gerealiseerd

Onderstaand overzicht toont welke functionaliteiten van het RBAC-systeem zijn gerealiseerd op basis van de eerder opgestelde eisen en wensen. Per functionaliteit is aangegeven wat de status van de implementatie is en waar het bewijs van realisatie terug te vinden is.

Eis / wens MoSCoW Status Toelichting realisatie Bewijs / bijlage
In de applicatie zijn verschillende soorten gebruikers actief, zoals Administrator, SupportAdmin en Operator, en zij hebben niet allemaal dezelfde rechten nodig. Must Gerealiseerd In het demo filmpje wordt getoond dat verschillende gebruikersrollen aanwezig zijn binnen het systeem. Demo filmpje
Een Administrator kan meer handelingen uitvoeren dan een Operator, bijvoorbeeld instellingen aanpassen of rechten beheren. Must Gerealiseerd In het demo filmpje wordt getoond dat de Administrator toegang heeft tot beheerfunctionaliteiten. Demo filmpje
Toegangsrechten worden niet los per gebruiker ingesteld maar ondergebracht in rollen. Must Gerealiseerd In het demo filmpje wordt de rollenstructuur en gebruikerskoppeling getoond. Demo filmpje
Een rol bestaat uit meerdere permissies die samen bepalen wat iemand binnen het systeem mag doen. Must Gerealiseerd In het demo filmpje wordt de RolePermission-pagina getoond waarin permissies gekoppeld zijn aan rollen. Demo filmpje
Eén gebruiker kan meerdere rollen hebben als dat nodig is voor zijn werkzaamheden. Should Gerealiseerd De interface en database-architectuur ondersteunen het toewijzen van meerdere rollen per gebruiker. Screenshot rolkoppeling
In sommige situaties kan een gebruiker een extra recht krijgen zonder dat daar een nieuwe rol voor aangemaakt hoeft te worden. Should Gerealiseerd Via UserPermission is het mogelijk om een directe permissie aan een gebruiker te koppelen. Screenshot UserPermission
Bij iedere actie checkt het systeem eerst of de gebruiker daar toestemming voor heeft. Must Gerealiseerd In het demo filmpje wordt getoond dat functionaliteiten verdwijnen wanneer permissies verwijderd worden. Demo filmpje
Na het inloggen ontvangt de gebruiker een JWT token waarin zijn rechten zijn vastgelegd via claims. Must Gerealiseerd In de JWT.io screenshot is zichtbaar dat gebruikersrechten als claims aanwezig zijn in het JWT-token. JWT.io screenshot
In dat token staan de permissies opgeslagen als claims. Must Gerealiseerd In de JWT.io screenshot zijn de permissieclaims zichtbaar binnen het JWT-token. JWT.io screenshot
Bij elke aanvraag richting de API wordt gecontroleerd of het juiste recht in het token aanwezig is. Must Gerealiseerd In de screenshot van de API-code is zichtbaar dat Authorize attributen gebruikt worden voor permissiecontrole. Screenshot API-code
Als het benodigde recht ontbreekt, wordt de actie niet uitgevoerd. Must Gerealiseerd In het demo filmpje wordt getoond dat onderdelen niet meer beschikbaar zijn nadat permissies verwijderd zijn. Demo filmpje
De gebruikersinterface laat alleen onderdelen zien waarvoor de gebruiker rechten heeft. Should Gerealiseerd In het demo filmpje verdwijnen onderdelen uit de interface nadat permissies verwijderd zijn. Demo filmpje
Functionaliteiten waarvoor geen toegang is, worden niet getoond of zijn niet klikbaar. Should Gerealiseerd In het demo filmpje wordt getoond dat functionaliteiten niet meer zichtbaar zijn zonder permissies. Demo filmpje

Eis / wens MoSCoW Status Toelichting realisatie Bewijs / bijlage
Toegang is standaard uitgeschakeld en wordt alleen actief wanneer rechten zijn toegekend. Must Gerealiseerd In het demo filmpje wordt zichtbaar dat functionaliteiten verdwijnen wanneer permissies verwijderd worden. Demo filmpje
Beveiliging mag niet afhankelijk zijn van alleen de interface maar moet technisch worden afgedwongen. Must Gerealiseerd In de API-code is zichtbaar dat permissiecontrole server-side wordt afgedwongen via Authorize attributen. Screenshot API-code
Het systeem moet stabiel blijven werken ook wanneer meerdere klanten het gebruiken. Should Gerealiseerd Iedere klant krijgt een eigen versie van de Print Manager applicatie. Het systeem wordt niet gedeeld tussen klanten. Geen bewijs beschikbaar wegens privacy
Wachtwoorden worden niet leesbaar opgeslagen in de database. Must Gerealiseerd Wachtwoorden worden veilig gehasht via PBKDF2 en zijn niet als plaintext in de database terug te vinden. Niet beschikbaar wegens beveiligingsrichtlijnen
Wachtwoorden worden veilig gehasht met een methode zoals PBKDF2. Must Gerealiseerd Binnen de authenticatie wordt PBKDF2 toegepast voor veilige wachtwoordhashing. Niet beschikbaar wegens beveiligingsrichtlijnen
De oplossing moet passen binnen de huidige opzet van de Print Manager en mag geen compleet nieuwe structuur introduceren. Must Gerealiseerd In het demo filmpje wordt de integratie binnen de bestaande applicatie getoond. Demo filmpje
Het systeem moet later eenvoudig aan te passen of uit te breiden zijn. Should Gerealiseerd In het demo filmpje worden nieuwe rollen en role-permission koppelingen aangemaakt. Demo filmpje
De autorisatiecontrole moet altijd aan de serverzijde plaatsvinden. Must Gerealiseerd In de screenshot van de API-code is zichtbaar dat permissies server-side gecontroled worden. Screenshot API-code

De bovenstaande functionaliteiten zijn gerealiseerd op basis van de eerder opgestelde eisen en wensen, planning en ontwerpdocumentatie. De implementatie is uitgevoerd binnen meerdere sprints en gecontroleerd via reviews, testmomenten en sprint closings.

Een groot deel van de geplande functionaliteiten van het RBAC-systeem is gerealiseerd en geïntegreerd binnen de bestaande Print Manager applicatie. De gerealiseerde onderdelen sluiten aan op de opgestelde eisen, ontwerpen en planning.

Bewijsstukken / Bijlages

Hieronder vind je de bewijslast en bijlages horende bij de gerealiseerde functionaliteiten van het RBAC-systeem. Klik op een afbeelding voor een vergrootte weergave of download het bestand direct.

Bijlage 1

Demo filmpje

Download
Bijlage 2

JWT met HMAC en claims

Bijlage 2
Download
Bijlage 3

API Code met authorize attribute

Bijlage 3
Download
Bijlage 4

Screenshot user permission

Bijlage 4
Download
Bijlage 5

Screenshot user met meerdere rollen

Bijlage 5
Download

"De opgeleverde functionaliteiten voldoen aan de eisen en wensen."

Kwaliteit opgeleverde functionaliteiten RBAC-systeem

Examen Bewijslast B1-K1-W3

Kwaliteit: > 80% Voldoet

Onderstaand overzicht toont in hoe verre de opgeleverde functionaliteiten van het RBAC-systeem voldoen aan de opgestelde eisen, wensen en uitgangspunten. Per functionaliteit is aangegeven hoe deze gecontroleerd is en welk bewijs hiervoor beschikbaar is.

Eis / wens MoSCoW Status Onderbouwing Bewijs / bijlage
In de applicatie zijn verschillende soorten gebruikers actief, zoals Administrator, SupportAdmin en Operator, en zij hebben niet allemaal dezelfde rechten nodig. Must Voldoet In het demo filmpje wordt getoond dat verschillende gebruikersrollen aanwezig zijn binnen het systeem. Demo filmpje
Een Administrator kan meer handelingen uitvoeren dan een Operator, bijvoorbeeld instellingen aanpassen of rechten beheren. Must Voldoet In het demo filmpje wordt getoond dat de Administrator toegang heeft tot beheerfunctionaliteiten. Demo filmpje
Toegangsrechten worden niet los per gebruiker ingesteld maar ondergebracht in rollen. Must Voldoet In het demo filmpje wordt de rollenstructuur en gebruikerskoppeling getoond. Demo filmpje
Een rol bestaat uit meerdere permissies die samen bepalen wat iemand binnen het systeem mag doen. Must Voldoet In het demo filmpje wordt de RolePermission-pagina getoond waarin permissies gekoppeld zijn aan rollen. Demo filmpje
Eén gebruiker kan meerdere rollen hebben als dat nodig is voor zijn werkzaamheden. Should Voldoet De interface en database-architectuur ondersteunen het toewijzen van meerdere rollen per gebruiker. Screenshot user met meerdere rolen
In sommige situaties kan een gebruiker een extra recht krijgen zonder dat daar een nieuwe rol voor aangemaakt hoeft te worden. Should Voldoet Via UserPermission is het mogelijk om een directe permissie aan een gebruiker te koppelen. Screenshot user met userpermission
Bij iedere actie checkt het systeem eerst of de gebruiker daar toestemming voor heeft. Must Voldoet In het demo filmpje wordt getoond dat functionaliteiten verdwijnen wanneer permissies verwijderd worden. Demo filmpje
Na het inloggen ontvangt de gebruiker een JWT token waarin zijn rechten zijn vastgelegd via claims. Must Voldoet In de JWT.io screenshot is zichtbaar dat gebruikersrechten als claims aanwezig zijn in het JWT-token. JWT.io screenshot
In dat token staan de permissies opgeslagen als claims. Must Voldoet In de JWT.io screenshot zijn de permissieclaims zichtbaar binnen het JWT-token. JWT.io screenshot
Bij elke aanvraag richting de API wordt gecontroleerd of het juiste recht in het token aanwezig is. Must Voldoet In de screenshot van de API-code is zichtbaar dat Authorize attributen gebruikt worden voor permissiecontrole. Screenshot API-code
Als het benodigde recht ontbreekt, wordt de actie niet uitgevoerd. Must Voldoet In het demo filmpje wordt getoond dat onderdelen niet meer beschikbaar zijn nadat permissies verwijderd zijn. Demo filmpje
De gebruikersinterface laat alleen onderdelen zien waarvoor de gebruiker rechten heeft. Should Voldoet In het demo filmpje verdwijnen onderdelen uit de interface nadat permissies verwijderd zijn. Demo filmpje
Functionaliteiten waarvoor geen toegang is, worden niet getoond of zijn niet klikbaar. Should Voldoet In het demo filmpje wordt getoond dat functionaliteiten niet meer zichtbaar zijn zonder permissies. Demo filmpje

Eis / wens MoSCoW Status Onderbouwing Bewijs / bijlage
Toegang is standaard uitgeschakeld en wordt alleen actief wanneer rechten zijn toegekend. Must Voldoet In het demo filmpje wordt zichtbaar dat functionaliteiten verdwijnen wanneer permissies verwijderd worden. Demo filmpje
Beveiliging mag niet afhankelijk zijn van alleen de interface maar moet technisch worden afgedwongen. Must Voldoet In de API-code is zichtbaar dat permissiecontrole server-side wordt afgedwongen via Authorize attributen. Screenshot API-code
Het systeem moet stabiel blijven werken ook wanneer meerdere klanten het gebruiken. Should Voldoet Iedere klant krijgt zijn eigen versie van de Print Manager. Het systeem wordt niet gedeeld tussen klanten. Geen bewijs beschikbaar wegens privacy van klanten
Wachtwoorden worden niet leesbaar opgeslagen in de database. Must Voldoet Wachtwoorden worden niet in platte tekst opgeslagen. Niet beschikbaar wegens beveiligingsrichtlijnen binnen de organisatie
Wachtwoorden worden veilig gehasht met een methode zoals PBKDF2. Must Voldoet Binnen de authenticatie wordt PBKDF2 toegepast voor veilige wachtwoordhashing. Niet beschikbaar wegens beveiligingsrichtlijnen binnen de organisatie
De oplossing moet passen binnen de huidige opzet van de Print Manager en mag geen compleet nieuwe structuur introduceren. Must Voldoet In het demo filmpje wordt de integratie binnen de bestaande applicatie getoond. Demo filmpje
Het systeem moet later eenvoudig aan te passen of uit te breiden zijn. Should Voldoet In het demo filmpje worden nieuwe rollen en role-permission koppelingen aangemaakt. Demo filmpje
De autorisatiecontrole moet altijd aan de serverzijde plaatsvinden. Must Voldoet In de screenshot van de API-code is zichtbaar dat permissies server-side gecontroleerd worden. Screenshot API-code

De bovenstaande functionaliteiten voldoen aan de eerder opgestelde eisen, wensen en uitgangspunten. Tijdens de ontwikkeling zijn de functionaliteiten gecontroleerd via reviews, testmomenten en sprint closings.

Meer dan 80% van de opgeleverde functionaliteiten voldoet aan de eerder opgestelde eisen, wensen en uitgangspunten van het RBAC-systeem. De gerealiseerde onderdelen functioneren goed binnen de bestaande Print Manager applicatie.

Bewijsstukken / Bijlages

Hieronder vind je de bewijslast en bijlages horende bij de kwaliteit van de opgeleverde functionaliteiten van het RBAC-systeem. Klik op een afbeelding voor een vergrootte weergave of download het bestand direct.

Bijlage 1

Demo filmpje

Download
Bijlage 2

JWT met HMAC en claims

Bijlage 2
Download
Bijlage 3

API Code met authorize attribute

Bijlage 3
Download
Bijlage 4

Screenshot user permission

Bijlage 4
Download
Bijlage 5

Screenshot user met meerdere rollen

Bijlage 5
Download

"De kwaliteit van de code is goed."

Kwaliteit code RBAC-systeem

Examen Bewijslast B1-K1-W3

Code Kwaliteit: Hoogste Standaard

Tijdens de ontwikkeling van het RBAC-systeem is er niet alleen gekeken naar werkende functionaliteit, maar ook naar de kwaliteit, leesbaarheid en onderhoudbaarheid van de code. Omdat het systeem geïntegreerd moest worden binnen de bestaande Print Manager applicatie, was het belangrijk dat de code aansloot op de bestaande architectuur, coding conventions en werkwijze binnen het ontwikkelteam. Daarnaast is tijdens de ontwikkeling rekening gehouden met validatie, foutafhandeling en security. De kwaliteit van de code is gedurende het project bewaakt via Pull Requests, reviews en feedback van andere developers.

Binnen het project zijn de bestaande coding conventions van de applicatie gevolgd. Hierdoor blijft de code consistent met de rest van het systeem en beter leesbaar voor andere developers.

Toegepaste afspraken:
  • Gebruik van PascalCase voor classes, methods en properties
  • Gebruik van camelCase voor lokale variabelen en parameters
  • Duidelijke en beschrijvende namen voor methods, services en entiteiten
  • Consistente naamgeving binnen services, Methods en database entiteiten
  • Gebruik van logische namespaces passend binnen de bestaande projectstructuur
  • Structuur en naamgeving sluiten aan op de bestaande code van de Print Manager applicatie

Het RBAC-systeem is ontwikkeld binnen de bestaande drie-lagenstructuur van de applicatie. Hierbij is onderscheid gemaakt tussen:

  • Database laag
  • Core / businesslogica
  • API laag

Door deze scheiding blijven verantwoordelijkheden duidelijk verdeeld. Database-entiteiten, businesslogica en API-functionaliteit zijn gescheiden opgebouwd.

Daarnaast is gebruikgemaakt van Dependency Injection voor services en autorisatiecomponenten. Hierdoor blijft de code onderhoudbaar en kunnen onderdelen eenvoudiger uitgebreid of aangepast worden.

Tijdens de implementatie is geprobeerd om logische en herbruikbare methods te maken zodat dubbele code zoveel mogelijk voorkomen werd.

Tijdens het ontwikkelen is rekening gehouden met de leesbaarheid van de code. Methods zijn zoveel mogelijk opgesplitst zodat iedere method één duidelijke verantwoordelijkheid heeft.

Daarnaast zijn onderdelen zoals permissiecontroles en tokenverwerking centraal verwerkt binnen services zodat deze op meerdere plekken herbruikbaar blijven.

Op plekken waar extra uitleg nodig was, is gebruikgemaakt van comments of Markdown-documentatie.

Binnen de applicatie is rekening gehouden met validatie en foutafhandeling.

Voorbeelden hiervan:
  • Controle of gebruikers beschikken over de juiste permissies
  • Blokkeren van acties wanneer gebruikers niet bevoegd zijn
  • Server-side autorisatiecontroles binnen de API

Hierdoor worden foutieve of ongeautoriseerde acties zoveel mogelijk voorkomen.

Security speelde een belangrijke rol binnen de ontwikkeling van het systeem.

Tijdens de implementatie zijn verschillende beveiligingsmaatregelen toegepast:
  • Gebruik van JWT tokens voor authenticatie en autorisatie
  • Opslaan van permissies als claims binnen het JWT-token
  • Controle of permissies bij iedere API-aanvraag
  • Server-side autorisatie via Authorize attributen
  • Deny-by-default principe waarbij gebruikers standaard geen toegang hebben
  • PBKDF2 hashing voor veilige opslag van wachtwoorden
  • Functionaliteiten worden verborgen wanneer gebruikers niet over de juiste rechten beschikken

Hierdoor is beveiliging niet afhankelijk van alleen de gebruikersinterface, maar wordt deze technisch afgedwongen binnen de applicatie.

De kwaliteit van de code is tijdens het project actief bewaakt.

Hiervoor is gebruikgemaakt van Pull Requests binnen Azure DevOps. De Pull Request is gedurende langere tijd open blijven staan zodat andere developers feedback konden geven op de implementatie.

Tijdens het project zijn reviewcomments verwerkt en is code aangepast of gerefactord op basis van feedback van begeleiders en developers.

Daarnaast zijn tijdens sprint closings controles uitgevoerd op merges, conflicten en correcte integratie binnen de applicatie.

Tijdens de ontwikkeling van het RBAC-systeem is consequent rekening gehouden met coding conventions, leesbaarheid, onderhoudbaarheid, validatie, foutafhandeling en security.

Door gebruik te maken van een consistente architectuur, code reviews, Pull Requests en server-side beveiliging is de kwaliteit van de code gedurende het volledige ontwikkelproces bewaakt.

Bewijsstukken / Bijlages

Hieronder vind je de volledige set van 18 bewijsstukken en bijlages horende bij de codekwaliteit van het RBAC-systeem. Klik op een afbeelding voor een vergrootte weergave of download het bestand direct.

Bijlage 1

Screenshot servicestructuur

Bijlage 1
Download
Bijlage 2

Screenshot Method naamgeving

Bijlage 2
Download
Bijlage 3

Screenshot naamgeving classes en methods

Bijlage 3
Download
Bijlage 4

Screenshot drie-lagenstructuur

Bijlage 4
Download
Bijlage 5

Screenshot Dependency Injection

Bijlage 5
Download
Bijlage 6

Screenshot services en repositories

Bijlage 6
Download
Bijlage 7

Screenshot projectstructuur

Bijlage 7
Download
Bijlage 8

Screenshot logisch opgebouwde methods

Bijlage 8
Download
Bijlage 9

Screenshot comments / documentatie

Bijlage 9
Download
Bijlage 10

Screenshot herbruikbare services

Bijlage 10
Download
Bijlage 11

Screenshot permissiecontrole met attribute

Bijlage 11
Download
Bijlage 12

Screenshot foutafhandeling / API response

Bijlage 12
Download
Bijlage 13

JWT.io screenshot met claims en HMAC signing

Bijlage 13
Download
Bijlage 14

Screenshot permissieclaims

Bijlage 14
Download
Bijlage 15

Screenshot UI permissie

Bijlage 15
Download
Bijlage 16

Screenshot Pull Request Azure DevOps

Bijlage 16
Download
Bijlage 17

Screenshot reviewcomments

Bijlage 17
Download
Bijlage 18

Screenshot refactoring of aangepaste code

Bijlage 18
Download

"Versiebeheer is effectief toegepast."

Versiebeheer RBAC systeem

Examen Bewijslast B1-K1-W3

Versiebeheer: Actief & Gestructureerd

Tijdens de ontwikkeling van het RBAC-systeem is gebruikgemaakt van versiebeheer om wijzigingen binnen het project beheersbaar en inzichtelijk te houden. In het project werd gewerkt met Git in Azure DevOps. Hierdoor konden wijzigingen veilig worden opgeslagen, gecontroleerd en teruggehaald wanneer nodig.

Daansaast maakte versiebeheer het mogelijk om samen te werken met andere Collega’s/developers binnen het team en feedback te verwerken voordat wijzigingen definitief werden gemerged.

Voor het versiebeheer is gebruikgemaakt van Git binnen Azure DevOps.

Binnen Azure DevOps zijn:
  • Commits uitgevoerd voor afzonderlijke wijzigingen.
  • Branches gebruikt voor ontwikkeling van functionaliteiten.
  • Pull Requests aangemaakt voor controle van wijzigingen.
  • Reviewcomments geplaatst door andere developers.
  • Wijzigingen gecontroleerd voordat deze werden gemerged.
Door gebruik te maken van Azure DevOps bleef zichtbaar:
  • Welke wijzigingen zijn uitgevoerd.
  • Wanneer wijzigingen zijn gedaan.
  • Door wie wijzigingen zijn uitgevoerd.
  • Welke versies zijn gemerged.
  • Welke feedback tijdens reviews is gegeven.

Binnen het project is gewerkt met een vaste workflow voor ontwikkeling en controle van code.

Nieuwe functionaliteiten werden eerst ontwikkeld binnen aparte branches. Vervolgens werd een Pull Request aangemaakt zodat andere developers de wijzigingen konden controleren.

Tijdens deze reviews werden comments geplaatst met verbeterpunten, mogelijke oplossingen of feedback op de implementatie. Op basis van deze feedback zijn onderdelen aangepast of gerefactord voordat de wijzigingen definitief werden gemerged.

Hierdoor werd de kwaliteit van de code en de stabiliteit van de applicatie bewaakt.

Binnen het project is gebruikgemaakt van Semantic Versioning (SemVer) voor het beheren van versies.

Hierbij zijn versies opgebouwd uit:
  • Major versie (Breaking changes, bijv. API structuur veranderd)
  • Minor versie (Bijv., Nieuwe functionaliteiten)
  • Patch versie (Bugfixes/Hotfixes)

Op deze manier bleef zichtbaar welke wijzigingen grote functionaliteiten, uitbreidingen of bugfixes bevatten.

Daarnaast werd de Print Manager aan het einde van iedere sprint bijgewerkt met de wijzigingen van de afgelopen sprint. Deze updates vonden plaats op de laatste donderdag van de sprint.

Hierdoor bleven releases gestructureerd en herleidbaar.

Tijdens de ontwikkeling van het RBAC-systeem is gestructureerd gebruikgemaakt van versiebeheer via Git binnen Azure DevOps.

Door gebruik te maken van commits, branches, Pull Requests, reviews en SemVer-versienummering bleven wijzigingen inzichtelijk en terug te halen. Daarnaast zorgde de gekozen workflow ervoor dat wijzigingen gecontroleerd konden worden voordat deze onderdeel werden van de applicatie.

Bewijsstukken / Bijlages

Hieronder vind je de volledige set van 10 bewijsstukken en bijlages horende bij het versiebeheer van het RBAC-systeem. Klik op een afbeelding voor een vergrootte weergave of download het bestand direct.

Bijlage 1

Screenshot Azure DevOps repository

Bijlage 1
Download
Bijlage 2

Screenshot commitgeschiedenis

Bijlage 2
Download
Bijlage 3

Screenshot branches

Bijlage 3
Download
Bijlage 4

Screenshot Pull Request

Bijlage 4
Download
Bijlage 5

Screenshot reviewcomments

Bijlage 5
Download
Bijlage 6

Screenshot workflow / branchstructuur

Bijlage 6
Download
Bijlage 7

Screenshot aangepaste code na review

Bijlage 7
Download
Bijlage 8

Screenshot merge naar hoofdbranch

Bijlage 8
Download
Bijlage 9

Screenshot versienummering

Bijlage 9
Download
Bijlage 10

Screenshot sprintclosing meeting

Bijlage 10
Download

B1-K1-W4

Test software.

Download W4 Compleet (ZIP)

"De testcases in het testplan sluiten aan op de functionaliteit en bevatten alle scenario’s."

Testplan RBAC-systeem

Examen Bewijslast B1-K1-W4

27 okt 2025 - 30 okt 2025 Ontwikkelomgeving
Doel van het testplan

Het doel van dit testplan is het checken of het geïmplementeerde RBAC systeem correct werkt en voldoet aan de eisen en wensen.
Tijdens de testfase wordt gecontroleerd of gebruikers alleen toegang hebben tot functionaliteiten waarvoor ze permissies hebben en of de authorization op een veilige manier gebeurd.

Binnen dit testplan worden de volgende onderdelen getest:

  • Werking van rollen en permissies
  • Koppeling tussen gebruikers en rollen
  • Directe permissies voor gebruikers
  • Autorisatiecontrole op API-niveau
  • Verwerking van permissies in het JWT token
  • Aanpassing van de gebruikersinterface op basis van rechten
  • Blokkeren van acties zonder voldoende rechten

Het RBAC-systeem functioneert correct wanneer:

  • Gebruikers alleen toegang hebben tot functionaliteiten waarvoor zij rechten hebben
  • Acties zonder rechten automatisch worden geblokkeerd
  • Rollen en permissies correct worden opgeslagen en gekoppeld
  • De gebruikersinterface zich aanpast aan de rechten van de gebruiker
  • Autorisatie server-side wordt afgedwongen
De resultaten van de testen zijn vastgelegd in het testrapport.

De testen zijn uitgevoerd door functionele controles binnen de applicatie.
Er is daarvoor is gebruikgemaakt van verschillende testgebruikers met uiteenlopende rollen en permissies.

De testactiviteiten bestonden uit:

  • Het uitvoeren van CRUD-acties op rollen en permissies
  • Het koppelen van rollen aan gebruikers
  • Het controleren van toegang tot beveiligde onderdelen
  • Het uitvoeren van acties met en zonder de juiste rechten
  • Het controleren van de inhoud van het JWT token
  • Het opnieuw testen na het verwerken van feedback uit Pull Requests

Testperiode:

De testfase vond plaats in de periode van 27 oktober 2025 tot en met 30 oktober 2025, conform de projectplanning en Gantt-chart.
Tijdens deze periode zijn functionaliteiten gecontroleerd voordat de Pull Request definitief werd goedgekeurd en gemerged.

Testomgeving details:

De testen zijn uitgevoerd binnen de ontwikkelomgeving van de Print Manager applicatie. Hierbij is gebruikgemaakt van:

  • De bestaande backend API
  • De Blazor gebruikersinterface
  • Testgebruikers met verschillende rollen
  • Lokale database en ontwikkelconfiguratie
Vanwege bedrijfsgevoelige informatie kon de volledige testomgeving niet extern gedeeld worden.

"De kandidaat heeft voor alle toegewezen of geplande functionaliteit testscenario's of testcases gemaakt."

Component: Roles
Doel:

Controleren of een nieuwe rol correct kan worden aangemaakt.

Teststappen:
  1. Log in als Admin
  2. Ga naar de pagina voor Roles
  3. Kies de optie om een nieuwe rol aan te maken
  4. Vul een naam in voor de rol
  5. Sla de rol op
Verwacht resultaat:

De rol wordt opgeslagen in het systeem en verschijnt in het overzicht van rollen.

Component: RolePermissions
Doel:

Controleren of permissies correct aan een rol gekoppeld kunnen worden.

Teststappen:
  1. Log in als Admin
  2. Open de pagina voor RolePermissions
  3. Selecteer een bestaande rol
  4. Koppel een of meerdere permissies
  5. Sla de wijzigingen op
Verwacht resultaat:

De gekoppelde permissies worden opgeslagen en zijn zichtbaar op de RolePermission pagina.

Component: UserRole
Doel:

Controleren of een gebruiker meerdere rollen kan krijgen.

Teststappen:
  1. Log in als Admin
  2. Open de UserRole
  3. Selecteer een gebruiker
  4. Koppel een rol aan de gebruiker
  5. Sla de wijzigingen op
Verwacht resultaat:

De rol wordt opgeslagen bij de gebruiker en blijft zichtbaar na het opnieuw laden van de pagina.

Component: UserPermissions
Doel:

Controleren of directe permissies correct werken.

Teststappen:
  1. Log in als Admin
  2. Open de pagina voor UserPermissions
  3. Selecteer een gebruiker
  4. Voeg een permissie toe
  5. Sla de wijzigingen op
Verwacht resultaat:

De permissie wordt gekoppeld aan de gebruiker en is zichtbaar in het overzicht.

Component: JWT
Doel:

Controleren of permissies correct in het token worden opgeslagen.

Teststappen:
  1. Log in met een testuser
  2. Haal het JWT token op
  3. Decodeer het token via jwt.io
  4. Controleer of permissieclaims aanwezig zijn
Verwacht resultaat:

De permissies van de gebruiker zijn zichtbaar als claims in het token.

Component: Toegang
Doel:

Controleren of een gebruiker toegang krijgt met de juiste rechten.

Teststappen:
  1. Log in met een gebruiker met voldoende rechten
  2. Navigeer naar een beveiligde pagina
  3. Voer een actie uit
Verwacht resultaat:

De gebruiker kan de pagina openen en de actie succesvol uitvoeren.

Component: Blokkering
Doel:

Controleren of autorisatie correct wordt afgedwongen.

Teststappen:
  1. Log in met een gebruiker zonder benodigde permissie
  2. Probeer een beveiligde pagina te openen
  3. Probeer een actie uit te voeren
Verwacht resultaat:

De actie wordt geweigerd of de pagina is niet zichtbaar.

Component: UI
Doel:

Controleren of UI zich aanpast aan gebruikersrechten.

Teststappen:
  1. Log in met een Admin
  2. Noteer zichtbare menu-onderdelen
  3. Log uit en log in als Operator
  4. Vergelijk zichtbare menu-onderdelen
Verwacht resultaat:

De Operator ziet minder functionaliteiten dan de Administrator.

"De kandidaat voert de testactiviteiten correct en volgens het testplan uit."

Testdemonstraties

Scenario 1: Aanmaken van een rol

Testdemonstratie RBAC Systeem

Gefaalt Download Video
Teststappen
1. Log in als Admin
2. Ga naar de pagina voor Roles
3. Kies de optie om een nieuwe rol aan te maken
4. Vul een naam in voor de rol
5. Sla de rol op
Testbevinding
De rol kon niet worden aangemaakt en werd niet opgeslagen in het systeem.

"Het testrapport bevat testresultaten van alle functionaliteiten. Alle resultaten worden voorzien van de juiste conclusies."

Testrapport RBAC systeem

Examen Bewijslast B1-K1-W4

27 okt 2025 - 30 okt 2025
Project

Implementatie Role Based Access Control (RBAC) binnen de Print Manager applicatie.

Doel van de test

Het doel van deze testfase was om te controleren of de gerealiseerde RBAC-functionaliteiten correct werken en voldoen aan de eerder opgestelde eisen en wensen.
Hierbij is specifiek gekeken naar autorisatie, gebruikersrollen, permissies en de werking van de gebruikersinterface.

Scenario Resultaat Bevinding / Toelichting
Scenario 1
Aanmaken van een rol 		Gefaalt De rol kon niet worden aangemaakt en werd niet opgeslagen in het systeem.
Scenario 2
Koppelen van permissies aan een rol 		Geslaagd Permissies konden correct aan een rol gekoppeld worden. De wijzigingen werden opgeslagen en waren direct zichtbaar op de RolePermissions-pagina.
Scenario 3
Koppelen van een rol aan een gebruiker 		Geslaagd Een gebruiker kon succesvol aan één of meerdere rollen worden gekoppeld. Na het opnieuw laden van de pagina bleven de toegewezen rollen correct zichtbaar.
Scenario 4
Toekennen van directe permissies 		Geslaagd Het systeem stood toe om directe permissies aan een gebruiker toe te kennen. De permissies werden correct opgeslagen en toegepast tijdens autorisatie.
Scenario 5
Autorisatie via JWT-token 		Geslaagd Na het inloggen werden de permissies van de gebruiker correct opgenomen in het JWT-token als claims. Bij controle via jwt.io waren deze claims zichtbaar en correct opgebouwd.
Scenario 6
Toegang tot beveiligde functionaliteit 		Geslaagd Gebruikers met voldoende rechten konden beveiligde pagina’s openen en acties uitvoeren zonder fouten.
Scenario 7
Blokkeren van toegang zonder rechten 		Geslaagd Gebruikers zonder de juiste permissies kregen geen toegang tot beveiligde onderdelen. Acties werden server-side geblokkeerd zoals verwacht.
Scenario 8
Dynamische gebruikersinterface 		Geslaagd De gebruikersinterface paste zich correct aan op basis van de rechten van de ingelogde gebruiker. Gebruikers met minder rechten zagen minder functionaliteiten in het menu.
Scenario 9
Werking na wijziging van rollen/permissies 		Geslaagd Na het aanpassen van rollen of permissies werd de autorisatie correct bijgewerkt. Na opnieuw inloggen werden de gewijzigde rechten direct toegepast.
Conclusie

Op basis van de uitgevoerde testscenario’s kan geconcludeerd worden dat het RBAC-systeem correct functioneert en voldoet aan de gestelde functionele en niet-functionele eisen.
Autorisatie wordt server-side afgedwongen, permissies worden correct verwerkt via JWT-tokens en de gebruikersinterface reageert dynamisch op de rechten van de gebruiker.
De gerealiseerde functionaliteiten zijn daarmee geschikt bevonden voor integratie binnen de applicatie.

B1-K1-W5

Doet verbetervoorstellen voor software.

Download W5 Compleet (ZIP)

"Analyseert systematisch alle beschikbare informatiebronnen voor mogelijke aanpassingen aan de software."

Analyseren – RBAC systeem

Examen Bewijslast B1-K1-W5

Tijdens de uitvoering van het RBAC-project heb ik op verschillende manieren informatie verzameld en geanalyseerd om het systeem te verbeteren en correct te realiseren. Hierbij heb ik gebruikgemaakt van feedback uit code reviews, testresultaten, overlegmomenten met developers en mijn eigen observaties tijdens het ontwikkelen.

De verzamelde informatie is gebruikt om technische problemen te analyseren, verbeterpunten vast te stellen en de implementatie beter aan te laten sluiten op de bestaande architectuur van de Print Manager applicatie.

Tijdens het project is mijn code meerdere keren beoordeeld via Pull Requests in Azure DevOps. Hierbij ontving ik feedback op onder andere:

  • structuur van services en mappers
  • naamgeving en consistentie van methods
  • foutafhandeling binnen API-endpoints
  • correcte toepassing van autorisatie-attributen
  • opbouw van de TokenService
  • herbruikbaarheid van services en componenten

Door deze opmerkingen te analyseren heb ik mijn code aangepast en verbeterd. Dit heeft geleid tot een beter onderhoudbare en technisch correctere implementatie van het RBAC-systeem.

Daarnaast heb ik geleerd om wijzigingen stapsgewijs door te voeren en beter rekening te houden met de bestaande architectuur en werkwijze binnen de applicatie.

Tijdens en na de implementatie heb ik verschillende functionaliteiten getest, zoals:

  • het aanmaken en koppelen van rollen en permissies
  • autorisatiecontrole via JWT
  • toegang tot beveiligde pagina’s
  • dynamisch tonen of verbergen van UI-onderdelen
  • directe permissies voor gebruikers
  • verwerking van permissieclaims binnen het token

Door deze testen uit te voeren kon ik controleren of het systeem werkte volgens de eerder opgestelde eisen en wensen.

Wanneer functionaliteit niet correct werkte, heb ik de oorzaak geanalyseerd binnen de backend-logica, databasekoppelingen of permissiecontroles en dit vervolgens aangepast.

De testresultaten vormden daarmee een belangrijke informatiebron voor het verbeteren van de stabiliteit, beveiliging en werking van het systeem.

Gedurende het project heb ik regelmatig overleg gehad met mijn praktijkbegeleider en andere developers. Tijdens deze momenten werden onder andere de volgende onderwerpen besproken:

  • de opbouw van de database-structuur
  • de juiste manier om permissies in JWT op te nemen
  • toepassing of Dependency Injection
  • beveiligingsaspecten van server-side autorisatie
  • haalbaarheid van bepaalde implementatiekeuzes
  • integratie binnen de bestaande softwarearchitectuur

Door deze feedback te analyseren kon ik beter begrijzen hoe het RBAC-systeem binnen de bestaande applicatie moest worden geïntegreerd.

Ook heeft pair programming mij geholpen om sneller inzicht te krijgen in complexe onderdelen van de code en mogelijke oplossingen voor technische problemen.

Tijdens het ontwikkelen merkte ik dat bepaalde onderdelen meer tijd kostten dan vooraf ingeschat. Vooral het werken met claims-based autorisatie en het begrijpen van de bestaande codebase waren in het begin lastig.

Door deze situatie te analyseren heb ik mijn werkwijze aangepast, bijvoorbeeld door:

  • eerder hulp te vragen wanneer ik vastliep
  • functionaliteit eerst in kleinere onderdelen op te bouwen
  • vaker tussentijds te testen
  • feedbackmomenten actiever te benutten
  • backend-functionaliteit eerst stabiel te maken voordat de UI verder werd uitgebreid

Daarnaast heb ik geconstateerd dat het belangrijk was om autorisatie eerst correct server-side te implementeren voordat aanvullende functionaliteiten in de gebruikersinterface werden toegevoegd.

Deze observaties hebben bijgedragen aan een betere planning, stabielere voortgang en een betrouwbaardere implementatie van het RBAC-systeem.

Tijdens het project zijn verschillende informatiebronnen gebruikt om het RBAC-systeem te analyseren en verbeteren. Door gebruik te maken van testresultaten, Pull Request feedback, overlegmomenten en eigen observaties konden verbeterpunten tijdig worden vastgesteld en verwerkt binnen de applicatie.

De analyse heeft bijgedragen aan een stabielere, beter onderhoudbare en veiligere implementatie van het RBAC-systeem binnen de bestaande Print Manager applicatie.

Bewijsstukken / Bijlages

Hieronder vind je de bewijslast en bijlages horende bij het analyseren van dit werkproces. Klik op een afbeelding voor een vergrootte weergave of download het bestand direct.

Bijlage 1

Screenshot Pull Request Azure DevOps

Bijlage 1
Download
Bijlage 2

Screenshot reviewcomments

Bijlage 2
Download
Bijlage 3

Screenshot aangepaste code na feedback

Bijlage 3
Download
Bijlage 4

Screenshot stand-up / overlegmomenten nov 24-27

Bijlage 4
Download
Bijlage 5

Screenshot sprint closing

Bijlage 5
Download
Bijlage 6

Screenshot pair programming bewijs tot pair programming

Bijlage 6
Download
Bijlage 7

Screenshot urenregistratie

Bijlage 7
Download
Bijlage 8

Screenshot aangepaste planning , meer uren als geschat (80)

Bijlage 8
Download
Bijlage 9

Screenshot logboek / eigen observaties

Bijlage 9
Download
Bijlage 10

Screenshot logboek / eigen observaties

Bijlage 10
Download

"Interpreteert en vertaalt wensen, reacties, testresultaten en/of meldingen naar realiseerbare verbetervoorstellen."

Verbetervoorstellen – RBAC systeem

Examen Bewijslast B1-K1-W5

Tijdens de uitvoering en afronding van het RBAC-project zijn op basis van testen, code reviews en eigen observaties enkele verbeterpunten naar voren gekomen. Deze verbeterpunten zijn vertaald naar concrete aanpassingen binnen de applicatie.

Situatie

Tijdens het testen van de functionaliteit voor het aanmaken en bewerken van rollen bleek dat deze actie niet correct werd uitgevoerd. Het systeem riep in sommige gewonnen een verkeerde serviceclient aan. Hierdoor werden wijzigingen niet opgeslagen zoals verwacht.

Analyse

Door gebruik te maken van breakpoints en het stap voor stap doorlopen van de code is onderzocht welke waarden in de variabelen werden gezet tijdens het uitvoeren van de actie. Hieruit bleek dat het component voor Create/Edit-functionaliteit automatisch de serviceclient koos op basis van de beste match. In dit geval werd echter de serviceclient van de UserRole aangeroepen in plaats van die van de Role.

Verbetervoorstel

Ik heb voorgesteld om de serviceclient niet langer automatisch te laten bepalen, maar deze expliciet (strict) aan te roepen binnen het component. Hierdoor wordt altijd de juiste service gebruikt voor de betreffende functionaliteit.

Resultaat

Na het doorvoeren van deze wijziging werkte het aanmaken en bewerken van rollen correct en voorspelbaar. Hiermee is de stabiliteit en betrouwbaarheid van de RBAC-functionaliteit verbeterd.

Situatie

Na de implementatie of het RBAC-systeem was duidelijk geworden dat het voor beheerders niet eenvoudig was om snel inzicht te krijgen in de huidige opzet van rollen, permissies en toebehoren. De informatie was er wel, maar verspreid over meerdere paginas.

Analyse

Op basis van eigen gebruikservaring en het testen van de applicatie is vastgesteld dat een overzicht zou bijdragen aan een beter begrip van de status en het beheerproces zou versnellen.

Verbetervoorstel

Er is voorgesteld om op het dashboard van de applicatie overzichtskaarten (Radzen cards) toe te voegen. Deze kaarten tonen onder andere het aantal bestaande rollen, permissies en gebruikerskoppelingen.

Resultaat

Door deze toevoeging is het mogelijk om op de landing page inzicht te krijgen in de configuratie van het RBAC-systeem. Dit verbetert de gebruiksvriendelijkheid en ondersteunt beheerders bij het uitvoeren van hun taken.

Situatie

Tijdens het testen van de RBAC-functionaliteit bleek dat gebruikers en beheerders niet direct konden zien welke rollen en permissies gekoppelde waren aan een account zonder naar aparte beheerpagina’s te navigeren.

Analyse

Tijdens mijn gebruik van de applicatie en feedbackmomenten met developers werd duidelijk dat een centraal overzicht op de profielpagina het beheer overzichtelijker zou maken. Hierdoor kan sneller gecontroleerd worden welke rechten actief zijn voor een gebruiker.

Verbetervoorstel

Er is voorgesteld om op de profile pagina een overzicht toe te voegen van de gekoppelde rollen en permissies van de ingelogde gebruiker. Dit overzicht is verwerkt binnen de bestaande gebruikersinterface.

Resultaat

Door deze toevoeging kunnen gebruikers en beheerders inzicht krijgen in rollen en permissies zonder meerdere paginas te openen. Dit verbetert de gebruikersgemak en sluit aan op de eerder toegevoegde dashboardoverzichten.

De verbeteringen zijn gebaseerd op analyse van testresultaten, codeinspectie, feedback van developers en mijn experience tijdens het gebruik van het systeem. Door deze aanpassingen is zowel de technische werking als de ervaring van het RBAC-systeem beter geworden.

Bewijsstukken / Bijlages

Hieronder vind je de bewijslast en bijlages horende bij de verbetervoorstellen van dit werkproces. Klik op een afbeelding voor een vergrootte weergave of download het bestand direct.

Bijlage 1

Screenshot serviceclient aanpassing

Bijlage 1
Download
Bijlage 2

Screenshot dashboard Radzen cards

Bijlage 2
Download
Bijlage 3

Screenshot voorstel authentication cards/p>

Bijlage 3
Download
Bijlage 4

Screenshot profielpagina overzicht

Bijlage 4
Download
Bijlage 5

Screenshot voorstel profiel overzicht

Bijlage 5
Download

"Stelt vast welke werkzaamheden benodigd zijn, evenals een haalbare planning."

Onderbouwing planning verbeteringen RBAC systeem

Op basis van de analyse van testresultaten, code reviews en eigen observaties is vastgesteld welke werkzaamheden nodig waren om verbeteringen door te voeren aan het RBAC-systeem. De werkzaamheden zijn geplant binnen de laatste fase van het project en sluit aan op de eerder opgestelde Gantt.

De verbeteractiviteiten zijn in de periode van 27 oktober 2025 tot en met 6 november 2025 uitgevoerd. Deze periode sluit aan op de test en afrondingsfase van het project, waar functionaliteiten werden gecheckt, bewerkt en weer getest voordat de Pull Request werd goedgekeurd en gemerged.

Prioritering

Voor de planning is gebruikgemaakt van prioritering op basis van het belang en de noodzaak binnen de afrondingsfase:

  • Must = essentieel voor het oplossen van falende testscenario's en blocker-bugs.
  • Should = belangrijk voor de UI-ervaring, beheerbaarheid en het afronden van de merge/PR.

Onderbouwing van planning en tijdsinschatting
Verbetering & Werkzaamheden Prioriteit Tijdsinschatting Onderbouwing
Correct aanroepen van serviceclient bij rolbeheer
Onderzoeken van foutieve service-aanroepen, debuggen met breakpoints, aanpassen van de serviceclient-aanroep binnen het component en opnieuw testen van de functionaliteit 		Must 4 uur Deze verbetering was noodzakelijk omdat rollen niet correct opgeslagen werden. Zonder deze aanpassing werkte de RBAC-functionaliteit niet stabiel.
Verbeteren van overzicht van rollen en permissies
Ontwerpen en toevoegen van dashboardkaarten (Radzen cards), ophalen van statistieken en verwerken binnen de gebruikersinterface 		Should 3 uur Deze verbetering verhoogde het gebruiksgemak voor beheerders door sneller inzicht te geven in rollen, permissies en gebruikerskoppelingen.
Toevoegen van rollen- en permissieoverzicht op profielpagina
Toevoegen van een overzicht van gekoppelde rollen en permissies op de profielpagina van gebruikers en verwerken binnen de gebruikersinterface 		Should 2 uur Deze verbetering geeft gebruikers en beheerders sneller inzicht in de actieve rollen en permissies van een account en sluit aan op de eerder toegevoegde dashboardoverzichten.
Verwerken van Pull Request feedback
Doorvoeren van reviewcomments, refactoring van methods en controleren van naamgeving en structuur 		Must 4 uur Deze werkzaamheden waren noodzakelijk om de codekwaliteit en aansluiting op de bestaande architectuur te verbeteren.
Opnieuw testen van RBAC-functionaliteiten
Uitvoeren van regressietesten na wijzigingen binnen rollen, permissies en autorisatie 		Must 3 uur Door opnieuw te testen kon gecontroleerd worden of eerdere functionaliteiten correct bleven werken na de verbeteringen.
Voorbereiden van merge en sprint-closing
Controleren van merge-conflicten, afronden van Pull Request en voorbereiden van opname in sprintbranch 		Should 2 uur Deze werkzaamheden waren nodig om de functionaliteit correct op te leveren binnen de sprintplanning.

Relatie met projectplanning

De bovenstaande werkzaamheden sloten aan op de eerder geplande test- en afrondingsfase uit de Gantt-chart. Tijdens deze fase lag de focus op:

  • uitvoeren van testen
  • verwerken van feedback
  • verbeteren van stabiliteit
  • afronden van openstaande functionaliteiten
  • voorbereiden van de definitieve merge

Omdat een deel van de verbeteringen voortkwam uit testresultaten en Pull Request feedback, zijn deze werkzaamheden uitgevoerd tijdens dezelfde projectfase als de testactiviteiten.

Haalbaarheid van de planning

De planning voor de verbeteractiviteiten is afgestemd op de beschikbare tijd binnen de laatste sprintfase van het project. Hierbij is rekening gehouden met:

  • beschikbare uren binnen de sprint
  • tijd voor code reviews
  • tijd voor het opnieuw testen van functionaliteiten
  • verwerking van feedback van developers en begeleiders
  • afronding van de Pull Request voor de sprint-closing

Door de verbeteringen op te splitsen in kleinere werkzaamheden bleef de planning haalbaar en beheersbaar.

De verbeterwerkzaamheden zijn gepland op basis van testresultaten, feedbackmomenten en eigen observaties tijdens de ontwikkeling van het RBAC-systeem. De werkzaamheden sloten aan op de test- en afrondingsfase van de bestaande projectplanning en konden binnen de beschikbare sprintperiode worden uitgevoerd.

B1-K2-W1

Voert overleg.

Download W1 Compleet (ZIP)

"De kandidaat neemt actief deel aan het overleg waarbij relevante onderwerpen worden ingebracht en de juiste vragen worden gesteld."

Looptijd: Gedurende het hele project
Deelname tussen: Seraja, Mitchel en Liam
Inleiding

Tijdens het RBAC-project heb ik actief deelgenomen aan verschillende overlegmomenten en samenwerkingen met andere developers en mijn praktijkbegeleider. Deze deelname vond plaats tijdens stand-ups, code reviews en informele overlegmomenten gedurende het ontwikkelproces.

Mijn actieve deelname bestond uit het stellen van vragen, het inbrengen van problemen en het reageren op feedback, zodat het project op een goede manier voortgang kon blijven maken.

Code Reviews & Pull Requests

Tijdens het project heb ik meerdere Pull Requests aangemaakt waarin mijn code werd beoordeeld door andere developers. Hierin ontving ik feedback op mijn implementatie.

Feedback ontvangen over:
de structuur van services het gebruik van mappers de toepassing van autorisatie
Actieve reactie op basis van feedback:
1

aanpassingen door te voeren in mijn code

2

opnieuw te testen

3

verbeteringen door te voeren totdat de code voldeed

Problemen inbrengen

Tijdens het ontwikkelproces heb ik zelf actief problemen ingebracht wanneer ik ergens tegenaan liep om samen met het team oplossingen te vinden.

Praktijkvoorbeeld

Een voorbeeld hiervan is het probleem met het aanmaken van rollen, waarbij een verkeerde serviceclient werd aangeroepen. Door dit probleem te analyseren en bespreekbaar te maken, kon er gericht naar een oplossing worden gezocht.

Actief Vragen Stellen:

Tijdens deze momenten heb ik actief vragen gesteld om beter te begrijpen hoe bepaalde onderdelen geïmplementeerd moesten worden en om mijn aanpak te verbeteren.

Vragen gesteld over:
de implementatie van autorisatie
het gebruik van JWT-tokens
de structuur van de RBAC-opzet
Meedenken over verbeteringen

Tijdens het project heb ik actief meegedacht over verbeteringen binnen het systeem:

Dashboardoverzicht

het voorstel om overzicht te creëren op het dashboard met kaarten (Radzen cards)

Gebruikersinterface

het verbeteren van de gebruikersinterface zodat deze duidelijker en overzichtelijker wordt

Deze ideeën zijn besproken en afgestemd met andere developers voordat ze verder werden uitgewerkt.

Actieve deelname aan het ontwikkelproces

Tijdens het project heb ik actief deelgenomen aan het ontwikkelproces door:

functionaliteiten zelfstandig uit te werken
feedback te verwerken
problemen op te lossen
verbeteringen door te voeren
Door deze actieve houding bleef ik betrokken bij het project en kon ik bijdragen aan een stabiele en werkende implementatie van het RBAC-systeem.
Conclusie

Door actief deel te nemen aan overlegmomenten, feedback te verwerken en zelf onderwerpen in te brengen, heb ik een belangrijke bijdrage geleverd aan het ontwikkelproces van het RBAC-systeem. Deze actieve deelname heeft geholpen om problemen tijdig op te lossen en het project succesvol af te ronden.

Screenshots ter onderbouwing van de actieve deelname, pr comments en overlegmomenten tijdens de projectduur.

Bijlage 1

Mijn pr comments

Bijlage 1
Download
Bijlage 2

Mijn pr comments

Bijlage 2
Download
Bijlage 3

Design meeting notities

Bijlage 3
Download
Bijlage 4

Sprint standup notities

Bijlage 4
Download
Bijlage 5

Vragen/antwoord Collega

Bijlage 5
Download
Bijlage 6

Vragen/antwoord Collega

Bijlage 6
Download

"De kandidaat stemt regelmatig en tijdig af met projectteamleden en opdrachtgever over de voortgang en eventuele knelpunten."

Looptijd: Gedurende het hele project
Afgestemd tussen: Seraja, Mitchel en Liam
Inleiding

Tijdens het RBAC-project hebben meerdere overlegmomenten plaatsgevonden waarin belangrijke keuzes, knelpunten en voortgang zijn besproken. Deze afstemming vond plaats tijdens stand-ups, design momenten en informele overlegmomenten met andere developers.

Niet alle momenten zijn formeel vastgelegd, maar de belangrijkste afgestemde zaken zijn hieronder overzichtelijk weergegeven op basis van het ontwikkelproces en de uitgevoerde werkzaamheden.

Planning en scope

Tijdens het project bleek dat de geplande tijd van het ticket niet voldoende was om de volledige RBAC-functionaliteit te realiseren.

Knelpunt & Inzicht:

Dit is in eerste instantie te laat aangekaart, waardoor er zonder overleg over de geplande uren heen is gewerkt. Na dit inzicht is dit alsnog besproken en afgestemd met betrokken developers.

Besluit & Actie

Er is besloten om de scope en beschikbare tijd uit te breiden zodat de functionaliteit correct afgerond kon worden.

Dit moment heeft geleid tot een verbeterde manier van communiceren en het eerder signaleren van knelpunten.
Verdeling van werkzaamheden

Tijdens het project is een andere stagiaire gestopt die ook betrokken was bij het RBAC-systeem. Hierdoor kwam een groter deel van het werk bij één persoon te liggen.

Dit is afgestemd binnen het team en heeft geleid tot:
uitbreiding van de beschikbare tijd
meer begeleiding vanuit developers
duidelijkere afstemming over prioriteiten
Functionele keuzes

Tijdens ontwerpmomenten zijn de functionele specificaties en restricties van het RBAC-systeem gedefinieerd:

Permission-pagina

Er is afgestemd hoe de Permission-pagina eruit moest zien, aangezien deze geen CRUD-functionaliteit bevat. Besloten is dat deze pagina een overzicht toont zonder bewerkfunctionaliteit, in tegenstelling tot andere entiteiten.

Koppeling structuur

Er is afgestemd hoe rollen en permissies gekoppeld moesten worden, zodat meerdere permissies per rol mogelijk zijn en gebruikers meerdere rollen kunnen hebben.

Directe permissies

Ook is afgestemd dat directe permissies ondersteund moesten worden, zodat uitzonderingen mogelijk zijn naast de rolstructuur.

UI en gebruikerservaring

De visuele weergave en dynamische interface-elementen zijn zorgvuldig afgestemd met het team:

Deze voorstellen zijn besproken en afgestemd met andere developers voordat ze verder zijn uitgewerkt.
Conditionele rendering

Er is afgestemd dat de gebruikersinterface zich moet aanpassen op basis van rechten (conditionele rendering).

Dashboardkaarten

Tijdens het project zijn verbeteringen voorgesteld, zoals het toevoegen van overzicht op het dashboard met behulp van kaarten (bijvoorbeeld aantallen rollen en permissies).

Technische implementatie

Op technisch niveau zijn er fundamentele keuzes gemaakt en afgestemd om de veiligheid en integratie te optimaliseren:

Server-side autorisatie

Er is afgestemd dat autorisatie server-side moet plaatsvinden en niet alleen via de UI.

JWT Claims

Er is gekozen om permissies op te nemen in JWT-tokens als claims, zodat deze bij iedere API-aanroep gecontroleerd kunnen worden.

Architectuur aansluiting

Ook is afgestemd dat de implementatie moet aansluiten op de bestaande architectuur (Database, Core, API) en geen aparte structuur mag vormen.

Samenwerking & Communicatie

De opgedane leerpunten hebben direct geleid tot concrete afspraken voor een betere afstemmingsfrequentie en sterkere samenwerking:

Dit heeft geleid tot een betere samenwerking en een duidelijkere verdeling van verantwoordelijkheden binnen het project.
Eerder signaleren

Tijdens het project is afgestemd dat het belangrijk is om eerder aan de bel te trekken bij problemen of vertraging.

Vaker afstemmen

Naar aanleiding van eerdere knelpunten is afgesproken om vaker en duidelijker af te stemmen over voortgang en technische keuzes.

Conclusie

Door gedurende het project regelmatig af te stemmen over planning, functionaliteit en technische keuzes kon het RBAC-systeem uiteindelijk correct worden gerealiseerd. De afstemming heeft bijgedragen aan het oplossen van knelpunten, het verbeteren van de samenwerking en het succesvol afronden van het project.

Screenshots ter onderbouwing van de afstemmingsmomenten en communicatie tijdens het RBAC-project.

Bijlage 1

Sprintplanning notities

Bijlage 1
Download
Bijlage 2

Sprintstandup notities

Bijlage 2
Download
Bijlage 3

permissie gedrag afgestemd met Collega

Bijlage 3
Download
Bijlage 4

Teams gesprek met merge en fix

Bijlage 4
Download
Bijlage 5

Bijgewerkte API goedkeuring

Bijlage 5
Download

"De gemaakte afspraken zijn eenduidig vastgelegd."

Datum overleg: 30-10-2025
Deelnemers: Seraja, Mitchel, Sem en Liam
Doel

Het vastleggen van afspraken en overeenkomsten voor de implementatie van het Role Based Access Control (RBAC) systeem binnen de Print Manager applicatie.

Beveiligingsnormen & Tokens
JWT Claims & Permissies

Permissies moeten worden opgenomen in de bestaande JWT tokens als claims, zodat bij iedere aanvraag gecontroleerd kan worden wat een gebruiker mag doen.

Server-side Beveiliging

Beveiliging moet server-side worden afgedwongen, zodat toegang niet afhankelijk is van alleen de gebruikersinterface.

API-endpoint Beveiliging

API-endpoints moeten beveiligd worden met bestaande autorisatie-attributen binnen het .NET framework.

HMAC-SHA512 Token Signing

Signing van tokens moet plaatsvinden met HMAC-SHA512, zodat de integriteit en veiligheid van het token gewaarborgd blijft.

Beveiligingsstructuur Behoud

De bestaande beveiligingsstructuur van de applicatie mag niet worden aangetast door de implementatie van het RBAC-systeem.

Conditionele Rendering

De gebruikersinterface moet gebruik maken van conditionele rendering, zodat gebruikers geen functionaliteiten zien waarvoor zij geen rechten hebben.

Functionele Richtlijnen & Eisen
Koppeltabellen Database

Er moet gebruik gemaakt worden van koppeltabellen voor database-relaties (zoals UserRole en RolePermission) om many-to-many relaties correct te ondersteunen.

CRUD-functionaliteit

Iedere entity moet een eigen pagina hebben voor CRUD-functionaliteit, zowel voor hoofdentiteiten als koppeltabellen.

Permission-pagina overzicht

De Permission-pagina hoeft geen volledige CRUD-functionaliteit te bevatten, omdat permissies centraal worden beheerd via ModuleConstants.

Veelvoudige koppelingen

Rollen moeten meerdere permissies kunnen bevatten en gebruikers moeten aan één of meerdere rollen gekoppeld kunnen worden.

Directe Permissies

Directe permissies voor gebruikers moeten ondersteund worden via een aparte koppeling (UserPermission), zodat uitzonderingen mogelijk zijn.

Rechtencontrole & Blokkering

Bij iedere actie moet gecontroleerd worden of de gebruiker de juiste rechten heeft, en moet de actie worden geblokkeerd wanneer deze ontbreken.

Architectuur & Implementatie
Drie-lagenarchitectuur

Het RBAC-systeem moet geïntegreerd worden binnen de bestaande drie-lagenarchitectuur (Database, Core, API).

Structuur Print Manager

De implementatie moet aansluiten op de huidige werkwijze en structuur van de Print Manager applicatie.

Architectuur consistentie

Er mogen geen losse of afwijkende structuren ontstaan buiten de bestaande architectuur.

Entity Framework Core

Entity Framework Core moet gebruikt worden voor database-interacties, zodat de datalaag consistent blijft.

Onderhoudbaarheid & Uitbreidbaarheid

De oplossing moet onderhoudbaar en uitbreidbaar blijven, zodat nieuwe rollen en permissies eenvoudig toegevoegd kunnen worden.

Afspraken voor personen die werken aan dit systeem
Pull Request Feedback

Feedback uit Pull Requests moet worden verwerkt voordat code wordt gemerged.

Project Naamgeving & Structuur

Code moet aansluiten op de bestaande structuur en naamgeving binnen het project.

Kwaliteit & Testen

Functionaliteit moet getest worden voordat deze wordt opgeleverd.

Tijdige Afstemming

Bij onduidelijkheden of problemen moet tijdig afgestemd worden met andere developers.

Begrijpelijke Wijzigingen

Wijzigingen moeten duidelijk en overzichtelijk worden doorgevoerd zodat andere developers het kunnen begrijpen en onderhouden.

Screenshots ter onderbouwing van de eenduidig vastgelegde afspraken en overeenkomsten tijdens het project.

Bijlage 1

Sprintplanning notities

Bijlage 1
Download
Bijlage 2

Sprintsstandup notities

Bijlage 2
Download
Bijlage 3

Designmeeting notities

Bijlage 3
Download
Bijlage 4

Mogelijke afspraken notities van mondeling overleg

Bijlage 4
Download

"De kandidaat houdt zich aan gemaakte afspraken."

Status: Gemaakte afspraken zijn consequent en succesvol nagekomen
Inleiding

Tijdens de ontwikkeling van het RBAC-systeem heb ik de gemaakte afspraken actief nageleefd en toegepast binnen de implementatie. Deze afspraken hadden betrekking op beveiliging, functionaliteit, integratie en werkwijze binnen het team.

Security

Op het gebied van security zijn de afspraken nageleefd door permissies op te nemen in JWT-tokens als claims en autorisatie server-side af te dwingen. API-endpoints zijn beveiligd met autorisatie-attributen en acties zonder de juiste rechten worden geblokkeerd. Daarnaast is de gebruikersinterface aangepast zodat alleen functionaliteiten zichtbaar zijn waarvoor een gebruiker toestemming heeft.

Beveiligingsrisico's zijn geminimaliseerd door server-side validatie en JWT claims te combineren.
Functionaliteit

Ook de functionele afspraken zijn nagekomen. De database is opgebouwd met koppeltabellen zoals UserRole en RolePermission om relaties correct te modelleren. Voor de meeste entiteiten zijn aparte pagina’s ontwikkeld voor CRUD-functionaliteit, terwijl de Permission-structuur bewust centraal en beheerd is gebleven via ModuleConstants. Daarnaast is ondersteuning toegevoegd voor directe permissies via een aparte koppeling, zodat uitzonderingen mogelijk zijn.

Flexibiliteit is gewaarborgd door zowel groepsgebaseerde als individuele permissies te ondersteunen.
Integratie

Op het gebied van integratie is het RBAC-systeem volledig binnen de bestaande architectuur van de applicatie ontwikkeld. De oplossing maakt gebruik van Entity Framework Core en sluit aan op de bestaande structuur van Database, Core en API. Hierdoor blijft de applicatie onderhoudbaar en consistent met de rest van het project.

Het gebruik van Entity Framework Core zorgt voor een stabiele en uniforme datalaag.
Werkwijze

De afspraken over werkwijze zijn nageleefd door feedback te verwerken, code aan te passen en functionaliteit te testen voordat deze werd opgeleverd. Tijdens het ontwikkelproces zijn verbeteringen doorgevoerd op basis van feedback en testresultaten, waardoor de kwaliteit van het systeem is verhoogd.

Doorlopende feedback en gerichte tests hebben geslaagd resultaat opgeleverd.
Conclusie

Door deze afspraken consequent toe te passen is het RBAC-systeem stabiel en volgens de gestelde eisen en richtlijnen gerealiseerd.

De onderstaande video toont een demonstratie van de gerealiseerde functionaliteiten en testscenario's van het RBAC-systeem, waarin de gemaakte afspraken in werking te zien zijn.

RBAC Werking & Testen

Tijdens deze video wordt gedemonstreerd hoe de gebruikersinterface zich aanpast op basis van rechten, en hoe de gerealiseerde functionaliteiten zoals rollen, permissies en gebruikerskoppelingen in praktijk werken.

Download Demo Video (MP4)

Het naleven van de gemaakte afspraken is direct terug te zien in onderstaand bewijsmateriaal, bestaande uit implementatie-screenshots, database-structuren en werkende demonstratievideo's:

Bijlage 1

De implementatie van JWT-tokens met permissieclaims

Bijlage 1
Download
Bijlage 2

Beveiligde API-endpoints en server-side autorisatie

Bijlage 2
Download
Bijlage 3

De database-structuur met koppeltabellen

Bijlage 3
Download
Demo (UI-rechten)

De gebruikersinterface die zich aanpast op basis van rechten

Bekijk Demo
Demo (Rollen & Permissies)

De gerealiseerde functionaliteiten zoals rollen, permissies en gebruikerskoppelingen

Bekijk Demo
K1-W4-Testen & Demo

Uitgevoerde testscenario’s en werkende demonstratie van het systeem

Ga naar B1-K1-W4

Voor gerealiseerde functionaliteiten verwijs ik naar K1-W3-Gerealiseerde functionaliteit

B1-K2-W2

Presenteert het opgeleverde werk.

Download W2 Compleet (ZIP)

"De kandidaat legt de functionaliteiten uit met een goed opgebouwd en met argumenten onderbouwd verhaal."

Examen Presentatie - RBAC

Tijdens deze presentatie van ongeveer 8 minuten licht ik de werking, architectuur en technische realisatie van het Role-Based Access Control (RBAC) systeem toe aan mijn stagebegeleider en collega-developers.

Gebruik de interactieve timestamps in de onderstaande tabel om direct naar specifieke onderwerpen of demonstraties in de video te springen.

Download Presentatie Video PowerPoint (.pptx)
Uitgelegde functionaliteiten RBAC

Tijdens de presentatie zijn de volgende functionele en technische aspecten van het RBAC-systeem uitgelegd. Klik op een tijdstip om direct naar dit moment in de video te springen.

Tijdstip Uitgelegde functionaliteit / onderwerp Onderbouwing / Context
00:01:01 CRUD beheerpagina's Demonstratie van de nieuw aangemaakte CRUD pagina's voor Roles, Permissions, UserRoles, UserPermissions en RolePermissions.
00:01:14 Rollen en permissies beheren Uitleg over hoe een administrator via de gebruikersinterface nieuwe rollen en permissies kan invoeren en bewerken.
00:01:30 Gebruikers groeperen in rollen Demonstratie van het toewijzen van gebruikers aan rollen (zoals Admin en Operator) om de rechtenstructuur centraal te beheren.
00:01:45 Directe permissies koppelen Uitleg over hoe een specifieke gebruiker een extra recht kan krijgen zonder direct een nieuwe rol te hoeven aanmaken (UserPermission).
00:02:08 Bijgewerkte JWT met permissions Uitleg over de uitbreiding van het JWT token, zodat ook de rollen en rechten van de gebruiker worden meegenomen als claims voor server-side controle.
00:03:08 Dependency Injection (DI) Technische toelichting over hoe autorisatieservices en DbContext via de built-in DI-container van ASP.NET Core worden geregistreerd.
00:04:02 Werking en Uitleg van de API Mondelinge uitleg van wat een API in de basis doet en hoe deze de communicatie tussen frontend en backend-architectuur regelt.
00:05:05 Many-to-Many database relaties Toelichting op de implementatie van koppeltabellen op databaseniveau om redundante data te voorkomen en relaties overzichtelijk te houden.
00:07:01 Nut van koppeltabellen (Vraag) Toelichting op het nut en de werking van koppeltabellen (UserRole, UserPermission en RolePermission) om dataredundantie te voorkomen.

"De kandidaat stemt de stijl van communiceren en de presentatiemiddelen af op de toehoorders."

Examen Presentatie - RBAC

Tijdens deze presentatie van ongeveer 8 minuten licht ik de werking, architectuur en technische realisatie van het Role-Based Access Control (RBAC) systeem toe aan mijn stagebegeleider en collega-developers.

Gebruik de interactieve timestamps in de onderstaande secties om direct naar specifieke onderwerpen of demonstraties in de video te springen.

Download Presentatie Video PowerPoint (.pptx)
Gebruikte manier van presenteren

Powerpoint presentatie van ongeveer 8 minuten.

Hoe ik contact behield

Door mijn stagebegeleider en de andere developer in de ogen te blijven aankijken tijdens het praten en mijn uitleg aan te passen naar hun niveau. Ik probeerde alles op een speelse en simpele manier uit te leggen die een niet-developer ook zou snappen. Daarnaast sprak ik duidelijk en gebruikte ik een presentatie puur als ondersteuning met steekwoorden, daarom zaten er ook geen afbeeldingen in de powerpoint..

Toegelichte afkortingen en vakjargon
CRUD

Create, Read, Update, Delete.

Permissions & Roles

Permissies/toegangen en Rollen.

JWT (JSON Web Token)

Fungeert als een digitaal toegangspasje.

Koppeltabellen

Gebruikt om veel-op-veel relaties te vermijden. Rollen, Permissies en Users worden hieraan gekoppeld (bijv. RolePermissions fungeert als koppeling tussen rollen en permissies).

3-Lagen structuur

Core, Db en API.

API

De afkorting werd toegelicht door de mede-developer, maar ik heb mondeling uitgelegd wat een API in de basis doet.

Dependency Injection

Geeft klassen hun benodigdheden zonder dat ze steeds opnieuw gemaakt hoeven te worden. Daarbij horen de volgende implementaties:

  • Singleton: 1x in de runtime van de applicatie.
  • Scoped: Bij ieder HTTP verzoek.
  • Transient: Bij iedere service aanroep.
Many-to-Many Relaties

Uitleg via een schoolsysteem. Studenten kunnen geen diploma's direct 'hebben', dat moet gesplitst worden zodat iedereen apart iets kan bezitten d.m.v. refereren met foreign keys in koppeltabellen.

"De kandidaat beantwoordt vragen met steekhoudende argumenten."

Examen Presentatie - RBAC

Tijdens deze presentatie van ongeveer 8 minuten licht ik de werking, architectuur en technische realisatie van het Role-Based Access Control (RBAC) systeem toe aan mijn stagebegeleider en collega-developers.

Gebruik de interactieve timestamps onder de vragen om direct naar de specifieke beantwoording in de video te springen.

Download Presentatie Video PowerPoint (.pptx)
Q1
Wat is een API?

Vraag 1: Wat is een API (00:04:02)

Mijn Beantwoording:

Deze vraag kreeg ik op een moment dat ik hem niet direct verwachtte. Ik twijfelde kort over de exacte benaming van de afkorting, maar heb vervolgens wel correct uitgelegd wat de functie van een API binnen de applicatie is. Ik heb daarna in de basis uitgelegd dat wanneer je gegevens wilt ophalen of een actie wilt uitvoeren binnen een applicatie, de API verantwoordelijk is voor de communicatie tussen onderdelen van het systeem. Mitchel lichtte daarna nog kort de exacte afkorting toe.

Demonstratie in video: 00:04:02
Q2
Wat is het nut van koppeltabellen?

Vraag 2: Wat is het nut van de koppeltabellen (00:07:01)

Mijn Beantwoording:

Seraja vroeg naar de koppeltabellen en het nut daarvan. Ik gaf aan dat deze koppeltabellen (bijvoorbeeld UserRole) er zijn om in de database de keys aan elkaar te koppelen, zodat je rollen aan gebruikers toe kunt wijzen zonder data dubbel te hoeven opslaan. Zo maak je op een nette manier een veel-op-veel relatie. Dit concept heb ik ook meteen doorgetrokken naar hoe dit in het project voor UserPermission en RolePermission werkt.

Demonstratie in video: 00:07:01

B1-K2-W3

Reflecteert op het werk.

Download W3 Compleet (ZIP)

"De kandidaat benoemt zowel positieve- als verbeterpunten van het proces van zowel eigen als teamprestaties."

Opname Feedbackgesprek - RBAC

Examen Bewijslast B1-K2-W3

Beluister hier de geluidsopname van het feedbackgesprek met stagebegeleider Seraja en mede-developer Mitchel. Hierin bespreken we de sterke punten van de implementatie en de concrete verbeterpunten voor het RBAC-systeem.

Download Audio
Eigen prestaties
Positieve punten:
  • Veel geleerd omdat het pas mijn tweede project was binnen het bedrijf
  • Geleerd om zelfstandiger te werken
  • Snel nieuwe technieken geleerd
  • Ik nam verantwoordelijkheid voor mijn taken
  • Zelfs na het stoppen van de andere projectmedewerker/stagiaire heb ik zelfstandig het project afgemaakt
Verbeterpunten:
  • Ik vroeg soms te laat om hulp
  • Ik had geen goede takenverdeling/planning
  • Ik begon sommige tasks zonder voldoende voorbereiding of analyse
  • Ik vertrouwde in het begin soms te veel op AI-tools zonder alles volledig zelf te controleren
  • Ik onderschatte soms hoeveel tijd bepaalde taken kostten
  • Ik had sneller aan de bel moeten trekken wanneer ik vastliep
Samenwerking met Sem / Teamprestaties
Positieve punten:
  • We hadden een goede samenwerking en communicatie
  • We waren erg gemotiveerd omdat veel nieuw voor ons was
  • We konden snel schakelen wanneer prioriteiten veranderden binnen het project
  • We vulden elkaar goed aan qua kennis en ondersteuning
  • Wanneer iemand vastliep of het overzicht verloor, hielpen we elkaar verder
  • We hielden elkaar goed op de hoogte, ook bij afwezigheid of ziekte
Verbeterpunten:
  • In het begin ontbrak er structuur in onze werkwijze en taakverdeling
  • We waren soms zo enthousiast om nieuwe dingen te leren dat we details over het hoofd zagen
  • We hadden meer moeten documenteren; daardoor missen we nu soms context voor het examen
  • We hadden tussentijds vaker moeten testen om later tijd te besparen
  • Omdat we nog weinig ervaring hadden met Azure DevOps en Git, verliep versiebeheer in het begin moeizaam
  • Taken hadden duidelijker verdeeld moeten worden
  • We hadden eerder extra tijd moeten investeren in cursussen/trainingen om sterker te starten

"De kandidaat reageert actief op ontvangen feedback."

Opname Feedbackgesprek - RBAC

Examen Bewijslast B1-K2-W3

Beluister hier de geluidsopname van het feedbackgesprek met stagebegeleider Seraja en mede-developer Mitchel. Hierin bespreken we de sterke punten van de implementatie en de concrete verbeterpunten voor het RBAC-systeem.

Download Audio
Reactie op feedback
  • Ik luisterde actief naar de ontvangen feedback en liet de ander uitpraten
  • Ik reageerde inhoudelijk op feedback en dacht mee over verbeteringen
  • Ik interpreteerde de feedback op de juiste manier en koppelde dit terug aan concrete situaties binnen het project
  • Ik erkende mijn verbeterpunten, zoals te laat hulp vragen en onvoldoende voorbereiding
  • Ik reageerde niet defensief op kritiek en stond open voor verbeteringen
  • Tijdens het gesprek reflecteerde ik op mijn eigen handelen en benoemde ik wat ik hiervan geleerd heb
  • Ik gaf voorbeelden van hoe bepaalde problemen later beter gingen, zoals werken met Git en Azure DevOps
  • Ik dacht actief mee over hoe problemen in toekomstige projecten voorkomen kunnen worden
  • Ik reageerde actief op vragen en feedback tijdens het gesprek

Project Planning

Tip: Pas het weeknummer aan voor de resterende planning te zien.

Contact

Heeft u een vraag of wilt u samenwerken? Neem gerust contact op, ik reageer zo snel mogelijk.

Contactgegevens

Bel mij +31 6 13970577
Mail mij liamvandenakker@gmail.com

Stuur een bericht

Laden
Uw bericht is verzonden, bedankt!