 |
Description  |
|
|
FIELD OF THE INVENTION
The present invention relates to computer networks and, more particularly,
to a computer network in which execution of applications and use of
content by users of the computer network is controlled. Specifically, one
embodiment of the present invention provides a comprehensive and efficient
unified security and access management system for enterprise security and
access control, so that the availability of intranet, extranet, and
electronic commerce ("e-commerce") applications and content to users of
the computer network can be effectively controlled and the integrity of
the applications and content can be assured by the owner of the
enterprise.
BACKGROUND OF THE INVENTION
Enterprise owners continue to develop intranet and extranet applications
for local and wide area computer networks. These enterprise owners have in
many instances also developed Web-enabled applications and content, as
well as e-commerce solutions, that are available to customers over the
Internet. A major challenge to these enterprise owners is to secure the
integrity of Web-enabled, as well as non-Web-enabled, intranet, extranet,
and e-commerce applications and content. Consequently, there is a need by
both enterprise owners and customers in the field of computer network
security and access control for applications and content.
At the present time, the growth of computer networks has strained the
capabilities of known security architectures. Major concerns have arisen
regarding control of access to critical applications and content and to
process access requests, which requires a security architecture to enable
network authentication and to provide secure access control.
Network security management tools such as perimeter protection, anti-viral
protection, encryption, and intrusion detection have been deployed to
secure communications between and across networks. System security
management tools secure the systems upon which applications execute,
including operating system level security and access control for
traditional client/server database applications or file systems. While Web
applications are accessed across networks and operate on managed systems,
due to their highly distributed nature, Web applications have specific
security requirements which are not protected by network and systems
management products.
Unauthorized users can cause incredible damage in a very short time. They
can break into the supply chain applications of an enterprise and disrupt
the flow of production lines. They can cause the Internet to place
unauthorized orders on an e-commerce system and steal goods or cause havoc
by shipping unauthorized orders to important customers. Electronic banking
applications are also prime targets for unauthorized users. Competitors
can use the Internet to access sensitive marketing plans, customer lists,
or product plans intended for legitimate partners on the extranet.
The internal network presents many additional risks. Employees can use the
intranet to access sensitive employee data on human resource applications.
Trusted users, such as employees, represent more than forty percent of
documented attacks. Organizations erroneously assume that critical
information assets, both inside and outside, are fully protected and
secure. Most enterprises are far from secure, yet remain unaware of
exactly where they are vulnerable.
There are fundamental challenges associated with providing effective Web
security. Discontinuity exists between the Internet/Web technologies of
today and traditional security systems. Security policy is fragmented
across platforms, vendors, and point solutions. Integration of Web
security infrastructure with existing infrastructure is not in place.
Current security approaches are not scalable.
Therefore, there is a need for an improved security and access control
system. The present invention satisfies this need by providing a unified
security and access management system for computer networks.
SUMMARY OF THE INVENTION
The present invention provides a security and access management system for
Web-enabled and non-Web-enabled applications and content on a computer
network. One embodiment of the security and access management system in
accordance with the present invention is based on a management model which
brings together disparate infrastructure components, consolidates multiple
security policies, and embraces both Web and emerging Internet
technologies to properly address the security requirements of the Web.
The security and access management system of the present invention provides
a uniform access management model to address the specific problems facing
the deployment of security for the Web and non-Web environment. Unified
access management consists of strategic approaches to unify all key
aspects of Web and non-Web security policies, including access control,
authorization, authentication, auditing, data privacy, administration, and
business rules. Unified access management also addresses technical
scalability requirements needed to successfully deploy a reliable unified
Web and non-Web security system. The security and access management system
in accordance with a preferred embodiment of the present invention
provides the technology required to support these key factors as they
relate to Web and non-Web security. The security and access management
system of the present invention operates in combination with network and
system security tools such as firewalls, network intrusion detection
tools, and systems management tools to provide comprehensive security for
the Web-enabled enterprise.
BRIEF DESCRIPTION OF THE DRAWINGS
The above and other objectives and features and the concomitant advantages
of the present invention will be better understood and appreciated by
those skilled in the art in view of the description of the preferred
embodiments given below in conjunction with the accompanying drawings. In
the drawings:
FIG. 1 illustrates one embodiment of the architecture of the security and
access management system in accordance with the present invention;
FIGS. 1A-1D illustrate various configurations of the security and access
management system shown in FIG. 1 during normal operation and in
alternative fail-over modes;
FIG. 2 illustrates the data model architecture of the security and access
management system of the present invention;
FIG. 3 illustrates the data model architecture of the security and access
management system for basic user entitlements;
FIG. 4 illustrates the data model architecture of the security and access
management system for one embodiment of business rules to process user
requests for access to application functions;
FIG. 5 illustrates the administrative structure of the security and access
management system in accordance with the present invention;
FIGS. 6-27 illustrate screens or panels that are displayed by the security
and access management system of the present invention to provide security
and access management;
FIG. 28 is a flow chart of an authorization method in accordance with one
embodiment of the present invention;
FIG. 29 is a flow chart of the user validation step shown in FIG. 28;
FIG. 30 illustrates a configuration of the security and access management
system shown in FIG. 1 to enable a single sign on by a user; and
FIGS. 31-33 illustrate panels that are displayed by the security and access
management system of the present invention to monitor attempts at
unauthorized access.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
The following description provides a system administrator with information
on understanding, administering, and maintaining servers incorporated into
the security and access management system of the invention. The following
description also provides a security architect with information for
effectively developing and managing the application-access security model
for an organization.
The following description is divided into two main sections: architecture
and administration. The architecture section provides an overview of the
architecture of the security and access management system in accordance
with the invention and the data model. The administration section details
administration of the server-side components, including starting and
stopping of the server components and descriptions of the server log
files.
The security and access management system of the present invention,
generally indicated by the numeral 10 in FIG. 1, is a highly scalable,
reliable, and configurable security architecture. As shown in FIG. 1, the
architecture for the security and access management system 10 comprises
five main components: at least one authorization component 12; an
entitlements (database) server component 14; an API server 16; an
administrative client (graphical user interface) 18; and at least one
enabled Web server 20 connected to the remainder of the computer network,
for example, over the Internet. The first three components are server-side
components. Each of the server-side components will now be described in
more detail.
The authorization component 12 performs authorization processing on behalf
of either an enabled Web server 20 or an API client 22. The authorization
component 12 comprises an authorization server 24. Preferably, as shown in
FIG. 1, the authorization component 12 comprises a plurality of
authorization servers 24A, 24B, 24C and at least one authorization
dispatcher 26. In order to avoid a single point source of failure, a
plurality of authorization dispatchers 26A, 26B also preferably comprises
the authorization component 12.
In the case in which the authorization component 12 comprises a single
authorization server 24, no authorization dispatcher 26 is required, and
the single authorization server processes all authorization requests. If
the single authorization server 24 goes down, authorization requests
cannot be processed.
Consequently, the preferred configuration is as shown in FIG. 1, in which
the security and access management system 10 comprises the plurality of
authorization servers 24A, 24B, 24C and authorization dispatchers 26A,
26B, which operate in conjunction to provide efficient scalability of
authorization requests. For example, it is possible to start many
authorization servers 24A, 24B, 24C on different machines, allowing for
load balancing and fail-over of authorization requests. In order to manage
the various authorization servers 24A, 24B, 24C, the authorization
dispatchers 26A and 26B contain a repository of all available
authorization servers.
One of the authorization servers 24A, 24B, 24C communicates with an enabled
Web server 20A, 20B, 20C and the authorization dispatchers 26A and 26B
over a socket connection. The authorization servers 24A, 24B, 24C
communicate with the entitlements server component 14 over a CORBA ORB
(Object Request Broker).
Additionally, each authorization server 24A, 24B, 24C preferably contains
several caches to maximize performance of authorization requests. As
information is retrieved during authorization processing, the information
is stored in various caches. This allows for quick retrieval when
information is re-requested. Each cache preferably has a defined maximum
size to contain memory growth. Consequently, as a cache reaches its
maximum size, information contained within the cache is aged out.
The entitlements server component 14 performs database processing on behalf
of at least one entitlements manager administrative client 18 and the API
server 16. In addition, the entitlements server component 14 also forwards
requests from the entitlements manager administrative client 18 and API
server 16 to the authorization servers 24A, 24B, 24C comprising the
authorization component 12.
Communications between the entitlements server component 14 and both
administrative clients 18A, 18B, 18C and authorization servers 24A, 24B,
24C occur over a CORBA ORB. In order for the authorization servers 24A,
24B, 24C and administrative clients 18A, 18B, 18C to establish a
communication channel with the entitlements server component 14, the
entitlements server component is assigned a name that uniquely identifies
it to the ORB. In contrast to the preferred configuration in which there
is a plurality of authorization servers 24A, 24B, 24C, there is preferably
only a single entitlements server component 14.
The API server component 16, in conjunction with the entitlements server
component 14, performs database processing on behalf of an API client 22.
Unlike an authorization server 24A, 24B, 24C or administrative client 18,
the API server component 16 is preferably an element within the
entitlements server component 14, as shown in FIG. 1. Communications
between the API server component 16 and an API client 22A, 22B, 22C occur
over a socket connection from an assigned port.
As shown in FIG. 1, the Web servers 20A, 20B, 20C provide Web-enabled
applications and content to computer network users. Also, the security and
access management system 10 provides the capability to provide security
and access management to non-Web-enabled applications. Such
non-Web-enabled applications can be provided through the API clients 22A,
22B, 22C on at least one non-Web server 30, as shown in FIG. 1.
Communications between the API server component 16 and the non-Web server
30 occur over a socket connection.
The security and access management system 10 is selectively operated in one
of two modes, namely, standard mode or distributed mode. Each mode has
fail-over capabilities.
On the one hand, standard mode means that the security and access
management system 10 is running the authorization servers 24A, 24B, 24C on
a single machine with a primary authorization server and a stand-by
authorization server. The primary authorization server 24A, 24B, or 24C
handles all of the access requests for all of the Web servers 20A, 20B,
20C. It is only if the primary authorization server 24A, 24B, or 24C is
unavailable that the stand-by authorization server is used.
On the other hand, distributed mode means that the security and access
management system 10 is running multiple authorization servers 24A, 24B,
24C across multiple servers. In the preferred embodiment of the security
and access management system 10, distributed authorization servers can run
on NT and UNIX servers simultaneously. The distributed mode load-balances
requests by the Web servers 20A, 20B, 20C in a round robin fashion across
all of the authorization servers 24A, 24B, 24C. In the event that a single
authorization server 24A, 24B, or 24C is unavailable, the surviving
authorization servers continue to fulfill requests from the Web servers
20A, 20B, 20C.
Referring to FIG. 1A, the standard mode start-up process is as follows.
1) When the authorization servers 24A, 24B, 24C are started, the
authorization servers notify the authorization dispatcher 26 of their
availability.
2) When the Web server plug-ins are started, the plug-ins query the
authorization dispatcher 26 for available authorization servers 24A, 24B,
24C. The authorization dispatcher 26 queries all of the authorization
servers 24A, 24B, 24C to verify that the authorization servers are
available.
3) The authorization dispatcher 26 sends a list of the available
authorization servers and their ports to the plug-ins.
4) The plug-ins then start querying the primary authorization server 24A,
24B, or 24C for authorization requests. The primary authorization server
24A, 24B, or 24C queries the entitlements database 32 for entitlements and
responds to the requests from the plug-ins.
1) Referring to FIG. 1B, if the primary authorization server 24A, 24B, or
24C becomes unavailable in the standard mode, the request of a plug-in
will time out after a configurable time period. After the request of the
plug-in times out a configurable number of times, for example, three
times, then the plug-in needs to access another authorization server 24A,
24B, 24C.
2) The plug-in contacts the authorization dispatcher 26 to notify the
authorization dispatcher that the primary authorization server 24A, 24B,
or 24C is not available.
3) The authorization dispatcher 26 queries all of the registered
authorization servers 24A, 24B, 24C to verify availability. When the
authorization dispatcher 26 determines that the primary authorization
server 24A, 24B, or 24C is down, the authorization dispatcher notifies an
administrator via email. An error log is written to record the failure.
4) The authorization dispatcher 26 then sends the port of the available
stand-by authorization server 24A, 24B, or 24C to the plug-in.
5) The plug-in begins querying the stand-by authorization server 24A, 24B,
or 24C for authorization requests.
Referring to FIG. 1C, the distributed mode start-up process is as follows.
1) When the authorization servers 24A, 24B, 24C are started, the
authorization servers notify the authorization dispatcher 26 of their
availability.
2) When the plug-ins of the Web servers 20A, 20B, 20C are started, the
plug-ins query the authorization dispatcher 26 for available authorization
servers 24A, 24B, 24C. The authorization dispatcher 26 queries all of the
authorization servers 24A, 24B, 24C to verify that the authorization
servers are available.
3) The authorization dispatcher 26 sends a list of the available
authorization servers 24A, 24B, 24C and their ports to the plug-ins.
4) The plug-ins then start querying the authorization servers 24A, 24B, 24C
in a round robin fashion for authorization requests.
1) Referring to FIG. 1D, if any authorization server 24A, 24B, or 24C
becomes unavailable in the distributed mode, the request of a plug-in will
time out after a configurable time period. After the request of the
plug-in times out a configurable number of times, for example, three
times, then the plug-in needs to access another authorization server 24A,
24B, or 24C. The plug-ins continue to query the remaining authorization
servers 24A, 24B, 24C for authorization services.
2) The plug-in contacts the authorization dispatcher 26 to notify the
authorization dispatcher that an authorization server 24A, 24B, or 24C has
not been available.
3) The authorization dispatcher 26 queries all of the registered
authorization servers 24A, 24B, 24C to verify availability. When the
authorization dispatcher 26 determines that an authorization server 24A,
24B, or 24C is down, the authorization dispatcher notifies an
administrator via email. An error log is written to record the failure.
4) The authorization dispatcher 26 then sends the port of the available
stand-by authorization server 24A, 24B, 24C to the plug-in.
5) The plug-ins continue querying the surviving authorization servers 24A,
24B, 24C for authorization requests.
The security and access management system 10 preferably additionally
comprises a redundant database for the entitlements database 32 to avoid a
last single potential point source of failure. That is, the security and
access management system 10 can also support replicated databases. This
replication is preferably provided using Oracle's replication technology.
The authorization servers 24A, 24B, 24C can be integrated to automatically
fail-over to a back-up entitlements database on another server.
The security and access management system 10 provides a highly flexible and
scalable data model for defining both accessibility of resources and
applications and data model administration policy. While the security and
access management system 10 provides out-of-the-box support for Web-based
applications, the security and access management system is also powerful
and flexible enough to secure proprietary applications, such as the
applications which run on the non-Web server 30 shown in FIG. 1. Security
policy is defined using an access control architecture. Through the access
control architecture, protected resources are associated with resource
consumers, defining access control policy. Additionally, the security and
access management system 10 provides a robust administration architecture,
securing access to the entitlements database 32. Through the
administration architecture, a user is associated with administrative
rights and ownership, defining an administrative policy.
The hierarchy for the complete data model administration architecture,
generally indicated by the numeral 50, is shown in FIG. 2. The data model
administration architecture 50 preferably comprises an access control
architecture 52 and an administrative architecture 54. The access control
architecture 52 is divided into three components: resource consumer
architecture 56; access definition architecture 58; and resource
definition architecture 60. These components constitute the basic building
blocks for an access policy.
A resource consumer is granted or denied access privilege to a resource
depending on policy as defined by the access definition architecture 58.
Additionally, the access definition architecture 58 is flexible enough to
define policy beyond simple access of resources. This will be described in
greater detail below.
Considered in more detail, a resource consumer is someone who accesses or
manipulates a defined resource. Generally, a resource consumer is someone
who requests access to a Web-enabled or non-Web-enabled application or
content. For example, a resource consumer could be an employee who needs
to retrieve sensitive documents, a customer who wishes to modify his or
her account information, or a supplier with rights to view, purge, or
otherwise update factory floor data. In any event, an architecture needs
to be flexible enough to dynamically define the attributes of a resource
consumer and scalable enough to handle large numbers of consumers and
resources. The resource consumer architecture 56 achieves flexibility and
scalability by defining an extendable consumer data model and a
containment hierarchy of consumers.
Specifically, as shown in FIG. 2, the resource consumer architecture 56
comprises a consumer architecture which is divided into a consumer object
model 64 and an extensible consumer attribute model 66. A consumer object
is referred to as a user 68. A user 68 has several defined attributes (for
example, user ID, first name, last name, password, etc.), as well as
extendible attributes. These extendible attributes are referred to as user
properties 70. The name and type of a user property 70 (for example, a
string property, a date property, and integer property, etc.) is defined
by a user property definition 72. When a user property definition 72 is
created, all users 68 automatically inherit a user property 70 of the
defined name and type. However, a value is not automatically assigned to a
user property 70. A user property definition 72 preferably includes at
least one of the following types: Boolean; string; integer; floating
point; and date.
The resource consumer architecture 56 also provides a containment hierarchy
or containers 74 of users 68. This allows an administrator to more easily
assign access rights to a large group of users 68 without having to assign
rights individually. A user 68 can be grouped together into a group object
76. Group objects 76 likewise can be grouped together into a realm object
78.
For example, a software company has developed an application allowing
customer companies to view their account information. Each customer
company may have several points of contact that are allowed to access the
account database. An administrator defines a user 68 for each point of
contact, adds each user 68 to a group 76 that represents the customer
company, adds the group to a customer realm 78, and defines a user
property 72, such as "service contract," of type integer. Then the
administrator sets the service contract user property value for each user
68.
As shown in FIG. 2, the access definition architecture 58 provides two
approaches to assign access rights of a consumer or user 68 to a protected
resource, namely, basic entitlements 80 or smart rules 82. Basic
entitlements 80 and smart rules 82 will now be described in more detail.
Referring to FIG. 3, a basic entitlement 80 is analogous to an access
control list (ACL). A basic entitlement 80 directly allows or denies a
specific user 68, group 76, or realm 78 access to a resource, such as an
application function 84. Basic entitlements 80 assigned at the group or
realm level grant access to the contained objects. Thus, if a group 76 is
assigned access rights to a resource through a basic entitlement 80, all
of the users 68 contained within the group object have access rights to
the resource as well.
While basic entitlements 80 are a relatively straightforward and effective
approach to define access rights, this approach is hindered by the fact
that access rights need to be assigned and maintained manually.
Consequently, as users 68 are added or modified, an administrator needs to
manually modify the basic entitlement 80.
A more sophisticated approach is to define accessibility rules to a
resource. As shown in FIG. 2, the access definition architecture 58 refers
to these rules as smart rules 82.
Referring to FIG. 4, a smart rule 82 defines accessibility by specifying a
criterion which a user property definition 72 for a user 68 must meet for
the user to be granted access to an application function 84. Smart rules
82 are expressions such as: "DENY if a property is less than a certain
value." Smart rules 82 can also be strung together to form complex
expressions.
A smart rule 82 has three resultants: ALLOW; DENY; or REQUIRE. ALLOW states
that if the smart rule 82 is satisfied, permit the user 68 to access the
resource without any further rule processing. DENY states that if the
smart rule 82 is satisfied, forbid the user 68 access without any further
rule processing. Since ALLOW and DENY are mutually exclusive rules, the
access definition architecture 58 provides a mechanism to specify whether
ALLOW or DENY takes precedence. Finally, REQUIRE states that if the smart
rule 82 is satisfied, continue to the next smart rule, if any, to
determine accessibility; however, if the current smart rule is not
satisfied, DENY the user 68 access.
Referring again to FIG. 2, the resource definition architecture 60
comprises an application architecture 86 which groups protected resources
into applications 88. A Web-based application 88 is comprised of Uniform
Resource Identifiers (URIs) 90. Other types of applications do not have
resources directly contained in the application; rather, the application
represents implicitly a group of resources. Applications 88 also have
associated application functions 84, which represent the various services
associated with an application.
A user 68 is granted rights to an application 88. However, the security and
access management system 10 actually does not assign rights at the
application level, but assigns access rights to an application function
84. This is a powerful mechanism. Associating rules and rights at the
application function level, instead of at the application level, provides
greater security granularity.
By default, when an application 88 is created, the application has one
application function 84, namely, ACCESS. The ACCESS function is used by
enabled Web server objects 92 to determine access rights of a user 68 to
an application 88. However, an administrator can add additional
application functions 84 to the application 88 through the API client 22.
The additional application functions 84 can further define whether or not
a user 68 has privileges to use various services associated with an
application 88. The access rights to these additional application
functions 84 can be determined through the API server 16.
For a Web-based application 88, the application can contain URIs 90.
Associated with a URI 90 is a defined Web server object 92 which owns the
URI. Together, the URI 90 and Web server object 92 combine to form a
Uniform Resource Locator (URL). The Web server object 92, besides
identifying the location of a URI 90, also defines the identity of an
enabled Web server 20 shown in FIG. 1. Thus, when a URL is requested from
an enabled Web server 20, both the URI 90 shown in FIG. 2 of the requested
URL and the identity of the enabled Web server define the application 88
being referenced. The ACCESS application function 84 of the referenced
application 88 is used for determining accessibility to the requested URL.
For example, consider the situation in which a customer account application
has varying functionality depending on the service contracts with
customers. Consequently, a service contract provider wants all of its
customers to be able to access the customer account application, but
return an interface supporting only the level of functionality that
matches the service contract of the customer. In order to accomplish this,
an administrator of the service contract service provider would create an
application 88, for example, denoted CustomerAccountApplication. Next, the
administrator would define the URI 90 of the application 88,
/customeraccountapp.cgi, and a Web server object 92 which owns the
application, for example, WebServer. The administrator would then define
application functions 84 representing the various functionality of the
CustomerAccountApplication. The administrator associates either a basic
entitlement 80 or a smart rule 82 with the ACCESS application function 84
and each additionally defined application function.
During a request for the CustomerAccountApplication, the enabled Web server
20 processes the ACCESS application function 84 to determine accessibility
to the application 88. Once a user 68, that is, a service contract
customer, is granted access, the customer account application uses the API
server 16 to determine the different application functions 84 to which the
customer has access rights, and returns the correct interface which
supports the function set.
Finally, as shown in FIG. 2, the administrative architecture 54 provides a
flexible model for defining ownership and administrative responsibilities
of data model architecture objects. On the one hand, ownership can be used
to segment objects by their geographical location, organizational
structure, or other logical grouping to limit access by an administrator
to only objects in his or her area of responsibility. An area of ownership
is defined as an administrative group 94. For example, an administrator
can be defined that can modify only objects in the North American
Administrative Group.
Additionally, the capabilities of an administrator can be restricted. For
example, an administrator can be limited to modifying only users 68 and
user properties 70 within the North American Administrative Group. As
shown in FIG. 2, a set of capabilities or privileges of an administrator
is defined by an administrative role object 96.
Consider the following example. A company is using the security and access
management system 10 to protect its external customer account application,
but it is protecting its internal human resource (HR) information as well.
In order to manage administration of the entitlements database 32, the
company can define two administrative groups 94, namely, Customer
Administrative Group and HR Administrative Group. Next, the company can
define two administrative roles 96, Customer Admin Role and HR Admin Role,
granting each administrative role a full set of administrative privileges.
The security and access management system 10 comprises advanced,
intelligent web security and access control software. The security and
access management system 10 includes a wide array of powerful features,
controlled through a streamlined and intuitive graphical user interface,
providing administrators complete control over the intranet. The security
and access management system 10 offers unparalleled flexibility in
intranet security for the enterprise. The security and access management
system 10 can be adapted to any security philosophy or corporate
structure, and is truly scaleable. That is, the security and access
management system 10 can meet the security needs of a department,
division, or an entire corporation. The security and access management
system 10 is preferably implemented using a Java-based construction so
that the software will run on any server in a computer network, and
protect all Web applications, all the time. Furthermore, the security and
access management system 10 is designed to work seamlessly with the top
names in enterprise computing, including products from companies such as
Microsoft, Sun Microsystems, and Netscape.
The security and access management system 10 provides intranet security by
controlling access to Web applications and data. Using the security and
access management system 10, a security administrator can define and
describe the user population on the intranet, all of the applications
contained on the computer network, and the relationships between them. The
security and access management system 10 also offers unmatched
administrative flexibility. An organization using the security and access
management system 10 to secure intranet applications can implement and
enforce any suitable security policy. Using two simple concepts, the user
and the application, the security and access management system 10 provides
owners of enterprises the opportunity to apply the strongest security
available to the intranet and extranet.
The layout and functionality of each panel of the graphical user interface
of the security and access management system 10 will now be described.
Also included are brief explanations of each basic function of the
security and access management system 10.
The security and access management system 10 defines a number of concepts
in conjunction with security administration. The following glossary lists
the most common terms.
User means a single user of Web applications protected by the security and
access management system 10, using various user properties such as
username, password, e-mail address, IP address, etc. Group means a
collection of users, grouped together for ease of administration. Groups
have specific properties. A realm is a collection of groups. A realm
contains all of the users within the component groups of the realm. Entity
means a user, group, or realm.
Application means any Web application protected by the security and access
management system 10. An application can be a collection of any number of
Web resources or "pages." A resource is a single component or "page" of a
Web application, characterized by having a single URI. URI means Uniform
Resource Identifier which identifies the resource that is protected, such
as http://www.sirrus.com, and is a more generic term than the more common
URL. The security and access management system 10 views a Web server 20 as
a container for Web applications. A Web server 20 can contain any number
of Web applications, and the security and access management system 10 can
protect any number of Web servers. In addition, a Web application can span
multiple Web servers 20A, 20B, 20C seamlessly.
An entitlement is a relationship between an entity and an application. An
entitlement gives a user access to an application on the Web. An
administrator is an individual who creates and maintains entities,
applications, and entitlements on the intranet. In comparison, a
sub-administrator is a type of user that can perform limited
administrative tasks via the security and access management system 10, as
designated by the administrator.
An administrative group is a set of ownable resources that is configured to
be under the control of a particular set of administrators. Administrative
role means a role defining the types of operations an administrator can
perform on a particular administrative group. An ownable resource is one
of all of the types of resources defined in the security and access
management system 10, which can fall under the control of an
administrative group. They are: user, group, realm, application, Web
server, administrative roles, and user property definitions. Other
resources, such as entitlements and smart rules, are owned by default by
the group that owns the related application, property, or
user/group/realm.
As mentioned earlier, the security and access management system 10
encompasses various concepts. These concepts include users, groups, and
realms.
Many enterprises or organizations deal with hundreds, or indeed thousands,
of computer users. Administering security to each of these users one by
one would be a daunting and unpleasant task. Preferably, the security and
access management system 10 incorporates the concept of grouping users
together to facilitate administration.
A group is a collection of users. Any action applied to a group is
automatically applied to every user in that group. Consequently, granting
a group access to an application automatically gives each user in that
group access to that application. The same rule applies for restricting
application access and various other features. The exception to this rule
is deleting a group. If a group is deleted, the users in that group are no
| | |
