Das bisher verwendete Zugriffsschutz-Konzept ist sicherlich sehr leistungsfähig (denkbar sind beliebig komplexe Schutzmechanismen), aber auch für den Anwender etwas unübersichtlich.
Dies liegt zum einen an den ausschließlich verwendeten Zahlen für Lock-/Keycodes an den UTM-Schnittstellen (Generierung, Administration).
Zum anderen muss man sich bei diesem Konzept bei der UTM-Generierung überlegen, auf welche Dienste bestimmte Nutzer zugreifen können sollen.
Häufig ist jedoch der umgedrehte Denkansatz leichter: Welche Nutzer sollen auf diesen Dienst zugreifen dürfen?
Einen solchen Denkansatz verfolgt das "neue" Zugriffsschutz-Konzept.
Dieses Konzept führt den "Rollenbegriff" ein. Jedem Nutzer können eine oder mehrere Rollen zugeordnet werden (z.B. "Chef", "Sachbearbeiter" oder "Hausmeister"). Soll der Zugriff auf einen Dienst geschützt werden, so wird am Dienst eine Zugriffsliste hinterlegt. Diese Zugriffsliste enthält ebenfalls eine oder mehrere Rollen. Es dürfen dann nur die Nutzer auf den Dienst zugreifen, die mindestens eine in der Zugriffsliste vorhandene Rolle haben. So könnte z.B. die Zugriffsliste des Dienstes "Gehalt" die Rollen "Chef" und "Lohnbuchhalter" enthalten, da alle Chefs und Lohnbuchhalter diesen Dienst nutzen können sollen, Hausmeister jedoch nicht.
Dieses Konzept ist sehr weitgehend auf das "alte" Schloss/Schlüssel-Konzept zurückzuführen: Man interpretiert die Key–/Lockcodes einfach als Rollen. Je ein bestimmter Key/Lockcode entspricht einer bestimmten Rolle (Code "1" entspricht z.B. der Rolle "Sachbearbeiter").Ein Keyset entspricht dann einer Rollenliste aber auch einer Zugriffsliste.
Das Festlegen der Berechtigungen der Nutzer und Koppler in Form von Rollenlisten entspricht dem Generieren eines Ksets an den Nutzer- und Koppler-Objekten.Für das Festlegen von Zugriffslisten bei Diensten wurden die Generierungsanweisungen der Objekttypen Tac und Ltac um den Parameter ACCESS-LIST erweitert, der das Zuweisen einer Zugriffsliste in Form eines Keysets ermöglicht.
Um das neue Konzept möglichst einfach und übersichtlich zu gestalten, wurde auf die Möglichkeit verzichtet, auch den Kopplern Zugriffslisten zuzuweisen. Der Parameter LOCK an den Kopplern Lterm und Tpool wird aus Kompatibilitätsgründen weiter unterstützt. Es ist jedoch zu empfehlen, den Kopplern keine Lockcodes zu geben. Die Koppler sind dann zwar alle ungeschützt, das macht aber nichts, da nicht die Koppler selbst die schützenswerten Ressourcen sind, sondern die Dienste in Form von Tacs und Ltacs.
Ein Nutzer kann also bei dem neuen Konzept nur dann auf einen Dienst zugreifen, wenn er
- eine Rolle besitzt, die in der Zugriffsliste des Dienstes hinterlegt ist, oder der Dienst ungeschützt ist
und - der verwendete Koppler eine Rolle besitzt, die in der Zugriffsliste des Dienstes hinterlegt ist, oder der Dienst ungeschützt ist.
Dieses Konzept wird von WebAdmin unterstützt. Wie, das wird in den nächsten Abschnitten detailliert beschrieben.