« »

Security Komponenten Klassendiagramm

30. Juni 2009 Roland

Dieser Artikel ist Teil 69 von 70 der Artikelserie Newssystem

Newssystem

Im Artikel Security fummelt man am Besten gleich in die Architektur hinein habe ich die verschiedenen Security Umsetzungsvarianten erläutert, die wir für die Erstellung des Newssystems verwenden können.
Da keine größeren Klagen eingetroffen sind, gehe ich mal davon aus, dass ihr mit meiner bevorzugten Variante leben könnt.
Jetzt wollen wir mal aus der grauen Theorie rauskrabbeln und die Welt mit schönen Klassendiagrammen beglücken :)
Ich habe jetzt ein Klassendiagramm zusammengesteckt bei dem die Security Komponenten weitgehend außerhalb der Newssystemkomponenten stehen.
Die Security Komponenten und ihre Interaktion mit den Newssystem Komponenten.
Das sind doch jetzt schon relativ viele Klassen und Verbindungen zwischen den einzelnen Komponenten.

Schnittstellen

In diesem Modell habe ich folgende Schnittstellen (Interfaces) festgelegt:

IUserModel

Dieses Interface kapselt die Methoden des UserModels.
Ich benötige ein Modell, mit dem wir unsere User im System ablegen können. Diese User müssen existieren und entsprechend das gewünschte Passwort vorweisen können.
Also LoginName und Passwort ist cool ;)
Ich habe mich entschlossen diese Security Elemente im UserModel abzulegen und dieses UserModel außerhalb der Security Komponenten zu positionieren.
Vielleicht wäre es noch sauberer gewesen alle Userdaten, wie Name, UserTyp usw. in einem UserModel zu verwalten und alle Security Dinge in einem SecurityUserModel.
Aber dann brauch ich noch mehr Modelle und irgendwann will ich auch mal mit dem Newssystem fertig werden ;)
Wir brauchen ja noch was zum Reverse Engineering gelle?
So, wir verwenden also den LoginName und das Passwort um den jeweiligen User zu authentisieren.
Da wir ein Interface verwenden, ist es völlig egal wie die Methode realisiert wird. Wir haben das Newssystem an dieser Stelle vom Security System entkoppelt.
Falls wir ein anderes Security System verwenden, können wir einfach auf die Speicherung von LoginName und Passwort im UserModel verzichten.

ICategory

Da unsere Redakteure nur in bestimmten Kategorien Zugriff erhalten, werden wir entsprechend die Frage, ob der Redakteur für eine bestimmte Kategorie berechtigt ist an unser Kategoriemodell weiterleiten. Falls das in einer Security Implementation nicht benötigt oder gewünscht ist, können wir hier auch die Systeme leicht voneinander entkoppeln.

IAuthentication

Wir greifen in unserem Newssystem über dieses Interface auf die Authentication Methoden zu. Falls ein anderes Security System gewünscht wird, muss es nur diesem Interface genügen. Wenn das andere anzubindende Security System dieses Interface nicht anbietet, können wir eine Fasade oder einen Adapter davorstellen. Das Security System ist somit vollkommen von unserem Newssystem entkoppelt und wir können es immer und überall aufrufen.
Cool ist, dass hiermit auch andere Systeme auf diese Schnittstelle zugreifen können.
Eventuell sollten wir, falls wir unser Security System mehrmals verwenden wollen, wirklich unser IUserModel im Security System realisieren. Dieser Umbau ist später einfach möglich.

IAuthorisation

Hierüber wird gesteuert, ob ein User überhaupt berechtigt ist auf eine bestimmte Komponente und Aktion zuzugreifen.
Da wir im Newssystem konzequent das CRUD Pattern umsetzen, können wir auf Komponentenebene jeweils die Create, Read, Update und Delete Aktion auf Userebene absichern.
Na, sind wir nicht stabil und sicher damit?

Klassen

Ein paar Klassen sollten wir trotzdem realisieren und uns nicht nur hinter Interfaces verstecken :)

Authentication

Hier realisieren wir unsere interne News-Berechtigungsklasse. Nur User, die sich am System anmelden können, lassen wir im System zu.
Diese Klasse verwendet die UserModel Klasse um auf die gespeicherten User und deren Passwörter zugreifen zu können.

Authorisation

Wenn ein User angemeldet ist, wird ihm eine bestimmte Rolle zugewiesen.
Bei uns gibt es Redakteuere, Master Redakteure, Administratoren usw.
Jede Rolle hat bestimmte Rechte. Wir können hiermit festlegen, dass der Redakteur nur seine Kategorien sieht und verändern kann.
Der Administrator kann neue Kategorien hinzufügen und verändern.
Diese Klasse kontrolliert, ob der jeweilige User die gegebenen Rechte hat.
Falls ja, liefert sie true zurück.

AuthenticationFactory

Damit wir unsere Authentication Klasse gegen andere Systeme austauschen können, bauen wir diese Fabrikklasse ein.
Jedesmal wenn wir einen Zugriff auf die Security Klassen benötigen, rufen wir diese Klasse auf. Wir erhalten die jeweils aktive Instanz, die dem Interface IAuthentication genügt. So können wir sicherstellen, dass wir später auch ein anderes Security System mitverwenden können.

AuthorisationFactory

Klar, wenn die Authentisierung schon gekapselt werden soll, dann auch die Authorisierung.
Damit haben wir die notwendigen Klassen beieinander um die bisher bekannten Security Anforderungen für den ersten Sprint abzubilden.
Jetzt muss sich nur noch jemand bereiterklären die Teile kurz auszucodieren.
Wenn sich kein Freiwilliger meldet, werde ich das wohl machen dürfen ;)

Merken und weiterempfehlen Diese Icons verlinken auf Bookmark Dienste bei denen Nutzer neue Inhalte finden und mit anderen teilen können.
  • Technorati
  • Wikio DE
  • Webnews
  • MisterWong
  • Y!GG
  • Digg
  • del.icio.us

Der Beitrag wurde am Dienstag, den 30. Juni 2009 um 08:49 Uhr veröffentlicht und wurde unter IT, Programmieren abgelegt.
Kurzlink: http://www.baldenhofer.eu/blog/?p=1656

Dir gefiel der Artikel? Dann abonniere doch den RSS Feedrss

Du kannst die Kommentare zu diesem Eintrag durch den RSS 2.0 Feed verfolgen. Du kannst einen Kommentar schreiben, oder einen Trackback auf deiner Seite einrichten.

...deine Chance den ersten Kommentar zu schreiben... ;-)

Schreibe mir

zum Seitenanfang