Obiettivo:
Sto cercando di capire il modo migliore per modellare / progettare e quindi implementare una funzione "utente" in un sistema.
Sfondo:
Sto progettando un sistema di richiesta di accesso on-line, quindi la nostra azienda può utilizzare un metodo basato sul Web per gli utenti che richiedono l'accesso a vari sistemi software. Dato che il sistema è interamente relativo all '"utente", l'utente è il punto focale del sistema.
Quindi, un utente può richiedere l'accesso a un sistema. Quindi, il Gestore dell'utente approverà / respingerà la richiesta. Successivamente, il proprietario del sistema approverà / respingerà la richiesta. Quindi è l'amministratore di sistema che approva / rifiuta e infine l'amministratore di sicurezza approva / rifiuta e li aggiunge al gruppo di Active Directory appropriato in modo che possano accedere all'applicazione basata su Active Directory di destinazione (non questa applicazione).
Problema:
Vedo tutte le entità che rappresentano un utente come una (e) classe (i) principale (i) nel sistema. L'oggetto User è semplice: basta passare il proprio accesso di Windows a Active Directory (AD) tramite una query LDAP e ottenere le informazioni e caricarle in un oggetto. In una query LDAP, se ci sono altri utenti che segnalano loro (il gestore di un utente è memorizzato nel nostro annuncio), questo "utente" non è solo un utente in questo sistema ma anche un manager. Se anche questo utente si trova nel database come proprietario del sistema, è anche un proprietario del sistema.
Finora:
(Si supponga che un Manager sia qualcuno con almeno un rapporto diretto ad esso assegnato in AD.)
Ho considerato un singolo oggetto utente, con proprietà come IsManager o IsSystemOwner. Tuttavia, dovrei costruire una gerarchia di oggetti dove (ad esempio) una classe Manager eredita dall'utente? Ci sono stranezze con questo, perché un proprietario del sistema potrebbe ereditare da utente o gestore. Non tutti i proprietari di sistemi sono gestori. Tuttavia, Manager, System Owners, System Admins e Security Admins sono tutti Utenti, poiché possono richiedere l'accesso ad alcuni sistemi software in cui il ruolo in questo sistema è solo come Utente. Ecco una panoramica di "è un" per tutte le entità utente:
- Un utente può richiedere l'accesso ad altri sistemi software in questo sistema.
- Un manager è un utente.
- Un proprietario del sistema è un utente.
- Un amministratore di sistema è un utente.
- Un amministratore della sicurezza è un utente (ma improbabile, a causa della nostra organizzazione).
- Un manager può essere un proprietario del sistema, ma non sempre.
- Un proprietario del sistema può essere un gestore, ma non sempre.
- Un amministratore di sistema può essere un gestore, ma non sempre.
- Un amministratore di sistema potrebbe essere un proprietario del sistema, ma non probabile.
- Un amministratore della sicurezza può essere un gestore, ma non sempre.
- Un amministratore della sicurezza potrebbe essere un proprietario del sistema, ma non probabile.
Alcune informazioni aggiuntive:
- Non prevedo che gli amministratori di sicurezza utilizzino il sistema come utente per richiedere l'accesso, ma è sempre possibile.
- Un manager può creare una richiesta di accesso per conto di uno dei suoi dipendenti (per revocare l'accesso a un dipendente licenziato, ad esempio)
- Tutti i dipendenti nel dominio Windows avranno accesso a questo sito. Presumo che avrò alcuni gruppi di Active Directory creati per amministratori di sistema e amministratori della sicurezza, poiché gli utenti di questi gruppi non saranno dinamici, piuttosto gli utenti di un team sono amministratori del sistema e gli utenti di un altro team sono amministratori della sicurezza.
- Il proprietario del sistema è soggetto a modifiche e verrà memorizzato nel database, insieme alla possibilità di designare un approvatore alternativo in vacanza, ecc.
- Potrei aver bisogno di un Manager per avere un approvatore alternativo, ma non avevo intenzione di archiviare tutti gli utenti nel dominio nel database!
Sembra che sia così facile modellare sulla carta, ma farcela in un codice buono e flessibile mi sta bloccando. Tutti i suggerimenti sono ben accetti.
EDIT: sulla base del feedback di Karl, ho questo modello prototipo. Sembra solido da una prospettiva OOP, in base alla mia destinazione d'uso?
Public Class MyCustomUserObject
Public Property LoginID As String
Public Property FirstName As String
Public Property LastName As String
Public Property EmailAddress As String
Public Property Roles As List(Of Role)
Public Function IsManager() As Boolean
' If List(Of Role) contains an object of type ManagerRole, then True, else False.
End Function
Public Function IsSystemOwner(systemName As String) As Boolean
' If List(Of Role) contains an object of type SystemOwnerRole with matching name
' in SystemOwnerRole.SoftwareSystems, then True, else False.
End Function
Public Function IsSystemAdministrator(systemName As String) As Boolean
' If List(Of Role) contains an object of type SystemAdministratorRole with matching name
' in SystemAdministratorRole.SoftwareSystems, then True, else False.
End Function
Public Function IsSecurityAdministrator() As Boolean
Return My.User.IsInRole("My Active Directory group name for Security Admins")
End Function
End Class
Public Class SoftwareSystem
Public Property ID As String
Public Property Name As String
End Class
Public MustInherit Class Role
Public Property DesignatedApproverLoginID As String
End Class
Public Class ManagerRole
Inherits Role
Public Property Subordinates As List(Of AafUser)
' Or this, with a List of login IDs?
' Public Property Subordinates As List(Of String)
End Class
Public Class SystemOwnerRole
Inherits Role
Public Property SoftwareSystems As List(Of SoftwareSystem)
End Class
Public Class SystemAdministratorRole
Inherits Role
Public Property SoftwareSystems As List(Of SoftwareSystem)
End Class
Public Class SecurityAdministratorRole
Inherits Role
' Explictly a Security Admin for all Software Systems.
End Class
