Sign up to receive free email alerts when patent applications with chosen keywords are publishedSIGN UP

Abstract:

Controlling access to managed objects associated with a networked device.
A method comprises receiving a request from a principal for access to a
managed object associated with the networked device. The managed objects
are accessible based on membership in access groups that are compliant
with a Simple Network Management Protocol (SNMP). A first and a second of
the access groups associated with the principal are determined. Access
privileges for the principal are determined, based on the first and the
second access groups. Access to the managed object is granted if
permitted based on the access privileges for the principal.

Claims:

1. A network management device comprising:a network management engine
configured to send a request for access to managed objects defined in a
management information base associated with a remote managed
device,wherein the request indicates a principal is a member of at least
one of a plurality of access groups compliant with a Simple Network
Management Protocol (SNMP),wherein each of the plurality access groups
defines a set of access privileges,wherein access to the managed objects
is based on membership in at least one of the plurality of access
groups;wherein the network management engine is aware that the remote
managed device is compliant with SNMP and not aware that the remote
managed device is configured to perform access control based on roles in
accordance with a Role-Based Command Line Interface (CLI) Access protocol
by aligning SNMP compliant access groups with corresponding roles of the
Role-Based CLI Access protocol.

2. The network management device of claim 1, wherein the management node
issues a request on behalf of a principal belonging to a first and a
second of the plurality of access groups.

3. The network management device of claim 1, further comprising a command
generator module configured to initiate a request to add or delete the
principal name to or from at least one of the plurality of access groups.

4. The network management device of claim 3, wherein the command module is
configured to modify a security to group table stored in a management
information base associated with a network device managed by the network
management device.

5. The network management device of claim 1, wherein the network
management engine is not aware that the managed device is configured to
map information associated with the principal to multiple access groups
of the plurality of access groups.

7. A network device comprising:a first management engine configured for
controlling access to a managed object, wherein the first management
engine permits access to the managed object based on a membership in one
or more access groups, wherein membership is determined by mapping a
combination of a security name and security model to at least one access
group name;wherein the first management engine is compliant with a
Role-Based Command Line Interface (CLI) Access protocol and a Simple
Network Management Protocol (SNMP);wherein the first management engine is
further configured to send a response to a request for access to the
managed object,wherein the format of the request is compliant with in the
SNMP;wherein the response to the SNMP request for access is based on
mapping in compliance with both the Role-Based Command Line Interface
(CLI) Access protocol and a Simple Network Management Protocol (SNMP).

8. The network device of claim 7, wherein the access groups define one or
more access privileges to the managed object.

9. The network device of claim 7, wherein the access groups define one or
more access privileges to the managed object.

10. The network device of claim 7, wherein the one or more access groups
align with SNMP compliant access groups and map to respective analogous
roles compliant with the Role-Based CLI Access protocol.

11. The network device of claim 9, wherein the alignment corresponds to a
unified security model.

12. A method of controlling access to a managed object associated with a
networked device, said method comprising:storing one or more tables
configured to map a combination of a principal name and security model to
at least one access group name compliant with both a Simple Network
Management Protocol (SNMP) and Role-Based Command Line Interface (CLI)
Access protocol;receiving a request from the principal for access to a
managed object associated with the networked device, the request format
SNMP compliant and including the principal name and an indication of a
security model;associating one or more access groups with the principal
by mapping the principal name and the security group identified in the
request to the corresponding one or more access groups indicated in the
one or more tables;determining a set of access privileges for the
principal based on the one or more access groups; andgranting access to
said managed object if the determined set of access privileges for said
principal comprises an access privilege to said managed object;wherein
the managed object is accessible based on both the requesting principal's
membership in one or more access groups that are compliant with a SNMP
and based on access based on CLI Roles mapped to all identified SNMP
compliant groups via the stored mapping tables.

13. The method as recited in claim 12, wherein the requesting device is
aware that the networked device is compliant with SNMP.

14. The method as recited in claim 13, wherein the requesting device is
not aware that the networked device is compliant with Role-Based CLI
Access protocol.

