Skip to main content

UC-BEH-ACC-003 — Accountrollen beheren

1. Kerngegevens

VeldWaarde
Usecase-IDUC-BEH-ACC-003
NaamAccountrollen beheren
DomeinBeheerder / Accountbeheer
Primaire actorBeheerder
Secundaire actor(en)Frontend, backend, database, autorisatiecomponent, identity-providerkoppeling, accountlogkanaal
RolcontextActieve beheerdercontext; server-side bepaald vanuit de ingelogde gebruiker
Betrokken schermenAccounts beheren > Accountdetail > Rollen
Gerelateerde usecasesUC-BEH-ACC-001, UC-BEH-ACC-002, UC-BEH-ACC-004, UC-BEH-ACC-005, UC-BEH-ACC-006, UC-BEH-ACC-007, UC-BEH-ACC-008, UC-BEH-ACC-009, UC-BEH-ACC-010, UC-GEN-ACC-001, UC-GEN-ACC-002, UC-GEN-ACC-005
Primaire entiteitenUsers, Roles, UserRoles, UserSettings, ProfileAvatars, accountlogkanaal
Secundaire entiteiten / eventsUserRelationships, RelationshipInvitations, TeacherLevels, TeacherLevelAuthorizations, LevelCollaborators, ExerciseRuns, LiveViewAudit, SystemMessages, PrivateMessageThreads, Tickets
Gerelateerde popupsPOP-BEH-ACC-ROLE-CHANGE-CONFIRM
PopupregisterOntwerpbronnen — Popup-register
MoSCoWMust

2. Omschrijving

De usecase beschrijft hoe een beheerder publieke rollen van een account beheert en actieve roltoekenningen intrekt of toevoegt binnen de combinatieregels van OefenHub.

Rolbeheer wijzigt UserRoles en niet de identity-providerclaims. De actieve frontendcontext van een gebruiker wordt bij een volgende sessie- of contextbepaling server-side opnieuw afgeleid uit de actuele roltoekenningen.

De leerlingrol heeft een bijzondere positie: een account met Leerling mag niet gecombineerd worden met Ouder/voogd, Docent, Beheerder of TestDocent. Ouder/voogd, Docent en Beheerder mogen wel gecombineerd voorkomen, mits niet in strijd met overige systeemregels.

Uitgangspunten

  • Rolbeheer gebruikt Roles en UserRoles als bron.
  • Rolmutaties zijn soft-auditbaar via UserRoles en accountlogkanaal.
  • Niet-publieke rollen worden in UC-BEH-ACC-004 apart behandeld.
  • De beheerder kan zichzelf of het laatste beheerdersaccount niet ongemerkt buitensluiten.
  • Een rolmutatie wijzigt geen relaties, berichten, tickets of oefenresultaten.

3. Scope

Deze usecase beschrijft:

  • Bekijken van actieve roltoekenningen.
  • Toevoegen van toegestane publieke rollen.
  • Intrekken van actieve roltoekenningen.
  • Toepassen van rolcombinatieregels.
  • Vastleggen van actor en tijdstip op UserRoles.
  • Accountlogmatig vastleggen van rolmutaties.

Deze usecase beschrijft niet:

  • Wachtwoorden, tokens, secrets, identity-provider-sessies of credentialstatus beheren.
  • Een Keycloak- of identity-provideraccount rechtstreeks wijzigen of verwijderen.
  • Vrij relatiebeheer tussen gebruikers uitvoeren; relatieflows blijven bronhoudend in het relatiedomein.
  • Profielwijzigingen als selfservice-gebruikersflow dupliceren; eigen profielbeheer blijft bronhoudend in generiek/profiel.
  • Popupteksten, knopteksten of inputlabels specificeren; usecases verwijzen uitsluitend naar PopupKey.
  • Niet-publieke rollen zoals Admin of TestDocent toekennen of intrekken; dit hoort bij UC-BEH-ACC-004.
  • Relaties, leerlingtoegang of docentcontext automatisch aanpassen buiten expliciete lifecycle-acties.
  • Actieve sessies bij de identity provider beëindigen.

3.1 Afbakening met aangrenzende domeinen

OnderdeelAfbakening
Generiek / AccountLogin, provisioning, logout en selfservice-accountverwijdering blijven bronhoudend in het generieke accountdomein.
Generiek / Profiel en voorkeurenEigen profiel- en voorkeurenbeheer blijft gebruikergericht; accountbeheer bevat alleen beheerdercorrecties en uitzonderingsacties.
Generiek / RelatiesRelatie-uitnodigingen, acceptatie en normale ontkoppeling blijven in het relatiedomein; accountbeheer kan wel afhankelijke toegang beëindigen bij lifecycle-acties.
Beheerder / DocentondersteuningDocentstructuur, leerlingtoegang en collaborators worden daar supportmatig beheerd; accountbeheer ziet accountbrede identiteit, rollen en lifecycle.
Identity providerAuthenticatie, wachtwoorden, verificatie, tokens en credentials blijven buiten OefenHub-accountbeheer.

