APPLICATION NETWORK APPLIANCE WITH BUILT-IN VIRTUAL DIRECTORY INTERFACE

Abstract

An application network appliance with a built-in virtual directory interface is described herein. According to one embodiment, a network element includes a virtual directory interface (VDI) coupled to multiple directory servers, and an authentication and authorization unit coupled to the VDI. In response to a packet of a network transaction received from a client over a first network for accessing a server of a datacenter over a second network, the authentication and authorization unit obtains user attributes from the directory servers via the VDI and performs authentication and authorization using the user attributes to determine whether a user of the client is eligible to access the server of the datacenter, where the network element operates as a security gateway to the datacenter. Other methods and apparatuses are also described.

Description

RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Patent Application No. 60/966,649, filed Aug. 28, 2007, which is incorporated by reference herein in its entirety.

FIELD OF THE INVENTION

The present invention relates generally to application network appliances. More particularly, this invention relates to application network appliances with built-in virtual directory interface.

BACKGROUND

The ability to connect information technology infrastructure reliably, cost-effectively and securely is of high importance for today's global enterprises. To communicate with customers, clients, business partners, employees, etc., the Internet has proven to be more appropriate compared to private communication networks. However, communication via the Internet, which typically uses TCP/IP (Transmission Control Protocol/Internet Protocol), also increases the requirements for data security. Network firewalls are one of the many examples of solutions for network security.

Enterprise Web Application Services build an important foundation for such client, customer, and employee communication. A very common configuration for hosting such enterprise web Application Services is shown in FIG. 1. As shown in FIG. 1, an enterprise can offer web Application Services to various clients and there are several possibilities for clients to connect to the servers depending on the location of the client relative to the servers' location. The servers which provide the Application Services are typically located in the enterprise's data center 1016 and are accessible, directly or indirectly, via World-Wide-Web (WWW) servers 1012. Sometimes enterprises provide access to the Application Services by making the application servers directly accessible by putting those application servers into a Demilitarized Zone (DMZ) 1011.

A client 1003 may connect via a Local Area Network (LAN) through the enterprise's intranet 1013. Another client 1004 may connect through a Wireless LAN (WLAN) to the intranet 1013. Yet another client 1005 may be located inside the enterprise's campus network 1015, which connects to the enterprise's intranet 1013. An enterprise may have zero or more campuses 1014 and 1015. Yet another client 1001 may connect through the Internet 1000, or a client 1002 may have a mobile connection to the Internet 1000. In any case to prevent illegitimate access to the enterprise's web Application Services, the “inside” of the enterprise's network, the intranet 1013, is protected by having a network perimeter 1010, which may comprise firewalls, associated network interconnect, and additional resources “within” the perimeter network configured so as to be broadly accessible to users on the “outside” of the enterprise.

Behind the perimeter 1010, access is granted to legitimate client requests only, while illegitimate access is rejected. The fundamentals in determining whether an access request is legitimate or not are based on the network reference model from the International Organization for Standardization (ISO). This ISO network reference model classifies Network Services into seven layers.

Traditional security products generally assume the existence of a trusted intranet—locations where enterprises control their own LANs, switches and routers—which can be organized into or placed within some type of security perimeter, to protect its resources from the un-trusted Internet. However, in today's business environment, enterprises no longer enjoy the same level of trust and control of their intranets, as enterprises increasingly rely on contractors, partners, consultants, vendors, and visitors on-site for daily operation. As a result, enterprises are exposing internal resources to this wide set of clients whose roles are also frequently changing. Thus, the network trust boundary, delineating inside and outside clients, is disappearing—a phenomenon referred to as “de-perimeterization”. In such an environment, protection of an enterprise's resources—such as its intellectual property, as well as mission-critical and operational systems—becomes of critical importance. Also, most security exploits easily traverse perimeter security, as enterprises typically let through email, web and any encrypted network traffic, such as Secure Sockets Layer (SSL), Simple Mail Transfer Protocol (SMTP) with Transport Layer Security (TLS), and authenticated Virtual Private Network (VPN) traffic, for example via IP Security (IPSec). Traditional perimeter security approaches, for example firewalls, intrusion detection systems and intrusion prevention systems have little or no benefit at the perimeter in providing access control functions to the resources. They have become more attack mitigation mechanisms than access control mechanisms. Enterprises are coming to terms with the fact that a hardened perimeter strategy is un-sustainable.

Traditional firewall or router access control lists cannot protect application resources from unauthorized access because network parameters such as Internet Protocol (IP) addresses and IP port numbers no longer deterministically identify resources, nor identify users, clients, or applications accessing these resources. Network firewall technology was invented when enterprises had a limited set of applications such as Telnet, File Transfer Protocol (FTP), and Email, and its primary functions were to limit access to specific applications from the outside and to limit access by systems within the enterprise to specific applications outside the firewall. Network layer parameters such as source, destination IP address and TCP or UDP port numbers were sufficient to identify the client and the operations the clients intended to perform on a particular resource. However, with the proliferation of mobile devices and tunneled applications, the network layer parameters are no longer useful to identify the client, the resource accessed, and the operation. Firewalls have evolved over the time, embracing functions such as deep packet inspection and intrusion detection/prevention, to handle application-level attacks, but the core access control function remains the same.

