WO2009068433A1

WO2009068433A1 - Dependent membership for collaborative applications in a portal server infrastructure

Info

Publication number: WO2009068433A1
Application number: PCT/EP2008/065289
Authority: WO
Inventors: Holger Waterstrat; Jan Paul Buchwald; Dieter Buehler; Andreas Zehnpfenning
Original assignee: International Business Machines Corporation
Priority date: 2007-11-27
Filing date: 2008-11-11
Publication date: 2009-06-04

Abstract

The present invention relates to the field of Network portals and in particular to a method and system for configuring access rights to resources used by both, a portal composite application (12) (CA) of a portal server (10) and a backend computer system (30) related to said composite application. In order to provide such method and system which is easier to use, the following steps are proposed: a) automatically generating a mapping (60) transforming the access rights valid at the backend computer system to the portal business component corresponding to the backend system, wherein the mapping maps specific data structures required for the definition of the access rights at the backend system to a valid definition of access rights to the business component at the portal side, b) using (510,...54O) this mapping during runtime for controlling the access rights for user actions targeting to view or edit the resources of the backend system via a respective portlet of the composite application

Description

D E S C R I P T I O N

Dependent Membership for Collaborative Applications in a Portal Server Infrastructure

1. BACKGROUND OF THE INVENTION

1.1. FIELD OF THE INVENTION

The present invention relates to the field of Network portals and in particular to a method and system for configuring access rights to resources used by both, a portal composite application (CA) and a backend computer system related thereto .

1.2. DESCRIPTION AND DISADVANTAGES OF PRIOR ART

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.

Figure 1 shows the 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: - the templating application infrastructure 13 -abbreviated herein also as TAI - that handles the templates in the system and the creation of new composite applications,

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

- the component registry 27 that manages the business components installed in the system, and

- the 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.

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 .

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.

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. In particular, the instantiation 17 needs to create the necessary portal artifacts like pages that allow to interact 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.

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

Figure 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.

For the composite application context deployed artifacts are:

- application components stored in a component registry 18,

- templates stored in a template catalog 20.

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

With special focus now to the technical problems underlying to the present invention on a portal server such as exemplarily shown in figure 1 and 2 the access control to different components of the list 27 is provided by specialized tools. These access right management tools manage the access rights to portlets and specific functionalities thereof for different user groups. A user is associated with a specific user group by a membership relation, such as user Smith is member of the user group "Administrator". Some further user groups are defined which is in general dependent of the portal application itself.

Many portal applications are used to perform business which also strictly relies to so-called backend systems, however, which are frequently implemented as business applications on a main frame base in particular in case of banking applications or other high performed computer systems.

Figure 3 illustrates the structural components relevant specifically for management of access control rights in such prior art hardware and software environment used for a prior art method in a portal server 10 at a portal site (left) when using a collaborative application 12 and at a backend system 30 (right) separate from the portal server.

The backend system 30 or several of them are connected via proxy servers, firewalls etc. and the internet to the before mentioned portal server business components. The access rights to resources managed by the backend systems are managed in prior art very often by manual interaction of an administration user who directly edits respective resources within managed by so-called business components 32.

The administration user uses a further, second administration tool for controlling the access rights to further resources, for example backend databases used by further business users. In the backend system the access rights are very often defined in a user-specific way, i.e. an exemplary user Bob has some predefined access rights to a given resource, whereas another exemplary user Alice has different access rights to this resource and so on. Very often the access rights are not user- group specific.

In common practice of business, however, very often the same persons want to have access either to resources at the portal side, and to resources at the backend side. So, in prior art both sides are managed independently of each other with different access right management tools. As a consequence, when modifications of the access rights are required, e.g. because a new staff member must have access to resources of the portal side and of the backend side, then respective independent tools must be used and changes of respective access right files must be affected. A person skilled in the art will be appreciate that this is in general an arrangement of complicated and double work for basically a single business aspect .

So it would be desirable to simplify the access management in such IT infrastructure.

1.3. OBJECTIVES OF THE INVENTION

It is thus an objective of the present invention to provide a method and system for configuring access rights to resources used by both, a portal composite application and a backend computer system related to this composite application which is easier to use. 2. SUMMARY AND ADVANTAGES OF THE INVENTION

This objective of the invention is achieved by the features stated in enclosed independent claims. Further advantageous arrangements and embodiments of the invention are set forth in the respective subclaims. Reference should now be made to the appended claims.

