Abstract:

The present invention relates to a method and system for controlling
access rights to dynamically instantiated portal applications in a portal
environment, wherein new instances of a portal application and respective
access control information on resources used in the application are
generated dynamically from an automated programmed mechanism, and wherein
a user-application role mapping is demanded for the portal application by
a respective runtime access control function implemented at the portal
environment. The method includes: assigning an individual
user-to-application role mapping to a respective individual one of the
created instances of the portal application, wherein for each incoming
user request to one of the created instances the runtime access control
function checks a target application instance identifier, which
identifies an individual application instance desired to be addressed by
the incoming request; and granting access rights to incoming user
requests according to the application roles as they are defined for the
target application instance.

Claims:

1. A method for controlling access rights to dynamically instantiated
portal applications in a portal environment, wherein new instances of a
portal application and respective access control information on resources
used in the application are generated dynamically from an automated
programmed mechanism, and wherein a user-application role mapping is
demanded for the portal application by a respective runtime access
control function implemented at the portal environment,
comprising:assigning an individual user-to-application role mapping to a
respective individual one of the created instances of the portal
application, wherein for each incoming user request to one of the created
instances the runtime access control function checks a target application
instance identifier, which identifies an individual application instance
desired to be addressed by the incoming request; andgranting access
rights to incoming user requests according to the application roles as
they are defined for the target application instance.

2. The method according to claim 1, wherein for a newly created
application instance a default higher privileged role is proposed for the
user who generates the instance, whereas for other users lower privileged
roles are granted.

3. The method according to claim 1, wherein the portal application is a
composite application.

4. The method according to claim 1, wherein the assigning is implemented
by persisting the application instance identifier for each
principal-to-application role mapping.

5. The method according to claim 1, wherein the assigning is implemented
by persisting empty application roles that point to a base application
role and are scoped to a particular application instance identifier.

6. An electronic data processing system for controlling access rights to
dynamically instantiated portal applications in a portal environment,
wherein new instances of a portal application and respective access
control information on resources used in the application are generated
dynamically from an automated programmed mechanism, and wherein a
user-application role mapping is demanded for the portal application by a
respective runtime access control function implemented at the portal
environment, comprising:a component for assigning an individual
user-to-application role mapping to a respective individual one of the
created instances of the portal application, wherein for each incoming
user request to one of the created instances the runtime access control
function checks a target application instance identifier, which
identifies an individual application instance desired to be addressed by
the incoming request; anda component for granting access rights to
incoming user requests according to the application roles as they are
defined for the target application instance.

7. A computer program product loaded on a computer readable medium, which
when executed, controls access rights to dynamically instantiated portal
applications in a portal environment, wherein new instances of a portal
application and respective access control information on resources used
in the application are generated dynamically from an automated programmed
mechanism, and wherein a user-application role mapping is demanded for
the portal application by a respective runtime access control function
implemented at the portal environment, the program product comprising
program code for:assigning an individual user-to-application role mapping
to a respective individual one of the created instances of the portal
application, wherein for each incoming user request to one of the created
instances the runtime access control function checks a target application
instance identifier, which identifies an individual application instance
desired to be addressed by the incoming request; andgranting access
rights to incoming user requests according to the application roles as
they are defined for the target application instance.

Description:

FIELD OF THE INVENTION

[0001]The present invention relates to the field of network portals and in
particular to a method and system for controlling access rights to
dynamically instantiated portal applications in a portal environment,
wherein new instances of a portal application are able to be generated
dynamically from an automated programmed mechanism, such as a template
based mechanism, and wherein a user-application role mapping is demanded
for the portal application by a respective runtime access control
function implemented at the portal environment.

RELATED ART

[0002]In this field the term "composite application" defines an
application hosted on a web portal platform which is built by combining
and connecting multiple components such as portlets, wikis, document
libraries, and web services, for a particular purpose such as a shop or a
virtual team room application. A single portal platform may host multiple
instances of the same composite application, for example different team
rooms for different associated user communities. Composite applications
are built from a template describing the contained components and their
set-up and interconnection.

[0003]FIG. 1 shows an overview of the components that build up the prior
art application infrastructure 11, abbreviated herein also as AI--system
architecture, within an overall portal system 10. The application
infrastructure comprises:

[0004]a templating application infrastructure 13, abbreviated herein also
as TAI, that handles templates in the system and the creation of new
composite applications;