In effect, de-perimeterization demands that access control functions are positioned close to application resources and that a micro-perimeter is established in the heart of the data center by placing an identity-based policy enforcement point in front of any application resource. Enterprise business drivers for such an enforcement point are the need for rich and uniform protection of resources, business agility via attribute-based, policy-driven provisioning, and regulatory compliance. Traditional server-centric authorization solutions providing role-based authorization often require custom code development, extensive cross-vendor testing whenever there is a version change (of the underlying operating system, agent or application), and are costly and difficult to maintain because of their proprietary nature. Also, traditional server-based network appliances—primarily focused on low-bandwidth ISO Layer-4 to ISO Layer-7 perimeter services—are unsuitable for data center deployment, both in functional richness and in ISO Layer-7 performance.

Authorization or access control typically determines the allowed set of actions by a legitimate client, possibly intercepting every access of the client to a resource in the system. Authentication is used in conjunction with authorization—authentication determines and verifies the basic identity of, for example, a user or a client process. Then, based on determining the user's or client's identity, an authorization decision can be appropriately made. Of course, if a client's or user's identity can not be verified, the authorization decision is quite simple—deny access or authority to perform any action.

Typically, authentication is performed once every session, unlike authorization, which is performed for every client action. Granular authorization is achieved by leveraging details of the identity such as attribute values, group membership, role assignment etc. Typically, Information Technology (IT) infrastructure implements access control in many places and at different levels.

Traditionally, authentication and authorization is done inside the application, however because of the long cycle of development and deployment in the process, not all applications have the same level of support. Many applications have a basic form of authentication using user name and a secret password. Certain vendor-specific applications support role-based authorization which is often vendor proprietary and does not interoperate well with implementations in another applications—it creates multiple silos of applications within an enterprise network infrastructure. Role provisioning is often challenging; without careful planning, enterprises often end up with the number of roles greater than the number of users, which eviscerates any potential management efficiency gains. As a result, a large number of applications are left behind with no protection and with no support for authentication or authorization. With de-perimeterization, enterprises are seeing a need to protect these applications uniformly with network-centric solutions that do not mandate modifying the application.

SUMMARY OF THE DESCRIPTION

An application network appliance with a built-in virtual directory interface is described herein. According to one embodiment, a network element includes a virtual directory interface (VDI) coupled to a plurality of directory servers, and an authentication and authorization unit coupled to the VDI. In response to a packet of a network transaction received from a client over a first network for accessing a server of a datacenter over a second network, the authentication and authorization unit is configured to obtain one or more user attributes from at least one of the directory server via the VDI. The authentication and authorization unit is configured to authenticate and/or authorize the packet based on at least the user attributes to determine whether a user of the client is eligible to access the server of the datacenter. The network element operates as a security gateway to the datacenter and each client of the first network has to go through the security gateway in order to access a server of the second network.

Other features of the present invention will be apparent from the accompanying drawings and from the detailed description which follows.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar elements.

FIG. 1 illustrates a typical corporate computer network connected to the Internet;

FIG. 2 illustrates the application of an application network appliance (ANA) as the APS according to one embodiment of the invention;

FIG. 3 is a network connected block diagram of an ANA according to one embodiment of the invention;

FIG. 4 is a block diagram of a Virtual Directory Infrastructure system for Triangulated Authorization according to another embodiment of the invention;

FIG. 5 is a block diagram of the APS combined with embedded PDP and PEP;

FIG. 6 is a block diagram of a system for Triangulated Authorization of a first request according to one embodiment of the invention;

FIG. 7 is a flow diagram of a method for Triangulated Authorization of a first request according to one embodiment of the invention;

FIG. 8 is a block diagram of a system for Triangulated Authorization of a subsequent request according to one embodiment of the invention;

FIG. 9 is a flow diagram of a method for Triangulated Authorization of a subsequent request according to one embodiment of the invention;

FIG. 10 is a flow diagram which illustrates the HTTP protocol;

FIG. 11 is a block diagram which illustrates the CIFS protocol packet;

FIG. 12 is a block diagram which illustrates the application of the SQLnet protocol;

FIG. 13 is a block diagram of a system for Triangulated Authorization of a first request using a Virtual Directory Infrastructure according to another embodiment of the invention;

FIG. 14 is a flow diagram of a method for Triangulated Authorization of a first request using a Virtual Directory Infrastructure according to another embodiment of the invention;

FIG. 15 is a block diagram of a system for Triangulated Authorization of a subsequent request using a Virtual Directory Infrastructure according to another embodiment of the invention;

FIG. 16 is a flow diagram of a method for Triangulated Authorization of a subsequent request using a Virtual Directory Infrastructure according to another embodiment of the invention;

DETAILED DESCRIPTION

In the following description, numerous details are set forth to provide a more thorough explanation of embodiments of the present invention. It will be apparent, however, to one skilled in the art, that embodiments of the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring embodiments of the present invention.

Reference in the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. The appearances of the phrase “in one embodiment” in various places in the specification do not necessarily all refer to the same embodiment.