4. Pre-condities

IDVoorwaarde
PRE-001De gebruiker is succesvol ingelogd in OefenHub.
PRE-002De backend heeft server-side vastgesteld dat de gebruiker een actieve beheerderrol heeft.
PRE-003De beheerder bevindt zich binnen Accounts beheren of een onderliggende accountbeheerroute.
PRE-004Clientstate, routeparameters of verborgen formuliervelden bepalen nooit welk account gewijzigd mag worden.
PRE-005De identity provider blijft bronhouder voor authenticatie, wachtwoorden, tokens, sessies en credential lifecycle.
PRE-006De beheerder heeft accountdetail geopend.
PRE-007Het doelaccount is niet geanonimiseerd.
PRE-008De lijst met actieve rollen en beschikbare rollen is server-side geladen.

5. Post-condities

IDResultaat
POST-001Gewenste toegestane rolmutaties zijn vastgelegd in UserRoles.
POST-002Toegevoegde roltoekenningen bevatten GrantedAtUtc en GrantedByUserId.
POST-003Ingetrokken roltoekenningen bevatten RevokedAtUtc, RevokedByUserId en IsActive = false.
POST-004Er is een accountlogregel voor de rolmutatie vastgelegd.
POST-005Er zijn geen identity-providercredentials gewijzigd.

6. Trigger

De usecase start wanneer de beheerder in accountdetail de sectie Rollen opent en een publieke rol toevoegt of intrekt.

7. Normale processtroom

StapActorComponent / contextActieResultaatData / controle
1BeheerderAccountdetailOpent de sectie Rollen.De frontend vraagt actuele rolcontext op.Users.Id.
2BackendAutorisatiecomponentControleert beheerdercontext.Alleen beheerder mag rollen beheren.Server-side controle.
3BackendRoleServiceLaadt actieve UserRoles en beschikbare publieke rollen.De beheerder ziet toegestane rolopties.Roles.IsActive en Roles.IsPublic.
4BeheerderRollenpaneelWijzigt rolselectie.De frontend vraagt validatie van de gewenste mutatie.Gewenste rolset.
5BackendRoleServiceValideert combinatieregels.Ongeldige combinaties worden geblokkeerd.Leerling exclusief.
6FrontendPopupcomponentToont bevestiging voor rolwijziging.De beheerder bevestigt de mutatie.POP-BEH-ACC-ROLE-CHANGE-CONFIRM.
7BackendRoleServicePast UserRoles transactioneel aan.Nieuwe en ingetrokken rollen worden auditbaar opgeslagen.UserRoles.
8BackendAccountlogLegt rolmutatie vast.Accountlifecyclelog bevat actor, doelaccount, oude en nieuwe rolset.Afgeschermd accountlogkanaal.
9FrontendAccountdetailToont bijgewerkte rolset.Actiebeschikbaarheid wordt opnieuw afgeleid.Nieuwe rolcontext.

8. Alternatieve en exceptionele processtromen

StapSituatieAfhandelingPopupKeyDatagevolg
2Actor is geen beheerder.De backend weigert de mutatie.Niet van toepassing.Geen.
4Doelaccount is geanonimiseerd.Rolbeheer wordt geblokkeerd.Niet van toepassing.Geen.
5Rolcombinatie bevat Leerling met andere rol.De mutatie wordt geweigerd.Niet van toepassing.Geen.
5Mutatie zou het laatste actieve beheerdersaccount verwijderen.De mutatie wordt geblokkeerd.Niet van toepassing.Geen.
6Beheerder annuleert bevestiging.Er wordt niets opgeslagen.POP-BEH-ACC-ROLE-CHANGE-CONFIRM.Geen.
7Roltoekenning is intussen gewijzigd door een andere beheerder.De mutatie wordt geweigerd en de rolset wordt opnieuw geladen.Niet van toepassing.Geen.

9. Business rules

IDBusiness rule
BR-001Rolmutaties worden vastgelegd in UserRoles; rollen worden niet hard uit historie verwijderd.
BR-002Leerling mag niet gecombineerd worden met Ouder/voogd, Docent, Beheerder of TestDocent.
BR-003Ouder/voogd, Docent en Beheerder mogen gecombineerd voorkomen wanneer geen leerlingrol actief is.
BR-004Niet-publieke rollen worden niet via de publieke rolbeheerroute behandeld.
BR-005Het laatste actieve beheerdersaccount mag niet zonder expliciete systeemwaarborg verdwijnen.
BR-006Rolmutatie wijzigt geen identity-providercredentials.
BR-007Actieve frontendcontext wordt bij volgende contextbepaling opnieuw server-side afgeleid.

10. Datavalidatie

