US8935418B2 - Access system interface - Google Patents

Access system interface Download PDF

Info

Publication number
US8935418B2
US8935418B2 US12/255,787 US25578708A US8935418B2 US 8935418 B2 US8935418 B2 US 8935418B2 US 25578708 A US25578708 A US 25578708A US 8935418 B2 US8935418 B2 US 8935418B2
Authority
US
United States
Prior art keywords
access
user
authentication
server
resource
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
US12/255,787
Other versions
US20090106433A1 (en
Inventor
Charles W. Knouse
Minoo Gupta
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Oracle International Corp
Original Assignee
Oracle International Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/793,354 external-priority patent/US7080077B2/en
Priority claimed from US09/792,934 external-priority patent/US7134137B2/en
Priority claimed from US09/793,320 external-priority patent/US8661539B2/en
Priority claimed from US09/793,658 external-priority patent/US7194764B2/en
Priority claimed from US09/793,196 external-priority patent/US7249369B2/en
Priority claimed from US09/793,355 external-priority patent/US8204999B2/en
Priority claimed from US09/792,911 external-priority patent/US7124203B2/en
Priority claimed from US09/792,915 external-priority patent/US9038170B2/en
Priority claimed from US09/792,918 external-priority patent/US7464162B2/en
Application filed by Oracle International Corp filed Critical Oracle International Corp
Priority to US12/255,787 priority Critical patent/US8935418B2/en
Publication of US20090106433A1 publication Critical patent/US20090106433A1/en
Publication of US8935418B2 publication Critical patent/US8935418B2/en
Application granted granted Critical
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • H04L29/08621
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • H04L67/142Managing session states for stateless protocols; Signalling session states; State transitions; Keeping-state mechanisms
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • H04L67/146Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding

Definitions

  • the present invention is directed to an application program interface (API) for an access system.
  • API application program interface
  • an E-business host company needs an access system that delivers the ability to effectively secure and manage all the various network-based interactions.
  • An appropriate access system should be able to provide authentication and authorization services while accommodating all participants involved with the E-business, whether they are local or remote. It must also be able to distinguish between the E-business' employees and all the users who are affiliated with the E-business host's customers, suppliers and/or partners.
  • access systems Prior to authorizing a user to access a resource, access systems typically will authenticate a user. That is, they will verify the identity of the user. After a user successfully authenticates for a first protected resource, the user may request access to a second resource. If the second resource is also protected, the user may be required to perform a second authentication for the second resource. However, it may be redundant to force the user to re-authenticate for the second resource, especially if the previous authentication occurred relatively recently. Requiring repetitive re-authentications can unduly burden both users and networks, causing reduction in productivity and degradation in network performance.
  • Some access systems may store a cookie on a client machine to save state information and assist in future authentication processes.
  • prior access systems do not provide for an application outside the access system, not having a web agent front end, to be able to use the cookie and access the contents of the cookie in order to participate in providing authentication or authorization services.
  • the present invention provides for an application program interface for an access system that enables an application without a web agent front end to use contents of an existing cookie (or other storage mechanism) to provide access system services.
  • a web agent is a component (usually software, but can be hardware or a combination of hardware and software) that plugs into (or otherwise integrates with) a web server (or equivalent) in order to participate in providing access services.
  • One embodiment of the present invention includes the steps of receiving user session state information for a first user, receiving resource request information for a first resource and receiving a request to authorize the first user to access the first resource.
  • the request to authorize is from an application without a web agent front end.
  • the request is received by the access system interface of the present invention.
  • the present invention attempts to authorize the first user to access the first resource without requiring the first user to re-submit authentication credentials
  • the user session state information is encrypted and stored in a cookie.
  • the step of receiving user session state information includes decrypting the user session state information.
  • the system is also capable of receiving a request from the application for unencrypted data from the user session state information and providing the unencrypted data from the user session state information to the application.
  • the application does not have access to a key to decrypt the data in the user session state information.
  • Another embodiment of the present invention includes a method for providing access services by an application without a web agent front end
  • the method includes receiving an electronic request from a first user to access a first resource.
  • the step of receiving includes receiving information from a cookie.
  • the application provides the information from the cookie to an access system interface and requests the access system interface to authorize the first user to access the first resource based on information from the user's request and based on the information from the cookie.
  • Another embodiment of the present invention includes the steps of authenticating a first user, causing user session state information to be stored at a client for the first user, and authorizing the first user to access a first protected resource. Subsequently, the system receives a request from an application without a web agent front end to allow the first user to access a second protected resource. The step of receiving a request includes receiving the user session state information from the application. The system allows the first user to access the second protected resource without requiring the first user to re-submit authentication credentials, if the first user is authorized to access the second protected resource.
  • Different embodiments of the present include application program interfaces for various programming languages.
  • the present invention can provide an interface for Java, C, C++, etc. Note, however, that almost any other programming language, tools, scheme, etc. can be supported by the present invention.
  • the present invention can be implemented using hardware, software, or a combination of both hardware and software.
  • the software used for the present invention is stored on one or more processor readable storage devices including hard disk drives, CD-ROMs, DVDs, optical disks, floppy disks, tape drives, RAM, ROM or other suitable storage devices.
  • some or all of the software can be replaced by dedicated hardware including custom integrated circuits, gate arrays, FPGAs, PLDs, and special purpose computers.
  • Hardware that can be used for the present invention includes computers, handheld devices, telephones (e.g. cellular, Internet enabled, etc.), etc. Some of these devices includes processors, memory, nonvolatile storage, input devices and output devices.
  • FIG. 1 is a block diagram depicting the components of one embodiment of the present invention.
  • FIG. 2 is a block diagram depicting the components of the computing system that can be used with the present invention.
  • FIG. 3 is a block diagram depicting the components of a Directory Server.
  • FIG. 4 is an example of a directory tree structure.
  • FIG. 5 is a flow chart describing a process for setting up access rules for an Identity Management System.
  • FIG. 6 is a flow chart describing a process for editing an attribute access criteria.
  • FIG. 7 is a flow chart describing a process for configuring localized access.
  • FIG. 8 is a flow chart describing a process for controlling access to attributes in the Identity Management System.
  • FIG. 9 is a flow chart describing a process for determining access to attributes of a target.
  • FIG. 10 is a flow chart describing a process for determining whether there is a localized access violation for a class.
  • FIG. 11 is a flow chart describing a process for determining whether there is localized access for an attribute.
  • FIG. 12 is a flow chart describing a process for modifying an attribute.
  • FIG. 13 is a flow chart describing the active automation process.
  • FIG. 14 is a block diagram depicting the components of a Web Gate.
  • FIG. 15 is a block diagram depicting the components of an Access Server.
  • FIG. 16 is a flow chart describing a process for creating a policy domain.
  • FIG. 17 is a flow chart describing a process for adding an authorization rule.
  • FIG. 18 is a flow chart describing a process for adding header variables to an HTTP request.
  • FIG. 19 is a flow chart describing a process for adding an authentication rule.
  • FIG. 20 is a flow chart describing a process for configuring an audit rule.
  • FIG. 21 is a flow chart describing a process for creating a policy.
  • FIG. 22 is a flow chart describing an exemplar process performed by the Access System of one embodiment of the present invention.
  • FIG. 23 is a flow chart describing a process for determining whether a particular resource is protected.
  • FIG. 24 is a flow chart describing a process for mapping a resource with a policy domain.
  • FIG. 25 is a flow chart describing a process for retrieving first and second level authentication rules.
  • FIG. 26 is a flow chart describing a process for determining whether a resource URL matches a specific policy URL.
  • FIG. 26A is a flow chart describing a process for determining whether a resource matches a specific policy using POST data.
  • FIG. 27 provides a block diagram of a retainer data structure.
  • FIG. 28 is a flow chart describing authentication.
  • FIG. 29 is a block diagram depicting various components involved in the authentication process.
  • FIG. 30 is a flow chart describing a process for authentication.
  • FIG. 31 is a flow chart describing a process for retrieving an authentication challenge scheme from a Directory Server.
  • FIG. 32 is a flow chart describing a method for performing basic authentication.
  • FIG. 33 is a flow chart describing the process performed by an Access Server to authenticate using a user ID and password.
  • FIG. 34 is a flow chart describing form authentication.
  • FIG. 35 is a flow chart describing a process for client certificate authentication.
  • FIG. 36 is a flow chart describing a process for authenticating a user using certificates.
  • FIG. 37 is a block diagram depicting the components of one embodiment of an encrypted cookie.
  • FIG. 38 is a flowchart describing a process for authorization.
  • FIG. 39 is a flow chart describing the steps performed when passing authorization information using POST data.
  • FIG. 40 is a block diagram of an exemplar HTTP request.
  • FIG. 41 is a flow chart describing a process for obtaining first and second level authorization rules from a Directory Server.
  • FIG. 42 is a flow chart describing a process for evaluating an authorization rule.
  • FIG. 43 is a flow chart describing a process for applying an authorization rule to extracted POST data.
  • FIG. 44 is a flow chart describing a process for performing authentication success actions.
  • FIG. 45 is a flow chart describing a process for performing authentication and authorization failure actions.
  • FIG. 46 is a flow chart describing a process for performing authorization success actions.
  • FIG. 47 is a flow chart describing a process for using header variables.
  • FIG. 48 is a flow chart describing the steps performed by the auditing module of one embodiment of the present invention.
  • FIG. 49 is a flow chart describing a method for retrieving first and second level audit rules.
  • FIG. 50 is a block diagram depicting one embodiment of components used for intrusion detection.
  • FIG. 51 is a flow chart describing a process for detecting intrusions.
  • FIG. 52 is a flow chart describing a process performed at a security server as part of a process for detecting intrusions.
  • FIG. 53 is a flow chart describing a process for flushing/synchronizing caches performed by an Access Manager.
  • FIG. 54 is a block diagram depicting a synchronization record.
  • FIG. 55 is a flow chart describing a process for flushing/synchronizing caches performed by an Access Server.
  • FIG. 56 is a flow chart describing a process for flushing/synchronizing caches performed by a Web Gate.
  • FIG. 57 is a flow chart describing a process for testing access criteria.
  • FIG. 58 is a block diagram of another embodiment of the present invention.
  • FIG. 59 is a flow chart of a process for receiving and acting on a request according to the embodiment of FIG. 58 .
  • FIG. 60 is a flow chart of a process for authentication and authorizing according to the embodiment of FIG. 58 .
  • FIG. 61 is a flow chart of 60 is a flow chart of a process for authorizing according to the embodiment of FIG. 58 .
  • FIG. 62 is a flow chart explaining the process of the single sign-on feature of to the embodiment of FIG. 58 .
  • FIG. 1 depicts an Access System which provides identity management and/or access management for a network.
  • an Access System manages access to resources available to a network.
  • the identity management portion of the Access System (hereinafter “the Identity Management System”) manages end user identity profiles, while the access management portion of the Access System (hereinafter “the Access Management System”) provides security for resources across one or more web servers.
  • the Access Management System manages end user identity profiles
  • the Access Management System provides security for resources across one or more web servers.
  • the Access Management System provides security for resources across one or more web servers.
  • the Access Management System provides security for resources across one or more web servers.
  • the Access Management System provides security for resources across one or more web servers.
  • the Access Management System provides security for resources across one or more web servers.
  • the Access Management System provides security for resources across one or more web servers.
  • the Access Management System provides security for resources across one or more web servers.
  • the Access Management System provides security for resources across one or more web servers.
  • one embodiment of the system centralizes the policy and identity repositories by building them on a directory service technology.
  • the system decentralizes their administration by hierarchy delegated Administrative roles.
  • the Access System of FIG. 1 includes an Identity Management System and an Access Management System, other Access Systems may only include an Identity Management System or only include an Access Management System.
  • FIG. 1 is a block diagram depicting one embodiment for deploying an Access System.
  • FIG. 1 shows web browsers 12 and 14 accessing Web Server 18 and/or Administration Server 20 via Internet 16 .
  • web browsers 12 and 14 are standard web browsers known in the art running on any suitable type of computer.
  • FIG. 1 depicts web browsers 12 and 14 communicating with Web Server 24 and Administration Server 20 using HTTP over the Internet; however, other protocols and networks can also be used.
  • Web Server 18 is a standard Web Server known in the art and provides an end user with access to various resources via Internet 16 .
  • there is a first firewall (not shown) connected between Internet 16 and Web Server 18 a second firewall (not shown) connected between Web Server 18 and Access Server 34 .
  • FIG. 1 shows two types of resources: resource 22 and resource 24 .
  • Resource 22 is external to Web Server 18 but can be accessed through Web Server 18 .
  • Resource 24 is located on Web Server 18 .
  • a resource can be anything that is possible to address with a uniform resource locator (URL see RFC 1738).
  • a resource can include a web page, software application, file, database, directory, a data unit, etc.
  • a resource is anything accessible to a user on a network.
  • the network could be the Internet, a LAN, a WAN, or any other type of network. Table 1, below, provides examples of resources and at least a portion of their respective URL syntax:
  • a URL includes two main components: a protocol identifier and a resource name separated from the protocol identifier by a colon and two forward slashes.
  • the protocol identifier indicates the name of the protocol to be used to fetch the resource. Examples includes HTTP, FTP, Gopher, File and News.
  • the resource name is the complete address to the resource. The format of the resource name depends on the protocol.
  • the resource name includes a host name, a file name, a port number (optional) and a reference (optional).
  • the host name is the name of the machine on which the resource resides.
  • the file name is the path name to the file on the machine.
  • the port number is the number of the port to which to connect.
  • a reference is a named anchor within a resource that usually identifies a specific location within a file.
  • the string “http” is the protocol identifier.
  • the string “www.oblix.com” is the host name.
  • the string “/oblix/sales/index.html” is the file name.
  • a complete path, or a cropped portion thereof, is called a URL prefix.
  • the string “/oblix/sales/index.html” is a URL prefix and the string “/oblix” is also a URL prefix.
  • the portion of the URL to the right of the host name and to the left of a query string (e.g. to the left of a question mark, if there is a query string) is called the absolute path.
  • “/oblix/sales/index.html” is the absolute path.
  • a URL can also include query data, which is typically information following a question mark. For example, in the URL:
  • FIG. 1 shows Web Server 18 including Web Gate 28 , which is a software module.
  • Web Gate 28 is a plug-in to Web Server 18 .
  • Web Gate 28 communicates with Access Server 34 .
  • Access Server 34 communicates with Directory Server 36 .
  • Administration Server 20 is a web-enabled server. In one embodiment, Administration Server 20 includes Web Gate 30 . Other embodiments of Administration Server 20 do not include Web Gate 30 . Administration Server 20 also includes other software modules, including User Manager 38 , Access Manager 40 , and System Console 42 . Directory Server 36 is in communication with User Manager 38 , Access Manager 40 , System Console 42 , and Access Server 34 . Access Manager 40 is also in communication with Access Server 34 .
  • the system of FIG. 1 is scalable in that there can be many Web Servers (with Web Gates), many Access Servers, and multiple Administration Servers.
  • Directory Server 36 is an LDAP Directory Server and communicates with other servers/modules using LDAP over SSL.
  • Directory Server 36 can implement other protocols or can be other types of data repositories.
  • the Access Management System includes Access Server 34 , Web Gate 28 , Web Gate 30 (if enabled), and Access Manager 40 .
  • Access Server 34 provides authentication, authorization, and auditing (logging) services. It further provides for identity profiles to be used across multiple domains and Web Servers from a single web-based authentication (sign-on).
  • Web Gate 28 acts as an interface between Web Server 18 and Access Server 34 .
  • Web Gate 28 intercepts requests from users for resources 22 and 24 , and authorizes them via Access Server 34 .
  • Access Server 34 is able to provide centralized authentication, authorization, and auditing services for resources hosted on or available to Web Server 18 and other Web Servers.
  • Access Manager 40 allows administrators access to manage multiple resources across an enterprise and to delegate policy administration to the persons closest to specific business applications and content. In one embodiment, administrators perform these tasks using an intuitive graphical user interface (“GUI”).
  • GUI graphical user interface
  • User Manager 38 provides a user interface for administrators to use, establish and/or manage identity profiles.
  • An identity profile (also called a user profile or user identity profile) is a set of information associated with a particular user.
  • the data elements of the identity profile are called attributes.
  • an attribute may include a name, value and access criteria.
  • an identity profile stores the following attributes: first name, middle name, last name, title, email address, telephone number, fax number, mobile telephone number, pager number, pager email address, identification of work facility, building number, floor number, mailing address, room number, mail stop, manager, direct reports, administrator, organization that the user works for, department number, department URL, skills, projects currently working on, past projects, home telephone, home address, birthday, previous employers and anything else desired to be stored by an administrator. Other information can also be stored. In other embodiments, less or more than the above-listed information is stored.
  • System Console 42 provides a GUI for administrators to perform various tasks such as managing Administration roles, managing various system wide settings, and configuring the Identity and Access Management Systems.
  • System Console 42 can be used to manage groups (optional) and departing users, reclaim unused resources, manage logging, configure parameters for authentication, configure parameters for authorization, and so on. Additionally, System Console 42 can be used to configure user schemes and control access to certain Identity Management System capabilities (such as “new user,” “deactivate user,” “workflow,” and so on).
  • the system of FIG. 1 is used to protect a web site, network, Intranet, Extranet, etc.
  • a web site or other structure
  • end users cause their browsers to send a request to a Web Server.
  • the request is usually an HTTP request which includes a URL.
  • the Web Server then translates, or maps, the URL into a file system's name space and locates the matching resource.
  • the resource is then returned to the browser.
  • Web Server 18 (enabled by Web Gate 28 , Access Server 34 , and Directory Server 36 ) can make informed decisions based on default and/or specific rules about whether to return requested resources to an end user.
  • the rules are evaluated based on the end user's profile, which is managed by the Identity Management System.
  • the general method proceeds as follows. An end user enters a URL or an identification of a requested resource residing in a protected policy domain. The user's browser sends the URL as part of an HTTP request to Web Server 18 .
  • Web Gate 28 intercepts the request. If the end user has not already been authenticated, Web Gate 28 causes Web Server 18 to issue a challenge to the browser for log-on information.
  • the received log-on information is then passed back to Web Server 18 and on to Web Gate 28 .
  • Web Gate 28 makes an authentication request to Access Server 34 , which determines whether the user's supplied log-on information is authentic or not.
  • Access Server 34 performs the authentication by accessing attributes of the user's profile and the resource's authentication criteria stored on Directory Server 36 . If the user's supplied log-on information satisfies the authentication criteria, the process flows as described below; otherwise, the end user is notified that access to the requested resource is denied and the process halts.
  • Web Gate 28 queries Access Server 34 about whether the user is authorized to access the resource requested.
  • Access Server 34 in turn queries Directory Server 36 for the appropriate authorization criteria for the requested resource.
  • Access Server 34 retrieves the authorization criteria for the resource and, based on that authorization criteria, Access Server 34 answers Web Gate 28 's authorization query. If the user is authorized, the user is granted access to the resource; otherwise, the user's request is denied.
  • Various alternatives to the above described flow are also within the spirit and scope of the present invention.
  • the system of FIG. 1 includes means for providing and managing identity profiles, and means for defining and managing authentication and authorization policies.
  • user identity and authentication/authorization information is administered through delegable Administration roles. Certain users are assigned to Administration roles, thus conferring to them the rights and responsibilities of managing policy and/or user identities in specific portions of the directory and web name spaces.
  • delegable Administration roles Certain users are assigned to Administration roles, thus conferring to them the rights and responsibilities of managing policy and/or user identities in specific portions of the directory and web name spaces.
  • the capability to delegate Administration duties enables a site to scale administratively by empowering those closest to the sources of policy and user information with the ability to manage that information.
  • a role is a function or position performed by a person in an organization.
  • An administrator is one type of role. In one embodiment, there are at least five different types of administrators: System Administrator, Master Access Administrator, Delegated Access Administrator, Master Identity Administrator, and Delegated Identity Administrator.
  • System Administrator serves as a super user and is authorized to configure the system deployment itself and can manage any aspect of the system.
  • a Master Access Administrator is assigned by the system administrator and is authorized to configure the Access Management System.
  • the Master Access Administrator can define and configure Web Gates, Access Servers, authentication parameters, and policy domains.
  • Master Access Administrators can assign individuals to Delegated Access Administrator roles.
  • a Delegated Access Administrator is authorized to create, delete and/or update policies within their assigned policy domain (described below), and create new policy domains subordinate to their assigned policy domains.
  • a Delegated Access Administrator may also confer these rights to others.
  • a Master Identity Administrator assigned by the System Administrator, is authorized to configure the Identity Management System, including defining and configuring end user identities and attributes, per attribute access control, who may perform new user and deactivate (revocation) user functions. Master Identity Administrators may also designate individuals to Delegate Identity Administrator roles.
  • a Delegated Identity Administrator is selectively authorized to perform new user and deactivate user functions.
  • a policy domain is a logical grouping of Web Server host ID's, host names, URL prefixes, and rules. Host names and URL prefixes specify the course-grain portion of the web name space a given policy domain protects. Rules specify the conditions in which access to requested resources is allowed or denied, and to which end users these conditions apply. Policy domains contain two levels of rules: first level default rules and second level rules contained in policies. First level default rules apply to any resource in a policy domain not associated with a policy.
  • a policy is a grouping of a URL pattern, resource type, operation type (such as a request method), and policy rules. These policy rules are the second level rules described above. There are two levels of rules available (first and second levels) for authentication, authorization, and auditing. Policies are always attached to a policy domain and specify the fine-grain portion of a web name space that a policy protects. In practice, the host names and URL prefixes from the policy domain the policy belongs to are logically concatenated with the policy's URL pattern and the resulting overall patterns compared to the incoming URL. If there is a match, then the policy's various rules are evaluated to determine whether the request should be allowed or denied; if there is not a match, then default policy domain rules are used.
  • FIG. 2 illustrates a high level block diagram of a computer system which can be used for the components of the present invention.
  • the computer system of FIG. 2 includes a processor unit 50 and main memory 52 .
  • Processor unit 50 may contain a single microprocessor, or may contain a plurality of microprocessors for configuring the computer system as a multi-processor system.
  • Main memory 52 stores, in part, instructions and data for execution by processor unit 50 . If the system of the present invention is wholly or partially implemented in software, main memory 52 can store the executable code when in operation.
  • Main memory 52 may include banks of dynamic random access memory (DRAM) as well as high speed cache memory.
  • DRAM dynamic random access memory
  • the system of FIG. 2 further includes a mass storage device 54 , peripheral device(s) 56 , user input device(s) 60 , portable storage medium drive(s) 62 , a graphics subsystem 64 and an output display 66 .
  • a mass storage device 54 peripheral device(s) 56 , user input device(s) 60 , portable storage medium drive(s) 62 , a graphics subsystem 64 and an output display 66 .
  • the components shown in FIG. 1 are depicted as being connected via a single bus 68 . However, the components may be connected through one or more data transport means.
  • processor unit 50 and main memory 52 may be connected via a local microprocessor bus
  • the mass storage device 54 , peripheral device(s) 56 , portable storage medium drive(s) 62 , and graphics subsystem 64 may be connected via one or more input/output (I/O) buses.
  • I/O input/output
  • Mass storage device 54 which may be implemented with a magnetic disk drive or an optical disk drive, is a non-volatile storage device for storing data and instructions for use by processor unit 50 .
  • mass storage device 54 stores the system software for implementing the present invention for purposes of loading to main memory 52 .
  • Portable storage medium drive 62 operates in conjunction with a portable non-volatile storage medium, such as a floppy disk, to input and output data and code to and from the computer system of FIG. 2 .
  • the system software for implementing the present invention is stored on such a portable medium, and is input to the computer system via the portable storage medium drive 62 .
  • Peripheral device(s) 56 may include any type of computer support device, such as an input/output (I/O) interface, to add additional functionality to the computer system.
  • peripheral device(s) 56 may include a network interface for connecting the computer system to a network, a modem, a router, etc.
  • User input device(s) 60 provide a portion of a user interface.
  • User input device(s) 60 may include an alpha-numeric keypad for inputting alpha-numeric and other information, or a pointing device, such as a mouse, a trackball, stylus, or cursor direction keys.
  • the computer system of FIG. 2 includes graphics subsystem 64 and output display 66 .
  • Output display 66 may include a cathode ray tube (CRT) display, liquid crystal display (LCD) or other suitable display device.
  • Graphics subsystem 64 receives textual and graphical information, and processes the information for output to display 66 .
  • the system of FIG. 2 includes output devices 58 . Examples of suitable output devices include speakers, printers, network interfaces, monitors, etc.
  • the components contained in the computer system of FIG. 2 are those typically found in computer systems suitable for use with the present invention, and are intended to represent a broad category of such computer components that are well known in the art.
  • the computer system of FIG. 2 can be a personal computer, workstation, server, minicomputer, mainframe computer, or any other computing device.
  • the computer can also include different bus configurations, networked platforms, multi-processor platforms, etc.
  • Various operating systems can be used including Unix, Linux, Windows, Macintosh OS, Palm OS, and other suitable operating systems.
  • FIG. 3 is a block diagram of Directory Server 36 .
  • Directory Server 36 stores user identity profiles 102 . Each identity profile includes a set of attributes for the particular end users. Group information 104 is also stored, which describes logical relationships and groupings of users having identity profiles 102 stored on Directory Server 36 .
  • a plurality of policies 106 are also stored on Directory Server 36 .
  • Revoked user list 108 identifies users previously (but no longer) allowed access to resources on their system.
  • Shared secret(s) 110 are keys stored on Directory Server 36 used for encrypting cookies set on browsers 12 or 14 after a successful user authentication. Shared secret(s) (keys) 110 can change as often as desired by an administrator.
  • Global sequence number (GSN) 112 is a unique number stored on Directory Server 36 which is assigned to a policy domain change (first level default rules) or policy change (second level resource-specific rules) and updated in response to subsequent policy changes for cache flushing purposes. In one embodiment of the present invention, the GSN is incremented to the next sequential number after detection of a policy domain or policy change.
  • User attribute list 114 is a list of user identity profile attributes used by cached authentication and authorization rules.
  • FIG. 4 depicts an exemplar directory tree that can be stored on Directory Server 36 .
  • Each node on the tree is an entry in the directory structure.
  • Node 130 is the highest node on the tree and represents an entity responsible for the directory structure.
  • an entity may set up an Extranet and grant Extranet access to many different companies.
  • the entity setting up the Extranet is node 130 .
  • Each of the companies with Extranet access would have a node at a level below node 130 .
  • company A node 132
  • company B node 134
  • Each company may be broken up into organizations. The organizations could be departments in the company or logical groups to help manage the users. For example, FIG.
  • FIG. 4 shows company A broken up into two organizations: organization A with node 136 and organization B with node 138 .
  • Company B is shown to be broken up into two organizations: organization C with node 140 and organization D with node 142 .
  • FIG. 4 shows organization A having two end users: employee 1 with node 150 and employee 2 with node 152 .
  • Organization B is shown with two end users: employee 3 with node 154 and employee 4 with node 156 .
  • Organization C is shown with two end users: employee 5 with node 158 and employee 6 with node 160 .
  • Organization D is shown with two end users: employee 7 with node 162 and employee 8 with node 164 .
  • Each node depicted in FIG. 4 can include one or more identity profiles stored in Directory Server 36 .
  • One exemplar class pertains to entities such as entity 130 , company A (node 133 ), and company B (node 134 ).
  • a second exemplar class stores information about organizational units such as organization A (node 136 ), organization B (node 138 ), organization C (node 140 ), and organization D (node 142 ).
  • each of the organizations are departments in a company and each of the users are employees who work for that particular organization.
  • a third exemplar class is for individual persons such as employee 1 (node 150 ), employee 2 , (node 152 ), . . . employee 8 (node 164 ).
  • employee 1 node 150
  • employee 2 node 152
  • . . . employee 8 node 164
  • the directory tree is depicted as having three levels, more or less than three levels can be used.
  • a source from the Identity Management System attempts to access a target in the Identity Management System.
  • employee 1 may seek to access the profile for employee 4 (node 156 ).
  • node 150 is the source and node 156 is the target.
  • one embodiment stores access information at the target and at the highest level for targets with common access rules. In some cases, access information is stored at a higher level even if a lower level does not include common access rules.
  • FIG. 5 is a flow chart describing the process for setting up an identity profile by an administrator having authority to do so.
  • the administrator selects the object class to be used for the directory entry or entries being created. As previously described, there are at least three classes: organization, organizational unit, and user.
  • the master identity administrator selects which class is to be used for the entry. After the object class is selected in step 200 , all possible attributes for the particular class appear on a graphical user interface (GUI) (step 202 ).
  • GUI graphical user interface
  • the administrator selects one of the attributes.
  • the master identity administrator edits the access criteria for the attribute.
  • FIG. 6 is a flow chart describing step 206 of FIG. 5 , editing access criteria for an attribute.
  • the administrator selects where in the tree structure of FIG. 4 to store the access information for the particular attribute under consideration. For example, if the administrator is setting up an identity profile for employee 2 (node 152 ) of FIG. 4 , attribute access information can be stored at node 152 , node 136 , node 132 , or node 130 . In step 230 , it is determined which one of those available nodes will store the information.
  • the permissions to modify the attribute are set up using a policy.
  • a policy can identify person(s) who can modify the attribute.
  • the policy can identify a set of people by identifying a role, by identifying a rule for identifying people, by identifying one or more people directly by name, or by identifying a named group.
  • permissions are set up to determine who can view the attributes.
  • the Identity Management System policy determines which users can view identity profile attributes by defining a role, defining a rule, identifying persons by name, or listing an identified group.
  • the rule mentioned above is an LDAP rule.
  • the ability to edit the permissions are delegated to others.
  • a notify list is set up. The notify list identifies a set of zero or more persons who are notified (e.g. by email) when the attribute is modified.
  • the Identity Management System includes a localized access feature. This feature restricts certain user's access to identity profiles within a defined locale. For example, if an entity sets up an Extranet similar to the tree of FIG. 4 , and allows two of its suppliers (e.g. company A and company B) to access the Extranet, company A may not want employees from company B to access identity profiles for employees of company A.
  • a set of identity profiles can be defined as a locale. Users outside the locale can be restricted from accessing identity profiles inside the locale. Alternatively, users outside the locale can be restricted from accessing certain attributes of identity profiles inside the locale.
  • the localized access feature can be used to prevent any nodes, including node 132 and any nodes below node 132 , from accessing node 134 and any node below node 134 .
  • the localized access feature can be used at other levels of granularity and/or at other levels of the organizational hierarchy. For example, users below node 136 can be blocked from accessing profiles below node 138 , node 140 , node 142 , node 134 , etc.
  • FIG. 7 is a flow chart describing the process for configuring localized access.
  • a localized access parameter for the entire system of FIG. 1 is set. This parameter turns on the localized access function.
  • a class attribute can be set for localized access.
  • Each identity profile has a set of attributes. One of those attributes is designated as the class attribute.
  • the class attribute is used to identify the identity profile.
  • a reference to a particular identity profile is a reference (or pointer) to the class attribute for the identity profile.
  • the class attribute can be configured for localized access by setting up a localized access filter that identifies the locale. If the source of a request is in a different locale than the locale defined for the class attribute, then the source is denied access to the target.
  • multiple domain attributes can be used to define the locale. Users whose domain attributes are equal, are in the same locale. A user can be a member of multiple locales.
  • individual attributes for a profile can be configured for localized access. That is, some attributes in an identity profile can be configured for localized access, while other attributes are not. Each attribute can be provided with a localized access filter that identifies the locale for that attribute.
  • the localized access filter can include an absolute test, an LDAP test or one or more domain attributes.
  • individual attributes are not configured in step 268 if the class attribute for the profile has already been set. It is possible to configure the class attribute for localized access and not configure the other attributes for localized access. Similarly, in some embodiments it is possible to not configure the class attribute for localized access while configuring the other attributes for localized access.
  • the system when a source seeks to access a particular attribute in a target, the system first checks to see if the localized access filter for the class attribute of the target is satisfied. If it is not satisfied, then access is denied. If it is satisfied, then the system first checks to see if the localized access filter for the particular attribute of the target is satisfied. If it is or it is not configured for localized access, then access can be granted. If the localized access filter for the particular attribute of the target is not satisfied, access to the particular attribute is denied.
  • the localized access filter for the class attribute determines access to the entire identity profile, while the localized access filter for a specific attribute (other than the class attribute) determines access to the specific attribute.
  • FIG. 8 is a flow chart describing the process for accessing data in the Identity Management System.
  • the data can be accessed for viewing, modifying, etc.
  • the entity attempting to access a profile in the Identity Management System is the source and the profile being accessed is the target.
  • the source user's browser sends a request to access attributes of a target directory entry.
  • the request is received by User Manager 38 .
  • User Manager 38 accesses the target profile and the source profile on Directory Server 36 .
  • User Manager 38 based on the attribute settings created or modified by the process of FIG. 5 and (possibly) the source profile, determines whether the source should have access to each of the different attributes of the target profile. This step is discussed in further detail below.
  • User Manager 38 passes the information for the attributes that access is allowed for to the source's browser.
  • the attributes that the source may view are displayed on the source's browser.
  • FIG. 9 is a flow chart describing the process of step 296 of FIG. 8 , determining whether the source should have access to the various attributes of the target.
  • the system determines whether a localized access violation for the class attribute has occurred. A localized access violation is found when the target's class attribute is configured for localized access and the source is not in the locale for the target. If there is a localized access violation, the method of FIG. 9 is done (step 344 ) and none of the attributes for the target may be accessed by the source. For example, if the source is employee 1 (node 150 of FIG. 4 ), the target is employee 8 (node 164 of FIG. 4 ), and all of company B is subject to localized access with a domain attribute set as “company” (in one embodiment the actual syntax is % company %) a localized access violation will be found in step 320 .
  • step 320 If no localized access violation is found in step 320 , then one of the attributes for the target is selected in step 322 and User Manager 38 determines whether the access information for that selected attribute is at the current level in the tree.
  • the first time step 324 is performed the current level in the tree is the level of the target. As previously explained, access information can be stored at the target's node or nodes above the target. If the access information is not found at the current level, then in step 340 , it is determined whether the system is inquiring at the top level of the directory structure (e.g. node 130 of FIG. 4 ). If the system is at the top level, then the system determines whether all attributes have been evaluated in step 332 . If all attributes have been evaluated, then the process of FIG.
  • the top level of the directory structure e.g. node 130 of FIG. 4
  • step 9 is done (step 348 ). If all attributes have not been evaluated, then the system accesses the initial level again in step 334 and loops back to step 322 . If in step 340 , it is determined that the system is not at the top level, then the system moves up one level (step 342 ) and loops back to step 324 .
  • step 324 if the access information for the attribute is at the current level being considered, then in step 326 it is determined whether there is a local access violation for the attribute under consideration. If the particular attribute being considered was configured for localized access and the source is not in the relevant locale for the target, then a localized access violation occurs and the method of FIG. 9 is done (step 346 ). It will be appreciated that localized access can apply to entire profiles or only certain portions (certain attributes) of profiles. If the attribute under consideration was not configured for localized access, then there is no localized access violation for the attribute under consideration. If there is no localized access violation for the attribute under consideration, then the identity profile for the source is applied to any additional access criteria to see whether the source should have access to the target's attribute.
  • step 330 access is granted in step 330 and the method loops to step 332 .
  • a source will be granted access to zero or more attributes.
  • Step 300 of FIG. 8 displays only those attributes for which the source has been granted access.
  • FIG. 10 is a flow chart describing the process of step 320 in FIG. 9 , determining whether a localized access violation has occurred for a class attribute.
  • the Identity Management System determines whether the localized access parameter is set. If not, there is no localized access violation. If so, then in step 364 , the system determines whether a class attribute is configured for localized access. If the class attribute is not configured for localized access, there is no local access violation (step 362 ). If the class attribute is configured for localized access, then in step 366 it is determined whether the localized access filter is satisfied (e.g. does the domain attribute for the target must match the domain attribute for the source?). If the localized access filter is satisfied, no localized access violation occurs (step 362 ). If the localized access filter is not satisfied, then a localized access violation exists and access should be denied (step 368 ).
  • the localized access filter is satisfied (e.g. does the domain attribute for the target must match the domain attribute for the source?).
  • FIG. 11 is a flow chart describing the process performed in step 326 of FIG. 9 , determining whether there is a localized access violation for a particular attribute.
  • step 380 it is determined whether a localized access parameter is set. If not, there is no localized access violation (step 382 ). Otherwise, in step 384 , it is determined whether the particular attribute is configured for localized access. If the particular attribute is not configured for localized access, then there is no localized access violation (step 382 ). If the particular attribute is configured for localized access, then in step 386 it is determined whether the localized access filter for the attribute under consideration is satisfied. If the localized access filter is satisfied, then there is no localized access violation (step 382 ). If the localized access filter is not satisfied, then there is a localized access violation and access should be denied (step 388 ).
  • FIG. 12 is a flow chart describing the process of how a source user can modify an attribute of a target profile.
  • the source user attempts to modify an attribute.
  • the source user is provided a GUI which depicts the directory tree.
  • the source user can select any node in the directory tree and click on a button to modify a target profile.
  • the source user can type in a URL, distinguished name, or other identifying information for the target.
  • the user selects a particular attribute and attempts to modify it by selecting a modify button on the GUI. This request to modify is sent to User Manager 38 .
  • User Manager 38 searches for the modify criteria for the attribute in the target directory.
  • This modify criteria is the information set up in step 232 of FIG. 6 .
  • User Manager 38 searches in the current target directory. If the criteria is not found in the current directory being accessed (see step 414 ), then it is determined whether the system is at the top of the directory tree structure (step 416 ). If not, then the system moves up one level in step 418 . If the top of the directory structure is reached, then the source user is not allowed to modify the attribute (step 420 ). In step 422 , User Manager 38 searches for the modify criteria in a new directory. After step 422 , the method loops back to step 414 .
  • step 414 If in step 414 , it is determined that the criteria was found at the current level being considered, then in step 430 , the User Manager evaluates the criteria against the target user's identity profile. If the identity profile for the target user satisfies the criteria for modifying the attribute (step 432 ) then the source user is allowed to modify the attribute (step 434 ). Otherwise, the source user is not allowed to modify the attribute (step 420 ).
  • FIG. 13 is a flow chart describing a process for automating the updating of identity profiles when a source user requesting the update is not allowed to modify the target profile.
  • the source user is the person identified by the target profile.
  • the source user requests modification of the target profile. This can be a request to modify any or all of the attributes for the target profile (e.g. address, telephone number, creation of the profile, deletion of the profile, etc.).
  • the User Manager 38 issues an electronic message (“ticket”) sent to a responsible party requesting that the modification be made.
  • the responsible party is a person granted access to modify a particular attribute and has the responsibility for doing so.
  • the ticket appears in a service queue accessible by the responsible party.
  • the service queue can be a directory which stores all tickets or can be any database which is used to store the tickets.
  • the responsible party may access a GUI which indicates all tickets in the service queue, the date they were received, and what service is requested.
  • the requesting source user can view whether a ticket has been serviced.
  • the ticket is fully serviced, partially serviced or denied by the responsible party.
  • the target will be modified. However, the target will not be modified if the ticket is denied.
  • the ticket is removed from the service queue in step 464 .
  • the source is automatically notified that the ticket is removed from the service queue and notified of the result of the request.
  • FIG. 14 provides a block diagram of Web Gate 28 .
  • Web Gate 28 is a Web Server plug-in running on Web Server 18 .
  • Web Gate 28 is an NSAPI Web Server plug-in.
  • Web Gate 28 is an ISAPI Web Server plug-in.
  • Web Gate 28 is an Apache Web Server plug-in.
  • a plurality of Web Gates conforming to different plug-in formats are distributed among multiple Web Servers.
  • Resource cache 502 caches authentication information for individual resources.
  • the information stored in resource cache 502 includes: request method, URL, retainer 505 , and audit mask 503 .
  • audit mask 503 is a four bit data structure with separate bits identifying whether authentication and/or authorization successes and/or failures are audited (logged) for a given resource.
  • Authentication scheme cache 506 stores authentication scheme information, including information necessary for the performance of each different authentication challenge scheme. For example, if the authentication scheme ID parameter of a resource cache 502 entry references a “client certificate” authentication scheme, then the authentication scheme ID parameter of the entry would reference an authentication scheme cache 506 entry (keyed by the authentication challenge method ID). In one embodiment, authentication scheme cache stores redirect URL, authentication challenge method ID (identifying an authentication challenge method), challenge parameters for authentication and authentication level. Web Gate 28 also stores the most recent global sequence number 510 received from Access Server 34 pursuant to a cache flushing operation, as further described below.
  • Event manager 514 calls redirection event handler 504 , resource protected event handler 508 , authentication event handler 512 , or authorization event handler 516 to perform redirection, a resource protected method, an authentication method, or an authorization method (all further described herein), respectively.
  • Redirection event handler 504 redirects browser 12 or 14 in response to redirection events initiated by Access Server 34 or other components of Web Gate 28 .
  • Resource protected event handler 508 performs steps in a method for determining whether a requested resource falls protected within a policy domain.
  • Authentication event handler 512 performs steps in a method for authenticating a user of browser 12 or 14 upon a finding that a requested resource is protected.
  • Authorization event handler 516 performs steps in a method for determining whether a user of browser 12 or 14 is authorized to access a requested resource upon a successful authentication or receipt of a valid authentication cookie, further described herein.
  • Sync record table 518 identifies all existing synchronization records not yet processed by Web Gate 28 as further described herein.
  • FIG. 15 provides a block diagram of Access Server 34 .
  • Authentication module 540 is provided for carrying out steps in a method for authenticating a user as further described herein.
  • Authorization module 542 is provided for carrying out steps in a method for authorizing a user to access a requested resource as further described herein.
  • Auditing module 544 carries out steps in a method for auditing (logging) successful and/or unsuccessful authentications and/or authorizations as further described herein.
  • Audit logs 546 store information logged by auditing module 544 in accordance with the present invention.
  • Audit logs sensors 548 include one or more sensors that monitor the audit logs for certain types of events.
  • Synchronization records 550 are stored on Access Server 34 in accordance with a method for flushing caches as further described herein.
  • Access Server 34 stores the most recent global sequence number 554 received from Access Manager 40 pursuant to a cache flushing operation.
  • URL prefix cache 564 stores the URL prefixes associated with policy domains that are protected by the Access Management System. URL prefix cache 564 facilitates the mapping of requested resources to policy domains, as further described herein. URL prefix cache 564 is loaded from Directory Server 36 upon initialization of Access Server 34 .
  • Policy domain cache 566 caches all default authentication rules of each policy domain in accordance with the present invention. Policy domain cache further stores an array of rules 565 listing all default and resource-specific rules associated with resources in a given policy domain. Each rule entry in array 565 includes the ID of the rule and compiled information about the URL pattern (resource) to which the rule applies. Array 565 enables Access Server 34 to quickly find the first level default authentication, authorization, and auditing rules for a given policy domain, as well as second level rules (authentication, authorization, and auditing rules) associated with particular policies in the policy domain.
  • Authentication scheme cache 568 caches information necessary for the performance of different authentication challenge methods as similarly described above for authentication scheme cache 506 of Web Gate 28 .
  • Authentication rule cache 570 caches second level authentication rules associated with policies. The rules in authentication rule cache 570 are listed in array 565 . Upon determining that a second level authentication rule exists and learning its ID (by looking in array 565 ), Access Server 34 can easily find the second level authentication rule in authentication rule cache 570 .
  • the second level rules are the rules associated with policies, discussed above.
  • Authorization rule cache 572 caches first level default authorization rules as well as second level authorization rules. The rules in authorization rule cache 572 are listed in array 565 . Upon determining that a first or second level authorization rule exists and learning its ID (by looking in array 565 ), Access Server 34 can easily find the applicable authorization rule for a given resource in authorization rule cache 572 .
  • Audit rule cache 574 caches first level default audit rules as well as second level audit rules. The rules in audit rule cache 574 are listed in array 565 . Upon determining that a first or second level audit rule exists and learning its ID (by looking in array 565 ), Access Server 34 can easily find the applicable audit rule for a given resource in audit rule cache 574 .
  • User profile cache 576 stores identity profile attributes previously used in authentications, authorization, or audit steps, in accordance with the present invention.
  • User policy cache 578 stores the successful and unsuccessful authorization results for specific users requesting specific resources governed by authorization rules based on an LDAP filter or a group membership.
  • User policy cache 578 allows Access Server 34 to quickly recall a user's authorization if the user has recently accessed the resource.
  • FIG. 16 is a flow chart which describes the process of creating a policy domain.
  • System Console 42 or Access Manager 40 receives a request to create a policy domain.
  • the name of the policy domain and the description of the policy name are stored.
  • one or more URL prefixes are added to the policy domain.
  • one or more host ID's are added to the policy domain (optional).
  • one or more access rules are added to the policy domain.
  • An access rule is a rule about accessing a resource. Examples of access rules include authorization rules, authentication rules, auditing rules, and other rules which are used during the process or attempting to access a resource.
  • a first level (default) authentication rule is added to the policy domain.
  • authentication is the process of verifying the identity of the user.
  • Authentication rules specify the challenge method by which end users requesting access to a resource in the policy domain must prove their identity (authentication).
  • first level (default) authentication rules apply to all resources in a policy domain
  • second level authentication rules are associated with policies that apply to subsets of resources or specific resources in the policy domain.
  • one or more first level or default authorization rules are added to the policy domain in step 608 .
  • an authorization rule determines who can access a resource. The default authorization rule allows or denies users access to resources within its applicable policy domain. If multiple authorization rules are created, then they are evaluated in an order specified in step 610 .
  • a first level (default) audit rule is configured for the policy domain.
  • zero or more policies are added to the policy domain.
  • the data for the policy domain is stored in Directory Server 36 and appropriate caches (optional) are updated.
  • an authorization rule or an authentication rule can be set up to take no action. That is, always grant authentication without any challenge or verification; or always grant authorization without any verification.
  • FIG. 17 is a flow chart describing the process of adding one or more authorization rules to a policy domain (step 608 of FIG. 16 ).
  • timing conditions are set up for the authorization rule. Timing conditions restrict the time when the authorization rule is in effect. For example, users can be allowed access to URLs in the policy domain only during business hours, Monday through Friday. In one embodiment, if timing conditions are not set, the authorization rule is always in effect.
  • the timing conditions include selecting a start date, an end date, selecting a start time and an end time, selecting the months of the year, selecting the days of the month, and selecting the days of the week that the rule is valid.
  • authorization actions are set up. Authorization actions personalize the end user's interaction with the Web Server.
  • header variables are provided for authorization success events and authorization failure events. This feature allows for the passing of header variables about the end user (or other information) to other web-enabled resources. Web-enabled applications can personalize the end user's interaction with the Web Server using these header variables. As a simple example, the actions could supply each application with the user's name. An application could then greet the user with the message “hello ⁇ user's name>” whenever the user logs on. Header variables are variables that are part of an HTTP request. FIG. 40 below illustrates the format of an HTTP request that includes header variables 1554 . If an authorization rule is set up with header variables as part of an authorization success action, then when a successful authorization occurs the HTTP request to the resource will include the header variables.
  • an authorization failure event will include adding header variables to the HTTP request that redirects a browser to an authorization failure web page.
  • the resources identified by the HTTP requests, that include the header variables can use the header variables any way desired.
  • one or more groups can be specified for authorization to the resource(s).
  • FIG. 18 is a flow chart that describes the process of adding header variables to an HTTP request (see step 634 of FIG. 17 ).
  • Header variables can be added during an authorization success event, authorization failure event, authentication success event or authentication failure event.
  • the variable name is entered.
  • a text string is entered.
  • one or more LDAP attributes are entered.
  • the variable name entered in step 650 is a value that appears in the HTTP header that names the variable.
  • the downstream resource using the header variable will search for the variable name.
  • the string entered is data that can be used by the downstream resource.
  • the LDAP attribute(s) can be one or more attributes from the requesting user's identity profile.
  • the variable name field can include “authorization success,” the return field can include “yes,” and the attribute field can include the name attribute for the user in the user's identity profile. Any of the attributes from the user's identity profile can be selected as a header variable.
  • a redirect URL can be added for an authorization success event and a redirect URL can be entered for an authorization failure event.
  • Step 638 includes specifying which users are allowed to access the resource associated with the authorization rule. By default, users cannot access a resource until they are granted access rights to it.
  • there are at least four means for specifying who can access a resource The first means is to explicitly name a set of users who can access the resource.
  • a second means includes identifying user roles.
  • the third means is to enter an LDAP rule that can be used to identify a set of users based on a combination of one or more attributes.
  • a fourth means is to enter an IP address which will allow users of computers having the specified IP address to access the resource.
  • Step 640 is used to specify the users not allowed to access the resource associated with this rule. Identification of users, roles, LDAP rules, and IP addresses are entered in step 640 in the same manner as entered in step 638 . It is possible that a particular user can be subject to both an allow access rule and a deny access rule. Step 642 is used to set a priority between such rules.
  • Optional step 644 is used to define any POST data to be used for authorization if this feature is implemented.
  • An HTTP POST request can include POST data in the body of the HTTP request (see FIG. 40 below). POST data can also be submitted in query string form.
  • POST data can also be submitted in query string form.
  • an administrator defines which POST data is to be used for authorization purposes.
  • Step 646 is used to set a priority of evaluation for the authorization rule relative to other authorization rules in a given policy. In one embodiment, if multiple authorization rules apply to a resource, this priority determines the order of evaluation.
  • FIG. 19 is a flow chart describing the process for adding an authentication rule (see step 606 of FIG. 16 ).
  • a challenge scheme also called an authentication scheme
  • An authentication scheme is a method for requesting log-on information (e.g. name and password) from end users trying to access a web resource.
  • a challenge method e.g. Basic, certificate or form.
  • There can be more than one authentication scheme with the same challenge method e.g. Basic over LDAP, Basic over NT Domain, . . .
  • Various other authentication schemes can also be used.
  • header variables are added for authentication success and authentication failure events.
  • redirect URLs are added for authentication success events and authentication failure events.
  • FIG. 20 provides a flow chart depicting the process for configuring an audit rule (see step 612 of FIG. 16 ).
  • the events to trigger an audit are selected.
  • authentication success, authentication failure, authorization success and authorization failure can be selected for auditing.
  • the information to be logged is selected for each particular event identified in step 680 .
  • the information logged can include information about the event and/or user attributes from the identity profile for the user requesting the authentication or authorization.
  • FIG. 21 is a flow chart describing the process of adding a policy (see step 614 of FIG. 16 ).
  • a resource type is specified.
  • the resource type allows different resources to be handled by different policies, depending on the nature of the resource itself. For example, in one embodiment, the resource type will distinguish between resources accessed using HTTP and resources accessed using FTP. In another embodiment, Enterprise Java Beans (EJBs) are a possible resource type. In another embodiment, user-defined custom resource types are supported.
  • EJBs Enterprise Java Beans
  • user-defined custom resource types are supported.
  • an operation type is specified. This allows different resources to be handled by different policies, depending on the operations used to request the resource. In one embodiment, the operations will be HTTP requests.
  • Supported HTTP request methods include GET, POST, PUT, HEAD, DELETE, TRACE, OPTIONS, CONNECT, and OTHER.
  • EJBs are identified as the resource type (step 718 )
  • an EXECUTE operation can be specified in step 720 .
  • user-defined custom operations are supported.
  • Other and future operations can also be supported.
  • step 722 a pattern for the URL path to which the policy applies is specified. This is the part of URL that does not include the scheme (“http”) and host/domain (“www.oblix.com”), and appears before a ‘?’ character in the URL.
  • a query string is specified.
  • the values after the question mark comprise a query string. Only a URL exhibiting the query string can match to this policy. For example, a URL with the “tigers” variable appearing before the “uid” variable will not match the above-identified policy.
  • query string variables are added.
  • Query string variables include a name of a variable and the variable's corresponding value.
  • Query string variables are used when it is a desirable that multiple variables are found in the query string, but the order is unimportant.
  • a URL with a query string having the appropriate uid and appropriate tigers variable, in any order will match the policy.
  • the path of the requested resource URL must match the path of the policy as well as any query string or query variables.
  • POST data can be submitted in query string form (for example, in a form submission), and evaluated using the query string variables entered in step 726 .
  • the query string or query variables specified in the steps of FIG. 21 do not need to uniquely identify a resource. Rather, they are used to identify a policy, which may apply to one or more resources.
  • the query data is added to a URL to access certain data from a resource.
  • the query data can be used in the URL to identify the resource.
  • Each application or resource is free to use the query data in any way that is in agreement with standards and norms known in the art.
  • step 728 of FIG. 21 the authentication rule is created in accordance with the method of FIG. 19 .
  • step 730 one or more authorization rules are created for the policy in accordance with the method of FIG. 17 .
  • an audit rule for the policy is configured in accordance with the method of FIG. 20 .
  • step 734 POST data (optional) is added to the policy. This POST data is used to map resources with policies.
  • An authentication scheme comprises an authentication level, a challenge method, an SSL assertion parameter, a challenge redirect parameter, and authentication plug-ins.
  • the authentication level represents an arbitrary designation of the level of confidence that an administrator has in a particular authentication scheme relative to other authentication schemes.
  • an authentication scheme can specify one of four challenge methods: none, basic, form, and X.509. If an authentication scheme's challenge method is set to “none,” no authentication is required to access a requested resource, thus allowing support for unauthenticated users.
  • This challenge method can be used over both unsecured as well as SSL connections.
  • the “basic” challenge method can also be used over both unsecured and SSL connections.
  • the “X.509” challenge method can only be used over an SSL connection between a user's browser and Web Server host, because the authentication method invoked for an X509 challenge method is part of the SSL protocol.
  • a “form” challenge method employs a custom, site-specific HTML form presented to the user, who enters information and submits the form. Subsequent processing is determined by the administrator at the time the authentication scheme is created. Form challenge methods can be used over both unsecured and SSL connections.
  • the SSL parameter of an authentication scheme identifies whether SSL is to be asserted on the connection to the user's browser by the Web Server.
  • the challenge parameter identifies where to redirect a request for authentication for the particular authentication scheme.
  • Authentication plug-ins are necessary for processing the user's supplied information. Authentication plug-ins can interface with Access Server 34 through an authentication API.
  • an authentication scheme that an attacker can easily and profitability eavesdrop upon is typically considered “weak.”
  • the basic authentication challenge method places the user's credential (supplied information), a simple password, “in the clear” over an unsecured network connection.
  • the authentication scheme can be made stronger by passing the user's credential over an encrypted connection, such as SSL.
  • an access administrator given two authentication schemes (one with and one without SSL), an access administrator will assign the authentication scheme without SSL to a lower authentication level than the authentication using SSL.
  • a user When a user first request a protected resource, the user is challenged according to the authentication scheme defined by the first level authentication rule in the applicable policy domain or the second level authentication rule in the applicable policy associated with the requested resource. If the user satisfies the authentication rule, an encrypted authentication cookie is passed to the user's browser indicating a successful authentication.
  • the user may request a second resource protected by a different policy domain and/or policy with a different authentication rule. The user will be allowed access to the second resource without re-authenticating if the authentication level of the authentication scheme used to successfully authenticate for the first resource is equal to or greater than the authentication level of the authentication scheme of the second resource.
  • the user is challenged and asked to re-authenticate for the second resource in accordance with the second resource's higher level authentication scheme. Satisfaction of a higher or lower authentication level is determined by evaluating the authentication cookie sent by the user's browser when requesting the second resource. In one embodiment of the present invention, administrators can define an unlimited number of authentication levels.
  • Authentication cookies can also be set by an administrator to be destroyed after a maximum idle time has elapsed between requests to resources protected in accordance with the present invention.
  • FIG. 22 provides a flow chart for one embodiment of a method for authenticating, authorizing, and logging.
  • a user's browser 12 requests a web-enabled resource 22 or 24 .
  • the request is intercepted by Web Gate 28 in step 752 .
  • the method determines whether the requested resource is protected by an authentication and/or authorization rule in step 753 . If the resource is not protected, then access is granted to the requested resource in step 795 . If the requested resource is protected however, the method proceeds to step 754 . If the user has previously authenticated for a protected resource in the same domain, a valid authentication cookie will be passed by browser 12 with the request in step 750 and intercepted by Web Gate in step 752 . If a valid cookie is received (step 754 ), the method attempts to authorize the user in step 756 . If no valid authorization cookie is received (step 754 ), the method attempts to authenticate the user for the requested resource (step 760 ).
  • step 762 If the user successfully authenticates for the requested resource (step 762 ), then the method proceeds to step 774 . Otherwise, the unsuccessful authentication is logged in step 764 . After step 764 , the system then performs authentication failure actions and Web Gate 28 denies the user access to the requested resource in step 766 . In step 774 , the successful authentication of the user for the resource is logged. The method then performs authentication success actions in step 766 . In response to the successful authentication, Web Gate 28 then passes a valid authentication cookie to browser 12 in step 780 which is stored by browser 12 . After passing the cookie in step 780 , the system attempts to authorize in step 756 .
  • step 756 the method attempts to determine whether the user is authorized to access the requested resource. If the user is authorized (step 790 ), the method proceeds to step 792 . Otherwise, the unsuccessful authorization is logged in step 796 . After step 796 , the method performs authorization failure actions (step 798 ) and Web Gate 28 denies the user access to the requested resource. If authorization is successful (step 790 ), then the successful authorization of the user is logged in step 792 , authorization success actions are performed in step 794 , and the user is granted access to the requested resource in step 795 . In one embodiment of step 795 , some or all of HTTP request information is provided to the resource.
  • FIG. 23 provides a flow chart of a method for determining whether a requested resource is protected (see step 753 of FIG. 22 ).
  • the steps of FIG. 23 are performed by resource protected event handler 508 and Access Server 34 .
  • Web Gate 28 determines whether an entry for the requested resource is found in resource cache 502 . If an entry is found, the cache entry is examined in step 842 to determine whether the cache entry indicates that the resource is protected (step 832 ) or unprotected (step 840 ). If an entry for the requested resource is not found in resource cache 502 , then Web Gate 28 passes the URL of the requested resource request method to Access Server 34 in step 833 . Access Server 34 attempts to map the requested resource to a policy domain using URL prefix cache 564 (step 836 ).
  • mapping step 836 is unsuccessful (step 838 ), then the requested resource is deemed to be unprotected (step 840 ). However, if a successful mapping has occurred (step 838 ), then Access Server 34 retrieves the authentication rule (step 844 ) and audit rule (step 846 ) associated with the requested resource. Access Server 34 then passes the authentication scheme ID from the authentication rule, audit mask 503 , retainer 505 and any POST data received to Web Gate 28 in step 848 . Web Gate 28 caches the authentication scheme ID from the authentication rule, audit mask 503 , retainer 505 and POST data in resource cache 502 (step 850 ). Since the requested resource was successfully mapped to a policy domain in step 836 , the resource is deemed protected (step 832 ).
  • FIG. 24 is a flow chart describing the process for mapping a resource to a policy domain (see step 836 of FIG. 23 ).
  • Access Server 34 receives the URL of the requested resource from Web Gate 28 .
  • Access Server 34 compares a URL prefix of the requested resource with entries in URL prefix cache 564 in step 902 .
  • the URL prefix of the requested resource equals the file name.
  • step 902 the URL prefix first compared by step 902 will be: “/oblix/sales/index.html.” If a matching URL prefix is found (step 904 ), Access Server 34 proceeds to step 916 .
  • Access Server 34 determines whether the policy domain associated with the matching URL prefix calls for one or more host ID's.
  • resources are mapped to certain policy domains if the port number of a resource request and the location of the resource itself conform to one or more host ID's.
  • multiple policy domains can be associated with identical URL prefixes, each policy domain requiring different host ID's (or none at all). If the policy domain considered in step 916 requires a matching host ID, then Access Server 34 proceeds to step 917 . Otherwise, Access Server 34 proceeds directly to step 906 where the requested resource is mapped to the policy domain associated with the currently considered URL prefix.
  • step 917 if a matching host ID is found, Access Server 34 proceeds to step 906 . If no matching host ID is found, Access Server 34 returns to step 904 where it determines whether additional matching URL prefixes exist.
  • Access Server 34 proceeds to step 908 .
  • step 908 Access Server 34 crops the right-most term from the resource URL prefix compared in step 902 .
  • the resource URL prefix compared in step 902 reads: “/oblix/sales/index.html” then the resource URL prefix will be cropped in step 908 to read: “/oblix/sales.”
  • the method proceeds to step 912 where Access Server 34 concludes that there is no policy domain associated with the requested resource. However, if one or more additional terms remain in the resource URL prefix, then the method returns to step 902 where the cropped URL prefix is compared with URL prefixes cached in URL prefix cache 564 .
  • the method recursively performs steps 902 , 904 , 908 , and 910 until either a match is found (step 904 ) or the entire resource URL prefix has been cropped (step 910 ).
  • the method of FIG. 24 will inevitably return either a successful mapping (step 906 ) or no mapping (step 912 ).
  • FIG. 25 provides a flow chart describing a method for loading an authentication rule (see step 844 of FIG. 23 ).
  • Access Server 34 loads the first level (default) authentication rule for the policy domain mapped in step 836 of FIG. 23 from Directory Server 36 into authentication rule cache 570 .
  • success and failure actions are part of all authentication and authorization rules.
  • Access Manager 40 maintains a user attribute list 114 on Directory Server 36 .
  • User attribute list 114 identifies all user attributes used by authentication and authorization actions loaded into authentication rule cache 570 and authorization rule cache 572 .
  • Access Server 34 also builds array 565 (previously described above) and loads it into policy domain cache 566 .
  • Array 565 includes all second level rules and patterns associated with each of the policies for the policy domain. Access Server 34 then selects a second level rule in array 565 (step 931 ). The selected second level rule is part of a policy. In step 932 , Access Server 34 performs a pattern matching method (further described below) for determining whether the rule applies to the requested resource. If so, then Access Server 34 proceeds to step 935 ; otherwise, Access Server 34 determines whether all rules in array 565 have been evaluated (step 933 ). If, in step 933 , it is determined that not all of the rules in the array have been evaluated, then Access Server 34 selects the next rule in array 565 (step 934 ) and returns to step 932 .
  • a pattern matching method further described below
  • step 933 the first level authentication rule previously loaded in step 930 is returned as the authentication rule, no second level authentication rule is loaded into authentication rule cache 570 , and the method of FIG. 25 is done (step 937 ). If an associated policy was found in step 932 , then authentication module 540 caches the second level authentication rule and success and failure actions for the rule in authentication rule cache 570 (step 935 ), returns that second level authentication rule (step 936 ), and the method is done (step 937 ).
  • FIG. 26 is a flow chart describing a method for determining whether a policy is associated with a resource (see step 932 of FIG. 25 ).
  • a policy URL can contain the following three types of patterns. All three types of patterns were referenced in FIG. 21 :
  • Pattern on name value pairs in the URL This may be a set of patterns. They apply to query data (data appearing after the ‘?’ character in the URL when operation is GET, or the POST data if operation is POST) and are configured as name (no pattern allowed) plus a pattern or value. For example:
  • a policy can contain one or more of above types of patterns. If multiple patterns are specified in one policy, they ALL must match to the incoming resource URL. If not, that policy doesn't apply to the incoming resource URL.
  • Access Server 34 loads a pattern in its cache, it creates an object. This object's constructor “compiles” the pattern. This compiling is essentially building a simple state machine from one pattern to other, i.e., it creates a chain of “glob nodes.” Each glob node consists of either one pattern or a node set. For example, consider pattern:
  • Each node or node set in this chain takes a pointer to a string, walks it and decides if it matches the pattern held by the node. In doing so, it also moves this pointer further up in the string. For example, when the server gets a URL “/1/3/abcdepqrxyz,” the system takes this string and starts walking the chain.
  • URL “/1/3/abcdepqrxyz”
  • the system takes this string and starts walking the chain.
  • *p pointer
  • Access Server 34 retrieves the policy information from policy domain cache 566 .
  • the policy information can include one or more of the following: a URL absolute path, a query string, and zero or more query variables.
  • Access Server 34 determines whether requested resource matches the policy resource type (see FIG. 21 ). If the resource type does not match, Access Server 34 skips to step 952 . However, if the resource type does match, Access Server 34 proceeds to step 942 .
  • Access Server 34 determines whether the operation used to request the resource matches policy operation type (see FIG. 21 ). If the operation type does not match, Access Server 34 skips to step 952 . If the operation type does match, Access Server 34 proceeds to step 943 .
  • step 943 the policy URL absolute path, query variables, and query strings are broken up into various nodes, as described above.
  • step 944 the various nodes are stored.
  • Access Server 34 accesses the requested resource URL in step 946 .
  • step 948 the first node of the policy URL is considered by Access Server 34 .
  • step 950 Access Server 34 considers whether the considered node matches the resource URL, as described above. If the first node does not match, then the entire policy will not match (step 952 ). If the node does match the resource URL, or if there are nodes for the policy, then in step 954 it is determined whether there are any more nodes to consider.
  • step 956 the next node is considered and the method loops back to step 950 . If there are no more nodes (step 954 ), the query string for the policy is compared to the query string of the resource URL in step 958 . If the query string for the policy exactly matches the query string for the resource URL, or if there is no query string for the policy, then the method continues with step 960 . If the query string for the policy does not match the query string for the resource URL, then the resource URL does not match and is not associated with the policy (step 952 ).
  • step 960 it is determined whether there are any query variables (see FIG. 21 ) to consider that have not already been considered. If there are query variables to consider, then the next query variable is accessed in step 964 . The accessed query variable is searched for in the resource URL in step 965 . If the query variable is found in the resource URL and the value for the query variable matches the stored value query variable in for the policy (step 966 ), then the method continues at step 960 ; otherwise, Access Server 34 proceeds to step 967 .
  • the purpose of steps 960 , 964 , 965 , and 966 is to determine whether each of the query variables (and associated values) defined for a policy are found, in any order, in the resource URL. If all of the query variables are in the URL with the appropriate values, than there is a match (step 970 ). In one embodiment, the query string and the query variables are in the portion of the URL following the question mark.
  • step 966 If in step 966 a match is not found, then it is determined whether a match may still be possible using POST data.
  • resources are mapped to policies by matching POST data submitted with resource requests.
  • different policies can be associated with a given resource, depending on the contents of the POST data. For example, a user may request a resource during the course of submitting an online form containing POST data. Applicable policies can be mapped on the basis of POST data added to the policy in step 734 of FIG. 21 .
  • Access Server 34 determines whether the policy operation type is an HTTP POST request. If not, then there is no match (step 952 ).
  • Access Server 34 requests and receives the POST data from Web Gate 28 .
  • Web Gate 28 transmits a flag with all POST requests forwarded to Access Server 34 . When POST data is transmitted with an HTTP POST request, the flag is set. If no POST data is transmitted, then the flag is not set.
  • retainer 505 is transmitted by Access Server 34 to Web Gate 28 when requesting POST data. Retainer 505 is returned by Web Gate 28 to Access Server 34 with the POST data, thus indicating which policy to continue evaluating in step 969 .
  • Access Server 34 evaluates whether the POST data received in step 968 matches the POST data required by the policy to achieve a match (see FIG. 21 ). If the POST data matches, then the method proceeds to step 970 . Otherwise, the method proceeds to step 952 .
  • FIG. 26A provides a flow chart detailing the steps performed when matching a resource with a specific policy using POST data in step 969 of FIG. 26 .
  • the steps of FIG. 26A are performed by authentication module 540 .
  • Access Server 34 selects the first data required for matching the policy under consideration.
  • Access Server 34 selects the first item of POST data received in step 968 of FIG. 26 .
  • Access Server 34 compares the POST data with the required data (step 982 ). If a match is found (step 983 ), Access Server proceeds to step 987 . Otherwise, Access Server 34 proceeds to step 984 where it determines whether all of the POST data received has already been compared in step 982 .
  • Access Server 34 selects the next item of POST data received (step 986 ) and loops back to step 982 . If all received POST data has already been compared (step 982 ) and no match was found (step 984 ), then Access Server 34 returns no match (step 985 ). In step 987 , Access Server 34 determines whether additional POST data is required to be matched in order to match the specific policy under consideration with the requested resource. If additional data is required, Access Server 34 selects the next required data (step 988 ) and loops back to step 981 . If no additional data is required, Access Server 34 returns a match (step 989 ).
  • FIG. 27 provides a block diagram of a retainer data structure (retainer) 505 that is passed by Web Gate 28 to Access Server 34 to identify the policy domain and policy previously mapped in step 836 of FIG. 23 and step 932 of FIG. 25 , respectively.
  • Retainer 505 is cached in resource cache 502 in step 850 of FIG. 23 .
  • Retainer 505 contains the policy domain ID 992 of the mapped policy domain to be used in authorization and logging steps, the policy ID 994 for an applicable policy residing in the mapped policy domain, and ID 996 for the applicable authentication scheme.
  • Web Gate 28 saves Access Server 34 from having to repeatedly remap the requested resource to a policy domain and policy during authorization and logging.
  • FIG. 28 provides a flowchart of a method for authenticating a user for various combinations of domains and Web Servers through a single authentication performed by the user.
  • an Internet domain can reside on a single Web Server, or be distributed across multiple Web Servers.
  • multiple Internet domains can reside on a single Web Server, or can be distributed across multiple Web Servers.
  • the method of FIG. 28 allows a user to satisfy the authentication requirements of a plurality of domains and/or Web Servers by performing a single authentication.
  • an e-business host company's web presence incorporates associated web sites whose Web Servers have names in multiple domains.
  • each of the associated portal Web Servers use a Web Gate plug-in configured to redirect user authentication exchanges to the e-business host's designated web log-in Web Server.
  • the user is then authenticated at the e-business host's web log-in server, and an encrypted cookie is issued for the e-business host's domain to the user's browser.
  • the user's browser is then redirected back to the original associated portal's site where the Web Gate creates a new cookie for the associated portal's domain and returns it to the user's browser.
  • the user is transparently authenticated in both the original associated portal's domain and the e-business host's domain.
  • the process is transparently performed for each different associated portal that a user may visit during a session.
  • the present invention's associated portal support easily supports single Web Servers having multiple DNS names in multiple domains, and/or multiple network addresses.
  • this multiple domain authentication enables “staging” of web sites. For example, a new edition of a web site can be deployed on a separate set of servers, and then mapped to policy domains protected by the present invention by simply updating the policy domain's host ID's.
  • authentication event handler 512 determines whether single or multiple domains are protected in a given deployment of the present invention. If only a single domain is protected, then the method proceeds to step 1022 where an authentication is attempted at the single domain. If the single domain is distributed across multiple Web Servers, then the domain attribute of the cookie set by the authenticating Web Server in step 1022 is set to broadly include all Web Servers in the domain.
  • authentication event handler 512 determines whether the multiple protected domains all reside on a single Web Server.
  • a single machine intranet.oblix.com may be addressed in multiple ways such as: sifl.oblix.com, intranet, asterix.oblix.com, or 192.168.70.1.
  • an administrator when multiple domains reside on a single Web Server, an administrator will designate exactly one of the domains a “preferred host domain.” If step 1024 indicates that all protected domains reside on the same Web Server, then authentication event handler 512 determines whether the domain of the requested resource is a preferred host (step 1026 ).
  • authentication event handler 512 attempts to authenticate the user at the preferred host domain in step 1030 (further described below with respect to FIG. 30 ). Otherwise, redirection event handler 504 redirects browser 12 to the preferred host domain (step 1028 ) for authentication (step 1030 ). Referring to step 1024 , if the multiple protected domains reside on multiple Web Servers, then authentication event handler 512 proceeds to step 1032 .
  • a single policy domain and/or policies are created for the preferred host domain while no policy domains or policies are created for the other domains residing on the same web server. All resource requests made to any of the multiple protected domains residing on the same web server are redirected to the preferred host domain, thus requiring the user to authenticate according to the preferred host domain's policy domain and/or policies. As a result, after authentication at the preferred host domain, the user is transparently authenticated for all other domains residing on the same web server. When subsequent resource requests for resources in domains residing on the same web server are redirected to the preferred host domain, the prior successful authentication for the host domain can be confirmed by the existence of a valid authentication cookie for the preferred host domain.
  • the user need not re-authenticate for the requested resource.
  • subsequent resource requests made to the preferred host domain or any of the other domains on the same web server) require a higher level of authentication, or if a previously valid authentication has expired, the user will be required to re-authenticate at the preferred host domain in accordance with the method of FIG. 28 .
  • FIG. 29 provides a block diagram of a plurality of Web Servers, each hosting a different domain accessible by browser 1082 .
  • the administrator when multiple domains are protected and distributed across multiple Web Servers, the administrator will identify exactly one of the domains a “master domain.”
  • Web Server 1070 hosts master domain A.com
  • Web Servers 1072 and 1074 host domains B.com and C.com, respectfully.
  • An end user's resource request is illustrated in FIG. 29 by path 1084 from browser 1082 to Web Server 1072 .
  • authentication event handler 512 determines that the domain of the requested resource is a master domain (step 1032 )
  • authentication event handler 512 attempts to authenticate at the master domain (step 1034 ). Otherwise, redirection event handler 504 redirects browser 12 to the master domain (step 1036 ). The user then authenticates at the master domain (step 1038 ). The redirection and authentication of steps 1036 and 1038 are illustrated in FIG. 29 by path 1086 .
  • the master domain Web Server passes an authentication cookie to the user's browser (step 1040 ) and re-directs the user's browser back to the first domain accessed by the user (step 1042 ).
  • the master domain passes information contained in the master domain authentication cookie to the first domain in the query data portion of the redirection URL.
  • Steps 1040 and 1042 are illustrated by paths 1088 and 1090 , respectively in FIG. 29 .
  • the Web Gate of the first domain Web Server extracts the master domain authentication cookie information from the redirection URL, thus confirming the user's authentication at the master domain and resulting in a successful authentication (step 1046 ).
  • the first domain Web Server (B.com) then sends its own authentication cookie to web browser 1082 (as depicted by path 1092 ) in accordance with step 780 of FIG. 22 , previously described above. Any subsequent authentication by browser 1082 at domain C.com on Web Server 1074 follows the method of FIG. 28 .
  • FIG. 30 provides a flow chart of the method for authenticating, as performed in steps 1022 , 1030 , 1034 , and 1038 of FIG. 28 .
  • the steps of FIG. 30 are performed by authentication event handler 512 .
  • authentication event handler 512 accesses resource cache 502 to determine what authentication challenge method is to be used for the given resource.
  • Authentication event handler 512 then accesses authentication scheme cache 506 in step 1122 to determine whether the authentication scheme associated with the requested resource has been previously cached. If the authentication scheme is found, authentication event handler 512 determines the specific type of challenge method in step 1126 . If the challenge scheme was not found in step 1122 , authentication event handler 512 loads the authentication rule associated with the requested resource from Directory Server 36 in step 1124 (further described below in FIG. 31 ), and then proceeds to step 1126 .
  • authentication event handler 516 discerns whether the authentication challenge scheme retrieved in step 1122 or 1124 calls for basic, form, certificate, or no authentication. If the challenge scheme indicates basic authentication, then the method proceeds to step 1128 and performs basic authentication. If the challenge scheme indicates form authentication, then the method proceeds to step 1130 and performs form authentication. If the challenge scheme indicates certificate authentication, then the method proceeds to step 1132 and performs certificate authentication. If the challenge scheme indicates that no authentication is required (step 1134 ), then the user is not challenged, authentication is not performed (in one embodiment, the system skips to step 756 of FIG. 22 and in another embodiment the system skips to step 774 of FIG. 22 ).
  • FIG. 31 provides a flow chart describing the method of loading an authentication challenge scheme from Directory Server 36 (step 1124 of FIG. 30 ).
  • the steps of FIG. 31 are performed by authentication event handler 512 and Access Server 34 .
  • authentication event handler 512 requests the authentication challenge scheme to be read from Access Server 34 . If the authentication challenge scheme is found in authentication scheme cache 568 (step 1162 ), then Access Server 34 proceeds to step 1168 . Otherwise, Access Server 34 retrieves the requested authentication challenge scheme from Directory Server 36 (step 1164 ). Upon retrieval, Access Server 34 caches the authentication challenge scheme in authentication scheme cache 568 (step 1166 ), and proceeds to step 1168 .
  • Access Server 34 passes the retrieved authentication challenge scheme to Web Gate 28 . Web Gate 28 then caches the authentication challenge scheme in authentication scheme cache 506 (step 1170 ).
  • FIG. 32 provides an exemplar method for performing basic authentication (step 1128 of FIG. 30 ).
  • the steps of FIG. 32 are performed by authentication event handler 512 and authentication module 540 .
  • authentication event handler 512 instructs browser 12 to prompt the user for a user ID and password.
  • the user enters and the user's browser submits the requested user ID and password (step 1204 ).
  • Web Gate 28 intercepts the user submission and authentication event handler 512 passes the user ID and password to Access Server 34 , along with retainer 505 , thus identifying a policy domain and policy applicable to the requested resource.
  • Access Server authentication module 540 then authenticates the user using the user ID and password in step 1208 .
  • authentication module 540 returns the authentication result, authentication success or failure actions, and any user attributes required by the actions to Web Gate 28 .
  • FIG. 33 provides a flow chart describing an exemplar method used by the Access Server to authenticate using a user ID and password (step 1208 of FIG. 32 ).
  • the steps of FIG. 33 are performed by authentication module 540 .
  • authentication module 540 searches user profile cache 576 for a user identity profile entry having a user ID attribute matching the user ID received from Web Gate 28 .
  • User profile cache 576 is a hash table of user identity profile attributes that can be used for authentication, authorization, or auditing. In one embodiment, the user ID attribute would appear in user profile cache 576 if it was previously used in a successful authentication. If a match is found (optional step 1232 ), then authentication module 540 proceeds to step 1234 . If no match is found, then authentication module 540 proceeds to step 1236 .
  • steps 1230 and 1232 of FIG. 33 are not performed.
  • the method of FIG. 33 begins with step 1236 where it searches user identity profiles 102 in Directory Server 36 (not user profile cache 576 ) for a user identity profile having a user ID attribute matching the user ID received from Web Gate 28 . If no matching user identity profile attribute is found in Directory Server 36 (step 1238 ), then the method proceeds to step 1241 . If a matching user identity profile attribute is found in Directory Server 36 (step 1238 ), then authentication module 540 binds to the directory using the distinguished name from the matching user identity profile entry and the password received from Web Gate 28 (step 1234 ).
  • authentication module 540 proceeds to step 1241 where it determines whether an entry for the current user is found in user profile cache 576 . If so, authentication module 540 proceeds to step 1243 . Otherwise, authentication module 540 retrieves all profile attributes of the current user appearing in user attribute list 114 and caches them in user profile cache 576 (step 1242 ). In step 1243 , authentication module 540 returns an unsuccessful authentication result.
  • authentication module 540 accesses revoked user list 582 to determine whether the user ID received from Web Gate appears on revoked user list 582 . If the user ID is on the revoked user list (step 1244 ), authentication module 540 proceeds to step 1241 . If the user ID is not on the revoked user list, then authentication module 540 determines whether an entry for the user is found in user profile cache 576 (step 1250 ). If not, authentication module 540 retrieves all profile attributes of the current user appearing in list 114 and caches them in user profile cache 576 (step 1254 ). If an entry was found, the method skips to step 1260 . In step 1260 , the method returns a successful authentication result.
  • FIG. 34 provides a flow chart describing a method for performing form authentication (step 1130 of FIG. 30 ).
  • the steps of FIG. 34 are performed by authentication event handler 512 , redirection event handler 504 , browser 12 , and authentication module 540 .
  • authentication event handler 512 sets a “form login” cookie on browser 12 .
  • the cookie includes the URL of the requested resource.
  • Authentication event handler 512 then redirects browser 12 to an authentication form URL (step 1310 ).
  • Web Gate 28 allows the authentication form referenced by the authentication form URL to pass to browser 12 .
  • the user then fills out the authentication form (step 1314 ) and transmits (e.g.
  • Authentication event handler 512 then extracts the URL of the requested resource from the form login cookie (step 1318 ), and passes the user ID and password filled out by the user in the authentication form (submitted as POST data) to Access Server 34 (step 1320 ).
  • authentication module 540 authenticates the user for the requested resource using the user's id and password received from Web Gate 28 , performing the steps of FIG. 33 previously described above.
  • authentication module 540 returns the authentication result, authentication actions, and user attributes to Web Gate 28 .
  • Authentication event handler 512 sets the form login cookie (previously set in step 1308 ) to indicate that the authentication process is completed (step 1326 ).
  • FIG. 35 is a flow chart describing a method for performing certificate authentication (step 1132 of FIG. 30 ).
  • client certificate authentication is performed using Web Servers employing the Netscape Enterprise Server plug-in interface (NSAPI).
  • NSAPI Netscape Enterprise Server plug-in interface
  • ISAPI Microsoft Internet Information Server plug-in interface
  • client certificate authentication is performed on a plurality of Web Servers, with a first subset of the Web Servers employing NSAPI and a second subset employing ISAPI.
  • Other Web Servers can also be used.
  • the steps of FIG. 35 are performed by authentication event handler 512 , redirection event handler 504 , browser 12 , and authentication module 540 .
  • authentication event handler 512 requests Web Server 18 to perform SSL client certificate authentication on browser 12 .
  • authentication event handler 512 redirects browser 12 to a special case URL (i.e. cert_authn.dll) that is configured to accept certificates. In such an embodiment, this redirection occurs within step 1348 .
  • Web Server 18 on behalf of Web Gate 28 , sends an SSL client certificate request along with trusted certificate authorities (CA's) and challenge data to browser 12 .
  • Browser 12 displays a selection box with client certificates from trusted CA's, allowing a user of browser 12 to select a certificate (step 1352 ).
  • Browser 12 then returns the selected certificate with challenge data signed by a private key to Web Server 18 (step 1356 ).
  • Web Server 18 then verifies that the challenge data was properly signed by the selected certificate (step 1360 ) and passes a valid certificate to Web Gate 28 (step 1362 ), which passes the certificate to Access Server 34 (step 1363 ).
  • authentication module 540 of Access Server 34 then decodes the certificate and maps the certificate subject to a valid distinguished name (further described in FIG. 36 ).
  • authentication module 540 returns the authentication result, authentication actions, and user attributes to Web Gate 28 .
  • FIG. 36 provides a flow chart describing a method for authenticating using a valid certificate (step 1364 of FIG. 35 ).
  • the steps of FIG. 36 are performed by authentication module 540 .
  • authentication module 540 decodes one or more fields of the certificate passed by Web Gate 28 in step 1362 of FIG. 35 .
  • the user's e-mail address is decoded.
  • authentication module 540 searches user profile cache 576 for a user identity profile entry having one or more attributes matching the decoded field(s). In one embodiment, the user attribute would appear in user profile cache 576 if it was previously used in a successful authentication. If a match is found (optional step 1394 ), then authentication module 540 proceeds to step 1406 . If no match is found, then authentication module 540 proceeds to step 1396 .
  • steps 1390 and 1392 of FIG. 36 are not performed.
  • the method of FIG. 36 begins with step 1396 where it searches user identity profiles 102 in Directory Server 36 for a user identity profile having one or more attributes matching the decoded field(s). If no matching user identity profile attribute is found in Directory Server 36 (step 1398 ), then the method proceeds to step 1402 where it determines whether an entry for the current user is found in user profile cache 576 . If so, authentication module 540 proceeds to step 1405 . Otherwise, authentication module 540 retrieves all profile attributes of the current user appearing in user attribute list 114 and caches them in user profile cache 576 (step 1404 ). In step 1405 , authentication module 540 returns an unsuccessful authentication result. If a matching user identity profile is found in step 1398 , the method proceeds to step 1406 .
  • authentication module 540 accesses revoked user list 582 to determine whether the user identity profile having the matching user attribute appears on revoked user list 582 . If so, authentication module 540 proceeds to step 1402 . Otherwise, authentication module 540 continues on to step 1410 and determines whether an entry for the current user is found in user profile cache 576 . If not, authentication module 540 retrieves all profile attributes of the current user appearing in list 114 and caches them in user profile cache 576 (step 1416 ). If an entry was found, the method skips to step 1422 . In step 1422 , the method returns a successful authentication result.
  • FIG. 37 provides a block diagram of an authentication cookie 1450 passed by Web Gate 28 to browser 12 in step 780 of FIG. 22 .
  • Cookie 1450 is encrypted with a symmetric cipher so that cookies from all instances of Web Gate 28 in a given deployment of the present invention may be encrypted using the same key.
  • This key (shared secret 110 ) is stored on Directory Server 36 and distributed to each of the Web Gates 28 by Access Server 34 .
  • Shared secret 110 can change as often as desired by an administrator.
  • cookie 1450 is encrypted using RC4 encryption with a 2048 bit key.
  • previously valid keys are grandfathered such that both the current key and the immediately prior key will both work to de-crypt encrypted cookie 1450 .
  • the present invention features a one-button key re-generation function. This function is easily scriptable.
  • the information stored by cookie 1450 includes the authentication level 1452 of the authentication scheme used to create the cookie, the user ID 1454 of the authenticated user, the IP address 1456 of the authenticated user, and session start time 1458 identifying the time at which cookie 1450 was created. If the time elapsed since the session start time 1458 exceeds a maximum session time, the cookie will become invalid. Idle start time 1460 is also stored, which identifies the time when the previous HTTP request for a protected resource was made in which cookie 1450 was passed. If the time elapsed since the idle start time 1460 exceeds a maximum idle time, the cookie will become invalid.
  • Cookie 1450 also stores a secured hash 1462 of information 1452 , 1454 , 1456 , 1458 , and 1460 .
  • secured hash 1462 is created using an MD5 hashing algorithm.
  • Most Internet browsers cache a user's supplied authentication information during basic and certificate authentication challenge methods, and then transparently re-send the information upon receiving an authentication challenge from a Web Server.
  • an administrator can enable a form authentication challenge method requiring end users to re-authenticate upon expiration of the maximum session or maximum idle time limits.
  • FIG. 38 provides a flow chart describing a method for attempting to authorize a user (step 756 of FIG. 22 ).
  • the method of FIG. 38 is performed by authorization event handler 516 and authorization module 542 .
  • authorization event handler 516 of Web Gate 28 passes authorization information to Access Server 34 .
  • authorization module 542 determines whether one or more authorization rules associated with the requested resource are found in authorization rule cache 572 . If one or more rules are found, authorization module 542 proceeds to step 1496 . Otherwise, authorization module 542 retrieves any authorization rules associated with the requested resource from Directory Server 36 in step 1498 . In one embodiment, authorization success and failure actions are retrieved with the authorization rules.
  • authorization module 542 After retrieving the authorization rules, authorization module 542 proceeds to step 1496 and reads the first authorization rule associated with the requested resource from authorization rule cache 572 . In one embodiment, multiple authorization rules are evaluated in an order determined by the priority set in step 646 of FIG. 17 . In another embodiment, second level authorization rules are evaluated prior to first level authorization rules. Authorization module 542 applies the authorization rule (step 1500 ) to the authorization information previously passed in step 1490 .
  • authorization module 542 determines whether an entry for the user is found in user profile cache 576 (step 1504 ). If so, authorization module 542 proceeds to step 1508 . If not, authorization module 542 retrieves all profile attributes of the current user appearing in user attribute list 114 (step 1507 ), and communicates the authorization success actions and attributes to Web Gate 28 (step 1508 ).
  • authorization module 542 determines whether more authorization rules remain to be evaluated (step 1509 ). If more rules remain, the next rule is read (step 1496 ) and evaluated (step 1500 ). If no more rules remain, authorization module 542 determines whether an entry for the user is found in user profile cache 576 (step 1510 ). If so, authorization module 542 proceeds to step 1512 . If not, authorization module 542 retrieves all profile attributes of the current user appearing in user attribute list 114 (step 1511 ), and communicates the authorization success actions and attributes to Web Gate 28 (step 1512 ).
  • FIG. 39 details the steps performed when passing authorization information to Access Server 34 in step 1490 of FIG. 38 .
  • the steps of FIG. 39 are performed by authorization event handler 516 .
  • authorization can be performed using POST data.
  • POST data is not used for authorization. If POST data is enabled to be used for authorization, then the method of FIG. 39 begins with optional step 1530 . Otherwise, the method begins at step 1534 . If the resource request issued by browser 12 in step 750 of FIG. 22 employs a POST request method and POST data is enabled to be used for authorization (step 1530 ), authorization event handler 516 passes the POST data and retainer 505 to Access Server 34 (step 1536 ).
  • authorization event handler 516 passes retainer 505 , the request method, the user's distinguished name, the user's IP address, and the time of the request to Access Server 34 in step 1534 .
  • FIG. 40 illustrates the format of an HTTP request.
  • an HTTP request 1550 comprises request line 1552 , zero or more headers 1554 , blank line 1556 , and body 1558 (used only for POST requests).
  • the HTTP protocol supports various types of requests.
  • the GET request returns whatever information is identified by the request-URI portion of request line 1552 .
  • the HEAD request is similar to the GET request, but only a server's header information is returned. The actual contents of the specified document is not returned. This request is often used to test hypertext links for validity, accessibility, and recent modifications.
  • the POST request is used for POSTing electronic mail, news, or sending forms that are filled in by an interactive user.
  • a POST is the only type of request that sends a body.
  • a valid content-linked header field is required in POST requests to specify the length of body 1558 .
  • HTTP request 1550 can contain a variable number of header fields 1560 .
  • a blank line 1556 separates header fields 1554 from body 1558 .
  • a header field comprises a field name, a string and the field value, as depicted in box 1560 .
  • the field value is an LDAP attribute.
  • Field names are case insensitive. Headers can be divided in three categories: those that apply to requests, those that apply to responses, and those that describe body 1558 . Certain headers apply to both requests and responses. Headers that describe the body can appear in a POST request or in any response.
  • FIG. 41 provides a flow chart describing a method for loading an authorization rule from the Directory Server (step 1498 of FIG. 38 ).
  • the steps of FIG. 41 are performed by authorization module 542 .
  • Access Server 34 loads the default authorization rule for the policy domain mapped in step 836 of FIG. 23 from Directory Server 36 into authorization rule cache 572 .
  • Access Server 34 selects a first rule in array 565 (step 1582 ) and determines whether the selected rule is a second level (specific) rule of a policy associated with the requested resource (step 1584 ), by calling the method of FIG. 26 previously described above. If yes, then Access Server 34 proceeds to step 1592 . Otherwise, Access Server 34 determines whether all rules in array 565 have been evaluated (step 1586 ).
  • Access Server 34 selects the next rule in array 565 (step 1588 ), and returns to step 1584 . Once all rules in array 565 have been considered (step 1586 ), Access Server 34 proceeds to step 1594 and loops back to step 1586 . If a second level authorization rule (a rule defined in a policy) was found for the requested resource in step 1584 , then authorization module 540 caches the second level authorization rule in authorization rule cache 570 (step 1592 ) and the method is done (step 1594 ). If a second level policy authorization rule was not found, then the default authorization rule previously loaded in step 1580 remains in authorization rule cache 572 , and the method is done (step 1594 ).
  • a second level authorization rule a rule defined in a policy
  • FIG. 42 provides a flow chart describing the method of applying an authorization rule (step 1500 of FIG. 38 ).
  • the steps of FIG. 42 are performed by authorization module 542 .
  • authorization can be performed using POST data.
  • POST data is not used for authorization. If POST data is to be used for authorization, then the method of FIG. 42 begins with optional step 1620 . Otherwise, the method begins at step 1624 .
  • optional step 1620 if the resource request employs a POST request method, then authorization module 542 proceeds to optional step 1622 where it applies the authorization rule to the POST data passed in step 1536 of FIG. 39 .
  • authorization module 542 proceeds to step 1624 . If specific users are defined (by distinguished name) in the authorization rule, authorization module 542 evaluates whether the distinguished name of the authenticated user matches the user's distinguished name called for by the authorization rule (step 1626 ). If specific groups are defined in the authorization rule (step 1628 ), authorization module 542 evaluates whether the group name of the authenticated user matches the group name called for by the authorization rule (step 1630 ). In one embodiment, the user's group membership is cached in user policy cache 578 .
  • authorization module 542 evaluates whether the role of the authenticated user matches the role called for by the authorization rule (step 1634 ). If specific LDAP rules are defined in the authorization rule (step 1640 ), authorization module 542 evaluates whether the LDAP rule matches the LDAP rule called for by the authorization rule (step 1642 ). In one embodiment, the result of the LDAP rule evaluation in step 1642 is cached in user policy cache 578 . If specific user IP addresses are defined in the authorization rule (step 1644 ), authorization module 542 evaluates whether the IP address of the authenticated user matches the IP address called for by the authorization rule (step 1646 ).
  • step 1650 If a successful match is found at any point (steps 1627 , 1631 , 1635 , 1643 , and 1647 ), the authorization is successful (step 1650 ).
  • successful matches of groups and LDAP rules are stored in user policy cache 578 in steps 1631 and 1643 . In another embodiment, multiple matches must be found before an authorization success is found. If no matches are found, authorization is unsuccessful (step 1652 ).
  • FIG. 43 provides a flow chart detailing the steps performed when applying an authorization rule to POST data in optional step 1622 of FIG. 42 .
  • the steps of FIG. 43 are performed by authorization module 542 .
  • Access Server 34 selects the first item of POST data received in optional step 1536 of FIG. 39 . If the selected POST data is of a type that is called for by the authorization rule being evaluated (step 1672 ), then Access Server 34 evaluates whether the selected POST data matches data required by the authorization rule (step 1674 ) and determines whether a successful match has been found (step 1675 ).
  • an authorization rule calls for a user's distinguished name
  • a distinguished name contained in the POST data will be compared with the distinguished name expected by the authorization rule. If the selected POST data equals the expected distinguished name, then a successful match will be found for the example above. If a match is found (step 1675 ), Access Server proceeds to step 1682 where it returns a successful authorization. Otherwise, Access Server proceeds to step 1676 . If, in step 1672 , it is determined that the type of POST data was not called for, then Access Server 34 proceeds directly to step 1676 .
  • Access Server 34 determines whether all of the POST data received in step 1536 has been considered by step 1672 . If additional POST data remains to be considered (step 1676 ), Access Server 34 selects the next available item of POST data (step 1678 ) and loops back to step 1672 . If no POST data remains to be considered and a match still has not been found (step 1676 ), access Server 34 proceeds to step 1684 and returns an authorization failure.
  • FIG. 44 is a flow chart describing the process of performing authentication success actions (step 776 of FIG. 22 ).
  • Web Gate 28 determines whether there is a redirect URL.
  • an administrator can set up a redirect URL for authentication success/failure events as well as authorization success/failure events.
  • An administrator can also set up various variables to add to an HTTP request based on these events. If, in step 1700 , it is determined that a redirect URL exists for an authentication success event, then in step 1702 it is determined whether there are any HTTP variables to add to the HTTP request.
  • step 1704 it is determined whether there are any HTTP variables to add to the request. If, in step 1704 , it is determined that there are HTTP variables to add to the request in response to the authentication success event, then in step 1706 , the header variables are added. If, in step 1704 , it is determined that there are no HTTP variables to add to the request, then no action is performed (step 1708 ). If, in step 1702 , it is determined that there are no HTTP variables to add to the request, then in step 1710 the redirect URL is added to the HTTP request and browser 12 is redirected using the HTTP request in step 1712 .
  • step 1702 If in step 1702 it is determined that there are HTTP variables to add to the request, then in step 1714 the redirect URL is added to the HTTP request and, in step 1716 , the header variables are added to the HTTP request. In step 1718 , the browser is redirected using the newly constructed HTTP request.
  • a Web Server When a Web Server receives an HTTP request, the Web Server stores the contents of the HTTP request in a data structure on the Web Server.
  • a Web Gate can edit that data structure using an API for the Web Server.
  • the downstream application that will be using the header variables is on, accessed using or associated with the same Web Server storing the HTTP request. In that case, the header variable are added (e.g. in step 1706 ) by storing the header variables in the data structure on the Web Server. Subsequently, the Web Server will provide the header variables to the downstream application.
  • FIG. 45 is a flow chart describing the steps of performing authentication and authorization failure actions (see steps 766 and 798 of FIG. 22 , respectively).
  • Web Gate determines whether there is a redirect URL for the authorization failure or authentication failure, whichever event is being considered. If there is no redirect URL, then in step 1740 , it is determined whether there are any HTTP variables for the authorization failure or authentication failure. If there are no HTTP variables, then in step 1742 , a default failure URL is added to a new HTTP request.
  • the default failure URL is a URL that points to a web page that notifies a user that access is denied to the resource. In other embodiments, other pages can be used as default failure pages.
  • step 1744 the user's browser 12 is redirected using the HTTP request that includes the default failure URL. If, in step 1740 , it is determined that there are HTTP variables to add to the HTTP request for the particular authentication failure or authorization failure event, then in step 1746 , those variables are added as header variables to the HTTP request. In step 1748 , the default failure URL is added to the HTTP request. The user's browser is redirected using the HTTP request in step 1750 .
  • step 1738 it is determined whether there is a redirect URL for the particular authentication failure or authorization failure event. If not, the redirect URL is added to the HTTP request in step 1754 and the browser is redirected using the HTTP request in step 1756 . If, in step 1752 it is determined that there are HTTP variables to add to the request, then in step 1758 , the redirect URL is added to the HTTP request. In step 1760 , the header variables are added to the HTTP request. The user's browser is then redirected using the HTTP request in step 1762 .
  • FIG. 46 is a flow chart describing the process of performing authorization success actions (step 794 of FIG. 22 ).
  • step 1782 it is determined whether there is a redirect URL for the authorization success action. If there is no redirect URL, then in step 1784 it is determined whether there are any HTTP header variables to add. If so, the header variables are added in step 1786 .
  • the header variables can be added to the data structure for the request that is stored on the Web Server. Subsequently, the Web Server will provide the header variables to the downstream application(s). If, in step 1784 it is determined that there are no HTTP variables to add to the request, then no action is taken.
  • step 1796 it is determined whether there are any HTTP variables to add to the request. If there are not any HTTP variables to add to the request, then the redirect URL is added to the HTTP request in step 1798 .
  • step 1800 the user's browser is redirected using the HTTP request with the redirect URL. If it is determined that there are HTTP variables to add to the request in step 1796 , then the redirect URL is added to the HTTP request in step 1802 .
  • step 1804 the HTTP variables are added as header variables to the HTTP request.
  • step 1806 the user's browser is redirected using the HTTP request.
  • FIG. 47 is a flow chart describing the process of how a downstream application or other resource uses header variables provided by the system of FIG. 1 .
  • the resource receives the request.
  • the resource receives request information from a Web Server.
  • the resource receives a redirected HTTP request.
  • the resource determines whether there are any header variables to consider. If there are no header variables, then in step 1834 , the resource responds to the request. Responding to the request can include providing a web page, access to a software process or anything else appropriate for the particular resource.
  • step 1836 the resource searches for a particular variable name.
  • the resource In order to use header variables, the resource must be preprogrammed to know what header variables to expect and how to use them. Thus, the resource will have a list of variable names it seeks.
  • step 1836 the resource looks for one of the listed variable names in the set of header variables. Once found, the resource reads the string for the found variable in step 1838 .
  • step 1840 the resource reads the variable value (e.g. LDAP attribute).
  • HTTP variables are set up in actions, a variable name, a string for the variable and data for the variable are provided.
  • step 1842 it is determined whether any variables to operate on.
  • step 1844 the resource acts on the variables by taking the information from the variables and using them in the manner appropriate for the particular resource.
  • the resource responds to the request as appropriate for that particular resource.
  • One example for using the process of FIG. 47 is to provide an automated login for a downstream application. For example, upon authentication or authorization successes, login information for a particular user and a particular application can be added to the HTTP request as header variables.
  • the downstream application can be programmed to search the header variables for the login and password information and automatically attempt to authorize the user.
  • user identity profile information is passed to a downstream application without the user accessing the application directly. This user identity profile information would be stored in header variables and provided to the resource being accessed.
  • the resource being accessed can be fully customized for the user accessing the resource. For example, the resource can address the user by name and title and access preferences for that user.
  • the Access System monitors and logs various events, including authorization and authentication failure/success events. In other embodiments, other events can be monitored and logged. When an event being monitored occurs, an entry is added to an appropriate audit log.
  • log and log entry are used broadly because no special format is necessary for the present invention.
  • a log can include any reasonable and organized system for storing information.
  • FIG. 48 provides a flow chart detailing the steps performed for logging authentication and/or authorization events (see steps 764 , 774 , 792 , and 796 of FIG. 22 ).
  • the steps of FIG. 48 are performed by Web Gate 28 and auditing module 544 .
  • the log process is configurable because the audit rule associated with a requested resource can specify any combination of information to be logged in audit logs 546 in response to a detected type of event selected to be audited.
  • an audit rule associated with a requested resource can specify that all or a subset of the attributes of the identity profile for the user making the access request should be logged in one of audit logs 546 for the specific event.
  • the time of the authentication and an identification authorization event is logged in one or more of audit logs 546 .
  • An identification of the resource, the rule evaluated, the type of event, the IP (or other) address of the requesting machine, user ID, an identification of the operation being performed (e.g. GET, etc.) an identification of the Web Gate and/or access server that processed the request, user password and any other suitable information can also be logged.
  • Storing identity profile information allows the system to provide data for load balancing, various business reports, and reports about how the system is being used. For example, knowledge of which resources are being accessed, when resources are being used and who is accessing the resources can allow an administrator to perform load balancing on the system. Reports identifying which content is being accessed the most can help a business allocate resources. Information about how various entities use the system can provide behavioral data to the host. Various other business reports and monitoring can also be useful.
  • the process of FIG. 48 is commenced by the detection of an access system event.
  • both the attempt to authenticate (steps 760 & 762 ) and the attempt to authorize (steps 756 & 790 ) can be thought of as the detection of an access system event.
  • the access system events of the embodiment of FIG. 22 includes authorization success, authorization failure, authentication success and authentication failure.
  • Other access system events can also be monitored for use with the present invention.
  • detecting an access system event can utilize different means than explicitly described in FIG. 22 , as long as the system has a means for knowing that an event occurred.
  • an access system event can be detected using specific monitors or sensors.
  • step 1870 of FIG. 48 Web Gate 28 reads audit mask 503 from resource cache 502 in response to an authentication or authorization result. If audit mask 503 indicates that the event is not audited (step 1872 ), then the method is done (step 1874 ). If the event is to be audited (step 1872 ), then Web Gate 28 passes retainer 505 to auditing module 544 , thus identifying the applicable policy domain and/or policy for auditing. In step 1878 , auditing module 544 reads the audit rule associated with the requested resource from audit rule cache 574 .
  • the audit rule read in step 1878 will be a first level (default) audit rule, a second level (specific) audit rule, or a master audit rule applicable to all resources when neither a first or second level audit rule is found.
  • auditing module 544 logs information specified by the found audit rule into one or more audit logs 546 .
  • Access Server 34 informs auditing module 544 of authentication and authorization events to be logged, thus, allowing auditing module 544 to perform steps 1878 and 1880 directly in response to an authentication or authorization result, rather than waiting to be prompted by Web Gate 28 .
  • FIG. 49 provides a flow chart of a method for loading audit rules (see step 846 of FIG. 23 ).
  • Access Server 34 loads the default audit rule for the policy domain mapped in step 836 of FIG. 23 from Directory Server 36 into audit rule cache 574 .
  • Access Server 34 selects a rule in array 565 (step 1902 ) and determines whether the selected rule is a specific audit rule for a policy associated with the requested resource, by using the method of FIG. 26 previously described above (step 1904 ). If the resource is part of the policy, then Access Server 34 proceeds to step 1912 . Otherwise, Access Server 34 determines whether all rules in array 565 have been considered (step 1906 ).
  • Access Server 34 selects the next rule in array 565 (step 1908 ), and returns to step 1904 . Once all rules in array 565 have been considered (step 1906 ), Access Server 34 proceeds to step 1912 . If a second level authentication rule was found for the requested resource in step 1904 , then authentication module 540 caches the second level audit rule in audit rule cache 574 (step 1912 ) and proceeds to step 1914 . In step 1914 , Access Server 34 prepares audit mask 503 , identifying the authentication and authorization events to be logged (audited) by auditing module 544 in accordance with the second level audit rule.
  • step 1910 If a second level audit rule was not found (step 1910 ), then the first level audit rule previously loaded in step 1484 remains in audit rule cache 574 , and Access Server 34 prepares audit mask 503 using the first level audit rule. Thus, when the method of FIG. 49 is done, only one audit rule for the requested resource will remain in audit rule cache 574 .
  • FIG. 50 depicts one embodiment of components used to detect attempted intrusions.
  • the attempted intrusions can be inadvertent or malicious.
  • the goal is to detect attempted intrusions of the access system, which includes the protected resources.
  • FIG. 50 shows audit logs 546 which can be one or more logs for logging various events. For example, there could be one log for logging authentication failure events, one log for logging authorization failure events, etc. Alternatively, there could be one log for logging multiple types of events.
  • an audit log sensor 548 monitors the type of event occurring. For example, in one embodiment there is an authentication failure sensor and an authorization failure sensor. If other events are monitored, there can be a sensor for each of the other events.
  • database server 1934 includes an SQL database for storing all of the received log entries. Periodically, database server 1934 sends a set of log entries to security server 1936 . In one embodiment, database server 1934 is stored within the local system of FIG. 1 and security server 1936 is located offsite. In one embodiment, database server 1934 is not provided and the various log sensors send their log entries directly to security server 1936 . As discussed above, the audit log entries are fully configurable. The log entries sent by the sensors can be exact duplicates of the log entries in the audit logs or they can be reformatted versions or versions that store only a subset of the original information.
  • FIG. 51 provides a flow chart describing the operation of the components depicted in FIG. 50 .
  • an event is logged.
  • the system is fully configurable to allow the sensors to monitor all or a subset of events being logged.
  • the events being monitored by sensors 548 are denoted as registered events. For example, in one embodiment, the system logs all authentication failure, authentication success, authorization failure and authorization success events, while sensors 548 monitor only authentication failure and authorization failure events.
  • step 1952 it is determined whether the logged event is a registered event. If not, the method of FIG. 51 is done (step 1964 ). If it is a registered event, then in step 1954 the sensor accesses instructions for the event type.
  • the system is configurable to perform any action specified by the administrator. For example, in one embodiment, an action will be to send the log entry to a database server. In another embodiment the action will also include adding information to the log entry such as information from a user identity profile, login information, time, date, etc.
  • sensor 548 accesses the log entry and performs instructions for the event type to the log entry in step 1958 . As discussed above, one exemplar instruction requests that the sensor sends the log entry to either database server 1934 or security server 1936 . If the sensor is instructed to send the log entry to database server 1934 , then database server 1934 receives and stores the log entry in step 1960 . In step 1962 , database server 1934 will periodically send all or a subset of the log entries to security server 1936 .
  • FIG. 52 is a flow chart describing the operation of security server 1936 .
  • security server 1936 receives a log entry.
  • Step 1980 could include receiving a particular log entry directly from a sensor 548 or receiving a set of log entries from database server 1934 .
  • the log entries are stored at security server 1936 .
  • a rules engine is run on a set of stored log entries.
  • the log entries used in step 1984 could include the newest set of log entries and, optionally, previous log entries going back historically as needed by the rules engine.
  • the rules engine can look for any particular pattern of events.
  • the steps of FIGS. 51 and 52 are used to detect one or more attempts of intrusion of the system.
  • the rules engine looks for patterns over time of an entity attempting to wrongfully access resources in the system of FIG. 1 .
  • various patterns can be detected.
  • the rules engine may look for three authorization failures for the same entity or three authentication failures with the same login name or password.
  • Security server 1936 correlates events over time to identify persons or actions that constitute security breaches or attempted security breaches.
  • FIG. 53 provides a flow chart detailing the steps performed by Access Manager 40 for flushing and synchronizing caches of Web Gate 28 and Access Server 34 in accordance with the present invention. If a change is made (by an administrator, user, or otherwise) to a policy domain or a policy stored on Directory Server 36 , any affected first level or second level rules cached in the respective caches of Web Gate 28 and Access Server 34 will become stale data. Similarly, if a change is made to user identity profiles 102 or revoked user list 108 on Directory Server 36 , previously cached versions of the changed data will become stale. Accordingly, the respective caches of Web Gate 28 and Access Server 34 must be flushed to prevent Web Gate 28 , Access Server 34 , User Manager 38 , Access Manager 40 , or System Console 42 from using the stale data.
  • Access Manager 40 detects a change to data stored on Directory Server 26 .
  • Access Manager 40 reads the previous Global Sequence Number (GSN) 112 stored on directory server 36 .
  • GSN Global Sequence Number
  • Access Manager 40 assigns a current GSN to the change detected in step 2010 .
  • the current GSN is the next sequential number after the previous GSN 112 .
  • Access Manager 40 stores the current GSN on Directory Server 36 , replacing the previous GSN 112 .
  • Access Manager 40 generates a synchronization (sync) record to facilitate cache flushing.
  • Access Manager 40 passes a cache flush request and the newly generated synchronization record to each Access Server 34 .
  • FIG. 54 provides a block diagram of a synchronization record in accordance with the present invention.
  • Synchronization record 2040 includes the current GSN 2042 assigned to the change detected in step 2010 of FIG. 53 .
  • Synchronization record 2040 also includes IDs 2044 , which identify the data affected by the detected change, such as the policy domain, first level rules, policy, second level rules, etc.
  • Synchronization record 2040 also indicates what type of change 2046 was detected (e.g. whether it be an addition, modification, or deletion).
  • Time 2048 is also stored, indicating the time at which the change was detected in step 2010 .
  • FIG. 55 provides a flow chart detailing steps performed by Access Server 34 in response to receiving a synchronization record 2040 from Access Manager 40 .
  • Access Server 34 receives a synchronization record and flush request.
  • Access Server 34 updates its stored GSN by replacing the stored GSN with the synchronization record GSN (step 2066 ).
  • Access Server 34 then flushes the cached information identified by elements 2044 , 2046 , and 2048 of synchronization record 2040 .
  • Access Server 34 then stores synchronization record 2040 on Access Server 34 (step 2070 ).
  • FIG. 56 provides a flow chart detailing the steps performed by Web Gate 28 for flushing and synchronizing its caches in accordance with the present invention.
  • Web Gate 28 issues a request to Access Server 34 .
  • Access Server 34 Upon serving the request, Access Server 34 returns the value of its stored GSN 554 (step 2102 ) to Web Gate 28 .
  • Web Gate 28 compares the GSN 544 returned in step 2102 with GSN 510 stored by Web Gate 28 (step 2104 ).
  • Web Gate 28 requests all synchronization records 550 stored on Access Server 34 having GSN's greater than GSN 510 stored on Web Gate 28 or appearing in sync record table 518 .
  • Web Gate 28 flushes data having ID's 2044 (specified in synchronization record 2040 received from Access Server 34 ) from its caches (step 2110 ).
  • Web Gate 28 updates its GSN 510 to equal GSN 554 stored on Access Server 34 (step 2112 ).
  • Web Gate 28 maintains a sync record table 518 that identifies all sync records that have not yet been processed by Web Gate 28 . For example, a sync record will remain unprocessed if its transmission to Web Gate 28 from Access Server 34 is delayed.
  • Web Gate 28 updates table 518 by removing entries for synchronization records processed in step 2110 .
  • FIG. 57 provides a flow chart describing the process of testing access to resources using the system of FIG. 1 .
  • Access Manager 40 includes an Access Tester process.
  • the Access Tester allows an administrator, or any other authorized user, to determine who or what entities may access a resource under the current access criteria, whether a particular individual or set of individuals have access to a resource under certain conditions and whether the first level and second level rules, policies or policy domains associated with a resource operate as intended.
  • an administrator accesses the Access Tester using a GUI on Access Server 40 .
  • the system tests access to a resource without actually authenticating or authorizing access to the resource. Thus, the system is testing a successfully authenticated user's access to the resource.
  • step 2260 the administrator enters a URL (or other identities) for a resource to be tested.
  • multiple URLs can be entered so that the test is performed for multiple resources.
  • the administrator can select to test for all possible resources so that the Access Tester will determine which resources are available to the users identified for the test.
  • step 2262 the administrator selects the HTTP request methods that the administrator wants to test. If no HTTP request methods are entered, the system will test all HTTP request methods. Protocols other than HTTP can also be used. In accordance with the present invention other protocols besides HTTP can be used. If the administrator wants to know if a particular computer can access the resource, the administrator can enter the computer's IP address in step 2264 . If no IP address is entered in step 2264 , then the test will not be limited to any particular computer.
  • the administrator can enter date and time restrictions.
  • the administrator can indicate that any time and day can be used so that the timing and date restrictions do not restrict the test.
  • the administrator can enter a specific time and/or date for testing.
  • the date and time information can identify a specific date and time or ranges of dates and times.
  • policies can be configured to allow certain access by users at certain times on certain dates.
  • the administrator selects which users to test access for. The administrator can request testing for all possible users or subsets thereof. If the user desires to test for selected users, the administrator can identify individual users. Alternatively, the administrator can use filters, rules, or roles to identify subsets of users.
  • Steps 2260 - 2268 are information gathering steps. In one embodiment, they are performed by having an administrator enter information into Access Manager 40 . In other embodiments, this information is provided to the Access Tester via a file, a software process, information exchange protocols such as XML, etc.
  • Steps 2270 - 2282 are performed by the Access Tester in order to test access to the resource in question.
  • the policy domain is identified for the URL entered in step 2260 using the processes described above.
  • the system searches for a policy associated with the URL in accordance with the processes described above. If more than one URL was entered in step 2260 , than more than one policy or more than one policy domain may be identified.
  • the Access Tester chooses one user from the set of users selected in step 2268 and the identity profile for the chosen user is accessed (optional).
  • authorization is checked for that user. Step 2276 is performed in a similar manner as described above with respect to step 756 of FIG.
  • step 2272 the authorization rules for the policy are used in step 2276 . If no policy was found in step 2272 , then the default authorization rules for the policy domain are used in step 2276 .
  • the information from steps 2262 , 2264 , and 2266 , and the user's identity profile (optional) are used to determine whether the one or more applicable authorization rules are satisfied. If they are satisfied, then it is determined that the particular user is authorized to access the resource under the conditions entered in steps 2260 - 2268 . In step 2278 , it is determined whether there are more users from the set of users identified in step 2268 .
  • step 2280 If there are more users, another user is chosen in step 2280 and the identity profile for that user is accessed. After step 2280 , the method loops back to step 2276 . If there are no more users to consider (step 2278 ), then the results are displayed in step 2282 .
  • the method of displaying and/or the contents of the results in step 2282 are configurable.
  • the administrator can select whether the matching policy domain, policy and/or matching rules should be displayed.
  • One embodiment of step 2282 includes displaying a table (not shown) in a GUI listing all users. For each user, the table displays the URL in question, the request method tested, the policy domain, the policy, the authorization rules, date and time information, IP address information, and an indication of whether the user is authorized to access the resource. In one embodiment, only a configurable subset of this information is displayed. It is possible that a user may have multiple entries in the result table, for example, when the date and timing information results in access grants at some times and access denials at other times.
  • the results table allows an administrator to determine whether the policies created for a particular resource or set of resources are appropriate.
  • the administrator can use the Access Tester to determine whether specific users have appropriate access rights.
  • the Access Tester quickly allows an administrator to verify authorization rules created for particular policy domains and/or policies.
  • the results are reported in a file, in XML, on a printer, using voice, etc.
  • the results reported could include an indication that access is granted, access is denied, there is redirection to a different resource or it is undetermined (e.g. a custom authorization plug-in cannot be loaded).
  • the system of FIG. 1 can include a separate Identity Server which will perform many (or all) of the tasks associated with managing the Identity System.
  • an Identity Server would include a Publisher, a User Manager, a Group Manager and an Organization Manager.
  • the Publisher is an application that lets a user publish LDAP-based directory information about users, reporting structures, departments, offices and other resources stored in enterprise directories.
  • the User Manager is responsible for password management, certificate management, and delegation administration of user identity profiles. For example, the User Manager can create and delete users, roles, rights and credentials.
  • the Group Manager manages groups. When a company is setting up an Extranet/Internet or ASP services, the company will need to provide only certain groups of people with access to the application/resources that they are making available.
  • the entities in a group can be determined by specifically adding a person or group, or by identifying a specific attribute or value in user identity profiles. Companies can use these methods to use roles/rights management, or to grant/deny access to the applications that they will need.
  • the Group Manager will manage this group functionality, including supporting multiple types of groups, managing group ownership, group membership, group administration, etc.
  • the Organization Manager is used to manage organizations. When companies are dealing with outside partners, suppliers, or other organizations (internal or external), the companies need a way to manage those organizations including creating the entity, modifying it or deleting it.
  • Organizations can be created and removed from the system. Additionally, organizations can be managed by a manager, self managed, or managed in a delegated fashion.
  • the system can also be implemented with multiple Identity Servers.
  • Each Identity Server will have its own cache or set of caches. In one scenario, if one of the Identity Servers change it cache, it will communicate to the others to flush their cache.
  • PKI Public Key Infrastructure
  • PPP server-side hooks allow customers to extend the business logic of the Identity Systems by communicating with other systems before and after an event happens in the Identity System (or Access System).
  • Customers can hook shared libraries, Pearl scripts or any other applications that can be called from specific well defined points in the processing logic of the application.
  • PPP can be used to perform data validation and password management.
  • PPP could also be used as a notification engine (e.g. when a given action occurs, send an email).
  • the system is implemented as a three-tier architecture.
  • This allows the Identity System to be placed behind a firewall, while the only component exposed outside the firewall (or in the DMZ) is a Web Server with a Web Pass plug-in.
  • the Web Pass plug-in is a plug-in for the Web Server that communicates with the Identity Server.
  • the Web Pass Plug-in is analogous to the Web Gate for the access system. This allows customers to run the system with enhanced security and provides another point to do fail over, load balance and utilize redundant servers.
  • system of FIG. 1 can accept input in XML format and provide output in XML format. Additionally, the system will make use of XML remote procedure calls (RPC).
  • RPC XML remote procedure calls
  • the system could attempt to validate data on input. If a user or application enters data into the system that is outside predefined constraints, the data will be rejected.
  • Access System authorization rules and actions can be created by third party developers through an API. In one embodiment, these custom authorization rules and actions are programmed in C code. In another embodiment, custom authorization rules and actions can reside in an Access System with pre-existing authorization rules and actions.
  • “affiliate” Web Gates are installed on remote Web Servers to provide single sign-on authentication across multiple organizations.
  • the affiliate Web Gates can access Web Gates of the Access System, but cannot directly communicate with Access Server 34 .
  • a first company may maintain a web site protected by an Access System in accordance with the present invention. If the first company agrees to allow customers of a second company to access a subset of resources on the first company's web site, an affiliate Web Gate will be installed on the second company's web server. When a customer of the second company requests resources from this subset, the affiliate Web Gate will request a Web Gate of the Access System to authenticate the customer. The Access System Web Gate will return a successful or unsuccessful authentication result to the affiliate Web Gate.
  • FIG. 4 shows a hierarchical directory structure.
  • Other data structures can also be used.
  • One example of a suitable alternative is a flat data structure that does not include a hierarchy.
  • Another suitable example includes a fat tree, which is a hierarchy that has few levels and each level is wide (a lot of nodes).
  • One additional feature that can be used with various data structures is the implementation of a variable search base.
  • a user can access the entire hierarchy, subject to access rules and localized access filters.
  • users will be limited to only accessing portions of the hierarchy.
  • the system can be set up so that users underneath a particular node in the hierarchy can only access other nodes below that particular node. This restriction on access is done before applying any access criteria and localized access filters, and can be thought of as restricting the search base.
  • the top root of the hierarchy can then vary on a per user or group basis.
  • Another alternative embodiment for the Identity System is allow the flow of managing user identity profiles to be configurable so that they can match the procedures of the company or entity.
  • Policy domain information and policy information can be stored with a resource, with a resource's information in the directory server or in a location on the directory server (or elsewhere) for storing sets of policy domain information and policy information. Additionally, the above described system can work with one directory server or multiple directory servers.
  • FIG. 58 is a block diagram that depicts an alternative embodiment that allows applications to use an application program interface (API) to accesses authentication and authorization services of an Access Server.
  • API application program interface
  • the term “application” pertains to a broad range of the software including stand-alone programs, servlets, applets, enterprise java beans (EJB), server pages, etc.
  • the embodiment of FIG. 58 allows applications to authenticate users using access system defined authentication schemes, import user session state from cookies and authorize user requests for resources.
  • FIG. 58 shows web browser 3002 and Web browser 3004 connecting to Web Server 3008 and application server 3040 via the Internet (or other network) 3006 .
  • Web Server is 3008 includes a Web Gate 3010 .
  • Web server is 3008 can be used to access resource 3012 or resource 3014 , as discussed above.
  • Web Gate 3010 can communicate with Access Server 3016 and Access Server 3016 utilizes Directory Server 3018 , as discussed above.
  • FIG. 58 also shows Application Server 3030 in communication with Web Server 3012 .
  • Application server 3030 can include any set of applications.
  • application server 3030 may include servlets 3032 and EJBs 3034 .
  • the applications on application server 3032 can communicate with the access system using the Access Server API 3036 .
  • FIG. 58 shows servlets 3032 and EJBs 3034 in communication with Access Server API 3036 .
  • Access Server API 3036 is in communication with Access Server 3016 .
  • a web browser sends a request to Web server 3008 .
  • Web server 3008 forwards that request to servlets 3032 .
  • Servlet 3032 in combination with EJB 3034 , communicates with Access Server API 3362 to authenticate and authorize the user of the web browser.
  • the applications on application server 3030 can access many of the authentication and authorization services from Access Server 3016 by using the Access Server API 3036 . Additionally, other types of applications different from the servlet/EJB configuration depicted will work with the present invention.
  • Application server 3030 can also include one or more resources 3031 .
  • a web browser can send a request directly to an application server, without first going through a Web server.
  • web browser 3002 can send a request directly to application server 3040 (via the Internet).
  • Application server 3040 is not connected behind a web server, a Web Gate or any other web agent; therefore, it does not have a web agent front end.
  • a web agent is a component (usually software, but can be hardware or a combination of hardware and software) that plugs into (or otherwise integrates with) a web server (or equivalent) in order to participate in providing access services.
  • a Web Gate is one example of a web agent.
  • Application server 3042 includes applications 3042 . As discussed above, applications 3042 can be any suitable application that can run on application server 3040 .
  • Application server 3040 also includes Access Server API 3036 , which is in communication with Access Server 3016 .
  • application server 303 can also include one or more resources 3041 .
  • the Access Server API is available on a platform other than an application server.
  • a stand alone application that is not on an application server may use the Access Server API.
  • the applications that can use the API are not limited to applications on an application server.
  • the applications can be any executable build using the Access Server API.
  • the Access Server API will include a set of one or more libraries of classes, functions, procedures, etc. that can be called by an application program to access services from Access Server 3016 .
  • the Access Server API provides an interface for Java, C and C++, the Access Server API includes five classes: an authentication scheme class (ObAuthenticationScheme), a resource request class (ObResourceRequest), a user session class (ObUserSession), a configuration class (ObConfig), and an access exception class(ObAccessException).
  • ObAuthenticationScheme an authentication scheme class
  • ObResourceRequest resource request class
  • ObUserSession user session class
  • ObConfig configuration class
  • access exception class(ObAccessException) Each of these by classes are defined below. Note that other embodiments include a different set of classes to achieve similar functionality and include more or less than five classes.
  • the authentication scheme class is used to create ObAuthenticationScheme objects.
  • ObAuthenticationScheme objects represent authentication schemes defined through the Access System and used in the authentication rules for policy domains and policies.
  • An authentication scheme specifies how a user is to be challenged for a set of credentials, name-value string pairs (for example, username and password) that are used to authenticate a user.
  • An authentication scheme has the following elements:
  • Name Scheme Value realm basic the authentication domain (e.g. an LDAP directory) form form the URL of the login form to be displayed to the user creds form a space-separated list of login form fields to be used as credentials action form the URL to which the login form posts its data
  • authentication domain e.g. an LDAP directory
  • form form the URL of the login form to be displayed to the user creds form a space-separated list of login form fields to be used as credentials action form the URL to which the login form posts its data
  • the resource request class is used to create an ObResourceRequest object.
  • An ObResourceRequest objects represent requests to access resources, including
  • the ObResourceRequest constructors get policy information about the resource request from the access system:
  • ObResourceRequest objects are used by the ObAuthenticationScheme constructors to retrieve information about the resource's authentication scheme and by the isAuthorized( ) method of the ObUserSession class to determine if a user is authorized to access the resource.
  • isAuthorized( ) method of the ObUserSession class to determine if a user is authorized to access the resource.
  • Java public class ObResourceRequest ⁇ public ObResourceRequest(String resType, String res, String operation) throws ObAccessException; public ObResourceRequest(String resType, String res, String operation, Hashtable parameters) throws ObAccessException; public String getResourceType( ); public String getResource( ); public String getOperation( ); public Hashtable getParameters( ); public boolean isProtected( ) throws ObAccessException; public Object clone( ); public void finalize( ); ⁇ C++ class ObResourceRequest ⁇ public: ObResourceRequest( ); // empty ObResourceRequest(const char *resType, const char *res); ObResourceRequest(const char *resType, const char *res, const char *op); ObResourceRequest(const char *resType, const char *res, const char *op,
  • the user session class is used to create ObUserSession objects.
  • ObUserSession objects represent a user who has successfully authenticated.
  • a user session object is initially created through a constructor that authenticates the user.
  • One constructor takes an ObResourceRequest object and an ObMap of credentials.
  • the resource request determines the authentication scheme that is to be applied to the credentials to authenticate the user.
  • the resource request also determines other aspects of authentication policy: success or failure actions and audit rules.
  • a session token string is a serialized representation of the user session, for example, from the cookie stored on the client (see FIG. 37 ).
  • a user session object can be constructed from a valid session token, and a session token can be generated from a user session object.
  • a session token stored in a cookie is encrypted.
  • the ObUserSession object can get the key (shared secret) from the directory server to decrypt the session token.
  • the application communicating with the API does not have access to the key (shared secret).
  • the application must make a request to the ObUserSession object by calling one of the methods listed below, which will return the desired information in an unencrypted form.
  • the session token stored in a cookie could have been originally created by the API or via a Web Gate.
  • Java public class ObUserSession ⁇ public ObUserSession( ); // empty public ObUserSession(ObResourceRequest res, Hashtable credentials) throws ObAccessException; public ObUserSession(ObResourceRequest res, Hashtable credentials, String location) throws ObAccessException; public ObUserSession(String sessionToken) throws ObAccessException; public String getUserIdentity( ); public int getLevel( ); public String getLocation( ); public int getStartTime( ); public int getLastUseTime( ); public int getNumberOfActions(String actionType); public Hashtable getActions(String actionType); public String getAction(String actionType, String name); public String[ ] getActionTypes( ); public int getStatus( ); public int getError( ); public String getErrorMessage
  • the ObConfig class includes class (static) methods to initialize and shutdown the Access Server API and to get part or all of the configuration for the client.
  • the initialize( ) method does the following:
  • shutdown( ) method There is a shutdown( ) method that can be called to release resources when an application no longer needs to use the Access Server API.
  • code for Java, C and C++ is code for Java, C and C++.
  • Name Value Id string identifier for application specifies the client's configuration in the policy directory cacheTimeout seconds that a cached authentication scheme or resource- request object will exist before it is automatically flushed. 0 means cache elements will never be flushed. maxCacheElements maximum number of cached resource-request objects. The size of the authentication scheme cache is fixed. failoverThreshold if the number of connections to primary Access Servers falls below this threshold, the Access API will open connections to secondary Access Servers. Debug on or off. The interpretation is up to the application. WebGate with debug on traces all messages to Access Servers.
  • maxConnections the maximum number of connections that will be opened to Access Clients sessionTimeout seconds that a user session created by the application will be valid idleTimeout seconds between authorization class that invalidate a session accessServerTimeout seconds that a connection to an Access Server will be left open before it is re-established SleepFor how often (in seconds) that the client checks that its Access Server connections are up preferredHost For WebGate, the user's browser will be redirected to this form of the web server host address if it did not originally specify it. Other applications are free to interpret or ignore this as needed.
  • primaryDomain For WebGate the domain to be used in setting cookies, e.g. the single signon domain. Other applications are free to interpret or ignore this as needed. state enabled or disabled. The interpretation is up to the application.
  • a disabled WebGate immediately allows access to all resources.
  • primaryServers the Access Servers to which the client will connect to first; a space-separated list of the format host1:port1, numConn1 host2:port2, numConn2 . . .
  • secondaryServers the Access Servers to which the client will connect to if the number of connections to the primary servers falls below the failoverThreshold; a space-separated list of the format host1:port1, numConn1host2:port2, numConn2 . . .
  • Each exception can have from zero to five parameters that inserted in a message defined in the ObAccessClient.msg catalog. Below is the code for the API pertaining to the ObAccessException object:
  • ObAccessException_AS_UNKNOWN 300, ObAccessException_ENGINE_DOWN, ObAccessException_NOCODE, ObAccessException_NULL_RESOURCE, ObAccessException_HOSTPORT_LOOKUP_FAILED, ObAccessException_URL_LOOKUP_FAILED, ObAccessException_SD_LOOKUP_FAILED, ObAccessException_WROR_LOOKUP_FAILED, ObAccessException_WROR_AUTHENT_LOOKUP_FAILED, ObAccessException_NO_AUTHENT_SCHEME, ObAccessException_EXCEPTION, ObAccessException_INVALID_SCHEME_ID, ObAccessException_INVALID_SCHEME_MAPPING, ObAccessException_INVALID_SCHEME_PARAMETERS, ObAccessException_NO_USER, ObAccessException_NONUNIQUE_USER, ObAccessException_USER_REVOKED, ObAccessException_MISSING_OBCRED_PASSWORD, ObAccessException_WRONG_PASSWORD, ObAccessException_MISS
  • the Access Server API allows a C program to define an exception handler function that is called when an exception is generated.
  • FIG. 59 is a flow chart describing one embodiment of the operation of the components of FIG. 58 when a user sends a request to access a resource using a web browser.
  • the method of FIG. 59 pertains to a request being sent to an application (e.g. servlet, EJB, etc) on application server 3040 or to a stand alone application running on any suitable platform having access to the Access Server API.
  • the request is received by application 3042 .
  • the request can be an HTTP request or a request using another protocol. If the request does not include the contents of a cookie (step 3102 ), then the user must be authenticated and authorized in step 3104 .
  • the request includes information from a cookie (step 3102 ) then that information is accessed in step 3106 .
  • the information from the cookie (see above) is called a session token.
  • a session token is encrypted as described above.
  • the session token is accessed from the request in step 3106 .
  • a resource request object (ObResourceRequest) is created using information from the request.
  • the resource request object is passed the resource type, the name of the resource, the operation being performed on the resource, and optional parameters which may include post data and/or query string data.
  • an authentication scheme object (ObAuthenticationScheme) is created.
  • the constructor for the authentication scheme object is passed the resource request object.
  • a user session object (ObUserSession) is created.
  • the constructor for the user session object is passed the session token.
  • the key for decrypting the session token is fetched from the directory server (if it is not already local), the session token is decrypted and the contents of the session token is stored in the new object.
  • the system determines whether the cookie is valid. There are many ways for determining if the cookie is valid. In one example, the application can request information from the user session object such as the start time or last use time to determine whether the session is still valid.
  • step 3116 the application requests the authentication level from the authentication scheme object.
  • the application can call the get Level( ) method from theObAuthenticationScheme object.
  • This authentication level pertains to the authentication rule or policy stored in the directory server for the resource.
  • the different portions of the authentication scheme or all portions of the authentication scheme can be reported to the application by the API.
  • the application requests the authentication level from the session object; for example, calling the getLevel( ) method from the ObUserSession object.
  • This level information is a number originally stored (and encrypted) in the cookie.
  • the ObUserSession provides the level in an unencrypted form.
  • step 3122 the application determines whether the authentication level in the cookie is less than or equal to the authentication level stored in the directory server for the resource. If so, then the user is properly authenticated for the resource, but still needs to be authorized to access the resource in step 3124 . Because the user has already been properly authenticated, there is no need to request that the user provide any credentials (username, password, certificate, information for a form, etc). If the authentication level from the cookie is greater than the authentication level from the directory server, then user must be authenticated and authorized in step 3126 .
  • FIG. 60 is a flow chart describing one embodiment of authenticating and authorizing a user with the components of FIG. 58 .
  • Steps 3104 , 3116 and 3126 of FIG. 59 perform the method of FIG. 60 .
  • a resource request object is created, if it has not already been created.
  • an authentication scheme object is created, if it has not already been created.
  • One example of performing step 3206 includes calling the isProtected( ) method of the resource request object.
  • the Access Server determines whether the resource is protected as described above.
  • the application If the resource is not protected the application will allow the user to access the requested resource. If the resource is protected, the application accesses the authentication scheme in step 3208 .
  • One means for determining the resource authentication scheme is to use the various methods of the ObAuthenticationScheme class, described above.
  • the application requests authentication credentials from the user and stores the credentials in a table in step 3212 .
  • the authentication credentials can be any data needed to authenticate.
  • a basic authentication credentials may include a username and a password. The exact type of credentials not important to the present invention.
  • the credentials is stored in a hash table.
  • a user session object is created, if it has not already been created. The user session object is passed the resource request object and credentials stored in the table.
  • the constructor of the user session object uses the resource request object and the credentials to authenticate the user in step 3216 .
  • the process of authentication is performed by the Access Server as described above. If the user is not properly authenticated (step 3222 ), then the application will send a response to a web browser in step 322 that the authentication failed and the user will not be given access to the resource.
  • the application will request a session token from the API in step 3226 .
  • the session token can be requested using the method getSessionToken( ) of the ObUserSession class.
  • a session token is added to a cookie stored on a client device.
  • the application request the API to authorize the user.
  • One embodiment step 3234 includes calling the isAuthorized( ) to method.
  • the access system will attempt to authorize user to access the requested resource. The process of authorization is performed by the Access Server as described above.
  • step 3240 is optional. In one embodiment, the application will only request the authorization actions. In step 3242 , the application will perform the authorization actions and (optionally) the audit rules. In one embodiment, the application can include log files for auditing.
  • step 3252 the application requested API for the authorization actions and/for rules.
  • step 3254 the application performs the actions/audit rules. As discussed above with respect to authorization success, steps 3252 and 3254 are optional.
  • the application only accesses the authorization actions and not the audit rules.
  • FIG. 61 is a flow chart describing the process of authorizing a user to access the resource without requesting additional authentication credentials and performing the full authentication process. The process of FIG. 61 is performed during step 3124 FIG. 59 .
  • step 3302 it is determined whether the resource being requested is protected. As discussed above, one option for performing step 3302 is to call the isProtected( ) method of the resource request object. If the resource is not protected, then the application allows the user to access the resource in step 3304 . If the resource is protected, then the application requests the API to authorize the user in step 3306 . The request to authorize uses the resource request object and the user session object. For example, step 3306 includes calling the isAuthorized( ) method of the user session object.
  • step 3308 the Access Server determines whether the user is authorized using the processes discussed above. If the user is authorized (step 3308 ), the application will allow access to the resource in step 3310 . In step 3312 , the application will request and receive the authorization actions and audit rules, and perform the necessary actions (and optional logging). If the user was not authorized to access the resource, then in step 3320 the application responds to the browser that authorization has failed. In step 3322 the application requests and receives the authorization actions and audit rules, and then performs necessary actions and/or logging (step 3322 is optional).
  • FIG. 62 is a flow chart describing, from a high level how a single sign-on (a user providing authentication credentials) can be used to access multiple resources.
  • the various steps of FIG. 62 use the particular methods described above.
  • a user requests access to a first resource. This request is received by an application or a Web Gate. The user is authenticated in step 3402 and a cookie is stored on the user's machine in step 3404 .
  • the user is authorized to access the first resource. Subsequent to step 3406 , the user requests access to a second resource. The request for access to the second resource is received by an application.
  • step 3410 the application, in conjunction with the API, authorizes the user to access the second resource without requesting the user to provide additional credentials for a full authentication. That is, the application receives the information from the cookie (the session token) and provides that session token to the API. If the information in the session token indicates that authentication is not necessary, then the user will not be requested to provide any additional credentials.
  • the application receives the information from the cookie (the session token) and provides that session token to the API. If the information in the session token indicates that authentication is not necessary, then the user will not be requested to provide any additional credentials.
  • the Access Server API should protect against several kinds of attacks. First, someone intercepting messages should not be able to obtain policy information or user attribute information. To protect against this, the messages must be encrypted with an algorithm and key strong enough to make cryptoanalysis of the messages infeasible. Second, someone with the Access Server API library and knowledge of the location of an Access Server must not be able to call the API to obtain policy or user information, unless specifically authorized to do so.
  • the API client should authenticate itself to the Access Server, and the Access Server must apply appropriate authorization for the API client's requests.
  • API client includes the WebGate web server agent as well as customer applications calling the Access Server API.
  • the protocol for communicating with the Access Server provides three security modes, in increasing security and administrative overhead: open, simple, and cert.
  • open simple, and cert.
  • cert When an API client connects to an Access Server, both sides send an indication of their configured security modes. If the configured client and server security modes do not match, the connection is terminated.
  • Open mode provides no encryption. Consequently, policy and user information sent between the clients and servers cannot be protected against disclosure or alteration. Open mode is therefore not recommended in environments where the communication channels are not trusted.
  • Simple mode is intended to provide strong encryption between clients and servers without requiring a full public key infrastructure (PKI).
  • PKI public key infrastructure
  • TLS Transport Layer Security
  • Triple-DES symmetric encryption is used with a strong key randomly generated for each client-server connection and the RSA public key protocol is used to exchange the key between the client and server.
  • RSA Transaction Layer Security
  • each client and server has a public/private key pair and an X.509 certificate, generated by the access system when the component is installed. All simple mode certificates are signed by a private key built into the access system, so anyone with access to an installation can generate a valid certificate. Consequently the certificates cannot be trusted for authentication between the client and server.
  • simple mode adds an additional password challenge authentication protocol on top of TLS.
  • the client and the server each share a secret password, supplied either in a local configuration file or interactively when the component is started.
  • the server sends the client a challenge and the client generates a response by computing the MD5 digest of the challenge, a key derived from the password, and TLS connection data.
  • the server authenticates the client by re-computing the digest from the same challenge, key, and TLS data and comparing it to the client's response.
  • the client challenges and authenticates the server.
  • Cert mode provides strong encryption between clients and servers using TLS with triple-DES encryption and RSA key exchange, just as in simple mode. But in cert mode, the client and server X.509 certificates are issued by a trusted certificate authority (CA) like VeriSign, so they can be used for mutual authentication between the client and the server. Consequently, the additional password challenge protocol in simple mode is not required.
  • CA trusted certificate authority
  • Access clients (WebGates and applications that use the Access Server API) have a password that is defined by a system administrator using the Access Client page of the Access System Configuration component. When an access client is configured, the client's password should be entered. The client password is encrypted and stored in a local configuration file, as well as the client's configuration entry in the policy directory.
  • an access client When an access client connects to an Access Server, the client sends the server its ID and they exchange randomly generated challenges. Each side then computes and sends to its peer the MD5 digest of the peer's challenge and the client's password, and the peer checks the received digest against its own computation of the digest. The connection is allowed only if the digest check is successful on both sides. Consequently, an access client can only connect to an Access Server if it is configured in the policy directory and both the client and the server know the same client password. Since digests of the password and challenge are exchanged instead of the password itself, this authentication method can be used safely over an unencrypted connection.
  • Client authentication is done independently of the security mode, so the same challenge-password digests are exchanged over open, simple, and cert mode connections. This leads to multiple passwords in some modes.
  • simple mode there is the global NAP password, the local certificate (PEM) file password and the password for each client.
  • cert mode there is the local certificate (PEM) file password and the password for each client.
  • the first set of pseudo code authenticates a user, (using a basic userid and password) and checks if that user is authorized to access a specified URL:
  • ObResourceRequest res new ObResourceRequest(“http”, url, method); if (res.isProtected( )) ⁇ // Check if the required authentication scheme is basic.
  • ObAuthenticationScheme authnScheme new ObAuthenticationScheme(res) if (authnScheme.isBasic( )) ⁇ System.out.printIn(“BASIC REALM : ” + authnScheme.getChallengeParameter(“realm”)); // Authenticate using the userid and password
  • Hashtable credentials new Hashtable( ); credentials.put(“userid”, userid); credentials.put(“password”, password);
  • the second set of pseudo code is a servlet fragment that gets a session token from a cookie (set by a WebGate or an application using the API) and determines if the user is authorized to access a requested URL. If the user's request is authorized, the requested resource is constructed. If the request is not authorized, a Not Authorized response is returned.

Abstract

An access system provides identity management and/or access management services for a network. An application program interface for the access system enables an application without a web agent front end to read and use contents of an existing encrypted cookie to bypass authentication and proceed to authorization. A web agent is a component (usually software, but can be hardware or a combination of hardware and software) that plugs into (or otherwise integrates with) a web server (or equivalent) in order to participate in providing access services.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
This application is a continuation of U.S. patent application Ser. No. 11/588,604, filed Oct. 27, 2006, by Knouse et al. and entitled “Access System Interface”, now U.S. Pat. No. 7,458,096 issued Nov. 25, 2008, which is a continuation of U.S. patent application Ser. No. 09/814,091, filed Mar. 21, 2001 by Knouse et al. and entitled “Access System Interface” now U.S. Pat. No. 7,185,364 issued Feb. 27, 2007, the entire disclosure of which is incorporated herein by reference.
This Application is related to the following Applications:
User Authentication, Marterus, et al. U.S. patent application Ser. No. 09/793,658, filed on Feb. 26, 2001, now U.S. Pat. No. 7,194,764 issued Mar. 20, 2007; Access Tester, by Christine Wai Han Chan, U.S. patent application Ser. No. 09/792,918, filed on Feb. 26, 2001, now U.S. Pat. No. 7,464,162 issued Dec. 9, 2008; Cache Flushing, by Joshi, et al., U.S. patent application Ser. No. 09/792,911, filed on Feb. 26, 2001 now U.S. Pat. No. 7,124,203 issued Oct. 17, 2006; Post Data Processing, by Knouse, et al., U.S. patent application Ser. No. 09/793,196, filed on Feb. 26, 2001, now U.S. Pat. No. 7,249,369 issued Jul. 24, 2007; Localized Access, by Ramamurthy, et al., U.S. patent application Ser. No. 09/793,354, filed on Feb. 26, 2001, now U.S. Pat. No. 7,080,077 issued Jul. 18, 2006; Query String Processing, by Crosbie, et al., U.S. patent application Ser. No. 09/793,355, filed on Feb. 26, 2001, published as U.S. Pat. Pub. No. 2002/0099671 on Jul. 25, 2002; Logging Access System Events, by Joshi, et al., U.S. patent application Ser. No. 09/792,915, filed on Feb. 26, 2001, published as U.S. Pat. Pub. No. 2002/0116642 on Aug. 22, 2002; Providing Data To Applications from an Access System, by Joshi, et al., U.S. patent application Ser. No. 09/792,934, filed on Feb. 26, 2001, now U.S. Pat. No. 7,134,137 issued Nov. 7, 2006; and Intrusion Threat Detection, by Jeffrey D. Hodges, U.S. patent application Ser. No. 09/793,320, filed on Feb. 26, 2001, published as U.S. Pat. Pub. No. 2002/0112185 on Aug. 15, 2002.
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention is directed to an application program interface (API) for an access system.
2. Description of the Related Art
As the impact of the Internet continues to alter the economic landscape, companies are experiencing a fundamental shift in how they do business. Business processes involve complex interactions between companies and their customers, suppliers, partners, and employees. For example, businesses interact constantly with their customers—often other businesses—to provide information on product specification and availability. Businesses also interact with vendors and suppliers in placing orders and obtaining payments. Businesses must also make a wide array of information and services available to their employee populations, generating further interactions. To meet new challenges and leverage opportunities, while reducing their overall cost-of-interactions, many organizations are migrating to network-based business processes and models. Among the most important of these is Internet-based E-business.
To effectively migrate their complex interactions to an Internet-based E-business environment, organizations must contend with a wide array of challenges and issues. For example, businesses need to securely provide access to business applications and content to users they deem authorized. This implies that businesses need to be confident that unauthorized use is prevented. Often, this involves the nontrivial, ongoing task of attempting to tie together disparate, system-specific authentication and/or authorization schemes under one access system.
To meet these challenges, an E-business host company needs an access system that delivers the ability to effectively secure and manage all the various network-based interactions. An appropriate access system should be able to provide authentication and authorization services while accommodating all participants involved with the E-business, whether they are local or remote. It must also be able to distinguish between the E-business' employees and all the users who are affiliated with the E-business host's customers, suppliers and/or partners.
Prior to authorizing a user to access a resource, access systems typically will authenticate a user. That is, they will verify the identity of the user. After a user successfully authenticates for a first protected resource, the user may request access to a second resource. If the second resource is also protected, the user may be required to perform a second authentication for the second resource. However, it may be redundant to force the user to re-authenticate for the second resource, especially if the previous authentication occurred relatively recently. Requiring repetitive re-authentications can unduly burden both users and networks, causing reduction in productivity and degradation in network performance.
Another shortcoming of some previous access systems is that the services are provided within the access system and cannot be accessed by other applications. Some users may require that an application not part of the access system participate in the process of granting access to resources. To accomplish this, a user may wish to program an application to provide a subset of the authentication/authorization features, and be able to access various services and data inside the access system. Previous attempts to provide an interface to an access system have required the application trying to interface with the access system to be positioned behind a web agent that is part of the access system. Such a configuration is inefficient, increases costs and increases maintenance efforts.
Some access systems may store a cookie on a client machine to save state information and assist in future authentication processes. However, prior access systems do not provide for an application outside the access system, not having a web agent front end, to be able to use the cookie and access the contents of the cookie in order to participate in providing authentication or authorization services.
Therefore, a solution is needed to allow an application that does not have a web agent front end to interface with an access system. Furthermore, it would be additionally advantageous if the application can provide authentication services such that users are not forced to unnecessarily provide authentication criteria every time they access protected resources.
SUMMARY OF THE INVENTION
The present invention, roughly described, provides for an application program interface for an access system that enables an application without a web agent front end to use contents of an existing cookie (or other storage mechanism) to provide access system services. A web agent is a component (usually software, but can be hardware or a combination of hardware and software) that plugs into (or otherwise integrates with) a web server (or equivalent) in order to participate in providing access services.
One embodiment of the present invention includes the steps of receiving user session state information for a first user, receiving resource request information for a first resource and receiving a request to authorize the first user to access the first resource. The request to authorize is from an application without a web agent front end. The request is received by the access system interface of the present invention. In response to the requests, the present invention attempts to authorize the first user to access the first resource without requiring the first user to re-submit authentication credentials
In one implementation, the user session state information is encrypted and stored in a cookie. The step of receiving user session state information includes decrypting the user session state information. The system is also capable of receiving a request from the application for unencrypted data from the user session state information and providing the unencrypted data from the user session state information to the application. In one option, the application does not have access to a key to decrypt the data in the user session state information.
Another embodiment of the present invention includes a method for providing access services by an application without a web agent front end The method includes receiving an electronic request from a first user to access a first resource. The step of receiving includes receiving information from a cookie. The application provides the information from the cookie to an access system interface and requests the access system interface to authorize the first user to access the first resource based on information from the user's request and based on the information from the cookie.
Another embodiment of the present invention includes the steps of authenticating a first user, causing user session state information to be stored at a client for the first user, and authorizing the first user to access a first protected resource. Subsequently, the system receives a request from an application without a web agent front end to allow the first user to access a second protected resource. The step of receiving a request includes receiving the user session state information from the application. The system allows the first user to access the second protected resource without requiring the first user to re-submit authentication credentials, if the first user is authorized to access the second protected resource.
Different embodiments of the present include application program interfaces for various programming languages. For example, the present invention can provide an interface for Java, C, C++, etc. Note, however, that almost any other programming language, tools, scheme, etc. can be supported by the present invention.
The present invention can be implemented using hardware, software, or a combination of both hardware and software. The software used for the present invention is stored on one or more processor readable storage devices including hard disk drives, CD-ROMs, DVDs, optical disks, floppy disks, tape drives, RAM, ROM or other suitable storage devices. In alternative embodiments, some or all of the software can be replaced by dedicated hardware including custom integrated circuits, gate arrays, FPGAs, PLDs, and special purpose computers. Hardware that can be used for the present invention includes computers, handheld devices, telephones (e.g. cellular, Internet enabled, etc.), etc. Some of these devices includes processors, memory, nonvolatile storage, input devices and output devices.
These and other objects and advantages of the present invention will appear more clearly from the following description in which the preferred embodiment of the invention has been set forth in conjunction with the drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram depicting the components of one embodiment of the present invention.
FIG. 2 is a block diagram depicting the components of the computing system that can be used with the present invention.
FIG. 3 is a block diagram depicting the components of a Directory Server.
FIG. 4 is an example of a directory tree structure.
FIG. 5 is a flow chart describing a process for setting up access rules for an Identity Management System.
FIG. 6 is a flow chart describing a process for editing an attribute access criteria.
FIG. 7 is a flow chart describing a process for configuring localized access.
FIG. 8 is a flow chart describing a process for controlling access to attributes in the Identity Management System.
FIG. 9 is a flow chart describing a process for determining access to attributes of a target.
FIG. 10 is a flow chart describing a process for determining whether there is a localized access violation for a class.
FIG. 11 is a flow chart describing a process for determining whether there is localized access for an attribute.
FIG. 12 is a flow chart describing a process for modifying an attribute.
FIG. 13 is a flow chart describing the active automation process.
FIG. 14 is a block diagram depicting the components of a Web Gate.
FIG. 15 is a block diagram depicting the components of an Access Server.
FIG. 16 is a flow chart describing a process for creating a policy domain.
FIG. 17 is a flow chart describing a process for adding an authorization rule.
FIG. 18 is a flow chart describing a process for adding header variables to an HTTP request.
FIG. 19 is a flow chart describing a process for adding an authentication rule.
FIG. 20 is a flow chart describing a process for configuring an audit rule.
FIG. 21 is a flow chart describing a process for creating a policy.
FIG. 22 is a flow chart describing an exemplar process performed by the Access System of one embodiment of the present invention.
FIG. 23 is a flow chart describing a process for determining whether a particular resource is protected.
FIG. 24 is a flow chart describing a process for mapping a resource with a policy domain.
FIG. 25 is a flow chart describing a process for retrieving first and second level authentication rules.
FIG. 26 is a flow chart describing a process for determining whether a resource URL matches a specific policy URL.
FIG. 26A is a flow chart describing a process for determining whether a resource matches a specific policy using POST data.
FIG. 27 provides a block diagram of a retainer data structure.
FIG. 28 is a flow chart describing authentication.
FIG. 29 is a block diagram depicting various components involved in the authentication process.
FIG. 30 is a flow chart describing a process for authentication.
FIG. 31 is a flow chart describing a process for retrieving an authentication challenge scheme from a Directory Server.
FIG. 32 is a flow chart describing a method for performing basic authentication.
FIG. 33 is a flow chart describing the process performed by an Access Server to authenticate using a user ID and password.
FIG. 34 is a flow chart describing form authentication.
FIG. 35 is a flow chart describing a process for client certificate authentication.
FIG. 36 is a flow chart describing a process for authenticating a user using certificates.
FIG. 37 is a block diagram depicting the components of one embodiment of an encrypted cookie.
FIG. 38 is a flowchart describing a process for authorization.
FIG. 39 is a flow chart describing the steps performed when passing authorization information using POST data.
FIG. 40 is a block diagram of an exemplar HTTP request.
FIG. 41 is a flow chart describing a process for obtaining first and second level authorization rules from a Directory Server.
FIG. 42 is a flow chart describing a process for evaluating an authorization rule.
FIG. 43 is a flow chart describing a process for applying an authorization rule to extracted POST data.
FIG. 44 is a flow chart describing a process for performing authentication success actions.
FIG. 45 is a flow chart describing a process for performing authentication and authorization failure actions.
FIG. 46 is a flow chart describing a process for performing authorization success actions.
FIG. 47 is a flow chart describing a process for using header variables.
FIG. 48 is a flow chart describing the steps performed by the auditing module of one embodiment of the present invention.
FIG. 49 is a flow chart describing a method for retrieving first and second level audit rules.
FIG. 50 is a block diagram depicting one embodiment of components used for intrusion detection.
FIG. 51 is a flow chart describing a process for detecting intrusions.
FIG. 52 is a flow chart describing a process performed at a security server as part of a process for detecting intrusions.
FIG. 53 is a flow chart describing a process for flushing/synchronizing caches performed by an Access Manager.
FIG. 54 is a block diagram depicting a synchronization record.
FIG. 55 is a flow chart describing a process for flushing/synchronizing caches performed by an Access Server.
FIG. 56 is a flow chart describing a process for flushing/synchronizing caches performed by a Web Gate.
FIG. 57 is a flow chart describing a process for testing access criteria.
FIG. 58 is a block diagram of another embodiment of the present invention.
FIG. 59 is a flow chart of a process for receiving and acting on a request according to the embodiment of FIG. 58.
FIG. 60 is a flow chart of a process for authentication and authorizing according to the embodiment of FIG. 58.
FIG. 61 is a flow chart of 60 is a flow chart of a process for authorizing according to the embodiment of FIG. 58.
FIG. 62 is a flow chart explaining the process of the single sign-on feature of to the embodiment of FIG. 58.
DETAILED DESCRIPTION
FIG. 1 depicts an Access System which provides identity management and/or access management for a network. In general, an Access System manages access to resources available to a network. The identity management portion of the Access System (hereinafter “the Identity Management System”) manages end user identity profiles, while the access management portion of the Access System (hereinafter “the Access Management System”) provides security for resources across one or more web servers. Underlying these modules is active automation, a delegation and work flow technology. The active automation technology couples the Identity and Access Management Systems by facilitating delegation of roles and rights, plus providing workflow-enabled management of end user identity profiles. A key feature of one embodiment of this system is the centralization of the repositories for policies and user identity profiles while decentralizing their administration. That is, one embodiment of the system centralizes the policy and identity repositories by building them on a directory service technology. The system decentralizes their administration by hierarchy delegated Administrative roles. Although the Access System of FIG. 1 includes an Identity Management System and an Access Management System, other Access Systems may only include an Identity Management System or only include an Access Management System.
FIG. 1 is a block diagram depicting one embodiment for deploying an Access System. FIG. 1 shows web browsers 12 and 14 accessing Web Server 18 and/or Administration Server 20 via Internet 16. In one embodiment, web browsers 12 and 14 are standard web browsers known in the art running on any suitable type of computer. FIG. 1 depicts web browsers 12 and 14 communicating with Web Server 24 and Administration Server 20 using HTTP over the Internet; however, other protocols and networks can also be used.
Web Server 18 is a standard Web Server known in the art and provides an end user with access to various resources via Internet 16. In one embodiment, there is a first firewall (not shown) connected between Internet 16 and Web Server 18, a second firewall (not shown) connected between Web Server 18 and Access Server 34.
FIG. 1 shows two types of resources: resource 22 and resource 24. Resource 22 is external to Web Server 18 but can be accessed through Web Server 18. Resource 24 is located on Web Server 18. A resource can be anything that is possible to address with a uniform resource locator (URL see RFC 1738). A resource can include a web page, software application, file, database, directory, a data unit, etc. In one embodiment, a resource is anything accessible to a user on a network. The network could be the Internet, a LAN, a WAN, or any other type of network. Table 1, below, provides examples of resources and at least a portion of their respective URL syntax:
Resource URL Encoding
Directory /Sales/
HTML Page /Sales/Collateral/index.html
CGI Script with no query /cgi-bin/testscript.cgi
CGI Script with query /cgi_bin/testscript.cgi?button=on
Application /apps/myapp.exe
A URL includes two main components: a protocol identifier and a resource name separated from the protocol identifier by a colon and two forward slashes. The protocol identifier indicates the name of the protocol to be used to fetch the resource. Examples includes HTTP, FTP, Gopher, File and News. The resource name is the complete address to the resource. The format of the resource name depends on the protocol. For HTTP, the resource name includes a host name, a file name, a port number (optional) and a reference (optional). The host name is the name of the machine on which the resource resides. The file name is the path name to the file on the machine. The port number is the number of the port to which to connect. A reference is a named anchor within a resource that usually identifies a specific location within a file. Consider the following URL: “http://www.oblix.com/oblix/sales/index.html.” The string “http” is the protocol identifier. The string “www.oblix.com” is the host name. The string “/oblix/sales/index.html” is the file name.
A complete path, or a cropped portion thereof, is called a URL prefix. In the URL above, the string “/oblix/sales/index.html” is a URL prefix and the string “/oblix” is also a URL prefix. The portion of the URL to the right of the host name and to the left of a query string (e.g. to the left of a question mark, if there is a query string) is called the absolute path. In the URL above, “/oblix/sales/index.html” is the absolute path. A URL can also include query data, which is typically information following a question mark. For example, in the URL:
http://www.oblix.com/oblix/sales/index.html?user=smith&dept=sales the query data is “user=smith&dept=sales.” Although the discussion herein refers to URLs to identify a resource, other identifiers can also be used within the spirit of the present invention.
FIG. 1 shows Web Server 18 including Web Gate 28, which is a software module. In one embodiment, Web Gate 28 is a plug-in to Web Server 18. Web Gate 28 communicates with Access Server 34. Access Server 34 communicates with Directory Server 36.
Administration Server 20 is a web-enabled server. In one embodiment, Administration Server 20 includes Web Gate 30. Other embodiments of Administration Server 20 do not include Web Gate 30. Administration Server 20 also includes other software modules, including User Manager 38, Access Manager 40, and System Console 42. Directory Server 36 is in communication with User Manager 38, Access Manager 40, System Console 42, and Access Server 34. Access Manager 40 is also in communication with Access Server 34.
The system of FIG. 1 is scalable in that there can be many Web Servers (with Web Gates), many Access Servers, and multiple Administration Servers. In one embodiment, Directory Server 36 is an LDAP Directory Server and communicates with other servers/modules using LDAP over SSL. In other embodiments, Directory Server 36 can implement other protocols or can be other types of data repositories.
The Access Management System includes Access Server 34, Web Gate 28, Web Gate 30 (if enabled), and Access Manager 40. Access Server 34 provides authentication, authorization, and auditing (logging) services. It further provides for identity profiles to be used across multiple domains and Web Servers from a single web-based authentication (sign-on). Web Gate 28 acts as an interface between Web Server 18 and Access Server 34. Web Gate 28 intercepts requests from users for resources 22 and 24, and authorizes them via Access Server 34. Access Server 34 is able to provide centralized authentication, authorization, and auditing services for resources hosted on or available to Web Server 18 and other Web Servers.
Access Manager 40 allows administrators access to manage multiple resources across an enterprise and to delegate policy administration to the persons closest to specific business applications and content. In one embodiment, administrators perform these tasks using an intuitive graphical user interface (“GUI”).
User Manager 38 provides a user interface for administrators to use, establish and/or manage identity profiles. An identity profile (also called a user profile or user identity profile) is a set of information associated with a particular user. The data elements of the identity profile are called attributes. In one embodiment, an attribute may include a name, value and access criteria. In one embodiment, an identity profile stores the following attributes: first name, middle name, last name, title, email address, telephone number, fax number, mobile telephone number, pager number, pager email address, identification of work facility, building number, floor number, mailing address, room number, mail stop, manager, direct reports, administrator, organization that the user works for, department number, department URL, skills, projects currently working on, past projects, home telephone, home address, birthday, previous employers and anything else desired to be stored by an administrator. Other information can also be stored. In other embodiments, less or more than the above-listed information is stored.
System Console 42 provides a GUI for administrators to perform various tasks such as managing Administration roles, managing various system wide settings, and configuring the Identity and Access Management Systems. System Console 42 can be used to manage groups (optional) and departing users, reclaim unused resources, manage logging, configure parameters for authentication, configure parameters for authorization, and so on. Additionally, System Console 42 can be used to configure user schemes and control access to certain Identity Management System capabilities (such as “new user,” “deactivate user,” “workflow,” and so on).
The system of FIG. 1 is used to protect a web site, network, Intranet, Extranet, etc. To understand how the system of FIG. 1 protects a web site (or other structure), it is important to understand the operation of unprotected web sites. In a typical unprotected web site, end users cause their browsers to send a request to a Web Server. The request is usually an HTTP request which includes a URL. The Web Server then translates, or maps, the URL into a file system's name space and locates the matching resource. The resource is then returned to the browser.
With the system of FIG. 1 deployed, Web Server 18 (enabled by Web Gate 28, Access Server 34, and Directory Server 36) can make informed decisions based on default and/or specific rules about whether to return requested resources to an end user. The rules are evaluated based on the end user's profile, which is managed by the Identity Management System. In one embodiment of the present invention, the general method proceeds as follows. An end user enters a URL or an identification of a requested resource residing in a protected policy domain. The user's browser sends the URL as part of an HTTP request to Web Server 18. Web Gate 28 intercepts the request. If the end user has not already been authenticated, Web Gate 28 causes Web Server 18 to issue a challenge to the browser for log-on information. The received log-on information is then passed back to Web Server 18 and on to Web Gate 28. Web Gate 28 in turn makes an authentication request to Access Server 34, which determines whether the user's supplied log-on information is authentic or not. Access Server 34 performs the authentication by accessing attributes of the user's profile and the resource's authentication criteria stored on Directory Server 36. If the user's supplied log-on information satisfies the authentication criteria, the process flows as described below; otherwise, the end user is notified that access to the requested resource is denied and the process halts. After authenticating the user, Web Gate 28 queries Access Server 34 about whether the user is authorized to access the resource requested. Access Server 34 in turn queries Directory Server 36 for the appropriate authorization criteria for the requested resource. Access Server 34 retrieves the authorization criteria for the resource and, based on that authorization criteria, Access Server 34 answers Web Gate 28's authorization query. If the user is authorized, the user is granted access to the resource; otherwise, the user's request is denied. Various alternatives to the above described flow are also within the spirit and scope of the present invention.
In one embodiment, the system of FIG. 1 includes means for providing and managing identity profiles, and means for defining and managing authentication and authorization policies. In one implementation, user identity and authentication/authorization information is administered through delegable Administration roles. Certain users are assigned to Administration roles, thus conferring to them the rights and responsibilities of managing policy and/or user identities in specific portions of the directory and web name spaces. The capability to delegate Administration duties enables a site to scale administratively by empowering those closest to the sources of policy and user information with the ability to manage that information.
A role is a function or position performed by a person in an organization. An administrator is one type of role. In one embodiment, there are at least five different types of administrators: System Administrator, Master Access Administrator, Delegated Access Administrator, Master Identity Administrator, and Delegated Identity Administrator. A System Administrator serves as a super user and is authorized to configure the system deployment itself and can manage any aspect of the system.
A Master Access Administrator is assigned by the system administrator and is authorized to configure the Access Management System. The Master Access Administrator can define and configure Web Gates, Access Servers, authentication parameters, and policy domains. In addition, Master Access Administrators can assign individuals to Delegated Access Administrator roles. A Delegated Access Administrator is authorized to create, delete and/or update policies within their assigned policy domain (described below), and create new policy domains subordinate to their assigned policy domains. A Delegated Access Administrator may also confer these rights to others. A Master Identity Administrator, assigned by the System Administrator, is authorized to configure the Identity Management System, including defining and configuring end user identities and attributes, per attribute access control, who may perform new user and deactivate (revocation) user functions. Master Identity Administrators may also designate individuals to Delegate Identity Administrator roles. A Delegated Identity Administrator is selectively authorized to perform new user and deactivate user functions.
A policy domain is a logical grouping of Web Server host ID's, host names, URL prefixes, and rules. Host names and URL prefixes specify the course-grain portion of the web name space a given policy domain protects. Rules specify the conditions in which access to requested resources is allowed or denied, and to which end users these conditions apply. Policy domains contain two levels of rules: first level default rules and second level rules contained in policies. First level default rules apply to any resource in a policy domain not associated with a policy.
A policy is a grouping of a URL pattern, resource type, operation type (such as a request method), and policy rules. These policy rules are the second level rules described above. There are two levels of rules available (first and second levels) for authentication, authorization, and auditing. Policies are always attached to a policy domain and specify the fine-grain portion of a web name space that a policy protects. In practice, the host names and URL prefixes from the policy domain the policy belongs to are logically concatenated with the policy's URL pattern and the resulting overall patterns compared to the incoming URL. If there is a match, then the policy's various rules are evaluated to determine whether the request should be allowed or denied; if there is not a match, then default policy domain rules are used.
FIG. 2 illustrates a high level block diagram of a computer system which can be used for the components of the present invention. The computer system of FIG. 2 includes a processor unit 50 and main memory 52. Processor unit 50 may contain a single microprocessor, or may contain a plurality of microprocessors for configuring the computer system as a multi-processor system. Main memory 52 stores, in part, instructions and data for execution by processor unit 50. If the system of the present invention is wholly or partially implemented in software, main memory 52 can store the executable code when in operation. Main memory 52 may include banks of dynamic random access memory (DRAM) as well as high speed cache memory.
The system of FIG. 2 further includes a mass storage device 54, peripheral device(s) 56, user input device(s) 60, portable storage medium drive(s) 62, a graphics subsystem 64 and an output display 66. For purposes of simplicity, the components shown in FIG. 1 are depicted as being connected via a single bus 68. However, the components may be connected through one or more data transport means. For example, processor unit 50 and main memory 52 may be connected via a local microprocessor bus, and the mass storage device 54, peripheral device(s) 56, portable storage medium drive(s) 62, and graphics subsystem 64 may be connected via one or more input/output (I/O) buses. Mass storage device 54, which may be implemented with a magnetic disk drive or an optical disk drive, is a non-volatile storage device for storing data and instructions for use by processor unit 50. In one embodiment, mass storage device 54 stores the system software for implementing the present invention for purposes of loading to main memory 52.
Portable storage medium drive 62 operates in conjunction with a portable non-volatile storage medium, such as a floppy disk, to input and output data and code to and from the computer system of FIG. 2. In one embodiment, the system software for implementing the present invention is stored on such a portable medium, and is input to the computer system via the portable storage medium drive 62. Peripheral device(s) 56 may include any type of computer support device, such as an input/output (I/O) interface, to add additional functionality to the computer system. For example, peripheral device(s) 56 may include a network interface for connecting the computer system to a network, a modem, a router, etc.
User input device(s) 60 provide a portion of a user interface. User input device(s) 60 may include an alpha-numeric keypad for inputting alpha-numeric and other information, or a pointing device, such as a mouse, a trackball, stylus, or cursor direction keys. In order to display textual and graphical information, the computer system of FIG. 2 includes graphics subsystem 64 and output display 66. Output display 66 may include a cathode ray tube (CRT) display, liquid crystal display (LCD) or other suitable display device. Graphics subsystem 64 receives textual and graphical information, and processes the information for output to display 66. Additionally, the system of FIG. 2 includes output devices 58. Examples of suitable output devices include speakers, printers, network interfaces, monitors, etc.
The components contained in the computer system of FIG. 2 are those typically found in computer systems suitable for use with the present invention, and are intended to represent a broad category of such computer components that are well known in the art. Thus, the computer system of FIG. 2 can be a personal computer, workstation, server, minicomputer, mainframe computer, or any other computing device. The computer can also include different bus configurations, networked platforms, multi-processor platforms, etc. Various operating systems can be used including Unix, Linux, Windows, Macintosh OS, Palm OS, and other suitable operating systems.
FIG. 3 is a block diagram of Directory Server 36. Directory Server 36 stores user identity profiles 102. Each identity profile includes a set of attributes for the particular end users. Group information 104 is also stored, which describes logical relationships and groupings of users having identity profiles 102 stored on Directory Server 36. A plurality of policies 106, each of which is associated with a policy domain as described above, are also stored on Directory Server 36. Revoked user list 108 identifies users previously (but no longer) allowed access to resources on their system. Shared secret(s) 110 are keys stored on Directory Server 36 used for encrypting cookies set on browsers 12 or 14 after a successful user authentication. Shared secret(s) (keys) 110 can change as often as desired by an administrator. In one embodiment of the present invention, previously valid keys are “grandfathered” such that both a current key and an immediately prior key will de-crypt encrypted cookies. Global sequence number (GSN) 112 is a unique number stored on Directory Server 36 which is assigned to a policy domain change (first level default rules) or policy change (second level resource-specific rules) and updated in response to subsequent policy changes for cache flushing purposes. In one embodiment of the present invention, the GSN is incremented to the next sequential number after detection of a policy domain or policy change. User attribute list 114 is a list of user identity profile attributes used by cached authentication and authorization rules.
FIG. 4 depicts an exemplar directory tree that can be stored on Directory Server 36. Each node on the tree is an entry in the directory structure. Node 130 is the highest node on the tree and represents an entity responsible for the directory structure. In one example, an entity may set up an Extranet and grant Extranet access to many different companies. The entity setting up the Extranet is node 130. Each of the companies with Extranet access would have a node at a level below node 130. For example, company A (node 132) and company B (node 134) are directly below node 130. Each company may be broken up into organizations. The organizations could be departments in the company or logical groups to help manage the users. For example, FIG. 4 shows company A broken up into two organizations: organization A with node 136 and organization B with node 138. Company B is shown to be broken up into two organizations: organization C with node 140 and organization D with node 142. FIG. 4 shows organization A having two end users: employee 1 with node 150 and employee 2 with node 152. Organization B is shown with two end users: employee 3 with node 154 and employee 4 with node 156. Organization C is shown with two end users: employee 5 with node 158 and employee 6 with node 160. Organization D is shown with two end users: employee 7 with node 162 and employee 8 with node 164.
Each node depicted in FIG. 4 can include one or more identity profiles stored in Directory Server 36. In one embodiment, there are different types of object-oriented classes for storing information for each identity profile. One exemplar class pertains to entities such as entity 130, company A (node 133), and company B (node 134). A second exemplar class stores information about organizational units such as organization A (node 136), organization B (node 138), organization C (node 140), and organization D (node 142). In one embodiment, each of the organizations are departments in a company and each of the users are employees who work for that particular organization. A third exemplar class is for individual persons such as employee 1 (node 150), employee 2, (node 152), . . . employee 8 (node 164). Although the directory tree is depicted as having three levels, more or less than three levels can be used.
In a typical use of the Identity Management System shown in FIG. 4, a source from the Identity Management System attempts to access a target in the Identity Management System. For example, employee 1 (node 150) may seek to access the profile for employee 4 (node 156). Thus, node 150 is the source and node 156 is the target. For efficiency purposes, one embodiment stores access information at the target and at the highest level for targets with common access rules. In some cases, access information is stored at a higher level even if a lower level does not include common access rules.
FIG. 5 is a flow chart describing the process for setting up an identity profile by an administrator having authority to do so. In step 200, the administrator selects the object class to be used for the directory entry or entries being created. As previously described, there are at least three classes: organization, organizational unit, and user. In step 200, the master identity administrator selects which class is to be used for the entry. After the object class is selected in step 200, all possible attributes for the particular class appear on a graphical user interface (GUI) (step 202). In step 204, the administrator selects one of the attributes. In step 206, the master identity administrator edits the access criteria for the attribute. In step 210, it is determined whether there are any more attributes to consider. If so, the method loops back to step 204. Otherwise, the process of FIG. 5 is completed (step 214).
FIG. 6 is a flow chart describing step 206 of FIG. 5, editing access criteria for an attribute. In step 230, the administrator selects where in the tree structure of FIG. 4 to store the access information for the particular attribute under consideration. For example, if the administrator is setting up an identity profile for employee 2 (node 152) of FIG. 4, attribute access information can be stored at node 152, node 136, node 132, or node 130. In step 230, it is determined which one of those available nodes will store the information. In step 232, the permissions to modify the attribute are set up using a policy. A policy can identify person(s) who can modify the attribute. The policy can identify a set of people by identifying a role, by identifying a rule for identifying people, by identifying one or more people directly by name, or by identifying a named group. In step 236, permissions are set up to determine who can view the attributes. The Identity Management System policy determines which users can view identity profile attributes by defining a role, defining a rule, identifying persons by name, or listing an identified group. In one embodiment, the rule mentioned above is an LDAP rule. In step 238 (an optional step), the ability to edit the permissions are delegated to others. In step 240, a notify list is set up. The notify list identifies a set of zero or more persons who are notified (e.g. by email) when the attribute is modified.
In one embodiment, the Identity Management System includes a localized access feature. This feature restricts certain user's access to identity profiles within a defined locale. For example, if an entity sets up an Extranet similar to the tree of FIG. 4, and allows two of its suppliers (e.g. company A and company B) to access the Extranet, company A may not want employees from company B to access identity profiles for employees of company A. In accordance with the present invention, a set of identity profiles can be defined as a locale. Users outside the locale can be restricted from accessing identity profiles inside the locale. Alternatively, users outside the locale can be restricted from accessing certain attributes of identity profiles inside the locale. The localized access feature can be used to prevent any nodes, including node 132 and any nodes below node 132, from accessing node 134 and any node below node 134. The localized access feature can be used at other levels of granularity and/or at other levels of the organizational hierarchy. For example, users below node 136 can be blocked from accessing profiles below node 138, node 140, node 142, node 134, etc.
FIG. 7 is a flow chart describing the process for configuring localized access. In step 262, a localized access parameter for the entire system of FIG. 1 is set. This parameter turns on the localized access function. In step 266 of FIG. 7, a class attribute can be set for localized access. Each identity profile has a set of attributes. One of those attributes is designated as the class attribute. The class attribute is used to identify the identity profile. A reference to a particular identity profile is a reference (or pointer) to the class attribute for the identity profile. The class attribute can be configured for localized access by setting up a localized access filter that identifies the locale. If the source of a request is in a different locale than the locale defined for the class attribute, then the source is denied access to the target. The localized access filter can be an absolute test such as “Company=Acme” or the filter can name another attribute (called a domain attribute). If the filter names a domain attribute (e.g. company attribute, address attribute, last name attribute, organization attribute, etc.), then the filter is satisfied if the named attribute for source matches the named attribute for the target. For example, if the domain attribute named for the class attribute is “Company Name,” than a source can only access a target if the company name for the source is the same as the company name for the target. Using a domain attribute, rather than hard coding the criteria, is more dynamic because it depends on the run-time relationship of the source and target. In one embodiment, multiple domain attributes can be used to define the locale. Users whose domain attributes are equal, are in the same locale. A user can be a member of multiple locales.
In step 268, individual attributes for a profile can be configured for localized access. That is, some attributes in an identity profile can be configured for localized access, while other attributes are not. Each attribute can be provided with a localized access filter that identifies the locale for that attribute. The localized access filter can include an absolute test, an LDAP test or one or more domain attributes. In one embodiment, individual attributes are not configured in step 268 if the class attribute for the profile has already been set. It is possible to configure the class attribute for localized access and not configure the other attributes for localized access. Similarly, in some embodiments it is possible to not configure the class attribute for localized access while configuring the other attributes for localized access.
In one embodiment, when a source seeks to access a particular attribute in a target, the system first checks to see if the localized access filter for the class attribute of the target is satisfied. If it is not satisfied, then access is denied. If it is satisfied, then the system first checks to see if the localized access filter for the particular attribute of the target is satisfied. If it is or it is not configured for localized access, then access can be granted. If the localized access filter for the particular attribute of the target is not satisfied, access to the particular attribute is denied. In summary, the localized access filter for the class attribute determines access to the entire identity profile, while the localized access filter for a specific attribute (other than the class attribute) determines access to the specific attribute. After the steps of FIG. 7 are completed, the profiles (or portions of profiles) that have been set for localized access can only be accessed by those within the same locale.
FIG. 8 is a flow chart describing the process for accessing data in the Identity Management System. The data can be accessed for viewing, modifying, etc. As described above, the entity attempting to access a profile in the Identity Management System is the source and the profile being accessed is the target. In step 290, the source user's browser sends a request to access attributes of a target directory entry. In step 292, the request is received by User Manager 38. In step 294, User Manager 38 accesses the target profile and the source profile on Directory Server 36. In step 296, User Manager 38, based on the attribute settings created or modified by the process of FIG. 5 and (possibly) the source profile, determines whether the source should have access to each of the different attributes of the target profile. This step is discussed in further detail below. In step 298, User Manager 38 passes the information for the attributes that access is allowed for to the source's browser. In step 300, the attributes that the source may view are displayed on the source's browser.
FIG. 9 is a flow chart describing the process of step 296 of FIG. 8, determining whether the source should have access to the various attributes of the target. In step 320, the system determines whether a localized access violation for the class attribute has occurred. A localized access violation is found when the target's class attribute is configured for localized access and the source is not in the locale for the target. If there is a localized access violation, the method of FIG. 9 is done (step 344) and none of the attributes for the target may be accessed by the source. For example, if the source is employee 1 (node 150 of FIG. 4), the target is employee 8 (node 164 of FIG. 4), and all of company B is subject to localized access with a domain attribute set as “company” (in one embodiment the actual syntax is % company %) a localized access violation will be found in step 320.
If no localized access violation is found in step 320, then one of the attributes for the target is selected in step 322 and User Manager 38 determines whether the access information for that selected attribute is at the current level in the tree. The first time step 324 is performed, the current level in the tree is the level of the target. As previously explained, access information can be stored at the target's node or nodes above the target. If the access information is not found at the current level, then in step 340, it is determined whether the system is inquiring at the top level of the directory structure (e.g. node 130 of FIG. 4). If the system is at the top level, then the system determines whether all attributes have been evaluated in step 332. If all attributes have been evaluated, then the process of FIG. 9 is done (step 348). If all attributes have not been evaluated, then the system accesses the initial level again in step 334 and loops back to step 322. If in step 340, it is determined that the system is not at the top level, then the system moves up one level (step 342) and loops back to step 324.
While in step 324, if the access information for the attribute is at the current level being considered, then in step 326 it is determined whether there is a local access violation for the attribute under consideration. If the particular attribute being considered was configured for localized access and the source is not in the relevant locale for the target, then a localized access violation occurs and the method of FIG. 9 is done (step 346). It will be appreciated that localized access can apply to entire profiles or only certain portions (certain attributes) of profiles. If the attribute under consideration was not configured for localized access, then there is no localized access violation for the attribute under consideration. If there is no localized access violation for the attribute under consideration, then the identity profile for the source is applied to any additional access criteria to see whether the source should have access to the target's attribute. If the criteria is met, access is granted in step 330 and the method loops to step 332. At the end of the process of FIG. 9, a source will be granted access to zero or more attributes. Step 300 of FIG. 8 displays only those attributes for which the source has been granted access.
FIG. 10 is a flow chart describing the process of step 320 in FIG. 9, determining whether a localized access violation has occurred for a class attribute. In step 360, the Identity Management System determines whether the localized access parameter is set. If not, there is no localized access violation. If so, then in step 364, the system determines whether a class attribute is configured for localized access. If the class attribute is not configured for localized access, there is no local access violation (step 362). If the class attribute is configured for localized access, then in step 366 it is determined whether the localized access filter is satisfied (e.g. does the domain attribute for the target must match the domain attribute for the source?). If the localized access filter is satisfied, no localized access violation occurs (step 362). If the localized access filter is not satisfied, then a localized access violation exists and access should be denied (step 368).
FIG. 11 is a flow chart describing the process performed in step 326 of FIG. 9, determining whether there is a localized access violation for a particular attribute. In step 380, it is determined whether a localized access parameter is set. If not, there is no localized access violation (step 382). Otherwise, in step 384, it is determined whether the particular attribute is configured for localized access. If the particular attribute is not configured for localized access, then there is no localized access violation (step 382). If the particular attribute is configured for localized access, then in step 386 it is determined whether the localized access filter for the attribute under consideration is satisfied. If the localized access filter is satisfied, then there is no localized access violation (step 382). If the localized access filter is not satisfied, then there is a localized access violation and access should be denied (step 388).
FIG. 12 is a flow chart describing the process of how a source user can modify an attribute of a target profile. In step 410, the source user attempts to modify an attribute. For example, in one embodiment the source user is provided a GUI which depicts the directory tree. The source user can select any node in the directory tree and click on a button to modify a target profile. Alternatively, the source user can type in a URL, distinguished name, or other identifying information for the target. Once presented with a target profile (e.g. the process of FIG. 8), the user selects a particular attribute and attempts to modify it by selecting a modify button on the GUI. This request to modify is sent to User Manager 38. In step 412, User Manager 38 searches for the modify criteria for the attribute in the target directory. This modify criteria is the information set up in step 232 of FIG. 6. User Manager 38 searches in the current target directory. If the criteria is not found in the current directory being accessed (see step 414), then it is determined whether the system is at the top of the directory tree structure (step 416). If not, then the system moves up one level in step 418. If the top of the directory structure is reached, then the source user is not allowed to modify the attribute (step 420). In step 422, User Manager 38 searches for the modify criteria in a new directory. After step 422, the method loops back to step 414. If in step 414, it is determined that the criteria was found at the current level being considered, then in step 430, the User Manager evaluates the criteria against the target user's identity profile. If the identity profile for the target user satisfies the criteria for modifying the attribute (step 432) then the source user is allowed to modify the attribute (step 434). Otherwise, the source user is not allowed to modify the attribute (step 420).
FIG. 13 is a flow chart describing a process for automating the updating of identity profiles when a source user requesting the update is not allowed to modify the target profile. In one embodiment, the source user is the person identified by the target profile. In step 450, the source user requests modification of the target profile. This can be a request to modify any or all of the attributes for the target profile (e.g. address, telephone number, creation of the profile, deletion of the profile, etc.). In step 452, it is determined whether the target profile is protected. It is possible to set all attributes such that any source entity can modify the attributes In such a configuration; the profile is not protected. If the target profile is not protected, then, in step 454, the target profile is modified as per the source user's request. If the target profile is protected, then in step 456, the User Manager 38 issues an electronic message (“ticket”) sent to a responsible party requesting that the modification be made. The responsible party is a person granted access to modify a particular attribute and has the responsibility for doing so. In step 458, the ticket appears in a service queue accessible by the responsible party. The service queue can be a directory which stores all tickets or can be any database which is used to store the tickets. The responsible party may access a GUI which indicates all tickets in the service queue, the date they were received, and what service is requested. In step 460, the requesting source user can view whether a ticket has been serviced. In step 462, the ticket is fully serviced, partially serviced or denied by the responsible party. If the ticket is serviced, then the target will be modified. However, the target will not be modified if the ticket is denied. After the target is modified (or purposely not modified) and a ticket is responded to, the ticket is removed from the service queue in step 464. In an optional embodiment, the source is automatically notified that the ticket is removed from the service queue and notified of the result of the request.
FIG. 14 provides a block diagram of Web Gate 28. In one embodiment, Web Gate 28 is a Web Server plug-in running on Web Server 18. In another embodiment, Web Gate 28 is an NSAPI Web Server plug-in. In another embodiment, Web Gate 28 is an ISAPI Web Server plug-in. In still a further embodiment, Web Gate 28 is an Apache Web Server plug-in. In another embodiment, a plurality of Web Gates conforming to different plug-in formats are distributed among multiple Web Servers.
Resource cache 502 caches authentication information for individual resources. The information stored in resource cache 502 includes: request method, URL, retainer 505, and audit mask 503. In one embodiment of the present invention, audit mask 503 is a four bit data structure with separate bits identifying whether authentication and/or authorization successes and/or failures are audited (logged) for a given resource.
Authentication scheme cache 506 stores authentication scheme information, including information necessary for the performance of each different authentication challenge scheme. For example, if the authentication scheme ID parameter of a resource cache 502 entry references a “client certificate” authentication scheme, then the authentication scheme ID parameter of the entry would reference an authentication scheme cache 506 entry (keyed by the authentication challenge method ID). In one embodiment, authentication scheme cache stores redirect URL, authentication challenge method ID (identifying an authentication challenge method), challenge parameters for authentication and authentication level. Web Gate 28 also stores the most recent global sequence number 510 received from Access Server 34 pursuant to a cache flushing operation, as further described below.
Event manager 514 calls redirection event handler 504, resource protected event handler 508, authentication event handler 512, or authorization event handler 516 to perform redirection, a resource protected method, an authentication method, or an authorization method (all further described herein), respectively. Redirection event handler 504 redirects browser 12 or 14 in response to redirection events initiated by Access Server 34 or other components of Web Gate 28. Resource protected event handler 508 performs steps in a method for determining whether a requested resource falls protected within a policy domain. Authentication event handler 512 performs steps in a method for authenticating a user of browser 12 or 14 upon a finding that a requested resource is protected. Authorization event handler 516 performs steps in a method for determining whether a user of browser 12 or 14 is authorized to access a requested resource upon a successful authentication or receipt of a valid authentication cookie, further described herein. Sync record table 518 identifies all existing synchronization records not yet processed by Web Gate 28 as further described herein.
FIG. 15 provides a block diagram of Access Server 34. Authentication module 540 is provided for carrying out steps in a method for authenticating a user as further described herein. Authorization module 542 is provided for carrying out steps in a method for authorizing a user to access a requested resource as further described herein. Auditing module 544 carries out steps in a method for auditing (logging) successful and/or unsuccessful authentications and/or authorizations as further described herein. Audit logs 546 store information logged by auditing module 544 in accordance with the present invention. Audit logs sensors 548 include one or more sensors that monitor the audit logs for certain types of events. Synchronization records 550 are stored on Access Server 34 in accordance with a method for flushing caches as further described herein.
Access Server 34 stores the most recent global sequence number 554 received from Access Manager 40 pursuant to a cache flushing operation. URL prefix cache 564 stores the URL prefixes associated with policy domains that are protected by the Access Management System. URL prefix cache 564 facilitates the mapping of requested resources to policy domains, as further described herein. URL prefix cache 564 is loaded from Directory Server 36 upon initialization of Access Server 34.
Policy domain cache 566 caches all default authentication rules of each policy domain in accordance with the present invention. Policy domain cache further stores an array of rules 565 listing all default and resource-specific rules associated with resources in a given policy domain. Each rule entry in array 565 includes the ID of the rule and compiled information about the URL pattern (resource) to which the rule applies. Array 565 enables Access Server 34 to quickly find the first level default authentication, authorization, and auditing rules for a given policy domain, as well as second level rules (authentication, authorization, and auditing rules) associated with particular policies in the policy domain.
Authentication scheme cache 568 caches information necessary for the performance of different authentication challenge methods as similarly described above for authentication scheme cache 506 of Web Gate 28. Authentication rule cache 570 caches second level authentication rules associated with policies. The rules in authentication rule cache 570 are listed in array 565. Upon determining that a second level authentication rule exists and learning its ID (by looking in array 565), Access Server 34 can easily find the second level authentication rule in authentication rule cache 570. The second level rules are the rules associated with policies, discussed above.
Authorization rule cache 572 caches first level default authorization rules as well as second level authorization rules. The rules in authorization rule cache 572 are listed in array 565. Upon determining that a first or second level authorization rule exists and learning its ID (by looking in array 565), Access Server 34 can easily find the applicable authorization rule for a given resource in authorization rule cache 572.
Audit rule cache 574 caches first level default audit rules as well as second level audit rules. The rules in audit rule cache 574 are listed in array 565. Upon determining that a first or second level audit rule exists and learning its ID (by looking in array 565), Access Server 34 can easily find the applicable audit rule for a given resource in audit rule cache 574.
User profile cache 576 stores identity profile attributes previously used in authentications, authorization, or audit steps, in accordance with the present invention. User policy cache 578 stores the successful and unsuccessful authorization results for specific users requesting specific resources governed by authorization rules based on an LDAP filter or a group membership. User policy cache 578 allows Access Server 34 to quickly recall a user's authorization if the user has recently accessed the resource.
FIG. 16 is a flow chart which describes the process of creating a policy domain. In step 600, System Console 42 (or Access Manager 40) receives a request to create a policy domain. In step 602, the name of the policy domain and the description of the policy name are stored. In step 604, one or more URL prefixes are added to the policy domain. In step 605, one or more host ID's are added to the policy domain (optional). Next, one or more access rules are added to the policy domain. An access rule is a rule about accessing a resource. Examples of access rules include authorization rules, authentication rules, auditing rules, and other rules which are used during the process or attempting to access a resource. In step 606, a first level (default) authentication rule is added to the policy domain. In general, authentication is the process of verifying the identity of the user. Authentication rules specify the challenge method by which end users requesting access to a resource in the policy domain must prove their identity (authentication). As previously discussed, first level (default) authentication rules apply to all resources in a policy domain, while second level authentication rules are associated with policies that apply to subsets of resources or specific resources in the policy domain. In one embodiment, there is only one default authentication rule for a policy domain. If an administrator desires an authentication rule to apply to only a specific resource in the policy domain, a separate policy for that specific resource having a second level (specific) authentication rule should be defined, as discussed below. After setting up the authentication rule in step 606, one or more first level or default authorization rules are added to the policy domain in step 608. In general, an authorization rule determines who can access a resource. The default authorization rule allows or denies users access to resources within its applicable policy domain. If multiple authorization rules are created, then they are evaluated in an order specified in step 610. In step 612, a first level (default) audit rule is configured for the policy domain. In step 614, zero or more policies are added to the policy domain. In step 616, the data for the policy domain is stored in Directory Server 36 and appropriate caches (optional) are updated. In one embodiment, an authorization rule or an authentication rule can be set up to take no action. That is, always grant authentication without any challenge or verification; or always grant authorization without any verification.
FIG. 17 is a flow chart describing the process of adding one or more authorization rules to a policy domain (step 608 of FIG. 16). In step 632, timing conditions are set up for the authorization rule. Timing conditions restrict the time when the authorization rule is in effect. For example, users can be allowed access to URLs in the policy domain only during business hours, Monday through Friday. In one embodiment, if timing conditions are not set, the authorization rule is always in effect. The timing conditions include selecting a start date, an end date, selecting a start time and an end time, selecting the months of the year, selecting the days of the month, and selecting the days of the week that the rule is valid. In steps 634 and 636, authorization actions are set up. Authorization actions personalize the end user's interaction with the Web Server. In step 634, header variables are provided for authorization success events and authorization failure events. This feature allows for the passing of header variables about the end user (or other information) to other web-enabled resources. Web-enabled applications can personalize the end user's interaction with the Web Server using these header variables. As a simple example, the actions could supply each application with the user's name. An application could then greet the user with the message “hello <user's name>” whenever the user logs on. Header variables are variables that are part of an HTTP request. FIG. 40 below illustrates the format of an HTTP request that includes header variables 1554. If an authorization rule is set up with header variables as part of an authorization success action, then when a successful authorization occurs the HTTP request to the resource will include the header variables. Similarly, if there are header variables for an authorization failure, then an authorization failure event will include adding header variables to the HTTP request that redirects a browser to an authorization failure web page. The resources identified by the HTTP requests, that include the header variables can use the header variables any way desired. In one embodiment of the method of FIG. 17, one or more groups can be specified for authorization to the resource(s).
FIG. 18 is a flow chart that describes the process of adding header variables to an HTTP request (see step 634 of FIG. 17). Header variables can be added during an authorization success event, authorization failure event, authentication success event or authentication failure event. In step 650, the variable name is entered. In step 652, a text string is entered. In step 654, one or more LDAP attributes are entered. In step 656, it is determined whether any more header variables will be added. If not, the method of FIG. 18 is done (step 658). If so, the method of FIG. 18 loops back to step 650.
The variable name entered in step 650 is a value that appears in the HTTP header that names the variable. The downstream resource using the header variable will search for the variable name. The string entered is data that can be used by the downstream resource. The LDAP attribute(s) can be one or more attributes from the requesting user's identity profile. Thus, in the simple authorization success example described above, the variable name field can include “authorization success,” the return field can include “yes,” and the attribute field can include the name attribute for the user in the user's identity profile. Any of the attributes from the user's identity profile can be selected as a header variable.
Looking back at FIG. 17, in step 636, a redirect URL can be added for an authorization success event and a redirect URL can be entered for an authorization failure event. Step 638 includes specifying which users are allowed to access the resource associated with the authorization rule. By default, users cannot access a resource until they are granted access rights to it. In one embodiment, there are at least four means for specifying who can access a resource. The first means is to explicitly name a set of users who can access the resource. A second means includes identifying user roles. The third means is to enter an LDAP rule that can be used to identify a set of users based on a combination of one or more attributes. A fourth means is to enter an IP address which will allow users of computers having the specified IP address to access the resource. Step 640 is used to specify the users not allowed to access the resource associated with this rule. Identification of users, roles, LDAP rules, and IP addresses are entered in step 640 in the same manner as entered in step 638. It is possible that a particular user can be subject to both an allow access rule and a deny access rule. Step 642 is used to set a priority between such rules. Optional step 644 is used to define any POST data to be used for authorization if this feature is implemented. An HTTP POST request can include POST data in the body of the HTTP request (see FIG. 40 below). POST data can also be submitted in query string form. One embodiment of the present invention allows POST data to be used for authorization purposes. In optional step 644, an administrator defines which POST data is to be used for authorization purposes. If POST data is to be used for authorization, in order for an authorization rule to be satisfied, the POST request must include all the appropriate POST data and values for that POST data as defined in step 644. However, it will be understood that POST data need not be used for authorization in all embodiments of the present invention. Step 646 is used to set a priority of evaluation for the authorization rule relative to other authorization rules in a given policy. In one embodiment, if multiple authorization rules apply to a resource, this priority determines the order of evaluation.
FIG. 19 is a flow chart describing the process for adding an authentication rule (see step 606 of FIG. 16). In step 670, a challenge scheme (also called an authentication scheme) is selected. An authentication scheme is a method for requesting log-on information (e.g. name and password) from end users trying to access a web resource. Within an authentication scheme is a challenge method (e.g. Basic, certificate or form). There can be more than one authentication scheme with the same challenge method (e.g. Basic over LDAP, Basic over NT Domain, . . . ). Various other authentication schemes can also be used. In step 672, header variables are added for authentication success and authentication failure events. In step 674, redirect URLs are added for authentication success events and authentication failure events.
FIG. 20 provides a flow chart depicting the process for configuring an audit rule (see step 612 of FIG. 16). In step 680, the events to trigger an audit are selected. In one embodiment, authentication success, authentication failure, authorization success and authorization failure can be selected for auditing. In step 682, the information to be logged is selected for each particular event identified in step 680. The information logged can include information about the event and/or user attributes from the identity profile for the user requesting the authentication or authorization.
FIG. 21 is a flow chart describing the process of adding a policy (see step 614 of FIG. 16). In step 718, a resource type is specified. The resource type allows different resources to be handled by different policies, depending on the nature of the resource itself. For example, in one embodiment, the resource type will distinguish between resources accessed using HTTP and resources accessed using FTP. In another embodiment, Enterprise Java Beans (EJBs) are a possible resource type. In another embodiment, user-defined custom resource types are supported. In step 720, an operation type is specified. This allows different resources to be handled by different policies, depending on the operations used to request the resource. In one embodiment, the operations will be HTTP requests. Supported HTTP request methods include GET, POST, PUT, HEAD, DELETE, TRACE, OPTIONS, CONNECT, and OTHER. In another embodiment, if EJBs are identified as the resource type (step 718), an EXECUTE operation can be specified in step 720. In another embodiment, user-defined custom operations are supported. Other and future operations can also be supported. In step 722, a pattern for the URL path to which the policy applies is specified. This is the part of URL that does not include the scheme (“http”) and host/domain (“www.oblix.com”), and appears before a ‘?’ character in the URL. In step 724, a query string is specified. This is a set of variables and values that must be included in the specified order in an incoming URL for the policy to match and be activated. For example, in the URL “HTTP://www.zoo.com/animals.cgi?uid=maneaters&tigers=2” the values after the question mark (e.g. “uid=maneaters&tigers=2”) comprise a query string. Only a URL exhibiting the query string can match to this policy. For example, a URL with the “tigers” variable appearing before the “uid” variable will not match the above-identified policy. In step 726, query string variables are added. Query string variables include a name of a variable and the variable's corresponding value. Query string variables are used when it is a desirable that multiple variables are found in the query string, but the order is unimportant. Thus, for a policy with query string variables “uid=maneaters” and “tigers=2,” a URL with a query string having the appropriate uid and appropriate tigers variable, in any order, will match the policy. In order for a resource URL to apply to a policy, the path of the requested resource URL must match the path of the policy as well as any query string or query variables. As discussed above, POST data can be submitted in query string form (for example, in a form submission), and evaluated using the query string variables entered in step 726.
The query string or query variables specified in the steps of FIG. 21 do not need to uniquely identify a resource. Rather, they are used to identify a policy, which may apply to one or more resources.
Typically, the query data is added to a URL to access certain data from a resource. However, the query data can be used in the URL to identify the resource. Each application or resource is free to use the query data in any way that is in agreement with standards and norms known in the art.
In step 728 of FIG. 21, the authentication rule is created in accordance with the method of FIG. 19. In step 730, one or more authorization rules are created for the policy in accordance with the method of FIG. 17. In step 732, an audit rule for the policy is configured in accordance with the method of FIG. 20. In step 734, POST data (optional) is added to the policy. This POST data is used to map resources with policies.
The present invention supports the use of multiple authentication schemes. An authentication scheme comprises an authentication level, a challenge method, an SSL assertion parameter, a challenge redirect parameter, and authentication plug-ins. The authentication level represents an arbitrary designation of the level of confidence that an administrator has in a particular authentication scheme relative to other authentication schemes.
In one embodiment of the present invention, an authentication scheme can specify one of four challenge methods: none, basic, form, and X.509. If an authentication scheme's challenge method is set to “none,” no authentication is required to access a requested resource, thus allowing support for unauthenticated users. This challenge method can be used over both unsecured as well as SSL connections. The “basic” challenge method can also be used over both unsecured and SSL connections. The “X.509” challenge method can only be used over an SSL connection between a user's browser and Web Server host, because the authentication method invoked for an X509 challenge method is part of the SSL protocol. A “form” challenge method employs a custom, site-specific HTML form presented to the user, who enters information and submits the form. Subsequent processing is determined by the administrator at the time the authentication scheme is created. Form challenge methods can be used over both unsecured and SSL connections.
The SSL parameter of an authentication scheme identifies whether SSL is to be asserted on the connection to the user's browser by the Web Server. The challenge parameter identifies where to redirect a request for authentication for the particular authentication scheme. Authentication plug-ins are necessary for processing the user's supplied information. Authentication plug-ins can interface with Access Server 34 through an authentication API.
An authentication scheme that an attacker can easily and profitability eavesdrop upon is typically considered “weak.” In one embodiment, the basic authentication challenge method places the user's credential (supplied information), a simple password, “in the clear” over an unsecured network connection. However, the authentication scheme can be made stronger by passing the user's credential over an encrypted connection, such as SSL. In one embodiment, given two authentication schemes (one with and one without SSL), an access administrator will assign the authentication scheme without SSL to a lower authentication level than the authentication using SSL.
When a user first request a protected resource, the user is challenged according to the authentication scheme defined by the first level authentication rule in the applicable policy domain or the second level authentication rule in the applicable policy associated with the requested resource. If the user satisfies the authentication rule, an encrypted authentication cookie is passed to the user's browser indicating a successful authentication. Once authenticated, the user may request a second resource protected by a different policy domain and/or policy with a different authentication rule. The user will be allowed access to the second resource without re-authenticating if the authentication level of the authentication scheme used to successfully authenticate for the first resource is equal to or greater than the authentication level of the authentication scheme of the second resource. Otherwise, the user is challenged and asked to re-authenticate for the second resource in accordance with the second resource's higher level authentication scheme. Satisfaction of a higher or lower authentication level is determined by evaluating the authentication cookie sent by the user's browser when requesting the second resource. In one embodiment of the present invention, administrators can define an unlimited number of authentication levels.
Once authenticated, a user can explicitly log out, causing authentication cookies cached (or otherwise stored) by the user's browser to be destroyed or become invalid. Authentication cookies can also be set by an administrator to be destroyed after a maximum idle time has elapsed between requests to resources protected in accordance with the present invention.
FIG. 22 provides a flow chart for one embodiment of a method for authenticating, authorizing, and logging. In step 750, a user's browser 12 requests a web-enabled resource 22 or 24. The request is intercepted by Web Gate 28 in step 752. The method then determines whether the requested resource is protected by an authentication and/or authorization rule in step 753. If the resource is not protected, then access is granted to the requested resource in step 795. If the requested resource is protected however, the method proceeds to step 754. If the user has previously authenticated for a protected resource in the same domain, a valid authentication cookie will be passed by browser 12 with the request in step 750 and intercepted by Web Gate in step 752. If a valid cookie is received (step 754), the method attempts to authorize the user in step 756. If no valid authorization cookie is received (step 754), the method attempts to authenticate the user for the requested resource (step 760).
If the user successfully authenticates for the requested resource (step 762), then the method proceeds to step 774. Otherwise, the unsuccessful authentication is logged in step 764. After step 764, the system then performs authentication failure actions and Web Gate 28 denies the user access to the requested resource in step 766. In step 774, the successful authentication of the user for the resource is logged. The method then performs authentication success actions in step 766. In response to the successful authentication, Web Gate 28 then passes a valid authentication cookie to browser 12 in step 780 which is stored by browser 12. After passing the cookie in step 780, the system attempts to authorize in step 756.
In step 756, the method attempts to determine whether the user is authorized to access the requested resource. If the user is authorized (step 790), the method proceeds to step 792. Otherwise, the unsuccessful authorization is logged in step 796. After step 796, the method performs authorization failure actions (step 798) and Web Gate 28 denies the user access to the requested resource. If authorization is successful (step 790), then the successful authorization of the user is logged in step 792, authorization success actions are performed in step 794, and the user is granted access to the requested resource in step 795. In one embodiment of step 795, some or all of HTTP request information is provided to the resource.
FIG. 23 provides a flow chart of a method for determining whether a requested resource is protected (see step 753 of FIG. 22). In one embodiment, the steps of FIG. 23 are performed by resource protected event handler 508 and Access Server 34. In step 830, Web Gate 28 determines whether an entry for the requested resource is found in resource cache 502. If an entry is found, the cache entry is examined in step 842 to determine whether the cache entry indicates that the resource is protected (step 832) or unprotected (step 840). If an entry for the requested resource is not found in resource cache 502, then Web Gate 28 passes the URL of the requested resource request method to Access Server 34 in step 833. Access Server 34 attempts to map the requested resource to a policy domain using URL prefix cache 564 (step 836).
If mapping step 836 is unsuccessful (step 838), then the requested resource is deemed to be unprotected (step 840). However, if a successful mapping has occurred (step 838), then Access Server 34 retrieves the authentication rule (step 844) and audit rule (step 846) associated with the requested resource. Access Server 34 then passes the authentication scheme ID from the authentication rule, audit mask 503, retainer 505 and any POST data received to Web Gate 28 in step 848. Web Gate 28 caches the authentication scheme ID from the authentication rule, audit mask 503, retainer 505 and POST data in resource cache 502 (step 850). Since the requested resource was successfully mapped to a policy domain in step 836, the resource is deemed protected (step 832).
FIG. 24 is a flow chart describing the process for mapping a resource to a policy domain (see step 836 of FIG. 23). In step 900, Access Server 34 receives the URL of the requested resource from Web Gate 28. Access Server 34 then compares a URL prefix of the requested resource with entries in URL prefix cache 564 in step 902. In one embodiment, when step 902 is called for the first time in FIG. 24, the URL prefix of the requested resource equals the file name. Thus, if the URL of the requested resource reads: “http://www.oblix.com/oblix/sales/index.html” then the URL prefix first compared by step 902 will be: “/oblix/sales/index.html.” If a matching URL prefix is found (step 904), Access Server 34 proceeds to step 916.
In step 916, Access Server 34 determines whether the policy domain associated with the matching URL prefix calls for one or more host ID's. In one embodiment, resources are mapped to certain policy domains if the port number of a resource request and the location of the resource itself conform to one or more host ID's. Thus, multiple policy domains can be associated with identical URL prefixes, each policy domain requiring different host ID's (or none at all). If the policy domain considered in step 916 requires a matching host ID, then Access Server 34 proceeds to step 917. Otherwise, Access Server 34 proceeds directly to step 906 where the requested resource is mapped to the policy domain associated with the currently considered URL prefix. In step 917, if a matching host ID is found, Access Server 34 proceeds to step 906. If no matching host ID is found, Access Server 34 returns to step 904 where it determines whether additional matching URL prefixes exist.
If no matching URL prefix is found in step 904, then Access Server 34 proceeds to step 908. In step 908, Access Server 34 crops the right-most term from the resource URL prefix compared in step 902. Thus, if the resource URL prefix compared in step 902 reads: “/oblix/sales/index.html” then the resource URL prefix will be cropped in step 908 to read: “/oblix/sales.” If the entire resource URL prefix has been cropped in step 908 such that no additional terms remain (step 910), then the method proceeds to step 912 where Access Server 34 concludes that there is no policy domain associated with the requested resource. However, if one or more additional terms remain in the resource URL prefix, then the method returns to step 902 where the cropped URL prefix is compared with URL prefixes cached in URL prefix cache 564.
As will be apparent from FIG. 24, the method recursively performs steps 902, 904, 908, and 910 until either a match is found (step 904) or the entire resource URL prefix has been cropped (step 910). In any case, the method of FIG. 24 will inevitably return either a successful mapping (step 906) or no mapping (step 912).
FIG. 25 provides a flow chart describing a method for loading an authentication rule (see step 844 of FIG. 23). In step 930, Access Server 34 loads the first level (default) authentication rule for the policy domain mapped in step 836 of FIG. 23 from Directory Server 36 into authentication rule cache 570. In one embodiment, success and failure actions are part of all authentication and authorization rules. In one embodiment, Access Manager 40 maintains a user attribute list 114 on Directory Server 36. User attribute list 114 identifies all user attributes used by authentication and authorization actions loaded into authentication rule cache 570 and authorization rule cache 572. In this step, Access Server 34 also builds array 565 (previously described above) and loads it into policy domain cache 566. Array 565 includes all second level rules and patterns associated with each of the policies for the policy domain. Access Server 34 then selects a second level rule in array 565 (step 931). The selected second level rule is part of a policy. In step 932, Access Server 34 performs a pattern matching method (further described below) for determining whether the rule applies to the requested resource. If so, then Access Server 34 proceeds to step 935; otherwise, Access Server 34 determines whether all rules in array 565 have been evaluated (step 933). If, in step 933, it is determined that not all of the rules in the array have been evaluated, then Access Server 34 selects the next rule in array 565 (step 934) and returns to step 932. Once all rules in array 565 have been considered (step 933), the first level authentication rule previously loaded in step 930 is returned as the authentication rule, no second level authentication rule is loaded into authentication rule cache 570, and the method of FIG. 25 is done (step 937). If an associated policy was found in step 932, then authentication module 540 caches the second level authentication rule and success and failure actions for the rule in authentication rule cache 570 (step 935), returns that second level authentication rule (step 936), and the method is done (step 937).
FIG. 26 is a flow chart describing a method for determining whether a policy is associated with a resource (see step 932 of FIG. 25). A policy URL can contain the following three types of patterns. All three types of patterns were referenced in FIG. 21:
1. Pattern on the path of the URL: This is the part of URL that does not include the scheme (“http”) and host/domain (“www.oblix.com”), and appears before a ‘?’ character in the URL. In the example URL:
    • http://www.oblix.com/oblix/sales/index.html?user=J.Smith&dept=engg the absolute path is “/oblix/sales/index.html.”
2. Pattern on name value pairs in the URL: This may be a set of patterns. They apply to query data (data appearing after the ‘?’ character in the URL when operation is GET, or the POST data if operation is POST) and are configured as name (no pattern allowed) plus a pattern or value. For example:
variable name pattern
user *Smith
dept *sales*

If multiple name value pairs are specified, they all must match to the incoming resource URL. So the URL:
    • http://www.oblix.com/oblix/sales/index.html?user=J.Smith&dept=engg will not match this pattern set. This pattern does not include a notion of order to these name-value pairs. A URL:
    • http://www.oblix.com/oblix/sales/index.html?dept=sales&user=J.Smith (with reverse order of “dept” and “user”) will also satisfy this pattern. This is important because it is usually difficult to control the order of name value pairs in GET/POST query data.
3. Pattern on the entire query string: This is useful when an administrator desires to enforce an order on the query string. For example, a pattern “user=*Smith*sales” will match query string “user=J.Smith&dept=sales.”
A policy can contain one or more of above types of patterns. If multiple patterns are specified in one policy, they ALL must match to the incoming resource URL. If not, that policy doesn't apply to the incoming resource URL.
Patterns used for one embodiment of the current invention can use the following special characters:
    • 1. ?: Matches any one character other than ‘/’. For example, “a?b” matches “aab” and “azb” but not “a/b.”
    • 2. *: Matches any sequence of zero or more characters. Does not match ‘/’. For example, “a*b” matches “ab,” “azb,” and “azzzzzzb but not “a/b.”
    • 3. [“set”]: Matches one from a set of characters. “set” can be specified as a series of literal characters or as a range of characters. A range of characters is any two characters (including ‘−’) with a ‘−’ between them. ‘/’ is not a valid character to include in a set. A set of characters will not match ‘/’ even if a range which includes ‘/’ is specified. Examples includes: “[nd]” matches only “n” or “d”; “[m-x]” matches any character between “m” and “x” inclusive; “[--b]” matches any character between “−” and “b” inclusive (except for “/”); “[abf-n]” matches “a,” “b,” and any character between “f” and “n” inclusive; and “[a-f-n]” matches any character between “a” and “f” inclusive, “−,” or “n.” The second “−” is interpreted literally because the “f” preceding it is already part of a range.
    • 4. {“pattern1,”“pattern2,” . . . }: Matches one from a set of patterns. The patterns inside the braces may themselves include any other special characters except for braces (sets of patterns may not be nested). Examples includes: “a{ab,bc}b” matches “aabb” and “abcb”; “a{x*y,y?x}b” matches “axyb,” “axabayb,” “ayaxb,” etc.
    • 5. “/ . . . /”: Matches any sequence of one or more characters that starts and ends with the ‘/’ character. Examples includes: “/ . . . /index.html” matches “/index.html,” “/oblix/index.html,” and “/oblix/sales/index.html,” but not “index.html,” “xyzindex.html,” or “xyz/index.html”; and “/oblix/ . . . /*.html” matches “/oblix/index.html,” “/oblix/sales/order.html,” etc.
    • 6. “\”: Any character preceded by a backslash matches itself Backslash is used to turn off special treatment of special characters. Examples include “abc\*d” only matches “abc*d”; and “abc\\d” only matches “abc\d.”
To increase the speed of pattern matching, the system tries to do some work up front. When Access Server 34 loads a pattern in its cache, it creates an object. This object's constructor “compiles” the pattern. This compiling is essentially building a simple state machine from one pattern to other, i.e., it creates a chain of “glob nodes.” Each glob node consists of either one pattern or a node set. For example, consider pattern:
/ . . . /abc*pqr{uv,xy*}.
The chain would look like:
node(“/ . . . /”)--->node(“abc”)--->node(“*”)--->node(“pqr”)--->nodeset(node(“uv”), (node(“xy”)--->node(“*”)))
Once the chain is constructed, it is used to match a resource URL to the pattern. Each node or node set in this chain takes a pointer to a string, walks it and decides if it matches the pattern held by the node. In doing so, it also moves this pointer further up in the string. For example, when the server gets a URL “/1/3/abcdepqrxyz,” the system takes this string and starts walking the chain. Below is an example of evaluation at each node/node set and pointer (*p) in the string. Note that the original string is not modified. To begin with lets assume that the pointer points to the beginning of the string: *p->“/1/3/abcdepqrxyz.”:
    • Step 1: node(“/ . . . /”)--->MATCHES--->advance *p->“abcdepqrxyz.”
    • Step 2: node(“abc”)--->MATCHES--->advance *p->“depqrxyz.”
    • Step 3: node(“*”)--->* matches everything except special characters ( unescaped ‘?,’ ‘*,’ ‘[,’ ‘],’ ‘{,’ ‘},’ ‘/’), so at this point, the system tries matching to the next node, node(“pqr”) like this:
      • a) does *p->“depqrxyz” match node (“pqr”)? NO, advance *p->“epqrxyz.”
      • b) does *p->“epqrxyz” match node (“pqr”)? NO, advance *p->“pqrxyz.”
      • c) does *p->“pqrxyz” match node (“pqr”)? YES, advance *p->“xyz.” If we walked to the end of string and didn't find a “pqr” (for example in case of URL “/1/3/abcdefgh”) there is no match.
    • Step 4: nodeset(node(“uv”), (node(“xy”)--->node(“*”))): A nodeset will match incoming string (in the example, *p->“xyz”) to one of set members. In this case “xyz” does not match “uv,” but it does match “xy*.” So there is a MATCH and *p->‘\0.’
    • Step 5: The pointer is at the end of the string. So the match is successful.
      At any point, if the system finds a node that does not match its string, the system stops processing and concludes that the string does not match the pattern. For example, a URL “/1/3/dddddd” will clear step 1 above, but will fail step 2, so the matching stops after step 2.
Referring to FIG. 26, in step 940, Access Server 34 retrieves the policy information from policy domain cache 566. The policy information can include one or more of the following: a URL absolute path, a query string, and zero or more query variables. In step 941, Access Server 34 determines whether requested resource matches the policy resource type (see FIG. 21). If the resource type does not match, Access Server 34 skips to step 952. However, if the resource type does match, Access Server 34 proceeds to step 942. In step 942, Access Server 34 determines whether the operation used to request the resource matches policy operation type (see FIG. 21). If the operation type does not match, Access Server 34 skips to step 952. If the operation type does match, Access Server 34 proceeds to step 943.
In step 943, the policy URL absolute path, query variables, and query strings are broken up into various nodes, as described above. In step 944, the various nodes are stored. Access Server 34 accesses the requested resource URL in step 946. In step 948, the first node of the policy URL is considered by Access Server 34. In step 950, Access Server 34 considers whether the considered node matches the resource URL, as described above. If the first node does not match, then the entire policy will not match (step 952). If the node does match the resource URL, or if there are no nodes for the policy, then in step 954 it is determined whether there are any more nodes to consider. If more nodes remain to be considered, then in step 956 the next node is considered and the method loops back to step 950. If there are no more nodes (step 954), the query string for the policy is compared to the query string of the resource URL in step 958. If the query string for the policy exactly matches the query string for the resource URL, or if there is no query string for the policy, then the method continues with step 960. If the query string for the policy does not match the query string for the resource URL, then the resource URL does not match and is not associated with the policy (step 952).
In step 960, it is determined whether there are any query variables (see FIG. 21) to consider that have not already been considered. If there are query variables to consider, then the next query variable is accessed in step 964. The accessed query variable is searched for in the resource URL in step 965. If the query variable is found in the resource URL and the value for the query variable matches the stored value query variable in for the policy (step 966), then the method continues at step 960; otherwise, Access Server 34 proceeds to step 967. The purpose of steps 960, 964, 965, and 966 is to determine whether each of the query variables (and associated values) defined for a policy are found, in any order, in the resource URL. If all of the query variables are in the URL with the appropriate values, than there is a match (step 970). In one embodiment, the query string and the query variables are in the portion of the URL following the question mark.
If in step 966 a match is not found, then it is determined whether a match may still be possible using POST data. In one embodiment, resources are mapped to policies by matching POST data submitted with resource requests. Thus, different policies can be associated with a given resource, depending on the contents of the POST data. For example, a user may request a resource during the course of submitting an online form containing POST data. Applicable policies can be mapped on the basis of POST data added to the policy in step 734 of FIG. 21. In step 967, Access Server 34 determines whether the policy operation type is an HTTP POST request. If not, then there is no match (step 952). However, if the operation type is an HTTP POST request, then Access Server 34 proceeds to step 968 where Access Server 34 requests and receives the POST data from Web Gate 28. In one embodiment, Web Gate 28 transmits a flag with all POST requests forwarded to Access Server 34. When POST data is transmitted with an HTTP POST request, the flag is set. If no POST data is transmitted, then the flag is not set. In another embodiment, retainer 505 is transmitted by Access Server 34 to Web Gate 28 when requesting POST data. Retainer 505 is returned by Web Gate 28 to Access Server 34 with the POST data, thus indicating which policy to continue evaluating in step 969. In step 969, Access Server 34 evaluates whether the POST data received in step 968 matches the POST data required by the policy to achieve a match (see FIG. 21). If the POST data matches, then the method proceeds to step 970. Otherwise, the method proceeds to step 952.
FIG. 26A provides a flow chart detailing the steps performed when matching a resource with a specific policy using POST data in step 969 of FIG. 26. In one embodiment, the steps of FIG. 26A are performed by authentication module 540. In step 980, Access Server 34 selects the first data required for matching the policy under consideration. Then, in step 981, Access Server 34 selects the first item of POST data received in step 968 of FIG. 26. Access Server 34 compares the POST data with the required data (step 982). If a match is found (step 983), Access Server proceeds to step 987. Otherwise, Access Server 34 proceeds to step 984 where it determines whether all of the POST data received has already been compared in step 982. If additional POST data remains to be compared, Access Server 34 selects the next item of POST data received (step 986) and loops back to step 982. If all received POST data has already been compared (step 982) and no match was found (step 984), then Access Server 34 returns no match (step 985). In step 987, Access Server 34 determines whether additional POST data is required to be matched in order to match the specific policy under consideration with the requested resource. If additional data is required, Access Server 34 selects the next required data (step 988) and loops back to step 981. If no additional data is required, Access Server 34 returns a match (step 989).
FIG. 27 provides a block diagram of a retainer data structure (retainer) 505 that is passed by Web Gate 28 to Access Server 34 to identify the policy domain and policy previously mapped in step 836 of FIG. 23 and step 932 of FIG. 25, respectively. Retainer 505 is cached in resource cache 502 in step 850 of FIG. 23. Retainer 505 contains the policy domain ID 992 of the mapped policy domain to be used in authorization and logging steps, the policy ID 994 for an applicable policy residing in the mapped policy domain, and ID 996 for the applicable authentication scheme. Thus, by passing retainer 505 rather than the complete URL of the requested resource, Web Gate 28 saves Access Server 34 from having to repeatedly remap the requested resource to a policy domain and policy during authorization and logging.
FIG. 28 provides a flowchart of a method for authenticating a user for various combinations of domains and Web Servers through a single authentication performed by the user. As will be apparent to those skilled in the art, an Internet domain can reside on a single Web Server, or be distributed across multiple Web Servers. In addition, multiple Internet domains can reside on a single Web Server, or can be distributed across multiple Web Servers. In accordance with the present invention, the method of FIG. 28 allows a user to satisfy the authentication requirements of a plurality of domains and/or Web Servers by performing a single authentication.
In the simplest case, all of an e-business host company's Web Servers will be in the same domain (i.e. oblix.com). When a user successfully authenticates at one of the Web Servers, the Web Gate running on the authenticating Web Server causes the Web Server to return an encrypted cookie, indicating a successful authentication. Subsequent requests by the browser to the domain will pass this cookie (assuming the cookie applies to the requested URL), proving the user's identity; therefore, further authentications are unnecessary.
In a more complex case, an e-business host company's web presence incorporates associated web sites whose Web Servers have names in multiple domains. In such a multiple domain case, each of the associated portal Web Servers use a Web Gate plug-in configured to redirect user authentication exchanges to the e-business host's designated web log-in Web Server. The user is then authenticated at the e-business host's web log-in server, and an encrypted cookie is issued for the e-business host's domain to the user's browser. The user's browser is then redirected back to the original associated portal's site where the Web Gate creates a new cookie for the associated portal's domain and returns it to the user's browser.
As a result, the user is transparently authenticated in both the original associated portal's domain and the e-business host's domain. The process is transparently performed for each different associated portal that a user may visit during a session. The present invention's associated portal support easily supports single Web Servers having multiple DNS names in multiple domains, and/or multiple network addresses. In accordance with the present invention, this multiple domain authentication enables “staging” of web sites. For example, a new edition of a web site can be deployed on a separate set of servers, and then mapped to policy domains protected by the present invention by simply updating the policy domain's host ID's.
In one embodiment, the steps of FIG. 28 are performed by authentication event handler 512 and redirection event handler 504. In step 1020, authentication event handler 512 determines whether single or multiple domains are protected in a given deployment of the present invention. If only a single domain is protected, then the method proceeds to step 1022 where an authentication is attempted at the single domain. If the single domain is distributed across multiple Web Servers, then the domain attribute of the cookie set by the authenticating Web Server in step 1022 is set to broadly include all Web Servers in the domain.
If multiple domains are protected, the method proceeds to step 1024 where authentication event handler 512 determines whether the multiple protected domains all reside on a single Web Server. For example, a single machine intranet.oblix.com may be addressed in multiple ways such as: sifl.oblix.com, intranet, asterix.oblix.com, or 192.168.70.1. In accordance with the present invention, when multiple domains reside on a single Web Server, an administrator will designate exactly one of the domains a “preferred host domain.” If step 1024 indicates that all protected domains reside on the same Web Server, then authentication event handler 512 determines whether the domain of the requested resource is a preferred host (step 1026). If it is a preferred host, then authentication event handler 512 attempts to authenticate the user at the preferred host domain in step 1030 (further described below with respect to FIG. 30). Otherwise, redirection event handler 504 redirects browser 12 to the preferred host domain (step 1028) for authentication (step 1030). Referring to step 1024, if the multiple protected domains reside on multiple Web Servers, then authentication event handler 512 proceeds to step 1032.
In one embodiment, a single policy domain and/or policies are created for the preferred host domain while no policy domains or policies are created for the other domains residing on the same web server. All resource requests made to any of the multiple protected domains residing on the same web server are redirected to the preferred host domain, thus requiring the user to authenticate according to the preferred host domain's policy domain and/or policies. As a result, after authentication at the preferred host domain, the user is transparently authenticated for all other domains residing on the same web server. When subsequent resource requests for resources in domains residing on the same web server are redirected to the preferred host domain, the prior successful authentication for the host domain can be confirmed by the existence of a valid authentication cookie for the preferred host domain. If such a cookie exists, then the user need not re-authenticate for the requested resource. In one embodiment, if subsequent resource requests made to the preferred host domain (or any of the other domains on the same web server) require a higher level of authentication, or if a previously valid authentication has expired, the user will be required to re-authenticate at the preferred host domain in accordance with the method of FIG. 28.
FIG. 29 provides a block diagram of a plurality of Web Servers, each hosting a different domain accessible by browser 1082. In accordance with the present invention, when multiple domains are protected and distributed across multiple Web Servers, the administrator will identify exactly one of the domains a “master domain.” As identified in FIG. 29, Web Server 1070 hosts master domain A.com, while Web Servers 1072 and 1074 host domains B.com and C.com, respectfully. An end user's resource request is illustrated in FIG. 29 by path 1084 from browser 1082 to Web Server 1072.
Referring back to FIG. 28, if authentication event handler 512 determines that the domain of the requested resource is a master domain (step 1032), then authentication event handler 512 attempts to authenticate at the master domain (step 1034). Otherwise, redirection event handler 504 redirects browser 12 to the master domain (step 1036). The user then authenticates at the master domain (step 1038). The redirection and authentication of steps 1036 and 1038 are illustrated in FIG. 29 by path 1086. Upon a successful authentication at the master domain, the master domain Web Server passes an authentication cookie to the user's browser (step 1040) and re-directs the user's browser back to the first domain accessed by the user (step 1042). Also in step 1042, the master domain passes information contained in the master domain authentication cookie to the first domain in the query data portion of the redirection URL. Steps 1040 and 1042 are illustrated by paths 1088 and 1090, respectively in FIG. 29. In step 1044, the Web Gate of the first domain Web Server extracts the master domain authentication cookie information from the redirection URL, thus confirming the user's authentication at the master domain and resulting in a successful authentication (step 1046). The first domain Web Server (B.com) then sends its own authentication cookie to web browser 1082 (as depicted by path 1092) in accordance with step 780 of FIG. 22, previously described above. Any subsequent authentication by browser 1082 at domain C.com on Web Server 1074 follows the method of FIG. 28.
FIG. 30 provides a flow chart of the method for authenticating, as performed in steps 1022, 1030, 1034, and 1038 of FIG. 28. In one embodiment, the steps of FIG. 30 are performed by authentication event handler 512. In step 1120, authentication event handler 512 accesses resource cache 502 to determine what authentication challenge method is to be used for the given resource. Authentication event handler 512 then accesses authentication scheme cache 506 in step 1122 to determine whether the authentication scheme associated with the requested resource has been previously cached. If the authentication scheme is found, authentication event handler 512 determines the specific type of challenge method in step 1126. If the challenge scheme was not found in step 1122, authentication event handler 512 loads the authentication rule associated with the requested resource from Directory Server 36 in step 1124 (further described below in FIG. 31), and then proceeds to step 1126.
In step 1126, authentication event handler 516 discerns whether the authentication challenge scheme retrieved in step 1122 or 1124 calls for basic, form, certificate, or no authentication. If the challenge scheme indicates basic authentication, then the method proceeds to step 1128 and performs basic authentication. If the challenge scheme indicates form authentication, then the method proceeds to step 1130 and performs form authentication. If the challenge scheme indicates certificate authentication, then the method proceeds to step 1132 and performs certificate authentication. If the challenge scheme indicates that no authentication is required (step 1134), then the user is not challenged, authentication is not performed (in one embodiment, the system skips to step 756 of FIG. 22 and in another embodiment the system skips to step 774 of FIG. 22).
FIG. 31 provides a flow chart describing the method of loading an authentication challenge scheme from Directory Server 36 (step 1124 of FIG. 30). In one embodiment, the steps of FIG. 31 are performed by authentication event handler 512 and Access Server 34. In step 1160, authentication event handler 512 requests the authentication challenge scheme to be read from Access Server 34. If the authentication challenge scheme is found in authentication scheme cache 568 (step 1162), then Access Server 34 proceeds to step 1168. Otherwise, Access Server 34 retrieves the requested authentication challenge scheme from Directory Server 36 (step 1164). Upon retrieval, Access Server 34 caches the authentication challenge scheme in authentication scheme cache 568 (step 1166), and proceeds to step 1168. In step 1168, Access Server 34 passes the retrieved authentication challenge scheme to Web Gate 28. Web Gate 28 then caches the authentication challenge scheme in authentication scheme cache 506 (step 1170).
FIG. 32 provides an exemplar method for performing basic authentication (step 1128 of FIG. 30). In one embodiment, the steps of FIG. 32 are performed by authentication event handler 512 and authentication module 540. In step 1202, authentication event handler 512 instructs browser 12 to prompt the user for a user ID and password. In response, the user enters and the user's browser submits the requested user ID and password (step 1204). In step 1206, Web Gate 28 intercepts the user submission and authentication event handler 512 passes the user ID and password to Access Server 34, along with retainer 505, thus identifying a policy domain and policy applicable to the requested resource. Access Server authentication module 540 then authenticates the user using the user ID and password in step 1208. In step 1210, authentication module 540 returns the authentication result, authentication success or failure actions, and any user attributes required by the actions to Web Gate 28.
FIG. 33 provides a flow chart describing an exemplar method used by the Access Server to authenticate using a user ID and password (step 1208 of FIG. 32). In one embodiment, the steps of FIG. 33 are performed by authentication module 540. In optional step 1230, authentication module 540 searches user profile cache 576 for a user identity profile entry having a user ID attribute matching the user ID received from Web Gate 28. User profile cache 576 is a hash table of user identity profile attributes that can be used for authentication, authorization, or auditing. In one embodiment, the user ID attribute would appear in user profile cache 576 if it was previously used in a successful authentication. If a match is found (optional step 1232), then authentication module 540 proceeds to step 1234. If no match is found, then authentication module 540 proceeds to step 1236.
In another embodiment, steps 1230 and 1232 of FIG. 33 are not performed. In such an embodiment, the method of FIG. 33 begins with step 1236 where it searches user identity profiles 102 in Directory Server 36 (not user profile cache 576) for a user identity profile having a user ID attribute matching the user ID received from Web Gate 28. If no matching user identity profile attribute is found in Directory Server 36 (step 1238), then the method proceeds to step 1241. If a matching user identity profile attribute is found in Directory Server 36 (step 1238), then authentication module 540 binds to the directory using the distinguished name from the matching user identity profile entry and the password received from Web Gate 28 (step 1234). If the bind is unsuccessful (step 1240), then authentication module 540 proceeds to step 1241 where it determines whether an entry for the current user is found in user profile cache 576. If so, authentication module 540 proceeds to step 1243. Otherwise, authentication module 540 retrieves all profile attributes of the current user appearing in user attribute list 114 and caches them in user profile cache 576 (step 1242). In step 1243, authentication module 540 returns an unsuccessful authentication result.
If the bind is successful (step 1240), then authentication module 540 accesses revoked user list 582 to determine whether the user ID received from Web Gate appears on revoked user list 582. If the user ID is on the revoked user list (step 1244), authentication module 540 proceeds to step 1241. If the user ID is not on the revoked user list, then authentication module 540 determines whether an entry for the user is found in user profile cache 576 (step 1250). If not, authentication module 540 retrieves all profile attributes of the current user appearing in list 114 and caches them in user profile cache 576 (step 1254). If an entry was found, the method skips to step 1260. In step 1260, the method returns a successful authentication result.
FIG. 34 provides a flow chart describing a method for performing form authentication (step 1130 of FIG. 30). In one embodiment, the steps of FIG. 34 are performed by authentication event handler 512, redirection event handler 504, browser 12, and authentication module 540. In step 1308, authentication event handler 512 sets a “form login” cookie on browser 12. The cookie includes the URL of the requested resource. Authentication event handler 512 then redirects browser 12 to an authentication form URL (step 1310). In step 1312, Web Gate 28 allows the authentication form referenced by the authentication form URL to pass to browser 12. The user then fills out the authentication form (step 1314) and transmits (e.g. post data) the information from the authentication form (step 1316), passing the form login cookie previously set in step 1308. Authentication event handler 512 then extracts the URL of the requested resource from the form login cookie (step 1318), and passes the user ID and password filled out by the user in the authentication form (submitted as POST data) to Access Server 34 (step 1320).
In step 1322, authentication module 540 authenticates the user for the requested resource using the user's id and password received from Web Gate 28, performing the steps of FIG. 33 previously described above. In step 1324, authentication module 540 returns the authentication result, authentication actions, and user attributes to Web Gate 28. Authentication event handler 512 then sets the form login cookie (previously set in step 1308) to indicate that the authentication process is completed (step 1326).
FIG. 35 is a flow chart describing a method for performing certificate authentication (step 1132 of FIG. 30). In one embodiment of the present invention, client certificate authentication is performed using Web Servers employing the Netscape Enterprise Server plug-in interface (NSAPI). In another embodiment, client certificate authentication is performed for Web Servers employing the Microsoft Internet Information Server plug-in interface (ISAPI). In yet another embodiment, client certificate authentication is performed on a plurality of Web Servers, with a first subset of the Web Servers employing NSAPI and a second subset employing ISAPI. Other Web Servers can also be used.
In one embodiment, the steps of FIG. 35 are performed by authentication event handler 512, redirection event handler 504, browser 12, and authentication module 540. In step 1348, authentication event handler 512 requests Web Server 18 to perform SSL client certificate authentication on browser 12. In one embodiment of the present invention performing client certificate authentication on ISAPI Web Servers, authentication event handler 512 redirects browser 12 to a special case URL (i.e. cert_authn.dll) that is configured to accept certificates. In such an embodiment, this redirection occurs within step 1348.
In step 1350, Web Server 18, on behalf of Web Gate 28, sends an SSL client certificate request along with trusted certificate authorities (CA's) and challenge data to browser 12. Browser 12 then displays a selection box with client certificates from trusted CA's, allowing a user of browser 12 to select a certificate (step 1352). Browser 12 then returns the selected certificate with challenge data signed by a private key to Web Server 18 (step 1356). Web Server 18 then verifies that the challenge data was properly signed by the selected certificate (step 1360) and passes a valid certificate to Web Gate 28 (step 1362), which passes the certificate to Access Server 34 (step 1363). In step 1364, authentication module 540 of Access Server 34 then decodes the certificate and maps the certificate subject to a valid distinguished name (further described in FIG. 36). In step 1366, authentication module 540 returns the authentication result, authentication actions, and user attributes to Web Gate 28.
FIG. 36 provides a flow chart describing a method for authenticating using a valid certificate (step 1364 of FIG. 35). In one embodiment, the steps of FIG. 36 are performed by authentication module 540. In optional step 1390, authentication module 540 decodes one or more fields of the certificate passed by Web Gate 28 in step 1362 of FIG. 35. In one embodiment, the user's e-mail address is decoded. In step 1392, authentication module 540 searches user profile cache 576 for a user identity profile entry having one or more attributes matching the decoded field(s). In one embodiment, the user attribute would appear in user profile cache 576 if it was previously used in a successful authentication. If a match is found (optional step 1394), then authentication module 540 proceeds to step 1406. If no match is found, then authentication module 540 proceeds to step 1396.
In another embodiment, steps 1390 and 1392 of FIG. 36 are not performed. In such an embodiment, the method of FIG. 36 begins with step 1396 where it searches user identity profiles 102 in Directory Server 36 for a user identity profile having one or more attributes matching the decoded field(s). If no matching user identity profile attribute is found in Directory Server 36 (step 1398), then the method proceeds to step 1402 where it determines whether an entry for the current user is found in user profile cache 576. If so, authentication module 540 proceeds to step 1405. Otherwise, authentication module 540 retrieves all profile attributes of the current user appearing in user attribute list 114 and caches them in user profile cache 576 (step 1404). In step 1405, authentication module 540 returns an unsuccessful authentication result. If a matching user identity profile is found in step 1398, the method proceeds to step 1406.
In step 1406, authentication module 540 accesses revoked user list 582 to determine whether the user identity profile having the matching user attribute appears on revoked user list 582. If so, authentication module 540 proceeds to step 1402. Otherwise, authentication module 540 continues on to step 1410 and determines whether an entry for the current user is found in user profile cache 576. If not, authentication module 540 retrieves all profile attributes of the current user appearing in list 114 and caches them in user profile cache 576 (step 1416). If an entry was found, the method skips to step 1422. In step 1422, the method returns a successful authentication result.
FIG. 37 provides a block diagram of an authentication cookie 1450 passed by Web Gate 28 to browser 12 in step 780 of FIG. 22. Cookie 1450 is encrypted with a symmetric cipher so that cookies from all instances of Web Gate 28 in a given deployment of the present invention may be encrypted using the same key. This key (shared secret 110) is stored on Directory Server 36 and distributed to each of the Web Gates 28 by Access Server 34. Shared secret 110 can change as often as desired by an administrator. In one embodiment of the present invention, cookie 1450 is encrypted using RC4 encryption with a 2048 bit key. As previously described, in one embodiment, previously valid keys are grandfathered such that both the current key and the immediately prior key will both work to de-crypt encrypted cookie 1450. The present invention features a one-button key re-generation function. This function is easily scriptable.
In one embodiment, the information stored by cookie 1450 includes the authentication level 1452 of the authentication scheme used to create the cookie, the user ID 1454 of the authenticated user, the IP address 1456 of the authenticated user, and session start time 1458 identifying the time at which cookie 1450 was created. If the time elapsed since the session start time 1458 exceeds a maximum session time, the cookie will become invalid. Idle start time 1460 is also stored, which identifies the time when the previous HTTP request for a protected resource was made in which cookie 1450 was passed. If the time elapsed since the idle start time 1460 exceeds a maximum idle time, the cookie will become invalid. Both of these time limits force users to re-authenticate if they have left a session unattended for longer than the maximum session or idle times. Cookie 1450 also stores a secured hash 1462 of information 1452, 1454, 1456, 1458, and 1460. In one embodiment of the present invention, secured hash 1462 is created using an MD5 hashing algorithm. Most Internet browsers cache a user's supplied authentication information during basic and certificate authentication challenge methods, and then transparently re-send the information upon receiving an authentication challenge from a Web Server. In one embodiment, an administrator can enable a form authentication challenge method requiring end users to re-authenticate upon expiration of the maximum session or maximum idle time limits.
FIG. 38 provides a flow chart describing a method for attempting to authorize a user (step 756 of FIG. 22). In one embodiment, the method of FIG. 38 is performed by authorization event handler 516 and authorization module 542. In step 1490, authorization event handler 516 of Web Gate 28 passes authorization information to Access Server 34. In step 1494, authorization module 542 determines whether one or more authorization rules associated with the requested resource are found in authorization rule cache 572. If one or more rules are found, authorization module 542 proceeds to step 1496. Otherwise, authorization module 542 retrieves any authorization rules associated with the requested resource from Directory Server 36 in step 1498. In one embodiment, authorization success and failure actions are retrieved with the authorization rules. After retrieving the authorization rules, authorization module 542 proceeds to step 1496 and reads the first authorization rule associated with the requested resource from authorization rule cache 572. In one embodiment, multiple authorization rules are evaluated in an order determined by the priority set in step 646 of FIG. 17. In another embodiment, second level authorization rules are evaluated prior to first level authorization rules. Authorization module 542 applies the authorization rule (step 1500) to the authorization information previously passed in step 1490.
If the authorization rule is satisfied in step 1502, authorization module 542 determines whether an entry for the user is found in user profile cache 576 (step 1504). If so, authorization module 542 proceeds to step 1508. If not, authorization module 542 retrieves all profile attributes of the current user appearing in user attribute list 114 (step 1507), and communicates the authorization success actions and attributes to Web Gate 28 (step 1508).
If the authorization rule is not satisfied (step 1502), then authorization module 542 determines whether more authorization rules remain to be evaluated (step 1509). If more rules remain, the next rule is read (step 1496) and evaluated (step 1500). If no more rules remain, authorization module 542 determines whether an entry for the user is found in user profile cache 576 (step 1510). If so, authorization module 542 proceeds to step 1512. If not, authorization module 542 retrieves all profile attributes of the current user appearing in user attribute list 114 (step 1511), and communicates the authorization success actions and attributes to Web Gate 28 (step 1512).
FIG. 39 details the steps performed when passing authorization information to Access Server 34 in step 1490 of FIG. 38. In one embodiment, the steps of FIG. 39 are performed by authorization event handler 516. In one embodiment, authorization can be performed using POST data. In another embodiment, POST data is not used for authorization. If POST data is enabled to be used for authorization, then the method of FIG. 39 begins with optional step 1530. Otherwise, the method begins at step 1534. If the resource request issued by browser 12 in step 750 of FIG. 22 employs a POST request method and POST data is enabled to be used for authorization (step 1530), authorization event handler 516 passes the POST data and retainer 505 to Access Server 34 (step 1536). If the resource request does not employ a POST request method or POST data is not enabled to be used for authorization (step 1530), then authorization event handler 516 passes retainer 505, the request method, the user's distinguished name, the user's IP address, and the time of the request to Access Server 34 in step 1534.
FIG. 40 illustrates the format of an HTTP request. As illustrated in FIG. 40, an HTTP request 1550 comprises request line 1552, zero or more headers 1554, blank line 1556, and body 1558 (used only for POST requests). The HTTP protocol supports various types of requests. The GET request returns whatever information is identified by the request-URI portion of request line 1552. The HEAD request is similar to the GET request, but only a server's header information is returned. The actual contents of the specified document is not returned. This request is often used to test hypertext links for validity, accessibility, and recent modifications. The POST request is used for POSTing electronic mail, news, or sending forms that are filled in by an interactive user. A POST is the only type of request that sends a body. A valid content-linked header field is required in POST requests to specify the length of body 1558. Post data can include zero or more data elements separated by “&” as depicted by line 1562. Each data element is of the form variable name=value.
HTTP request 1550 can contain a variable number of header fields 1560. A blank line 1556 separates header fields 1554 from body 1558. A header field comprises a field name, a string and the field value, as depicted in box 1560. In one embodiment, the field value is an LDAP attribute. Field names are case insensitive. Headers can be divided in three categories: those that apply to requests, those that apply to responses, and those that describe body 1558. Certain headers apply to both requests and responses. Headers that describe the body can appear in a POST request or in any response.
FIG. 41 provides a flow chart describing a method for loading an authorization rule from the Directory Server (step 1498 of FIG. 38). In one embodiment, the steps of FIG. 41 are performed by authorization module 542. In step 1580, Access Server 34 loads the default authorization rule for the policy domain mapped in step 836 of FIG. 23 from Directory Server 36 into authorization rule cache 572. Access Server 34 then selects a first rule in array 565 (step 1582) and determines whether the selected rule is a second level (specific) rule of a policy associated with the requested resource (step 1584), by calling the method of FIG. 26 previously described above. If yes, then Access Server 34 proceeds to step 1592. Otherwise, Access Server 34 determines whether all rules in array 565 have been evaluated (step 1586). If not, then Access Server 34 selects the next rule in array 565 (step 1588), and returns to step 1584. Once all rules in array 565 have been considered (step 1586), Access Server 34 proceeds to step 1594 and loops back to step 1586. If a second level authorization rule (a rule defined in a policy) was found for the requested resource in step 1584, then authorization module 540 caches the second level authorization rule in authorization rule cache 570 (step 1592) and the method is done (step 1594). If a second level policy authorization rule was not found, then the default authorization rule previously loaded in step 1580 remains in authorization rule cache 572, and the method is done (step 1594).
FIG. 42 provides a flow chart describing the method of applying an authorization rule (step 1500 of FIG. 38). In one embodiment, the steps of FIG. 42 are performed by authorization module 542. In one embodiment, authorization can be performed using POST data. In another embodiment, POST data is not used for authorization. If POST data is to be used for authorization, then the method of FIG. 42 begins with optional step 1620. Otherwise, the method begins at step 1624. In optional step 1620, if the resource request employs a POST request method, then authorization module 542 proceeds to optional step 1622 where it applies the authorization rule to the POST data passed in step 1536 of FIG. 39. If the resource request does not employ a POST request method (or if POST data is not enabled to be used for authorization), then authorization module 542 proceeds to step 1624. If specific users are defined (by distinguished name) in the authorization rule, authorization module 542 evaluates whether the distinguished name of the authenticated user matches the user's distinguished name called for by the authorization rule (step 1626). If specific groups are defined in the authorization rule (step 1628), authorization module 542 evaluates whether the group name of the authenticated user matches the group name called for by the authorization rule (step 1630). In one embodiment, the user's group membership is cached in user policy cache 578. If specific roles are defined in the authorization rule (step 1632), authorization module 542 evaluates whether the role of the authenticated user matches the role called for by the authorization rule (step 1634). If specific LDAP rules are defined in the authorization rule (step 1640), authorization module 542 evaluates whether the LDAP rule matches the LDAP rule called for by the authorization rule (step 1642). In one embodiment, the result of the LDAP rule evaluation in step 1642 is cached in user policy cache 578. If specific user IP addresses are defined in the authorization rule (step 1644), authorization module 542 evaluates whether the IP address of the authenticated user matches the IP address called for by the authorization rule (step 1646). If a successful match is found at any point ( steps 1627, 1631, 1635, 1643, and 1647), the authorization is successful (step 1650). In one embodiment, successful matches of groups and LDAP rules are stored in user policy cache 578 in steps 1631 and 1643. In another embodiment, multiple matches must be found before an authorization success is found. If no matches are found, authorization is unsuccessful (step 1652).
FIG. 43 provides a flow chart detailing the steps performed when applying an authorization rule to POST data in optional step 1622 of FIG. 42. In one embodiment, the steps of FIG. 43 are performed by authorization module 542. In step 1670, Access Server 34 selects the first item of POST data received in optional step 1536 of FIG. 39. If the selected POST data is of a type that is called for by the authorization rule being evaluated (step 1672), then Access Server 34 evaluates whether the selected POST data matches data required by the authorization rule (step 1674) and determines whether a successful match has been found (step 1675). For example, if an authorization rule calls for a user's distinguished name, then a distinguished name contained in the POST data will be compared with the distinguished name expected by the authorization rule. If the selected POST data equals the expected distinguished name, then a successful match will be found for the example above. If a match is found (step 1675), Access Server proceeds to step 1682 where it returns a successful authorization. Otherwise, Access Server proceeds to step 1676. If, in step 1672, it is determined that the type of POST data was not called for, then Access Server 34 proceeds directly to step 1676.
In step 1676, Access Server 34 determines whether all of the POST data received in step 1536 has been considered by step 1672. If additional POST data remains to be considered (step 1676), Access Server 34 selects the next available item of POST data (step 1678) and loops back to step 1672. If no POST data remains to be considered and a match still has not been found (step 1676), access Server 34 proceeds to step 1684 and returns an authorization failure.
FIG. 44 is a flow chart describing the process of performing authentication success actions (step 776 of FIG. 22). In step 1700, Web Gate 28 determines whether there is a redirect URL. As described above, when setting up a policy domain or a policy, an administrator can set up a redirect URL for authentication success/failure events as well as authorization success/failure events. An administrator can also set up various variables to add to an HTTP request based on these events. If, in step 1700, it is determined that a redirect URL exists for an authentication success event, then in step 1702 it is determined whether there are any HTTP variables to add to the HTTP request. If it was determined in step 1700 that there was not a redirect URL, then in step 1704, it is determined whether there are any HTTP variables to add to the request. If, in step 1704, it is determined that there are HTTP variables to add to the request in response to the authentication success event, then in step 1706, the header variables are added. If, in step 1704, it is determined that there are no HTTP variables to add to the request, then no action is performed (step 1708). If, in step 1702, it is determined that there are no HTTP variables to add to the request, then in step 1710 the redirect URL is added to the HTTP request and browser 12 is redirected using the HTTP request in step 1712. If in step 1702 it is determined that there are HTTP variables to add to the request, then in step 1714 the redirect URL is added to the HTTP request and, in step 1716, the header variables are added to the HTTP request. In step 1718, the browser is redirected using the newly constructed HTTP request.
When a Web Server receives an HTTP request, the Web Server stores the contents of the HTTP request in a data structure on the Web Server. A Web Gate can edit that data structure using an API for the Web Server. In one embodiment, the downstream application that will be using the header variables is on, accessed using or associated with the same Web Server storing the HTTP request. In that case, the header variable are added (e.g. in step 1706) by storing the header variables in the data structure on the Web Server. Subsequently, the Web Server will provide the header variables to the downstream application.
FIG. 45 is a flow chart describing the steps of performing authentication and authorization failure actions (see steps 766 and 798 of FIG. 22, respectively). In step 1738, Web Gate determines whether there is a redirect URL for the authorization failure or authentication failure, whichever event is being considered. If there is no redirect URL, then in step 1740, it is determined whether there are any HTTP variables for the authorization failure or authentication failure. If there are no HTTP variables, then in step 1742, a default failure URL is added to a new HTTP request. The default failure URL is a URL that points to a web page that notifies a user that access is denied to the resource. In other embodiments, other pages can be used as default failure pages. In step 1744, the user's browser 12 is redirected using the HTTP request that includes the default failure URL. If, in step 1740, it is determined that there are HTTP variables to add to the HTTP request for the particular authentication failure or authorization failure event, then in step 1746, those variables are added as header variables to the HTTP request. In step 1748, the default failure URL is added to the HTTP request. The user's browser is redirected using the HTTP request in step 1750.
If, in step 1738, it is determined that there is a redirect URL for the particular authentication failure or authorization failure event, then it is determined whether there are any HTTP variables for this particular action in step 1752. If not, the redirect URL is added to the HTTP request in step 1754 and the browser is redirected using the HTTP request in step 1756. If, in step 1752 it is determined that there are HTTP variables to add to the request, then in step 1758, the redirect URL is added to the HTTP request. In step 1760, the header variables are added to the HTTP request. The user's browser is then redirected using the HTTP request in step 1762.
FIG. 46 is a flow chart describing the process of performing authorization success actions (step 794 of FIG. 22). In step 1782, it is determined whether there is a redirect URL for the authorization success action. If there is no redirect URL, then in step 1784 it is determined whether there are any HTTP header variables to add. If so, the header variables are added in step 1786. For example, the header variables can be added to the data structure for the request that is stored on the Web Server. Subsequently, the Web Server will provide the header variables to the downstream application(s). If, in step 1784 it is determined that there are no HTTP variables to add to the request, then no action is taken.
If it is determined in step 1782 that there is a redirect URL, then in step 1796, it is determined whether there are any HTTP variables to add to the request. If there are not any HTTP variables to add to the request, then the redirect URL is added to the HTTP request in step 1798. In step 1800, the user's browser is redirected using the HTTP request with the redirect URL. If it is determined that there are HTTP variables to add to the request in step 1796, then the redirect URL is added to the HTTP request in step 1802. In step 1804, the HTTP variables are added as header variables to the HTTP request. In step 1806, the user's browser is redirected using the HTTP request.
FIG. 47 is a flow chart describing the process of how a downstream application or other resource uses header variables provided by the system of FIG. 1. Upon authorization success, authorization failure, authentication success or authentication failure, various data can be added as header variables. In step 1830, the resource receives the request. In one embodiment, the resource receives request information from a Web Server. In another embodiment, the resource receives a redirected HTTP request. In step 1832, the resource determines whether there are any header variables to consider. If there are no header variables, then in step 1834, the resource responds to the request. Responding to the request can include providing a web page, access to a software process or anything else appropriate for the particular resource. If, in step 1832, it is determined that there are header variables, then in step 1836 the resource searches for a particular variable name. In order to use header variables, the resource must be preprogrammed to know what header variables to expect and how to use them. Thus, the resource will have a list of variable names it seeks. In step 1836, the resource looks for one of the listed variable names in the set of header variables. Once found, the resource reads the string for the found variable in step 1838. In step 1840, the resource reads the variable value (e.g. LDAP attribute). When HTTP variables are set up in actions, a variable name, a string for the variable and data for the variable are provided. In step 1842, it is determined whether any variables to operate on. If so, the method of FIG. 47 loops back to step 1836. If there are no more variables to operate, then in step 1844 the resource acts on the variables by taking the information from the variables and using them in the manner appropriate for the particular resource. In step 1846, the resource responds to the request as appropriate for that particular resource.
One example for using the process of FIG. 47 is to provide an automated login for a downstream application. For example, upon authentication or authorization successes, login information for a particular user and a particular application can be added to the HTTP request as header variables. The downstream application can be programmed to search the header variables for the login and password information and automatically attempt to authorize the user. In another example, user identity profile information is passed to a downstream application without the user accessing the application directly. This user identity profile information would be stored in header variables and provided to the resource being accessed. Thus, the resource being accessed can be fully customized for the user accessing the resource. For example, the resource can address the user by name and title and access preferences for that user. There are an unlimited number of resources that can be accessed by a user and, thus, unlimited ways to use the information contained in header variables.
As discussed above, the Access System monitors and logs various events, including authorization and authentication failure/success events. In other embodiments, other events can be monitored and logged. When an event being monitored occurs, an entry is added to an appropriate audit log. For purposes of the present invention, the terms log and log entry are used broadly because no special format is necessary for the present invention. A log can include any reasonable and organized system for storing information.
FIG. 48 provides a flow chart detailing the steps performed for logging authentication and/or authorization events (see steps 764, 774, 792, and 796 of FIG. 22). In one embodiment, the steps of FIG. 48 are performed by Web Gate 28 and auditing module 544. The log process is configurable because the audit rule associated with a requested resource can specify any combination of information to be logged in audit logs 546 in response to a detected type of event selected to be audited. For example, in one embodiment of the present invention, an audit rule associated with a requested resource can specify that all or a subset of the attributes of the identity profile for the user making the access request should be logged in one of audit logs 546 for the specific event. In another embodiment, the time of the authentication and an identification authorization event is logged in one or more of audit logs 546. An identification of the resource, the rule evaluated, the type of event, the IP (or other) address of the requesting machine, user ID, an identification of the operation being performed (e.g. GET, etc.) an identification of the Web Gate and/or access server that processed the request, user password and any other suitable information can also be logged.
Storing identity profile information, as well as the other information listed above, allows the system to provide data for load balancing, various business reports, and reports about how the system is being used. For example, knowledge of which resources are being accessed, when resources are being used and who is accessing the resources can allow an administrator to perform load balancing on the system. Reports identifying which content is being accessed the most can help a business allocate resources. Information about how various entities use the system can provide behavioral data to the host. Various other business reports and monitoring can also be useful.
The process of FIG. 48 is commenced by the detection of an access system event. In the embodiment of FIG. 22, both the attempt to authenticate (steps 760 & 762) and the attempt to authorize (steps 756 & 790) can be thought of as the detection of an access system event. Thus, the access system events of the embodiment of FIG. 22 includes authorization success, authorization failure, authentication success and authentication failure. Other access system events can also be monitored for use with the present invention. In other embodiment, detecting an access system event can utilize different means than explicitly described in FIG. 22, as long as the system has a means for knowing that an event occurred. Alternatively, an access system event can be detected using specific monitors or sensors.
In step 1870 of FIG. 48, Web Gate 28 reads audit mask 503 from resource cache 502 in response to an authentication or authorization result. If audit mask 503 indicates that the event is not audited (step 1872), then the method is done (step 1874). If the event is to be audited (step 1872), then Web Gate 28 passes retainer 505 to auditing module 544, thus identifying the applicable policy domain and/or policy for auditing. In step 1878, auditing module 544 reads the audit rule associated with the requested resource from audit rule cache 574. In one embodiment, the audit rule read in step 1878 will be a first level (default) audit rule, a second level (specific) audit rule, or a master audit rule applicable to all resources when neither a first or second level audit rule is found. In step 1880, auditing module 544 logs information specified by the found audit rule into one or more audit logs 546. In one embodiment of the present invention, Access Server 34 informs auditing module 544 of authentication and authorization events to be logged, thus, allowing auditing module 544 to perform steps 1878 and 1880 directly in response to an authentication or authorization result, rather than waiting to be prompted by Web Gate 28.
FIG. 49 provides a flow chart of a method for loading audit rules (see step 846 of FIG. 23). In step 1900, Access Server 34 loads the default audit rule for the policy domain mapped in step 836 of FIG. 23 from Directory Server 36 into audit rule cache 574. Access Server 34 then selects a rule in array 565 (step 1902) and determines whether the selected rule is a specific audit rule for a policy associated with the requested resource, by using the method of FIG. 26 previously described above (step 1904). If the resource is part of the policy, then Access Server 34 proceeds to step 1912. Otherwise, Access Server 34 determines whether all rules in array 565 have been considered (step 1906). If not, then Access Server 34 selects the next rule in array 565 (step 1908), and returns to step 1904. Once all rules in array 565 have been considered (step 1906), Access Server 34 proceeds to step 1912. If a second level authentication rule was found for the requested resource in step 1904, then authentication module 540 caches the second level audit rule in audit rule cache 574 (step 1912) and proceeds to step 1914. In step 1914, Access Server 34 prepares audit mask 503, identifying the authentication and authorization events to be logged (audited) by auditing module 544 in accordance with the second level audit rule. If a second level audit rule was not found (step 1910), then the first level audit rule previously loaded in step 1484 remains in audit rule cache 574, and Access Server 34 prepares audit mask 503 using the first level audit rule. Thus, when the method of FIG. 49 is done, only one audit rule for the requested resource will remain in audit rule cache 574.
FIG. 50 depicts one embodiment of components used to detect attempted intrusions. The attempted intrusions can be inadvertent or malicious. The goal is to detect attempted intrusions of the access system, which includes the protected resources. FIG. 50 shows audit logs 546 which can be one or more logs for logging various events. For example, there could be one log for logging authentication failure events, one log for logging authorization failure events, etc. Alternatively, there could be one log for logging multiple types of events. In one embodiment, for each log, or each type of event, an audit log sensor 548 monitors the type of event occurring. For example, in one embodiment there is an authentication failure sensor and an authorization failure sensor. If other events are monitored, there can be a sensor for each of the other events. When an authorization failure event occurs and a log entry is added to audit log 546 for the event, the authorization failure sensor will make a copy of the log entry and send it to database server 1934. Each of the audit log sensors 548 will send copies of log entries they detect to database server 1934. In one embodiment, database server 1934 includes an SQL database for storing all of the received log entries. Periodically, database server 1934 sends a set of log entries to security server 1936. In one embodiment, database server 1934 is stored within the local system of FIG. 1 and security server 1936 is located offsite. In one embodiment, database server 1934 is not provided and the various log sensors send their log entries directly to security server 1936. As discussed above, the audit log entries are fully configurable. The log entries sent by the sensors can be exact duplicates of the log entries in the audit logs or they can be reformatted versions or versions that store only a subset of the original information.
FIG. 51 provides a flow chart describing the operation of the components depicted in FIG. 50. In step 1950, an event is logged. The system is fully configurable to allow the sensors to monitor all or a subset of events being logged. The events being monitored by sensors 548 are denoted as registered events. For example, in one embodiment, the system logs all authentication failure, authentication success, authorization failure and authorization success events, while sensors 548 monitor only authentication failure and authorization failure events. In step 1952, it is determined whether the logged event is a registered event. If not, the method of FIG. 51 is done (step 1964). If it is a registered event, then in step 1954 the sensor accesses instructions for the event type. For each event type being monitored by a sensor, the system is configurable to perform any action specified by the administrator. For example, in one embodiment, an action will be to send the log entry to a database server. In another embodiment the action will also include adding information to the log entry such as information from a user identity profile, login information, time, date, etc. In step 1956, sensor 548 accesses the log entry and performs instructions for the event type to the log entry in step 1958. As discussed above, one exemplar instruction requests that the sensor sends the log entry to either database server 1934 or security server 1936. If the sensor is instructed to send the log entry to database server 1934, then database server 1934 receives and stores the log entry in step 1960. In step 1962, database server 1934 will periodically send all or a subset of the log entries to security server 1936.
FIG. 52 is a flow chart describing the operation of security server 1936. In step 1980, security server 1936 receives a log entry. Step 1980 could include receiving a particular log entry directly from a sensor 548 or receiving a set of log entries from database server 1934. In step 1982, the log entries are stored at security server 1936. In step 1984, a rules engine is run on a set of stored log entries. The log entries used in step 1984 could include the newest set of log entries and, optionally, previous log entries going back historically as needed by the rules engine. The rules engine can look for any particular pattern of events. In one embodiment, the steps of FIGS. 51 and 52 are used to detect one or more attempts of intrusion of the system. For intrusion detection, the rules engine looks for patterns over time of an entity attempting to wrongfully access resources in the system of FIG. 1. In such a case, various patterns can be detected. For example, the rules engine may look for three authorization failures for the same entity or three authentication failures with the same login name or password. Security server 1936 correlates events over time to identify persons or actions that constitute security breaches or attempted security breaches.
FIG. 53 provides a flow chart detailing the steps performed by Access Manager 40 for flushing and synchronizing caches of Web Gate 28 and Access Server 34 in accordance with the present invention. If a change is made (by an administrator, user, or otherwise) to a policy domain or a policy stored on Directory Server 36, any affected first level or second level rules cached in the respective caches of Web Gate 28 and Access Server 34 will become stale data. Similarly, if a change is made to user identity profiles 102 or revoked user list 108 on Directory Server 36, previously cached versions of the changed data will become stale. Accordingly, the respective caches of Web Gate 28 and Access Server 34 must be flushed to prevent Web Gate 28, Access Server 34, User Manager 38, Access Manager 40, or System Console 42 from using the stale data.
In step 2010, Access Manager 40 detects a change to data stored on Directory Server 26. In step 2012, Access Manager 40 reads the previous Global Sequence Number (GSN) 112 stored on directory server 36. In step 2014, Access Manager 40 assigns a current GSN to the change detected in step 2010. In one embodiment of the present invention, the current GSN is the next sequential number after the previous GSN 112. In step 2016, Access Manager 40 stores the current GSN on Directory Server 36, replacing the previous GSN 112. In step 2018, Access Manager 40 generates a synchronization (sync) record to facilitate cache flushing. In step 2020, Access Manager 40 passes a cache flush request and the newly generated synchronization record to each Access Server 34.
FIG. 54 provides a block diagram of a synchronization record in accordance with the present invention. Synchronization record 2040 includes the current GSN 2042 assigned to the change detected in step 2010 of FIG. 53. Synchronization record 2040 also includes IDs 2044, which identify the data affected by the detected change, such as the policy domain, first level rules, policy, second level rules, etc. Synchronization record 2040 also indicates what type of change 2046 was detected (e.g. whether it be an addition, modification, or deletion). Time 2048 is also stored, indicating the time at which the change was detected in step 2010.
FIG. 55 provides a flow chart detailing steps performed by Access Server 34 in response to receiving a synchronization record 2040 from Access Manager 40. In step 2060, Access Server 34 receives a synchronization record and flush request. Access Server 34 updates its stored GSN by replacing the stored GSN with the synchronization record GSN (step 2066). In step 2068, Access Server 34 then flushes the cached information identified by elements 2044, 2046, and 2048 of synchronization record 2040. Access Server 34 then stores synchronization record 2040 on Access Server 34 (step 2070).
FIG. 56 provides a flow chart detailing the steps performed by Web Gate 28 for flushing and synchronizing its caches in accordance with the present invention. In step 2100, Web Gate 28 issues a request to Access Server 34. Upon serving the request, Access Server 34 returns the value of its stored GSN 554 (step 2102) to Web Gate 28. Web Gate 28 compares the GSN 544 returned in step 2102 with GSN 510 stored by Web Gate 28 (step 2104). Web Gate 28 requests all synchronization records 550 stored on Access Server 34 having GSN's greater than GSN 510 stored on Web Gate 28 or appearing in sync record table 518. Web Gate 28 flushes data having ID's 2044 (specified in synchronization record 2040 received from Access Server 34) from its caches (step 2110). In step 2112, Web Gate 28 updates its GSN 510 to equal GSN 554 stored on Access Server 34 (step 2112). In one embodiment, Web Gate 28 maintains a sync record table 518 that identifies all sync records that have not yet been processed by Web Gate 28. For example, a sync record will remain unprocessed if its transmission to Web Gate 28 from Access Server 34 is delayed. In step 2114, Web Gate 28 updates table 518 by removing entries for synchronization records processed in step 2110.
FIG. 57 provides a flow chart describing the process of testing access to resources using the system of FIG. 1. Access Manager 40 includes an Access Tester process. The Access Tester allows an administrator, or any other authorized user, to determine who or what entities may access a resource under the current access criteria, whether a particular individual or set of individuals have access to a resource under certain conditions and whether the first level and second level rules, policies or policy domains associated with a resource operate as intended. In one embodiment, an administrator accesses the Access Tester using a GUI on Access Server 40. In one implementation, the system tests access to a resource without actually authenticating or authorizing access to the resource. Thus, the system is testing a successfully authenticated user's access to the resource. In step 2260, the administrator enters a URL (or other identities) for a resource to be tested. In one alternative, multiple URLs can be entered so that the test is performed for multiple resources. In another alternative, the administrator can select to test for all possible resources so that the Access Tester will determine which resources are available to the users identified for the test. In step 2262, the administrator selects the HTTP request methods that the administrator wants to test. If no HTTP request methods are entered, the system will test all HTTP request methods. Protocols other than HTTP can also be used. In accordance with the present invention other protocols besides HTTP can be used. If the administrator wants to know if a particular computer can access the resource, the administrator can enter the computer's IP address in step 2264. If no IP address is entered in step 2264, then the test will not be limited to any particular computer.
In step 2266 of FIG. 57, the administrator can enter date and time restrictions. In one embodiment, the administrator can indicate that any time and day can be used so that the timing and date restrictions do not restrict the test. Alternatively, the administrator can enter a specific time and/or date for testing. The date and time information can identify a specific date and time or ranges of dates and times. As discussed above, policies can be configured to allow certain access by users at certain times on certain dates. In step 2268, the administrator selects which users to test access for. The administrator can request testing for all possible users or subsets thereof. If the user desires to test for selected users, the administrator can identify individual users. Alternatively, the administrator can use filters, rules, or roles to identify subsets of users. Testing for all users allows an administrator to see which users have access to a particular resource. Steps 2260-2268 are information gathering steps. In one embodiment, they are performed by having an administrator enter information into Access Manager 40. In other embodiments, this information is provided to the Access Tester via a file, a software process, information exchange protocols such as XML, etc.
Steps 2270-2282 are performed by the Access Tester in order to test access to the resource in question. In step 2270, the policy domain is identified for the URL entered in step 2260 using the processes described above. In step 2272, the system searches for a policy associated with the URL in accordance with the processes described above. If more than one URL was entered in step 2260, than more than one policy or more than one policy domain may be identified. In step 2274, the Access Tester chooses one user from the set of users selected in step 2268 and the identity profile for the chosen user is accessed (optional). In step 2276, authorization is checked for that user. Step 2276 is performed in a similar manner as described above with respect to step 756 of FIG. 22, except that after it is determined whether the user is authorized, no log entry is created and the user is not actually authorized. If a policy was found in step 2272, then the authorization rules for the policy are used in step 2276. If no policy was found in step 2272, then the default authorization rules for the policy domain are used in step 2276. The information from steps 2262, 2264, and 2266, and the user's identity profile (optional) are used to determine whether the one or more applicable authorization rules are satisfied. If they are satisfied, then it is determined that the particular user is authorized to access the resource under the conditions entered in steps 2260-2268. In step 2278, it is determined whether there are more users from the set of users identified in step 2268. If there are more users, another user is chosen in step 2280 and the identity profile for that user is accessed. After step 2280, the method loops back to step 2276. If there are no more users to consider (step 2278), then the results are displayed in step 2282.
In one embodiment, the method of displaying and/or the contents of the results in step 2282 are configurable. For example, the administrator can select whether the matching policy domain, policy and/or matching rules should be displayed. One embodiment of step 2282 includes displaying a table (not shown) in a GUI listing all users. For each user, the table displays the URL in question, the request method tested, the policy domain, the policy, the authorization rules, date and time information, IP address information, and an indication of whether the user is authorized to access the resource. In one embodiment, only a configurable subset of this information is displayed. It is possible that a user may have multiple entries in the result table, for example, when the date and timing information results in access grants at some times and access denials at other times. The results table allows an administrator to determine whether the policies created for a particular resource or set of resources are appropriate. In addition, the administrator can use the Access Tester to determine whether specific users have appropriate access rights. The Access Tester quickly allows an administrator to verify authorization rules created for particular policy domains and/or policies. In alternative embodiments of step 2282, the results are reported in a file, in XML, on a printer, using voice, etc. In one embodiment, the results reported could include an indication that access is granted, access is denied, there is redirection to a different resource or it is undetermined (e.g. a custom authorization plug-in cannot be loaded).
Various alternatives to the above-described embodiments are also within the spirit of the present invention. For example, in one embodiment, the system of FIG. 1 can include a separate Identity Server which will perform many (or all) of the tasks associated with managing the Identity System. In one embodiment, such an Identity Server would include a Publisher, a User Manager, a Group Manager and an Organization Manager.
The Publisher is an application that lets a user publish LDAP-based directory information about users, reporting structures, departments, offices and other resources stored in enterprise directories. The User Manager is responsible for password management, certificate management, and delegation administration of user identity profiles. For example, the User Manager can create and delete users, roles, rights and credentials.
The Group Manager manages groups. When a company is setting up an Extranet/Internet or ASP services, the company will need to provide only certain groups of people with access to the application/resources that they are making available. The entities in a group can be determined by specifically adding a person or group, or by identifying a specific attribute or value in user identity profiles. Companies can use these methods to use roles/rights management, or to grant/deny access to the applications that they will need. The Group Manager will manage this group functionality, including supporting multiple types of groups, managing group ownership, group membership, group administration, etc.
The Organization Manager is used to manage organizations. When companies are dealing with outside partners, suppliers, or other organizations (internal or external), the companies need a way to manage those organizations including creating the entity, modifying it or deleting it. There are three fundamental data structures that are used to organize directory data in the directory server: (1) User objects for the actual information about the user; (2) group objects for collections of users; and (3) organization objects, which are containers for user, group and other organization objects. Organizations can be created and removed from the system. Additionally, organizations can be managed by a manager, self managed, or managed in a delegated fashion.
The system can also be implemented with multiple Identity Servers. Each Identity Server will have its own cache or set of caches. In one scenario, if one of the Identity Servers change it cache, it will communicate to the others to flush their cache.
Another alternative embodiment will include Public Key Infrastructure (PKI) integration. By deploying PKI, customers can issue certificates to various users. PKI is a key technology for enabling e-business and e-commerce by making transactions and interactions that are more secure between companies and across the Internet.
Another embodiment includes Pre and Post Processing (PPP). PPP server-side hooks allow customers to extend the business logic of the Identity Systems by communicating with other systems before and after an event happens in the Identity System (or Access System). Customers can hook shared libraries, Pearl scripts or any other applications that can be called from specific well defined points in the processing logic of the application. As an example, during the user creation work flow process, a customer might want to call out to another system that creates an account for a user and provides information that should be stored in the user identity profile. As part of the call out, information can be returned to the Identity System. PPP can be used to perform data validation and password management. PPP could also be used as a notification engine (e.g. when a given action occurs, send an email).
In one embodiment, the system is implemented as a three-tier architecture. This allows the Identity System to be placed behind a firewall, while the only component exposed outside the firewall (or in the DMZ) is a Web Server with a Web Pass plug-in. The Web Pass plug-in is a plug-in for the Web Server that communicates with the Identity Server. The Web Pass Plug-in is analogous to the Web Gate for the access system. This allows customers to run the system with enhanced security and provides another point to do fail over, load balance and utilize redundant servers.
In another embodiment, the system of FIG. 1 can accept input in XML format and provide output in XML format. Additionally, the system will make use of XML remote procedure calls (RPC).
In an alternative implementation, the system could attempt to validate data on input. If a user or application enters data into the system that is outside predefined constraints, the data will be rejected.
In one variation, Access System authorization rules and actions can be created by third party developers through an API. In one embodiment, these custom authorization rules and actions are programmed in C code. In another embodiment, custom authorization rules and actions can reside in an Access System with pre-existing authorization rules and actions.
In another embodiment, “affiliate” Web Gates are installed on remote Web Servers to provide single sign-on authentication across multiple organizations. The affiliate Web Gates can access Web Gates of the Access System, but cannot directly communicate with Access Server 34. For example, a first company may maintain a web site protected by an Access System in accordance with the present invention. If the first company agrees to allow customers of a second company to access a subset of resources on the first company's web site, an affiliate Web Gate will be installed on the second company's web server. When a customer of the second company requests resources from this subset, the affiliate Web Gate will request a Web Gate of the Access System to authenticate the customer. The Access System Web Gate will return a successful or unsuccessful authentication result to the affiliate Web Gate.
FIG. 4, above, shows a hierarchical directory structure. Other data structures can also be used. One example of a suitable alternative is a flat data structure that does not include a hierarchy. Another suitable example includes a fat tree, which is a hierarchy that has few levels and each level is wide (a lot of nodes). One additional feature that can be used with various data structures is the implementation of a variable search base. In some embodiments, a user can access the entire hierarchy, subject to access rules and localized access filters. In other embodiments, users will be limited to only accessing portions of the hierarchy. For example, the system can be set up so that users underneath a particular node in the hierarchy can only access other nodes below that particular node. This restriction on access is done before applying any access criteria and localized access filters, and can be thought of as restricting the search base. In effect, the top root of the hierarchy can then vary on a per user or group basis.
Another alternative embodiment for the Identity System is allow the flow of managing user identity profiles to be configurable so that they can match the procedures of the company or entity.
Policy domain information and policy information can be stored with a resource, with a resource's information in the directory server or in a location on the directory server (or elsewhere) for storing sets of policy domain information and policy information. Additionally, the above described system can work with one directory server or multiple directory servers.
FIG. 58 is a block diagram that depicts an alternative embodiment that allows applications to use an application program interface (API) to accesses authentication and authorization services of an Access Server. The term “application” pertains to a broad range of the software including stand-alone programs, servlets, applets, enterprise java beans (EJB), server pages, etc. The embodiment of FIG. 58 allows applications to authenticate users using access system defined authentication schemes, import user session state from cookies and authorize user requests for resources. FIG. 58 shows web browser 3002 and Web browser 3004 connecting to Web Server 3008 and application server 3040 via the Internet (or other network) 3006. Web Server is 3008 includes a Web Gate 3010. Web server is 3008 can be used to access resource 3012 or resource 3014, as discussed above. Web Gate 3010 can communicate with Access Server 3016 and Access Server 3016 utilizes Directory Server 3018, as discussed above.
FIG. 58 also shows Application Server 3030 in communication with Web Server 3012. Application server 3030 can include any set of applications. For example, application server 3030 may include servlets 3032 and EJBs 3034. The applications on application server 3032 can communicate with the access system using the Access Server API 3036. Thus, FIG. 58 shows servlets 3032 and EJBs 3034 in communication with Access Server API 3036. Access Server API 3036 is in communication with Access Server 3016. In one implementation, a web browser sends a request to Web server 3008. Web server 3008 forwards that request to servlets 3032. Servlet 3032, in combination with EJB 3034, communicates with Access Server API 3362 to authenticate and authorize the user of the web browser. The applications on application server 3030 can access many of the authentication and authorization services from Access Server 3016 by using the Access Server API 3036. Additionally, other types of applications different from the servlet/EJB configuration depicted will work with the present invention. Application server 3030 can also include one or more resources 3031.
In another alternative, a web browser can send a request directly to an application server, without first going through a Web server. For example, web browser 3002 can send a request directly to application server 3040 (via the Internet). Application server 3040 is not connected behind a web server, a Web Gate or any other web agent; therefore, it does not have a web agent front end. A web agent is a component (usually software, but can be hardware or a combination of hardware and software) that plugs into (or otherwise integrates with) a web server (or equivalent) in order to participate in providing access services. A Web Gate is one example of a web agent. Application server 3042 includes applications 3042. As discussed above, applications 3042 can be any suitable application that can run on application server 3040. Application server 3040 also includes Access Server API 3036, which is in communication with Access Server 3016. In one embodiment, application server 303 can also include one or more resources 3041.
In another embodiment, the Access Server API is available on a platform other than an application server. For example, a stand alone application that is not on an application server may use the Access Server API.
Note that the applications that can use the API are not limited to applications on an application server. The applications can be any executable build using the Access Server API.
Depending on the programming languages supported, the Access Server API will include a set of one or more libraries of classes, functions, procedures, etc. that can be called by an application program to access services from Access Server 3016. In one embodiment of the Access Server API provides an interface for Java, C and C++, the Access Server API includes five classes: an authentication scheme class (ObAuthenticationScheme), a resource request class (ObResourceRequest), a user session class (ObUserSession), a configuration class (ObConfig), and an access exception class(ObAccessException). Each of these by classes are defined below. Note that other embodiments include a different set of classes to achieve similar functionality and include more or less than five classes.
The authentication scheme class is used to create ObAuthenticationScheme objects. ObAuthenticationScheme objects represent authentication schemes defined through the Access System and used in the authentication rules for policy domains and policies. An authentication scheme specifies how a user is to be challenged for a set of credentials, name-value string pairs (for example, username and password) that are used to authenticate a user. An authentication scheme has the following elements:
    • a display name,
    • a mask indicating the authentication challenge method to be used
Challenge Mask
Method Bit Expected credentials
none 0x00 none; plug-in should map to anonymous user
basic 0x00 userid and password (e.g. HTTP basic)
certificate 0x02 certificate from SSL/TLS client authentication
(e.g. https)
form 0x04 customer-defined credential fields in an HTML login
form
secure 0x08 credentials must be sent over secure connection
(e.g. https)
    • a numeric level indicating the strength of the authentication,
    • a redirection URL indicating where HTTP authentication is to be performed (may be empty),
    • a set of challenge parameters each of the form parameter:value which supply additional scheme-dependent information
Name Scheme Value
realm basic the authentication domain (e.g. an LDAP directory)
form form the URL of the login form to be displayed to the user
creds form a space-separated list of login form fields to be used as
credentials
action form the URL to which the login form posts its data
    • a sequence of plugins that specify how the credentials are to be processed. Plugins are not visible to user applications.
      Authentication schemes are tied by authentication policies to resources. Certain aspects of authentication (audit policy, actions) are only defined for resources. ObAuthenticationScheme constructors consequently require an ObResourceRequest object to specify the authentication scheme. Below is the API in Java, C and C++:
Java
public class ObAuthenticationScheme {
 public ObAuthenticationScheme(ObResourceRequest res) throws
ObAccessException;
 public String  getName( );
 public int  getMask( );
 public boolean  requiresSecureTransport( );
 public boolean  isBasic( );
 public boolean  isCertificate( );
 public boolean  isForm( );
 public boolean  isNone( );
 public int  getLevel( );
 public String  getRedirectUrl( );
 public String  getChallengeParameter(String parameterName);
 public Hashtable getAllChallengeParameters( );
 public int  getNumberOfChallengeParameters( );
 public Object  clone( ) throws CloneNotSupportedException;
 public void  finalize( );
}
C++
class ObAuthenticationScheme {
public:
 ObAuthenticationScheme( ); // empty
 ObAuthenticationScheme(const ObResourceRequest &res);
 ObAuthenticationScheme(const ObResourceRequest *pRes);
 ObAuthenticationScheme(const ObAuthenticationScheme &other);
// copy constructor
 const char *getName( ) const;
 int  getMask( ) const;
 ObBoolean_t requiresSecureTransport( ) const;
 ObBoolean_t isBasic( ) const;
 ObBoolean_t isCertificate( ) const;
 ObBoolean_t isForm( ) const;
 ObBoolean_t isNone( ) const;
 int  getLevel( ) const;
 const char *getRedirectUrl( ) const;
 const char *getChallengeParameter(const char *parameterName) const;
 const ObMap &getAllChallengeParameters( ) const;
 int getNumberOfChallengeParameters( ) const;
}
C
 typedef const void * ObAuthnScheme_t;
 ObAuthnScheme_t ObAuthn_new(ObResourceRequest_t res);
 const char *ObAuthn_getName(ObAuthnScheme_t scheme);
 int  ObAuthn_getMask(ObAuthnScheme_t scheme);
 ObBoolean_t ObAuthn_requiresSecureTransport(ObAuthn-
 Scheme_t scheme);
 ObBoolean_t ObAuthn_isBasic(ObAuthnScheme_t scheme);
 ObBoolean_t ObAuthn_isCertificate(ObAuthnScheme_t scheme);
 ObBoolean_t ObAuthn_isForm(ObAuthnScheme_t scheme);
 ObBoolean_t ObAuthn_isNone(ObAuthnScheme_t scheme);
 int  ObAuthn_getLevel(ObAuthnScheme_t scheme);
 const char *ObAuthn_getRedirectUrl(ObAuthnScheme_t
 scheme);
 const char *ObAuthn_getChallengeParameter(ObAuthn-
      Scheme_t scheme, const char *parameterName);
 ObMap_t  ObAuthn_getAllChallengeParameters(ObAuthn-
 Scheme_t scheme);
 int  ObAutnn_getNumberOfChallengeParameters(ObAuthn-
Scheme_t scheme);
 void  ObAuthn_free(ObAuthnScheme_t *pScheme);
The resource request class is used to create an ObResourceRequest object. An ObResourceRequest objects represent requests to access resources, including
    • the resource type, using built-in types (for example, http or ejb) or custom types defined through the access system. The resource type can be anything from a URL to an abstract alphabetical string.
    • the name of the resource in the access system name space, in the format
      • [//host[:port]]/resourceName
    •  where the optional host and port indicate the web or application server servicing the resource request.
    • the operation to be performed against the resource, with allowed operations defined by resource type; for example, GET and POST for http resources and EXECUTE for EJB resources. The operations for custom resource types are defined through the access system when the resource type is defined. Other and custom operations can also be supported
    • optionally, a set of parameters (name-value pairs) for the requested operation; parameter names and values must be strings. For http resources, this may be extracted from the request query string or post data. For EJB resources, they may be bean method parameters. In general, they can be any arbitrary data that the application developer and policy setter have agreed upon.
The ObResourceRequest constructors get policy information about the resource request from the access system:
    • whether the resource request is protected, and
    • the authentication scheme defined in the authentication policy that applies to the resource request.
ObResourceRequest objects are used by the ObAuthenticationScheme constructors to retrieve information about the resource's authentication scheme and by the isAuthorized( ) method of the ObUserSession class to determine if a user is authorized to access the resource. Below is the API in Java, C and C++”
Java
public class ObResourceRequest {
 public ObResourceRequest(String resType, String res, String operation)
  throws ObAccessException;
 public ObResourceRequest(String resType, String res, String operation,
      Hashtable parameters) throws ObAccessException;
 public String  getResourceType( );
 public String  getResource( );
 public String  getOperation( );
 public Hashtable getParameters( );
 public boolean  isProtected( ) throws ObAccessException;
 public Object  clone( );
 public void  finalize( );
}
C++
class ObResourceRequest {
public:
 ObResourceRequest( ); // empty
 ObResourceRequest(const char *resType, const char *res);
 ObResourceRequest(const char *resType, const char *res, const
 char *op);
 ObResourceRequest(const char *resType, const char *res, const
 char *op,
     const ObMap &parameters);
 ObResourceRequest(const ObResourceRequest &other); // copy
 constructor
 const char *getResourceType( ) const;
 const char *getResource( ) const;
 const char *getOperation( ) const;
 const ObMap &getParameters( ) const;
 int   getNumberOfParameters( ) const;
 ObBoolean_t isProtected( ) const;
}
C
 typedef const void *ObResourceRequest_t;
 ObResourceRequest_t ObResourceRequest_new(const char *resType,
          const char *res,
          const char *op,
          ObMap_t parameters);
 const char
 *ObResource_getResourceType(ObResourceRequest_t res);
 const char  *ObResource_getResource(ObResourceRequest_t res);
 const char  *ObResource_getOperation(ObResourceRequest_t res);
 const
 ObMap_t ObResource_getParameters(ObResourceRequest_t res);
 ObBoolean_t  ObResource_isProtected(ObResourceRequest_t res);
 void   ObResource_free(ObResourceRequest_t *res);
The user session class is used to create ObUserSession objects. ObUserSession objects represent a user who has successfully authenticated. A user session object is initially created through a constructor that authenticates the user. One constructor takes an ObResourceRequest object and an ObMap of credentials. The resource request determines the authentication scheme that is to be applied to the credentials to authenticate the user. The resource request also determines other aspects of authentication policy: success or failure actions and audit rules.
A session token string is a serialized representation of the user session, for example, from the cookie stored on the client (see FIG. 37). A user session object can be constructed from a valid session token, and a session token can be generated from a user session object.
A session token stored in a cookie is encrypted. The ObUserSession object can get the key (shared secret) from the directory server to decrypt the session token. The application communicating with the API does not have access to the key (shared secret). Thus, if an application wants information from the session token, the application must make a request to the ObUserSession object by calling one of the methods listed below, which will return the desired information in an unencrypted form. The session token stored in a cookie could have been originally created by the API or via a Web Gate.
Elements of a user session object are
    • the user identity; for example, the DN of the user's profile entry in a user directory,
    • the level of the authentication scheme used to authenticate the user,
    • an optional location (DNS hostname or IP address) of the user's client,
    • a session start time recording when the user authenticated, used to determine a session expiration,
    • a last use time set a user request is authorized, used to determine an idle session expiration,
    • actions (name-value pairs) set during authentication and authorization according to policy rules. Each rule defines an arbitrary type for each action that indicates to the application how the action is to be interpreted. For http, action types include “cookie: and “headerVar”.
    • the status of session (logged in, logged out, login failed, or expired), and
    • an error number and localized error message from the most recent authentication or authorization. Error messages are defined in the ObAccessClient.msg message catalog and can have zero to five parameters inserted into the message.
      The isAuthorized( ) method of the user session class determines if the user is authorized to request an operation against a resource in the access system name space. Results of the authorization can be obtained through ObUserSession methods: an error number if the authorization failed, and authorization success or failure policy actions. An authorization audit record may be generated as specified by the audit rule associated with the resource request. Below is code for the API in Java, C and C++.
Java
public class ObUserSession {
 public ObUserSession( ); // empty
 public ObUserSession(ObResourceRequest res, Hashtable credentials)
  throws ObAccessException;
 public ObUserSession(ObResourceRequest res, Hashtable credentials, String location)
  throws ObAccessException;
 public ObUserSession(String sessionToken) throws ObAccessException;
 public String  getUserIdentity( );
 public int  getLevel( );
 public String  getLocation( );
 public int  getStartTime( );
 public int  getLastUseTime( );
 public int  getNumberOfActions(String actionType);
 public Hashtable getActions(String actionType);
 public String  getAction(String actionType, String name);
 public String[ ] getActionTypes( );
 public int  getStatus( );
 public int  getError( );
 public String  getErrorMessage( );
 public boolean  isAuthorized(ObResourceRequest res) throws
ObAccessException;
 public String  getSessionToken( );
 public void  logoff( );
 public Object  clone( );
 public void  finalize( );
 // returned by getStatus( )
 public static int AWAITINGLOGIN;
 public static int LOGGEDIN;
 public static int LOGGEDOUT;
 public static int LOGINFAILED;
 public static int EXPIRED;
 // returned by getError( )
 public static int OK;
 public static int ERR_AUTHN_PLUGIN_DENIED;
 public static int ERR_DENY;
 public static int ERR_IDLE_TIMEOUT;
 public static int ERR_INSUFFICIENT_LEVEL;
 public static int ERR_INVALID_CERTIFICATE;
 public static int ERR_NO_USER;
 public static int ERR_NOT_LOGGED_IN;
 public static int ERR_SESSION_TIMEOUT;
 public static int ERR_UNKNOWN;
 public static int ERR_USER_REVOKED;
 public static int ERR_WRONG_PASSWORD;
}
C++
enum ObUserStatus_t {
 ObUser_AWAITINGLOGIN = 0,
 ObUser_LOGGEDIN,
 ObUser_LOGGEDOUT,
 ObUser_LOGINFAILED,
 ObUser_EXPIRED
};
enum ObUserError_t {
 ObUser_OK = 0,
 ObUser_ERR_UNKNOWN = 100,
 ObUser_ERR_NO_USER,
 ObUser_ERR_USER_REVOKED,
 ObUser_ERR_WRONG_PASSWORD,
 ObUser_ERR_INVALID_CERTIFICATE,
 ObUser_ERR_AUTHN_PLUGIN_DENIED,
 ObUser_ERR_INSUFFICIENT_LEVEL,
 ObUser_ERR_NOT_LOGGED_IN,
 ObUser_ERR_SESSION_TIMEOUT,
 ObUser_ERR_IDLE_TIMEOUT,
 ObUser_ERR_DENY
};
class ObUserSession {
public:
 ObUserSession( ); // empty
 ObUserSession(const char *sessionToken);
 ObUserSession(const ObResourceRequest &res, const ObMap &credentials,
     const char *location = NULL);
 ObUserSession(const ObResourceRequest *pRes, const ObMap &credentials,
     const char *location = NULL);
 ObUserSession(const ObUserSession &other); // copy constructor
 const char *getUserIdentity( ) const;
 const char *getLocation( )const;
 const char *getAction(const char *actionType, const char *name) const;
 const ObMap &getActions(const char *actionType) const;
 const char **getActionTypes( ) const; // NULL terminated array of string pointers
 int   getNumberOfActions(const char *actionType) const;
 int   getLevel( ) const;
 int   getStartTime( ) const;
 int   getLastUseTime( ) const;
 ObUserStatus_t getStatus( ) const;
 ObUserError_t getError( ) const;
 const char *getErrorMessage( ) const;
 ObBoolean_t isAuthorized(const ObResourceRequest &res);
 ObBoolean_t isAuthorized(const ObResourceRequest *pRes);
 const char *getSessionToken( ) const;
 void logoff( );
}
C
 typedef const void *ObUserSession_t;
 ObUserSession_t ObUserSession_fromToken(const char *sessionToken);
 ObUserSession_t ObUserSession_authenticate(ObResourceRequest_t res,
         ObMap_t credentials
         const char *location);
 const char  *ObUser_getUserIdentity(ObUserSession_t user);
 const char  *ObUser_getLocation(ObUserSession_t user);
 const ObMap_t ObUser_getActions(ObUserSession_t user, const char
*actionType);
 const char  *ObUser_getAction(ObUserSession_t user, const char *resType,
       const char *name);
 const char  *ObUser_getSessionToken(ObUserSession_t user);
 int   ObUser_getLevel(ObUserSession_t user);
 int   ObUser_getStartTime(ObUserSession_t user);
 int   ObUser_getLastUseTime(ObUserSession_t user);
 ObUserError_t ObUser_getError(ObUserSession_t user);
 cont char  *ObUser_getErrorMessage(ObUserSession_t user);
 ObUserStatus_t ObUser_getStatus(ObUserSession_t user);
 ObBoolean_t ObUser_isAuthorized(ObUserSession_t user,
        ObResourceRequest_t res);
 void   ObUser_logoff(ObUserSession_t user);
 void   ObUser_free(ObUserSession_t *user);
Each client of the Access Server API must be configured through the access system, which creates an entry for the client in the policy directory. Also, each client must be locally configured using a tool which generates the initial bootstrap ObAccessClient.lst file. The ObConfig class includes class (static) methods to initialize and shutdown the Access Server API and to get part or all of the configuration for the client. The initialize( ) method does the following:
    • Determines the installation directory for the client, either from its configDir parameter or from an environment variable OBACCESS_INSTALL_DIR.
    • checks that the ObAccessClient.lst file exists in the installation directory and is readable by the client program.
    • Reads the bootstrap configuration from ObAccessClient.lst.
    • Opens the ObAccessClient.msg message catalog to be used for user errors and exceptions.
    • Connects to one or more Access Servers specified in the bootstrap configuration.
    • Gets the full client configuration from the Access Server (which in turn reads the client's policy directory entry).
    • Creates the local resource request and authentication scheme caches.
    • Creates a thread to periodically update the client's configuration.
There is a shutdown( ) method that can be called to release resources when an application no longer needs to use the Access Server API. Below is code for Java, C and C++.
Java
public class ObConfig {
 public static void  initialize( ) throws ObAccessException;;
 public static void  initialize(String configDir) throws
 ObAccessException;
 public static void  shutdown( );
 public static int  getNumberOfItems( ) throws ObAccessException;
 public static Hashtable getAllItems( ) throws ObAccessException;;
 public static String  getItem(String name) throws ObAccessException;;
}
C++
class ObConfig {
public:
 static void  initialize(const char *configDir = NULL);
 static void  shutdown( );
 static ObMap  &getAllItems( );
 static int  getNumberOfItems( );
 static const char *getItem(const char* name);
}
C
 void  ObConfig_initialize(const char *configDir);
 void  ObConfig_shutdown( );
 ObMap_t  ObConfig_getAllItems( );
 int   ObConfig_getNumberOfItems( );
 const char *ObConfig_getItem(const char* name);
The configuration items are discussed in the table below:
Name Value
Id string identifier for application; specifies the client's
configuration in the policy directory
cacheTimeout seconds that a cached authentication scheme or resource-
request object will exist before it is automatically flushed. 0
means cache elements will never be flushed.
maxCacheElements maximum number of cached resource-request objects. The size
of the authentication scheme cache is fixed.
failoverThreshold if the number of connections to primary Access Servers falls
below this threshold, the Access API will open connections
to secondary Access Servers.
Debug on or off. The interpretation is up to the application.
WebGate with debug on traces all messages to Access
Servers.
encrypted the security mode used for connecting to the Access Servers
open - no encryption
simple - TLS encryption, using certificates generated from a
built-in CA
cert - TLS encryption, using certificates issued by a full
CA.
lastUpdateTime the last time (in seconds since 1/1/1970 00:00) that client's
configuration was updated.
maxConnections the maximum number of connections that will be opened to
Access Clients
sessionTimeout seconds that a user session created by the application will be
valid
idleTimeout seconds between authorization class that invalidate a session
accessServerTimeout seconds that a connection to an Access Server will be left
open before it is re-established
SleepFor how often (in seconds) that the client checks that its Access
Server connections are up
preferredHost For WebGate, the user's browser will be redirected to this
form of the web server host address if it did not originally
specify it. Other applications are free to interpret or ignore
this as needed.
primaryDomain For WebGate, the domain to be used in setting cookies, e.g.
the single signon domain. Other applications are free to
interpret or ignore this as needed.
state enabled or disabled. The interpretation is up to the
application. A disabled WebGate immediately allows access
to all resources.
primaryServers the Access Servers to which the client will connect to first; a
space-separated list of the format host1:port1, numConn1
host2:port2, numConn2 . . .
secondaryServers the Access Servers to which the client will connect to if the
number of connections to the primary servers falls below the
failoverThreshold; a space-separated list of the format
host1:port1, numConn1host2:port2, numConn2 . . .
When the Access Server API methods detect problems, they will throw an ObAccessException object. Each exception can have from zero to five parameters that inserted in a message defined in the ObAccessClient.msg catalog. Below is the code for the API pertaining to the ObAccessException object:
Java
public class ObAccessException extends java.lang.Exception {
 public ObAccessException(String message);
 // inherited from Throwable
 public String toString( );
}
C++
enum ObAccessExceptionCode_t {
 ObAccessException_OK = 0,
 ObAccessException_UNKNOWN = 200,
 ObAccessException_BAD_SESSION_TOKEN,
 ObAccessException_NO_SCHEME_ID,
 ObAccessException_NEED_PARAMETERS,
 ObAccessException_NOT_INITIALIZED,
 ObAccessException_CACHE_PROBLEM,
 ObAccessException_NO_CONFIG_FILE,
 ObAccessException_NO_INSTALL_DIR_ENV,
 ObAccessException_NOT_PROTECTED,
 ObAccessException_MISSING_RESOURCE,
 ObAccessException_MISSING_OPERATION,
 ObAccessException_BAD_LOCATION,
 ObAccessException_NO_CLIENT_ID,
 ObAccessException_JNI_ERROR,
 ObAccessException_OUT_OF_MEMORY,
 ObAccessException_MISSING_ITEM,
 ObAccessException_NO_MSG_CAT,
 ObAccessException_CLIENT_NOT_IN_DIR,
 ObAccessException_OBERROR,
 // Exceptions for errors returned by the Access Server.
 ObAccessException_AS_UNKNOWN = 300,
 ObAccessException_ENGINE_DOWN,
 ObAccessException_NOCODE,
 ObAccessException_NULL_RESOURCE,
 ObAccessException_HOSTPORT_LOOKUP_FAILED,
 ObAccessException_URL_LOOKUP_FAILED,
 ObAccessException_SD_LOOKUP_FAILED,
 ObAccessException_WROR_LOOKUP_FAILED,
 ObAccessException_WROR_AUTHENT_LOOKUP_FAILED,
 ObAccessException_NO_AUTHENT_SCHEME,
 ObAccessException_EXCEPTION,
 ObAccessException_INVALID_SCHEME_ID,
 ObAccessException_INVALID_SCHEME_MAPPING,
 ObAccessException_INVALID_SCHEME_PARAMETERS,
 ObAccessException_NO_USER,
 ObAccessException_NONUNIQUE_USER,
 ObAccessException_USER_REVOKED,
 ObAccessException_MISSING_OBCRED_PASSWORD,
 ObAccessException_WRONG_PASSWORD,
 ObAccessException_MISSING_PASSWORD,
 ObAccessException_MISSING_CERTIFICATE,
 ObAccessException_INVALID_CERTIFICATE,
 ObAccessException_INVALID_SELECTION_FILTER,
 ObAccessException_MISSING_AUTHN_PLUGIN,
 ObAccessException_AUTHN_PLUGIN_ABORT,
 ObAccessException_AUTHN_PLUGIN_DENIED,
 ObAccessException_AUTHN_PLUGIN_NO_USER
};
class ObAccessException {
 ObAccessException(ObAccessExceptionCode_t code,
    const char *p1 = NULL,
    const char *p2 = NULL,
    const char *p3 = NULL,
    const char *p4 = NULL,
    const char *p5 = NULL);
 ObAccessExceptionCode_t getCode( );
 const char    *toString( );
 static const char *getCodeString(ObAccessExceptionCode_t code,
       const char *p1 = NULL,
       const char *p2 = NULL,
       const char *p3 = NULL,
       const char *p4 = NULL,
       const char *p5 = NULL);
}
C
 typedef void
(*ObAccessExceptionHandler_t) (ObAccessExceptionCode_t code);
 void
ObAccessException_setHandler(ObAccessExceptionHandler_t handler);
 const char
*ObAccessException_getCodeString(ObAccessExceptionCode_t code);
Since the C programming language does not provide an exception facility, the Access Server API allows a C program to define an exception handler function that is called when an exception is generated.
FIG. 59 is a flow chart describing one embodiment of the operation of the components of FIG. 58 when a user sends a request to access a resource using a web browser. The method of FIG. 59 pertains to a request being sent to an application (e.g. servlet, EJB, etc) on application server 3040 or to a stand alone application running on any suitable platform having access to the Access Server API. In step 3100, the request is received by application 3042. The request can be an HTTP request or a request using another protocol. If the request does not include the contents of a cookie (step 3102), then the user must be authenticated and authorized in step 3104. If the request includes information from a cookie (step 3102) then that information is accessed in step 3106. The information from the cookie (see above) is called a session token. In one embodiment, a session token is encrypted as described above. The session token is accessed from the request in step 3106. In step 3108, a resource request object (ObResourceRequest) is created using information from the request. The resource request object is passed the resource type, the name of the resource, the operation being performed on the resource, and optional parameters which may include post data and/or query string data.
In step 3110, an authentication scheme object (ObAuthenticationScheme) is created. The constructor for the authentication scheme object is passed the resource request object. In step 3112, a user session object (ObUserSession) is created. The constructor for the user session object is passed the session token. The key for decrypting the session token is fetched from the directory server (if it is not already local), the session token is decrypted and the contents of the session token is stored in the new object. In step 3114, the system determines whether the cookie is valid. There are many ways for determining if the cookie is valid. In one example, the application can request information from the user session object such as the start time or last use time to determine whether the session is still valid. If the cookie was not valid, then user must be authenticated and authorized in step 3116. If the cookie is valid, then in step 3118 the application requests the authentication level from the authentication scheme object. For example, the application can call the get Level( ) method from theObAuthenticationScheme object. This authentication level pertains to the authentication rule or policy stored in the directory server for the resource. In other embodiments, the different portions of the authentication scheme or all portions of the authentication scheme can be reported to the application by the API. In step 3120, the application requests the authentication level from the session object; for example, calling the getLevel( ) method from the ObUserSession object. This level information is a number originally stored (and encrypted) in the cookie. The ObUserSession provides the level in an unencrypted form.
In step 3122, the application determines whether the authentication level in the cookie is less than or equal to the authentication level stored in the directory server for the resource. If so, then the user is properly authenticated for the resource, but still needs to be authorized to access the resource in step 3124. Because the user has already been properly authenticated, there is no need to request that the user provide any credentials (username, password, certificate, information for a form, etc). If the authentication level from the cookie is greater than the authentication level from the directory server, then user must be authenticated and authorized in step 3126.
FIG. 60 is a flow chart describing one embodiment of authenticating and authorizing a user with the components of FIG. 58. Steps 3104, 3116 and 3126 of FIG. 59 perform the method of FIG. 60. In step 3202, a resource request object is created, if it has not already been created. In step 3204, an authentication scheme object is created, if it has not already been created. In step 3206, it is determined whether the resource is protected. One example of performing step 3206 includes calling the isProtected( ) method of the resource request object. The Access Server determines whether the resource is protected as described above.
If the resource is not protected the application will allow the user to access the requested resource. If the resource is protected, the application accesses the authentication scheme in step 3208. One means for determining the resource authentication scheme is to use the various methods of the ObAuthenticationScheme class, described above. In step 3210, the application requests authentication credentials from the user and stores the credentials in a table in step 3212. The authentication credentials can be any data needed to authenticate. For example, a basic authentication credentials may include a username and a password. The exact type of credentials not important to the present invention. In one embodiment, the credentials is stored in a hash table. In step 3114, a user session object is created, if it has not already been created. The user session object is passed the resource request object and credentials stored in the table. The constructor of the user session object uses the resource request object and the credentials to authenticate the user in step 3216. The process of authentication is performed by the Access Server as described above. If the user is not properly authenticated (step 3222), then the application will send a response to a web browser in step 322 that the authentication failed and the user will not be given access to the resource.
If the user was properly authenticated (step 3222), then the application will request a session token from the API in step 3226. In one embodiment, the session token can be requested using the method getSessionToken( ) of the ObUserSession class. In step 3228, a session token is added to a cookie stored on a client device. In step 3234, the application request the API to authorize the user. One embodiment step 3234 includes calling the isAuthorized( ) to method. In step 3236, the access system will attempt to authorize user to access the requested resource. The process of authorization is performed by the Access Server as described above.
If the user was properly authorized, then the application requests the API for the authorization actions and audit rules in step 3240. Note that step 3240 is optional. In one embodiment, the application will only request the authorization actions. In step 3242, the application will perform the authorization actions and (optionally) the audit rules. In one embodiment, the application can include log files for auditing.
If the user was not properly authorized, then the application responds to the browser that authorization failed in step 3250. In step 3252, the application requested API for the authorization actions and/for rules. In step 3254, the application performs the actions/audit rules. As discussed above with respect to authorization success, steps 3252 and 3254 are optional. One embodiment, the application only accesses the authorization actions and not the audit rules.
FIG. 61 is a flow chart describing the process of authorizing a user to access the resource without requesting additional authentication credentials and performing the full authentication process. The process of FIG. 61 is performed during step 3124 FIG. 59. In step 3302, it is determined whether the resource being requested is protected. As discussed above, one option for performing step 3302 is to call the isProtected( ) method of the resource request object. If the resource is not protected, then the application allows the user to access the resource in step 3304. If the resource is protected, then the application requests the API to authorize the user in step 3306. The request to authorize uses the resource request object and the user session object. For example, step 3306 includes calling the isAuthorized( ) method of the user session object. In step 3308, the Access Server determines whether the user is authorized using the processes discussed above. If the user is authorized (step 3308), the application will allow access to the resource in step 3310. In step 3312, the application will request and receive the authorization actions and audit rules, and perform the necessary actions (and optional logging). If the user was not authorized to access the resource, then in step 3320 the application responds to the browser that authorization has failed. In step 3322 the application requests and receives the authorization actions and audit rules, and then performs necessary actions and/or logging (step 3322 is optional).
FIG. 62 is a flow chart describing, from a high level how a single sign-on (a user providing authentication credentials) can be used to access multiple resources. The various steps of FIG. 62 use the particular methods described above. In step 3400, a user requests access to a first resource. This request is received by an application or a Web Gate. The user is authenticated in step 3402 and a cookie is stored on the user's machine in step 3404. In step 3406, the user is authorized to access the first resource. Subsequent to step 3406, the user requests access to a second resource. The request for access to the second resource is received by an application. In step 3410, the application, in conjunction with the API, authorizes the user to access the second resource without requesting the user to provide additional credentials for a full authentication. That is, the application receives the information from the cookie (the session token) and provides that session token to the API. If the information in the session token indicates that authentication is not necessary, then the user will not be requested to provide any additional credentials.
The Access Server API should protect against several kinds of attacks. First, someone intercepting messages should not be able to obtain policy information or user attribute information. To protect against this, the messages must be encrypted with an algorithm and key strong enough to make cryptoanalysis of the messages infeasible. Second, someone with the Access Server API library and knowledge of the location of an Access Server must not be able to call the API to obtain policy or user information, unless specifically authorized to do so. The API client should authenticate itself to the Access Server, and the Access Server must apply appropriate authorization for the API client's requests.
Third, someone must not be able to impersonate an Access Server to illicitly obtain information like authentication credentials from API clients. To protect against such a scenario, an Access Server should authenticate itself to its clients. Note that in this discussion of security, “API client” includes the WebGate web server agent as well as customer applications calling the Access Server API.
The protocol for communicating with the Access Server provides three security modes, in increasing security and administrative overhead: open, simple, and cert. When an API client connects to an Access Server, both sides send an indication of their configured security modes. If the configured client and server security modes do not match, the connection is terminated.
Open mode provides no encryption. Consequently, policy and user information sent between the clients and servers cannot be protected against disclosure or alteration. Open mode is therefore not recommended in environments where the communication channels are not trusted.
Simple mode is intended to provide strong encryption between clients and servers without requiring a full public key infrastructure (PKI). TLS (Transport Layer Security) is used between the client and server. Triple-DES symmetric encryption is used with a strong key randomly generated for each client-server connection and the RSA public key protocol is used to exchange the key between the client and server. To use RSA, each client and server has a public/private key pair and an X.509 certificate, generated by the access system when the component is installed. All simple mode certificates are signed by a private key built into the access system, so anyone with access to an installation can generate a valid certificate. Consequently the certificates cannot be trusted for authentication between the client and server. To compensate for this, simple mode adds an additional password challenge authentication protocol on top of TLS. The client and the server each share a secret password, supplied either in a local configuration file or interactively when the component is started. The server sends the client a challenge and the client generates a response by computing the MD5 digest of the challenge, a key derived from the password, and TLS connection data. The server authenticates the client by re-computing the digest from the same challenge, key, and TLS data and comparing it to the client's response. Similarly, the client challenges and authenticates the server.
Cert mode provides strong encryption between clients and servers using TLS with triple-DES encryption and RSA key exchange, just as in simple mode. But in cert mode, the client and server X.509 certificates are issued by a trusted certificate authority (CA) like VeriSign, so they can be used for mutual authentication between the client and the server. Consequently, the additional password challenge protocol in simple mode is not required.
Access clients (WebGates and applications that use the Access Server API) have a password that is defined by a system administrator using the Access Client page of the Access System Configuration component. When an access client is configured, the client's password should be entered. The client password is encrypted and stored in a local configuration file, as well as the client's configuration entry in the policy directory.
When an access client connects to an Access Server, the client sends the server its ID and they exchange randomly generated challenges. Each side then computes and sends to its peer the MD5 digest of the peer's challenge and the client's password, and the peer checks the received digest against its own computation of the digest. The connection is allowed only if the digest check is successful on both sides. Consequently, an access client can only connect to an Access Server if it is configured in the policy directory and both the client and the server know the same client password. Since digests of the password and challenge are exchanged instead of the password itself, this authentication method can be used safely over an unencrypted connection.
Client authentication is done independently of the security mode, so the same challenge-password digests are exchanged over open, simple, and cert mode connections. This leads to multiple passwords in some modes. In simple mode, there is the global NAP password, the local certificate (PEM) file password and the password for each client. In cert mode there is the local certificate (PEM) file password and the password for each client.
Below is pseudo code that further illustrates various features of the embodiment of FIG. 58. The first set of pseudo code authenticates a user, (using a basic userid and password) and checks if that user is authorized to access a specified URL:
import java.util.*;
import java.util.Enumeration;
import com.oblix.access.*;
public class AccessChecker {
 public static void main(String[ ] args) {
  if (args.length != 5) {
   System.out.printIn(“expected: userid password
   HTTP-method URL”);
   return;
  }
  String userid  = args[1];
  String password  = args[2];
  String method  = args[3];
  String url  = args[4];
  try {
   ObConfig.initialize( ); // Expects OBACCESS_INSTALL_DIR
   env variable.
   ObResourceRequest res = new ObResourceRequest(“http”,
   url, method);
   if (res.isProtected( ))
   {
    // Check if the required authentication scheme is basic.
     ObAuthenticationScheme authnScheme =
           new ObAuthenticationScheme(res)
    if (authnScheme.isBasic( )) {
     System.out.printIn(“BASIC REALM : ” +
          authnScheme.getChallengeParameter(“realm”));
     // Authenticate using the userid and password
     Hashtable credentials = new Hashtable( );
     credentials.put(“userid”, userid);
     credentials.put(“password”, password);
     ObUserSession user = new ObUserSession(res, credentials);
     if (user.getStatus( ) == ObUserSession.LOGGEDIN) {
      // Check if the user is authorized to access the URL.
      if (user.isAuthorized(res)) {
       System.out.printIn(“GRANTED”);
      }
      else {
       System.out.printIn(“DENIED”);
      }
      // Display actions from authenticate( ) and isAuthorized( ).
      System.out.printIn(“ACTIONS:”);
      String [ ] actionTypes = user.getActionTypes( );
      for (int i = 0; i < actionTypes.length; i++) {
       Hashtable actions = user.getActions(actionType[i]);
       Enumeration e = actions.keys( );
       while (e.hasMoreElements( ))) {
        String name = (String) e.nextElement( );
        System.out.printIn(actionType[i] +
        “: ” + name + “=” +
            actions.get(name));
      }
      user.logoff( );
     }
     else {
      System.out.printIn(“Login failed: ” +
      user.getErrorMessage( ));
     }
    }
    else {
     System.out.printIn(“Resource authentication is not basic”);
    }
   }
   else {
    System.out.printIn(“Resource is not protected”);
   }
  }
  catch (Throwable e) { // ObAccessException is a Throwable object
   System.out.printIn(e.toString( ));
  }
 }
}
The second set of pseudo code is a servlet fragment that gets a session token from a cookie (set by a WebGate or an application using the API) and determines if the user is authorized to access a requested URL. If the user's request is authorized, the requested resource is constructed. If the request is not authorized, a Not Authorized response is returned.
import javax.servlet.*;
import com.oblix.access.*;
public class MyServlet extends HttpServlet
{
 public void doGet(HttpServletRequest req, HttpServletResponse res)
 {
  // Set the user session from the ObSSOCookie from WebGate.
  Cookie[ ] cookies = req.GetCookies( );
  String obSSOcookie;
  for (i = 0; i < cookies.length; i++) {
   if (cookies[i].getName( ).equals(“ObSSSOCookie”)) {
    obSSOcookie = cookies[i].getValue( );
   }
  }
  ObUserSession user = new ObUserSession(obSSOcookie);
  // Make a parameter hashtable from the request query string:
  // name1=val1&name2=val2...
  // Ignore hex decoding for this example.
  Hashtable parameters = new Hashtable( );
  String queryString = req.getQueryString( );
  if (queryString != null) {
   StringTokenizer t = new StringTokenizer(queryString, “=&”);
   while (t.hasMoreTokens( )) {
    String name = t.nextToken( );
    String val = t.hasMoreTokens( ) ? t.nextToken( ) : null;
    parameters.put(name, val);
   }
  }
  // Check if the user is authorized to access the requested resource.
  ObResourceRequest res = new ObResourceRequest(
   “http”,
   req.getRequestURI( ),
   req.getMethod( ),
   req.makeQueryHashTable( ));
  Hashtable actions = new Hashtable( ); // initially empty
  if (!res.isProtected( ) || user.isAuthorized(res)) {
   // construct response
  }
  else {
   // construct Not Authorized response
  }
 }
}
The foregoing detailed description of the invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. The described embodiments were chosen in order to best explain the principles of the invention and its practical application to thereby enable others skilled in the art to best utilize the invention in various embodiments and with various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the claims appended hereto.

Claims (19)

What is claimed is:
1. A method for controlling access to one or more network resources, the method comprising:
receiving at an access control device without a web agent front end and through an Application Program Interface (API) that is not a web page or provided through a web page a request for access to the network resource from an application executing on an application server, wherein the request includes encrypted session state information from a cookie provided by a client, and wherein the application server and access control device do not have access to a key for decrypting the session state information from the cookie;
requesting by the access control device authentication of a user of the application making the request from an access server based on the encrypted session state information from the cookie;
receiving at the access control device from the access server an indication of authentication of the user of the application and decrypted session state information from the cookie;
applying by the access control device one or more access rules to the indication of authentication and the decrypted information from the cookie, the access rules defined in a plurality of nodes of a hierarchical policy domain; and
determining by the access control device whether to allow the requested access based on the indication of authentication of the user and said applying one or more access rules.
2. The method of claim 1, further comprising:
receiving the request for authentication of the user at the access server;
decrypting by the access server the encrypted session state information from the cookie;
authenticating by the access server the user making the request based on the decrypted session state information from the cookie and one or more authentication rules defined in the plurality of nodes of the hierarchical policy domain; and
providing the indication of authentication from the access server to the access control device based on said authenticating, the indication of authentication including the decrypted session state information from the cookie.
3. The method of claim 2, wherein an administration server provides a graphical user interface for managing the one or more access rules.
4. The method of claim 1, wherein the access rule defines access for a group of users and authorizing access of the user is based the access rule and group membership of the user.
5. The method of claim 4, wherein authorization of the user is based on the access rule and a role of the user.
6. The method of claim 1, wherein the resource comprises a network.
7. The method of claim 1, wherein the access control device selects an authentication method from a plurality of authentication methods based on the request for the resource.
8. A system comprising:
an access control device, the access control device comprising a processor and a memory storing a set of instructions which, when executed by the processor, causes the processor to control access to one or more network resources by:
receiving at the access control device without a web agent front end and through an Application Program Interface (API) that is not a web page or provided through a web page a request for access to the network resource from an application executing on an application server, wherein the request includes encrypted session state information from a cookie provided by a client, and wherein the application server and access control device do not have access to a key for decrypting the session state information from the cookie;
requesting by the access control device authentication of a user of the application making the request from an access server based on the encrypted session state information from the cookie;
receiving at the access control device from the access server an indication of authentication of the user of the application and decrypted session state information from the cookie;
applying by the access control device one or more access rules to the indication of authentication and the decrypted session state information from the cookie, the access rules defined in a plurality of nodes of a hierarchical policy domain; and
determining by the access control device whether to allow the requested access based on the indication of authentication of the user and said applying one or more access rules.
9. The system of claim 8, further comprising the access server comprising a processor and a memory storing a set of instructions which, when executed by the processor, causes the processor to:
receive the request for authentication of the user;
decrypting the encrypted session state information from the cookie;
authenticating the user making the request based on the decrypted session state information from the cookie and one or more authentication rules defined in the plurality of nodes of the hierarchical policy domain; and
providing the indication of authentication to the access control device based on said authenticating, the indication of authentication including the decrypted session state information from the cookie.
10. The system of claim 9, further comprising an administration server comprising a processor and a memory storing a set of instructions which, when executed by the processor, causes the processor to provide a graphical user interface for managing the one or more access rules.
11. The system of claim 8, wherein the access rule defines access for a group of users and authorizing access of the user is based the access rule and group membership of the user.
12. The system of claim 11, wherein authorization of the user is based on the access rule and a role of the user.
13. The system of claim 8, wherein the resource comprises a network.
14. The system of claim 8, wherein the access control device selects an authentication method from a plurality of authentication methods based on the request for the resource.
15. A computer-readable memory storing a set of instructions which, when executed by a processor, causes the processor to control access to one or more network resources by:
receiving at an access control device without a web agent front end and through an Application Program Interface (API) that is not a web page or provided through a web page a request for access to the network resource from an application executing on an application server, wherein the request includes encrypted session state information from a cookie provided by a client, and wherein the application server and access control device do not have access to a key for decrypting the session state information from the cookie;
requesting by the access control device authentication of a user of the application making the request from an access server based on the encrypted session state information from the cookie;
receiving at the access control device from the access server an indication of authentication of the user of the application and decrypted session state information from the cookie;
applying one or more access rules to the indication of authentication and the decrypted session state information from the cookie, the access rules defined in a plurality of nodes of a hierarchical policy domain; and
determining whether to allow the requested access based on the indication of authentication of the user and said applying one or more access rules.
16. The computer-readable memory of claim 15, wherein the access rule defines access for a group of users and authorizing access of the user is based the access rule and group membership of the user.
17. The computer-readable memory of claim 16, wherein an administration server provides a graphical user interface for managing the one or more access rules.
18. The computer-readable memory of claim 15, wherein the resource comprises a network.
19. The computer-readable memory of claim 15, wherein the access control device selects an authentication method from a plurality of authentication methods based on the request for the resource.
US12/255,787 2001-02-26 2008-10-22 Access system interface Expired - Fee Related US8935418B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US12/255,787 US8935418B2 (en) 2001-02-26 2008-10-22 Access system interface

Applications Claiming Priority (12)

Application Number Priority Date Filing Date Title
US09/793,355 US8204999B2 (en) 2000-07-10 2001-02-26 Query string processing
US09/792,934 US7134137B2 (en) 2000-07-10 2001-02-26 Providing data to applications from an access system
US09/792,915 US9038170B2 (en) 2000-07-10 2001-02-26 Logging access system events
US09/793,196 US7249369B2 (en) 2000-07-10 2001-02-26 Post data processing
US09/792,918 US7464162B2 (en) 2000-07-10 2001-02-26 Systems and methods for testing whether access to a resource is authorized based on access information
US09/792,911 US7124203B2 (en) 2000-07-10 2001-02-26 Selective cache flushing in identity and access management systems
US09/793,658 US7194764B2 (en) 2000-07-10 2001-02-26 User authentication
US09/793,354 US7080077B2 (en) 2000-07-10 2001-02-26 Localized access
US09/793,320 US8661539B2 (en) 2000-07-10 2001-02-26 Intrusion threat detection
US09/814,091 US7185364B2 (en) 2001-03-21 2001-03-21 Access system interface
US11/588,604 US7458096B2 (en) 2001-03-21 2006-10-27 Access system interface
US12/255,787 US8935418B2 (en) 2001-02-26 2008-10-22 Access system interface

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US11/588,604 Continuation US7458096B2 (en) 2001-02-26 2006-10-27 Access system interface

Publications (2)

Publication Number Publication Date
US20090106433A1 US20090106433A1 (en) 2009-04-23
US8935418B2 true US8935418B2 (en) 2015-01-13

Family

ID=25214147

Family Applications (3)

Application Number Title Priority Date Filing Date
US09/814,091 Expired - Lifetime US7185364B2 (en) 2001-02-26 2001-03-21 Access system interface
US11/588,604 Expired - Lifetime US7458096B2 (en) 2001-02-26 2006-10-27 Access system interface
US12/255,787 Expired - Fee Related US8935418B2 (en) 2001-02-26 2008-10-22 Access system interface

Family Applications Before (2)

Application Number Title Priority Date Filing Date
US09/814,091 Expired - Lifetime US7185364B2 (en) 2001-02-26 2001-03-21 Access system interface
US11/588,604 Expired - Lifetime US7458096B2 (en) 2001-02-26 2006-10-27 Access system interface

Country Status (2)

Country Link
US (3) US7185364B2 (en)
WO (1) WO2002077819A1 (en)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170163556A1 (en) * 2012-04-12 2017-06-08 Netflix, Inc. Method and system for reclaiming unused resources in a networked application environment
KR20180019162A (en) * 2015-06-16 2018-02-23 알리바바 그룹 홀딩 리미티드 A method and device for retransmitting a hypertext transfer protocol request,
US10089219B1 (en) * 2017-01-20 2018-10-02 Intuit Inc. Mock server for testing
US10218704B2 (en) 2016-10-06 2019-02-26 Cisco Technology, Inc. Resource access control using named capabilities
US10984019B2 (en) * 2017-12-25 2021-04-20 Kyocera Document Solutions Inc. Data management system and storage medium
US11050722B2 (en) * 2017-09-12 2021-06-29 Fujitsu Limited Information processing device, program, and information processing method
US20220360565A1 (en) * 2019-04-02 2022-11-10 Bright Data Ltd. System and method for managing non-direct url fetching service
US11748374B2 (en) * 2021-11-30 2023-09-05 Snowflake Inc. Replication group objects configuration in a network-based database system

Families Citing this family (430)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6618806B1 (en) * 1998-04-01 2003-09-09 Saflink Corporation System and method for authenticating users in a computer network
US6965999B2 (en) * 1998-05-01 2005-11-15 Microsoft Corporation Intelligent trust management method and system
US6928547B2 (en) 1998-07-06 2005-08-09 Saflink Corporation System and method for authenticating users in a computer network
US7058817B1 (en) 1999-07-02 2006-06-06 The Chase Manhattan Bank System and method for single sign on process for websites with multiple applications and services
US6725381B1 (en) * 1999-08-31 2004-04-20 Tumbleweed Communications Corp. Solicited authentication of a specific user
AU3438401A (en) 1999-11-04 2001-05-14 Jp Morgan Chase Bank System and method for automated financial project management
US10275780B1 (en) 1999-11-24 2019-04-30 Jpmorgan Chase Bank, N.A. Method and apparatus for sending a rebate via electronic mail over the internet
US8571975B1 (en) 1999-11-24 2013-10-29 Jpmorgan Chase Bank, N.A. System and method for sending money via E-mail over the internet
US9767167B2 (en) * 2000-04-27 2017-09-19 Proquest Llc Method and system for retrieving search results from multiple disparate databases
US7426530B1 (en) 2000-06-12 2008-09-16 Jpmorgan Chase Bank, N.A. System and method for providing customers with seamless entry to a remote server
US10185936B2 (en) 2000-06-22 2019-01-22 Jpmorgan Chase Bank, N.A. Method and system for processing internet payments
US9038170B2 (en) * 2000-07-10 2015-05-19 Oracle International Corporation Logging access system events
US7194764B2 (en) * 2000-07-10 2007-03-20 Oracle International Corporation User authentication
US8204999B2 (en) * 2000-07-10 2012-06-19 Oracle International Corporation Query string processing
US8661539B2 (en) * 2000-07-10 2014-02-25 Oracle International Corporation Intrusion threat detection
US7124203B2 (en) * 2000-07-10 2006-10-17 Oracle International Corporation Selective cache flushing in identity and access management systems
US7464162B2 (en) * 2000-07-10 2008-12-09 Oracle International Corporation Systems and methods for testing whether access to a resource is authorized based on access information
US9928508B2 (en) * 2000-08-04 2018-03-27 Intellectual Ventures I Llc Single sign-on for access to a central data repository
US8566248B1 (en) 2000-08-04 2013-10-22 Grdn. Net Solutions, Llc Initiation of an information transaction over a network via a wireless device
US7257581B1 (en) * 2000-08-04 2007-08-14 Guardian Networks, Llc Storage, management and distribution of consumer information
JP3393604B2 (en) * 2000-09-01 2003-04-07 株式会社インターナショナルビジネスリンク Service provision method
US7266503B2 (en) * 2001-03-22 2007-09-04 International Business Machines Corporation System and method for generating a company group user profile
US7155403B2 (en) 2001-03-22 2006-12-26 International Business Machines Corporation System and method for leveraging procurement across companies and company groups
US7386495B2 (en) 2001-03-23 2008-06-10 International Business Machines Corporation System and method for processing tax codes by company group
US8027892B2 (en) 2001-03-28 2011-09-27 International Business Machines Corporation System and method for automating invoice processing with positive confirmation
US8335855B2 (en) 2001-09-19 2012-12-18 Jpmorgan Chase Bank, N.A. System and method for portal infrastructure tracking
US7802174B2 (en) * 2000-12-22 2010-09-21 Oracle International Corporation Domain based workflows
US7581011B2 (en) * 2000-12-22 2009-08-25 Oracle International Corporation Template based workflow definition
US7185364B2 (en) * 2001-03-21 2007-02-27 Oracle International Corporation Access system interface
US7243077B2 (en) 2001-03-02 2007-07-10 International Business Machines Corporation Method and computer program product for managing an internet trading network
US8849716B1 (en) 2001-04-20 2014-09-30 Jpmorgan Chase Bank, N.A. System and method for preventing identity theft or misuse by restricting access
US20050210263A1 (en) * 2001-04-25 2005-09-22 Levas Robert G Electronic form routing and data capture system and method
US7975042B2 (en) * 2001-05-01 2011-07-05 International Business Machines Corporation Method for adapting an internet web server to short-term changes in demand
WO2002099598A2 (en) 2001-06-07 2002-12-12 First Usa Bank, N.A. System and method for rapid updating of credit information
US7266839B2 (en) 2001-07-12 2007-09-04 J P Morgan Chase Bank System and method for providing discriminated content to network users
US7409420B2 (en) * 2001-07-16 2008-08-05 Bea Systems, Inc. Method and apparatus for session replication and failover
US6918013B2 (en) * 2001-07-16 2005-07-12 Bea Systems, Inc. System and method for flushing bean cache
US7571215B2 (en) * 2001-07-16 2009-08-04 Bea Systems, Inc. Data replication protocol
US7702791B2 (en) * 2001-07-16 2010-04-20 Bea Systems, Inc. Hardware load-balancing apparatus for session replication
US20030023898A1 (en) * 2001-07-16 2003-01-30 Jacobs Dean Bernard Layered architecture for data replication
US8239531B1 (en) * 2001-07-23 2012-08-07 At&T Intellectual Property Ii, L.P. Method and apparatus for connection to virtual private networks for secure transactions
WO2003010669A1 (en) * 2001-07-24 2003-02-06 Barry Porozni Wireless access system, method, signal, and computer program product
US7243369B2 (en) * 2001-08-06 2007-07-10 Sun Microsystems, Inc. Uniform resource locator access management and control system and method
US7130854B2 (en) * 2001-08-14 2006-10-31 Endforce, Inc. Selection and storage of policies in network management
US20030046230A1 (en) * 2001-08-30 2003-03-06 Jacobs Dean Bernard Method for maintaining account consistency
US7028030B2 (en) * 2001-08-30 2006-04-11 Bea Systems, Inc. Cluster caching with concurrency checking
US8560709B1 (en) * 2004-02-25 2013-10-15 F5 Networks, Inc. System and method for dynamic policy based access over a virtual private network
US7113980B2 (en) * 2001-09-06 2006-09-26 Bea Systems, Inc. Exactly once JMS communication
US8108499B2 (en) * 2001-09-12 2012-01-31 Alcatel Societe Anonyme Name registrar system and method
US7103576B2 (en) 2001-09-21 2006-09-05 First Usa Bank, Na System for providing cardless payment
US8621077B2 (en) * 2001-09-21 2013-12-31 Mcafee, Inc. Distribution of security policies for small to medium-sized organizations
JP2003099413A (en) * 2001-09-25 2003-04-04 Nec Commun Syst Ltd Distributed processing system
WO2003027878A1 (en) * 2001-09-28 2003-04-03 Fiberlink Communications Corporation Client-side network access polices and management applications
US7076797B2 (en) * 2001-10-05 2006-07-11 Microsoft Corporation Granular authorization for network user sessions
CA2466071C (en) 2001-11-01 2016-04-12 Bank One, Delaware, N.A. System and method for establishing or modifying an account with user selectable terms
US7412720B1 (en) * 2001-11-02 2008-08-12 Bea Systems, Inc. Delegated authentication using a generic application-layer network protocol
US8244837B2 (en) * 2001-11-05 2012-08-14 Accenture Global Services Limited Central administration of one or more resources
US7225256B2 (en) * 2001-11-30 2007-05-29 Oracle International Corporation Impersonation in an access system
US7987501B2 (en) * 2001-12-04 2011-07-26 Jpmorgan Chase Bank, N.A. System and method for single session sign-on
US8006280B1 (en) 2001-12-12 2011-08-23 Hildebrand Hal S Security system for generating keys from access rules in a decentralized manner and methods therefor
US7260555B2 (en) 2001-12-12 2007-08-21 Guardian Data Storage, Llc Method and architecture for providing pervasive security to digital assets
US7380120B1 (en) 2001-12-12 2008-05-27 Guardian Data Storage, Llc Secured data format for access control
US7783765B2 (en) 2001-12-12 2010-08-24 Hildebrand Hal S System and method for providing distributed access control to secured documents
US7921284B1 (en) 2001-12-12 2011-04-05 Gary Mark Kinghorn Method and system for protecting electronic data in enterprise environment
US7565683B1 (en) 2001-12-12 2009-07-21 Weiqing Huang Method and system for implementing changes to security policies in a distributed security system
US7631184B2 (en) * 2002-05-14 2009-12-08 Nicholas Ryan System and method for imposing security on copies of secured items
US10360545B2 (en) 2001-12-12 2019-07-23 Guardian Data Storage, Llc Method and apparatus for accessing secured electronic data off-line
US8065713B1 (en) 2001-12-12 2011-11-22 Klimenty Vainstein System and method for providing multi-location access management to secured items
US7921450B1 (en) 2001-12-12 2011-04-05 Klimenty Vainstein Security system using indirect key generation from access rules and methods therefor
US7930756B1 (en) 2001-12-12 2011-04-19 Crocker Steven Toye Multi-level cryptographic transformations for securing digital assets
US7921288B1 (en) 2001-12-12 2011-04-05 Hildebrand Hal S System and method for providing different levels of key security for controlling access to secured items
US7178033B1 (en) 2001-12-12 2007-02-13 Pss Systems, Inc. Method and apparatus for securing digital assets
US7478418B2 (en) * 2001-12-12 2009-01-13 Guardian Data Storage, Llc Guaranteed delivery of changes to security policies in a distributed system
US10033700B2 (en) * 2001-12-12 2018-07-24 Intellectual Ventures I Llc Dynamic evaluation of access rights
USRE41546E1 (en) 2001-12-12 2010-08-17 Klimenty Vainstein Method and system for managing security tiers
US7681034B1 (en) 2001-12-12 2010-03-16 Chang-Ping Lee Method and apparatus for securing electronic data
US7305469B2 (en) * 2001-12-18 2007-12-04 Ebay Inc. Prioritization of third party access to an online commerce site
US7509393B2 (en) * 2001-12-19 2009-03-24 International Business Machines Corporation Method and system for caching role-specific fragments
US20030188021A1 (en) * 2001-12-19 2003-10-02 International Business Machines Corporation Method and system for processing multiple fragment requests in a single message
US7950066B1 (en) 2001-12-21 2011-05-24 Guardian Data Storage, Llc Method and system for restricting use of a clipboard application
US7020684B2 (en) * 2002-01-18 2006-03-28 Bea Systems, Inc. System and method for optimistic caching
US6978278B2 (en) * 2002-01-18 2005-12-20 Bea Systems, Inc. System and method for heterogeneous caching
US6898587B2 (en) * 2002-01-18 2005-05-24 Bea Systems, Inc. System and method for performing commutative operations in data access systems
US7334039B1 (en) * 2002-02-01 2008-02-19 Oracle International Corporation Techniques for generating rules for a dynamic rule-based system that responds to requests for a resource on a network
US7243138B1 (en) 2002-02-01 2007-07-10 Oracle International Corporation Techniques for dynamic rule-based response to a request for a resource on a network
US7855972B2 (en) * 2002-02-08 2010-12-21 Enterasys Networks, Inc. Creating, modifying and storing service abstractions and role abstractions representing one or more packet rules
JP2003233590A (en) * 2002-02-08 2003-08-22 Hitachi Ltd Mobile follow-up service providing method, system and program
US8176334B2 (en) 2002-09-30 2012-05-08 Guardian Data Storage, Llc Document security system that permits external users to gain access to secured files
US20030154221A1 (en) * 2002-02-13 2003-08-14 Sun Microsystems, Inc. System and method for accessing file system entities
US7941533B2 (en) 2002-02-19 2011-05-10 Jpmorgan Chase Bank, N.A. System and method for single sign-on session management without central server
US20030163761A1 (en) * 2002-02-21 2003-08-28 Michael Chen System and method for message driven bean service migration
US7392302B2 (en) 2002-02-21 2008-06-24 Bea Systems, Inc. Systems and methods for automated service migration
US7152181B2 (en) 2002-02-22 2006-12-19 Bea Systems, Inc. Method for highly available transaction recovery for transaction processing systems
US7178050B2 (en) * 2002-02-22 2007-02-13 Bea Systems, Inc. System for highly available transaction recovery for transaction processing systems
US20030163575A1 (en) * 2002-02-27 2003-08-28 Perkins Gregory Eugene Resource location and access
US7506313B2 (en) * 2002-03-04 2009-03-17 International Business Machines Corporation Debug of code with selective display of data
US20030177364A1 (en) * 2002-03-15 2003-09-18 Walsh Robert E. Method for authenticating users
US20030177390A1 (en) * 2002-03-15 2003-09-18 Rakesh Radhakrishnan Securing applications based on application infrastructure security techniques
NO318842B1 (en) * 2002-03-18 2005-05-09 Telenor Asa Authentication and access control
US7418500B1 (en) 2002-03-25 2008-08-26 Network Appliance, Inc. Mechanism for controlled sharing of files in a clustered application environment
US7496952B2 (en) * 2002-03-28 2009-02-24 International Business Machines Corporation Methods for authenticating a user's credentials against multiple sets of credentials
US7748045B2 (en) * 2004-03-30 2010-06-29 Michael Frederick Kenrich Method and system for providing cryptographic document retention with off-line access
US8613102B2 (en) * 2004-03-30 2013-12-17 Intellectual Ventures I Llc Method and system for providing document retention using cryptography
US7606881B2 (en) * 2002-04-25 2009-10-20 Oracle International Corporation System and method for synchronization of version annotated objects
US7076567B1 (en) * 2002-04-25 2006-07-11 Oracle International Corporation Simplified application object data synchronization for optimized data storage
US8799501B2 (en) * 2002-04-30 2014-08-05 Hewlett-Packard Development Company, L. P. System and method for anonymously sharing and scoring information pointers, within a system for harvesting community knowledge
US7277924B1 (en) 2002-05-07 2007-10-02 Oracle International Corporation Method and mechanism for a portal website architecture
US7548957B1 (en) 2002-05-07 2009-06-16 Oracle International Corporation Method and mechanism for a portal website architecture
US7840658B2 (en) * 2002-05-15 2010-11-23 Oracle International Corporation Employing job code attributes in provisioning
US20030220978A1 (en) * 2002-05-24 2003-11-27 Rhodes Michael J. System and method for message sender validation
WO2003104947A2 (en) * 2002-06-06 2003-12-18 Hardt Dick C Distributed hierarchical identity management
US7444414B2 (en) * 2002-07-10 2008-10-28 Hewlett-Packard Development Company, L.P. Secure resource access in a distributed environment
US7373347B2 (en) * 2002-07-22 2008-05-13 Ricoh Company, Ltd. Information processing apparatus and information processing method
US20110119353A1 (en) * 2002-08-06 2011-05-19 Tsao Sheng Tai Ted Method and Apparatus for information exchange over a web based environment
US7127681B1 (en) * 2002-09-10 2006-10-24 Cisco Technology Inc. Method for managing contents of a web site
US7512810B1 (en) 2002-09-11 2009-03-31 Guardian Data Storage Llc Method and system for protecting encrypted files transmitted over a network
US20040059941A1 (en) * 2002-09-19 2004-03-25 Myfamily.Com, Inc. Systems and methods for identifying users and providing access to information in a network environment
US7058660B2 (en) 2002-10-02 2006-06-06 Bank One Corporation System and method for network-based project management
US7787489B2 (en) * 2002-10-07 2010-08-31 Oracle International Corporation Mobile data distribution
US7480935B2 (en) * 2002-10-10 2009-01-20 International Business Machines Corporation Method for protecting subscriber identification between service and content providers
US7296235B2 (en) * 2002-10-10 2007-11-13 Sun Microsystems, Inc. Plugin architecture for extending polices
US20040073668A1 (en) * 2002-10-10 2004-04-15 Shivaram Bhat Policy delegation for access control
US7793342B1 (en) * 2002-10-15 2010-09-07 Novell, Inc. Single sign-on with basic authentication for a transparent proxy
US7814050B2 (en) * 2002-10-22 2010-10-12 Brocade Communications Systems, Inc. Disaster recovery
US7568218B2 (en) * 2002-10-31 2009-07-28 Microsoft Corporation Selective cross-realm authentication
US7526798B2 (en) * 2002-10-31 2009-04-28 International Business Machines Corporation System and method for credential delegation using identity assertion
US7836310B1 (en) 2002-11-01 2010-11-16 Yevgeniy Gutnik Security system that uses indirect password-based encryption
US8301493B2 (en) 2002-11-05 2012-10-30 Jpmorgan Chase Bank, N.A. System and method for providing incentives to consumers to share information
US7426642B2 (en) * 2002-11-14 2008-09-16 International Business Machines Corporation Integrating legacy application/data access with single sign-on in a distributed computing environment
US7890990B1 (en) 2002-12-20 2011-02-15 Klimenty Vainstein Security system with staging capabilities
US7779247B2 (en) 2003-01-09 2010-08-17 Jericho Systems Corporation Method and system for dynamically implementing an enterprise resource policy
US7503061B2 (en) * 2003-03-24 2009-03-10 Hewlett-Packard Development Company, L.P. Secure resource access
US8612590B1 (en) 2003-04-11 2013-12-17 International Business Machines Corporation Method and apparatus for access management
US7343628B2 (en) 2003-05-28 2008-03-11 Sap Ag Authorization data model
US8707034B1 (en) 2003-05-30 2014-04-22 Intellectual Ventures I Llc Method and system for using remote headers to secure electronic files
US20040254832A1 (en) * 2003-06-12 2004-12-16 Michael Harkin Integrated browser plug-in and user defined database
CA2686265A1 (en) * 2003-06-17 2004-12-17 Ibm Canada Limited - Ibm Canada Limitee Multiple identity management in an electronic commerce site
US7594256B2 (en) * 2003-06-26 2009-09-22 Sun Microsystems, Inc. Remote interface for policy decisions governing access control
GB2418757B (en) * 2003-07-07 2006-11-08 Progress Software Corp Multi-platform single sign-on database driver
US7334254B1 (en) * 2003-07-31 2008-02-19 Sprint Communications Company L.P. Business-to-business security integration
WO2005020002A2 (en) * 2003-08-15 2005-03-03 Fiberlink Communications Corporation System, method, apparatus and computer program product for facilitating digital communications
US8127366B2 (en) 2003-09-30 2012-02-28 Guardian Data Storage, Llc Method and apparatus for transitioning between states of security policies used to secure electronic documents
US7703140B2 (en) 2003-09-30 2010-04-20 Guardian Data Storage, Llc Method and system for securing digital assets using process-driven security policies
US7904487B2 (en) * 2003-10-09 2011-03-08 Oracle International Corporation Translating data access requests
US7882132B2 (en) * 2003-10-09 2011-02-01 Oracle International Corporation Support for RDBMS in LDAP system
US7594018B2 (en) * 2003-10-10 2009-09-22 Citrix Systems, Inc. Methods and apparatus for providing access to persistent application sessions
US20050086531A1 (en) * 2003-10-20 2005-04-21 Pss Systems, Inc. Method and system for proxy approval of security changes for a file security system
US9614772B1 (en) 2003-10-20 2017-04-04 F5 Networks, Inc. System and method for directing network traffic in tunneling applications
US8190893B2 (en) 2003-10-27 2012-05-29 Jp Morgan Chase Bank Portable security transaction protocol
US7533370B2 (en) * 2003-10-28 2009-05-12 Exent Technologies, Ltd. Security features in on-line and off-line delivery of applications
US7653688B2 (en) * 2003-11-05 2010-01-26 Sap Ag Role-based portal to a workplace system
JP4049730B2 (en) * 2003-11-12 2008-02-20 シャープ株式会社 Data output device
US20050138371A1 (en) * 2003-12-19 2005-06-23 Pss Systems, Inc. Method and system for distribution of notifications in file security systems
US7702909B2 (en) * 2003-12-22 2010-04-20 Klimenty Vainstein Method and system for validating timestamps
US7243157B2 (en) * 2004-02-20 2007-07-10 Microsoft Corporation Dynamic protocol construction
US7664828B2 (en) * 2004-02-20 2010-02-16 Microsoft Corporation Invalid policy detection
US7523486B1 (en) * 2004-03-05 2009-04-21 Sprint Communications Company Lp User administration tool
US7702767B2 (en) * 2004-03-09 2010-04-20 Jp Morgan Chase Bank User connectivity process management system
US20050226468A1 (en) * 2004-03-30 2005-10-13 Intel Corporation Method and apparatus for enabling context awareness in a wireless system
US7823192B1 (en) * 2004-04-01 2010-10-26 Sprint Communications Company L.P. Application-to-application security in enterprise security services
US20050240671A1 (en) * 2004-04-23 2005-10-27 Loraine Beyer IP-based front-end web server
US8095658B2 (en) * 2004-05-07 2012-01-10 International Business Machines Corporation Method and system for externalizing session management using a reverse proxy server
US7640574B1 (en) * 2004-06-02 2009-12-29 Sun Microsystems, Inc. Method and system for resource based authentication
US8245049B2 (en) * 2004-06-14 2012-08-14 Microsoft Corporation Method and system for validating access to a group of related elements
US8527752B2 (en) 2004-06-16 2013-09-03 Dormarke Assets Limited Liability Graduated authentication in an identity management system
US9245266B2 (en) * 2004-06-16 2016-01-26 Callahan Cellular L.L.C. Auditable privacy policies in a distributed hierarchical identity management system
US8504704B2 (en) * 2004-06-16 2013-08-06 Dormarke Assets Limited Liability Company Distributed contact information management
US7823197B2 (en) 2004-06-30 2010-10-26 Panasonic Corporation Program execution device and program execution method
US7665127B1 (en) * 2004-06-30 2010-02-16 Jp Morgan Chase Bank System and method for providing access to protected services
US7587755B2 (en) * 2004-07-02 2009-09-08 Citrix Systems, Inc. System and method for executing interactive applications with minimal privileges
US7707427B1 (en) 2004-07-19 2010-04-27 Michael Frederick Kenrich Multi-level file digests
US7478426B2 (en) * 2004-07-20 2009-01-13 International Busines Machines Corporation Multi-field classification dynamic rule updates
US7725589B2 (en) * 2004-08-16 2010-05-25 Fiberlink Communications Corporation System, method, apparatus, and computer program product for facilitating digital communications
US7885934B2 (en) * 2004-08-17 2011-02-08 Teleran Technologies, Inc. Monitoring and auditing system
US7797294B2 (en) * 2004-08-25 2010-09-14 International Business Machines Corporation Method, system and program for testing accessibility in data processing system programs
US7752203B2 (en) * 2004-08-26 2010-07-06 International Business Machines Corporation System and method for look ahead caching of personalized web content for portals
US8272032B2 (en) 2004-11-10 2012-09-18 Mlb Advanced Media, L.P. Multiple user login detection and response system
US7996883B2 (en) * 2004-12-09 2011-08-09 International Business Machines Corporation Centralized identity management for delegating resource management in a technology outsourcing environment
US8024360B2 (en) * 2004-12-10 2011-09-20 Centrify Corporation Method and apparatus for maintaining multiple sets of identity data
US9143502B2 (en) * 2004-12-10 2015-09-22 International Business Machines Corporation Method and system for secure binding register name identifier profile
US20060136999A1 (en) * 2004-12-16 2006-06-22 Martin Kreyscher Trust based relationships
US8015561B2 (en) * 2004-12-28 2011-09-06 Sap Ag System and method for managing memory of Java session objects
US7694065B2 (en) * 2004-12-28 2010-04-06 Sap Ag Distributed cache architecture
US8204931B2 (en) * 2004-12-28 2012-06-19 Sap Ag Session management within a multi-tiered enterprise network
US7539821B2 (en) * 2004-12-28 2009-05-26 Sap Ag First in first out eviction implementation
US20060143256A1 (en) 2004-12-28 2006-06-29 Galin Galchev Cache region concept
US8281014B2 (en) * 2004-12-28 2012-10-02 Sap Ag Session lifecycle management within a multi-tiered enterprise network
US7971001B2 (en) * 2004-12-28 2011-06-28 Sap Ag Least recently used eviction implementation
US20060259950A1 (en) * 2005-02-18 2006-11-16 Ulf Mattsson Multi-layer system for privacy enforcement and monitoring of suspicious data access behavior
US20060195544A1 (en) * 2005-02-28 2006-08-31 Bcks Posting and receiving resources for external applications using a web browser as an agent
US7392253B2 (en) * 2005-03-03 2008-06-24 Microsoft Corporation System and method for secure full-text indexing
US20060206922A1 (en) * 2005-03-08 2006-09-14 Securedatainnovations Ag Secure Remote Access To Non-Public Private Web Servers
US8290979B1 (en) * 2005-03-10 2012-10-16 The United States Of America As Represented By The Secretary Of The Navy Software architecture for access control based on hierarchical characteristics
US7792860B2 (en) * 2005-03-25 2010-09-07 Oracle International Corporation System for change notification and persistent caching of dynamically computed membership of rules-based lists in LDAP
US8631476B2 (en) * 2005-03-31 2014-01-14 Sap Ag Data processing system including explicit and generic grants of action authorization
US9069436B1 (en) * 2005-04-01 2015-06-30 Intralinks, Inc. System and method for information delivery based on at least one self-declared user attribute
US8024566B2 (en) * 2005-04-29 2011-09-20 Sap Ag Persistent storage implementations for session data within a multi-tiered enterprise network
US8762547B2 (en) * 2005-04-29 2014-06-24 Sap Ag Shared memory implementations for session data within a multi-tiered enterprise network
US7853698B2 (en) * 2005-04-29 2010-12-14 Sap Ag Internal persistence of session state information
US7761435B2 (en) * 2005-04-29 2010-07-20 Sap Ag External persistence of session state information
US20060248283A1 (en) * 2005-04-29 2006-11-02 Galin Galchev System and method for monitoring threads in a clustered server architecture
US20060248199A1 (en) * 2005-04-29 2006-11-02 Georgi Stanev Shared closure persistence of session state information
US8589562B2 (en) 2005-04-29 2013-11-19 Sap Ag Flexible failover configuration
US7571473B1 (en) 2005-06-10 2009-08-04 Sprint Communications Company L.P. Identity management system and method
US8185877B1 (en) 2005-06-22 2012-05-22 Jpmorgan Chase Bank, N.A. System and method for testing applications
US7966412B2 (en) * 2005-07-19 2011-06-21 Sap Ag System and method for a pluggable protocol handler
US9282081B2 (en) 2005-07-28 2016-03-08 Vaporstream Incorporated Reduced traceability electronic message system and method
US7610345B2 (en) * 2005-07-28 2009-10-27 Vaporstream Incorporated Reduced traceability electronic message system and method
US8418233B1 (en) * 2005-07-29 2013-04-09 F5 Networks, Inc. Rule based extensible authentication
US20070033157A1 (en) * 2005-08-08 2007-02-08 Simdesk Technologies Transaction protection in a stateless architecture using commodity servers
US8533308B1 (en) 2005-08-12 2013-09-10 F5 Networks, Inc. Network traffic management through protocol-configurable transaction processing
US20070055752A1 (en) * 2005-09-08 2007-03-08 Fiberlink Dynamic network connection based on compliance
WO2007031955A2 (en) * 2005-09-16 2007-03-22 Koninklijke Philips Electronics, N.V. Cryptographic role-based access control
US8583926B1 (en) 2005-09-19 2013-11-12 Jpmorgan Chase Bank, N.A. System and method for anti-phishing authentication
JP2007096704A (en) * 2005-09-28 2007-04-12 Brother Ind Ltd Data transmission system, data transmitting method, program, and data transmitting device
US7716721B2 (en) * 2005-10-18 2010-05-11 Cisco Technology, Inc. Method and apparatus for re-authentication of a computing device using cached state
US8260908B2 (en) * 2005-11-16 2012-09-04 Cisco Technologies, Inc. Techniques for sequencing system log messages
US8095960B2 (en) * 2005-11-21 2012-01-10 Novell, Inc. Secure synchronization and sharing of secrets
US8069153B2 (en) * 2005-12-02 2011-11-29 Salesforce.Com, Inc. Systems and methods for securing customer data in a multi-tenant environment
US20070143851A1 (en) 2005-12-21 2007-06-21 Fiberlink Method and systems for controlling access to computing resources based on known security vulnerabilities
US20070143827A1 (en) * 2005-12-21 2007-06-21 Fiberlink Methods and systems for intelligently controlling access to computing resources
US20070150934A1 (en) * 2005-12-22 2007-06-28 Nortel Networks Ltd. Dynamic Network Identity and Policy management
CA2531533C (en) * 2005-12-28 2013-08-06 Bce Inc. Session-based public key infrastructure
US8688813B2 (en) * 2006-01-11 2014-04-01 Oracle International Corporation Using identity/resource profile and directory enablers to support identity management
US20070174429A1 (en) 2006-01-24 2007-07-26 Citrix Systems, Inc. Methods and servers for establishing a connection between a client system and a virtual machine hosting a requested computing environment
DE102006007793B3 (en) * 2006-02-20 2007-05-31 Siemens Ag User-conference`s termination detecting method for Internet gateway, involves transmitting status information from client device to gateway, and transmitting hypertext transfer protocol redirect on web page requested by device
US8744885B2 (en) * 2006-03-28 2014-06-03 Snowflake Itm, Inc. Task based organizational management system and method
JP2007299236A (en) * 2006-04-28 2007-11-15 Toshiba Corp Information processor and authentication method
US8042160B1 (en) * 2006-06-22 2011-10-18 Sprint Communications Company L.P. Identity management for application access
US8793490B1 (en) 2006-07-14 2014-07-29 Jpmorgan Chase Bank, N.A. Systems and methods for multifactor authentication
US8566925B2 (en) * 2006-08-03 2013-10-22 Citrix Systems, Inc. Systems and methods for policy based triggering of client-authentication at directory level granularity
US8091126B2 (en) * 2006-08-18 2012-01-03 Microsoft Corporation Failure recognition
US20080077704A1 (en) * 2006-09-24 2008-03-27 Void Communications, Inc. Variable Electronic Communication Ping Time System and Method
US20080077791A1 (en) * 2006-09-27 2008-03-27 Craig Lund System and method for secured network access
US8327142B2 (en) 2006-09-27 2012-12-04 Secureauth Corporation System and method for facilitating secure online transactions
US8176525B2 (en) * 2006-09-29 2012-05-08 Rockstar Bidco, L.P. Method and system for trusted contextual communications
US7841000B2 (en) * 2006-10-16 2010-11-23 Lenovo (Singapore) Pte. Ltd. Authentication password storage method and generation method, user authentication method, and computer
FR2908252B1 (en) * 2006-11-02 2008-12-26 Alcatel Sa METHOD FOR REAL-TIME INTERACTIVE SHARING OF SERVER MULTIMEDIA DATA AND REAL-TIME INTERACTIVE COMMUNICATION NETWORK
US9762576B2 (en) 2006-11-16 2017-09-12 Phonefactor, Inc. Enhanced multi factor authentication
US8510813B2 (en) * 2006-12-15 2013-08-13 Yahoo! Inc. Management of network login identities
US8032922B2 (en) * 2006-12-18 2011-10-04 Oracle International Corporation Method and apparatus for providing access to an application-resource
US20080163063A1 (en) * 2006-12-29 2008-07-03 Sap Ag Graphical user interface system and method for presenting information related to session and cache objects
US20080189776A1 (en) * 2007-02-01 2008-08-07 Credit Suisse Securities (Usa) Llc Method and System for Dynamically Controlling Access to a Network
US8533291B1 (en) * 2007-02-07 2013-09-10 Oracle America, Inc. Method and system for protecting publicly viewable web client reference to server resources and business logic
WO2008101165A2 (en) * 2007-02-15 2008-08-21 Void Communications, Inc. Electronic messaging recordlessness warning and routing system and method
US7917759B2 (en) * 2007-03-30 2011-03-29 Symantec Corporation Identifying an application user as a source of database activity
US7992198B2 (en) * 2007-04-13 2011-08-02 Microsoft Corporation Unified authentication for web method platforms
US8327456B2 (en) * 2007-04-13 2012-12-04 Microsoft Corporation Multiple entity authorization model
US20080263389A1 (en) * 2007-04-20 2008-10-23 At&T Knowledge Ventures, L.P. System for monitoring enum performance
US20080271122A1 (en) * 2007-04-27 2008-10-30 John Edward Nolan Granulated hardware resource protection in an electronic system
US8473735B1 (en) 2007-05-17 2013-06-25 Jpmorgan Chase Systems and methods for managing digital certificates
US9800614B2 (en) * 2007-05-23 2017-10-24 International Business Machines Corporation Method and system for global logoff from a web-based point of contact server
US20080313730A1 (en) * 2007-06-15 2008-12-18 Microsoft Corporation Extensible authentication management
US8474022B2 (en) * 2007-06-15 2013-06-25 Microsoft Corporation Self-service credential management
US8984620B2 (en) * 2007-07-06 2015-03-17 Cyberoam Technologies Pvt. Ltd. Identity and policy-based network security and management system and method
KR100944724B1 (en) * 2007-08-21 2010-03-03 엔에이치엔비즈니스플랫폼 주식회사 User authentication system using IP address and method thereof
US8621573B2 (en) * 2007-08-28 2013-12-31 Cisco Technology, Inc. Highly scalable application network appliances with virtualized services
JP4912996B2 (en) * 2007-09-18 2012-04-11 株式会社日立製作所 Information processing apparatus and computer system
US7925694B2 (en) * 2007-10-19 2011-04-12 Citrix Systems, Inc. Systems and methods for managing cookies via HTTP content layer
US20090112932A1 (en) * 2007-10-26 2009-04-30 Microsoft Corporation Visualizing key performance indicators for model-based applications
JP2009110214A (en) * 2007-10-30 2009-05-21 Hitachi Ltd Data access control system and method according to position information of mobile terminal
US20090126007A1 (en) * 2007-11-08 2009-05-14 Avantia, Inc. Identity management suite
US20090132537A1 (en) * 2007-11-16 2009-05-21 Daron Denton System and Method for Managing Storage and Access of Data Files
US20090132713A1 (en) * 2007-11-20 2009-05-21 Microsoft Corporation Single-roundtrip exchange for cross-domain data access
US7930264B2 (en) * 2007-12-06 2011-04-19 First Data Corporation Multi-module authentication platform
US20090177510A1 (en) * 2008-01-04 2009-07-09 Marsh L Trenton System and method of generating a business plan
US8321682B1 (en) 2008-01-24 2012-11-27 Jpmorgan Chase Bank, N.A. System and method for generating and managing administrator passwords
US8090877B2 (en) 2008-01-26 2012-01-03 Citrix Systems, Inc. Systems and methods for fine grain policy driven cookie proxying
US9430660B2 (en) * 2008-01-31 2016-08-30 International Business Machines Corporation Managing access in one or more computing systems
US8181155B2 (en) * 2008-02-29 2012-05-15 Microsoft Corporation Unified expression and location framework
US8196175B2 (en) * 2008-03-05 2012-06-05 Microsoft Corporation Self-describing authorization policy for accessing cloud-based resources
US8418222B2 (en) * 2008-03-05 2013-04-09 Microsoft Corporation Flexible scalable application authorization for cloud computing environments
US8301877B2 (en) 2008-03-10 2012-10-30 Secureauth Corporation System and method for configuring a valid duration period for a digital certificate
US8959199B2 (en) * 2008-03-18 2015-02-17 Reduxio Systems Ltd. Network storage system for a download intensive environment
US20090248855A1 (en) * 2008-03-31 2009-10-01 International Business Machines Corporation Method for monitoring web page statistics
US8094560B2 (en) * 2008-05-19 2012-01-10 Cisco Technology, Inc. Multi-stage multi-core processing of network packets
US8667556B2 (en) 2008-05-19 2014-03-04 Cisco Technology, Inc. Method and apparatus for building and managing policies
US8677453B2 (en) 2008-05-19 2014-03-18 Cisco Technology, Inc. Highly parallel evaluation of XACML policies
US9832069B1 (en) 2008-05-30 2017-11-28 F5 Networks, Inc. Persistence based on server response in an IP multimedia subsystem (IMS)
US8055587B2 (en) * 2008-06-03 2011-11-08 International Business Machines Corporation Man in the middle computer technique
US8356345B2 (en) * 2008-06-03 2013-01-15 International Business Machines Corporation Constructing a secure internet transaction
US9736207B1 (en) * 2008-06-13 2017-08-15 West Corporation Passive outdial support for mobile devices via WAP push of an MVSS URL
US8719572B2 (en) * 2008-07-16 2014-05-06 Disney Enterprises, Inc. System and method for managing authentication cookie encryption keys
US20100017889A1 (en) * 2008-07-17 2010-01-21 Symantec Corporation Control of Website Usage Via Online Storage of Restricted Authentication Credentials
US8788681B1 (en) * 2008-08-25 2014-07-22 Symantec Corporation Method and apparatus for autonomously managing a computer resource using a security certificate
US9130846B1 (en) 2008-08-27 2015-09-08 F5 Networks, Inc. Exposed control components for customizable load balancing and persistence
US8689289B2 (en) * 2008-10-02 2014-04-01 Microsoft Corporation Global object access auditing
US20100100950A1 (en) * 2008-10-20 2010-04-22 Roberts Jay B Context-based adaptive authentication for data and services access in a network
US20100138907A1 (en) * 2008-12-01 2010-06-03 Garret Grajek Method and system for generating digital certificates and certificate signing requests
US8464256B1 (en) 2009-04-10 2013-06-11 Open Invention Network, Llc System and method for hierarchical interception with isolated environments
US9577998B2 (en) * 2008-12-17 2017-02-21 International Business Machines Corporation Dynamic file access to files of unmapped remote computers
JP4737283B2 (en) * 2008-12-19 2011-07-27 富士ゼロックス株式会社 Program, information processing apparatus and information processing system
JP4631969B2 (en) * 2008-12-25 2011-02-16 富士ゼロックス株式会社 License management apparatus and license management program
US20100180329A1 (en) * 2009-01-09 2010-07-15 International Business Machines Corporation Authenticated Identity Propagation and Translation within a Multiple Computing Unit Environment
US8844040B2 (en) * 2009-03-20 2014-09-23 Citrix Systems, Inc. Systems and methods for using end point auditing in connection with traffic management
US8347356B2 (en) * 2009-03-31 2013-01-01 Microsoft Corporation Adaptive HTTP authentication scheme selection
US8266680B2 (en) * 2009-03-31 2012-09-11 Microsoft Corporation Predictive HTTP authentication mode negotiation
US10419504B1 (en) 2009-04-10 2019-09-17 Open Invention Network Llc System and method for streaming application isolation
US8555360B1 (en) 2009-04-10 2013-10-08 Open Invention Network Llc System and method for on-line and off-line streaming application isolation
US11538078B1 (en) 2009-04-10 2022-12-27 International Business Machines Corporation System and method for usage billing of hosted applications
US8418236B1 (en) * 2009-04-10 2013-04-09 Open Invention Network Llc System and method for streaming application isolation
US8788809B2 (en) * 2009-04-27 2014-07-22 Qualcomm Incorporated Method and apparatus to create a secure web-browsing environment with privilege signing
US8843648B2 (en) * 2009-05-26 2014-09-23 Microsoft Corporation External access and partner delegation
US8850041B2 (en) * 2009-05-26 2014-09-30 Microsoft Corporation Role based delegated administration model
US8332647B2 (en) * 2009-06-25 2012-12-11 Raytheon Company System and method for dynamic multi-attribute authentication
US9608826B2 (en) 2009-06-29 2017-03-28 Jpmorgan Chase Bank, N.A. System and method for partner key management
MY159467A (en) * 2009-07-07 2017-01-13 Netsweeper (Barbados) Inc System and method for providing customized response messages based on requested website
US8489685B2 (en) 2009-07-17 2013-07-16 Aryaka Networks, Inc. Application acceleration as a service system and method
US8776214B1 (en) 2009-08-12 2014-07-08 Amazon Technologies, Inc. Authentication manager
US20120198539A1 (en) * 2009-08-31 2012-08-02 China Mobile Communications Corporation Service Access Method, System and Device Based on WLAN Access Authentication
CA2774648C (en) * 2009-09-30 2017-07-25 Amazon Technologies, Inc. Modular device authentication framework
JP2011077769A (en) * 2009-09-30 2011-04-14 Fujifilm Corp Vpn system and operation control method thereof
US20110093367A1 (en) * 2009-10-20 2011-04-21 At&T Intellectual Property I, L.P. Method, apparatus, and computer product for centralized account provisioning
US9165043B2 (en) * 2009-11-25 2015-10-20 Maobing Jin Logical object search framework and application programming interface
US10057239B2 (en) 2009-12-17 2018-08-21 Pulse Secure, Llc Session migration between network policy servers
US20110166943A1 (en) * 2010-01-07 2011-07-07 Oracle International Corporation Policy-based advertisement engine
US20110167479A1 (en) * 2010-01-07 2011-07-07 Oracle International Corporation Enforcement of policies on context-based authorization
US9509791B2 (en) 2010-01-07 2016-11-29 Oracle International Corporation Policy-based exposure of presence
US20130036455A1 (en) * 2010-01-25 2013-02-07 Nokia Siemens Networks Oy Method for controlling acess to resources
US9495521B2 (en) * 2010-02-05 2016-11-15 Oracle International Corporation System self integrity and health validation for policy enforcement
US20110196728A1 (en) * 2010-02-05 2011-08-11 Oracle International Corporation Service level communication advertisement business
US9467858B2 (en) * 2010-02-05 2016-10-11 Oracle International Corporation On device policy enforcement to secure open platform via network and open network
US20110225649A1 (en) * 2010-03-11 2011-09-15 International Business Machines Corporation Protecting Computer Systems From Malicious Software
US20120036263A1 (en) * 2010-05-21 2012-02-09 Open Subnet Inc. System and Method for Monitoring and Controlling Access to Web Content
US8266292B2 (en) * 2010-06-21 2012-09-11 Microsoft Corporation Memorable resource names
US20110321117A1 (en) * 2010-06-23 2011-12-29 Itt Manufacturing Enterprises, Inc. Policy Creation Using Dynamic Access Controls
US8744990B2 (en) * 2010-07-09 2014-06-03 Yahoo! Inc. Rule based, proactive web browsing
WO2012005739A1 (en) * 2010-07-09 2012-01-12 Hewlett-Packard Development Company, L.P. Responses to server challenges included in a hypertext transfer protocol header
US8838962B2 (en) * 2010-09-24 2014-09-16 Bryant Christopher Lee Securing locally stored Web-based database data
EP2668563A4 (en) * 2011-01-27 2015-06-10 Varonis Systems Inc Access permissions management system and method
US9680839B2 (en) 2011-01-27 2017-06-13 Varonis Systems, Inc. Access permissions management system and method
US9118657B1 (en) * 2011-03-15 2015-08-25 Avior, Inc. Extending secure single sign on to legacy applications
US9342274B2 (en) 2011-05-19 2016-05-17 Microsoft Technology Licensing, Llc Dynamic code generation and memory management for component object model data constructs
US8881101B2 (en) 2011-05-24 2014-11-04 Microsoft Corporation Binding between a layout engine and a scripting engine
US8689298B2 (en) * 2011-05-31 2014-04-01 Red Hat, Inc. Resource-centric authorization schemes
US10362019B2 (en) 2011-07-29 2019-07-23 Amazon Technologies, Inc. Managing security credentials
US9767262B1 (en) 2011-07-29 2017-09-19 Amazon Technologies, Inc. Managing security credentials
US11444936B2 (en) 2011-07-29 2022-09-13 Amazon Technologies, Inc. Managing security credentials
US9069943B2 (en) 2011-08-15 2015-06-30 Bank Of America Corporation Method and apparatus for token-based tamper detection
US8752123B2 (en) 2011-08-15 2014-06-10 Bank Of America Corporation Apparatus and method for performing data tokenization
US8566918B2 (en) * 2011-08-15 2013-10-22 Bank Of America Corporation Method and apparatus for token-based container chaining
WO2013068789A1 (en) * 2011-11-11 2013-05-16 Pismo Labs Technology Ltd. Method and system for allowing the use of domain names in enforcing network policy
US9934310B2 (en) * 2012-01-18 2018-04-03 International Business Machines Corporation Determining repeat website users via browser uniqueness tracking
US8863250B2 (en) 2012-02-01 2014-10-14 Amazon Technologies, Inc. Logout from multiple network sites
US8955065B2 (en) * 2012-02-01 2015-02-10 Amazon Technologies, Inc. Recovery of managed security credentials
US9253176B2 (en) 2012-04-27 2016-02-02 Intralinks, Inc. Computerized method and system for managing secure content sharing in a networked secure collaborative exchange environment
US9251360B2 (en) 2012-04-27 2016-02-02 Intralinks, Inc. Computerized method and system for managing secure mobile device content viewing in a networked secure collaborative exchange environment
US9152803B2 (en) * 2012-04-24 2015-10-06 Oracle International Incorporated Optimized policy matching and evaluation for hierarchical resources
US9547764B2 (en) 2012-04-24 2017-01-17 Oracle International Corporation Optimized policy matching and evaluation for non-hierarchical resources
US9553860B2 (en) 2012-04-27 2017-01-24 Intralinks, Inc. Email effectivity facility in a networked secure collaborative exchange environment
CA2871600A1 (en) 2012-04-27 2013-10-31 Intralinks, Inc. Computerized method and system for managing networked secure collaborative exchange
JP5968077B2 (en) * 2012-05-22 2016-08-10 キヤノン株式会社 Information processing apparatus, control method therefor, program, and image processing apparatus
US20140007197A1 (en) * 2012-06-29 2014-01-02 Michael John Wray Delegation within a computing environment
US9596328B2 (en) * 2012-08-09 2017-03-14 Oracle International Corporation Hierarchical criteria-based timeout protocols
US8745718B1 (en) 2012-08-20 2014-06-03 Jericho Systems Corporation Delivery of authentication information to a RESTful service using token validation scheme
US9083691B2 (en) * 2012-09-14 2015-07-14 Oracle International Corporation Fine-grained user authentication and activity tracking
US9424543B2 (en) 2012-09-27 2016-08-23 International Business Machines Corporation Authenticating a response to a change request
US9092607B2 (en) * 2012-10-01 2015-07-28 Oracle International Corporation Dynamic flow control for access managers
US8925050B2 (en) * 2012-10-29 2014-12-30 Oracle International Corporation Communication between authentication plug-ins of a single-point authentication manager and client systems
CN103841154B (en) * 2012-11-26 2019-03-01 腾讯科技(北京)有限公司 Network media information dissemination method, system and client
US9690759B2 (en) * 2013-01-03 2017-06-27 Cable Television Laboratories, Inc. Content linking
US9251363B2 (en) 2013-02-20 2016-02-02 Varonis Systems, Inc. Systems and methodologies for controlling access to a file system
US9300644B1 (en) * 2013-02-22 2016-03-29 Symantec Corporation Knowledge-based authentication based on tracked credential usage
US9282098B1 (en) 2013-03-11 2016-03-08 Amazon Technologies, Inc. Proxy server-based network site account management
US9419957B1 (en) 2013-03-15 2016-08-16 Jpmorgan Chase Bank, N.A. Confidence-based authentication
US10193993B2 (en) 2013-05-30 2019-01-29 Ebay Inc. Systems and methods of token piggybacking
US9430452B2 (en) 2013-06-06 2016-08-30 Microsoft Technology Licensing, Llc Memory model for a layout engine and scripting engine
US9590884B2 (en) * 2013-07-03 2017-03-07 Facebook, Inc. Native application hotspot
US10666771B2 (en) 2013-08-05 2020-05-26 Pismo Labs Technology Limited Method and system for allowing the use of domain name based network policies stored in a second device in enforcing network policy at a first device
US20150089632A1 (en) * 2013-09-26 2015-03-26 Aaron Robert Bartholomew Application authentication checking system
US9514327B2 (en) 2013-11-14 2016-12-06 Intralinks, Inc. Litigation support in cloud-hosted file sharing and collaboration
US10475018B1 (en) 2013-11-29 2019-11-12 Amazon Technologies, Inc. Updating account data for multiple account providers
US9742840B2 (en) * 2013-12-20 2017-08-22 Siemens Aktiengesellschaft Integration of user interfaces for different physically distributed medical applications
US10122717B1 (en) 2013-12-31 2018-11-06 Open Text Corporation Hierarchical case model access roles and permissions
US9477818B1 (en) * 2014-01-02 2016-10-25 Google Inc. Leveraging a unification of content hosting and social networking
US9961011B2 (en) 2014-01-21 2018-05-01 Oracle International Corporation System and method for supporting multi-tenancy in an application server, cloud, or other environment
US10148726B1 (en) 2014-01-24 2018-12-04 Jpmorgan Chase Bank, N.A. Initiating operating system commands based on browser cookies
US20150242529A1 (en) * 2014-02-21 2015-08-27 Pradeep S. Kinger Method for Interlacing Multiple Internet domain names with a Database Driven Website to Obtain Better Webpage Ranking on Major Search Engines by Executing Computer-Executable Instructions Stored On a Non-Transitory Computer-Readable Medium
GB2530685A (en) 2014-04-23 2016-03-30 Intralinks Inc Systems and methods of secure data exchange
WO2015174968A1 (en) * 2014-05-13 2015-11-19 Hewlett-Packard Development Company, L.P. Network access control at controller
TW201547247A (en) * 2014-06-13 2015-12-16 Vivotek Inc Web authentication methods and system
US10015242B2 (en) * 2014-06-23 2018-07-03 Oracle International Corporation System and method for supporting restful management in a multitenant application server environment
US9405929B1 (en) 2014-07-31 2016-08-02 Emc Corporation Hierarchical permissions model within a document
EP3178200A4 (en) * 2014-08-07 2018-04-11 Intel IP Corporation Control of traffic from applications when third party servers encounter problems
US9454773B2 (en) 2014-08-12 2016-09-27 Danal Inc. Aggregator system having a platform for engaging mobile device users
US10154082B2 (en) 2014-08-12 2018-12-11 Danal Inc. Providing customer information obtained from a carrier system to a client device
US9461983B2 (en) 2014-08-12 2016-10-04 Danal Inc. Multi-dimensional framework for defining criteria that indicate when authentication should be revoked
US10318280B2 (en) 2014-09-24 2019-06-11 Oracle International Corporation System and method for supporting patching in a multitenant application server environment
KR102443172B1 (en) 2014-09-24 2022-09-14 오라클 인터내셔날 코포레이션 System and method for supporting patching in a multitenant application server environment
US9059985B1 (en) 2014-12-08 2015-06-16 Fmr Llc Methods for fraud detection
US20160173502A1 (en) * 2014-12-15 2016-06-16 International Business Machines Corporation Jurisdictional cloud data access
US20160205081A1 (en) * 2015-01-14 2016-07-14 Microsoft Technology Licensing, Llc Hierarchical data security
US10250512B2 (en) 2015-01-21 2019-04-02 Oracle International Corporation System and method for traffic director support in a multitenant application server environment
JP6449993B2 (en) * 2015-04-15 2019-01-09 株式会社日立システムズ Single sign-on system and single sign-on method
EP3318037B1 (en) * 2015-07-02 2023-06-21 Convida Wireless, LLC Content security at service layer
US10033702B2 (en) 2015-08-05 2018-07-24 Intralinks, Inc. Systems and methods of secure data exchange
US9866592B2 (en) * 2015-09-28 2018-01-09 BlueTalon, Inc. Policy enforcement system
US9871825B2 (en) 2015-12-10 2018-01-16 BlueTalon, Inc. Policy enforcement for compute nodes
WO2017166166A1 (en) 2016-03-31 2017-10-05 Oracle International Corporation System and method for providing runtime tracing for web-based client accessing transactional middleware platform using extension interface
CN108476216B (en) * 2016-03-31 2021-01-22 甲骨文国际公司 System and method for integrating a transactional middleware platform with a centralized access manager for single sign-on in an enterprise-class computing environment
US10515317B1 (en) 2016-07-29 2019-12-24 Microsoft Technology Licensing, Llc Machine learning algorithm for user engagement based on confidential data statistical information
US10484387B1 (en) * 2016-07-29 2019-11-19 Microsoft Technology Licensing, Llc Tracking submission of confidential data in a computer system
US10616320B2 (en) 2016-09-16 2020-04-07 Oracle International Corporation System and method for restful management distributed collection in an application server environment
US11057431B2 (en) 2016-09-22 2021-07-06 Vmware, Inc. Methods and apparatus to provide resource security
US10135810B2 (en) * 2016-11-17 2018-11-20 Adp, Llc Selective authentication system
US10880295B2 (en) * 2017-03-06 2020-12-29 Ssh Communications Security Oyj Access control in a computer system
US10791119B1 (en) * 2017-03-14 2020-09-29 F5 Networks, Inc. Methods for temporal password injection and devices thereof
US10868721B2 (en) 2017-08-17 2020-12-15 Oracle International Corporation System and method for supporting a situational configuration in an application server environment
US10715472B2 (en) 2017-08-22 2020-07-14 Oracle International Corporation System and method for unit-of-order routing
US11070559B2 (en) 2017-08-23 2021-07-20 Oracle International Corporation System and method for supporting object-based security
CN108366120A (en) * 2018-02-13 2018-08-03 宁夏灵智科技有限公司 A kind of internet-of-things terminal management method and device
US10165109B1 (en) 2018-02-20 2018-12-25 Ploytech Ipco Pty Ltd. Telephony software control via web application
US11157571B2 (en) * 2018-07-12 2021-10-26 Bank Of America Corporation External network system for extracting external website data using generated polymorphic data
EP3830721A4 (en) 2018-07-31 2021-08-18 Visa International Service Association Pre-authorization access request screening
GB2579574B (en) * 2018-12-03 2021-08-11 Advanced Risc Mach Ltd Bootstrapping with common credential data
IT201900005876A1 (en) * 2019-04-16 2020-10-16 Roberto Griggio SYSTEM AND METHOD FOR MANAGING THE MULTI-DOMAIN ACCESS CREDENTIALS OF A USER ENABLED TO ACCESS A PLURALITY OF DOMAINS
US11461484B2 (en) 2019-12-30 2022-10-04 Imperva, Inc. Capturing contextual information for data accesses to improve data security
US11418395B2 (en) * 2020-01-08 2022-08-16 Servicenow, Inc. Systems and methods for an enhanced framework for a distributed computing system
US11108763B2 (en) * 2020-01-09 2021-08-31 Cisco Technology, Inc. Intelligent identity-aware application proxy
US11522867B2 (en) 2020-03-31 2022-12-06 LendingClub Bank, National Association Secure content management through authentication
US11470090B2 (en) 2020-03-31 2022-10-11 LendingClub Bank, National Association Dynamically-tiered authentication
US11483312B2 (en) * 2020-03-31 2022-10-25 LendingClub Bank, National Association Conditionally-deferred authentication steps for tiered authentication
US11023607B1 (en) * 2020-04-03 2021-06-01 Imperva, Inc. Detecting behavioral anomalies in user-data access logs
US11876778B2 (en) * 2020-04-05 2024-01-16 Raja Srinivasan Methods and systems of a secure and private customer service automation platform
US11876796B2 (en) * 2020-06-09 2024-01-16 Strata Identity, Inc. Systems, methods, and storage media for abstraction and enforcement in an identity infrastructure
US20220006654A1 (en) * 2020-07-02 2022-01-06 EMC IP Holding Company LLC Method to establish an application level ssl certificate hierarchy between master node and capacity nodes based on hardware level certificate hierarchy
US11184444B1 (en) * 2020-07-27 2021-11-23 International Business Machines Corporation Network traffic reduction by server-controlled cookie selection
US11595444B2 (en) 2020-12-03 2023-02-28 International Business Machines Corporation Authenticity assessment of a requestor based on a communication request
WO2023287678A1 (en) * 2021-07-13 2023-01-19 Mastercard Internationalincorporated Systems and methods for use in altering attributes of user identities on networks
US20230015697A1 (en) * 2021-07-13 2023-01-19 Citrix Systems, Inc. Application programming interface (api) authorization

Citations (234)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4484306A (en) 1982-03-22 1984-11-20 Exide Electronics Corporation Method and apparatus for controlling access in a data transmission system
US4956769A (en) 1988-05-16 1990-09-11 Sysmith, Inc. Occurence and value based security system for computer databases
US4961224A (en) 1989-03-06 1990-10-02 Darby Yung Controlling access to network resources
US5023773A (en) 1988-02-10 1991-06-11 International Business Machines Corporation Authorization for selective program access to data in multiple address spaces
US5077666A (en) 1988-11-07 1991-12-31 Emtek Health Care Systems, Inc. Medical information system with automatic updating of task list in response to charting interventions on task list window into an associated form
US5113499A (en) 1989-04-28 1992-05-12 Sprint International Communications Corp. Telecommunication access management system for a packet switching network
US5226143A (en) 1990-03-14 1993-07-06 International Business Machines Corporation Multiprocessor system includes operating system for notifying only those cache managers who are holders of shared locks on a designated page by global lock manager
US5261102A (en) * 1991-03-28 1993-11-09 International Business Machines Corporation System for determining direct and indirect user access privileges to data base objects
US5428795A (en) 1992-07-31 1995-06-27 International Business Machines Corporation Method of and apparatus for providing automatic security control of distributions within a data processing system
US5455953A (en) 1993-11-03 1995-10-03 Wang Laboratories, Inc. Authorization system for obtaining in single step both identification and access rights of client to server directly from encrypted authorization ticket
US5530861A (en) 1991-08-26 1996-06-25 Hewlett-Packard Company Process enaction and tool integration via a task oriented paradigm
US5557742A (en) 1994-03-07 1996-09-17 Haystack Labs, Inc. Method and system for detecting intrusion into and misuse of a data processing system
US5581691A (en) 1992-02-04 1996-12-03 Digital Equipment Corporation Work flow management system and method
US5678041A (en) 1995-06-06 1997-10-14 At&T System and method for restricting user access rights on the internet based on rating information stored in a relational database
US5689679A (en) 1993-04-28 1997-11-18 Digital Equipment Corporation Memory system and method for selective multi-level caching using a cache level code
US5692125A (en) 1995-05-09 1997-11-25 International Business Machines Corporation System and method for scheduling linked events with fixed and dynamic conditions
US5708780A (en) 1995-06-07 1998-01-13 Open Market, Inc. Internet server access control and monitoring systems
US5757920A (en) 1994-07-18 1998-05-26 Microsoft Corporation Logon certification
US5765153A (en) 1996-01-03 1998-06-09 International Business Machines Corporation Information handling system, method, and article of manufacture including object system authorization and registration
US5764890A (en) 1994-12-13 1998-06-09 Microsoft Corporation Method and system for adding a secure network server to an existing computer network
US5793966A (en) 1995-12-01 1998-08-11 Vermeer Technologies, Inc. Computer system and computer-implemented process for creation and maintenance of online services
US5802518A (en) 1996-06-04 1998-09-01 Multex Systems, Inc. Information delivery system and method
US5812776A (en) 1995-06-07 1998-09-22 Open Market, Inc. Method of providing internet pages by mapping telephone number provided by client to URL and returning the same in a redirect command by server
US5819271A (en) 1996-06-04 1998-10-06 Multex Systems, Inc. Corporate information communication and delivery system and method including entitlable hypertext links
US5826029A (en) 1995-10-31 1998-10-20 International Business Machines Corporation Secured gateway interface
US5842212A (en) 1996-03-05 1998-11-24 Information Project Group Inc. Data modeling and computer access record memory
US5845267A (en) * 1996-09-06 1998-12-01 At&T Corp System and method for billing for transactions conducted over the internet from within an intranet
US5872969A (en) 1995-06-23 1999-02-16 International Business Machines Corporation System and method for efficiently synchronizing cache and persistent data in an object oriented transaction processing system
US5875461A (en) 1997-04-03 1999-02-23 Sun Microsystems, Inc. Method of synchronizing one of the objects with one of the threads at a time
US5884312A (en) * 1997-02-28 1999-03-16 Electronic Data Systems Corporation System and method for securely accessing information from disparate data sources through a network
US5889952A (en) 1996-08-14 1999-03-30 Microsoft Corporation Access check system utilizing cached access permissions
US5892903A (en) 1996-09-12 1999-04-06 Internet Security Systems, Inc. Method and apparatus for detecting and identifying security vulnerabilities in an open network computer communication system
US5893149A (en) 1996-07-01 1999-04-06 Sun Microsystems, Inc. Flushing of cache memory in a computer system
US5903878A (en) 1997-08-20 1999-05-11 Talati; Kirit K. Method and apparatus for electronic commerce
US5907621A (en) 1996-11-15 1999-05-25 International Business Machines Corporation System and method for session management
US5908469A (en) 1997-02-14 1999-06-01 International Business Machines Corporation Generic user authentication for network computers
US5918013A (en) * 1996-06-03 1999-06-29 Webtv Networks, Inc. Method of transcoding documents in a network environment using a proxy server
US5924096A (en) 1997-10-15 1999-07-13 Novell, Inc. Distributed database using indexed into tags to tracks events according to type, update cache, create virtual update log on demand
US5940394A (en) 1996-08-08 1999-08-17 At&T Corp Transferring messages in networks made up of subnetworks with different namespaces
US5944780A (en) 1997-05-05 1999-08-31 At&T Corp Network with shared caching
US5944824A (en) * 1997-04-30 1999-08-31 Mci Communications Corporation System and method for single sign-on to a plurality of network elements
US5978779A (en) 1997-11-14 1999-11-02 Merrill Lynch, Pierce, Fenner & Smith Distributed architecture utility
US5991881A (en) 1996-11-08 1999-11-23 Harris Corporation Network surveillance system
US5991771A (en) 1995-07-20 1999-11-23 Novell, Inc. Transaction synchronization in a disconnectable computer and network
US5991878A (en) * 1997-09-08 1999-11-23 Fmr Corp. Controlling access to information
US5991810A (en) 1997-08-01 1999-11-23 Novell, Inc. User name authentication for gateway clients accessing a proxy cache server
US5999911A (en) 1995-06-02 1999-12-07 Mentor Graphics Corporation Method and system for managing workflow
US6005571A (en) 1997-09-30 1999-12-21 Softline, Inc. Graphical user interface for managing security in a database system
US6012059A (en) 1997-08-21 2000-01-04 Dataxel Corporation Method and apparatus for replicated transaction consistency
US6014666A (en) * 1997-10-28 2000-01-11 Microsoft Corporation Declarative and programmatic access control of component-based server applications using roles
US6018619A (en) 1996-05-24 2000-01-25 Microsoft Corporation Method, system and apparatus for client-side usage tracking of information server systems
US6020884A (en) 1996-11-08 2000-02-01 America Online, Inc. System integrating an on-line service community with a foreign service
US6023684A (en) * 1997-10-01 2000-02-08 Security First Technologies, Inc. Three tier financial transaction system with cache memory
US6026474A (en) 1996-11-22 2000-02-15 Mangosoft Corporation Shared client-side web caching using globally addressable memory
US6028605A (en) 1998-02-03 2000-02-22 Documentum, Inc. Multi-dimensional analysis of objects by manipulating discovered semantic properties
US6029195A (en) 1994-11-29 2000-02-22 Herz; Frederick S. M. System for customized electronic identification of desirable objects
US6032227A (en) 1996-09-30 2000-02-29 International Business Machines Corporation System and method for cache management in mobile user file systems
US6041357A (en) 1997-02-06 2000-03-21 Electric Classified, Inc. Common session token system and protocol
US6052468A (en) * 1998-01-15 2000-04-18 Dew Engineering And Development Limited Method of securing a cryptographic key
US6058480A (en) 1996-06-03 2000-05-02 Cranberry Properties, Llc System for remote pass-phase authentication
US6058381A (en) 1996-10-30 2000-05-02 Nelson; Theodor Holm Many-to-many payments system for network content materials
US6061799A (en) 1997-10-31 2000-05-09 International Business Machines Corp. Removable media for password based authentication in a distributed system
US6064656A (en) * 1997-10-31 2000-05-16 Sun Microsystems, Inc. Distributed system and method for controlling access control to network resources
US6073174A (en) 1994-09-27 2000-06-06 Bristish Telecommunications Remote access systems
US6073109A (en) 1993-02-08 2000-06-06 Action Technologies, Inc. Computerized method and system for managing business processes using linked workflows
US6076108A (en) * 1998-03-06 2000-06-13 I2 Technologies, Inc. System and method for maintaining a state for a user session using a web system having a global session server
US6081518A (en) 1999-06-02 2000-06-27 Anderson Consulting System, method and article of manufacture for cross-location registration in a communication system architecture
US6088679A (en) 1997-12-01 2000-07-11 The United States Of America As Represented By The Secretary Of Commerce Workflow management employing role-based access control
US6088796A (en) 1998-08-06 2000-07-11 Cianfrocca; Francis Secure middleware and server control system for querying through a network firewall
US6092196A (en) * 1997-11-25 2000-07-18 Nortel Networks Limited HTTP distributed remote user authentication system
US6098056A (en) 1997-11-24 2000-08-01 International Business Machines Corporation System and method for controlling access rights to and security of digital content in a distributed information system, e.g., Internet
US6119167A (en) 1997-07-11 2000-09-12 Phone.Com, Inc. Pushing and pulling data in networks
US6131120A (en) 1997-10-24 2000-10-10 Directory Logic, Inc. Enterprise network management directory containing network addresses of users and devices providing access lists to routers and servers
US6134658A (en) 1997-06-09 2000-10-17 Microsoft Corporation Multi-server location-independent authentication certificate management system
US6133916A (en) 1998-04-08 2000-10-17 International Business Machines Corporation Graphical user interface providing access to files downloaded over a network
US6138104A (en) 1996-04-26 2000-10-24 Workgroup Technology Corporation Product development system and method using integrated process and data management
US6141778A (en) 1998-06-29 2000-10-31 Mci Communications Corporation Method and apparatus for automating security functions in a computer system
US6151531A (en) 1996-12-12 2000-11-21 Charles Frankel Et Al System and method for managing the alteration of garments
US6154741A (en) 1999-01-29 2000-11-28 Feldman; Daniel J. Entitlement management and access control system
US6157942A (en) 1997-08-13 2000-12-05 Microsoft Corporation Imprecise caching of directory download responses for dynamic directory services
US6157925A (en) 1997-10-01 2000-12-05 Novell, Inc. System and method for caching identification and location information in a computer network
US6158010A (en) 1998-10-28 2000-12-05 Crosslogix, Inc. System and method for maintaining security in a distributed computer network
US6161139A (en) * 1998-07-10 2000-12-12 Encommerce, Inc. Administrative roles that govern access to administrative functions
US6163844A (en) 1997-03-06 2000-12-19 Software And Systems Engineering Limited Method for granting accesses to information in a distributed computer system
US6170013B1 (en) 1998-03-27 2001-01-02 Nortel Networks Limited Method and apparatus for controlling access to network information sources
US6170017B1 (en) * 1997-05-08 2001-01-02 International Business Machines Corporation Method and system coordinating actions among a group of servers
US6178418B1 (en) 1998-07-28 2001-01-23 Noetix Corporation Distributed data warehouse query and resource management system
US6182086B1 (en) 1998-03-02 2001-01-30 Microsoft Corporation Client-server computer system with application recovery of server applications and client applications
US6185650B1 (en) 1998-08-28 2001-02-06 International Business Machines Corporation High performance locking facility
US6185608B1 (en) 1998-06-12 2001-02-06 International Business Machines Corporation Caching dynamic web pages
US6192476B1 (en) 1997-12-11 2001-02-20 Sun Microsystems, Inc. Controlling access to a resource
US6205480B1 (en) * 1998-08-19 2001-03-20 Computer Associates Think, Inc. System and method for web server user authentication
US6208986B1 (en) 1997-12-15 2001-03-27 International Business Machines Corporation Web interface and method for accessing and displaying directory information
US6212558B1 (en) 1997-04-25 2001-04-03 Anand K. Antur Method and apparatus for configuring and managing firewalls and security devices
US6212640B1 (en) 1999-03-25 2001-04-03 Sun Microsystems, Inc. Resources sharing on the internet via the HTTP
US6216199B1 (en) 1999-08-04 2001-04-10 Lsi Logic Corporation Hardware mechanism for managing cache structures in a data storage system
US6226752B1 (en) * 1999-05-11 2001-05-01 Sun Microsystems, Inc. Method and apparatus for authenticating users
US6230185B1 (en) 1997-07-15 2001-05-08 Eroom Technology, Inc. Method and apparatus for facilitating communication between collaborators in a networked environment
US6233618B1 (en) 1998-03-31 2001-05-15 Content Advisor, Inc. Access control of networked data
US6233576B1 (en) 1995-06-09 2001-05-15 International Business Machines Corporation Enhanced security for computer system resources with a resource access authorization control facility that creates files and provides increased granularity of resource permission
US6240360B1 (en) 1995-08-16 2001-05-29 Sean Phelan Computer system for indentifying local resources
US6240414B1 (en) 1997-09-28 2001-05-29 Eisolutions, Inc. Method of resolving data conflicts in a shared data environment
US6243816B1 (en) 1998-04-30 2001-06-05 International Business Machines Corporation Single sign-on (SSO) mechanism personal key manager
US6253248B1 (en) 1997-06-13 2001-06-26 Canon Kabushiki Kaisha Information processing apparatus and method
US6256739B1 (en) 1997-10-30 2001-07-03 Juno Online Services, Inc. Method and apparatus to determine user identity and limit access to a communications network
US6266420B1 (en) 1998-10-08 2001-07-24 Entrust Technologies Limited Method and apparatus for secure group communications
US6275916B1 (en) 1997-12-18 2001-08-14 Alcatel Usa Sourcing, L.P. Object oriented program memory management system and method using fixed sized memory pools
US6275944B1 (en) 1998-04-30 2001-08-14 International Business Machines Corporation Method and system for single sign on using configuration directives with respect to target types
US6279001B1 (en) 1998-05-29 2001-08-21 Webspective Software, Inc. Web service
US6282546B1 (en) 1998-06-30 2001-08-28 Cisco Technology, Inc. System and method for real-time insertion of data into a multi-dimensional database for network intrusion detection and vulnerability assessment
US6286098B1 (en) 1998-08-28 2001-09-04 Sap Aktiengesellschaft System and method for encrypting audit information in network applications
US6289462B1 (en) 1998-09-28 2001-09-11 Argus Systems Group, Inc. Trusted compartmentalized computer operating system
US6301668B1 (en) 1998-12-29 2001-10-09 Cisco Technology, Inc. Method and system for adaptive network security using network vulnerability assessment
US6311269B2 (en) * 1998-06-15 2001-10-30 Lockheed Martin Corporation Trusted services broker for web page fine-grained security labeling
US6314492B1 (en) 1998-05-27 2001-11-06 International Business Machines Corporation System and method for server control of client cache
US6321339B1 (en) * 1998-05-21 2001-11-20 Equifax Inc. System and method for authentication of network users and issuing a digital certificate
US6321338B1 (en) 1998-11-09 2001-11-20 Sri International Network surveillance
US6324656B1 (en) 1998-06-30 2001-11-27 Cisco Technology, Inc. System and method for rules-driven multi-phase network vulnerability assessment
US20010054153A1 (en) 2000-04-26 2001-12-20 Wheeler David B. System and method for determining user identity fraud using similarity searching
US6338097B1 (en) 1998-06-19 2002-01-08 Sap Aktiengesellschaft Cross application time sheet for communicating with one or more enterprise management applications during time data entry
US6339423B1 (en) * 1999-08-23 2002-01-15 Entrust, Inc. Multi-domain access control
US6345266B1 (en) 1998-12-23 2002-02-05 Novell, Inc. Predicate indexing for locating objects in a distributed directory
US6347312B1 (en) 1998-11-05 2002-02-12 International Business Machines Corporation Lightweight directory access protocol (LDAP) directory server cache mechanism and method
US6347374B1 (en) 1998-06-05 2002-02-12 Intrusion.Com, Inc. Event detection
US20020026563A1 (en) 1999-01-25 2002-02-28 John T. Chamberlain Cache override control in an apparatus for caching dynamic content
US6357010B1 (en) 1998-02-17 2002-03-12 Secure Computing Corporation System and method for controlling access to documents stored on an internal network
US20020032684A1 (en) 2000-07-18 2002-03-14 Chieko Kobayashi Directory information management apparatus, directory information management method, and computer readable recording medium having directory information management program stored therein
US6366913B1 (en) 1998-10-21 2002-04-02 Netscape Communications Corporation Centralized directory services supporting dynamic group membership
US6374359B1 (en) 1998-11-19 2002-04-16 International Business Machines Corporation Dynamic use and validation of HTTP cookies for authentication
US6381579B1 (en) 1998-12-23 2002-04-30 International Business Machines Corporation System and method to provide secure navigation to resources on the internet
US6385653B1 (en) 1998-11-02 2002-05-07 Cisco Technology, Inc. Responding to network access requests using a transparent media access and uniform delivery of service
US6393569B1 (en) 1996-12-18 2002-05-21 Alexander S. Orenshteyn Secured system for accessing application services from a remote station
US6415321B1 (en) 1998-12-29 2002-07-02 Cisco Technology, Inc. Domain mapping method and system
US20020091745A1 (en) 2000-07-10 2002-07-11 Srinivasagopalan Ramamurthy Localized access
US20020091798A1 (en) 2000-07-10 2002-07-11 Joshi Vrinda S. Providing data to applications from an access system
US6421781B1 (en) 1998-04-30 2002-07-16 Openwave Systems Inc. Method and apparatus for maintaining security in a push server
US6421682B1 (en) 1999-07-26 2002-07-16 Microsoft Corporation Catalog management system architecture having data table objects and logic table objects
US20020099671A1 (en) 2000-07-10 2002-07-25 Mastin Crosbie Tanya M. Query string processing
US6430688B1 (en) 1998-12-22 2002-08-06 International Business Machines Corporation Architecture for web-based on-line-off-line digital certificate authority
US6434531B1 (en) 1995-02-28 2002-08-13 Clinicomp International, Inc. Method and system for facilitating patient care plans
US20020112155A1 (en) 2000-07-10 2002-08-15 Martherus Robin E. User Authentication
US20020112083A1 (en) 2000-07-10 2002-08-15 Joshi Vrinda S. Cache flushing
US20020112185A1 (en) 2000-07-10 2002-08-15 Hodges Jeffrey D. Intrusion threat detection
US20020116642A1 (en) 2000-07-10 2002-08-22 Joshi Vrinda S. Logging access system events
US6442567B1 (en) 1999-05-14 2002-08-27 Appintec Corporation Method and apparatus for improved contact and activity management and planning
US20020120858A1 (en) 1996-09-09 2002-08-29 Jack Edward Porter Method and apparatus for document management utilizing a messaging system
US20020120599A1 (en) 2000-07-10 2002-08-29 Knouse Charles W. Post data processing
US20020129116A1 (en) 1998-03-16 2002-09-12 Douglas E. Humphrey Network broadcasting system and method of distrituting information from a master cache to local caches
US6453342B1 (en) 1998-12-03 2002-09-17 International Business Machines Corporation Method and apparatus for selective caching and cleaning of history pages for web browsers
US6457047B1 (en) 2000-05-08 2002-09-24 Verity, Inc. Application caching system and method
US6460141B1 (en) * 1998-10-28 2002-10-01 Rsa Security Inc. Security and access management system for web-enabled and non-web-enabled applications and content on a computer network
US6463509B1 (en) 1999-01-26 2002-10-08 Motive Power, Inc. Preloading data in a cache memory according to user-specified preload criteria
US6463418B1 (en) 1997-08-15 2002-10-08 Sun Microsystems, Inc. Secure and stateful electronic business transaction system
US6466932B1 (en) 1998-08-14 2002-10-15 Microsoft Corporation System and method for implementing group policy
US6470386B1 (en) 1997-09-26 2002-10-22 Worldcom, Inc. Integrated proxy interface for web based telecommunications management tools
US20020165960A1 (en) 2000-07-10 2002-11-07 Chan Christine Wai Han Access tester
US6487663B1 (en) 1998-10-19 2002-11-26 Realnetworks, Inc. System and method for regulating the transmission of media data
US6490574B1 (en) 1997-12-17 2002-12-03 International Business Machines Corporation Method and system for managing rules and events in a multi-user intelligent agent environment
US6499107B1 (en) 1998-12-29 2002-12-24 Cisco Technology, Inc. Method and system for adaptive network security using intelligent packet analysis
US6507847B1 (en) 1999-12-17 2003-01-14 Openwave Systems Inc. History database structure for Usenet
US6513056B1 (en) 1994-09-16 2003-01-28 International Business Machines Corporation System and method for efficiently synchronizing cache and persistant data in an object oriented transaction processing system
US6516416B2 (en) 1997-06-11 2003-02-04 Prism Resources Subscription access system for use with an untrusted network
US6519643B1 (en) 1999-04-29 2003-02-11 Attachmate Corporation Method and system for a session allocation manager (“SAM”)
US6519648B1 (en) 2000-01-24 2003-02-11 Friskit, Inc. Streaming media search and continuous playback of multiple media resources located on a network
US6526447B1 (en) 1999-12-14 2003-02-25 International Business Machines Corporation Apparatus for restarting interrupted data transfer and method therefor
US6526438B1 (en) 1999-07-12 2003-02-25 Divine, Inc. Method for distributing information to subscribers over a network
US6536037B1 (en) 1999-05-27 2003-03-18 Accenture Llp Identification of redundancies and omissions among components of a web based architecture
US6539396B1 (en) 1999-08-31 2003-03-25 Accenture Llp Multi-object identifier system and method for information service pattern environment
US6539382B1 (en) 1999-04-29 2003-03-25 International Business Machines Corporation Intelligent pre-caching algorithm for a directory server based on user data access history
US6539379B1 (en) 1999-08-23 2003-03-25 Oblix, Inc. Method and apparatus for implementing a corporate directory and service center
US20030061272A1 (en) 1997-06-02 2003-03-27 Balachander Krishnamurthy Method and apparatus for cache validation for proxy caches
US6542993B1 (en) 1999-03-12 2003-04-01 Lucent Technologies Inc. Security management system and method
US20030074580A1 (en) 2001-03-21 2003-04-17 Knouse Charles W. Access system interface
US6557039B1 (en) 1998-11-13 2003-04-29 The Chase Manhattan Bank System and method for managing information retrievals from distributed archives
US6578147B1 (en) 1999-01-15 2003-06-10 Cisco Technology, Inc. Parallel intrusion detection sensors with load balancing for high speed networks
US6584569B2 (en) 2000-03-03 2003-06-24 Sanctum Ltd. System for determining web application vulnerabilities
US6584548B1 (en) 1999-07-22 2003-06-24 International Business Machines Corporation Method and apparatus for invalidating data in a cache
US6591347B2 (en) 1998-10-09 2003-07-08 National Semiconductor Corporation Dynamic replacement technique in a shared cache
US6598058B2 (en) 1999-09-22 2003-07-22 International Business Machines Corporation Method and apparatus for cross-node sharing of cached dynamic SQL in a multiple relational database management system environment
US6601169B2 (en) 1999-12-30 2003-07-29 Clyde Riley Wallace, Jr. Key-based secure network user states
US20030145074A1 (en) 2001-12-13 2003-07-31 David Penick System and method for resource management
US20030149737A1 (en) 1997-07-21 2003-08-07 Lambert Mark L. Method and apparatus for storing and delivering documents of the internet
US6609205B1 (en) 1999-03-18 2003-08-19 Cisco Technology, Inc. Network intrusion detection signature analysis using decision graphs
US20030158897A1 (en) 2000-05-09 2003-08-21 Viryanet Ltd. Networked platform for creating and supporting communities
US6615218B2 (en) 1998-07-17 2003-09-02 Sun Microsystems, Inc. Database for executing policies for controlling devices on a network
US6618806B1 (en) 1998-04-01 2003-09-09 Saflink Corporation System and method for authenticating users in a computer network
US6629132B1 (en) 1998-12-23 2003-09-30 Novell, Inc. Predicate indexing of data stored in a computer with application to indexing cached data
US6636891B1 (en) 1998-11-06 2003-10-21 Seiko Epson Corporation Methods and apparatus for controlling an input or output device over the internet
US6647393B1 (en) 1996-11-22 2003-11-11 Mangosoft Corporation Dynamic directory service
US6668322B1 (en) 1999-08-05 2003-12-23 Sun Microsystems, Inc. Access management system and method employing secure credentials
US6675261B2 (en) 2000-12-22 2004-01-06 Oblix, Inc. Request based caching of data store data
US6678828B1 (en) 2002-07-22 2004-01-13 Vormetric, Inc. Secure network file access control system
US6680942B2 (en) 1999-07-02 2004-01-20 Cisco Technology, Inc. Directory services caching for network peer to peer service locator
US6691232B1 (en) 1999-08-05 2004-02-10 Sun Microsystems, Inc. Security architecture with environment sensitive credential sufficiency evaluation
US6697849B1 (en) 1999-08-13 2004-02-24 Sun Microsystems, Inc. System and method for caching JavaServer Pages™ responses
US6708170B1 (en) 1999-12-14 2004-03-16 International Business Machines Corporation Method and system for usage of non-local data within a lightweight directory access protocol directory environment
US6711632B1 (en) 1998-08-11 2004-03-23 Ncr Corporation Method and apparatus for write-back caching with minimal interrupts
US6718328B1 (en) 2000-02-28 2004-04-06 Akamai Technologies, Inc. System and method for providing controlled and secured access to network resources
US6742126B1 (en) 1999-10-07 2004-05-25 Cisco Technology, Inc. Method and apparatus for identifying a data communications session
US6741992B1 (en) 1999-07-29 2004-05-25 Xtenit Flexible rule-based communication system and method for controlling the flow of and access to information between computer users
US6745221B1 (en) 1999-03-01 2004-06-01 Mitel, Inc. Dynamic resource reallocation
US6748540B1 (en) 1999-06-17 2004-06-08 International Business Machines Corporation Method and apparatus for detection and notification of unauthorized access attempts in a distributed data processing system
US6748447B1 (en) 2000-04-07 2004-06-08 Network Appliance, Inc. Method and apparatus for scalable distribution of information in a distributed network
US6754696B1 (en) 1999-03-25 2004-06-22 Micosoft Corporation Extended file system
US6757708B1 (en) 2000-03-03 2004-06-29 International Business Machines Corporation Caching dynamic content
US6763370B1 (en) 1998-11-16 2004-07-13 Softricity, Inc. Method and apparatus for content protection in a secure content delivery system
US6765864B1 (en) 1999-06-29 2004-07-20 Cisco Technology, Inc. Technique for providing dynamic modification of application specific policies in a feedback-based, adaptive data network
US6772214B1 (en) 2000-04-27 2004-08-03 Novell, Inc. System and method for filtering of web-based content stored on a proxy cache server
US6775704B1 (en) 2000-12-28 2004-08-10 Networks Associates Technology, Inc. System and method for preventing a spoofed remote procedure call denial of service attack in a networked computing environment
US6779120B1 (en) 2000-01-07 2004-08-17 Securify, Inc. Declarative language for specifying a security policy
US6782379B2 (en) * 2000-12-22 2004-08-24 Oblix, Inc. Preparing output XML based on selected programs and XML templates
US6804221B1 (en) 2000-06-26 2004-10-12 Alcatel Micromobility using multicast
US6859834B1 (en) 1999-08-13 2005-02-22 Sun Microsystems, Inc. System and method for enabling application server request failover
US6868406B1 (en) 1999-10-18 2005-03-15 Stamps.Com Auditing method and system for an on-line value-bearing item printing system
US6879995B1 (en) 1999-08-13 2005-04-12 Sun Microsystems, Inc. Application server message logging
US6901433B2 (en) 1995-06-07 2005-05-31 Microsoft Corporation System for providing users with a filtered view of interactive network directory obtains from remote properties cache that provided by an on-line service
US6944777B1 (en) 1998-05-15 2005-09-13 E.Piphany, Inc. System and method for controlling access to resources in a distributed environment
US6957237B1 (en) 2000-06-02 2005-10-18 Sun Microsystems, Inc. Database store for a virtual heap
US6968314B1 (en) 1999-12-22 2005-11-22 International Business Machines Corporation Enhanced security features for an automated order fulfillment system
US6983377B1 (en) 1999-03-08 2006-01-03 Software Ag Method for checking user access
US6985946B1 (en) 2000-05-12 2006-01-10 Microsoft Corporation Authentication and authorization pipeline architecture for use in a web server
US6985953B1 (en) 1998-11-30 2006-01-10 George Mason University System and apparatus for storage and transfer of secure data on web
US7003587B1 (en) 1996-07-18 2006-02-21 Computer Associates Think, Inc. Method and apparatus for maintaining data integrity across distributed computer systems
US7017041B2 (en) 2000-12-19 2006-03-21 Tricipher, Inc. Secure communications network with user control of authenticated personal information provided to network entities
US7058947B1 (en) 2000-05-02 2006-06-06 Microsoft Corporation Resource manager architecture utilizing a policy manager
US7111321B1 (en) 1999-01-25 2006-09-19 Dell Products L.P. Portable computer system with hierarchical and token-based security policies
US7124354B1 (en) 2000-03-24 2006-10-17 Hewlett-Packard Development Company, L.P. Enterprise application transactions as shared active documents
US7137008B1 (en) * 2000-07-25 2006-11-14 Laurence Hamid Flexible method of user authentication
US7140039B1 (en) 1999-06-08 2006-11-21 The Trustees Of Columbia University In The City Of New York Identification of an attacker in an electronic system
US7155737B1 (en) 1999-05-11 2006-12-26 Entrust, Inc. Integrating user specified extensions into an information access system
US7231661B1 (en) 2001-06-21 2007-06-12 Oracle International Corporation Authorization services with external authentication
US7231517B1 (en) 2000-03-03 2007-06-12 Novell, Inc. Apparatus and method for automatically authenticating a network client
US7272625B1 (en) 1997-03-10 2007-09-18 Sonicwall, Inc. Generalized policy server
US7290288B2 (en) 1997-06-11 2007-10-30 Prism Technologies, L.L.C. Method and system for controlling access, by an authentication server, to protected computer resources provided via an internet protocol network

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US557742A (en) * 1896-04-07 Car-dumping apparatus
JP4265874B2 (en) * 2000-07-10 2009-05-20 富士通株式会社 Disk apparatus and track following control method

Patent Citations (253)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4484306A (en) 1982-03-22 1984-11-20 Exide Electronics Corporation Method and apparatus for controlling access in a data transmission system
US5023773A (en) 1988-02-10 1991-06-11 International Business Machines Corporation Authorization for selective program access to data in multiple address spaces
US4956769A (en) 1988-05-16 1990-09-11 Sysmith, Inc. Occurence and value based security system for computer databases
US5077666A (en) 1988-11-07 1991-12-31 Emtek Health Care Systems, Inc. Medical information system with automatic updating of task list in response to charting interventions on task list window into an associated form
US4961224A (en) 1989-03-06 1990-10-02 Darby Yung Controlling access to network resources
US5113499A (en) 1989-04-28 1992-05-12 Sprint International Communications Corp. Telecommunication access management system for a packet switching network
US5226143A (en) 1990-03-14 1993-07-06 International Business Machines Corporation Multiprocessor system includes operating system for notifying only those cache managers who are holders of shared locks on a designated page by global lock manager
US5261102A (en) * 1991-03-28 1993-11-09 International Business Machines Corporation System for determining direct and indirect user access privileges to data base objects
US5530861A (en) 1991-08-26 1996-06-25 Hewlett-Packard Company Process enaction and tool integration via a task oriented paradigm
US5581691A (en) 1992-02-04 1996-12-03 Digital Equipment Corporation Work flow management system and method
US5428795A (en) 1992-07-31 1995-06-27 International Business Machines Corporation Method of and apparatus for providing automatic security control of distributions within a data processing system
US6073109A (en) 1993-02-08 2000-06-06 Action Technologies, Inc. Computerized method and system for managing business processes using linked workflows
US5689679A (en) 1993-04-28 1997-11-18 Digital Equipment Corporation Memory system and method for selective multi-level caching using a cache level code
US5455953A (en) 1993-11-03 1995-10-03 Wang Laboratories, Inc. Authorization system for obtaining in single step both identification and access rights of client to server directly from encrypted authorization ticket
US5557742A (en) 1994-03-07 1996-09-17 Haystack Labs, Inc. Method and system for detecting intrusion into and misuse of a data processing system
US5757920A (en) 1994-07-18 1998-05-26 Microsoft Corporation Logon certification
US6513056B1 (en) 1994-09-16 2003-01-28 International Business Machines Corporation System and method for efficiently synchronizing cache and persistant data in an object oriented transaction processing system
US6073174A (en) 1994-09-27 2000-06-06 Bristish Telecommunications Remote access systems
US6029195A (en) 1994-11-29 2000-02-22 Herz; Frederick S. M. System for customized electronic identification of desirable objects
US5764890A (en) 1994-12-13 1998-06-09 Microsoft Corporation Method and system for adding a secure network server to an existing computer network
US6434531B1 (en) 1995-02-28 2002-08-13 Clinicomp International, Inc. Method and system for facilitating patient care plans
US5692125A (en) 1995-05-09 1997-11-25 International Business Machines Corporation System and method for scheduling linked events with fixed and dynamic conditions
US5999911A (en) 1995-06-02 1999-12-07 Mentor Graphics Corporation Method and system for managing workflow
US5678041A (en) 1995-06-06 1997-10-14 At&T System and method for restricting user access rights on the internet based on rating information stored in a relational database
US5812776A (en) 1995-06-07 1998-09-22 Open Market, Inc. Method of providing internet pages by mapping telephone number provided by client to URL and returning the same in a redirect command by server
US6901433B2 (en) 1995-06-07 2005-05-31 Microsoft Corporation System for providing users with a filtered view of interactive network directory obtains from remote properties cache that provided by an on-line service
US5708780A (en) 1995-06-07 1998-01-13 Open Market, Inc. Internet server access control and monitoring systems
US6233576B1 (en) 1995-06-09 2001-05-15 International Business Machines Corporation Enhanced security for computer system resources with a resource access authorization control facility that creates files and provides increased granularity of resource permission
US5872969A (en) 1995-06-23 1999-02-16 International Business Machines Corporation System and method for efficiently synchronizing cache and persistent data in an object oriented transaction processing system
US5991771A (en) 1995-07-20 1999-11-23 Novell, Inc. Transaction synchronization in a disconnectable computer and network
US6240360B1 (en) 1995-08-16 2001-05-29 Sean Phelan Computer system for indentifying local resources
US5826029A (en) 1995-10-31 1998-10-20 International Business Machines Corporation Secured gateway interface
US5793966A (en) 1995-12-01 1998-08-11 Vermeer Technologies, Inc. Computer system and computer-implemented process for creation and maintenance of online services
US5765153A (en) 1996-01-03 1998-06-09 International Business Machines Corporation Information handling system, method, and article of manufacture including object system authorization and registration
US5842212A (en) 1996-03-05 1998-11-24 Information Project Group Inc. Data modeling and computer access record memory
US6138104A (en) 1996-04-26 2000-10-24 Workgroup Technology Corporation Product development system and method using integrated process and data management
US6018619A (en) 1996-05-24 2000-01-25 Microsoft Corporation Method, system and apparatus for client-side usage tracking of information server systems
US5918013A (en) * 1996-06-03 1999-06-29 Webtv Networks, Inc. Method of transcoding documents in a network environment using a proxy server
US6058480A (en) 1996-06-03 2000-05-02 Cranberry Properties, Llc System for remote pass-phase authentication
US5819271A (en) 1996-06-04 1998-10-06 Multex Systems, Inc. Corporate information communication and delivery system and method including entitlable hypertext links
US5802518A (en) 1996-06-04 1998-09-01 Multex Systems, Inc. Information delivery system and method
US5893149A (en) 1996-07-01 1999-04-06 Sun Microsystems, Inc. Flushing of cache memory in a computer system
US7003587B1 (en) 1996-07-18 2006-02-21 Computer Associates Think, Inc. Method and apparatus for maintaining data integrity across distributed computer systems
US5940394A (en) 1996-08-08 1999-08-17 At&T Corp Transferring messages in networks made up of subnetworks with different namespaces
US5889952A (en) 1996-08-14 1999-03-30 Microsoft Corporation Access check system utilizing cached access permissions
US20030191846A1 (en) 1996-08-14 2003-10-09 Heath Hunnicutt Access check system utilizing cached access permissions
US5845267A (en) * 1996-09-06 1998-12-01 At&T Corp System and method for billing for transactions conducted over the internet from within an intranet
US20020120858A1 (en) 1996-09-09 2002-08-29 Jack Edward Porter Method and apparatus for document management utilizing a messaging system
US5892903A (en) 1996-09-12 1999-04-06 Internet Security Systems, Inc. Method and apparatus for detecting and identifying security vulnerabilities in an open network computer communication system
US6032227A (en) 1996-09-30 2000-02-29 International Business Machines Corporation System and method for cache management in mobile user file systems
US6058381A (en) 1996-10-30 2000-05-02 Nelson; Theodor Holm Many-to-many payments system for network content materials
US6020884A (en) 1996-11-08 2000-02-01 America Online, Inc. System integrating an on-line service community with a foreign service
US5991881A (en) 1996-11-08 1999-11-23 Harris Corporation Network surveillance system
US5907621A (en) 1996-11-15 1999-05-25 International Business Machines Corporation System and method for session management
US6647393B1 (en) 1996-11-22 2003-11-11 Mangosoft Corporation Dynamic directory service
US6026474A (en) 1996-11-22 2000-02-15 Mangosoft Corporation Shared client-side web caching using globally addressable memory
US6151531A (en) 1996-12-12 2000-11-21 Charles Frankel Et Al System and method for managing the alteration of garments
US6393569B1 (en) 1996-12-18 2002-05-21 Alexander S. Orenshteyn Secured system for accessing application services from a remote station
US6041357A (en) 1997-02-06 2000-03-21 Electric Classified, Inc. Common session token system and protocol
US5908469A (en) 1997-02-14 1999-06-01 International Business Machines Corporation Generic user authentication for network computers
US5884312A (en) * 1997-02-28 1999-03-16 Electronic Data Systems Corporation System and method for securely accessing information from disparate data sources through a network
US6163844A (en) 1997-03-06 2000-12-19 Software And Systems Engineering Limited Method for granting accesses to information in a distributed computer system
US7272625B1 (en) 1997-03-10 2007-09-18 Sonicwall, Inc. Generalized policy server
US5875461A (en) 1997-04-03 1999-02-23 Sun Microsystems, Inc. Method of synchronizing one of the objects with one of the threads at a time
US6212558B1 (en) 1997-04-25 2001-04-03 Anand K. Antur Method and apparatus for configuring and managing firewalls and security devices
US5944824A (en) * 1997-04-30 1999-08-31 Mci Communications Corporation System and method for single sign-on to a plurality of network elements
US5944780A (en) 1997-05-05 1999-08-31 At&T Corp Network with shared caching
US6170017B1 (en) * 1997-05-08 2001-01-02 International Business Machines Corporation Method and system coordinating actions among a group of servers
US20030061272A1 (en) 1997-06-02 2003-03-27 Balachander Krishnamurthy Method and apparatus for cache validation for proxy caches
US6134658A (en) 1997-06-09 2000-10-17 Microsoft Corporation Multi-server location-independent authentication certificate management system
US7290288B2 (en) 1997-06-11 2007-10-30 Prism Technologies, L.L.C. Method and system for controlling access, by an authentication server, to protected computer resources provided via an internet protocol network
US6516416B2 (en) 1997-06-11 2003-02-04 Prism Resources Subscription access system for use with an untrusted network
US6253248B1 (en) 1997-06-13 2001-06-26 Canon Kabushiki Kaisha Information processing apparatus and method
US6119167A (en) 1997-07-11 2000-09-12 Phone.Com, Inc. Pushing and pulling data in networks
US6230185B1 (en) 1997-07-15 2001-05-08 Eroom Technology, Inc. Method and apparatus for facilitating communication between collaborators in a networked environment
US20030149737A1 (en) 1997-07-21 2003-08-07 Lambert Mark L. Method and apparatus for storing and delivering documents of the internet
US5991810A (en) 1997-08-01 1999-11-23 Novell, Inc. User name authentication for gateway clients accessing a proxy cache server
US6157942A (en) 1997-08-13 2000-12-05 Microsoft Corporation Imprecise caching of directory download responses for dynamic directory services
US6463418B1 (en) 1997-08-15 2002-10-08 Sun Microsystems, Inc. Secure and stateful electronic business transaction system
US5903878A (en) 1997-08-20 1999-05-11 Talati; Kirit K. Method and apparatus for electronic commerce
US6012059A (en) 1997-08-21 2000-01-04 Dataxel Corporation Method and apparatus for replicated transaction consistency
US5991878A (en) * 1997-09-08 1999-11-23 Fmr Corp. Controlling access to information
US6968571B2 (en) 1997-09-26 2005-11-22 Mci, Inc. Secure customer interface for web based data management
US6470386B1 (en) 1997-09-26 2002-10-22 Worldcom, Inc. Integrated proxy interface for web based telecommunications management tools
US6240414B1 (en) 1997-09-28 2001-05-29 Eisolutions, Inc. Method of resolving data conflicts in a shared data environment
US6005571A (en) 1997-09-30 1999-12-21 Softline, Inc. Graphical user interface for managing security in a database system
US6157925A (en) 1997-10-01 2000-12-05 Novell, Inc. System and method for caching identification and location information in a computer network
US6023684A (en) * 1997-10-01 2000-02-08 Security First Technologies, Inc. Three tier financial transaction system with cache memory
US5924096A (en) 1997-10-15 1999-07-13 Novell, Inc. Distributed database using indexed into tags to tracks events according to type, update cache, create virtual update log on demand
US6131120A (en) 1997-10-24 2000-10-10 Directory Logic, Inc. Enterprise network management directory containing network addresses of users and devices providing access lists to routers and servers
US6014666A (en) * 1997-10-28 2000-01-11 Microsoft Corporation Declarative and programmatic access control of component-based server applications using roles
US6256739B1 (en) 1997-10-30 2001-07-03 Juno Online Services, Inc. Method and apparatus to determine user identity and limit access to a communications network
US6061799A (en) 1997-10-31 2000-05-09 International Business Machines Corp. Removable media for password based authentication in a distributed system
US6064656A (en) * 1997-10-31 2000-05-16 Sun Microsystems, Inc. Distributed system and method for controlling access control to network resources
US5978779A (en) 1997-11-14 1999-11-02 Merrill Lynch, Pierce, Fenner & Smith Distributed architecture utility
US6098056A (en) 1997-11-24 2000-08-01 International Business Machines Corporation System and method for controlling access rights to and security of digital content in a distributed information system, e.g., Internet
US6092196A (en) * 1997-11-25 2000-07-18 Nortel Networks Limited HTTP distributed remote user authentication system
US6088679A (en) 1997-12-01 2000-07-11 The United States Of America As Represented By The Secretary Of Commerce Workflow management employing role-based access control
US6192476B1 (en) 1997-12-11 2001-02-20 Sun Microsystems, Inc. Controlling access to a resource
US6208986B1 (en) 1997-12-15 2001-03-27 International Business Machines Corporation Web interface and method for accessing and displaying directory information
US6490574B1 (en) 1997-12-17 2002-12-03 International Business Machines Corporation Method and system for managing rules and events in a multi-user intelligent agent environment
US6275916B1 (en) 1997-12-18 2001-08-14 Alcatel Usa Sourcing, L.P. Object oriented program memory management system and method using fixed sized memory pools
US6052468A (en) * 1998-01-15 2000-04-18 Dew Engineering And Development Limited Method of securing a cryptographic key
US6028605A (en) 1998-02-03 2000-02-22 Documentum, Inc. Multi-dimensional analysis of objects by manipulating discovered semantic properties
US6357010B1 (en) 1998-02-17 2002-03-12 Secure Computing Corporation System and method for controlling access to documents stored on an internal network
US6640307B2 (en) 1998-02-17 2003-10-28 Secure Computing Corporation System and method for controlling access to documents stored on an internal network
US6182086B1 (en) 1998-03-02 2001-01-30 Microsoft Corporation Client-server computer system with application recovery of server applications and client applications
US6076108A (en) * 1998-03-06 2000-06-13 I2 Technologies, Inc. System and method for maintaining a state for a user session using a web system having a global session server
US6085220A (en) * 1998-03-06 2000-07-04 I2 Technologies, Inc. Enterprise interaction hub for managing an enterprise web system
US20020129116A1 (en) 1998-03-16 2002-09-12 Douglas E. Humphrey Network broadcasting system and method of distrituting information from a master cache to local caches
US6170013B1 (en) 1998-03-27 2001-01-02 Nortel Networks Limited Method and apparatus for controlling access to network information sources
US6233618B1 (en) 1998-03-31 2001-05-15 Content Advisor, Inc. Access control of networked data
US6618806B1 (en) 1998-04-01 2003-09-09 Saflink Corporation System and method for authenticating users in a computer network
US6133916A (en) 1998-04-08 2000-10-17 International Business Machines Corporation Graphical user interface providing access to files downloaded over a network
US6275944B1 (en) 1998-04-30 2001-08-14 International Business Machines Corporation Method and system for single sign on using configuration directives with respect to target types
US6243816B1 (en) 1998-04-30 2001-06-05 International Business Machines Corporation Single sign-on (SSO) mechanism personal key manager
US6421781B1 (en) 1998-04-30 2002-07-16 Openwave Systems Inc. Method and apparatus for maintaining security in a push server
US6944777B1 (en) 1998-05-15 2005-09-13 E.Piphany, Inc. System and method for controlling access to resources in a distributed environment
US6321339B1 (en) * 1998-05-21 2001-11-20 Equifax Inc. System and method for authentication of network users and issuing a digital certificate
US6314492B1 (en) 1998-05-27 2001-11-06 International Business Machines Corporation System and method for server control of client cache
US6279001B1 (en) 1998-05-29 2001-08-21 Webspective Software, Inc. Web service
US6347374B1 (en) 1998-06-05 2002-02-12 Intrusion.Com, Inc. Event detection
US6185608B1 (en) 1998-06-12 2001-02-06 International Business Machines Corporation Caching dynamic web pages
US6311269B2 (en) * 1998-06-15 2001-10-30 Lockheed Martin Corporation Trusted services broker for web page fine-grained security labeling
US6338097B1 (en) 1998-06-19 2002-01-08 Sap Aktiengesellschaft Cross application time sheet for communicating with one or more enterprise management applications during time data entry
US6141778A (en) 1998-06-29 2000-10-31 Mci Communications Corporation Method and apparatus for automating security functions in a computer system
US6324656B1 (en) 1998-06-30 2001-11-27 Cisco Technology, Inc. System and method for rules-driven multi-phase network vulnerability assessment
US6282546B1 (en) 1998-06-30 2001-08-28 Cisco Technology, Inc. System and method for real-time insertion of data into a multi-dimensional database for network intrusion detection and vulnerability assessment
US6161139A (en) * 1998-07-10 2000-12-12 Encommerce, Inc. Administrative roles that govern access to administrative functions
US6182142B1 (en) * 1998-07-10 2001-01-30 Encommerce, Inc. Distributed access management of information resources
US6615218B2 (en) 1998-07-17 2003-09-02 Sun Microsystems, Inc. Database for executing policies for controlling devices on a network
US6178418B1 (en) 1998-07-28 2001-01-23 Noetix Corporation Distributed data warehouse query and resource management system
US6088796A (en) 1998-08-06 2000-07-11 Cianfrocca; Francis Secure middleware and server control system for querying through a network firewall
US6711632B1 (en) 1998-08-11 2004-03-23 Ncr Corporation Method and apparatus for write-back caching with minimal interrupts
US6466932B1 (en) 1998-08-14 2002-10-15 Microsoft Corporation System and method for implementing group policy
US6205480B1 (en) * 1998-08-19 2001-03-20 Computer Associates Think, Inc. System and method for web server user authentication
US6286098B1 (en) 1998-08-28 2001-09-04 Sap Aktiengesellschaft System and method for encrypting audit information in network applications
US6185650B1 (en) 1998-08-28 2001-02-06 International Business Machines Corporation High performance locking facility
US6289462B1 (en) 1998-09-28 2001-09-11 Argus Systems Group, Inc. Trusted compartmentalized computer operating system
US6266420B1 (en) 1998-10-08 2001-07-24 Entrust Technologies Limited Method and apparatus for secure group communications
US6591347B2 (en) 1998-10-09 2003-07-08 National Semiconductor Corporation Dynamic replacement technique in a shared cache
US6487663B1 (en) 1998-10-19 2002-11-26 Realnetworks, Inc. System and method for regulating the transmission of media data
US6366913B1 (en) 1998-10-21 2002-04-02 Netscape Communications Corporation Centralized directory services supporting dynamic group membership
US6460141B1 (en) * 1998-10-28 2002-10-01 Rsa Security Inc. Security and access management system for web-enabled and non-web-enabled applications and content on a computer network
US6158010A (en) 1998-10-28 2000-12-05 Crosslogix, Inc. System and method for maintaining security in a distributed computer network
US6385653B1 (en) 1998-11-02 2002-05-07 Cisco Technology, Inc. Responding to network access requests using a transparent media access and uniform delivery of service
US6347312B1 (en) 1998-11-05 2002-02-12 International Business Machines Corporation Lightweight directory access protocol (LDAP) directory server cache mechanism and method
US6636891B1 (en) 1998-11-06 2003-10-21 Seiko Epson Corporation Methods and apparatus for controlling an input or output device over the internet
US6321338B1 (en) 1998-11-09 2001-11-20 Sri International Network surveillance
US6557039B1 (en) 1998-11-13 2003-04-29 The Chase Manhattan Bank System and method for managing information retrievals from distributed archives
US6763370B1 (en) 1998-11-16 2004-07-13 Softricity, Inc. Method and apparatus for content protection in a secure content delivery system
US6374359B1 (en) 1998-11-19 2002-04-16 International Business Machines Corporation Dynamic use and validation of HTTP cookies for authentication
US6985953B1 (en) 1998-11-30 2006-01-10 George Mason University System and apparatus for storage and transfer of secure data on web
US6453342B1 (en) 1998-12-03 2002-09-17 International Business Machines Corporation Method and apparatus for selective caching and cleaning of history pages for web browsers
US6430688B1 (en) 1998-12-22 2002-08-06 International Business Machines Corporation Architecture for web-based on-line-off-line digital certificate authority
US6381579B1 (en) 1998-12-23 2002-04-30 International Business Machines Corporation System and method to provide secure navigation to resources on the internet
US6629132B1 (en) 1998-12-23 2003-09-30 Novell, Inc. Predicate indexing of data stored in a computer with application to indexing cached data
US6345266B1 (en) 1998-12-23 2002-02-05 Novell, Inc. Predicate indexing for locating objects in a distributed directory
US6499107B1 (en) 1998-12-29 2002-12-24 Cisco Technology, Inc. Method and system for adaptive network security using intelligent packet analysis
US6301668B1 (en) 1998-12-29 2001-10-09 Cisco Technology, Inc. Method and system for adaptive network security using network vulnerability assessment
US6415321B1 (en) 1998-12-29 2002-07-02 Cisco Technology, Inc. Domain mapping method and system
US6578147B1 (en) 1999-01-15 2003-06-10 Cisco Technology, Inc. Parallel intrusion detection sensors with load balancing for high speed networks
US20020026563A1 (en) 1999-01-25 2002-02-28 John T. Chamberlain Cache override control in an apparatus for caching dynamic content
US7111321B1 (en) 1999-01-25 2006-09-19 Dell Products L.P. Portable computer system with hierarchical and token-based security policies
US6463509B1 (en) 1999-01-26 2002-10-08 Motive Power, Inc. Preloading data in a cache memory according to user-specified preload criteria
US6154741A (en) 1999-01-29 2000-11-28 Feldman; Daniel J. Entitlement management and access control system
US6745221B1 (en) 1999-03-01 2004-06-01 Mitel, Inc. Dynamic resource reallocation
US6983377B1 (en) 1999-03-08 2006-01-03 Software Ag Method for checking user access
US6542993B1 (en) 1999-03-12 2003-04-01 Lucent Technologies Inc. Security management system and method
US6609205B1 (en) 1999-03-18 2003-08-19 Cisco Technology, Inc. Network intrusion detection signature analysis using decision graphs
US6754696B1 (en) 1999-03-25 2004-06-22 Micosoft Corporation Extended file system
US6212640B1 (en) 1999-03-25 2001-04-03 Sun Microsystems, Inc. Resources sharing on the internet via the HTTP
US6519643B1 (en) 1999-04-29 2003-02-11 Attachmate Corporation Method and system for a session allocation manager (“SAM”)
US6539382B1 (en) 1999-04-29 2003-03-25 International Business Machines Corporation Intelligent pre-caching algorithm for a directory server based on user data access history
US7155737B1 (en) 1999-05-11 2006-12-26 Entrust, Inc. Integrating user specified extensions into an information access system
US20010037469A1 (en) 1999-05-11 2001-11-01 Sun Microsystems, Inc. Method and apparatus for authenticating users
US6226752B1 (en) * 1999-05-11 2001-05-01 Sun Microsystems, Inc. Method and apparatus for authenticating users
US6442567B1 (en) 1999-05-14 2002-08-27 Appintec Corporation Method and apparatus for improved contact and activity management and planning
US6536037B1 (en) 1999-05-27 2003-03-18 Accenture Llp Identification of redundancies and omissions among components of a web based architecture
US6081518A (en) 1999-06-02 2000-06-27 Anderson Consulting System, method and article of manufacture for cross-location registration in a communication system architecture
US7140039B1 (en) 1999-06-08 2006-11-21 The Trustees Of Columbia University In The City Of New York Identification of an attacker in an electronic system
US6748540B1 (en) 1999-06-17 2004-06-08 International Business Machines Corporation Method and apparatus for detection and notification of unauthorized access attempts in a distributed data processing system
US6765864B1 (en) 1999-06-29 2004-07-20 Cisco Technology, Inc. Technique for providing dynamic modification of application specific policies in a feedback-based, adaptive data network
US6680942B2 (en) 1999-07-02 2004-01-20 Cisco Technology, Inc. Directory services caching for network peer to peer service locator
US6526438B1 (en) 1999-07-12 2003-02-25 Divine, Inc. Method for distributing information to subscribers over a network
US6584548B1 (en) 1999-07-22 2003-06-24 International Business Machines Corporation Method and apparatus for invalidating data in a cache
US6421682B1 (en) 1999-07-26 2002-07-16 Microsoft Corporation Catalog management system architecture having data table objects and logic table objects
US6741992B1 (en) 1999-07-29 2004-05-25 Xtenit Flexible rule-based communication system and method for controlling the flow of and access to information between computer users
US6216199B1 (en) 1999-08-04 2001-04-10 Lsi Logic Corporation Hardware mechanism for managing cache structures in a data storage system
US6668322B1 (en) 1999-08-05 2003-12-23 Sun Microsystems, Inc. Access management system and method employing secure credentials
US6691232B1 (en) 1999-08-05 2004-02-10 Sun Microsystems, Inc. Security architecture with environment sensitive credential sufficiency evaluation
US6879995B1 (en) 1999-08-13 2005-04-12 Sun Microsystems, Inc. Application server message logging
US6859834B1 (en) 1999-08-13 2005-02-22 Sun Microsystems, Inc. System and method for enabling application server request failover
US6697849B1 (en) 1999-08-13 2004-02-24 Sun Microsystems, Inc. System and method for caching JavaServer Pages™ responses
US6339423B1 (en) * 1999-08-23 2002-01-15 Entrust, Inc. Multi-domain access control
US6539379B1 (en) 1999-08-23 2003-03-25 Oblix, Inc. Method and apparatus for implementing a corporate directory and service center
US6539396B1 (en) 1999-08-31 2003-03-25 Accenture Llp Multi-object identifier system and method for information service pattern environment
US6598058B2 (en) 1999-09-22 2003-07-22 International Business Machines Corporation Method and apparatus for cross-node sharing of cached dynamic SQL in a multiple relational database management system environment
US6742126B1 (en) 1999-10-07 2004-05-25 Cisco Technology, Inc. Method and apparatus for identifying a data communications session
US6868406B1 (en) 1999-10-18 2005-03-15 Stamps.Com Auditing method and system for an on-line value-bearing item printing system
US6526447B1 (en) 1999-12-14 2003-02-25 International Business Machines Corporation Apparatus for restarting interrupted data transfer and method therefor
US6708170B1 (en) 1999-12-14 2004-03-16 International Business Machines Corporation Method and system for usage of non-local data within a lightweight directory access protocol directory environment
US6507847B1 (en) 1999-12-17 2003-01-14 Openwave Systems Inc. History database structure for Usenet
US6968314B1 (en) 1999-12-22 2005-11-22 International Business Machines Corporation Enhanced security features for an automated order fulfillment system
US6601169B2 (en) 1999-12-30 2003-07-29 Clyde Riley Wallace, Jr. Key-based secure network user states
US6920560B2 (en) 1999-12-30 2005-07-19 Clyde Riley Wallace, Jr. Secure network user states
US6779120B1 (en) 2000-01-07 2004-08-17 Securify, Inc. Declarative language for specifying a security policy
US6519648B1 (en) 2000-01-24 2003-02-11 Friskit, Inc. Streaming media search and continuous playback of multiple media resources located on a network
US6718328B1 (en) 2000-02-28 2004-04-06 Akamai Technologies, Inc. System and method for providing controlled and secured access to network resources
US6757708B1 (en) 2000-03-03 2004-06-29 International Business Machines Corporation Caching dynamic content
US7231517B1 (en) 2000-03-03 2007-06-12 Novell, Inc. Apparatus and method for automatically authenticating a network client
US6584569B2 (en) 2000-03-03 2003-06-24 Sanctum Ltd. System for determining web application vulnerabilities
US7124354B1 (en) 2000-03-24 2006-10-17 Hewlett-Packard Development Company, L.P. Enterprise application transactions as shared active documents
US6748447B1 (en) 2000-04-07 2004-06-08 Network Appliance, Inc. Method and apparatus for scalable distribution of information in a distributed network
US20010054153A1 (en) 2000-04-26 2001-12-20 Wheeler David B. System and method for determining user identity fraud using similarity searching
US6772214B1 (en) 2000-04-27 2004-08-03 Novell, Inc. System and method for filtering of web-based content stored on a proxy cache server
US7058947B1 (en) 2000-05-02 2006-06-06 Microsoft Corporation Resource manager architecture utilizing a policy manager
US6457047B1 (en) 2000-05-08 2002-09-24 Verity, Inc. Application caching system and method
US20030158897A1 (en) 2000-05-09 2003-08-21 Viryanet Ltd. Networked platform for creating and supporting communities
US6985946B1 (en) 2000-05-12 2006-01-10 Microsoft Corporation Authentication and authorization pipeline architecture for use in a web server
US6957237B1 (en) 2000-06-02 2005-10-18 Sun Microsystems, Inc. Database store for a virtual heap
US6804221B1 (en) 2000-06-26 2004-10-12 Alcatel Micromobility using multicast
US20020165960A1 (en) 2000-07-10 2002-11-07 Chan Christine Wai Han Access tester
US7464162B2 (en) * 2000-07-10 2008-12-09 Oracle International Corporation Systems and methods for testing whether access to a resource is authorized based on access information
US8661539B2 (en) 2000-07-10 2014-02-25 Oracle International Corporation Intrusion threat detection
US20020112185A1 (en) 2000-07-10 2002-08-15 Hodges Jeffrey D. Intrusion threat detection
US20020112083A1 (en) 2000-07-10 2002-08-15 Joshi Vrinda S. Cache flushing
US8204999B2 (en) 2000-07-10 2012-06-19 Oracle International Corporation Query string processing
US20020112155A1 (en) 2000-07-10 2002-08-15 Martherus Robin E. User Authentication
US7080077B2 (en) 2000-07-10 2006-07-18 Oracle International Corporation Localized access
US7194764B2 (en) 2000-07-10 2007-03-20 Oracle International Corporation User authentication
US7814536B2 (en) 2000-07-10 2010-10-12 Oracle International Corporation User authentication
US20020099671A1 (en) 2000-07-10 2002-07-25 Mastin Crosbie Tanya M. Query string processing
US20020091798A1 (en) 2000-07-10 2002-07-11 Joshi Vrinda S. Providing data to applications from an access system
US7124203B2 (en) 2000-07-10 2006-10-17 Oracle International Corporation Selective cache flushing in identity and access management systems
US20020116642A1 (en) 2000-07-10 2002-08-22 Joshi Vrinda S. Logging access system events
US7134137B2 (en) 2000-07-10 2006-11-07 Oracle International Corporation Providing data to applications from an access system
US20020120599A1 (en) 2000-07-10 2002-08-29 Knouse Charles W. Post data processing
US20020091745A1 (en) 2000-07-10 2002-07-11 Srinivasagopalan Ramamurthy Localized access
US7249369B2 (en) 2000-07-10 2007-07-24 Oracle International Corporation Post data processing
US7398311B2 (en) 2000-07-10 2008-07-08 Oracle International Corporation Selective cache flushing in identity and access management systems
US20020032684A1 (en) 2000-07-18 2002-03-14 Chieko Kobayashi Directory information management apparatus, directory information management method, and computer readable recording medium having directory information management program stored therein
US7137008B1 (en) * 2000-07-25 2006-11-14 Laurence Hamid Flexible method of user authentication
US7017041B2 (en) 2000-12-19 2006-03-21 Tricipher, Inc. Secure communications network with user control of authenticated personal information provided to network entities
US6675261B2 (en) 2000-12-22 2004-01-06 Oblix, Inc. Request based caching of data store data
US6782379B2 (en) * 2000-12-22 2004-08-24 Oblix, Inc. Preparing output XML based on selected programs and XML templates
US6775704B1 (en) 2000-12-28 2004-08-10 Networks Associates Technology, Inc. System and method for preventing a spoofed remote procedure call denial of service attack in a networked computing environment
US7185364B2 (en) 2001-03-21 2007-02-27 Oracle International Corporation Access system interface
US7458096B2 (en) 2001-03-21 2008-11-25 Oracle International Corpration Access system interface
US20030074580A1 (en) 2001-03-21 2003-04-17 Knouse Charles W. Access system interface
US7231661B1 (en) 2001-06-21 2007-06-12 Oracle International Corporation Authorization services with external authentication
US20030145074A1 (en) 2001-12-13 2003-07-31 David Penick System and method for resource management
US6678828B1 (en) 2002-07-22 2004-01-13 Vormetric, Inc. Secure network file access control system

Non-Patent Citations (142)

* Cited by examiner, † Cited by third party
Title
"DNS-Contents," http://www2.rad.com/networks/1998/dns/main.htm, 15 pages, Dec. 7, 1999.
Barrett, Debbie, "Diary of a Break-and-Enter, Cyber Style," Technology in Government, p. 22, Jan. 2000.
Beznosov et al., "A Resource Access Decision Service for CORBA-based Distributed Systems", 15th Annual Computer Security Applications Conference, Dec. 10, 1999, pp. 310-319.
Boulton, Clint, "Oracle Buys Oblix to Secure Web Servies", www.internetnews.com/bus-news/article.php/3493341, dated Mar. 28, 2005, Business News for IT Managers, 3 pages.
Business Wire, "Oblix Becomes First Single Sign-On Provider to Receive Siebel Validation", Business Editors/High-Tech Writers, Jun. 5, 2001, 4 pages.
Cholter, William La et al., "IBAN: Intrusion Blocker Based on Active Networks," Proceedings of the DARPA Active Networks Conference and Exposition (DANCE'02), 11 pages, 2002.
Cooney, Michael, "IBM Rolls Out Host- and Server-Based Mgmt. Apps," Network World, vol. 12, Issue 6, pp. 6-7, Feb. 6, 1995.
Di Sorte, D. et al., "Network Service Provisioning in UWB Open Mobile Access Networks," 2002, Selected Areas in Communications, IEEE Journal, vol. 20, Issue 9, pp. 1745-1753.
Easter, C., "Method to Report Access Control of LAN Server Resources on a Per User Basis," IBM Technical Disclosure Bulletin, p. 172, Apr. 1992.
Good, G., "The LDAP Data Interchange Format (LDIF)-Technical Specification," RFC 2849, 14 pages, Jun. 2000.
Hayes, Jeff, "Policy-Based Authentication and Authorization: Secure Access to the Network Infrastructure," IEEE, pp. 328-333, 2000.
Hewlett-Packard, "HP Introduces Next-Generation Web Authorization Products for E-Business," Press Release, 3 pages, Jan. 18, 1999.
Hewlett-Packard, "HP Introduces Security for Microsoft NT Extranets, Portals and E-Services," Press Release, 3 pages, Jan. 17, 2000.
Hewlett-Packard, "HP Provides Unprecedented Range of Authentication Options," Press Release, 3 pages, Sep. 1, 1999.
Hitchens, Michael et al., "Design Choices for Symmetric Key Based Inter-domain Authentication Protocols in Distributed Systems," Computer Security Applications Conference, 1996., 12th Annual Dec. 9-13, 1996; pp. 105-116.
Hodges, J. et al., "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security," RFC 2830, 12 pages, May 2000.
Howard, L., "An Approach for Using LDAP as a Network Information Service," RFC 2307, 20 pages, Mar. 1998.
Janis, Reference Monitor-Creating Group Membership, IBM Technical Disclosure Bulletin, p. 431, Mar. 1990.
Kim, Hahnsang et al., "Improving Cross-domain Authentication over Wirsless Local Area Networks," Security and Privacy for Emerging Areas in Communications Networks, 2005 (SecureComm 2005; First International Conference on Sep. 5-9, 2005 pp. 127-138.
Klensin et al., "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, Sep. 1997, pp. 1-5.
Leon, Mark, "McAfee's NetTools Promises to Ease Network Desktop Diagnosis," InfoWorld, vol. 17, Issue 30, p. 53, Jul. 24, 1995.
Lin, Whe Dar et al., "A Wireless-based Authentication and Anonymous Channels for Large Scale Area," Computers and Communications, 2001; Proceedings; Sixth IEEE Symposium on Jul. 3-5, 2001; pp. 36-41.
Luciani, J. et al., "Server Cache Synchronization Protocol (SCSP)," RFC 2334, 39 pages, Apr. 1998.
Martherus, Robin, "Extending Identity Management Solutions Into a SOA", obtained online on Feb. 14, 2010 at http://robinmartherus.sys-con.com/ , 2 pages.
Musthaler, Linda, "The Trouble With Help Desk Selection," Network World, vol. 12, Issue 8, pp. 35-39, Feb. 20, 1995.
Mwakalinga, Jeffy et al., "Authorization System in Open Networks based on Attribute Certificates," http://www.dsv.su.se/-matei/courses/3%20-%202i1272/L3b.pdf. 17 pages, printed date Feb. 20, 2007.
Netegrity Inc., "SiteMinder Agent Operations Guide," Version 4.0, pp. 1-174, 1997.
Netegrity Inc., "SiteMinder Deployment Guide," Version 4.0, pp. 1-314, 1997.
Netegrity Inc., "SiteMinder Developer's API Guide," Version 4.0, pp. 1-368, 1997.
Netegrity Inc., "SiteMinder Installation Guide," Version 4.0, pp. 1-280, 1997.
Netegrity Inc., "SiteMinder Policy Server Operations Guide," Version 4.0, pp. 1-556, 1997.
Netscape Communications Corporation, "Introduction to SSL," http://developer.netscape.com/docs/manuals/security/sslin/contents.htm, 12 pages, Oct. 9, 1998.
Newman et al., "ACAP—Application Configuration Access Protocol", RFC 2244, Nov. 1997, pp. 1-72.
Oblix, Inc., "Oblix CSA Solution Administration Guide," Version 3.5, 328 pages, 1999.
Okayama, K. et al., "An Efficient Management Method of Access Policies for Hierarchical Virtual Networks," 2007, Okayama University, Communication Systems Software and Middleware, 2nd International Conference, pp. 1-7.
Park, Joon S. et al., "Secure Cookies on the Web," IEEE Internet Computing, pp. 36-44, Jul./Aug. 2002.
Pfitzmann, Birgit et al., "Analysis of Liberty Single-Sign-On With Enabled Clients," IEEE Internet Computing, pp. 38-44, Nov./Dec. 2003.
Phipatanasuphorn, Veradej et al., "Vulnerability of Sensor Networks to Unauthorized Traversal and Monitoring," IEEE Transactions on Computers, vol. 53, No. 3, pp. 364-369, Mar. 2004.
Piscitello, David M. et al., "Project Guards Laptop and Desktop Data," InfoWorld, pp. 48 and 54, Jun. 21, 1999.
Schmersal, Frank, "Testing to Maintain Service Standards," Communications News, vol. 35, Issue 3, pp. 22-23, Mar. 1998.
Securant Technologies, Inc., "Clear Trust, Unified Access Management," pp. 1-23, 1997.
Skaggs, B. et al., "Network Vulnerability Analysis," IEEE, pp. III-493-III-495, 2002.
Stokes et al., "Access Control Requirements for LDAP", RFC 2820, May 2000, 9 pages.
Sun Microsystems, Inc., "Appendix B-ACL File Syntax," iPlanet Web Server: FastTrack Edition Administrator's Guide, 7 pages, Jul. 13, 2000.
Sun Microsystems, Inc., "Chapter 12-Controlling Access to Your Server," iPlanet Web Server: FastTrack Edition Administrator's Guide, 24 pages, Jul. 13, 2000.
Sun Microsystems, Inc., "Chapter 2-Syntax and Use of obj.conf," iPlanet Web Server, FastTrack Edition NSAPI Programmer's Guide, 16 pages, Jul. 20, 2000.
U.S. Appl. No. 09/792,911, Advisory Action dated Aug. 9, 2005, 3 pages.
U.S. Appl. No. 09/792,911, Final Office Action dated May 9, 2005, 17 pages.
U.S. Appl. No. 09/792,911, Notice of Allowance dated Jun. 7, 2006, 7 pages.
U.S. Appl. No. 09/792,911, Office Action dated Dec. 2, 2005, 13 pages.
U.S. Appl. No. 09/792,911, Office Action dated Sep. 9, 2004, 18 pages.
U.S. Appl. No. 09/792,915, Advisory Action dated Jun. 23, 2006, 4 pages.
U.S. Appl. No. 09/792,915, Appeal Brief dated Nov. 24, 2006, 33 pages.
U.S. Appl. No. 09/792,915, Examiner's Reply Brief dated Jun. 16, 2009, 27 pages.
U.S. Appl. No. 09/792,915, Examiner's Reply Brief dated Mar. 7, 2007.
U.S. Appl. No. 09/792,915, Final Office Action dated Apr. 3, 2006, 22 pages.
U.S. Appl. No. 09/792,915, Final Office Action dated Jun. 30, 2005, 18 pages.
U.S. Appl. No. 09/792,915, Final Office Action dated Mar. 8, 2005, 19 pages.
U.S. Appl. No. 09/792,915, Final Office Action dated Oct. 16, 2013, 22 pages.
U.S. Appl. No. 09/792,915, Final Office Action mailed on Jun. 27, 2014, 23 pages.
U.S. Appl. No. 09/792,915, Non Final Office Action mailed on Feb. 5, 2014, 23 pages.
U.S. Appl. No. 09/792,915, Non-Final Office Action dated May 13, 2013, 21 pages.
U.S. Appl. No. 09/792,915, Office Action dated Jul. 23, 2004, 17 pages.
U.S. Appl. No. 09/792,915, Office Action dated Oct. 4, 2005, 17 pages.
U.S. Appl. No. 09/792,918, Advisory Action dated Sep. 20, 2005, 3 pages.
U.S. Appl. No. 09/792,918, Appeal Brief dated Jan. 20, 2006, 23 pages.
U.S. Appl. No. 09/792,918, Examiner's Reply Brief dated Apr. 5, 2006, 14 pages.
U.S. Appl. No. 09/792,918, Final Office Action dated Jun. 21, 2005, 16 pages.
U.S. Appl. No. 09/792,918, Notice of Allowance dated Aug. 11, 2008, 6 pages.
U.S. Appl. No. 09/792,918, Notice of Allowance dated Mar. 21, 2008, 7 pages.
U.S. Appl. No. 09/792,918, Office Action dated Sep. 8, 2004, 22 pages.
U.S. Appl. No. 09/792,934, Final Office Action dated Jun. 2, 2005, 10 pages.
U.S. Appl. No. 09/792,934, Notice of Allowance dated Feb. 9, 2006, 4 pages.
U.S. Appl. No. 09/792,934, Office Action dated Aug. 19, 2005, 5 pages.
U.S. Appl. No. 09/792,934, Office Action dated Sep. 21, 2004, 19 pages.
U.S. Appl. No. 09/793,196, Advisory Action dated Aug. 16, 2006, 3 pages.
U.S. Appl. No. 09/793,196, Advisory Action dated Jul. 21, 2005, 3 pages.
U.S. Appl. No. 09/793,196, Final Office Action dated Mar. 8, 2005, 15 pages.
U.S. Appl. No. 09/793,196, Final Office Action dated May 31, 2006, 22 pages.
U.S. Appl. No. 09/793,196, Notice of Allowance dated May 2, 2007, 4 pages.
U.S. Appl. No. 09/793,196, Office Action dated Dec. 13, 2005, 12 pages.
U.S. Appl. No. 09/793,196, Office Action dated Jul. 14, 2004, 19 pages.
U.S. Appl. No. 09/793,196, Office Action dated Nov. 21, 2006, 11 pages.
U.S. Appl. No. 09/793,320, 2nd or Subsequent Examiner's Answer to Appeal Brief dated Apr. 21, 2009.
U.S. Appl. No. 09/793,320, Advisory Action dated Jun. 7, 2006, 5 pages.
U.S. Appl. No. 09/793,320, Appeal Brief dated Nov. 21, 2006, 35 pages.
U.S. Appl. No. 09/793,320, Examiner's Reply Brief dated Mar. 7, 2007.
U.S. Appl. No. 09/793,320, Final Office Action dated Mar. 17, 2006, 18 pages.
U.S. Appl. No. 09/793,320, Final Office Action dated May 10, 2005, 19 pages.
U.S. Appl. No. 09/793,320, Non-Final Office Action dated Apr. 30, 2013, 6 pages.
U.S. Appl. No. 09/793,320, Notice of Allowance dated Oct. 11, 2013, 12 pages.
U.S. Appl. No. 09/793,320, Office Action dated Aug. 4, 2004, 18 pages.
U.S. Appl. No. 09/793,320, Office Action dated Sep. 20, 2005, 15 pages.
U.S. Appl. No. 09/793,320, Reply Brief dated May 7, 2007, 8 pages.
U.S. Appl. No. 09/793,354, Advisory Action dated Dec. 15, 2005, 3 pages.
U.S. Appl. No. 09/793,354, Final Office Action dated Apr. 19, 2004, 15 pages.
U.S. Appl. No. 09/793,354, Final Office Action dated Aug. 26, 2005, 9 pages.
U.S. Appl. No. 09/793,354, Notice of Allowance dated Feb. 21, 2006, 6 pages.
U.S. Appl. No. 09/793,354, Office Action dated Jan. 4, 2005, 11 pages.
U.S. Appl. No. 09/793,354, Office Action dated Oct. 1, 2003, 12 pages.
U.S. Appl. No. 09/793,355, Advisory Action dated Jun. 21, 2005, 7 pages.
U.S. Appl. No. 09/793,355, Advisory Action dated May 2, 2006, 3 pages.
U.S. Appl. No. 09/793,355, Appeal Brief dated Jul. 29, 2008, 31 pgs.
U.S. Appl. No. 09/793,355, Examiner's Answer to Appeal Brief dated Oct. 20, 2008, 16 pgs.
U.S. Appl. No. 09/793,355, Final Office Action dated Apr. 6, 2005, 16 pages.
U.S. Appl. No. 09/793,355, Final Office Action dated Feb. 9, 2006, 15 pages.
U.S. Appl. No. 09/793,355, Notice of Allowance mailed on Feb. 22, 2012, 14 pages.
U.S. Appl. No. 09/793,355, Office Action dated Mar. 12, 2004, 13 pages.
U.S. Appl. No. 09/793,355, Office Action dated Oct. 6, 2011, 14 pages.
U.S. Appl. No. 09/793,355, Office Action dated Sep. 7, 2005, 13 pages.
U.S. Appl. No. 09/793,355, Reply Brief dated Dec. 22, 2008, 6 pgs.
U.S. Appl. No. 09/793,658, Advisory Action dated Jan. 31, 2006, 3 pages.
U.S. Appl. No. 09/793,658, Final Office Action dated Nov. 2, 2005, 16 pages.
U.S. Appl. No. 09/793,658, Notice of Allowance, dated Jan. 30, 2007, 2 pages.
U.S. Appl. No. 09/793,658, Notice of Allowance, dated Jun. 20, 2006, 8 pages.
U.S. Appl. No. 09/793,658, Office Action dated Sep. 9, 2004, 14 pages.
U.S. Appl. No. 09/793,658, Requirement for Restriction/Election dated Jun. 1, 2005, 5 pages.
U.S. Appl. No. 09/814,091, Advisory Action dated Jul. 5, 2005, 3 pages.
U.S. Appl. No. 09/814,091, Final Office Action dated Apr. 8, 2005, 24 pages.
U.S. Appl. No. 09/814,091, Notice of Allowance dated Sep. 18, 2006, 7 pages.
U.S. Appl. No. 09/814,091, Office Action dated Jul. 14, 2004, 22 pages.
U.S. Appl. No. 09/814,091, Office Action dated May 3, 2006, 7 pages.
U.S. Appl. No. 09/814,091, Office Action dated Nov. 1, 2005, 18 pages.
U.S. Appl. No. 09/886,515, Advisory Action dated May 8, 2006, 3 pages.
U.S. Appl. No. 09/886,515, Final Office Action dated Feb. 14, 2006, 36 pages.
U.S. Appl. No. 09/886,515, Notice of Allowance dated Feb. 28, 2007, 9 pages.
U.S. Appl. No. 09/886,515, Office Action dated Aug. 29, 2005, 35 pages.
U.S. Appl. No. 09/886,515, Office Action dated Dec. 28, 2004, 35 pages.
U.S. Appl. No. 09/886,515, Office Action dated Sep. 7, 2006, 43 pages.
U.S. Appl. No. 11/538,705, Notice of Allowance dated Jun. 7, 2010, 8 pages.
U.S. Appl. No. 11/538,705, Office Action dated Feb. 25, 2010, 10 pages.
U.S. Appl. No. 11/542,311, Final Office Action dated Sep. 11, 2007, 14 pages.
U.S. Appl. No. 11/542,311, Notice of Allowance dated Feb. 11, 2008, 7 pages.
U.S. Appl. No. 11/542,311, Office Action dated Jun. 8, 2007, 25 pages.
U.S. Appl. No. 11/588,604, Notice of Allowance dated Jul. 23, 2008, 4 pages.
U.S. Appl. No. 11/588,604, Office Action dated Jan. 24, 2008, 23 pages.
Wahl, M. et al., "Authentication Methods for LDAP," RFC 2829, 16 pages, May 2000.
Wahl, M. et al., "Lightweight Directory Access Protocol (v3)," RFC 2251, 48 pages, Dec. 1997.
Walsh, Jeff, "Remedy Releases Three Applications for Help-Desk Suite," InfoWorld, vol. 19, Issue 16, p. 34, Apr. 21, 1997.
Wu, Kun-Lung et al., "Personalization With Dynamic Profiler," IEEE, pp. 12-20, 2001.
Yaacovi, Y. et al., "Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services," RFC 2589, 12 pages, May 1999.
Zorn, G., "Microsoft Vendor-Specific RADIUS Attributes", The Internet Society (1999), Microsoft Corporation Request for Comments 2548, Mar. 1999, 42 pages.

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170163556A1 (en) * 2012-04-12 2017-06-08 Netflix, Inc. Method and system for reclaiming unused resources in a networked application environment
US10798017B2 (en) * 2012-04-12 2020-10-06 Netflix, Inc. Method and system for reclaiming unused resources in a networked application environment
US10693942B2 (en) 2015-06-16 2020-06-23 Alibaba Group Holding Limited Resending a hypertext transfer protocol request
KR20180019162A (en) * 2015-06-16 2018-02-23 알리바바 그룹 홀딩 리미티드 A method and device for retransmitting a hypertext transfer protocol request,
US10530834B2 (en) * 2015-06-16 2020-01-07 Alibaba Group Holding Limited Resending a hypertext transfer protocol request
US10862949B2 (en) * 2015-06-16 2020-12-08 Advanced New Technologies Co., Ltd. Resending a hypertext transfer protocol request
KR102113409B1 (en) 2015-06-16 2020-05-21 알리바바 그룹 홀딩 리미티드 Method and device for retransmitting a hypertext transfer protocol request, and a client terminal
US10218704B2 (en) 2016-10-06 2019-02-26 Cisco Technology, Inc. Resource access control using named capabilities
US10657038B1 (en) * 2017-01-20 2020-05-19 Intuit, Inc. Mock server for testing
US10089219B1 (en) * 2017-01-20 2018-10-02 Intuit Inc. Mock server for testing
US10565098B2 (en) * 2017-01-20 2020-02-18 Intuit Inc. Mock server for testing
US11113187B2 (en) 2017-01-20 2021-09-07 Intuit, Inc. Mock server for testing
US11169913B2 (en) 2017-01-20 2021-11-09 Intuit, Inc. Mock server for testing
US11050722B2 (en) * 2017-09-12 2021-06-29 Fujitsu Limited Information processing device, program, and information processing method
US10984019B2 (en) * 2017-12-25 2021-04-20 Kyocera Document Solutions Inc. Data management system and storage medium
US20220360565A1 (en) * 2019-04-02 2022-11-10 Bright Data Ltd. System and method for managing non-direct url fetching service
US11748374B2 (en) * 2021-11-30 2023-09-05 Snowflake Inc. Replication group objects configuration in a network-based database system

Also Published As

Publication number Publication date
US20030074580A1 (en) 2003-04-17
US7458096B2 (en) 2008-11-25
US20090106433A1 (en) 2009-04-23
US7185364B2 (en) 2007-02-27
US20070044144A1 (en) 2007-02-22
WO2002077819A1 (en) 2002-10-03

Similar Documents

Publication Publication Date Title
US8935418B2 (en) Access system interface
US7134137B2 (en) Providing data to applications from an access system
US8661539B2 (en) Intrusion threat detection
US8204999B2 (en) Query string processing
US7814536B2 (en) User authentication
US7398311B2 (en) Selective cache flushing in identity and access management systems
US7249369B2 (en) Post data processing
US7464162B2 (en) Systems and methods for testing whether access to a resource is authorized based on access information
US9038170B2 (en) Logging access system events
US7080077B2 (en) Localized access
US7231661B1 (en) Authorization services with external authentication
US7225256B2 (en) Impersonation in an access system
US6182142B1 (en) Distributed access management of information resources
US7350229B1 (en) Authentication and authorization mapping for a computer network
US6453353B1 (en) Role-based navigation of information resources
JP2005538434A (en) Method and system for user-based authentication in a federated environment
CA2415868A1 (en) Systems and methods for authenticating a user to a web server
WO2002013114A1 (en) Systems and methods for integrating independent secure application service providers

Legal Events

Date Code Title Description
STCF Information on status: patent grant

Free format text: PATENTED CASE

CC Certificate of correction
MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551)

Year of fee payment: 4

FEPP Fee payment procedure

Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

LAPS Lapse for failure to pay maintenance fees

Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

STCH Information on status: patent discontinuation

Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362

FP Lapsed due to failure to pay maintenance fee

Effective date: 20230113