One aspect of the invention is to perform Triangulated Authorization as a means for network-centric, application-agnostic authorization and access control to certain Application Services. The concept of Triangulated Authorization operates on policies, which can take into account multiple aspects of clients, of the networking environment and of the applications and services requested by clients. Performing Triangulated Authorization requires analysis of the ISO Layer-7 application data, which can be transmitted via various protocols. Using a LDTF in a multi-processing approach provides the compute power to perform such analysis efficiently. The concept of Triangulated Authorization can be enhanced by utilizing a Virtual Directory Infrastructure (VDI) to multiple directory stores. Further, because LDTF can support virtualization, for example InfiniBand as the LDTF supports so-called virtual lanes, the concept of Triangulated Authorization can also be implemented in a virtualized manner. One physical ANA can then be used to serve multiple independent network domains thus increasing flexibility and reducing the cost and the complexity of access control.

One aspect of the invention is a Network Application Protection system and method, for access control in a network environment by using Triangulated Authorization based on user attributes, environment attributes, and resource attributes to make rapid, reliable, and secure authorization decisions, based on a number of factors, including user attributes, environment attributes, and subject attributes. User attributes may include, among others: company department, role, project association, seniority, citizenship. Environment attributes may include, among others: network access method, location, time and date. Subject attributes may include, among others: protocol attributes, content attributes, and resource attributes.

Overview

The approach described herein applies combinations of parallel, multi-processor computing technology with lossless, low-latency, high-bandwidth network fabric technology (also known as Lossless Data Transport Fabric, or LDTF) to form novel methods and systems for high performance, high-reliability, high availability, and secure network applications. The various embodiments of the inventions described herein enable the implementation of highly reliable, highly scalable solutions for enterprise networking such as, for example, the APS 2000 from FIG. 2.

Multiple network Services are efficiently provided by terminating transport protocols centrally. As can be seen, any transport protocol can be terminated centrally, each PDU's payload can be collected and converted into a data stream and, vice versa, a data stream can be converted into PDUs for any transport protocol and be transported via the given transport protocol. A simple concatenation of the PDU payload into a byte-stream is not sufficient. Key to the conversion is that state information must be maintained about the meta-data of each connection. Such meta-data includes the session information, for example via a unique connection identification number, the transaction information, as well as the information regarding segments and packets. Finite state machines can be used to track the meta-data.

Transport protocols are protocols which are used to transport information via networks. These include, obviously, the ISO Layer-3 protocols such as IPv4, IPv6, IPSec, the ISO Layer-4 protocols such as TCP, UDP, SCTP, the various ISO Layer-5 protocols such as FTP, HTTP, IMAP, SMTP, GTP, L2TP, PPTP, SOAP, SDP, RTSP, RTP, RTCP, RPC, SSH, TLS, DTLS, SSL, IPSec, and VPN protocols. However, other protocols and approaches are contemplated within the scope of the inventions, which serve as transport mechanisms for transmitting information and application data and can also be terminated in a centralized fashion by a protocol proxy and the corresponding PDUs can be transformed into a data stream for application layer processing. Examples of such are, CSIv2, CORBA, IIOP, DCOM and other Object Request Brokers (ORB), MPEG-TS or RTP as a transport for multi-media information, RTSP or SIP as another transport for multi-media information, peer-to-peer transport mechanisms, transport mechanisms based on J2EE such as Java RMI, streaming media protocols such as VoIP, IPTV, etc.

For the sake of simplicity we will use the term Centralized Transport Protocol Termination throughout the rest of the description, however, this is for exemplary purposes only and is not intended to be limiting. Centralized Transport Protocol Termination can be performed by dedicated processing units, and different ISO Layer-7 services can be performed in other dedicated processing units. The use of a lossless low-latency high-bandwidth fabric for inter-process communication between such dedicated processing units makes it possible to simultaneously support Centralized Transport Protocol Termination for multiple services. For example, TCP can be terminated once, transformed into a data stream and this data stream is transported from one dedicated processing unit to another using the lossless low-latency high-bandwidth fabric. The low-latency nature of the fabric helps to reduce the overall latency in client-to-server transactions.

In one embodiment, the Application Protection System (APS) 2000 is a network appliance that can act as a proxy between the client 2001 and the application server 2005, and can determine whether a client 2001 shall be granted access to certain applications 2005. In one example, the client 2001 is one or more of the clients 1001, 1002, 1003, 1004, or 1005 of FIG. 1. In another example, the client 2001 can be a virtual machine or a cluster of computers, or a server (for server-to-server connections, for example). The application server 2005 can be, for example, without limitation, one or more file servers, one or more web servers, one or more database servers, one or more compute servers, one or more storage servers or one or more game servers. The decision whether access is granted or rejected involves an Identity Management Server 2003 to identify the user, client, or application, for example using Lightweight Directory Access Protocol (LDAP) or Active Directory (AD), and is the result of querying a Policy Server 2002 to analyze the access policy for the requested application 2005.

