PLM-Informationsmodellierung
3. Beziehungen zwischen Objekten
6.1. Grundkonzepte der Autorisierung
Von grundlegender Bedeutung für den Mechanismus der Autorisie-rung ist der Zeitpunkt des Zugriffs im Lebenslauf eines Objekts. Dies-bezüglich sind drei Hauptphasen zu unterscheiden, wobei die Autorisierung jeweils auf unterschiedliche Weise geregelt wird (vgl.
Bild B028obmZ). Während der ersten Phase „Working“ ist ein Objekt quasi in Arbeit und die Zugriffsrechte können bei Bedarf beliebig ver-ändert werden, um gegebenenfalls einem anderen User, einer ande-ren Rolle, Gruppe usw. die benötigten Privilegien einzuräumen.
Sobald sich ein Objekt jedoch in einem formalen Prozess befindet, sind sämtliche Zugriffsrechte in der Prozessdefinition festgelegt und werden ausschliesslich hierüber kontrolliert, d.h. sie können i.d.R. vom Benutzer – auch dem Eigentümer (Owning User) – nicht beeinflusst werden! Nach einem erfolgreichen Prozessdurchlauf erhält ein Objekt in der Regel einen Status zugewiesen, womit auch eine feste Defini-tion von Zugriffsrechten verbunden ist. Zum Schutz von z.B. freigege-benen Objekten dürfen diese Privilegien (i.d.R. nur noch World: Read) nicht mehr geändert werden. Die Unterscheidung der in Bild B028obmZ dargestellten drei Hauptphasen ist somit von grundlegen-der Bedeutung für die Autorisierung.
Bild (B028obmZ) Unterscheidung dreier Hauptphasen für die Autorisierung
Ausgangspunkt eines jeden Autorisierungsentscheides ist ein Benut-zer, der eine Funktion auf ein Objekt anwenden möchte. Für die Auto-risierung stehen daher drei wesentliche Zugriffsaspekte im Vordergrund, die zusammen ein Zugriffstripel bilden (Bild B029obmZ):
• Accessor(User im Kontext der Sitzung),
• Anwendungsfunktion (z.B. Read oder Kopieren auf neue Revi-sion),
• Objektprivilegien (Menge definierter Zugriffsrechte).
Bild (B029obmZ) Aspekte der Autorisierung
Accessor
Unter dem Begriff Accessor ist der „Benutzer im Kontext seiner Sit-zung“ zu verstehen, d.h. die Kombination aus User, aktueller Gruppe und Rolle. Der Benutzer alleine ist zumindest in allgemeiner Hinsicht nicht ausreichend, da ein Benutzer häufig mehrere Rollen annehmen kann.
In Process Released
Working
Lebenslauf
Accessor (User im Kontext der Sitzung)
aktuell effektive Zugriffsprivilegien
R W D C
Objektdaten
Objektprivilegien Anwendungsfunktion
(z.B. Read)
Autorisierung: JA Autorisierung: NEIN
Zugriffstripel
R W D C
User A x x x x
Gruppe B x x -
-Rolle C x - -
-Die Unterscheidung von Gruppen und Rollen und deren zweck-mässige Anwendung ist hierbei von grundlegender Bedeutung:
• Gruppen
• repräsentieren ein Entwicklungsteam bzw. eine organisato-rische Unternehmenseinheit,
• üblicherweise werden Zugriffsrechte allgemein auf Grup-penmitglieder beschränkt.
• Rollen
• repräsentieren funktionale Verantwortlichkeiten,
• üblicherweise werden Zugriffsrechte für spezifische Infor-mationsaspekte anhand von Rollen definiert (Konstrukteure haben Schreibzugriff auf CAD-Datasets, NC-Programmierer haben Zugriff auf CAM-Datasets),
• Zugriffsrechte für Rollen können sowohl abhängig von der Gruppe als auch global vergeben werden (ggf. gibt es nur einen NC-Programmierer für alle Gruppen).
In allgemeiner Hinsicht können von der funktionellen Verantwortlich-keit her drei grundsätzliche Benutzerkategorien, d.h. charakteristische Rollen unterschieden werden, die zur Wahrnehmung ihrer Aufgaben entsprechende Privilegien in der Datenbank benötigen:
• Systemadministratoren
• unterhalten das System,
• Projektleiter
• bestimmen die Zugriffsrechte und
• Sachbearbeiter
• erzeugen Daten (CAD, CAM, etc.).
Objektdaten werden daher vornehmlich von Sachbearbeitern erzeugt, wobei insbesondere der erzeugende User und dessen aktuelle Grup-penzugehörigkeit interessiert. Ein Objekt „gehört“ daher immer einem User (Owning User) und einer Gruppe (Owning Group).
Gegenüber diesen beiden primären Hauptmerkmalen eines Objekts in punkto Zugriff muss der bereits erwähnte Kontext der Sit-zung ermittelt werden. Hierbei kann eine mehr oder weniger feine Untergliederung von Accessors getroffen werden, die idealerweise von einem PLM-System unterstützt werden sollte (vgl. Tab. 1.3). Da für einen Zugreifenden gleichzeitig mehrere Accessors zutreffend sein können, muss in der Regel eine Priorisierung erfolgen, wobei immer vom Owning User absteigend bis zum allgemeinsten Zugriffsprofil World gegliedert wird.
Anwendungsfunktion
Der zweite wesentliche Zugriffsaspekt ist die Anwendungsfunktion, die ein Benutzer ausführen will. Hierfür können eine oder mehrere Zugriffsprivilegien von einem oder mehreren Objekten benötigt wer-den. Im einfachen Fall eines Read-Zugriffs auf ein atomares Objekt wird lediglich eine Read-Erlaubnis auf dasselbe benötigt. Für den etwas komplexeren Fall einer Revisionierung wird je nach systemseiti-ger Modellbildung eine Kopiererlaubnis auf die betreffende Objektre-vision und eine Schreiberlaubnis für das eine Sachnummer repräsentierende Objekt benötigt. Unabhängig davon, ob eine Funk-tion ein oder mehrere Zugriffsprivilegien für ein oder mehrere Objekte benötigt, ist zu beachten, dass hier zunächst von „geforderten Privile-gien“ (!) auszugehen ist.
Objektprivilegien
Der dritte Zugriffsaspekt betrifft die Objekte mit ihren Privilegien selbst. Als kleinstes Granulat sind hier die Einzelprivilegien Read, Write etc. zu unterscheiden, wobei gesamthaft eine ganze Liste möglichst flexibel erweiterbarer Privilegien zu unterscheiden ist (vgl. Tabelle T006obmZ)
Nr. Accessor Bemerkung
1 Owning User Eigentümer des Objekts
2 User spezifischer User (z.B. Müller
3 Role in Owning Group spezifische Rolle in der Eigentümer-Gruppe (z.B CAD-Designer)
4 Role in Group spezifische Rolle
5 Owning Group Gruppe, der das Objekt gehört 6 Administrator Systemadministrator
7 Group spezifische Gruppe
8 World Menge aller Benutzer
Tabelle (T006obmZ) Beispielhafte Rangordnung der Accessors
Im Hinblick auf die Unterstützung dieser Privilegien und der Art und Weise ihrer Definition bestehen einige Unterschiede bei den heutigen PLM-Applikationen, die im Gesamtzusammenhang der verfügbaren Autorisierungsfunktionalität zu vergleichen sind.
6.1.1. Methoden der Autorisierung
Aufbauend auf dem vorstehend dargelegten Grundverständnis wer-den im folgenwer-den die in marktüblichen PLM-Applikationen verfügba-ren Autorisierungskonzepte vorgestellt und analysiert. Hierbei sind drei wesentliche Methoden zu unterscheiden:
• objektbasierende 3 Stufen-Autorisierung,
• objektbasierende ACL-Autorisierung,
• regelbasierende ACL-Autorisierung.
Objektbasierende 3 Stufen-Autorisierung
Abgesehen vom primitiven Schutz transportabler Speichermedien (DAT-Tape, Disketten ect.) durch einen binären Schalter auf Read Only oder Writable stellt die 3 Stufen-Autorisierung die einfachste Methode für einen Zugriffsschutz dar, mit der eine PLM-Applikation betrieben werden kann. In Anlehnung an die Unix-Zugriffsdefinition werden nur drei Accessor-Typen unterstützt:
• Eigentümer (Owning User),
• Gruppe (Owning Group),
Privileg Bemerkung
Read R Recht zum Lesen
Write W Recht zum Schreiben
Delete D Recht zum Löschen
Change C Recht zum Ändern der Rechte
Print P Recht zum Printen
Copy c Recht zum Kopieren
Archive A Recht zum Archivieren
Import I Recht zum Importieren
Export E Recht zum Exportieren
... ...
Tabelle (T007obmZ) Beispiele von Privilegien
• World (Menge aller Benutzer).
Bild (B030obmZ) Beispiel einer 3 Stufen-Autorisierung
Hinsichtlich der Privilegien werden häufig nur Read und Write unter-schieden, wodurch Zugriffsrechte nur sehr rudimentär definiert wer-den können. Erwähnt sei an dieser Stelle, dass oftmals parallel eine objektunabhängige Autorisierung auf Anwendungsfunktionen (z.B.
Archive-Funktion) angeboten wird, wodurch die übrigen Objektprivile-gien zumindest teilweise nachgebildet werden können. Hauptnachteil der 3 Stufen-Autorisierung ist jedoch die Beschränktheit auf die drei allgemeinen Accessors, ohne jede Möglichkeit, spezifische Zugriffs-rechte für andere Gruppen (d.h. Projektteams oder Abteilungen) zu vergeben. Da nur allgemein die Privilegien für die Owning Group und eben nicht für eine spezielle Gruppe (z.B. Arbeitsvorbereitung) verge-ben werden kann, spricht man hier auch von einer Pseudo-Gruppe und einer Pseudo-Autorisierung. Anwendung findet diese Autorisie-rungsmethode beispielsweise im PLM-System Axalant.
Objektbasierende ACL-Autorisierung
Deutlich leistungsfähiger präsentiert sich die Methode der objektspe-zifischen ACL-Autorisierung. Hierbei wird eine sogenannte Access Control List (ACL) eingeführt, die aus mehreren Einträgen besteht, wo jeweils für einen Accessor dessen Privilegien aufgeführt sind (vgl. Bild B031obmZ). Da die ACL-Liste um weitere Accessors beliebig erweiter-bar ist, besteht eine erheblich grössere Flexibilität gegenüber der obenerläuterten 3 Stufen-Autorisierung. Die Privilegien sind in der Regel zwar vielfältiger, aber nicht unbedingt erweiterbar. Angewendet wird diese objektbasierende ACL-Methode in der Mehrzahl der modernen objektorientierten PLM-Systeme, wobei als Beispiel der HP/
WorkManager genannt sei.