U.S. patent application number 12/101857 was filed with the patent office on 2009-03-05 for application protection architecture with triangulated authorization.
This patent application is currently assigned to ROHATI SYSTEMS, INC.. Invention is credited to Nagaraj Bagepalli, Prashant Gandhi, Abhijit Patra, Kirti Prabhu, Anant Thakar.
Application Number | 20090064287 12/101857 |
Document ID | / |
Family ID | 40407382 |
Filed Date | 2009-03-05 |
United States Patent
Application |
20090064287 |
Kind Code |
A1 |
Bagepalli; Nagaraj ; et
al. |
March 5, 2009 |
APPLICATION PROTECTION ARCHITECTURE WITH TRIANGULATED
AUTHORIZATION
Abstract
Application protection architecture with triangulated
authorization is described herein. According to one embodiment, a
packet of a network transaction is received at a network element
from a client system over a first network for accessing a destined
server of a datacenter over a second network, where network element
operates as a security gateway to the datacenter. In response to
the packet, one or more user attributes associated with a user of
the client system are obtained from an identity store, where the
user attributes include a user identifier that identifies the user
and a machine identifier that identifies the client system.
Authentication and/or authorization are performed on the packet
using the user attributes to determine whether the user of the
client system is eligible to access the destined server of the
datacenter. Other methods and apparatuses are also described.
Inventors: |
Bagepalli; Nagaraj; (San
Jose, CA) ; Gandhi; Prashant; (San Jose, CA) ;
Patra; Abhijit; (San Jose, CA) ; Prabhu; Kirti;
(San Jose, CA) ; Thakar; Anant; (Cupertino,
CA) |
Correspondence
Address: |
BLAKELY SOKOLOFF TAYLOR & ZAFMAN LLP
1279 OAKMEAD PARKWAY
SUNNYVALE
CA
94085-4040
US
|
Assignee: |
ROHATI SYSTEMS, INC.
Sunnyvale
CA
|
Family ID: |
40407382 |
Appl. No.: |
12/101857 |
Filed: |
April 11, 2008 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60966649 |
Aug 28, 2007 |
|
|
|
Current U.S.
Class: |
726/4 |
Current CPC
Class: |
H04L 47/20 20130101;
H04L 63/02 20130101; H04L 63/166 20130101; H04L 69/16 20130101;
H04L 9/3242 20130101; H04L 69/161 20130101; H04L 63/0428 20130101;
H04L 63/205 20130101; H04L 69/321 20130101; Y10T 70/5827
20150401 |
Class at
Publication: |
726/4 |
International
Class: |
G06F 7/04 20060101
G06F007/04 |
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 system over a first network for accessing a destined
server of a datacenter over a second network, the network element
operating as a security gateway to the datacenter, wherein each
client of the first network has to go through the network element
in order to access the datacenter over the second network; in
response to the packet, obtaining one or more user attributes
associated with a user of the client system from an identity store,
the user attributes including a user identifier that identifies the
user and a machine identifier that identifies the client system;
and performing authentication and/or authorization on the packet
using the user attributes to determine whether the user of the
client system is eligible to access the destined server of the
datacenter.
2. The method of claim 1, wherein the user attributes further
comprise a work department of an organization associated with the
user, a role within the work department of the user, and a project
involved by the user.
3. The method of claim 2, wherein the user attributes further
comprise a seniority of the user within the organization, a
citizenship of the user, and security clearance information
associated with the user.
4. The method of claim 1, wherein the user attributes are obtained
from a plurality of identity stores in a plurality of directory
servers via a virtual directory interface (VDI), including Active
Directory, LDAP, SQL stores, Unix NIS directory, and RADIUS.
5. The method of claim 1, wherein the authentication and/or
authorization using the user attributes is part of a layer 7 access
control process performed within the network element.
6. The method of claim 1, wherein the authentication and/or
authorization is performed further based on one or more environment
attributes associated with the user and an organization associated
with the datacenter.
7. The method of claim 6, wherein the environment attributes
identify a location of the user and/or the client system in view of
the organization associated with the datacenter, including at least
one of a source IP address, destination IP address, network
environment attributes, network access methods, time of accesses,
threat conditions, weather alerts, and emergency conditions.
8. The method of claim 7, wherein the network access methods
comprise at least one of a LAN access, WLAN access, Wi-Fi access,
mobile access, mobile phone access, dial-up access, and VPN
access.
9. The method of claim 6, wherein the authentication and/or
authorization is performed further based on one or more of
protocol, content, and resource and data attributes associated with
the network transaction.
10. A machine-readable medium having instructions stored therein,
which when executed from 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 system over a first
network for accessing a destined server of a datacenter over a
second network, the network element operating as a security gateway
to the datacenter, wherein each client of the first network has to
go through the network element in order to access the datacenter
over the second network; in response to the packet, obtaining one
or more user attributes associated with a user of the client system
from an identity store, the user attributes including a user
identifier that identifies the user and a machine identifier that
identifies the client system; and performing authentication and/or
authorization on the packet using the user attributes to determine
whether the user of the client system is eligible to access the
destined server of the datacenter.
11. The machine-readable medium of claim 10, wherein the user
attributes further comprise a work department of an organization
associated with the user, a role within the work department of the
user, and a project involved by the user.
12. The machine-readable medium of claim 11, wherein the user
attributes further comprise a seniority of the user within the
organization, a citizenship of the user, and security clearance
information associated with the user.
13. The machine-readable medium of claim 10, wherein the user
attributes are obtained from a plurality of identity stores in a
plurality of directory servers via a virtual directory interface
(VDI), including Active Directory, LDAP, SQL stores, Unix NIS
directory, and RADIUS.
14. The machine-readable medium of claim 10, wherein the
authentication and/or authorization using the user attributes is
part of a layer 7 access control process performed within the
network element.
15. The machine-readable medium of claim 10, wherein the
authentication and/or authorization is performed further based on
one or more environment attributes associated with the user and an
organization associated with the datacenter.
16. The machine-readable medium of claim 15, wherein the
environment attributes identify a location of the user and/or the
client system in view of the organization associated with the
datacenter, including at least one of a source IP address,
destination IP address, network environment attributes, network
access methods, time of accesses, threat conditions, weather
alerts, and emergency conditions.
17. The machine-readable medium of claim 16, wherein the network
access methods comprise at least one of a LAN access, WLAN access,
Wi-Fi access, mobile access, mobile phone access, dial-up access,
and VPN access.
18. The machine-readable medium of claim 15, wherein the
authentication and/or authorization is performed further based on
one or more of protocol, content, and resource and data attributes
associated with the network transaction.
19. A network element, comprising: an attribute collector; an
authentication and authorization unit coupled to the attribute
collector; and wherein in response to a packet of a network
transaction received from a client system over a first network for
accessing a server of a datacenter over a second network, the
attribute collector is configured to obtain one or more user
attributes from an identity store, the user attributes including a
user identifier that identifies the user and a machine identifier
that identifies the client system, wherein the authentication and
authorization unit is configured to authenticate and/or authorize
the packet based on the user attributes to determine whether a user
of the client system 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.
20. The network element of claim 19, further comprising a user
attribute manager coupled to the attribute collector to manage the
user attributes, wherein the user attributes further comprise a
work department of an organization associated with the user, a role
within the work department of the user, and a project involved by
the user.
21. The network element of claim 20, wherein the user attributes
further comprise a seniority of the user within the organization, a
citizenship of the user, and security clearance information
associated with the user.
22. The network element of claim 19, wherein the authentication
and/or authorization using the user attributes is part of a layer 7
access control process performed within the network element.
23. The network element of claim 19, further comprising a virtual
directory interface (VDI) to access different identity stores of a
plurality of directory servers to obtain the user attributes,
including Active Directory, LDAP, SQL stores, Unix NIS directory,
and RADIUS.
24. The network element of claim 19, further comprising an
environment attribute manager to manage environment attributes,
wherein the authentication and/or authorization is performed
further based on one or more environment attributes associated with
the user and an organization associated with the datacenter, and
wherein the environment attributes identify a location of the user
and/or the client system in view of the organization associated
with the datacenter, including at least one of a source IP address,
destination IP address, network environment attributes, network
access methods, time of accesses, threat conditions, weather
alerts, and emergency conditions.
25. The network element of claim 24, further comprising a content
attribute manager for managing protocol, content, and resource and
data attributes, wherein the authentication and/or authorization is
performed further based on one or more of protocol, content, and
resource attributes associated with the network transaction.
Description
RELATED APPLICATIONS
[0001] 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
[0002] The present invention relates generally to application
network appliances. More particularly, this invention relates to
application protection architecture with triangulated
authorization.
BACKGROUND
[0003] 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.
[0004] 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.
[0005] 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.
[0006] 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.
[0007] 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.
[0008] 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.
[0009] 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.
[0010] 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.
[0011] 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.
[0012] 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
[0013] Application protection architecture with triangulated
authorization is described herein. According to one embodiment, a
packet of a network transaction is received at a network element
from a client system over a first network for accessing a destined
server of a datacenter over a second network. The network element
operates as a security gateway to the datacenter, where each client
of the first network has to go through the network element in order
to access the datacenter over the second network. In response to
the packet, one or more user attributes associated with a user of
the client system are obtained from an identity store, where the
user attributes include a user identifier that identifies the user
and a machine identifier that identifies the client system.
Authentication and/or authorization are performed on the packet
using the user attributes to determine whether the user of the
client system is eligible to access the destined server of the
datacenter.
[0014] 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
[0015] 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.
[0016] FIG. 1 illustrates a typical corporate computer network
connected to the Internet;
[0017] FIG. 2 illustrates the application of an application network
appliance (ANA) as the APS according to one embodiment of the
invention;
[0018] FIG. 3 is a network connected block diagram of an ANA
according to one embodiment of the invention;
[0019] FIG. 4 is a block diagram of a Virtual Directory
Infrastructure system for Triangulated Authorization according to
another embodiment of the invention;
[0020] FIG. 5 is a block diagram of a Network Service Module (NSM)
of an ANA according to one embodiment of the invention;
[0021] FIG. 6 is a block diagram of a NSM of an ANA according to
another embodiment of the invention;
[0022] FIG. 7 is a block diagram of an Application Service Module
(ASM) of an ANA according to one embodiment of the invention;
[0023] FIG. 8 is a block diagram of an ASM of an ANA according to
another embodiment of the invention;
[0024] FIG. 9 is a block diagram which illustrates LDTF
connectivity between a NSM and an ASM of an ANA according to one
embodiment of the invention;
[0025] FIG. 10 is a block diagram of the APS combined with embedded
PDP and PEP;
[0026] FIG. 11 is a block diagram of a system for Triangulated
Authorization of a first request according to one embodiment of the
invention;
[0027] FIG. 12 is a flow diagram of a method for Triangulated
Authorization of a first request according to one embodiment of the
invention;
[0028] FIG. 13 is a block diagram of a system for Triangulated
Authorization of a subsequent request according to one embodiment
of the invention;
[0029] FIG. 14 is a flow diagram of a method for Triangulated
Authorization of a subsequent request according to one embodiment
of the invention;
[0030] FIG. 15 is a detailed flow diagram of Triangulated
Authorization in an ANA according to one embodiment of the
invention;
[0031] FIG. 16 is a block diagram which illustrates context
identification for a virtualized Triangulated Authorization in an
ANA according to one embodiment of the invention;
[0032] FIG. 17 is a flow diagram which illustrates the HTTP
protocol;
[0033] FIG. 18 is a block diagram which illustrates the CIFS
protocol packet;
[0034] FIG. 19 is a block diagram which illustrates the application
of the SQLnet protocol;
[0035] FIG. 20 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;
[0036] FIG. 21 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;
[0037] FIG. 22 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;
[0038] FIG. 23 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;
[0039] FIG. 24 is a detailed flow diagram of Triangulated
Authorization in an ANA using a Virtual Directory Infrastructure
according to one embodiment of the invention;
[0040] FIG. 25 is a block diagram of functional components to
perform Triangulated Authorization in an ANA according to one
embodiment of the invention;
[0041] FIG. 26 is a flow diagram to perform Triangulated
Authorization in an ANA according to one embodiment of the
invention;
DETAILED DESCRIPTION
[0042] 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.
[0043] 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.
[0044] 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.
[0045] 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
[0046] 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.
[0047] 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.
[0048] 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.
[0049] 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.
[0050] 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.
[0051] 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.
[0052] 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.
[0053] 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.
[0054] 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.
[0055] 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.
[0056] 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.
[0057] 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.
[0058] 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:
[0059] 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.
[0060] 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.
[0061] 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.
[0062] 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.
L2-L5 Processing Unit--NSM
[0063] A NSM processes the lower network layers, ISO Layer-2 to ISO
Layer-5. In one embodiment of the invention, such a NSM can be
constructed as shown in FIG. 5. The NSM 2800, which can be, for
example, NSM 2103 of FIG. 3, comprises a host channel adapter (HCA)
2801, a network services processor (NSP) 2802, an physical network
layer receiver (Phy) 2803 and memory 2804. The host channel adapter
2801 connects to the LDTF, which can be IB fabric. The physical
network layer receiver 2803 connects to Ethernet. The NSP 2803 runs
programs stored in memory 2804 to perform ISO Layer-2 to ISO
Layer-5 processing, such as Centralized Transport Protocol
Termination, PDU reassembly to transform the PDU payload into a
data stream, cryptographic processing, etc.
[0064] For better scalability, in one embodiment of the invention,
a NSM can be a multi-processor architecture, as shown in FIG. 6.
Here the NSM 2810 can comprise two--or more--NSPs, such as NSP
2812, NSP 2822, NSP 2832, each having a dedicated host channel
adapter, such as host channel adapter 2811, host channel adapter
2821, and host channel adapter 2831, and dedicated memory, such as
memory 2814, memory 2824, and memory 2834. A load balancer 2815 is
in between the NSPs and the physical network layer receiver 2813
and balances the network load between the two--or more--NSPs. The
load balancer 2815 can use common approaches known in the art to
balance ingress or egress network traffic.
L7 Processing Unit--ASM
[0065] An ASM performs the ISO Layer-7 services, including
application data processing on the data stream, which is the data
stream of the transport protocol's PDU payload transformed by one
or more NSMs. FIG. 7 illustrates how an ASM can be constructed in
one embodiment of the invention. The ASM 3300 comprises a host
channel adapter (HCA) 3301, an Application Service Processor (ASP)
3302, a bridge 3303 and memory 3304. The host channel adapter 3301
connects to the converged data center fabric which can be, for
example, without limitation, LDTF or IB fabric. The bridge 3303
connects to the LDTF as a link to NSMs, for example. The ASP 3302
runs programs stored in memory 3304 to examine all ISO Layer-7
traffic and to perform ISO Layer-7 processing such as regular
expression parsing, compression and decompression, standard and
custom protocol proxy functions, etc.
[0066] For those tasks a high compute power is needed, typically
more than for plain ISO Layer-2 to ISO Layer-5 processing.
Therefore, a single-processor architecture using existing
micro-processors may require hardware assist to provide sufficient
compute power for high-bandwidth client-to-server connections.
Alternatively, it may be advantageous to implement an ASM either as
a homogeneous multi-processor system of generic ISO Layer-7
processing units, or as a heterogeneous multi-processing system
using a sea of different, specialized ISO Layer-7 processing units.
FIG. 8 shows such a multi-processor architecture: Here the ASM 3310
can comprise two--or more--ASPs, such as ASP 3312, ASP 3322, ASP
3332, each having a dedicated host channel adapter, such as host
channel adapter 3311, host channel adapter 3321, and host channel
adapter 3331, and dedicated memory, such as memory 3314, memory
3324, and memory 3334. The LDTF bridge 3313 connects the ASPs via
the LDTF to the NSMs, for example.
[0067] For building the multi-processor architecture of the ASM
several options exist: A multi-core processor technology can be
used, which can be a System-on-a-Chip with on-chip hardware
accelerators; or one can use multi-core processors with external
co-processors, for example, a co-processor for cryptographic
operations, a co-processor for regular expression analysis, a
co-processor for data compression and decompression, etc. A
parallel-mode compute architecture can be deployed which will
require a flow dispatcher to distribute incoming traffic across the
multiple processors. A pipelined-mode compute architecture can be
used, where one processing element acts as a pre-processor for a
subsequent processing element. Or, a hybrid approach can be used
combining parallel mode with pipelined compute architectures.
Further, any other architecture contemplated by one of skill in the
art may be used.
LDTF to Connect L2-L5 Unit with L7 Units
[0068] In any case, the compute architecture requires a lossless,
low-latency, high-bandwidth fabric for any-to-any inter-process
communication links between the one or more NSMs (which each may
comprise one or more NSPs) and the one or more ASMs (which each may
comprise one or more ASPs). FIG. 9 shows how in one embodiment of
the invention, one ISO Layer-2 to ISO Layer-5 processing unit, NSM
3441, and one ISO Layer-7 processing unit, ASM 3443, can be
connected via the LDTF 3442. Key to the connection is the use of an
RDMA network interface connector (RNIC) which can be a host channel
adapter for IB, for example, host channel adapter 2801, or host
channel adapter 2811, or host channel adapter 2821, or host channel
adapter 2831, or host channel adapter 3301, or host channel adapter
3311, or host channel adapter 3321, or host channel adapter 3331.
Of course, two or more ISO Layer-2 to ISO Layer-5 processing units
can be connected to two or more ISO Layer-7 processing units
accordingly.
[0069] Many options exist for implementing the LDTF 3442: In one
embodiment of the invention the LDTF can be IB. In another
embodiment of the invention the LDTF can be Data Center Ethernet
with RDMA support. In yet another embodiment of the invention, the
LDTF can be iWARP which supports RDMA over TCP. Besides being a
lossless, low-latency, high-bandwidth interconnect means RDMA
enables the performance of RDMA one-sided read-based load
monitoring and can be used to map connection level flow control
using RDMA queue-pair flow control.
Triangulated Authorization
[0070] 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. 10 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. 10, 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: [0071] 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. [0072]
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, or network security
classification. [0073] 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).
[0074] 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.
[0075] 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. 10 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.
[0076] 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.
[0077] FIGS. 11-12 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.
[0078] FIGS. 13-14 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.
[0079] FIG. 15 shows the details of Triangulated Authorization
according to one embodiment of the invention. A communication
subsystem manager 4815 forwards the data stream to the application
container 4814. In a multi-processing architecture, application
container 4814 can perform load balancing and dispatching of tasks
to one or more processing elements. The one or more processing
elements then perform protocol recognition 4813 and, depending on
the protocol recognized in the data stream, forward the data stream
to the appropriate protocol proxy. For example, if the JDBC
protocol was recognized, the data stream is forwarded to the JDBC
proxy 4809, if the CIFS protocol was recognized, the data stream is
forwarded to the CIFS proxy 4810, if the HTTP protocol was
recognized, the data stream is forwarded to the HTTP proxy 4811, or
if a custom protocol was recognized, the data stream is forwarded
to the custom protocol proxy 4812. The custom protocol proxy 4812
can be programmable, for example, without limitation, using the
Java.TM. programming language or the TCL scripting language, or any
other programming language as may be contemplated by one of skill
in the art, to analyze various custom protocols. Each protocol
engine can then use the regular expression engine 4808, the user
attribute manager 4807 and the content attribute manager 4806 to
extract Triangulated Identity attributes from the data stream. The
user attribute manager 4807 can query an identity store 4802
through a directory interface 4805 to obtain user attributes. The
attribute collector 4804 collects all attributes extracted,
including attributes obtained by the environmental attribute
manager 4803, to query a rule engine 4801 whether the particular
request matches policies such that a policy decision can be
made.
[0080] In protocol recognition 4813 of FIG. 46, various approaches
for analyzing protocols can be deployed for protocol analysis. LAN
frames and VLAN frames can be analyzed by looking at their portions
(FIG. 16). The HTTP protocol is illustrated in FIG. 17. The CIFS
protocol is illustrated in FIG. 18. The SQLNet protocol is
illustrated in FIG. 19.
Virtual Directory Infrastructure
[0081] 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. 20 and FIG. 21 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.
[0082] FIGS. 22-23 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.
[0083] FIG. 24 shows the details of Triangulated Authorization
utilizing Virtual Directory Infrastructure according to one
embodiment of the invention. A communication subsystem manager 4815
forwards the data stream to the application container 4814. In a
multi-processing architecture, application container 4814 can
perform load balancing and dispatching of tasks to one or more
processing elements. The one or more processing elements then
perform protocol recognition 4813 and, depending on the protocol
recognized in the data stream, forward the data stream to the
appropriate protocol proxy. For example, if the JDBC protocol was
recognized, the data stream is forwarded to the JDBC proxy 4809, if
the CIFS protocol was recognized, the data stream is forwarded to
the CIFS proxy 4810, if the HTTP protocol was recognized, the data
stream is forwarded to the HTTP proxy 4811, or if a custom protocol
was recognized, the data stream is forwarded to the custom protocol
proxy 4812. Each protocol engine can then use the regular
expression engine 4808, the user attribute manager 4807 and the
content attribute manager 4806 to extract Triangulated Identity
attributes from the data stream. The user attribute manager 4807
can query multiple identity stores 4802, 4911, and 4912 through
Virtual Directory Infrastructure 4910 to obtain user attributes.
The Virtual Directory Infrastructure 4910 can, for example, be
Virtual Directory Infrastructure 4900 of FIG. 4. The attribute
collector 4804 collects all attributes extracted, including
attributes obtained by the environmental attribute manager 4803, to
query a rule engine 4801 whether the particular request matches
policies such that a policy decision can be made.
Processing Flows
[0084] Splitting the data network processing into two separate
domains, Network Service processing and Application Service
processing--especially when constrained by scalability and
high-availability--may require a particular processing flow between
the one or more NSPs and the one or more ASPs.
[0085] For example, it is desirable to enforce flow-control because
the proxy splits the client-server connection into two portions:
One client-to-proxy connection which typically has a high
round-trip delay time and low throughput and a proxy-to-server
connection which typically has low round-trip delay time and high
throughput. The flow control for the client connection and the
server connection mimic the behavior of the end-to-end flow-control
of the original client-to-server connection. The internal LDTF
enables the mapping of connection-level flow-control using RDMA
queue-pair flow-control and therefore solves the problem created by
splitting the client-server connection with a proxy.
[0086] The processing flow of yet another embodiment of the
invention is shown in FIGS. 25-26. In an initialization step 3721,
the ASP Configuration Agent 3701 calls the Rule Engine Build API
3704 to build the rule and regular expression database 3703. In a
first step 3722 the Rule Engine Build API 3704 calls the Attribute
Management API 3705 to map attributes in the policies to
identifications. In a second step 3723, the Application Switch
Transport API 3716 calls the HTTP Proxy 3712 callbacks whenever it
receives an HTTP segment. In a third step 3724, the Session Manager
3711 calls the AAA API 3718 to authenticate the user based on an
authentication policy. In a fourth step 3725, The User and
Attribute Manager 3706 calls the Virtual Directory Infrastructure
Virtual Directory Infrastructure API 3707 to authenticate the user
and to retrieve user attributes from the Virtual Directory
Infrastructure Virtual Directory Infrastructure 3708. In a fifth
step 3726, the Session Manager 3711 calls the Rule Engine (PDP and
PEP) 3709 to determine the resource access decision. In a sixth
step 3727, the HTTP Proxy 3712 calls the Application Switch
Transport API 3716 to forward the user's request or response. In a
seventh step 3728, the Session Manager 3711 calls the Session
Record Replicate API 3715 to backup the session record. The order
of the above steps is exemplary only, and is not intended to be
limiting.
[0087] 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.
[0088] 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.
[0089] 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.
[0090] 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.
[0091] 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.
[0092] 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.
* * * * *