[0005]a composite application infrastructure 15, abbreviated herein also
as CAI, that handles application instances 19 during runtime and manages
connections and the data flow between the components of an application;

[0006]a component registry 27 that manages business components installed
in the system; and

[0007]a portal handler 29 which is a specific local component that manages
any portal related artifacts 8 like pages or portlets for the application
infrastructure in the portal, and which is used by the instantiation
component 17 to create such artifacts during the creation of a new
composite application.

[0008]The templating application infrastructure (TAI) component 13 manages
the templates 23 in the system which contain references to instantiable
components in a local list of components 27. As an example, a template
for shopping applications could consist of a reference to a document
library component which is used to hold the available goods and their
descriptions, a shop portlet that lets clients process actual shopping
transactions, an invoice business component that handles the payment
process, and a blogging component that allows clients to comment on their
satisfaction.

[0009]The TAI component 13 also creates application instances from the
templates via an instantiation component 17, which creates separate
instances of the referenced business components, typically by creating or
copying individual configurations for these components such that multiple
application instances can be created from the same template without
interfering with each other.

[0010]For the above mentioned sample template, the instantiation 17 would,
among other things, create an individual storage compartment in the
document library, an individual configuration of the invoice component
referring to the bank account and an individual configuration for the
shop portlet that is set up to display goods from the created document
library and to delegate payment processing to the created invoice
component instance.

[0011]In particular, the instantiation 17 needs to create the necessary
portal artifacts like pages that allow interaction with the created
composite application, which is typically done by employing a specific
handler 29 that creates those portal artifacts 8 and links them with the
business components of the application.

[0012]The created composite application instances 19 hold a context 25
that lists the component instances that make up the composite application

[0013]FIG. 2 shows an overview of the storage components involved in the
portal architecture 10 that comprises deployment related code in a
deployment component 14 and a runtime environment in one or more runtime
containers 12 where the deployed components are executed.

[0014]For the composite application context deployed artifacts are:

[0015]application components stored in a component registry 18; and

[0016]templates stored in a template catalog 20.

This data is then referenced by the application's instance specific data
16.

[0017]In such a portal environment, a plurality of composite applications
(CA) are usually used for providing at least a part of the portal
functionality for members of one or more user communities. Herein, an
administration user administrates an application-specific membership of a
user to an application role.

[0018]A portal composite application infrastructure is known from prior
art, for example from IBM's WebSphere Portal. Within this portal
composite application infrastructure a plurality of N applications are
stored in the form of respective application instances. For each of those
applications a respective application community is defined. The composite
applications may access a database storing the composite application
data.

[0019]With special reference to the technical problem related to the
present invention a portal application, be that a composite application
or a single component application, is used by a specific set of portal
users called a "community". To become a member of an application
community a portal user has to be assigned to at least one application
role by a basically application-specific membership manager. Thereafter
the user has all permissions and respective access rights to business
data as specified by its application role. Typical roles are supervisor,
manager, editor, user, etc. But generally, those roles are
domain-specific and thus individual for any business.

[0020]The application infrastructure provides programmed functions which
enable the creation of portal application instances based on predefined
templates. A template defines business components and application roles
which specify permissions for the included components and parameters
which are resolved during the creation of an application instance.

[0021]The usage of such parameters allows the configuration of the
appearance and the behavior of the created applications. Thus, one
template can be used to create multiple flavors of one single application
type. Template parameters are also called "points of variability" (POV).

[0022]To become a member of an application community a portal user has to
be assigned to at least one application role by an application specific
membership manager. Thereafter, the user has all permissions specified by
this application role. With respect to the above mentioned multiple
business components a template is comprised of, and with respect to the
plurality of users which are usually equipped with specific rights
associated with such business components, it is quite complicated to
manage the overall access rights for those composite applications.

[0023]It should be further noted that a given template instance is
typically instantiated multiple times in the system resulting in multiple
application instances of that template. Such an application instance is
then stored on the hard disk of the system and is run such as usual
programs are run. Those application instances contain distinct
application role instances as defined within the template. The membership
information for such an application role can be managed individually
within each application. A portal user can be in the same application
role in many of those composite applications originating for the same
template. If a specific user actually needs to be in many of those roles,
the corresponding role assignments have to be individually created in
prior art within each application instance. Thereby the membership
manager has to repeat the same role mapping over and over again. This is
a manual task which may lead to configuration errors resulting in
undesired, unintended or insufficient role assignments.

