Skip to main content

ADR-002: TEACHER Migrat de Rol de Seguretat a Rol de Domini

Estat: Acceptat
Data: 2024-12
Decisors: Equip LDP
Fase: Phase 2B

Context​

Originalment, TEACHER era un dels tres rols de seguretat (USER, TEACHER, ADMIN) a l'enum Role.java. Això permetia que els usuaris amb rol TEACHER poguessin crear i editar qualsevol recurs (Dance, Song, Event, Location, Venue) via hasAnyRole('TEACHER', 'ADMIN') a SecurityConfig i @PreAuthorize.

Problemes​

  1. Escalada de privilegis implícita: Qualsevol TEACHER podia editar recursos creats per altres TEACHERs.
  2. Confusió conceptual: "Professor de line dance" és una identitat de domini, no un nivell de permisos.
  3. BOLA vulnerability: Els checks a nivell de rol no validaven ownership.
  4. Rigidesa: Afegir nous rols de domini (DJ, CHOREOGRAPHER) implicava modificar l'enum de seguretat.

Decisió​

TEACHER es mou de rol de seguretat a rol de domini.

Canvis Implementats​

  1. Enum Role.java: Només conté USER i ADMIN.
  2. Enum PersonRoleType: Conté TEACHER, CHOREOGRAPHER, DJ, ARTIST, STAFF, GUEST.
  3. SecurityConfig: POST/PUT requereixen authenticated(), no hasAnyRole('TEACHER', 'ADMIN').
  4. Autorització d'edició: Basada en ownership (owner_id) + ADMIN override, validada al service layer.
  5. promoteToTeacher(): Només assigna PersonRoleType.TEACHER, no canvia el rol de seguretat.

Diagrama de Rols​

┌─────────────────────────────────────────────────────────────┐
│  CAPA DE SEGURETAT (Role.java)                              │
│  ─────────────────────────────────                          │
│  USER   → Usuari autenticat estàndard                       │
│  ADMIN  → Accés administratiu complet                       │
└─────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐
│  CAPA DE DOMINI (PersonRoleType.java)                       │
│  ────────────────────────────────────                       │
│  TEACHER      → Professor de line dance                     │
│  CHOREOGRAPHER → Creador de coreografies                    │
│  DJ           → Disc jockey                                 │
│  ARTIST       → Artista musical                             │
│  STAFF        → Personal d'organització                     │
│  GUEST        → Convidat                                    │
└─────────────────────────────────────────────────────────────┘

Conseqüències​

Positives​

  • ✅ Separació clara entre autenticació/autorització (RBAC) i identitat de domini.
  • ✅ BOLA enforcement: L'edició es valida per ownership, no per rol genèric.
  • ✅ Extensibilitat: Nous rols de domini no afecten la seguretat.
  • ✅ Principle of Least Privilege: Només el propietari o ADMIN pot editar.

Negatives​

  • ⚠️ Migració: El frontend haurà d'adaptar-se per no dependre de role === "TEACHER".
  • ⚠️ Retrocompatibilitat: Usuaris amb Role.TEACHER a BD hauran de ser migrats a Role.USER + PersonRoleType.TEACHER.

Accions Pendents​

  1. Migració de BD per convertir users.role = 'TEACHER' a 'USER' + crear PersonRole.TEACHER.
  2. Actualitzar frontend per usar personRoles.includes('TEACHER') en lloc de role === 'TEACHER'.
  3. Revisar altres recursos (Dance, Song, Event) per assegurar BOLA consistent.

Referències​