tawiki

Hierbei handelt es sich um ein Systemkonto, über welches sich Systeme an PRO·M anmelden können, die aber keiner Person entsprechen. Das Systemkonto 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¹⁾.

Das Systemkonto hat eine surrogate Id, welches es identifiziert. Es hat auch einen Namen, der²⁾ eindeutig ist. Man könnte den Namen unveränderbar machen, und das Konto darüber identifizieren lassen. Vielleicht später³⁾.

Wobei es schwierig ist, wenn der Name das Konto identifiziert, also die Aggregate Id ist, und das Konto gelöscht werden kann. Was tun, wenn es später neu angelegt wird, bzw. ein neues Konto mit demselben Namen? Es gibt in PRO·M dafür bereits eine Lösung, indem ein Aggregate mit derselben Id wieder erzeugt werden kann, aber nur, nachdem es gelöscht wurde, wobei es komplett auf Null gesetzt wird. Am sinnvollsten wäre es, das Konto nicht löschen zu können, und die vorhandenen Mittel zu nutzen, z.B. dass man das Konto sperren kann. Nachteil: Man bekommt ein einmal angelegtes Konto nie wieder aus der Liste der Konten raus.

Es gibt keinen Index auf den Namen des Kontos. Konten werden über die Lizengruppe erzeugt, damit die Lizenzgruppe vorher prüfen kann, ob ausreichend Lizenzen vorhanden sind⁴⁾. 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 Benutzername⁵⁾ wird spätestens bei der Anmeldung mit dem Kontonamen abgefangen, mit einer DuplicateUsernameException. Der Anwender wird dann den Administrator anrufen, und dieser wird einen der beiden Kontonamen ändern⁶⁾.

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

Keine Nennenswerten Regeln.

• AddSystemAccount: Systemkonto-Rolle einer Person hinzufügen
• ChangeSystemAccountName: Änderung des Kontonamens, z.B um ein doppelt vergebenen Namen zu korrigieren.
• AllowSystemAccountFullImpersonation: das Recht geben, alle anderen Konten zu impersonieren.
• DenySystemAccountFullImpersonation: das Recht nehmen, alle anderen Konten zu impersonieren.
• LockSystemAccount: 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 Fehlversuchen⁷⁾
• UnlockSystemAccount: Das Konto entsperren, z.B. nach einer automatischen Sperre und nachdem das Kennwort zurück gesetzt wurde⁸⁾.

• SystemAccountAdded
• SystemAccountChanged
• SystemAccountAllowedFullImpersonation
• SystemAccountDeniedFullImpersonation
• SystemAccountLocked
• SystemAccountUnlocked

I.d.R. hat ein Systemkonto ohne Authentifizierungsmechanismen wenig Sinn. Somit wird meist der Befehl AddSystemAccount in einem Batch mit dem Befehl AddSystemAccountAuthentication⁹⁾ 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.