15. The method as recited in claim 13, wherein the associating is executed
transparently to a requesting device that is non-compliant with
Role-Based Command Line Interface (CLI) Access protocol and aware that
the networked device is compliant with SNMP.

16. The method as recited in claim 12, wherein the one or more access
groups align with SNMP compliant access groups and to respective
analogous roles compliant with the Role-Based CLI Access protocol.

17. The method as recited in claim 16, wherein the alignment corresponds
to a unified security model.

Description:

RELATED APPLICATIONS

[0001]This application is a continuation of pending U.S. patent
application Ser. No. 11/107,500, filed Apr. 15, 2005, which is
incorporated herein by reference.

FIELD OF THE INVENTION

[0002]Embodiments of the present invention relate to managing devices
coupled to a network. More specifically, embodiments of the present
invention relate to a method, system, and apparatus for controlling
access to managed objects associated with networked devices.

BACKGROUND OF THE INVENTION

[0003]Simple Network Protocol Management (SNMP) provides a simple protocol
for managing devices in a network. FIG. 1 illustrates a network
management station 120 communicating with agents 124 in managed devices
126 via an SNMP protocol. The network management station 120 executes
network management applications 122 that monitor and control the managed
devices 126. The interface 128 allows users 130, such as network
administrators, to access the network management station 120.

[0004]The managed devices 126 have agents 124, which are typically
software modules that collect and store management information and
provide an interface between the network management station 120 and the
managed device(s) 126. The network management station 120 and the agents
124 communicate via a simple set of commands and employ a Management
Information Sase (MIS) 132. A MIS 132 describes various managed objects
associated with its managed device 126. To retrieve or modify
information, the network management station 120 sends a request to the
managed device 126, identifying a managed object in the MIS 132.

[0005]Principals may make requests to access the managed objects via the
network management station. A principal may be a user acting in a
particular role, a set of users each acting in a particular role, an
application, a set of applications, or a combination of these. SNMP has
an access control mechanism that controls the access privileges a
principal has to managed objects. For example, one principal may only
have read access to certain managed objects, while another principal may
have read/write access to those managed objects. Furthermore, access
control may be used in connection with SNMP notification messages.

[0006]SNMP has a specification for an engine that comprises an access
control subsystem that checks whether a specific type of access (e.g.,
read, write, notify) to a particular managed object (instance) is
allowed. The access control subsystem may use an access control model
that specifies sets of access control rules that pertain to respective
groups of principals. In the SNMP viewbased access control model (VACM),
a group is a set of principals that have certain access privileges to
managed objects. In an SNMP view-based access control model, the
combination of a securityModel and a securityName maps to at most one
group. A securityName is the principal on whose behalf access is
requested and a securityModel is a security model under which access is
requested. Some SNMP access control models are known as "view-based."
However, other than "view-based" models are contemplated.

[0007]The relative simplicity of SNMP has led to its proliferation.
However, SNMP's simplicity constrains its flexibility and functionality.
For example, an ultimate determination of access to a managed object may
involve additional factors to those already discussed, including:
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), and variableName (object instance
to which access is requested). Because many factors are involved in
determining access to a managed object in a networked device, it would be
possible for complexity to increase greatly if individual portions of the
overall process are made even slightly more complex. Moreover, it is
difficult to foresee where a benefit of adding complexity to the process
may outweigh a cost of the added complexity.

[0008]Therefore, it would be desirable to have a method and system for
management of networked devices that is simple and flexible. It would be
advantageous if this method and system were compatible with an SNMP
protocol.

BRIEF DESCRIPTION OF THE DRAWINGS

[0009]The accompanying drawings, which are incorporated in and form a part
of this specification, illustrate embodiments of the invention and,
together with the description, serve to explain the principles of the
invention:

[0011]FIG. 2 illustrates a network in accordance with an embodiment of the
present invention.

[0012]FIG. 3A and FIG. 3B illustrate tables used to determine access
privileges in accordance with an embodiment of the present invention.

[0013]FIG. 4 is a flowchart illustrating steps of a process of controlling
access to managed objects in a network device, in accordance with an
embodiment of the present invention.

DETAILED DESCRIPTION

