kontakt

+49 421 20696 - 0
info@team-neusta.de

Ein Portal, ein Tor zum personalisierten Content – Teil 6

Security-Schicht

Die Security-Schicht steuert zentralisiert alle Zugriffe auf Portalinhalte in
Relation zur Identität des aktuell angemeldeten Benutzers. Alle qualifizierenden Attribute eines Benutzerobjektes, wie z.B. seine Position oder Email-Adresse, werden dabei direkt während des Logins in das Portal aus dem Verzeichnisdienst und dem Identity-Access-Management-System (IAM) übernommen. Die Schicht regelt die Zugriffe auf Basis der im Verzeichnisdienst hinterlegten Gruppenmitgliedschaften oder den Einstellungen der
Rechte auf Benutzerobjektebene.

Portale #8

Da Datensicherheit innerhalb einer Portal-Implementierung akribisch und allumfassend abgedeckt werden muss, positioniert sich die Security-Schicht wie eine Art Schutzschild und Firewall bei den meisten Lösungen um den Systemkern herum und bezieht sowohl Portal-Instanz-Manager als auch das Interface-Management (Konnektoren) mit ein.

Bei den meisten Portallösungen wird das Thema Sicherheit dreistufig angegangen:

  1. Access Management – Das Access Management stellt sicher, dass nur autorisierte Benutzer Zugriff zu Portalinhalten erhalten.
  2. User Identity Management – Stellt im Bedarfsfall sicher, dass bestimmte Attribute bezgl. eines Benutzerobjektes zur Laufzeit von Verzeichnisserver abgefragt werden können, um z.B. den Zugang zu speziellen Anwendungen auf einen bestimmten Nutzerkreis einschränken zu können.
  3. Logging/Auditing – Die Security-Schicht schreibt ständig Zugriffsfehler und Informationen zur Ausführungszeit bestimmter Portalkomponenten in Logdateien. Dies erlaubt spätere Analysen oder frühzeitige Entdeckung von Anomalitäten.

Storage-Management

Zu den bislang aufgezählten, funktionellen Modulen kommen weitere Module mit einem technischeren Ansatz bei einer Portallösung hinzu. Im Normalfall sind Portallösungen hochverfügbare integrierte Systeme, die sich verteilte Speichersysteme zu Nutze machen. Die meisten Portale bringen aus diesem Grund ihre eigenen, optimal abgestimmten Storage-Manager mit.

Dieses Modul deckt in der Regel das Caching und die physische Speicherung
der statischen und temporären Daten, sowie der Portalinhalte ab. Das
Storage-Management interpretiert normalerweise Kommandos, wie lesen,
schreiben, aktualisieren und löschen (RWUD), und akzeptiert Anfragen von
allen Modulen der Portalinstanz, die einen Speicherzugriff erfordern.

Alle Speicherzugriffsanfragen (lesend) leitet der Portal-Instanz-Manager in
der Regel zuvor durch die Security-Schicht, bevor sie vom Storage-Management ausgeführt wird. Schreibzugriffe hingegen werden bei den
meisten Portallösungen aus Performancegründen nicht in dieser Form
umgeleitet.

Suchmaschine
Die Suchmaschine indiziert den kompletten Portalinhalt und die Informationen
aus Workflows, um Suchergebnisse und Verweise auf maschinelle oder
manuelle Anfragen von Benutzern geben zu können.

Inhaltliche Sicht

Im Normalfall können alle Arten von Daten sehr leicht gruppiert werden, um
Informationen eines identischen Typs und einer bestimmten inhaltlichen
Ausrichtung einem bestimmten Zweck zuzuordnen. Nach erfolgter
Zuordnung des Zwecks kann in Abhängigkeit vom jeweiligen Besitzer oder
von der Art des Zugriffes eine Standardaktion in der inhaltlichen Sicht assoziiert
sein. Diese inhaltliche Sicht repräsentiert alle Informationsflüsse,
Datenquellen mit ihren gemeinsamen Abhängigkeiten und Verbindungen in
Bezug auf die Systemarchitektur.

Daten-Elemente

Mittels gängiger Modellierungsmethoden wie z.B. UML sollte bei jeder
Portalintegration ein Diagramm der zu integrierenden Daten angefertigt
werden. In einem Portalprojekt sollen ja mehrere Datenquellen und
verschiedene Datentypen gemeinsam mit kalkulierten Ergebnissen im
Frontend oder in Workflows zusammen gebracht werden. Wo es geht, sollte
man so genannte „Rich Entities“ schaffen, um die Anzahl der verschiedenen
Datenobjekte und ihrer Relationen zu reduzieren. Ein beispielhaftes Design
könnte z.B. in etwa so aussehen.

Portale #9

 

Daten-Synchronisierung & Data-Ownership

Durch die Ausrichtung der Portalarchitektur in Richtung eines Workflow-Basierten Systems, drängen sich früher oder später auch zwangsläufig
Fragen der Datensynchronisierung und des Data-Ownerships auf.

Besitzverhältnisse und die Echtheit der Daten sind im Normalfall in einem
Portal-Workflow aber recht schnell geklärt: Durch die serielle Abarbeitung
der Workflows werden Daten mit einem „Lock“ vor Veränderung geschützt,
sollte ein Task innerhalb des Workflows noch aktiv sein.

Daten können somit nur durch den Besitzer der jeweiligen Workflowkette
verändert werden.

Informationsfluss und Datenströme

Gerade in einer flexiblen und dynamischen Portal-Architektur ist es
besonders wichtig, die möglichen Informationsflüsse im Vorfeld zu kennen.
Hauptsächlich in Bezug auf die Einbindung externer Datenquellen, kann eine Kartographie der Datenströme hilfreich sein, um z.B. von proprietären Datenformaten hin zu Standards wie der Service Provisioning Markup Language (SPML) zu wechseln.

Aber nicht nur die Datenströme für eigentlichen Portalinhalte sind
interessant, auch das Portal selbst erzeugt im Laufe seines Betriebes sehr
viele Daten. Diese prozessrelevanten Informationen steuern beispielsweise
die Workflows oder geben zur Laufzeit kalkulierte Ergebnisse an höher
geordnete Module oder Portal-Instanzen weiter.

Mit Ausnahme der Task-Ergebnisse werden diese Werte in der Regel „nurlesend“ gespeichert, um sie vor Veränderung zu schützen.

Fortsetzung in Teil 7:

Im nächsten Teil geht es um EAI (Enterprise Application Integration).

Lesen Sie hier ab dem 02.10 den Teil 7

Share