ROLE DERIVATION BV REMOTELY IMPLEMENTED NETWORK SECURITY POLICIES

FIELD OF THE INVENTION

This invention relates to the field of computer network security and, more specifically, to derivation of roles of remotely located user in a network security appliance for effective implementation of role-based security policies.

BACKGROUND

Along with the introduction and growth of interconnected computer networks into every aspect of modern life, malicious activity within such computer networks has also worked its way into every aspect of modern life. Such malicious activity is combatted with various tools such as antivirus software and firewalls.

One of the most powerful security measures for a managed site area network, often an enterprise-administered local area network (LAN), is a locally enforced policy to regulate traffic coming into and leaving the site area network. Complex policies are typically implemented in host computer in which the full processing capabilities and full application-level information available in a general-purpose computer. A better place to implement a policy is at the nodes of the network. However, while user identification for role-based policy enforcement is a simple matter of user authentication in a host computer with which the user directly interacts, such user identification in remotely located network nodes is a different matter altogether.

What is needed is a way to remotely identify users associated with network flows to effectively implement role-based policies in network nodes.

SUMMARY OF THE INVENTION

In accordance with the present invention, role derivation logic in a network security appliance monitors network traffic for authentication events and leverages observed authentication events to identify users associated with network flows for role- based policy enforcement. The role derivation logic includes a rule engine that processes attributes of the authentication event and of the user associated therewith to attribute one

or more roles to the user. The attributes are represented in a standardized form according to one or more predefined attribute data types processed by the rules engine. As a result, the rules engine is extensible in that new attributes can be processed so long as the new attributes can be expressed in one of the predefined attribute data types. Extensibility is important because the role derivation logic queries one or more remotely located directory servers for additional information regarding the user of the authentication event. Thus, a user identifier of the authentication event can be used to leverage directory servers for such additional information as the user's address, social security number, department within an organization, etc. can be used to attribute one or more roles to the user. Each attribute of the user stored in the directory server can be used in a rule defining one or more roles of users. Adding such attributes does not require modification of the rule engine so long as the attributes can be expressed in one of the predefined attribute data types.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a diagram illustrating a local area network that includes a network security appliance according to the present invention.

Figure 2 is a block diagram showing the network security appliance of Figure 1 in greater detail.

Figure 3 is a block diagram showing a policy engine of the network security appliance of Figure 2 in greater detail. Figure 4 is a block diagram of role derivation logic of the policy engine of Figure 3 in greater detail.

Figure 5 is a logic flow diagram of the processing of the role derivation logic of Figure 4.

Figure 6 is a block diagram of an authenticated user profile of the role derivation logic of Figure 4 in greater detail.

Figure 7 is a block diagram of a flow user/role record of the role derivation logic of Figure 4 in greater detail.

Figure 8 is a block diagram of an attribute map used by the role derivation logic of

Figure 4 in greater detail.

Figure 9 is a block diagram of an attribute definition corresponding to the attribute map of Figure 8.

Figure 10 is a block diagram of a rule map of the role derivation logic of Figure 4 in greater detail.

Figure 11 is a block diagram of a condition of the rule map of Figure 10 in greater detail.

Figure 12 is a block diagram of an action of the rule map of Figure 10 in greater detail. Figure 13 is a block diagram of an LDAP manager of the role derivation logic of

Figure 4 in greater detail.

Figure 14 is a logic flow diagram of the binding of an LDAP server by the LDAP manager of Figure 13.

Figure 15 is a logic flow diagram of the querying of an LDAP server by the LDAP manager of Figure 13.

DETAILED DESCRIPTION

In accordance with the present invention, role derivation logic 310 (Figure 3) in a network security appliance 110 (Figures 1 and 2) monitors network traffic for authentication events and leverages observed authentication events to identify users associated with network flows for role-based policy enforcement. A packet inspector 212 (Figure 2) monitors content of various flows processed by network security appliance 110 and detects authentication events. Packet inspector 212 notifies a policy engine 216 and role derivation logic 310 therein of the authentication event and includes user identification parsed from the authentication event within the flow. Role derivation logic 310 (Figure 4) uses a user manager 404 to determine one or more roles of the identified user and perhaps additional user information. User manager 404 uses a role derivation rule engine 410 to apply a number of rules according to which user roles are derived.