The APS 2000 may use a Triangulated Authorization method which, for example, is based on multiple aspects of a client (such as the client 2001), the requested application (such as application 2005) and certain network characteristics: Who—a client (a user or a machine) and its associated attributes such as department, role, project association, seniority, citizenship, etc; Where—network and environment attributes such as access methods (wire-line/wireless/VPN), location (e.g., USA, Switzerland, China) and time; What—on-the-wire session attributes, including protocol and content/resource attributes. The outcome of this Triangulated Authorization method can be used to determine whether access to an application is granted or rejected. Optionally, a Single-Sign-On (SSO) server such as server 2004 may be involved that allows the client 2001 to obtain authorization for accessing multiple applications at once.

One embodiment of the invention acts as a proxy between one or more clients and one or more application servers to control the access of the one or more clients to the one or more applications. This is described, for example, in FIG. 2, where the APS 2000 controls access of client 2001 to application server 2005. Thereby the approach can act as a high-speed, full proxy which terminates both client-side and server-side transport protocol connections, and which behaves as a virtual server to the one or more clients, and as a virtual client to the one or more servers. The proxy function is required because of the need to reassemble PDUs into data streams and (where needed) to decrypt the payload data for inspection such as access control. The proxy function involves ISO Layer-2 to ISO Layer-5 processing such as Centralized Transport Protocol Termination.

FIG. 3 is a block diagram illustrating an example of application service appliance system according to one embodiment of the invention. Referring to FIG. 3, ANA 2100 acts as a proxy between a client 2104 and an application server 2105. The client 2104 is connected to the ANA 2100 via a network 2107. Network 2107 can, for example, be a LAN, a WAN, a WLAN, an intranet, or the Internet. The application server 2105 is connected to the ANA 2100 via network 2106. Network 2106 can, for example, be a LAN, a WAN, a WLAN, an intranet, or the Internet. Networks 2106-2107 may be the same network or different networks. While it is apparent that multiple clients and multiple application servers may be connected to the ANA 2100, for the sake of simplicity a single client, single application server case is used as a placeholder throughout. Incoming connections, for example, a request from the client 2104 is terminated in the NSM 2103 and is transformed into a data stream. This is done by PDU processing and reassembling the payload of the PDU into a data stream of ISO Layer-7 application data. This data stream is transported via LDTF 2102 to the ASM 2101 for further ISO Layer-7 processing. LDTF 2102 may be an RDMA or IB compatible fabric. The result of ISO Layer-7 processing done by ASM 2101 is then transported back—still as a data stream—via the LDTF 2102 to the NSM 2103. The NSM 2103 then transforms the data stream into PDUs and sends the PDUs to the application server 2105 via the appropriate transport protocol. Connections which originate from the application server 2105 can be handled similarly. Using this novel approach, both processing domains can be scaled independent of each other and a well-balanced system can be achieved at reasonable costs.

The novel approach described herein, which in one embodiment of the invention is the APS 2000 of FIG. 2, provides attribute-based authorization based on Triangulated Identity (for example, based on user, network/environment, protocol and content/resource attributes) to control access to application resources. Both policy decision point (PDP) and policy enforcement point (PEP) are centralized in the network to provide a policy-driven, standards-based and granular authorization enforcement that is non-invasive to applications. It complements network access control in that network access control protects the network via client-side (in-building) deployment whereas the APS 2000 can be used to protect applications for both client-to-server and server-to-server sessions via data center-side deployment. Network access control ensures only that the proper client with appropriate host integrity gets access to the network, where as the APS 2000 of this approach ensures that the client is restricted to legitimate use once he/she is on the network. Thus a client (a user or machine) having access to a given LAN no longer gets automatic access to LAN applications unless explicitly authorized. The novel approach described herein leverages existing enterprise identity management and policy definition infrastructure through standards-based protocols (e.g. via LDAP/AD, XACML, SAML/Kerberos). In order to apply the authorization policy to any connection/session, it is essential to identify the client originating that connection.

As described in detail in this disclosure, there are many embodiments of the invention that can be used to identify a client and to grant or reject authorization. In one embodiment of the invention, as an ANA it can be used to act as an authentication proxy for web (HTTP, for example) and file (CIFS, for example) protocols. For example, in case of a not-yet-authorized, or a known illegitimate HTTP request, the APS 2000 could send an HTTP 401 status response to a client requesting the client to provide its credentials. In another embodiment of the invention, the APS 2000 together with Windows Single-Sign-On can provide a seamless end user login experience in active directory (AD) environments. In yet another embodiment of the invention, the APS 2000 can interact with a network gateway and provide the username credentials for seamless user login.

Various other embodiments of the invention can be used as an LDAP Proxy, for snooping of AD/RADIUS transactions, etc. In all these cases, this approach may maintain an IP address to user-id mapping, though such mapping cannot be solely relied on, because of the possibility of source IP address spoofing. When the Transparent Secure Transport functionality of this approach is enabled, IP spoofing can be made impossible—a major security benefit that no other approach known in the art can support—because integrity of the packet is checked making sure that the appropriate client is guaranteed to have generated the given IP packet.