According to the broadest aspect of the present invention a method and respective system for configuring access rights to resources used by both, a portal composite application and a backend computer system related to the composite application is disclosed which comprises the steps of:

a) automatically generating a mapping transforming the access rights valid at the backend computer system to the portal business component corresponding to the backend system, wherein the mapping maps specific data structures required for the definition of the access rights at the backend system to a valid definition of access rights to the business component at the portal side,

b) using this mapping during runtime for controlling the access rights for user actions targeting to view or edit the resources of the backend system via a respective portlet of the composite application.

Advantageously, using these steps as mentioned before a business user which uses the front end at the portal server is automatically equipped with the correct access rights for both, using a specific portlet and a specific backend system resource processed by the portlet. In consequence, this business user need not be aware of the necessity to acquire the proper rights for both different IT-worlds, i.e. the portal world and the backend world. By generating automatically a valid mapping of access rights the business user does not even notice that any action triggered by a portlet travels through the internet and enters the backend system database, traversing at least several security systems such as firewalls etc., because any management of access rights is done fully automatically and transparent to the business user.

Further advantageously, if the access rights of a user are modified, this modification of the access rights of the backend system is reflected also in an updated version of the mapping which results in an automatic adaptation of the access rights at the portal side.

Further, the direction of the access right dependencies can also be inversed. In such a case, the access rights relevant at the portal side are transformed to access rights of the backend system side.

The mapping stated above requires some logical rules which are predefined and applied either by a computer program or by manual interaction.

Such a rule will take the role names and definitions on the portal server side as well as on the backend system side into account. Administrator or Admin roles in the backend system can be automatically matched to a Manager role in the portal server via the role names. If such an automated mapping is not possible because of a complex role setup, manual interaction will be provided during the initial application deployment. Preferably the step of generating the mapping is triggered automatically when at the portal the application specific roles of the portal application are initiated during initial deployment of the application.

Further advantageously, the status of the access rights of a given user role made available by the mapping is controlled either, if certain predefined events occur, or, if access rights to certain resources are granted, or they are triggered otherwise, for example periodically in time, or after any reboot of the portal server, or after restart of the portal business application.

The overall advantage is that any modification of the access rights at the backend system can be automatically seen within the mapping and thus can be used for controlling the access rights at the front end. A business user wanting to use a portlet for reading, editing and deleting data managed by the backend system automatically receives appropriate permissions to use this portlet according to the access rights granted in the backend system.

Further preferably three attributes are introduced which can be used for qualifying the access rights in a simple way, as follows :

A first attribute is "required". In this case a user must explicitly have granted access rights on both sides, portal and backend, for accessing a certain resource. That is the user must have the necessary backend access rights and be granted access rights to the portal resources by which he wants to control the access to the backend data. According to a second attribute, denoted here as "sufficient", a user just needs the granted access rights at the backend side to access some resource there, whereas the access rights at the portal side for issuing a specific action in the application are not specifically checked. Moreover, the access rights at the backend may imply access rights on portal resources .

Third, the attribute "optional" implies that the access rights on the backend system do not contribute to any access rights on the portal side. That is, a respective data object at the backend system is free for access as well as a specific portlet at the portal by which the data object is to be controlled as long as the user has the necessary access rights on the portal side.

So, preferably, a group of attributes is defined for qualifying the access rights in a way differentiating between respective different user privileges.

In this sense, further preferably, a "required" attribute is used for defining an access configuration in which the access to said backend system resource is required for controlling the respective portal resources.

Similar, further preferably, a "sufficient" attribute is used for defining an access configuration in which the access to said backend system resource is sufficient for controlling the respective portal resources.

Similar, preferably, an "optional" attribute is used for defining an access configuration in which the access to said backend system resource and the portal application resources are managed independently. A user needs appropriate access rights granted on the portal side and on the backend resources .

3. BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and is not limited by the shape of the figures of the drawings in which:

Figure 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,

Figure 3 illustrates the structural components relevant specifically for management of access control rights in a prior art hardware and software environment used for a prior art method at a portal site (left) and at a backend system separate from the portal server (right) ,

Figure 4 illustrates the structural components relevant for management of access control rights in an inventional hardware and software environment used according to a preferred embodiment of the inventional method,

Figure 5 illustrates the control flow of the most important steps of a preferred embodiment of the inventional method,

Figure 6 illustrates an exemplary dataset created and used by the inventional mapping function,