By monitoring flows of data processed by network security appliance 110 (Figures

1 and 2), the identity of a remotely located user can be determined without explicit authentication of the user by network security appliance 110. Thus, user authentication by network security appliance 110 is effective yet unobtrusive, not interfering with the user's experience in using various network services.

System Overview To facilitate appreciation and understanding of the present invention, the operational context of policy enforcement according to an illustrative embodiment is described. Figure 1 shows a local area network (LAN) 100 coupled to a wide area network (WAN) 102, which is the Internet in this illustrative embodiment, through a router 106. Router 106 includes a conventional firewall for protecting against malicious activity entering LAN 100 from WAN 102. Data is routed within LAN 100 through router 106 and switches 108A-C between end-point computers 112A-F, which are sometimes referred to as hosts 112A-F. Hosts 112A-F can include firewall software and antivirus software executing therein to protect against malicious activity by worms, viruses, and other malicious programs that might be executing within hosts 112A-F. Thus, LAN 100 is protected from harm coming from WAN 102 by router 106 and from harm coming from hosts 112A-F by software executing therein. However, centralized administration of hosts 112A-F to provide adequate protection against malicious activity can be impractical. For example, consider that host 112A is used by a visitor and is not maintained by the personnel responsible for security within LAN 100. Coupling host 112A to LAN 100 can subject hosts reachable through LAN 100 and WAN 102 to harm caused by malicious programs executing in host 112A. While some LANs provide limited access to guest hosts only after checking for compliance with security policies, conventional security tools executing in hosts can be vulnerable to attacks. This is particularly true of attacks that exploit vulnerabilities before a fix is available, such as zero day worms for example.

To protect against threats coming from host 112A that might not be prevented by software executing therein, host 112A is connected to router 106 through a network security appliance 110, which is capable of detecting and stopping malicious activity within LAN 100. Network security appliance 110 monitors traffic through switches 108 A-B and therefore traffic of hosts 112A-D. In this illustrative embodiment, switch 108C includes network security logic analogous to that described herein with respect to network security

appliance 110 to protect against threats coming from hosts 112E-F.

Network security appliance 110 and network security logic within switch 108C are directly analogous to one another and the following description of network security appliance 110 is equally applicable to network security logic within switch 108C. Network security appliance 110 is shown in greater detail in Figure 2 and includes an input buffer 202, a hold buffer 204, an output buffer 206, and network security logic 208. Input buffer 202 stores data packets received from computer 112A (Figure 1) and destined for switch 106 for subsequent routing to an intended recipient, whether within LAN 100 or through WAN 102. Hold buffer 204 (Figure 2) stores data packets for access by network security logic 208. Once network security logic 208 determines that a given packet ought to be forwarded to switch 106, network security logic 208 moves the packet from hold buffer 204 to output buffer 206 for delivery to switch 106 (Figure 1). In this illustrative embodiment, network security appliance 110 only processes packets from computer 112A. In an alternative embodiment, network security appliance 110 also processes packets destined for computer 112A from switch 106.

Network security logic 208 includes a host policy 210, a packet inspector 212, a malware detector 214, and a policy engine 216, each of which can be all or part of one or more computer processes executing in one or more processors of network security appliance 110 and be wholly or in part implemented in digital logic circuitry. Host policy 210 provides an interface whereby a security administrator can specify policies for packets traveling through network security appliance 110. Policies are each a collection of one or more flow conditions and associated actions. Conditions can include, for example, that the flow is addressed to an IP address in a specific range, that the flow involves transportation of a file indicated as confidential, and that the flow is determined to be part of malicious activity of a worm. Actions can include, for example, allowing the flow to proceed to switch 106, denying the flow (dropping packets of the flow altogether), notifying a security administrator, holding packets of the flow pending further processing, and modifying the priority of the flow. Policy engine 216 implements the policies specified by host policy 210 to process flows received in input buffer 202. Packet inspector 212 performs qualitative analysis of the substantive content of packets and communicates such analysis to policy engine 216, thus enabling policy conditions specific to content of packets and flows. A flow is a series of packets

transported between two hosts according to a single protocol without requiring a new synchronization packet. In this illustrative embodiment, a flow is defined by a 5-tuple that includes a source address, a destination address, a source port, a destination port, and a protocol identifier. The addresses in this illustrative embodiment are IP (Internet Protocol) addresses.