[0014]Reference will now be made in detail to various embodiments of the
invention, examples of which are illustrated in the accompanying
drawings. While the invention will be described in conjunction with
various embodiments, it will be understood that they are not intended to
limit the invention to these embodiments. On the contrary, the invention
is intended to cover alternatives, modifications and equivalents, which
may be included within the spirit and the scope of the invention as
defined by the appended claims. Furthermore, in the following detailed
description of the present invention, numerous specific details are set
forth in order to provide a thorough understanding of the present
invention. However, it will be apparent to one skilled in the art that
the present invention may be practiced without these specific details. In
other instances, wellknown methods, procedures, components, structures
and devices have not been described in detail so as to avoid
unnecessarily obscuring aspects of the present invention.

[0015]FIG. 2 illustrates a network 200 in accordance with an embodiment of
the present invention. The network management station 120 receives
requests from a principal (e.g., user 130, application 122) for access to
managed objects associated with one of the managed devices 126. Each
principal is a part of at least one group that defines access privileges
to managed objects. A principal's access privileges are defined by the
union of the privileges of all groups to which a principal belongs, in
one embodiment. However, the principal's access privileges may be defined
by other than the union of the privileges of all groups to which a
principal belongs.

[0016]Each managed device 126 has a management information base (MIS) 132
defining managed objects. In one embodiment, the managed objects are
accessible based on membership in access groups that are compliant with a
Simple Network Management Protocol (SNMP). Each access group defines a
set of access privileges accorded to the principals in the group. In one
embodiment, if a principal is a member of any SNMP group that has access
privileges to the managed object, it is allowed access. Each managed
device 126 also has an engine 202 for controlling access to the managed
objects. The engine 202 enforces a set of rules for accessing the managed
objects. The rules comprise a rule in which a principal name is allowed
to belong to more than one access group. The managed device may be a
router, switch, etc.

[0017]The network 200 has a network management station 120 communicatively
coupled to the managed devices 126, wherein the network management
station 120 is operable to send requests to the managed devices 126 for
access to the managed objects. In this fashion, the network management
station 120 may be used to view and configure parameters associated with
the managed devices 126.

[0018]In one embodiment, one of the applications 122 is a command
generator application that initiates a request to add or delete a
security name (or principal name) to or from a group. In this fashion,
one or more of the security to group tables 206 are modified by the
application 122.

[0019]However, it is not required that the applications 122 or the network
management station engine 203 be aware of a managed device's ability to
map a security name/security model combination to multiple groups. Thus
in one embodiment, the engine 203 is compliant with an SNMP protocol that
allows a security name/security model combination to map to only a single
group. In one embodiment, an application is compliant with an SNMP
protocol that allows a security name/security model combination to map to
only a single group.

[0020]The managed devices 126 have stored thereon one or more security to
group tables 206 that map a combination of a security name and security
model to at least one group name. Furthermore, the managed devices 126
have stored thereon an access table 208 that defines access privileges
for each group. The MIS 132 defines the structure for the security to
group tables 206 and the access table 208. An exemplary MIS is described
herein.

[0021]In one embodiment, the managed devices 126 and network management
station 120 have processors for implementing the engines (202, 203) and
computer readable media for implementing the MISs (132). For example, the
security to group tables 206 and access tables 208 may be stored in a
computer readable medium that is accessible by the engine 202.

[0022]FIG. 3A illustrates tables used to determine access privileges in
accordance with an embodiment of the present invention. In particular,
FIG. 3A illustrates access privileges determination for a received
request. The request comprises a principal name and a security model, in
this embodiment. In one embodiment, the format of the request is
compliant with in an SNMP protocol, such as "An Architecture for
Describing SNMP Management Frameworks (RFC 3411). However, the request is
not limited to this architecture. The security to group table 206 is
organized with rows each having an entry for a principal name, a security
model, a group name, a storage type, and a status. The security to group
table 206 allows a combination of a principal name and a security model
to be mapped to multiple groups. In this example, the combination of the
principal name of "A" and security model "1" are associated with group
names "G 1" and "G2".