In one embodiment of the invention, for example as the APS 2000 of FIG. 2, the approach comprises techniques to utilize Virtual Directory Infrastructure. The Virtual Directory Infrastructure concepts of this approach are illustrated in FIG. 4. The Virtual Directory Infrastructure 4900 hides the complexity of the different protocols and the different formats by providing a common interface, for example the LDAP interface 4901, on one end and translating to the native protocols and formats of various identity stores, for example of identity store 4905 and identity store 4906, on the other end. The translation is done via special connectors, for example a Directory Connector 4902, or a Database Connector 4903. Providing this abstraction also helps to integrate emerging formats of identity stores into an enterprise network solution. When a new kind of identity store, for example, the Flat file Identity Store 4907 with a new format needs to be integrated, the Virtual Directory Infrastructure 4900 can be extended by adding a new connector (in this case the Flat file Connector 4904) which translates to the protocol of the new identity store.

Virtual Directory Infrastructure can provide real-time access to the existing identity stores without moving the data out of the original repository. Real-time access permits the data in the underlying stores to be quickly accessed, without requiring batch conversions of the repository data in advance. This has the advantage of maintaining the consistent identity information i.e., the modifications done in the identity store will take effect immediately. However, if the information changes rarely, then the Virtual Directory Infrastructure could be configured to cache the identity information so that it does not need to read from the identity store each time a request is made, and hence it can avoid the costly operation of translating between LDAP requests and the native protocols used by the identity repositories. The Virtual Directory Infrastructure can act as a single access point for retrieving or updating data in multiple data repositories. For example, the Virtual Directory Infrastructure can logically represent information from a number of disparate directories, databases, and other data repositories in a virtual directory tree. Various users and applications can get different views of the information, based on their access rights, which helps to control who can access/modify which identity information. The Virtual Directory Infrastructure can also provide multitude of other features as described below:

Dynamic Join: One of the main tasks of Virtual Directory Infrastructure is to act as a single access point where information from a large number of identity repositories need to be retrieved. Many times, there is no one-to-one correspondence between the information needed and the amount of information stored in the back-end repositories. A common situation is that the information is scattered over several data repositories. It is desirable therefore to dynamically join data sets from several repositories before the result is returned. The Virtual Directory Infrastructure can provide such a Dynamic Join function.

Multi-Search: In the case of Multi-Search, Virtual Directory Infrastructure submits the search request to all (or to a defined subset) of the available repositories. The Virtual Directory Infrastructure can have the capability to either return the first match found, or all the matching entries from all defined repositories.

Schema adaptations: Virtual Directory Infrastructure can overcome the schema differences between the incoming requests and the data sources by mapping the attribute names in the back-end data sources to the attribute names used in the incoming LDAP requests.

Attribute value modification: In many cases it may be necessary to change the actual attribute value being returned in the response. For example, changing the sequence of the surname and given name in the common name. The Virtual Directory Infrastructure can provide such attribute value modification.

Triangulated Authorization

In one embodiment of the invention, the APS 2000 in FIG. 2 is used to perform attribute-based Triangulated Authorization services. In another embodiment of the invention, the ISO Layer-7 authorization server 4740 and/or 4710 of FIG. 5 is used for performing attribute-based Triangulated Authorization services for a subject 4741 which requests access to a resource 4714 hosted on an application server 4710. Attribute-based Triangulated Authorization complements existing approaches for access control known in the art via a network-centric, application-agnostic applications access control based on a Triangulated Identity. The Triangulated Identity can comprise protocol and content attributes, such as protocol and content attributes 4742 from FIG. 5, and thus extend the common identification concepts known in the art which almost solely rely on ISO Layer-4 attributes. The Triangulated Identity comprises three areas of identification:

• • User Attributes relate to attributes for identifying the user and client system itself. Those attributes can be, for example, the user name, the account name, an account number, a user identification token, a client machine identification, a unique Media Access Control (MAC) layer address, a client machine computer name, a unique client network interface serial number, personal identification tokens, fingerprint data, as well as attributes associated with the client, such as the work department, the client's role in the organization (for example, consultant, officer, engineer, maintenance staff, etc.), the association with certain projects (for example, the SOX compliance project, or the West Coast Open Source Design Project), the users' seniority, the user's current level of training, the user's citizenship, the user's security clearance, etc.
  • Environment Attributes relate to attributes for identifying the location of the client in the enterprise's network, such as source IP addresses or ports, destination IP addresses or ports, protocol numbers, other ISO Layer-2 to ISO Layer-5 attributes, network environment attributes, network access method used such as LAN access, WLAN access, Wi-Fi access, mobile access, mobile phone access (for example, via WAP, GPRS, UMTS), dial-up access, VPN access, as well as the physical location attributes of the client such as the country (for example, USA, China, India, Denmark) or the city (for example, Paris, London, Sunnyvale), the client is in, or other aspects of the location such as the vicinity (for example, inside a museum, inside a particular coffee-shop), as well as date and time, as well as the current threat level, emergency/weather alarm, or network security classification.
  • Protocol and Content Attributes relate to on-the-wire session attributes, such as protocol attributes (for example, for HTTP or HTTPS—methods and parameters, FTP, SSH, Telnet, RDP), as well as file-based protocol attributes (for example, for CIFS), content attributes (for example, URL fields, web cookies, MIME types, file names), or resource attributes (for example, for JDBC/SQL data, J2EE/EJB methods and parameters).
  • Machine Attributes relate to a machine or a peripheral (e.g. printer, phone, server) model number and software image types/versions, etc.

