 |
Description  |
|
|
MICROFICHE APPENDIX
A microfiche appendix, consisting of 1 microfiche and 28 frames, has been submitted in accordance with 37 C.F.R. 96. The microfiche appendix is incorporated herein by reference.
FIELD OF THE INVENTION
This invention generally relates to methods of controlling access to protected information resources in a network environment. The invention relates more specifically to methods, apparatus, and products for managing and administering, from
several distributed locations, a system for facilitating secure and selective access to network resources based on a role of a user of the resources.
BACKGROUND OF THE INVENTION
Computer networks have become ubiquitous in business, industry, and education. In one approach, a network is configured with one or more user accounts, each of which is uniquely associated with a human network user or host computer. The network
also has one or more resources, such as application programs that provide various computing functions, which are available to all users. In this approach, a user logs into his or her user account, selects a desired application. A disadvantage of this
approach is that every user has the same rights to access any of the network resources.
Development of the globally accessible, packet-switched network known as the Internet has enabled network resources, accounts and applications to become available worldwide. Development of hypertext protocols that implement the World Wide Web
("The Web") is enabling networks to serve as a platform for global electronic commerce. In particular, the Web is enabling the easy exchange of information between businesses and their customers, suppliers and partners.
Businesses are rushing to publish information on the Web and just as quickly stumbling into several roadblocks. For example, some information is valuable and sensitive, and needs to be made available only to selected users. Thus, there is a
need to provide selective access to network resources and information over the Web.
This need exists in the context of internal Web networks that are available to employees of an organization, called Intranets, as well as Web networks and resources that are available to external customers, suppliers and partners of the
organization, called extranets. Extranet users may require information from a large number of diverse sources, for example, product catalogs, customer databases, or inventory systems. There may be millions of potential users, the number of which grows
dramatically as an organization prospers. Thus, there is a need for a large-scale system that can provide selective access to a large number of information sources for a large number of users.
Because some of the information sources are sensitive, there is a need to provide secure access to the information.
Current networks and Web systems, including Intranets and extranets, are expensive and complex to implement. These technologies also change rapidly. There is a need for any information access method or system to integrate with and use existing
equipment, software and systems. There is also a need for method and system that is flexible or adaptable to changing technologies and standards.
One approach to some of the foregoing problems and needs has been to provide each network resource or application program with a separate access control list. The access control list identifies users or hosts that are authorized to access a
particular application. As new users or hosts are added to the network, the access control lists grow, making security management more complicated and difficult. Use of a large number of separate lists also makes the user experience tedious and
unsatisfactory.
Another disadvantage of the foregoing approaches is duplication of management processes. To add new users to the system, a network administrator must repeat similar access processes for each application or resource to be made available to the
new users. The redundancy of these processes, combined with rapid growth in the number of users, can make the cost of deploying, managing and supporting a system unacceptably high.
Thus, there is a need for a mechanism to govern access to one or more information resources in which selective access is given to particular users.
There is also a need for such a mechanism that is equally adaptable to an internal network environment and to an external network environment.
There is a further need for such a mechanism that is easy to configure and re-configure as new users and resources become part of the system.
There is a need to selectively delegate to multiple administrators the administration of access control to resources connected to various networks, allowing some of the administrators to administer one set of resources while disallowing others.
There is need to selectively grant administrative privileges to the multiple administrators. There is yet another need to selectively delegate administration and grant administrative privileges to the multiple administrators using a mechanism that is
simple to use.
There is need to enable an administrator logged into one network to administer access to resources connected to other networks, including other extranets and intranets. There is yet another need to securely and conveniently enable the
administration of such resources connected to other networks.
SUMMARY OF THE INVENTION
The foregoing needs, and other needs and objectives that will become apparent from the description herein, are achieved by the present invention, which comprises, in one aspect, a method of delegating to a user the administration of an access
control computer system. The method comprises storing information that defines administration roles, that associates a user with one or more of the administrative roles, and that associates each administration role with one or more administrative
privileges. An administrative privilege authorizes at least one administrative function. When the user requests the execution of an administrative function, the requests is honored only when one of the user's administrative roles includes an
administrative privilege that authorizes the requested administrative function.
According to one feature, information is stored that associates each of a plurality of users with one or more administrative roles. At least two users administer the access control computer system from different locations, or from computers
connected to two different local area networks.
According to another feature, information is stored that associates a user with an administrative role, and that associates the administrative role with one or more other roles.
When the user requests to associate a particular user with a particular role, the request is honored only when the administrative role is associated with the particular role. In addition, the particular role may include a privilege authorizing
access to resources associated with the particular role. According to yet another feature, information associating a user with one or more administrative roles is stored in a cookie. The cookie may be encrypted. The information stored in the cookie is
used to determine whether an administrative function requested by a user may be executed on behalf of the user.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
FIG. 1 is a block diagram of an information access system;
FIG. 2 is a block diagram of a protected server and its connections to the system of FIG. 1;
FIG. 3A is a state diagram showing actions carried out by a protected server;
FIG. 3B is a state diagram showing a process of opening a protected resource;
FIG. 3C is a state diagram showing a process of authorizing access to a restricted resource;
FIG. 4 is a block diagram of an access server used in the system of FIG. 1;
FIG. 5A is a state diagram showing steps carried out in a user verification process;
FIG. 5B is a state diagram showing steps carried out in a login process;
FIG. 5C is a state diagram showing steps carried out in generating user profile information;
FIG. 5D is a state diagram showing steps carried out in a logout process;
FIG. 5E is a state diagram showing steps carried out in a process of generating a personalized menu;
FIG. 6 is a block diagram of a registry server used in the system of FIG. 1;
FIG. 7 is a block diagram of the system of FIG. 1 showing details of an administrative application;
FIG. 8 is a block diagram of the system of FIG. 1 showing security features;
FIG. 9 is a block diagram of a computer system with which aspects of the invention may be implemented;
FIG. 10A is a block diagram of a resource administration user interface display;
FIG. 10B is a block diagram of a role assignment user interface display;
FIG. 10C is a block diagram of a user interface display generated to facilitate working with groups of users.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
A method and apparatus for controlling access to protected information resources is described. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of
the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to
avoid unnecessarily obscuring the present invention.
OVERVIEW OF PREFERRED EMBODIMENT
FIG. 1 is a block diagram of main elements of an information access system 2 according to a preferred embodiment. Generally, an information access system 2 comprises a plurality of components including an Access Server 106, Registry Server 108,
Administration Application 114, and Integration Tools 115. The foregoing components cooperate to control access to resources stored on one or more Protected Servers 104, 112. Generally, each Protected Server is a Web server. Each component comprises
one or more modules. Each module provides one or more services to users of the system 2 and administrators. There may be any number of Protected Servers 104. Users are individuals who have a relationship with an organization and play various roles,
and are registered in the system 2. Users may be members of an organization, or may be customers, suppliers, or business partners of the organization. Administrators control the system. In one embodiment, all the components are stored on and executed
by one physical server or computer. In alternate embodiments, one ore more components are installed on separate computers; this approach may improve security and performance. For example, Registry Server 108 may be part of a secure Intranet that is
protected using a firewall 118, and Access Server 106 may be located on an extranet for access by users inside and outside the enterprise. Further, there may be more than one Registry Server 108 in a mirrored or replicated configuration. Each Access
Server 106 may be coupled to more than one Registry Server 108, so that a particular Access Server 106 can communicate with a second Registry Server 108 if a first one is busy or unavailable. Each Registry Server 108 may be coupled to or support more
than one Access Server 106. Each Registry Server 108 may execute operations using multiple execution threads, in which access of each thread to Registry Repository 110 is managed by the Access Control Library.
A browser 100 is coupled by a communication link to a network 102. The block shown for browser 100 represents a terminal, workstation computer, or an equivalent that executes a standard Web browser program or an equivalent, such as Netscape
Navigator, Internet Explorer, or NCSA Mosaic. Network 102 is a compatible information communication network, preferably the Internet. In alternate embodiments, the browser 100 is a client process or client workstation of any convenient type, and the
network 102 is a data communication network that can transfer information between the client and a server that is also coupled to the network.
The system 2 enables organizations to register information sources or Resources and register Users of the information in a central repository. A Resource is a source of information, identified by a Uniform Resource Locator (URL) and published by
a Web server either in a static file formatted using Hypertext Markup Language (HTML) or in a dynamically generated page created by a CGI-based program. Examples of resources include a Web page, a complete Web site, a Web-enabled database, and an
applet. The system 2 enables administrators to implement access rules by defining Roles that Users play when working for an organization or doing business with an enterprise. A Role may reflect a relationship of a User to the organization (employee,
customer, distributor, supplier), their department within an organization (sales, marketing, engineering) or any other affiliation or function (member of quality task force, hotline staff member) that defines their information needs and thus their access
rights or privileges. Thus, examples of Roles include Employee, Customer, Distributor, Supplier, Sales, Marketing, Engineering, and Hotline Staff.
Roles are defined by information identifying a name of a role and by a functional group in which the role resides. A functional group is often a department in which similar functions exist. Examples of functional groups are Marketing, Sales,
Engineering, Human Resources, and Operations.
In some embodiments, the term User Type or Person Type refers to employees, directors, officers, contractors, customers, distributors, etc., and Role refers to a job function such as sales representative, financial analyst, etc.
Roles determine what resources a User can access. Further, each role may require a unique set of information that is available in resources. For example, a User who is an Employee in the Marketing department could access Price List and New
Products Resources. Thus, system 2 enables the creation of resource profiles by assigning roles to resources, and user profiles by assigning roles to users to generate access rights. System 2 automatically links a user profile to the resources profiles
that have been assigned the same roles, so that deployment of new resources may occur rapidly.
Roles and resources are owned by Functional Groups within the organization.
The system 2 makes managing access simple because it is based on an additive data model. Assigning a role to a user or deleting a role from a user can add or delete access to all resources with that role. Similarly, adding a role to a resource
or removing a role from a resource can give or take away access to that resource from all users with that role. The system 2 allows administrators to make such changes in a simple manner, resulting in significant administration time savings.
The system 2 also enables Users to log-in to the system once, and thereafter access one or more Resources during an authenticated session. Users may log in either with a digital certificate or by opening a login page URL with a web browser and
entering a name and password. In the past, users have had to log in individually to each Web application that they are authorized to use. In the preferred embodiment, users always access the same login page regardless of the number of resources to
which they need access. Thus, the system provides a mechanism of single secure log-in to Web resources.
If the login attempt is successful, the system 2 presents the User with a Personalized Menu that assists the User in identifying and selecting a Resource. In one embodiment, a Personalized Menu is an HTML page containing a list of authorized
Resources. The Personalized Menu displays only Resources to which the User has access. The User can then select and access a Resource.
Protected Server 104 is coupled to the network 102 logically separate from browser 100.
The Registry Server 108 is coupled to a Registry Repository 110 that stores information about users, resources and roles of the users. Registry Server 108 is coupled by a secure communication link 109 to Access Server 106, which is coupled to
network 102. Registry Server 108 has an Authentication Server Module that manages concurrent access of multiple users or browsers 100 to Registry Repository 110.
A Protected Server 112 is coupled to Registry Server 108. The Protected Server 112 executes or supervises execution of an Administration Application 114, which functions to register and manage users, resources and roles by reading and writing
information to or from Registry Repository 110.
Integration Tools 115 are selectively executed on Protected Server 112 and function to customize the particular configuration of the foregoing components. For example, Integration Tools 115 are use to customize the form or content of screen
displays presented to browser 100 for user login and logout, or to enforce password selection rules. Integration Tools 115 also function to integrate resources with the foregoing components and to integrate data stores or directories with Registry
Repository 110.
Access Server 106 stores a log-in page, Authentication Client Module and Access Menu Module. The Authentication Client Module authenticates a user by verifying the name and password with the Registry Server 108. If the name and password are
correct, the Authentication Client Module reads the user's roles from the Registry Server 108. It then encrypts and sends this information in a "cookie" to the user's browser. A "cookie" is a packet of data sent by web servers to web browsers. Each
cookie is saved by browser 100 until the cookie expires. Cookies received from a web server in a specific domain are returned to web servers in that same domain during open URL requests. A cookie returned by the Authentication Client Module is required
for access to resources protected by the system 2.
Once a user has been authenticated, the Access Menu Module of the Access Server returns a Personalized Menu of the type described above.
When the user selects a resource, the browser sends an open URL request and cookie to a Protected Web Server. A Protected Web Server is a web server with resources protected by the Runtime Module. The Runtime Module decrypts information in the
cookie and uses it to verify that the user is authorized to access the resource. The cookie is also used by the resource to return information that is customized based on the user's name and roles.
The Registry Server contains an Authentication Server Module and a Registry Repository. The Authentication Server Module is structured as a Java server. The Registry Repository is structured as a database. For example, the Registry Repository
may be an SQL Server relational database management system, the Oracle7.RTM. database, etc. The Registry Server also contains an Access Control Library that is structured as a Java library.
The Administration Application contains Administration Application Modules, a Runtime Module, and an Access Control Library. The Administration Application Modules are structured as one or more HTML pages, CGI-based Java programs, or applets.
The Runtime Module is structured as a C/C++ web server plug-in.
The Integration Tools comprise an Access Control Library, and sample program source code. Preferably, the source code is written in the Java.RTM. language.
The Access Server comprises an Authentication Client Module, Access Menu Module, Runtime Module, and an Access Control Library Lite. The Authentication Client Module and Access Menu Module are structured as one or more HTML pages or CGI-based
Java programs. The Access Control Library Lite is one or more software components that interact to control access to the Access Server and its resources. The term "Lite" indicates that the access control components provide more limited functions, and
are therefore more secure, than an Access Control Library.
The Protected Web Server comprises a Runtime Module and an Access Control Library.
The Runtime Module and Access Control Library are reused by several components, for example, the Runtime Module is used to protect resources on Protected Web Servers and system resources in the Access Server and Administration Application.
PROTECTED SERVER
A Protected Server 104 preferably is a World Wide Web server that stores one or more resources 208 that are protected by a Runtime Module 206. In the preferred embodiment, Runtime Module 206 provides one or more functional services. For
example, the Runtime Module functions to provide a Remote Configuration Service, an Authentication Verification Service, and an Authorization Verification Service. Each service is structured as a C/C++ web server plug-in. The Access Control Library 210
of the Protected Web Server functions to provide access to the Registry Server 108.
To associate a Protected Server 104 with system 2, the Administration Application 114 is used to enter information about the Protected Server. The information is stored in the Registry Repository 110. In the preferred embodiment, Administration
Application 114 displays a Servers Administration screen. An administrator enters, for each Protected Server 104, an identifier; a name; a protocol; a port; a description; the location of an authentication server; URLs that identify pages displayed upon
logout, upon login, and where restricted resources are encountered; the Protected Server on which cookies are stored; and the default time in minutes after which a cookie expires. The information is stored in Registry Repository 110.
When the Runtime Module 206 is initialized, it reads a configuration file and caches a list of all the resources 208 on the Protected Server 104 that need to be protected. Configuration changes, for example adding resources 208 to the Protected
Server 104, are made using the Administration Application 114. When the Runtime Module 206 is notified of a change by the Administration Application 114, a Remote Configuration Service of the Runtime Module 206 uses the Access Control Library 210 to
read updated information from the Registry Server 108.
The Protected Server 104 executes an HTTP Server 202 that sends and receives requests or messages conforming to Hypertext Transfer Protocol (HTTP). An example of the HTTP Server 202 is the public domain Apache Web server.
FIG. 3A is a state diagram showing certain actions carried out by Protected Server 104. As shown by state 302, a browser 100 issues an HTTP request, such as "Open the Resource designated by this URL," and provides a URL as a parameter. For
every HTTP request that is received, HTTP Server 202 sets a Web server environment variable "REMOTE.sub.-- ADDR" equal to the Internet Protocol (IP) address of the requesting client or server. As shown by state 304, the HTTP Server 202 then calls the
Runtime Module 206, which runs in the same process space as the HTTP Server, and passes it the browser's request. Runtime Module 206 determines whether the requested URL is a protected resource. If the requested URL is not a protected resource, then as
shown by state 306, the Runtime Module takes no further action and passes control back to HTTP Server 202. As shown by state 308, the in response the HTTP Server 202 provides one or more Web pages containing the requested resource to the browser 100.
FIG. 3B is a state diagram showing processes carried out when the URL is a protected resource. As shown by state 312, Runtime Module 206 calls the Authentication Verification Service to check whether an authenticated user is making the request.
An authenticated user is one who has successfully logged into the system. A user is considered authenticated if the request contains a "user cookie" that can be decrypted, and the request's IP address matches that in the cookie. If the conditions are
not satisfied, then the user cannot be authenticated, and as shown in state 314, Runtime Module 206 returns a redirection to the Login URL. As shown by state 316, HTTP Server 202 returns the redirection to the Login URL to the browser 100.
FIG. 3C is a state diagram showing processes carried out when the URL is a protected resource and the user is authenticated. After the user has been authenticated in state 312, Runtime Module 206 calls the Authorization Verification Service to
check that the user has the right to access the protected resource. All authenticated users have the right to access "public" resources. In state 318, the Runtime Module 206 tests whether the resource is a public resource. If so, then Runtime Module
206 returns a direction to one or more resource pages, and HTTP Server 202 returns the redirection to browser 100, as shown by state 308.
If the resource is not a public resource, then a user is allowed access only if the user is authorized, as shown by state 320. In the preferred embodiment, state 320 involves testing whether the request from browser 100 contains a "roles cookie"
that can be decrypted, and the user has one or more roles, in a combination defined by an Access Rule. Each Access Rule is a Boolean expression of one or more roles. In an alternate embodiment, state 320 involves testing whether the user has at least
one role needed to access the resource. If these conditions are satisfied, then the user is deemed authorized. If these conditions are not satisfied, the user does not have authorization and the Runtime Module returns a redirection to a pre-defined
URL, as shown by state 322. Preferably, the pre-defined URL identifies a Web page that displays the message "Access Restricted," or an equivalent warning that informs the user that it cannot access the requested resource.
If the user is authorized to view or use the protected resource, then as shown in state 324, Runtime Module 206 sets certain environment variables and passes control to the protected resource 208. In the preferred environment, a REMOTE.sub.--
USER environment variable is set to the user's login name. A HTTP.sub.-- LOCALE environment variable is set to the user's language code. A HTTP.sub.-- ROLES environment variable contains the user's roles for this resource. The environment variables
are set so that the protected resource 208 may display different information or behave differently depending upon the values of the environment variables. If the protected resource 208 is a static HTML page, then HTTP Server 202 passes the page directly
to the browser 100. If the protected resource 208 is a CGI-based program, it can dynamically generate and return a custom HTML page based on the user's name and roles.
ACCESS SERVER
FIG. 4 is a block diagram of Access Server 106. An Access Server 106 is a Web server that authenticates users of the access system 2. In the preferred embodiment, Access Server 106 comprises an HTTP Server 402, Server Application Programming
Interface (API) 404, an Authentication Client Module 414, Access Menu Module 412, Runtime Module 406, and Access Control Library 410.
HTTP Server 402 sends and receives messages and requests that conform to the HTTP protocol. Server API 404 enables external programs and processes to access functions of the HTTP Server 402. The Authentication Client Module 414 functions to
provide an Authentication Service, Login Tracking Service, Profile Management Service, Authorization Service, and Logout Service. Each service is structured as one or more HTML pages, or CGI-based Java programs. The Access Menu Module 412 provides a
Personalized Menu Service. It is also structured as one or more HTML pages or CGI-based Java programs. The Access Control Library 410 protects system resources and provides access to the Registry Server.
The Authentication Client Module 414 enables users to begin and end authenticated sessions and change their account profiles. The Authentication Service of Authentication Client Module 414 is invoked when a user opens the login page URL of the
system 2. The Authentication Service is also invoked, as described above in connection with FIG. 2, FIG. 3A, FIG. 3B, and FIG. 3C, when a user tries to access a protected resource 208 without first logging in.
FIG. 5A is a state diagram of steps carried out by Access Server 106 in a preferred embodiment. As shown by state 502, browser 100 opens the URL of a login page. The login page prompts the user for a name and password, as shown in state 504.
Preferably, a single login page is provided, regardless of the number of Web applications to which the user has access. Thus, the system 2 provides single secure log-in to Intranet or Extranet Web applications. The login page provides a single
universal point of access to authorized applications and content.
The user enters the name and password into the login page using browser 100, which provides the name and password to Access Server 106. A user is considered authenticated if the name and password matches information stored in the Registry
Server, as indicated by state 508. The Registry Server 108 returns the result of the verification step to Access Server 106, as shown by state 510. If the name and password cannot be authenticated or the account is marked inactive, then as shown by
state 512, Access Server 106 returns an error message to browser 100.
For each login attempt, the Login Tracking Service logs the user's login activity. It saves the time of last successful and unsuccessful logins and number of consecutive, unsuccessful login attempts. The last successful and unsuccessful login
times are displayed to the user after each successful login. Users can thus detect if someone else has attempted to use their account.
In the preferred embodiment, Administration Application 114 has a Login Monitoring function that displays a Login Monitoring data entry screen. An administrator may enter values that define the maximum consecutive unsuccessful login attempts
allowed for a single user, and the number of minutes to lock an account when the maximum is reached. For multiple users, the Login Monitoring data entry screen accepts values for the maximum number of unsuccessful login attempts to track and the number
of minutes during which unsuccessful login attempts are tracked. The administrator may also enable or disable email notification, and define a list of users who are notified when the system appears to be under attack.
FIG. 5B is a state diagram showing steps carried out in the Login Tracking Service. As shown by state 502, state 504, state 506, state 508, and state 510, the foregoing user login steps are carried out. After Registry Server 108 returns the
result of verifying the user's name and password, Access Server 106 requests Registry Server 108 to record a login attempt, as shown in state 514. In state 516, Registry Server 108 informs Access Server 106 that a login attempt has been recorded in
persistent storage in Registry Server 108. If the user is an authenticated user, then as shown in step 518, the date and time of the user's last successful and unsuccessful login are returned by Access Server 106 to browser 100, which may display the
date and time information.
If the number of consecutive unsuccessful login attempts by a user exceeds a predetermined number, which may be set by the administrator set amount, then Registry Server 108 and Access Server 106 cooperate to disable the user's account for a
pre-determined period of time. The pre-determined period of time may be configured by the administrator.
Registry Server 108 also stores a count of the total number of unsuccessful login attempts made by any registered or unregistered user within a pre-determined period of time, which may be set by the administrator. The value of this number may
indicate that someone is trying to break into user accounts. Registry Server 108 automatically notifies the administrator of such suspicious activity by electronic mail.
FIG. 5C is a state diagram of actions taken by the browser, Registry Server 108, and Access Server 106 when a user is authenticated. After a user is authenticated, the Authentication Client module 414 calls the Authorization service of Access
Server 106. In response, the Authorization service requests profile information about the user from the Registry Server 108, as shown by state 520. In state 522, Registry Server 108 returns the profile information to Access Server 106. The profile
information may comprise the user's name, locale information, IP address, and information defining roles held by the user. The Authorization service creates a "user cookie" 528 and "roles cookie" 530, which are used to convey profile information to
browser 100. The "user cookie" contains a subset of the user profile information. The "roles cookie" contains a list of the user's roles.
As shown by state 524, cookie 528 and cookie 530 are encrypted and returned to the browser 100. Alternatively, state 524 may involve digitally signing cookie 528 and cookie 530 using a digital signature algorithm. Preferably, the cookies are
encrypted rather than digitally signed because encryption is faster and produces a smaller cookie. Each of the cookies 528, 530 is marked with or contains an expiration date value.
Cookie 528 and co | | |