[0023]The access privileges table 208 contains a row for each group,
wherein each group has a defined set of access privileges. In this
example, the access privileges table 208 is indexed separately with group
G1 and with group G2, wherein the access privileges are the union of the
privileges accorded to group G1 and group G2. However, the access
privileges do not have to be formed by a logical union. In one
embodiment, the access table 208 is compliant with an SNMP protocol.
Thus, managed objects may be accessible based on a requesting principal's
membership in access groups that are compliant with a Simple Network
Management Protocol (SNMP).

[0024]FIG. 38 illustrates tables used to determine access privileges in
accordance with an embodiment of the present invention. FIG. 38
illustrates an extended security to group table 206b and an access
privilege table 208 that are similar to the tables in FIG. 3A. FIG. 38
also has a basic security to group table 206a that maps a combination of
a security name and a security model to only one group. In one
embodiment, basic security to group table 206a is compliant with an SNMP
protocol. In one embodiment, the group table 206a is compliant with
"View-based Access Control Model (VACM) for the Simple Network Management
Protocol (SNMP) (RFC 3415). However, the basic security to group table
206a is not limited to this implementation. In the example of FIG. 38,
the combination of the security name "A" and security model "1" are
associated with only group name "G4", in the basic security to group
table 206a. Furthermore, in this example, the access privileges table 208
is indexed separately with group names "G1", "G2" and "G4," wherein the
access privileges are the union of the privileges accorded to groups
"G1", "G2" and "G4." However, the access privileges may be formed by
other than the union of the privileges accorded to groups "G1", "G2" and
"G4."

[0025]Table I-Table V define portions of an exemplary MIS that may be used
as an extension of a "vacmSecurityToGroupTable" defined in an SNMP
protocol, such as RFC 3415. However, the present invention is not limited
to this exemplary MIS. Furthermore, the present invention limited to an
extension of a "vacmSecurityToGroupTable" defined in an SNMP protocol.

[0026]Table I depicts a structure for an exemplary security to group
table, "cvacmSecurityToGroupTable", in accordance with an embodiment of
the present invention. The cvacmSecurityToGroupTable table depicted in
Table I provides a mechanism to map a combination of `securityModel` and
`securityName` into one or more groups in addition to the `vacmGroupName`
mapped in the `vacmSecurityToGroupTable` that are defined in an SNMP
protocol such as RFC 3415. These groups provided for by the
"cvacmSecurityToGroupTable" provide additional access control policies
for a principal.

[0027]In one embodiment, the agent allows the same group mapping entry to
be present in both the `cvacmSecurityToGroupTable` and the
`vacmSecurityToGroupTable`.

[0028]A row in the "cvacmSecurityToGroup" table does not exist without a
corresponding row for the same combination of "securityModel" and
"securityName" in the "vacmSecurityToGroupTable", in one embodiment.
While creating a row in the "cvacmSecurityToGroupTable" table, if there
is no corresponding row for the same combination of "securityModel" and
"securityName" in the `"vacmSecurityToGroupTable," the same mapping entry
is created in the "vacmSecurityToGroupTable" by the agent using the
values of instance variables of the entry in the
"cvacmSecurityToGroupTable" table, in one embodiment.

[0029]The deletion of a row in the `vacmSecurityToGroupTable`, also causes
the deletion of all the group mapping entries for the same combination of
`vacmSequrityModel` and vacmSecurityName` in the
`cvacmSecurityToGroupTable`, in one embodiment. The deletion of a row in
this table does not affect `vacmSecurityToGroupTable` entries, in one
embodiment.

[0030]Table II describes a conceptual row "cvacmSecurityToGroupEntry" in
the "cvacmSecurityToGroup Table" depicted in Table I herein. Each row
represents one groupName mapping for the combination of `securityModel`
and `securityName` in the system. Further, each row comprises a storage
type and row status. Table II describes an index for the
"cvacmSecurityToGroupTable," wherein "cvacmSecurityGrpName" is described
herein in Table III herein.