As an example of such qualitative analysis, consider a flow representing an FTP (File Transport Protocol) transport of a file through network security appliance 110. FTP transports typically involve two flows, namely, a control flow and a data flow. The control flow specifies the name and full path of the file or files being transported. Packet inspector 212 decodes packets of the control flow to determine precisely which files are being transported. Packet inspector 212 reports such information, and perhaps additional information regarding the flow, to policy engine 216. Policy engine 216 can compare the transported file(s) to conditions in the relevant policy. For example, policy engine 216 can use a list of confidential directories or owners of files indicated as "confidential" to thereby identify files not allowed to be transported to switch 106.

Malware detector 214 determines whether observed activity through network security appliance 110 is malicious and reports such determinations to policy engine 216. Malware detector 214 is described in more detail in co-pending U.S. Patent Application Ser. No. 11/556,160, filed on November 2, 2006 and entitled "Behavior-Based Detection of Malicious Activity in Computer Networks" by Dr. Rodolfo A. Milito and Dr. Mario Nemirovsky, and that description is incorporated herein by reference.

Policy engine 216 uses information received from packet inspector 212 and malware detector 214 to identify various characteristics of packets and/or flows and enforces policies specified by host policy 210.

Role Derivation Policy engine 216 is shown in greater detail in Figure 3 and includes policy engine logic 302, global context data 304, user context data 306, flow context data 308, and role derivation logic 310. Policy engine logic 302, global context data 304, user context data 306, and flow context data 308 are described more completely in U.S. Patent Application Ser. No. 11/614,969 filed December 21, 2006 and entitled "Efficient Policy Enforcement in Network Nodes" by Rajeev Batni, and that description is incorporated herein by reference.

Role derivation logic 310 is all or part of one or more computer processes executing within network security appliance 110 (Figure 2) and informs policy engine logic 302 (Figure 3) of respective identities of users associated with various flows processed by policy engine logic 302. Role derivation logic 310 is shown in greater detail in Figure 4. In this illustrative embodiment, role derivation logic 310 includes an authentication manager 402, a user manager 404, and an LDAP (Lightweight Directory Access Protocol) manager 412. Authentication manager 402 stores authentication information from received authentication events as authenticated user profiles 406 and associates authenticated users and one or more roles of each such user with one or more flows processed by network security appliance 110. Authentication manager 402 cooperates with user manager 404 to determine one or more roles of each of the authenticated users as illustrated in logic flow diagrams 500 (Figure 5) and 520.

In step 502, authentication manager 402 receives an authentication event from packet inspector 212 and parses one or more attributes of the authenticated user and the IP address of the flow to which the authentication event pertains. Authentication manager 402 stores the attributes of the authenticated user in an authenticated user profile 406, which is shown in greater detail in Figure 6. Authentication manager 402 stores the attributes of the authenticated user in authentication attributes 606 and associates the authenticated user with a user identifier 604 that is unique among all user identifiers processed by authentication manager 402. Authentication attributes 606 typically includes a user identifier by which the authenticated user is authenticated - e.g., the username in a username/password combination.

In step 504 (Figure 5), authentication manager 402 sends authentication attributes 606 to user manager 404 in a request for derivation of the one or more roles of the authenticated user. User manager 404, receives authenticated user information from authentication manager 402, uses a role derivation rule engine 410 to determine one or more roles of the authenticated users in step 522, and returns data representing those roles to authentication manager 402 in step 524. The execution of role derivation rules by user manager 404, including use of LDAP manager 412 to acquire additional information for authenticated users from one or more remotely located LDAP servers, is described more completely below. It should be appreciated that any directory service can be used, such as Active Directory (AD) service, in addition to or instead of LDAP service.

The attributes communicated by authentication manager 402 to user manager 404 are in a standardized form, making the collection of attributes that can be processed by user manager 404 extensible. In particular, new attributes can be recognized by packet inspector 212 and/or LDAP manager 412 and evaluated by user manager 404 without modification of role derivation rule engine 410.

Figure 8 shows an attribute map 802 in the form communicated between authentication manager 402 and user manager 404. Attribute map 802 includes one or more attributes 804, each of which includes an attribute identifier 806 and an attribute value 808. Attribute identifier 806 includes data specifying an attribute class 904 (Figure 9) and an attribute name 906 of an attribute definition 902. In this illustrative embodiment, attribute name 906 is an integer and is mapped to a string name for the convenience of administrators configuring rule maps as described below. In addition, attribute name 906 is unique among all attributes of a given class.

