User Tools

Site Tools


prom20:usermanagement:useraccount

UserAccount

Hierbei handelt es sich um eine Rolle, die eine Person annehmen kann. Der UserAccount ist dabei ein Benutzerkonto des Mandanten, das die Person repräsentiert. Das Benutzerkonto hat an dieser Stelle erst mal nur einen Namen, und kann noch gesperrt werden und das Recht erhalten, alle anderen Konten zu impersonieren.

Es hat noch kein Passwort, da das Teil der Authentifizierung ist, und diese austauschbar sein soll. Wenn man z.B. eine Windows-Authentifizierung implementiert, dann würde man das Konto mit dem Bentzernamen “rta” anlegen, und dem Windows Konto “tavenso/rta” zuordnen, d.h. in PRO·M müsste man gar kein eigenes Kennwort vergeben.

Identität

UserAccount ist eine Rolle der Person, somit eine Entität im Person Aggregte. Die Identität der Rolle ist die der Person.

Index

Es gibt keinen Index auf den Benutzernamen. Benutzer werden über die Lizengruppe erzeugt, damit die Lizenzgruppe vorher prüfen kann, ob ausreichend Lizenzen vorhanden sind1). Dort wird ebenfalls über das Read Modell geprüft, ob der Benutzername bereits in einem anderen Benutzerkonto oder in einem Systemkonto verwendet wird.

Ein doppelter Benutzername2) wird spätestens bei der Anmeldung mit dem Benutzernamen abgefangen, mit einer DuplicateUsernameException. Der Anwender wird dann den Administrator anrufen, und dieser wird einen der beiden Benutzernamen ändern3).

Inhalte

Die Benutzerkonto Rolle enthält (vorerst) keine weiteren Entitäten oder Value Objects.

Regeln

Keine Nennenswerten Regeln

Befehle

  • AddUserAccount: Benutzerkonto-Rolle einer Person hinzufügen
  • ChangeUserName: Änderung des Benutzernamens, z.B um ein doppelt vergebenen Namen zu korrigieren.
  • AllowUserAccountFullImpersonation: das Recht geben, alle anderen Konten zu impersonieren.
  • DenyUserAccountFullImpersonation: das Recht nehmen, alle anderen Konten zu impersonieren.
  • LockUserAccount: Das Konto sperren. Egal, welche Authentifizierungsmethode umgesetzt wird, hierauf sollte beim Authentifizieren immer geprüft werden. Die integrierte Authentifizierung sperrt z.B. das Konto nach 5 Fehlversuchen4)
  • UnlockUserAccount: Das Konto entsperren, z.B. nach einer automatischen Sperre und nachdem das Kennwort zurück gesetzt wurde5).

Ereignisse

  • UserAccountAdded
  • UsernameChanged
  • UserAccountAllowedFullImpersonation
  • UserAccountDeniedFullImpersonation
  • UserAccountLocked
  • UserAccountUnlocked

Workflow

I.d.R. hat ein Benutzerkonto ohne Authentifizierungsmechanismen wenig Sinn. Somit wird meist der Befehl AddUserAccount in einem Batch mit dem Befehl AddUserAccountAuthentication6) abgeschickt, damit das Konto gleich mit Kennwort oder einem anderen Authentifizierungsmechanismus erstellt wird. Es kann auch gleich mit der Person erstellt werden, da das Konto ja eine Rolle der Person ist, und somit Teil desselben Haupt Aggregates ist.

1) Über das Read Modell, also nicht 100% konsistent
2) Wahrscheinlichkeit hierfür ist geschätzt 0,0001%
3) Ist doch ganz einfach, das mit der eventual consistency, wenn man nicht eine allgemeine Lösung sucht, sondern sich die Fälle einfach mal genau anguckt
4) Die Logik ist eingebaut, das Ergebnis nicht, weil PRO·M 1.0 noch keine Sperren nach N Fehlversuchen kennt
5) Bzw. in demselben Batch, da beide Befehle auf dasselbe Hauptaggregate gehen
6) Oder einem ähnlichen
prom20/usermanagement/useraccount.txt · Last modified: 2013/11/13 17:04 by rtavassoli