[0031]Table III depicts a group name "cvacmSecurityGrpName," which is the
name of the group for the mapping represented by this row. This is in
addition to the `vacmGroupName` mapped in the `vacmSecurityToGroupTable`.
For example, a principal represented by `securityName` maps to a group
represented by `cvacmSecurityGrpName` under a security model represented
by `securityModel`. This groupName is used as index into the
`vacmAccessTable` described in RFC 3415, in one embodiment. However, a
value in this table does not imply that an instance with the value exists
in table `vacmAccessTable`. Referring to Table II herein, the group name
"cvacmSecurityGrpName" is entry 1 in the sequence.

[0032]Table IV depicts the storage type for a conceptual row. Conceptual
rows having the value `permanent` need not allow write-access to any
columnar objects in the row, in one embodiment. Referring to Table II
herein, the storage type is entry 2 in the sequence.

[0033]Table V depicts the row status "cvacmSecurityGrpStatus" for a
conceptual row. The value of this object has no effect on whether other
objects in this conceptual row can be modified, in one embodiment.
Referring to Table II herein, the row status is entry 3 in the sequence.

[0034]FIG. 4 is a flowchart illustrating steps of a process 400 of
controlling access to managed objects in a network device, in accordance
with an embodiment of the present invention. Process 400 may be
implemented by engine 202 of managed device 126, although process 400 is
not so limited. In one embodiment, process 400 is implemented as
instructions embedded in a computer readable medium and executed in a
processor. However, process 400 may be implemented by hardware or a
combination of hardware and software. Step 410 is receiving a request
from a principal for access to a managed object associated with the
networked device. The managed objects are accessible based on a
requesting principal's membership in access groups that are compliant
with a Simple Network Management Protocol (SNMP), in one embodiment.

[0035]Step 420 is determining a first access group associated with the
principal. In one embodiment, step 420 comprises indexing a table that
maps a principal name/security model combination to a single access
group. However, step 420 is not limited to indexing a table that maps a
principal name/security model combination to a single access group.

[0036]Step 430 is determining access privileges for the principal based on
the presently examined access group. Step 430 may comprise indexing an
access table with the group name determined in step 420 (or step 460). In
one embodiment, the access table is compliant with an SNMP protocol.

[0037]Step 435 is granting access to the m-anaged object if permitted
based on the access privileges for the principal.

[0038]If access to the managed object is not allowed based on the group,
then step 440 is performed to determine of the principal belongs to more
access groups. If the principal is not in another access group, access to
the managed object is denied in step 450. Process 400 then ends.

[0039]If the principal is in another access group, the next access group
is determined in step 460. Step 460 may include indexing a table that may
map a security name/security model to more than one access group. Process
400 then returns to step 430 to determine if access to the managed object
is allowed for this access group. Process 400 continues until either
access is granted or there are no more access groups for the principal.

[0040]SNMP groups may roughly map to Command Line Interface (eLi) "roles."
Generally, it is possible to associate multiple roles with a CLI
principal (e.g., user, application). However, a conventional SNMP
protocol does not allow association of multiple groups with a single
principal (e.g., user, principal). Embodiments of the present invention
allow a single principal to be associated with multiple groups. Hence, an
embodiment of the present invention allows groups to be aligned with CLI
roles, enabling a unified security model.

[0041]Table VI depicts how allowing users to be assigned to multiple
groups allows a unified security model, in accordance with an embodiment
of the present invention. The CLI users U1, U2, and U3 might be assigned
roles R1-RS as depicted. Embodiments of the present invention allow
alignment of the user roles to SNMP groups, wherein the user is assigned
to SNMP groups that are analogous to CLI roles. Therefore, users U1-U3
are assigned to groups G1-GS, wherein groups G1-GS are similar in
functionality as their corresponding roles R1-RS in CLI.

[0042]The foregoing descriptions of specific embodiments of the present
invention have been presented for purposes of illustration and
description. They are not intended to be exhaustive or to limit the
invention to the precise forms disclosed. Many modifications and
variations are possible in light of the above teachings. The embodiments
were chosen and described in order to best explain the principles of the
invention and its practical application, to thereby enable others skilled
in the art to best utilize the invention and various embodiments with
various modifications as are suited to the particular use contemplated.
It is intended that the scope of the invention be defined by the Claims
appended hereto and their equivalents.