Skip to main content

3. Elements of Procedure

  1. Elements of Procedure

This section describes the procedures followed by an Access Control module that implements the View-based Access Control Model when checking access rights as requested by an application (for example a Command Responder or a Notification Originator application). The abstract service primitive is:

  statusInformation =          -- success or errorIndication
      isAccessAllowed(
          securityModel        -- Security Model in use
          securityName         -- principal who wants access
          securityLevel        -- Level of Security
          viewType             -- read, write, or notify view
          contextName          -- context containing variableName
          variableName         -- OID for the managed object
          )

The abstract data elements are:

  statusInformation - one of the following:
     accessAllowed  - a MIB view was found and access is granted.
     notInView      - a MIB view was found but access is denied.
                      The variableName is not in the configured
                      MIB view for the specified viewType (e.g., in
                      the relevant entry in the vacmAccessTable).
     noSuchView     - no MIB view found because no view has been
                      configured for specified viewType (e.g., in
                      the relevant entry in the vacmAccessTable).
     noSuchContext  - no MIB view found because of no entry in the
                      vacmContextTable for specified contextName.
     noGroupName    - no MIB view found because no entry has been
                      configured in the vacmSecurityToGroupTable
                      for the specified combination of
                      securityModel and securityName.
     noAccessEntry  - no MIB view found because no entry has been
                      configured in the vacmAccessTable for the
                      specified combination of contextName,
                      groupName (from vacmSecurityToGroupTable),
                      securityModel and securityLevel.
     otherError     - failure, an undefined error occurred.
  securityModel - Security Model under which access is requested.
  securityName  - the principal on whose behalf access is requested.
  securityLevel - Level of Security under which access is requested.
  viewType      - view to be checked (read, write or notify).
  contextName   - context in which access is requested.
  variableName  - object instance to which access is requested.

3.1. Overview of isAccessAllowed Process

The following picture shows how the decision for access control is made by the View-based Access Control Model.

+--------------------------------------------------------------------+ | | | +-> securityModel -+ | | | (a) | | | who -+ +-> groupName ----+ | | (1) | | (x) | | | +-> securityName --+ | | | (b) | | | | | | where -> contextName ---------------------+ | | (2) (e) | | | | | | | | | +-> securityModel -------------------+ | | | (a) | | | how -+ +-> viewName -+ | | (3) | | (y) | | | +-> securityLevel -------------------+ | | | (c) | +-> yes/no | | | | decision | | why ---> viewType (read/write/notify) ----+ | (z) | | (4) (d) | | | | | | what --> object-type ------+ | | | (5) (m) | | | | +-> variableName (OID) ------+ | | | (f) | | which -> object-instance --+ | | (6) (n) | | | +--------------------------------------------------------------------+

How the decision for isAccessAllowed is made.

  1. Inputs to the isAccessAllowed service are:

    (a) securityModel -- Security Model in use (b) securityName -- principal who wants to access (c) securityLevel -- Level of Security (d) viewType -- read, write, or notify view (e) contextName -- context containing variableName (f) variableName -- OID for the managed object -- this is made up of: - object-type (m) - object-instance (n)

  2. The partial "who" (1), represented by the securityModel (a) and the securityName (b), are used as the indices (a,b) into the vacmSecurityToGroupTable to find a single entry that produces a group, represented by groupName (x).

  3. The "where" (2), represented by the contextName (e), the "who", represented by the groupName (x) from the previous step, and the "how" (3), represented by securityModel (a) and securityLevel (c), are used as indices (e,x,a,c) into the vacmAccessTable to find a single entry that contains three MIB views.

  4. The "why" (4), represented by the viewType (d), is used to select the proper MIB view, represented by a viewName (y), from the vacmAccessEntry selected in the previous step. This viewName (y) is an index into the vacmViewTreeFamilyTable and selects the set of entries that define the variableNames which are included in or excluded from the MIB view identified by the viewName (y).

  5. The "what" (5) type of management data and "which" (6) particular instance, represented by the variableName (f), is then checked to be in the MIB view or not, e.g., the yes/no decision (z).

3.2. Processing the isAccessAllowed Service Request

This section describes the procedure followed by an Access Control module that implements the View-based Access Control Model whenever it receives an isAccessAllowed request.

  1. The vacmContextTable is consulted for information about the SNMP context identified by the contextName. If information about this SNMP context is absent from the table, then an errorIndication (noSuchContext) is returned to the calling module.

  2. The vacmSecurityToGroupTable is consulted for mapping the securityModel and securityName to a groupName. If the information about this combination is absent from the table, then an errorIndication (noGroupName) is returned to the calling module.

  3. The vacmAccessTable is consulted for information about the groupName, contextName, securityModel and securityLevel. If information about this combination is absent from the table, then an errorIndication (noAccessEntry) is returned to the calling module.

  4. a) If the viewType is "read", then the read view is used for checking access rights.

    b) If the viewType is "write", then the write view is used for checking access rights.

    c) If the viewType is "notify", then the notify view is used for checking access rights.

    If the view to be used is the empty view (zero length viewName) then an errorIndication (noSuchView) is returned to the calling module.

  5. a) If there is no view configured for the specified viewType, then an errorIndication (noSuchView) is returned to the calling module.

    b) If the specified variableName (object instance) is not in the MIB view (see DESCRIPTION clause for vacmViewTreeFamilyTable in section 4), then an errorIndication (notInView) is returned to the calling module.

    Otherwise,

    c) The specified variableName is in the MIB view. A statusInformation of success (accessAllowed) is returned to the calling module.

Last updated on