The following table describes classes of attributes implemented in this illustrative embodiment.

The following table provides examples of attributes of the attribute classes implemented in this illustrative embodiment.

What makes the attributes that can be processed role derivation rule engine 410 extensible is that there are a finite number of predefined attribute data types that can be processed by role derivation rule engine 410. In this illustrative embodiment, all attribute values are expressed as NULL-terminated alphanumeric character strings. Some attribute values can have special types of information, and such attribute values are expressed in respective specific formats of NULL-terminated alphanumeric character strings as described in the following table.

Thus, role derivation rule engine 410 is capable of evaluating any attribute so long as the attribute is represented in a data type recognized by role derivation rule engine 410.

As described above, authentication manager 402 receives the results of processing by role derivation rule engine 410 in step 504 (Figure 5). In step 506, authentication manager 402 stores the one or more roles received from user manager 404 as roles 706

(Figure 7) in a flow user/role record 408. Authentication manager 402 also stores user identifier 604 (Figure 6) as user identifier 704 and stores the IP address of the authentication event in IP address 702, to thereby associate roles 706 with user identifier 704 and IP address 702. Thereafter, authentication manager 402 can provide role information for any flow associated with IP address 702 such that policy engine logic 302 can enforce role-based policies.

In step 522, role derivation rule engine 410 processes received attribute information using one or more rule maps such as rule map 1002 (Figure 10). Rule map 1000 specifies one or more ways roles of the authenticated user should be changed and one or more conditions for such changes. Actions 1018 specify the manner in which roles are to be changed, and conditions 1016 specify under what circumstances such changes are to be made. Actions 1018 and conditions 1016 are described in greater detail below.

Name 1004 of rule map 1002 is an identifier of rule map 1002 that is unique among all rule maps processed by role derivation rule engine 410 (Figure 4). Description 1006 (Figure 10) of rule map 1002 is a textual description of the rule implemented by rule map 1002 to aid administrators in proper use and maintenance of rule map 1002.

Logical operator 1008 of rule map 1002 specifies a logical relationship between conditions 1016 and can represent a logical "and" relationship or a logical "or" relationship.

Mode 1010 of rule map 1002 specifies a mode of setting roles and can specify that new roles are to be appended, preserving any previously determined roles, or that new roles are to be set, over-writing any previously determined roles.

Terminating action 1012 of rule map 1002 specifies a manner in which processing of rule map 1002 terminates, either continuing to process subsequent rule maps or stopping so as to skip processing of subsequent rule maps.

Precedence 1014 of rule map 1002 specifies a sequence of rule maps processed by role derivation rule engine 410. Role derivation rule engine 140 processes rule maps in order of descending precedence values. Condition 1016 of rule map 1002 is shown in greater detail in Figure 11.

Condition 1016 includes an attribute 1102 that specifies a particular one of authentication

attributes 606 (Figure 6) received from authentication manager 402 (Figure 4) as the attribute whose value is to be tested. Negation flag 1104 indicates whether the logical result of condition 1016 is to be negated. Test 1106 of condition 1016 specifies a particular comparison operation to be applied to the value of the attribute specified by attribute 1102. Arguments 1108 specifies one or more data values to be compared to the value of the attribute specified by attribute 1102.

The various comparison operations supported in this illustrative embodiment are summarized in the following table.

Action 1018 (Figure 10) of rule map 1002 is shown in greater detail in Figure 12. Mode 1202 specifies whether data is to be appended to an attribute, preserving data already associated with the attribute, or set, superseding any data already associated with the attribute. Attribute 1204 specifies a particular attribute to be modified. Data 1206 specifies data to be associated with attribute 1204 in the manner specified by mode 1202.

Directory Server Access As described above, user manager 404 (Figure 4) uses LDAP manager 412 to get

additional information for authenticated users. LDAP manager 412 is shown in greater detail in Figure 13.

LDAP manager 412 maintains lists of LDAP servers and various levels of availability and includes binding logic 1302, query logic 1304, to-be-bound table 1306, bound table 1308, and pending table 1310.