Figure 7 illustrates the control flow of the most important steps of a preferred embodiment of the inventional method, when during runtime of the portal application server a user' s data are checked if the user is member of a particular Community Role.

Figures 8 and 9 illustrate two different use cases for the inventional method.

4. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

With general reference to the figures and with special reference now to figure 4 an inventional access control module

40 of a collaborative application 12 is provided, preferably at the portal server because this is the location, where the actual access to the backend system data is initiated by a user. This control module 40 is operatively connected to a data store (not depicted) , for example the portal server database, which comprises generalized access rights which are aggregated from the portal definition and the backend system definition of respective access rights. In order to implement the access control module, respective access right definitions of the backend systems are read, see the bi-directional arrow

41 of figure 4 and evaluated in a respective control program

42 preferably separately for each business component. This is done only once, preferably and will be valid as long as the program language specific definitions of the access rights do not change, neither at the backend side nor at the portal server side.

In a freely selected, typical sample use case the system architecture shown in figure 4 is used by a banking application which comprises a backend component resident at the backend system 30 (right side of figure 4) and a portal business component 32 resident at the portal server (center of figure 4) . Both components expose two different business domain specific component roles which are mapped according to the invention to "community roles". At the portal side these are the roles "supervisor", "employee", whereas at the backend side these are the roles "admin" and "user". According to this specific embodiment, the membership of a certain user is automatically propagated from the backend system side to a corresponding component role at the portal server side, by aggregating both types of access rights into a resulting single access right which is valid for both, the portal side and the backend system side.

According to a preferred embodiment of the invention a box 32 is depicted in figure 4, which is denoted to implement the business components at the portal server. For each of these business components an inventional control module 40 (only one is depicted for improved clarity) is provided which comprises logic program functionality 42 for aggregating the access rights of both sides, the portal server side and the external backend system side. The basic control flow implemented within this preferred embodiment includes the following steps, which are also depicted in the drawing of figure 4 by the arrows provided with the reference numbers:

In step 1, during portal server application runtime, the portal server software receives a request issued by a browser indicating that a user, let us say user Bob, wants to access a specific business application which is managed within one of the business components in the logical module 32. Now, the logic comprised of the control module 40, will check all roles assigned to Bob in order to determine if the access request should be granted or not.

In a preferred implementation the already existing community component 38 is used therefore. So, in step 2 this portal communities component 38 is requested to check for all roles Bob is assigned for in the before mentioned application.

Then, in a further step 3 the specific business component corresponding to this business application and comprised of logic module 32 is requested by the control logic of module 40 to check the roles Bob is assigned for in the external backend system.

Then, in a further step 4, the respective business component accesses the backend system, for example a backend system, in order to check for Bob's roles. Then it returns the data to the control module 40 of this inventional collaborative infrastructure .

Then in a further step 5 the control module aggregates both types of access rights, i.e. those of the portal server and those of the backend system. Details of the aggregation procedure are given further below.

Then, in a step 5 the control module 40 reads a combined result from the community module 38 and the external system access rights and uses this combined result to determine if or if not Bob's request should be granted and further processed.

Figure 5 is a control flow diagram reflecting this basic control flow in a further embodiment of the inventional method. The logic which implements these steps is preferably implemented in a control shell, comprised either of a specific business component, or of the collaborative infrastructure component .

According to figure 5 in a first step 510 a browser action is sensed, wherein a certain web page, a portlet ID and an action ID is specified and determined, e.g. when a user clicks any control panel provided by a specific portlet. This corresponds to figure 4, step 1.

Then in a further step 520 the control logic evaluates and reads the access rights required by this user action.

During a further, subsequent checking step 530 the control logic checks a mapping table which maps and aggregates the backend system access rights and the portal server access rights to the user in question after having defined the data target in the backend system, where the access is intended to be done .

Then, in a further step 540 the aggregated access rights comprised of the mapping table, for example, are checked if they are sufficient or not. In case they are not sufficient, the access to the backend system data resource is denied, step 550. Otherwise, see step 560, the rights are assumed and evaluated as sufficient. Thus, the command targeted to the backend system data is forwarded to the backend system.

At the backend system itself no modification of any code is necessary according to the preferred embodiment. This is advantageous because such modifications would otherwise require further coding work.

Figure 6 depicts a data record sample for an exemplary case of a collaborative application called "team room department 02981", where the users Bob, Alice, Jane, Jack and John are defined as "participants", so, their community role name is participant as the second column indicates. Further, the user John is also assigned the role of being "manager".