[0024]With reference to FIG. 3, there is shown a prior art system overview
showing the prior art access control for dynamically instantiated
applications. The components particularly relevant for the present
invention are the collaborative infrastructure 11 and the access control
component 32 located both on the portal server. In FIG. 3 the
collaborative application 1 denoted by reference sign 34 is a dynamically
instantiable application, so the collaborative infrastructure 11 stores
only one instance of this application in the database as a persistent
data structure. This application is thus referred to as "base
application". Further instances of this application 34 are then generated
and launched dynamically during runtime by the collaborative
infrastructure 11 taking dynamic, transient copies of all resources
contained in the application and associating them to a respective dynamic
instance of the application, which are denoted as Collab App 1' and
Collab App 1'' with reference signs 35 and 36, respectively.

[0025]Such dynamic application instances 35 and 36 usually make sense for
applications that are instantiated very often, when particular instances
of an application differ at very few points and have a limited lifetime.
Examples are applications for web conferences, where an application
instance represents one occurrence of a web conference, including the
respective pages and portlets for preparing, running, and documenting the
conference, activities, or incident management, both of which can be
considered as temporary collections of documents and information about a
particular topic, where an application instance may provide the necessary
page structure and infrastructure portlets to handle those.

[0026]The access control component 32 provides the capability to define
application roles that can be described as collections of permissions
related to a base application 34. In FIG. 3, the application role
"Visitor", e.g., contains the permissions to use the pages and portlet in
application 34, whereas the application role "Moderator" contains edit
permissions on the pages and manage permission on the portlet.

[0027]In the state of the art, the permissions can disadvantageously only
relate to persisted resources, so it is not possible to define
application roles for dynamically instantiated applications.

[0028]Application roles can be assigned to users or groups, which give
them the respective permissions. In the diagram of FIG. 3, the user Alice
is assigned to the Visitor application role, and user Bob is assigned to
the Moderator application role. The collaborative infrastructure 11
consults the access control component 32 to decide what kinds of
operations the current user can perform on a particular application.

[0029]The collaborative infrastructure 11 is triggered by the basic
rendering and navigation mechanism 38 in the portal server, if the
client, usually a browser, requests or interacts with pages that belong
to a collaborative application.

[0030]With reference to FIG. 4, which is a diagram according to FIG. 3
enriched by references to the essential control flow steps, the prior art
control flow of access right management to some dynamically created
instance 35 or 36 is as follows:

[0031]Step 410

[0032]Bob uses his browser to access the instance 35 of the collaborative
application 1. The portal rendering and navigation component 38 routes
this request to the collaborative infrastructure component 11.

[0033]Step 420

[0034]The collaborative infrastructure component 11 asks the access
control component 32 for Bob's permissions on the instance 35 of the
collaborative application 1. As the access control component 32 has no
means to store permissions for dynamically created resources, it returns
the permissions for the base application, i.e., that one of the base
application 34.

[0035]Step 430

[0036]The collaborative infrastructure component 11 processes the request
and displays the instance 35 based on Bob's permissions on the base
application 34.

[0037]As a person skilled in the art may appreciate, this prior art access
control management is insufficient because it does not reflect the basic
needs of large enterprises, in which, for example, a large number of
application instances are generated per day, wherein all these instances
originate from the same basic application. In particular, there must
always be at least one user who is granted super-user or administrator
rights in order to be able to manage the resources comprised of a
respective application instance.

[0038]Assume a case in which multiple departments coexist in a single
enterprise, for example a financial department, development department,
public relations department, etc. In the prior art, one and the same
administration user is responsible to manage the instances used of all
these different departments. This may generate confidentiality problems
because the data visibility cannot be restricted according to
individually defined confidentiality guidelines.

SUMMARY OF THE INVENTION

[0039]The present invention provides an access right control method which
can be adapted to better satisfy individual needs of an enterprise. The
prior art access right management process is enriched by the management
of an additional attribute which is referred to herein as a "target
application instance identifier".