IDValidatie
VAL-001Doelaccount moet bestaan en actief of beheerbaar gedeactiveerd zijn.
VAL-002Gewenste rollen moeten bestaan in Roles en actief zijn.
VAL-003Publieke rolmutaties gebruiken alleen Roles.IsPublic = true, tenzij verwezen wordt naar UC-BEH-ACC-004.
VAL-004Actieve UserId + RoleId-combinatie moet uniek blijven.
VAL-005GrantedByUserId en RevokedByUserId verwijzen naar de uitvoerende beheerder.
VAL-006Concurrente wijziging moet worden gedetecteerd via actuele rolset of versiecontrole.

11. Datamutaties en events

OnderdeelMutatie / event
UserRoles toevoegenNieuwe roltoekenning met IsActive = true, GrantedAtUtc en GrantedByUserId.
UserRoles intrekkenBestaande roltoekenning krijgt IsActive = false, RevokedAtUtc en RevokedByUserId.
AccountlogkanaalRolmutatie wordt met oude en nieuwe rolset vastgelegd.

12. Geen datamutaties

Object / gegevenNiet wijzigen
UsersAccountidentiteit en IsActive wijzigen niet.
UserSettingsGeen gebruikersinstellingen wijzigen.
Identity providerGeen claims, wachtwoorden, tokens of sessies wijzigen.
Relaties en autorisatiesGeen automatische relatie- of niveauautorisatiemutatie.
ExerciseRuns en geschiedenisGeen resultaten of runs wijzigen.

13. State diagram

14. Decision flow

15. Data lifecycle diagram

16. Sequence diagrammen

17. Popupverwijzingen

PopupKeyGebruik
POP-BEH-ACC-ROLE-CHANGE-CONFIRMBevestiging voor het toevoegen of intrekken van een rol.

Popupinhoud, knopteksten, themakeuzes en eventuele inputlabels blijven bronhoudend in het centrale popupregister en popup-themes.

18. Afleiding naar Functioneel Ontwerp / Technisch Ontwerp / Software Requirements Specification

DocumentAfleiding
Functioneel OntwerpAccountbeheer ondersteunt beheerdergestuurde roltoekenning en intrekking binnen rolcombinatieregels.
Technisch OntwerpTechnisch Ontwerp: identiteit en accountlifecycle, autorisatie, logging en foutafhandeling en privacy en anonimisering beschrijven de technische uitwerking. RoleService moet UserRoles transactioneel wijzigen en accountlog schrijven.
Software Requirements SpecificationSRS moet rolcombinatieregels, laatste-beheerderbescherming en auditplicht expliciet vastleggen.
DatabaseGebruikt Roles en UserRoles; geen wijziging aan identity-providercredentials.

19. SRS-trace

Deze usecase bevat geen normatieve requirementtekst. De centrale eis en acceptatiecriteria staan in de SRS; onderstaande tabel koppelt de usecase-afleiding alleen aan centrale SRS-*- en AC-*-items.

Usecase-afleidingDektUsecasecontext
UC-BEH-ACC-003-REQ-001SRS-ACC-002
SRS-ADM-002
SRS-ADM-001
AC-ACC-002
AC-ADM-002
AC-ADM-001
Een beheerder publieke rollen van een account kunnen laten beheren
UC-BEH-ACC-003-REQ-002SRS-AUTH-001
SRS-ADM-002
SRS-ADM-001
AC-AUTH-001
AC-ADM-002
AC-ADM-001
Rolmutaties server-side valideren
UC-BEH-ACC-003-REQ-003SRS-LRN-009
SRS-ADM-002
SRS-ADM-001
AC-LRN-009
AC-ADM-002
AC-ADM-001
De leerlingrol exclusief houden ten opzichte van andere hoofdrollen
UC-BEH-ACC-003-REQ-004SRS-ADM-002
SRS-ADM-001
SRS-NFR-AUD-001
AC-ADM-002
AC-ADM-001
AC-NFR-AUD-001
UserRoles niet hard verwijderen maar intrekken met auditvelden
UC-BEH-ACC-003-REQ-005SRS-ACC-002
SRS-ADM-002
SRS-ADM-001
SRS-NFR-AUD-001
AC-ACC-002
AC-ADM-002
AC-ADM-001
AC-NFR-AUD-001
Rolmutaties vastleggen in een accountlogkanaal
UC-BEH-ACC-003-REQ-006SRS-ACC-002
SRS-ADM-002
SRS-ADM-001
AC-ACC-002
AC-ADM-002
AC-ADM-001
Voorkomen dat het laatste actieve beheerdersaccount ongemerkt verdwijnt
UC-BEH-ACC-003-REQ-007SRS-ADM-002
SRS-ADM-001
SRS-NFR-SEC-001
SRS-NFR-PRV-001
SRS-ARCH-002
AC-ADM-002
AC-ADM-001
AC-NFR-SEC-001
AC-NFR-PRV-001
AC-ARCH-002
Bij rolmutaties geen identity-providercredentials wijzigen