To-be-bound table 1306 identifies a number of LDAP servers that are known to LDAP manager 412 and that are not bound. Bound table 1308 identifies a number of LDAP servers that are bound to LDAP manager 412. Pending table 1310 identifies a number of LDAP servers that are bound to LDAP manager 412 and for which LDAP queries are pending.

Binding logic 1302 and query logic 1304 are all or part of one or more computer processes executing in network security appliance 110. Binding logic 1302 periodically attempts to bind LDAP servers known to LDAP manager 412. An LDAP server is said to be bound to a client when the client is authenticated by the LDAP server and the LDAP server has agreed to provide LDAP services to the client. Query logic 1304 submits

LDAP queries to various bound LDAP servers to obtain additional information regarding authenticated users.

Logic flow diagram 1400 (Figure 14) illustrates the operation of binding logic 1302. Loop step 1402 and next step 1410 define a loop in which binding logic 1302 processes each of the LDAP servers represented in to-be-contacted table 1306 according to steps 1404-1408. During each iteration of the loop of steps 1402-1410, the particular LDAP server processed by binding logic 1302 is sometimes referred to as the subject LDAP server.

In step 1404, binding logic 1302 sends a binding request to the subject LDAP server. In test step 1406, binding logic 1302 determines whether the subject LDAP server agrees to be bound. The request times out and fails if the subject LDAP server does not agree to be bound within a predetermined period of time, e.g., one second. If the subject LDAP server agrees to be bound within the predetermined period of time, processing transfers to step 1408 in which binding logic 1302 records the subject LDAP server as bound by moving data representing the subject LDAP server from to-be-bound table 1306 to bound table 1308.

After step 1408, processing transfers through next step 1410 to loop step 1402 and

binding logic processes the next LDAP server represented in to-be-bound table 1302. If binding logic 1302 determines in test step 1406 that the subject LDAP server does not agree to be bound within the predetermined period of time, binding logic 1302 skips step 1408 and processing transfers through next step 1410 to loop step 1402 and binding logic processes the next LDAP server represented in to-be-bound table 1302.

Once all LDAP servers represented in to-be-bound table 1306 have been processed by binding logic 1302, processing by binding logic 1302 suspends for a predetermined period of time (e.g., five seconds), after which binding logic 1302 repeats processing according to logic flow diagram 1400. Logic flow diagram 1500 (Figure 15) illustrates the operation of query logic 1304.

In step 1502, query logic 1304 determines the correct server to query for a particular authenticated user. In this illustrative embodiment, the correct server is determined according to a domain associated with the authentication event. The domain can be a domain of the user identifier used for authentication, e.g., if the user identifier is an e-mail address, the domain is the domain name portion of the e-mail address. The domain can also be a domain associated with the authenticating host, e.g., a domain portion of a URL used to identify the authenticating host. In an alternative embodiment, any attribute or combination of attributes of the authentication event can be used to determine a LDAP server to serve the LDAP request. In step 1504, query logic 1304 queries the correct LDAP server for information regarding the authenticated user. While the query is pending, query logic 1304 records the status of the correct LDAP server as "pending" in step 1506, e.g., by moving a record representing the correct LDAP server from bound table 1308 (Figure 13) to pending table 1310. In test step 1508 (Figure 15), query logic 1304 determines whether the queried

LDAP server responds to the request of step 1504 within a predetermined period of time, e.g., one second. If so, processing transfers to step 1510 in which query logic 1304 records the status of the queried LDAP server as bound. For example, query logic 1304 moves a record representing the queried LDAP server from pending table 1310 (Figure 13) to bound table 1308. In step 1512 (Figure 15), LDAP manager 412 (Figures 13 and 4) returns the LDAP data received from the LDAP server to user manager 404. User manager 404 can thereafter use any information available from an LDAP server as a basis

for assigning one or more roles to an authenticated user.

If query logic 1304 (Figure 13) does not receive a timely response from the queried LDAP server in test step 1508 (Figure 15), processing transfers to step 1514. In step 1514, query logic 1304 records the status of the queried LDAP server as to-be-bound, since the queried LDAP server seems to be unavailable. In this illustrative embodiment, query logic 1304 moves a record representing the queried LDAP server from pending table 1310 (Figure 13) to to-be-bound table 1306. In step 1516 (Figure 15), LDAP manager 412 (Figures 13 and 4) returns an error state to user manager 404.

After either step 1512 or step 1516, processing according to logic flow diagram 1500 completes.