The fourth column comprises the external backend system roles which are defined at the backend system and the inventional mapping 60 to community roles of the portal collaborative application 12:

Here, Bob, Alice, Jane, Jack and John have a so-called "reader" role, whereas John is assigned the so-called "admin" role, i.e. John has some privileged administration rights in relation to Bob, Alice, Jane and Jack who have just reading rights .

The most right column reflects the respective portal permissions for the homepage, for the backend page and for a specific portlet on the backend page, say the portlet backend access. For these data objects Bob, Alice, Jane and Jack as well as John have a view permission. So with this view permission those users are enabled to view the homepage, the backend page and the portlet of backend access.

Further, the privileged user John has editor rights to the homepage, to the backend page as well as to the backend management portlet. This is depicted in the second row of the most right column.

As reveals from the fourth column the attribute "sufficient" is provided as an aggregated attribute combining the permissions of the backend system and the permissions of the portal system. So the attribute sufficient reflects the mapping of community roles to external system roles. This mapping is preferably done by the administration user, here John, during an initial application setup. In a variation of this embodiment, this is done also automatically based on certain keywords, wherein the rules according to which the access attribute "sufficient" is defined, are simply defined in a programmed form. The respective control program is then run once during an initial application setup.

With reference back to the "sufficient" attribute the sufficient attribute is interpreted such that the "reader" access rights at the backend system imply an assignment to the "Participant" community role and thus the view permissions on the respective pages and portlet at the portal server. As a consequence, when for example user Clarice is assigned to the "reader" role at the backend system, she is automatically assigned to the "Participant" community role and thus has the view permissions on the homepage, the backend page, and the backend Access portlet.

Further, the same attribute "sufficient" is evaluated for user John who has even more privileged access rights at the backend system.

For a more detailed reference the external system roles are summarized in the right bottom part of figure 6, wherein the name of the external system backend, a role name within this system, i.e. reader or admin, and the assigned principles are depicted.

A skilled reader will appreciate that an additional mapping between the persons or the names respectively, as they are used at the portal sight and at the backend system sight, respectively must be implemented. In this mapping for example John is mapped to John Wayne, Bob is mapped to Bob Jackson 23. A further user denoted as ChrisDRLabtor only exists at the backend system and is not configured at the portal server system. Also Alice, Jane and Jack, as well as John, are assigned principles of the backend system having the reader role. This however is not depicted in the drawing in order to increase clarity thereof.

With further reference to figure 7 the control flow followed by evaluating the question if a special user is member of a special community role is depicted. This control flow is followed in particular for making the decision which leads to granting an access or to denying the access to the desired request target of the backend system.

Before entering into the details of the control flow depicted in figure 7 a further access right attribute "required" usable preferably together with the before mentioned attribute "sufficient" and a further attribute "optional" is described as follows :

Each community role has an associated dependency specification. Preferably, the default dependency specification or attribute as mentioned before, is "optional". The respective attribute or dependency specification defines how to evaluate a voting of each mapped component role in analogy to a JAAS login module voting.

Preferably the following semantics are implemented:

A specific user, such as Bob, Alice or John, is member of a community role if and only if Bob is assigned this community role in the portal server environment and all role mappings of this community role are flagged as "optional", or

the community role contains one or more "sufficient" role mappings, and Bob is reported as being assigned to at least one of them by at least one of the involved business components, or

Bob is assigned the community role in the portal server and all involved components report Bob as being assigned to all the roles that are mapped to the community role with the dependency specification "required".

In order to improve the clarity of this dependency definition, further details are given as follows:

Access to applications and application specific resources is granted through community roles which are administrated through the portal system. Dependent on the mapping of those community roles to backend specific roles and a given dependency definition for each mapping, the effective access rights of a user can be extended or reduced.

A 'sufficient' role mapping grants a user additional access rights on the portal side, if the user is not member of the community role.

A ^λrequired' role mapping may reduce the effective access rights as it requires granted access rights through a role mapping not only on the portal system but also on the backend system.

An ^λoptional' role mapping leaves the access rights on the portal side unchanged by the access rights on the backend system. If the user does have the right to issue a specific action on the portal side which is not granted on the backend system, this must be handled by the application. Access rights on both systems have to be administrated separately and synchronized.

A more detailed description of the control flow inside the control logic 40 of the collaborative infrastructure is given as follows :

