3. Verfahrenselemente

Dieser Abschnitt beschreibt die Verfahren, die von einem Access Control-Modul befolgt werden, das das View-based Access Control Model implementiert, wenn es eine Service-Anfrage von einer Anwendung erhält (zum Beispiel einer Command Responder-Anwendung oder einer Notification Originator-Anwendung).

3.1. Überblick über den isAccessAllowed-Prozess

Das View-based Access Control Model stellt ein Service-Primitiv bereit, isAccessAllowed, das von einer Anwendung verwendet wird, wenn sie feststellen muss, ob der Zugriff auf eine bestimmte verwaltete Objektinstanz für eine bestimmte Operation erlaubt ist.

Die Eingaben für das isAccessAllowed-Service-Primitiv sind:

• securityModel - das verwendete Sicherheitsmodell
• securityName - der Prinzipal, dessen Zugriffsrechte geprüft werden
• securityLevel - die Sicherheitsstufe
• viewType - die Art des angeforderten Zugriffs (Lesen, Schreiben oder Benachrichtigen)
• contextName - der Kontext, der die Objektinstanz enthält
• variableName - die Objektinstanz, auf die zugegriffen wird

Die Ausgabe des isAccessAllowed-Service-Primitivs ist:

• errorIndication - Erfolgs- oder Fehleranzeige

Das Service-Primitiv verwendet die Eingabewerte, um festzustellen, ob der Zugriff erlaubt ist. Die Feststellung wird durch Folgendes getroffen:

1. Verwendung von securityModel und securityName zur Bestimmung des groupName aus der vacmSecurityToGroupTable.

2. Verwendung des bestimmten groupName, des eingegebenen securityModel, des eingegebenen securityLevel, des eingegebenen contextName und der Informationen aus der vacmAccessTable zur Bestimmung der MIB-View (identifiziert durch viewName), die für den angeforderten viewType (Lesen, Schreiben oder Benachrichtigen) verwendet werden soll.

3. Verwendung des bestimmten viewName und des eingegebenen variableName zur Feststellung über die vacmViewTreeFamilyTable, ob der variableName in der durch den viewName identifizierten MIB-View enthalten ist.

Wenn der variableName in der MIB-View enthalten ist, dann ist der Zugriff erlaubt und das Service-Primitiv gibt Erfolg zurück. Andernfalls ist der Zugriff nicht erlaubt und das Service-Primitiv gibt eine Fehleranzeige zurück.

3.2. Verarbeitung der isAccessAllowed-Service-Anfrage

Das folgende Verfahren wird von einem Access Control-Modul befolgt, das das View-based Access Control Model implementiert, wenn es eine isAccessAllowed-Service-Anfrage erhält.

1. Die vacmContextTable wird konsultiert, um zu prüfen, ob Informationen über den durch den contextName-Parameter identifizierten SNMP-Kontext verfügbar sind. Wenn Informationen über diesen SNMP-Kontext in der vacmContextTable fehlen, wird eine errorIndication (noSuchContext) an das aufrufende Modul zurückgegeben.

2. Die vacmSecurityToGroupTable wird nach einem Eintrag konsultiert, dessen vacmSecurityModel-Komponente gleich dem securityModel-Parameter und dessen vacmSecurityName-Komponente gleich dem securityName-Parameter ist. Wenn kein übereinstimmender Eintrag gefunden wird oder wenn der Wert von vacmGroupName die leere Zeichenkette ist, wird eine errorIndication (noGroupName) an das aufrufende Modul zurückgegeben. Andernfalls wird die Verarbeitung mit dem Wert von vacmGroupName aus dem übereinstimmenden Eintrag als Gruppe fortgesetzt.

3. Die vacmAccessTable wird nach Einträgen konsultiert, deren Werte von vacmGroupName, vacmAccessContextPrefix, vacmAccessSecurityModel und vacmAccessSecurityLevel mit der Gruppe, contextName, securityModel bzw. securityLevel übereinstimmen. Es kann null, einen oder mehrere solcher Einträge geben.

   Die Übereinstimmung des contextName mit dem vacmAccessContextPrefix wird wie folgt durchgeführt:

   a) Wenn vacmAccessContextMatch exact ist, muss der contextName genau mit dem Wert von vacmAccessContextPrefix übereinstimmen.

   b) Wenn vacmAccessContextMatch prefix ist, müssen die ersten N Zeichen von contextName mit den N Zeichen von vacmAccessContextPrefix übereinstimmen, wobei N die Länge von vacmAccessContextPrefix ist.

   Zum Zweck der Übereinstimmung kann vacmAccessSecurityModel einen Wildcard-Wert (any) enthalten, der mit jedem securityModel-Wert übereinstimmt.

   Zum Zweck der Übereinstimmung kann vacmAccessSecurityLevel gleich oder kleiner als der securityLevel-Wert sein, wobei:

   noAuthNoPriv < authNoPriv < authPriv

   Wenn mehr als ein vacmAccessEntry übereinstimmt, wird der Eintrag mit dem längsten contextPrefix ausgewählt. Wenn es mehrere Einträge mit demselben längsten contextPrefix gibt, wird der Eintrag mit dem höchsten securityLevel ausgewählt. Wenn es mehrere Einträge mit demselben längsten contextPrefix und demselben securityLevel gibt, wird der Eintrag mit dem höchsten Wert von vacmAccessSecurityModel ausgewählt. Im unwahrscheinlichen Fall, dass es immer noch mehrere übereinstimmende Einträge gibt, wird der lexikografisch kleinste Eintrag ausgewählt.

   Wenn es keine übereinstimmenden Einträge gibt, wird eine errorIndication (noAccessEntry) an das aufrufende Modul zurückgegeben.

4. Abhängig vom Wert von viewType wird entweder der vacmAccessReadViewName oder der vacmAccessWriteViewName oder der vacmAccessNotifyViewName als viewName ausgewählt. Wenn der ausgewählte viewName die leere Zeichenkette ist, wird eine errorIndication (noSuchView) an das aufrufende Modul zurückgegeben.

5. Die vacmViewTreeFamilyTable wird konsultiert, um festzustellen, ob der variableName in der durch den ausgewählten viewName identifizierten MIB-View enthalten ist. Dies geschieht wie folgt:

   a) Für jede aktive Zeile in der vacmViewTreeFamilyTable, deren vacmViewTreeFamilyViewName gleich dem ausgewählten viewName ist, wird festgestellt, ob der variableName ein Mitglied der durch die Zeile definierten viewTreeFamily ist. Dies geschieht gemäß dem in Abschnitt 2.4.2 definierten Verfahren.

   b) Wenn der variableName ein Mitglied einer viewTreeFamily ist, deren vacmViewTreeFamilyType excluded(2) ist, dann ist der variableName nicht in der MIB-View, und eine errorIndication (notInView) wird an das aufrufende Modul zurückgegeben.

   c) Wenn der variableName ein Mitglied einer viewTreeFamily ist, deren vacmViewTreeFamilyType included(1) ist, dann ist der variableName in der MIB-View, und das Service-Primitiv gibt Erfolg an das aufrufende Modul zurück.

   d) Wenn der variableName kein Mitglied irgendeiner viewTreeFamily für den ausgewählten viewName ist, dann ist er nicht in der MIB-View, und eine errorIndication (notInView) wird an das aufrufende Modul zurückgegeben.