Rule Map Examples

The following is an example configuration to illustrate the use of rule maps to determine one or more roles of authenticated users.

Example 1 aaa rule-map specialRole operation or match ad.dn contains "Users/Engineering" match ad.dn contains "Users/Sales/Pre-Sales" set system. roleName "ENG" action stop end aaa rule-map dnRole match ad.dn exists set system. roleName value-of ad.dn end aaa apply rule-map specialRole precendence 9 aaa apply rule-map dnRole precedence 1θ

In Example 1, there are two rule maps, namely, "specialRole" and "dnRole", with respective precedence values 9 and 10. In this illustrative embodiment, rule maps are executed in order of increasing precedence. Accordingly, rule map dnRole is performed only after performance of rule map "specialRole".

Rule map specialRole includes two conditions. "Operation or" indicates that satisfaction of either of the conditions makes rule map specialRole applicable. The first condition is satisfied if the attribute ad.dn (Active Directory distinctive name, a known LDAP attribute) includes the text "Users/Engineering". The second condition is satisfied if the attribute ad.dn includes the text "Users/Sales/Pre-Sales".

Upon satisfaction of either condition in rule map specialRole, role derivation rule engine 410 (Figure 4) sets the system.roleName attribute to "ENG" to thereby set the role of the authenticated user to "ENG". Thereafter, role derivation rule engine 410 performs the terminating action of "stop" and therefore does not process rule map dnRole. In rule map dnRole, role derivation logic 410 sets the role of the authenticated user to the value of attribute ad.dn if that attribute exists.

Example 2 aaa rule-map specialGroups operation or match ad .memberOf contains "specialGroupl" match ad .memberOf contains "specialGroup2" set system. roleName value-of "specialPerson" end aaa apply rule-map specialGroups precedence lθ

In Example 2, rule map specialGroups uses the LDAP group membership attribute, ad.memberθf, to assign a role to the authenticated user according to membership in such groups.

Example 3 aaa rule-map nightShift operation and match ad.memberOf contains "specialGroupl" match system.timeOfDay between 20:006:00 set system.roleName value-of "nightShiftSpecial" end aaa rule-map dayShift operation and match ad.memberOf contains "specialGroupl" match system.timeOfDay between 6:0020:00 set system.roleName value-of "dayShiftSpecial" end aaa apply rule-map nightShift precedence lθ aaa apply rule-map dayShift precedence 10 In Example 3, rule map nightShift assigns a role of "nightShiftSpecial" to the authenticated user if the user has an LDAP group membership attribute, ad.memberθf, in the group "specialGroupl" and the current time of day is later than 8:00pm and earlier than 6:00am. Similarly, rule map dayShift assigns a role of "dayShiftSpecial" to the authenticated user if the user has an LDAP group membership attribute, ad.memberθf, in the group "specialGroupl" and the current time of day is between 6:00am and 8:00pm.

Example 4 aaa rule-map specialGroups operation or match ad .memberOf contains "Engineering" match ad .memberOf contains "Sales" match ad .memberOf contains "Exec" match ad .memberOf contains "FrontOffice" set system. roleName value-of system. matchedValue aaa apply rule-map specialGroups precedence 1

In Example 4, rule map specialGroups uses a system attribute, system.matchedValue, to simplify a complex role derivation rule. Attribute system.matchedValue stores the most recently matched value. Rule map specialGroups tests attribute ad.memberθf for matching substrings "Engineering", "Sales", "Exec", and "FrontOffice". The most recently matched of those substrings is stored in attribute system.matchedValue, and rule map specialGroups stores that matched value as the role of the authenticated user in attribute system.roleName.

Example 5 aaa rule-map frontOffice operation and match system. username equals "guest" match system. portNumber equals 0/12 set system.roleName value-of "frontOfficeGuest" end aaa rule-map conferenceRoom operation and match system. username equals "guest" match system. portNumber equals 0/14 set system.roleName value-of "conferenceRoomGuest" end aaa apply rule-map frontOffice precedence 10 aaa apply rule-map conferenceRoom precedence 10