The Triangulated Authorization can complement and even co-operate with other existing approaches for authorization and authentication, for example, to form a multi-stage authorization solution: In a first stage, classical ISO Layer-3-based and/or ISO Layer-4-based authorization can be done, for example, using a classical firewall. Requests that pass this first stage then get processed by a second stage authorization. In this second stage, the appropriate APS performs Triangulated Authorization based on ISO Layer-7 Application Service data. If the request passes this second stage, it will get handled by a third stage. This third stage can, for example, be another APS—in a multi-APS and/or in a multi-ANA architecture, or it can be handled by classical application-centric authorization methods.

Besides cascaded operation, the APS can perform Triangulated Authorization in combination with embedded PDP and embedded PEP and, optionally, with external PDP. In one example, as shown in FIG. 5 a subject 4741 requests access to a resource 4714 which is provided by application server 4710. In a first authorization stage, the APS 4740 performs Triangulated Authorization using its own internal PEP 4743 and its own internal PDP 4745. This PDP 4745 operates on the Triangulated Identity which can rely on protocol and content attributes 4742, for example. The APS 4740 can, optionally, also interact with another external PDP, such as PDP 4725, which is served by a policy server 4726 and which operates on the user attributes 4722. When the APS 4740 grants subject 4741 access to resource 4714 a secondary authorization, this time embedded in the application server 4710, can be performed. Various possibilities exist, for example, the application server 4710 can have its own embedded PEP 4713 and its own embedded PDP 4715. The embedded PDP 4715 can operate on user attributes 4712 to make an access control decision. Or, PDP 4715 can operate on user attributes 4722, for example via a Virtual Directory Infrastructure. In another example, the application server 4710 has no embedded PDP 4715 and instead interacts with the PDP 4745 from the APS 4740, or with the PDP 4725 from policy server 4726, or both. In yet another example, the application server 4710 has no embedded PEP 4713 and instead utilizes the PEP 4743 from the APS 4740 for access control.

In one of the embodiments of one of these inventions, policies are used in a rule-based authorization method to define sets of rules for authorization permissions. Rules are expressions or conditions on multiple, arbitrary attributes which evaluate to TRUE or FALSE and determine whether access shall be granted or rejected. Policies are stored in a PDP, for example, PDP 4735, which can be, for example, LDAP/AD. Also, policies can interact with single-sign-on assertions from SAML, or Kerberos. The policies can be described in various formats including common scripting languages such as TCL, Python, or Perl. Policies can also be described in industry standard formats such as XACML or in proprietary formats, or combinations thereof.

FIGS. 6-7 show how one embodiment of the invention can perform Triangulated Authorization when a client issues a first request. A user 4750, which can be, for example, client 1001 of FIG. 1, or client 2001 of FIG. 2, connects to the ANA 4760, which can be, for example, the APS 2000 of FIG. 2, or any appropriate authorization approach contemplated by one of ordinary skill in the art. In a first step 4751, the user 4750 issues for the first time a request to login (for example, to access certain resources) on application server 4762; ISO Layer-7 proxy 4766 terminates the transport protocol connection from the user 4750 and acts as a proxy for application server 4762 as described above. In a second step 4752, the ANA 4760 then authenticates the user via access to a directory service 4764. In a third step 4753, the directory service 4764 obtains user attributes from the multiple identity data stores 4761. In a fourth step 4754, the obtained user attributes get cached in the session record table 4763. In a fifth step 4755, the ANA 4760 finds the relevant policy and makes a policy-based access decision based on the user or other attributes, obtained, for example, via ISO Layer-7 service processing using the rule engine 4765 as described above. In a sixth step 4756, the ISO Layer-7 proxy 4766 forwards the request from user 4750 to the application server 4762, if and only if permitted by the policy. In a seventh step 4757, the ISO Layer-7 proxy 4766 proxies the response from the application server 4762 and forwards the server's response, together with a session cookie, back to the user 4750. The order of the above steps is exemplary only, and is not intended to be limiting.

FIGS. 8-9 show how an embodiment of the invention performs Triangulated Authorization when a client issues a subsequent request. The user 4750 connects to the ANA 4760. In a first step 4781, the user 4750 issues a subsequent request to login (for example, to again access certain resources) on application server 4762; ISO Layer-7 proxy 4766 terminates the transport protocol connection from the user 4750 and acts as a proxy for application server 4762 as described above. In a second step 4782, the session cookie embedded within the user's subsequent request is validated against the session record in the session record table 4763. In a third step 4783, the ANA 4760 finds the relevant policy and makes a policy-based access decision based on the user or other attributes, obtained, for example, via ISO Layer-7 service processing using the rule engine 4765 as described above. In a fourth step 4784, the ISO Layer-7 proxy forwards the request from user 4750 to the application server 4762, if and only if permitted by the policy. In a fifth step 4755, the ISO Layer-7 proxy proxies the response from the application server 4762 and forwards the server's response, together with a session cookie, back to the user 4750. The order of the above steps is exemplary only, and is not intended to be limiting.