For each community role that is available in an application, the control component 40 (figure 4) checks, if the current user is assigned to a given role.

The user can either be directly assigned through a community role assignment in the portal system, or indirectly through a role assignment in the external system, see the "sufficient" check of step 710, 730 and step 750.

If external role mappings are flagged as required, see steps 720, 730, and 770 - both role mappings have to exist. This strengthens security in the overall system.

Figure 8 illustrates a first use case and respective steps enumerated 1 to 5 of the control flow performed by an inventional control program, wherein a new user is defined in the backend system in the backend admin role. This role is marked with the "sufficient" attribute in the portal server business component role definition. Once this definition is given, this new member is automatically assigned to the Manager role of the application at the portal side.

In step 1 a request is received that Mary wants to access the application .

In step 2 and 3 it is checked that the Portal community component does not have a community role assigned to Mary in the portal. So, user Mary does not have a permission to access the application.

In step 4 the backend system returns the information that Mary is assigned to the backend ADMIN role.

In step 5 the backend Admin role is translated to the community role "Manager": As the Manager role has a "sufficient" role mapping to the backend ADMIN role, Mary is virtually assigned to the Manager role in the application and is now allowed to access.

In figure 9 a further use case is depicted in which a member is removed from the backend admin role. This is preferably implemented just by using the "required" attribute at the portal server side.

In step 1 a request is received that Lucas wants to access the application .

In step 2 and 3 it is proved that the Portal community component does have a community role Manager assigned to Lucas in portal. So, Lucas has the permission to access the application .

In step 4 the backend system returns the information that

Lucas is "not" assigned to any backend role.

In step 5, as the Manager role has a "required" role mapping to the backend ADMIN role, Lucas is virtually removed from the

Manager community role in portal. The access request is then rejected.

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 a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.

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.

The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. 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.

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. 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 .

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.

Claims

C L A I M S

1. A method for configuring access rights to resources used by both, a portal composite application (12) (CA) of a portal server (10) and a backend computer system (30) related to said composite application, characterised by the steps of: a) automatically generating a mapping (60) transforming the access rights valid at the backend computer system to the portal business component corresponding to the backend system, wherein the mapping maps specific data structures required for the definition of the access rights at the backend system to a valid definition of access rights to the business component at the portal side, b) using (510,...54O) said mapping during runtime for controlling the access rights for user actions targeting to view or edit the resources of the backend system via a respective portlet of the composite application.

2. The method according to claim 1, wherein the step of generating the mapping (60) is triggered automatically when at said portal application roles of the portal application are initiated.

3. The method according to claim 1, wherein status information relating to the access rights of a given user role is controlled if predefined events occur, or, if access rights to certain resources are granted.

4. The method according to claim 1, wherein a group of attributes is defined, and the group members define a respective different quality of the access rights.

5. The method according to the preceding claim, wherein a "required" attribute is used for defining an access configuration in which the access to said backend system resource is required for controlling the respective portal ressources.

6. The method according to claim 5, wherein a "sufficient" attribute is used for defining an access configuration in which the access to said backend system resource is sufficient for controlling the respective portal ressources .

7. The method according to claim 5, wherein a "optional" attribute is used for defining an access configuration in which the access to said backend system resource is not required for controlling the respective portal resources .

8. An electronic data processing system for configuring access rights to resources used by both, a portal composite application (12) (CA) of a portal server (10) and a backend computer system (30) related to said composite application having a functional component for performing the sps of: a) automatically generating a mapping (60) transforming the access rights valid at the backend computer system to the portal business component corresponding to the backend system, wherein the mapping maps specific data structures required for the definition of the access rights at the backend system to a valid definition of access rights to the business component at the portal s ide , b) using (510,...54O) this mapping during runtime for controlling the access rights for user actions targeting to view or edit the resources of the backend system via a respective portlet of the composite application.

9. A computer program product comprising a computer useable medium including a computer readable program, wherein the computer readable program includes a functional component that when executed on a computer causes the computer to perform the steps of: a) automatically generating a mapping (60) transforming the access rights valid at the backend computer system to the portal business component corresponding to the backend system, wherein the mapping maps specific data structures required for the definition of the access rights at the backend system to a valid definition of access rights to the business component at the portal side, b) using (510,... 540) this mapping during runtime for controlling the access rights for user actions targeting to view or edit the resources of the backend system via a respective portlet of the composite application.