In Example 5, rule maps frontOffice and conferenceRoom use system attributes representing a physical location of the authenticated user to assign roles. The system attribute system.portNumber indicates a physical connecting port of network security appliance 110 (Figure 1) through which the authenticated user is connected to network security appliance 110. In this illustrative example, it is known that a network cable connected to port 12 on slot 0 of network security appliance 110 is routed to a front office. Accordingly, a user authenticated as "guest" on that port is assigned the role of frontOfficeGuest. In addition, it is known that a network cable connected to port 14 on slot 0 of network security appliance 110 is routed to a conference room. Accordingly, a user authenticated as "guest" on that port is assigned the role of conferenceRoomGuest.

Attributes

In this illustrative embodiment, the system attributes described in the table below are supported. It should be noted that, as with all attributes except roleName, the system attributes are read-only. All attributes in the system class are accessed from the CLI (Command-Line user Interface) by prepending the "system" keyword to the attribute name (i.e. system.srcIP).

DHCP attributes are obtained only if DHCP is the protocol used to obtain the interface mapping. These DHCP attributes may or may not be present based on the configuration of the DHCP client and server as well. The attributes are accessed on the CLI by prepending the keyword "dhcp" to the attribute names shown below.

Kerberos attributes are present only if kerberos was the authentication protocol by which the authenticated user is authenticated. The attributes are accessed on the CLI by prepending the keyword "kerberos" to the attribute name (i.e. kerberos.realmName).

In this illustrative embodiment, all LDAP attributes are specific to the Microsoft AD schema. These attributes are represented on the CLI by the class "ad". The table below shows attributes supported in this illustrative embodiment. It should be noted that, when the value of an attribute is of type "distinguished name" (DN in the chart below), the value is converted by the attribute system into AD canonical format. An example of this is: "cn=John Smith,cn=Users,dc=Auth,dc=dev" would be translated to "auth.dev/Users/John Smith"

RADIUS attributes are learned from RADIUS protocol exchanges. RADIUS standard attributes are identified on the CLI by radius.AttrName, where "AttrName" is the name of the attribute. Vendor-specific RADIUS extensions are identified by "radius.vendor.attrName", where "vendor" identifies a vendor to which the attribute is specific. For example, the RADIUS attribute NAS-IP would be specified as

"radius.nasIP", whereas the VLAN name attribute for the vendor Extreme Networks would be specified as "radius.extremeNetworks.vlanName".

By default, user manager 404 (Figure 4) and LDAP manager 412 support the RADIUS attributes shown in the table below. These attributes are specified in RFC 2865. In addition, vendor-specific attributes can be added by download of vendor dictionary files.

Directory Server Types

As LDAP servers are added to LDAP manager 412, the servers are assigned a type. This assigned type allows LDAP manager 412 to determine query parameters, including search filters, attributes and attribute types, and schema structure. By default, LDAP manager 412 can query AD-based LDAP servers. An administrator can configure LDAP manager 412 with additional LDAP server types by downloading server configuration files. The supported parameters in this illustrative embodiment are shown in the table below:

In addition to the parameters above, an administrator can specify attributes that should be fetched from the LDAP server. The format of an attribute specification is shown below:

(hostAttribute|userAttribute) <ldap-name> <display-name> <type>

In the configuration line above the ldap-name is the attribute name that is added to the LDAP query's attrlist attribute list. The display name is the name added to the CLI. Attributes are added to the role derivation CLI as <server-type>.<display-name>.

Addition of two servers of the same type is not an error, but addition of two attributes with the same server type and display name is an error.

The supported types are:

To configure LDAP manager 412 to support a new LDAP server type, an administrator can use the copy command. This is shown below: copy tftp: //<url>/filename ldap-server-description

To clear out existing LDAP server configuration of LDAP manager 412, an administrator can issue the clear command, shown below: clear aaa ldap-server-descriptions A file with contents shown below describes an LDAP server that conforms to the posixAccount standard. This standard is described in RFC 2307. The LDAP server type string is "po six", so an administrator could add a server of this type by specifying

"server-type posix" .

serverTypeName : posix hostFilter String : ( objectClass=ipHost ) userFilter String : ( objectClass=posixAccount ) userNameAttribute : uid

The filter strings above will be added together with the search strings constructed from the user and host name attributes. In this case, the complete search string is:

(I (& (objectClass=posixAccount) (uid=%username) ) (& (objectClass=ipHost ) (cn=%hostname) ) )

The above description is illustrative only and is not limiting. Instead, the present invention is defined solely by the claims which follow and their full range of equivalents.