Virtual Directory Infrastructure

A Virtual Directory Infrastructure hides the complexity of the different protocols and the different formats of identity stores and can provide real-time access to the existing identity stores without moving the data out of the original repository. The Virtual Directory Infrastructure can be used in conjunction with Triangulated Authorization. FIG. 13 and

FIG. 14 show how one embodiment of the invention can perform Triangulated Authorization when a client issues a first request and Virtual Directory Infrastructure is utilized. A user 4750, which can be, for example, client 2001 of FIG. 2, connects to the ANA 4760, which can be, for example, the APS 2000 of FIG. 2. In a first step 4751, the user 4750 issues for the first time a request to login (for example, to access certain resources) on application server 4762; ISO Layer-7 proxy 4766 terminates the transport protocol connection from the user 4750 and acts as a proxy for application server 4762 as described above. In a second step 4752, the ANA 4760 then authenticates the user via access to Virtual Directory Infrastructure 4768. This Virtual Directory Infrastructure can, for example, be Virtual Directory Infrastructure 4900 of FIG. 4. In a third step 4753, the Virtual Directory Infrastructure 4768 obtains user attributes from the multiple identity data stores 4761 and 4767. In a fourth step 4754, the obtained user attributes get cached in the session record table 4763. In a fifth step 4755, the ANA 4760 finds the relevant policy and makes a policy-based access decision based on the user or other attributes, obtained, for example, via ISO Layer-7 service processing using the rule engine 4765 as described above. In a sixth step 4756, the ISO Layer-7 proxy 4766 forwards the request from user 4750 to the application server 4762, if and only if permitted by the policy. In a seventh step 4757, the ISO Layer-7 proxy 4766 proxies the response from the application server 4762 and forwards the server's response, together with a session cookie, back to the user 4750. The order of the above steps is exemplary only, and is not intended to be limiting.

FIGS. 15-16 show how an embodiment of the invention can perform Triangulated Authorization when a client issues a subsequent request. The user 4750 connects to the ANA 4760. In a first step 4781, the user 4750 issues a subsequent request to login (for example, to again access certain resources) on application server 4762; ISO Layer-7 proxy 4766 terminates the transport protocol connection from the user 4750 and acts as a proxy for application server 4762 as described above. In a second step 4782, the session cookie embedded within the user's subsequent request is validated against the session record in the session record table 4763. In a third step 4783, the ANA 4760 finds the relevant policy and makes a policy-based access decision based on the user or other attributes, obtained, for example, via ISO Layer-7 service processing using the rule engine 4765 as described above. In a fourth step 4784, the ISO Layer-7 proxy 4766 forwards the request from user 4750 to the application server 4762, if and only if permitted by the policy. In a fifth step 4755, the ISO Layer-7 proxy 4766 proxies the response from the application server 4762 and forwards the server's response, together with a session cookie, back to the user 4750. The order of the above steps is exemplary only, and is not intended to be limiting.

Some portions of the preceding detailed descriptions have been presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the ways used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. The operations are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the above discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

Embodiments of the present invention also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), erasable programmable ROMs (EPROMs), electrically erasable programmable ROMs (EEPROMs), magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.

The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method operations. The required structure for a variety of these systems will appear from the description below. In addition, embodiments of the present invention are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of embodiments of the invention as described herein.

A machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium includes read only memory (“ROM”); random access memory (“RAM”); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.); etc.

In the foregoing specification, embodiments of the invention have been described with reference to specific exemplary embodiments thereof. It will be evident that various modifications may be made thereto without departing from the broader spirit and scope of the invention as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.

Claims

1. A method performed by a network element, the method comprising:

receiving at a network element a packet of a network transaction from a client requesting accessing a server of a datacenter having a plurality of servers, the network element operating as a security gateway to the datacenter;

in response to the packet, obtaining user attributes associated with a user of the network transaction from a plurality of directory servers via a virtual directory interface (VDI), wherein the VDI is embedded within the network element; and

authenticating and authorizing the user of network transaction using at least the user attributes obtained via the VDI to determine whether the user is eligible to access the server of the datacenter.

2. The method of claim 1, wherein the VDI is configured to access the directory servers via a converged datacenter fabric without having to use a TCP connection.

3. The method of claim 2, wherein the VDI is configured to provide a common interface to retrieve the user attributes from a plurality of identity stores located in the directory servers which require different protocols to access the identity stores.

4. The method of claim 3, wherein the VDI is configured to provide a single VDI view representing all user attributes that are associated with the user retrieved from the identity stores.

5. The method of claim 1, wherein the authentication and authorization is a part of layer 5 to layer 7 (layer 5-7) services performed within the network element.

6. The method of claim 1, wherein the user attributes comprise at least one of a department of an enterprise associated with the user, a role of the user within the enterprise, a project in which the user is a member, a seniority of the user within the enterprise, and a citizenship of the user.