[0040]This target application instance identifier is assigned to each
http-request against the portal and points to an individual application
instance which is accessed by a respective request. In order to manage
this identifier the user-to-role mapping facilities existing in prior art
are modified according to the invention in order to specify dynamically
created application instances in order to explicitly delimit each of such
mappings to a respective application instance. During runtime, the prior
art access control component is enriched by further program evaluation
logic which evaluates this additional information, identifies the target
application instance and delivers the application role assignments for a
requesting user only with reference to a respective application instance.
So, only those application roles that are explicitly scoped to the target
application instance are active for the current user request. All other
application roles are muted for this request. Thus, basically, different
users can have respective different access rights, i.e., privileges in
respective different application instances, which were instantiated from
the same base application. By this inventional method it is thus possible
to configure individual permissions on different instances of the same
base application. This can be implemented without creating a respective
number of persisted application instances for each needed combination of
permissions, and without any complex logic required to hide such
permission logic to a requesting user.

[0041]Thus, the inventional methods provides the capability to
automatically generate access control permissions on a large set of
dynamic applications, thereby enhancing the ability to administrate and
run a large number of individual applications in such an enterprise.

[0042]According to an aspect of the invention, a method and respective
system for controlling access rights to dynamically instantiated portal
applications in a portal environment are disclosed, wherein new instances
of a portal application and respective access control information on
resources used in the portal application are generated dynamically from
an automated programmed mechanism, such as a template based mechanism,
and wherein a user-application role mapping is demanded for the portal
application by a respective runtime access control function implemented
at the portal environment. The method comprises: assigning an individual
user-to-application role mapping to a respective individual one of the
created instances of the portal application, for example, in an
initialization step, wherein for an incoming request to one of the
created instances the runtime access control function checks a target
application instance identifier, which identifies an individual
application instance desired to be addressed by the incoming request; and
granting access rights only based on those application roles which are
granted for the target application instance.

[0043]By the term "generate dynamically" a way is meant to generate the
instances during runtime of the portal server with a limited life time of
such instance, such as for example when creating a web conference and
using it for half an hour with different participants round the world.
Thereafter, the instance is terminated and no essential data of the
application instance is persisted in a portal database, except the usual
logging data.

[0044]Further, advantageously, for a newly created application instance a
default higher privileged role such as "administrator", "moderator",
etc., including major access rights for editing data items, is proposed
for the very user who generates the instance. For other users, lower
privileged rules are granted with respective more restricted user access
rights, such as, e.g., read-only rights. This increases user comfort, as
a useful access right assignment can be done for most cases automatically
without manual intervention.

[0045]Further, the assigning is implemented by persisting the application
instance identifier for each principal-to-application role mapping in
form of an application scope, i.e., wherein the validity of the mapping
is delimited to the actual application instance only, instead of the
general composite or collaborative application, as done in prior art.

[0046]The assigning can also be implemented by persisting empty
application roles that point to a base application role and are scoped,
i.e., selectively defined to be delimited to, to a particular application
instance identifier. By that they can be assigned to principals only in
this application scope.

BRIEF DESCRIPTION OF THE DRAWINGS

[0047]The present invention is illustrated by way of example and is not
limited by the shape of the figures of the drawings.

[0048]FIGS. 1 and 2 illustrate the most basic structural components of a
prior art hardware and software environment used for a prior art method
at a portal site.

[0049]FIG. 3 is a prior art system overview depiction focusing the
components involved particularly by the present invention, according to
prior art.

[0050]FIG. 4 is a system overview depiction according to FIG. 3, enriched
by references to the control flow of the prior art method of access
control management.

[0051]FIG. 5 is a depiction according to FIG. 3, enriched by an
inventional component and including an inventional version of access
control component.

[0052]FIG. 6 is a depiction according to FIG. 5, including again
references to interactions according to the inventional method.

[0053]FIGS. 7 and 8 show data records sample within an application role
table (FIG. 7) and a principle to application role mappings table (FIG.
8).

[0054]FIGS. 9 and 10 are representations according to FIGS. 7 and 8
illustrating a second data record sample.

DETAILED DESCRIPTION OF THE INVENTION

[0055]With general reference to the figures and with special reference now
to FIG. 5, according to an embodiment of the inventional method the
existing components of prior art are extended as described below.

[0056]A request parser 54 is added as a new component to determine the
particular target application instance that is addressed in a current
request incoming from a browser. The access control component 52 is
extended with programmed logic which implements functionality allowing
that each mapping from a user or from a group to an application role is
delimited to a particular application instance.