7. The method of claim 1, wherein authenticating and authorizing the user further comprises authenticating and authorizing using environment attributes and subject attributes, wherein the environment attributes comprise at least one of network access methods, a location associated with the client, and a time and date associated with the network transaction, threat condition and emergency/weather alarm, wherein the subject attributes comprise at least one of protocol attributes, content attributes, resource attributes, and data attributes, and wherein the authentication and authorization are performed further using machine attributes including at least one of model identifier of a device and software image type and/or version.

8. The method of claim 4, wherein the VDI is configured to dynamically join different data sets obtained from different identity stores to provide the single VDI view, wherein the VDI is configured to consolidate different schemas associated with the different identity stores by mapping attribute names of the identity stores with attribute names obtained from the packet of the network transaction.

9. A machine-readable medium having instructions stored therein, which when executed by a machine, cause the machine to perform a method, the method comprising:

receiving at a network element a packet of a network transaction from a client requesting accessing a server of a datacenter having a plurality of servers, the network element operating as a security gateway to the datacenter;

in response to the packet, obtaining user attributes associated with a user of the network transaction from a plurality of directory servers via a virtual directory interface (VDI), wherein the VDI is embedded within the network element; and

authenticating and authorizing the user of network transaction using at least the user attributes obtained via the VDI to determine whether the user is eligible to access the server of the datacenter.

10. The machine-readable medium of claim 9, wherein the VDI is configured to access the directory servers via a converged datacenter fabric without having to use a TCP connection.

11. The machine-readable medium of claim 10, wherein the VDI is configured to provide a common interface to retrieve the user attributes from a plurality of identity stores located in the directory servers which require different protocols to access the identity stores.

12. The machine-readable medium of claim 11, wherein the VDI is configured to provide a single VDI view representing all user attributes that are associated with the user retrieved from the identity stores.

13. The machine-readable medium of claim 9, wherein the authentication and authorization is a part of layer 5 to layer 7 (layer 5-7) services performed within the network element.

14. The machine-readable medium of claim 9, wherein the user attributes comprise at least one of a department of an enterprise associated with the user, a role of the user within the enterprise, a project in which the user is a member, a seniority of the user within the enterprise, and a citizenship of the user.

15. The machine-readable medium of claim 9, wherein authenticating and authorizing the user further comprises authenticating and authorizing using environment attributes and subject attributes, wherein the environment attributes comprise at least one of network access methods, a location associated with the client, and a time and date associated with the network transaction, threat condition and emergency/weather alarm, wherein the subject attributes comprise at least one of protocol attributes, content attributes, resource attributes, and data attributes, and wherein the authentication and authorization are performed further using machine attributes including at least one of model identifier of a device and software image type and/or version.

16. The machine-readable medium of claim 12, wherein the VDI is configured to dynamically join different data sets obtained from different identity stores to provide the single VDI view, wherein the VDI is configured to consolidate different schemas associated with the different identity stores by mapping attribute names of the identity stores with attribute names obtained from the packet of the network transaction.

17. A network element, comprising:

a virtual directory interface (VDI) coupled to a plurality of directory servers; and

an authentication and authorization unit coupled to the VDI,

wherein in response to a packet of a network transaction received from a client over a first network for accessing a server of a datacenter over a second network, the authentication and authorization unit is configured to obtain one or more user attributes from at least one of the directory server via the VDI,

wherein the authentication and authorization unit is configured to authenticate and/or authorize the packet based on at least the user attributes to determine whether a user of the client is eligible to access the server of the datacenter, and

wherein the network element operates as a security gateway to the datacenter and each client of the first network has to go through the security gateway in order to access a server of the second network.

18. The network element of claim 17, wherein the VDI is configured to access the directory servers via a converged datacenter fabric without having to use a TCP connection.

19. The network element of claim 18, wherein the VDI is configured to provide a common interface to retrieve the user attributes from a plurality of identity stores located in the directory servers which require different protocols to access the identity stores.

20. The network element of claim 19, wherein the VDI is configured to provide a single VDI view representing all user attributes that are associated with the user retrieved from the identity stores.

21. The network element of claim 17, wherein the authentication and authorization is a part of layer 5 to layer 7 (layer 5-7) services performed within the network element.

22. The network element of claim 17, wherein the user attributes comprise at least one of a department of an enterprise associated with the user, a role of the user within the enterprise, a project in which the user is a member, a seniority of the user within the enterprise, and a citizenship of the user.

23. The network element of claim 17, wherein authenticating and authorizing the user further comprises authenticating and authorizing using environment attributes and subject attributes, wherein the environment attributes comprise at least one of network access methods, a location associated with the client, and a time and date associated with the network transaction, threat condition and emergency/weather alarm, wherein the subject attributes comprise at least one of protocol attributes, content attributes, resource attributes, and data attributes, and wherein the authentication and authorization are performed further using machine attributes including at least one of model identifier of a device and software image type and/or version.

24. The network element of claim 20, wherein the VDI is configured to dynamically join different data sets obtained from different identity stores to provide the single VDI view, wherein the VDI is configured to consolidate different schemas associated with the different identity stores by mapping attribute names of the identity stores with attribute names obtained from the packet of the network transaction.