[0057]Thus, the mapping becomes only valid when one of the correct
application instance is addressed by an incoming request.

[0058]For example, Bob now has a mapping to the Visitor application role
that is only valid for instance 35, and a mapping to the Moderator
application role that is valid for the base application 34 and instance
36.

[0059]With reference to FIG. 6 the following interaction steps are
performed according to this embodiment of the inventional method:

[0067]The access control component 32 asks the request parser 54 for the
target application instance. As any role mappings are now delimited to
particular application instances, the access control component is able to
consider only those role mappings that are valid for instance 35, for
example. For user Bob this is a visitor application role in this case.

[0068]Step 650

[0069]The collaborative infrastructure component 11 processes the request
and displays the instance 35 based on the permissions that have been
explicitly defined for user Bob and for this particular dynamic
application instance.

[0070]FIGS. 7 and 8 give further implementational details on how the
access control component 32 may store the relevant new information
according to a first preferred way.

[0071]FIGS. 7 and 8 give some details of how the existing data structure
can be extended to realize the logic introduced by the invention. Both
the application roles and the principal-to-application role mappings data
structures already exist in the state of the art. Application roles are
basically described by their name and the list of portal permissions they
contain. This structure remains unchanged in the implementation variant
of FIGS. 7 and 8.

[0072]The principal-to-application role mappings in the state of the art
are described by tuples of an application role (name) and a principal.
For this variant of the inventional method this tuple is extended to a
triple including the ID 80 of the target application instance that
additionally defines the application instance scope for the mapping such
as described previously. This limiting ID 80 limits for example the
mapping for Alice and the Visitor application role only to be valid in
the context of Collab App 1', i.e., instance 35.

[0073]FIGS. 9 and 10 show a further implementational variant for the
inventional method, again with respect to how to store the inventional
information.

[0074]In this case, the principal-to-application role mappings remain
unchanged, and the application role data structure is extended by a base
application role and an application instance limitation referred to as
"application scope" attribute 90. With this variant, each dynamically
instantiated application gets its own copies of the application roles in
the base application, e.g., Visitor' and Moderator' for Collab. App 1',
instance 35. These copies are represented as empty application roles that
do not contain any portal permission, but define them implicitly by
pointing to the base application role. Additionally, the application
scope is needed to specify for which application instance the application
role is valid. For example, the application role `Visitor` points to the
Visitor base application role and thus contains the equivalent
permissions related to Collab App 1', instance 35, i.e., User@Page1',
User@Page2', User@PortletA'. In the principal-to-application role
mappings structure the mappings are now defined for the "scoped"
application roles, so, e.g., Alice is directly assigned the Visitor'
application role.

[0075]The invention can take the form of an entirely hardware embodiment,
an entirely software embodiment or an embodiment containing both hardware
and software elements. In an embodiment, the invention is implemented in
software, which includes but is not limited to firmware, resident
software, microcode, etc.

[0076]Furthermore, the invention can take the form of a computer program
product accessible from a computer-usable or computer-readable medium
providing program code for use by or in connection with a computer or any
instruction execution system. For the purposes of this description, a
computer-usable or computer readable medium can be any apparatus that can
contain, store, communicate, propagate, or transport the program for use
by or in connection with the instruction execution system, apparatus, or
device.

[0077]The medium can be an electronic, magnetic, optical, electromagnetic,
infrared, or semiconductor system (or apparatus or device). Examples of a
computer-readable medium include a semiconductor or solid state memory,
magnetic tape, a removable computer diskette, a random access memory
(RAM), a read-only memory (ROM), a rigid magnetic disk and an optical
disk. Current examples of optical disks include compact disk-read only
memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD.

[0078]A data processing system suitable for storing and/or executing
program code will include at least one processor coupled directly or
indirectly to memory elements through a system bus. The memory elements
can include local memory employed during actual execution of the program
code, bulk storage, and cache memories which provide temporary storage of
at least some program code in order to reduce the number of times code
must be retrieved from bulk storage during execution.

[0079]Input/output or I/O devices (including but not limited to keyboards,
displays, pointing devices, etc.) can be coupled to the system either
directly or through intervening I/O controllers.

[0080]Network adapters may also be coupled to the system to enable the
data processing system to become coupled to other data processing systems
or remote printers or storage devices through intervening private or
public networks. Modems, cable modem and Ethernet cards are just a few of
the currently available types of network adapters.