System for managing access rights to exposed services

Abstract

This invention relates to a system (S) for managing access permissions to exposed services (EDs). The system (S) includes: a management unit (VE) for managing access permissions, at least one exposed service (ED), and an access permission determination unit (ZBE). The management unit (VE) is configured to receive a request to launch a general application (GA), the general application comprising at least one component (CI), the general application (GA) having a description file required for launch, the description file including at least one reference to the at least one exposed service (ED), and the management unit (VE) is further configured to request access permissions for the at least one exposed service (ED) from the access permission determination unit (ZBE), obtain application-specific and / or environment-specific access permissions from the access permission determination unit (ZBE), and launch the general application (GA) using the obtained access permissions. This system allows for the centralized granting of access permissions to the general application dynamically based on current application-specific and environment-specific conditions.

Description

Technical Field

[0001] This invention relates to a system for managing access permissions to exposed services. Furthermore, this invention relates to a method for managing access permissions to exposed services. Additionally, this invention relates to a computer program product that causes the execution of the method for managing access permissions to exposed services on a program-controlled device. Background Technology

[0002] In the field of container visualization, in a centrally managed environment, so-called service access or service accounts can be assigned to container instances. With a service access or service account, the instance running in the corresponding container can log in to a programming or user interface (API) exposed over the network (hereinafter collectively referred to as an exposed service). When using such a service account, an orchestrator or snap-in issues an access token to the container instance. The container instance can then use this access token to log in to the exposed service.

[0003] To assign access permissions to a container instance for a service centrally managed by the orchestrator, the requesting container instance can authenticate to the service using the service account mentioned above (see, for example, https: / / kubernetes.io / docs / tasks / configure-pod-container / configure-service-account / ). In the case of the Kubernetes API server, access permissions or access tokens are assigned using the Kubernetes role-based access control system (https: / / kubernetes.io / docs / reference / access-authn-authz / rbac / ). In this case, the orchestrator then performs the corresponding authorization for each service account. However, when launching an application, the assignment of service accounts to the individual container instances within the application must be done manually by adjusting the deployment configuration (hereinafter also referred to as the descriptor file or startup descriptor information), and the operator of the managed infrastructure must generate and activate additional permissions for the corresponding service accounts using the appropriate RBAC (role-based access control).

[0004] It should be noted that regardless of the grammatical gender of a particular term, it includes people of all genders.

[0005] In industrial environments, there exists a container-based edge computing ecosystem where complete, standalone applications, similar to smartphone apps, are defined using Docker-Compose files and the container images they reference. These applications can be installed in a customer-specific runtime environment and can reference services already existing within that runtime environment. These services can be centrally provided by the execution environment or provided by other apps. If applications from different manufacturers now access shared exposed services or APIs managed by a centralized management system or orchestrator, the following problem arises: app providers can arbitrarily assign themselves arbitrary access privileges to access those exposed services.

[0006] A monolithic application or application (potentially including service accounts and access permissions for the exposed or remote services) can be imported using so-called Helm Charts (see https: / / helm.sh). Here, all resources required to run these components are distributed or deployed as an application package or application bundle (hereinafter referred to as the monolithic application). In this case, the Helm Chart is typically provided by the application provider and parameterized only by the operator using the corresponding delivery parameters. In this scenario, the operator does not perform any granular adjustments to permissions, nor does it perform hierarchical checks on application trustworthiness or the resulting hierarchical allocation of access permissions to specific services or services.

[0007] In solutions like Kubernetes, deployment configuration requirements can be checked and validated, for example, using its own admission controller (see https: / / kubernetes.io / docs / reference / access-authn-authz / admission-controllers / ). A known variant is OPA-Gatekeeper (https: / / github.com / open-policy-agent / gatekeeper-library). In this case, the platform operator can define requirements for settings within the deployment configuration, and users or providers of applications importing that configuration must meet these requirements.

[0008] In the edge computing ecosystem, the OpenPolicyAgent solution (see https: / / www.openpolicyagent.org) can be used. Users importing industrial edge apps through industrial edge management will be informed of which checks are performed and what results they provide. The status of individual checks can then be allowed, warned, or blocked. However, OpenPolicyAgent only checks or monitors whether the deployment configuration conforms to predefined standards. No user permission settings derived from this are applied. Summary of the Invention

[0009] In this context, one objective of the present invention is to provide the possibility of automatically providing access permissions to exposed services for an overall application, wherein such access permissions are adapted to their respective current conditions and presets.

[0010] Therefore, a system for managing access permissions to exposed services is proposed.

[0011] The system has a management unit (i.e., an orchestrator) for managing access permissions, at least one exposed service, and an access permission determination unit. The management unit is configured to receive a request to launch the entire application. This entire application, also known as an application package, consists of at least one component, namely at least one application or container instance that can be constructed as a container. The entire application has a description file (i.e., a deployment configuration or startup description information) required for launch, which includes at least one reference to the at least one exposed service. The exposed service may, for example, be an API server or a service exposed by any other app. Here, the description file may have one or more references, where one reference may point to multiple exposed services, or multiple references may point to the same exposed service.

[0012] Furthermore, the management unit is configured to request access rights (also known as access tokens) for the at least one exposed service from the access rights determination unit for the overall application; obtain application-specific and / or environment-specific access rights from the access rights determination unit; and launch the overall application using the obtained access rights.

[0013] The corresponding unit (e.g., an access permission determination unit or a management unit) can be implemented using hardware and / or software technologies. When implemented using hardware technologies, the corresponding unit can be constructed as an apparatus or part of an apparatus, such as a computer or microprocessor, or a control unit on a server, host system, or similar device. When implemented using software technologies, the corresponding unit can be constructed as a computer program product, function, routine, part of program code, or executable object.

[0014] Therefore, the proposed system enables a central management unit to examine the description file of the containerized application (i.e., the monolithic application) during its installation process and, based on this, assign access permissions to the monolithic application for at least one referenced exposed service. Here, access permissions are dynamically created based on the respective monolithic application and orchestration environment. This means that access permissions adapt to their respective current monolithic applications. Furthermore, the centralized creation of access permissions by the management unit and the access permission determination unit prevents the monolithic application provider or user from arbitrarily assigning access rights to the exposed service.

[0015] According to one embodiment, the access permission determination unit is configured to retrieve access permissions from a database that conform to a predefined policy for the at least one exposed service, wherein the policy is stored in the database. This database can be any database set up separately from the management unit and the access permission determination unit. Alternatively, the database can also be integrated into the access permission determination unit.

[0016] Policies can be predefined to specify which access permissions are granted to an exposed service. In this way, it's possible to predefine which access permissions exist for which exposed service, and under what circumstances (i.e., application- and environment-specific) these permissions are granted. It should be noted that access permissions generally allow access to at least one exposed service, but the scope of these permissions can be adjusted based on policies. Therefore, when granting access permissions, the entire application or its description file and orchestration environment can be compared with the predefined policies. In this way, dynamic access permissions are granted, adapted to the specific application and environment.

[0017] In another implementation, the access permission determination unit is configured to update the access permissions of the entire application when a predefined policy is updated. If the policy is updated, this can be transmitted to the management unit, which can then transmit the updated access permissions to the entire application. This ensures that the access permissions granted to the entire application always conform to the currently valid policy.

[0018] In another implementation, the access permission includes one or more access privileges. This access privilege can be a single access right. Therefore, an access permission can consist of multiple individual access rights, allowing for detailed design of the access permission. This means that by adjusting multiple individual access rights, the access permission can allow for very precise specification of access to different sub-components of the exposed service.

[0019] According to the present invention, the management unit is configured to create service access for the at least one exposed service for the overall application based on the obtained access permissions, and to assign the service access to the overall application. Therefore, if the access permission determination unit determines the access permission (possibly with corresponding access rights) for the overall application, the management unit can set the access permission as service access via the corresponding API call. Thus, the exposed service obtains the corresponding information for authorizing (i.e., releasing or responding to) requests from the overall application. Subsequently, the determined service access is assigned to the overall application, and the overall application is started at the management unit via the corresponding API call. The advantage of using this service access is that it can be created once and reused by the overall application or other overall applications when needed.

[0020] Accordingly, in another implementation, the management unit is configured to allocate created service access to other monolithic applications with the same access permissions. In this way, the resources required by the system (such as storage and computing power) can be reduced. Furthermore, the allocation of service access can be accelerated.

[0021] In another implementation, the management unit is configured to delete the corresponding service access and / or access permissions when the monolithic application is stopped or uninstalled. Once the monolithic application is no longer active, deleting the service access and / or access permissions provides a simple way to prevent the monolithic application from accessing exposed services.

[0022] For example, if the monolithic application is to be stopped and uninstalled via the management unit on the execution environment, the management unit can first determine whether service access has been assigned to the monolithic application or its individual instances. If so, the access control unit can check whether these service accesses were set by it, and if they are application-specific (i.e., created only for that application), delete the granted permissions stored in the management unit's database (e.g., in the RBAC system and / or service account management). If the service accesses are shared across multiple deployment configurations / monolithic applications, these service accesses can only be deleted, for example, if there are no other references made through other deployment configurations / monolithic applications, and the corresponding error handling has been performed by the access control unit.

[0023] In another embodiment, the request to launch the monolithic application includes a description file for that monolithic application. Advantageously, this description file (i.e., the deployment configuration) contains all the data required to launch the monolithic application, as well as the information needed to create access permissions and / or service access. For example, the request to launch the monolithic application may have references to exposed services and the target execution environment of the monolithic application. This information may be included in the request or in a description file within the request. By referencing the exposed services, the management unit can grant access permissions for the corresponding services. The target execution environment may, for example, indicate the requirements of the desired target runtime environment.

[0024] In another implementation, the request includes attributes of the target execution environment and / or desired access privileges. This information can also be directly included in the request or description file. Unlike some previous systems where users, i.e., the creators of the monolithic application, can grant access permissions themselves, this specifies that the monolithic application can indicate which access privileges (i.e., access rights) it expects (e.g., needs). However, the actual selection of the access privileges to be granted is performed by the management unit or access permission determination unit. In this way, granting access rights to the monolithic application beyond those stored in, for example, policies can be prevented.

[0025] The attributes of the target execution environment (i.e., runtime environment-specific information) can describe the criticality of the desired execution environment. This information can be passed to the management unit or access control unit, for example, in the form of clearly defined labels.

[0026] Based on the requirements of the desired target runtime environment, the desired access permissions, and other information about the overall application, it is possible to categorize, for example, which (process) privileges on the runtime environment are requested by individual applications within the overall application or by specific instances within the overall application. In this way, access permissions can be tailored very specifically to the corresponding overall application and its requirements.

[0027] In another embodiment, the request (directly or in a description file) has a signature of the entire application, wherein the access control unit is configured to determine one or more access privileges for the entire application based on the signature. The signature may define the trust state of the entire application. Based on the signature, the access control unit may correspondingly determine which access rights should be assigned to the entire application.

[0028] According to another embodiment, a request is made for one or more vulnerabilities in the overall application, wherein an access control unit is configured to determine access rights based on the vulnerabilities.

[0029] These vulnerabilities might be detected, for example, when uploading a description file or the entire application to a central app store. These detected vulnerabilities can then be integrated into the request, for example, as metadata in the description file. This information can be secured for integrity, for example, through a signature, and added to the description file by the app store operator or other trusted entity. The vulnerability (so-called vulnerability status) can be provided in this case as a score or as a URL, which the access control unit can access to retrieve the latest score. Information about these vulnerabilities allows for more precise adjustment of access rights, granting only access based on known vulnerabilities that will not pose a risk to the system.

[0030] According to another embodiment, the access permission determination unit is configured to determine the access permission based on the access privileges of at least one component of the overall application or the access privileges of an instance of the overall application.

[0031] Therefore, access permissions are granted or determined not only based on the overall application, but also on the individual access privileges required by each application or component. Thus, both desired access privileges and individual access privileges determined based on application- and environment-specific conditions can be considered.

[0032] According to another aspect, a method for managing access permissions to exposed services is proposed, wherein the method includes the following steps: obtaining a request for launching a monolithic application consisting of at least one component, wherein the monolithic application has a description file required for launching, the description file including at least one reference to at least one exposed service; a management unit requesting access permissions for the at least one exposed service for the monolithic application from an access permission determination unit; obtaining application-specific and / or environment-specific access permissions from the access permission determination unit; creating service access for the at least one exposed service for the monolithic application based on the obtained access permissions, and assigning the service access to the monolithic application; and launching the monolithic application using the obtained access permissions.

[0033] Furthermore, a computer program product is proposed that causes the execution of the method described above on a program-controlled device.

[0034] Computer program products, such as computer program mechanisms, may be provided or delivered as storage media such as memory cards, USB flash drives, CD-ROMs, and DVDs, or they may be provided or delivered from a server on a network as downloadable files. This can be done, for example, by transmitting corresponding files containing the computer program product or computer program mechanism over a wireless communication network.

[0035] The implementation forms and features described for the proposed system are correspondingly applicable to the proposed method.

[0036] Other possible implementations of the invention include combinations of features or embodiments not explicitly mentioned in the preceding or following descriptions of the embodiments. Those skilled in the art will also consider various aspects as improvements or additions to the corresponding basic forms of the invention. Attached Figure Description

[0037] Other advantageous designs and aspects of the invention are the subject of the dependent claims and the embodiments described below. The invention is further explained below with reference to the accompanying drawings and preferred embodiments.

[0038] Figure 1 A schematic block diagram of a system for managing access permissions to exposed services is shown. Figure 2 Shown in more detailed view Figure 1 A schematic block diagram of the system; Figure 3 It shows that according to Figure 1 or Figure 2 The message flow diagram of the methods used in the system to manage access permissions to exposed services; and Figure 4 It shows that according to Figure 3 A schematic flowchart of a method for managing access permissions to exposed services. Detailed Implementation

[0039] In the accompanying drawings, unless otherwise specified, the same or functionally equivalent elements are given the same reference numerals.

[0040] Figure 1 A system S for managing access permissions to at least one exposed service ED is shown. System S has a management unit VE for managing access permissions and an access permission determination unit ZBE.

[0041] If user A ( Figure 2 (As shown in the diagram) Once a monolithic application GA is created, a request can be made to the management unit VE to obtain access to the exposed service ED. The monolithic application GA may consist of one or more components (e.g., applications) or instances and includes a description file required for startup. This description file contains references to the exposed service ED for which access is requested.

[0042] Once the management unit VE receives the request, it can request the corresponding access permissions from the access permission determination unit ZBE for the overall application GA. At this point, the access permissions are created not only specifically for the application but also specifically for the environment and are passed to the overall application GA. The overall application can then be started by the management unit VE and access the exposed services through the granted access permissions.

[0043] like Figure 2 As shown, in addition to the overall application GA, the management unit VE can also manage various application APPs, each with its own container instance. These application APPs can also be assigned access permissions to exposed services ED. Each of these applications can run on a different runtime environment LZ if it is launched by the management unit VE. After the overall application GA is launched, it can also run on one of the runtime environment LZs. Information about the runtime environment LZ to be used can be included in the request to launch the overall application GA or in the description file.

[0044] To create access permissions, the Access Determination Unit (ZBE) can access the Policy Package (RP). The Policy Package can store policies for exposed services (EDs) or the overall application general (GA). These policies define what access permissions are assigned to applications under what conditions (i.e., attributes of the overall application GA, such as vulnerabilities, instances, desired access permissions, etc.). If the overall application GA is assigned access permissions that can consist of multiple access rights, the Management Unit (VE) can create a service access (e.g., through the Service Access Management Unit (DAV)) and store it in the Access Control Unit (ZK). The overall application GA can then access the exposed services (EDs) through this service access. Here, the service access can be assigned to the overall application GA, or to individual application, component, or container instances within the overall application GA.

[0045] In the description file, individual users or creators A (e.g., application developers) can directly (by specifying a service name—e.g., an API server) or indirectly by specifying a reference (e.g., a specific tag) to the exposed service ED. Multiple managed services can later be combined by the management unit VE by specifying shared tags. Furthermore, user A can describe in the description file the minimum privileges required from their perspective for the exposed service ED. If these privileges are not described, the overall application GA can accept the permissions determined by the access control unit ZBE.

[0046] Regarding the allocation of the aforementioned service access, the following possibilities exist: User A defines the service access in the description file or within the overall application GA, or the access control unit ZBE independently determines the service access after determining privileges. The disadvantage of the first method is the potential for name conflicts with other container instances from other apps, and conflicts may also occur with the determined privileges. However, the advantage is that multiple container instances from different applications can selectively use the same service access name in this case. However, when the access control unit ZBE automatically provides service access (also known as service accounts), it is advantageous that name conflicts are avoided, and the access is determined and generated for each instance in a clear manner and method.

[0047] If a reference to an exposed service ED is defined globally in a description file or the overall application, and the corresponding container instance (i.e., a component of the overall application GA) is linked therein, service access can also be unique within the application and shared among multiple instances within that application.

[0048] Figure 3 It shows that it can be made by Figure 1 and Figure 2 An example of a method executed by system S for managing access permissions.

[0049] In step S1, the management unit VE first receives a request to create access permissions. In particular, this request contains a description file for the overall application GA.

[0050] After the installation request is passed to the management unit VE, the management unit VE identifies whether and which references to the exposed service ED are included (S2), and in step S3, passes the references along with the determined target execution environment (e.g., by providing a Kubernetes namespace, an industrial edge device selected by the operator) to the access control determination unit ZBE. In this case, runtime-specific information describing the critical aspects of the desired execution environment can be provided. This information can, for example, be passed to the access control determination unit ZBE in the form of well-defined labels.

[0051] After all the information has been transmitted, the access permission determination unit ZBE verifies the information in step S4 by comparing it with the policy package RP provided in the set (e.g., its implementation is the OpenPolicyAgent policy package).

[0052] By conveying the desired requirements of the target runtime environment, the desired access permissions, and the entire description file or overall application GA, step S4 can be used to categorize which (process) privileges each application or instance specified within the overall application GA requests on the runtime environment. Furthermore, a signature may exist within the metadata of the description file or overall application GA, and the trust status of this signature is defined within the policy package RP.

[0053] The verification result here can be one or more explicitly defined permission profiles known to the creator of the policy package RP and the management unit VE, or alternatively, it can represent access permissions directly exported to the referenced exposed service ED, from which permission profiles can be directly created for the corresponding service access. For example, multiple verification functions can be performed within the policy package RP, and these verification functions can also provide contradictory results (e.g., contradictory permission assignments for the privilege "the container runs in the host's process namespace" or the privilege "the container runs in the host's network namespace"), because different privileges requested by the application or individual instances can also be combined.

[0054] Although it is assumed here that the various explicitly defined access profiles are not contradictory, it is indeed possible within the policy package RP to produce the following result: an access profile is allowed in one authentication function, but is denied in another. If this occurs, the policy package RP must define whether the overall application GA installation process should be aborted upon error, or whether the denial of the profile should be prioritized, or alternatively, the allocation of the profile should be prioritized.

[0055] If the access permission determination unit ZBE determines the access permissions to be assigned to the overall application GA, then in the next step S5, service access is set at the service access management unit DAV. Subsequently, the service access is mapped to the determined, exposed service ED's access privileges or access permissions, and stored in the access control unit ZK (e.g., an RBAC system) in step S6.

[0056] In step S7, the access permission determination unit ZBE reports the successful setup of service access to the management unit VE, and in step S8, it subsequently reports the allocation of service access and requests the management unit VE to start the overall application GA.

[0057] In the next step S9, the management unit VE then starts the overall application GA via the corresponding API call, where the container instance CI starts the overall application GA using the determined service access. The container instance CI can then access the exposed service ED via the service access ED (step S10), or authenticate with the exposed service ED using the service access. The exposed service ED can then verify the container instance or service access permissions by querying the access control unit ZK in step S11. If the verification is successful, the exposed service ED can authorize the container instance CI's access in step S12.

[0058] Launching container instance CIs and subsequent authorizations via service access can be performed on each container instance or application as a whole. Each container instance CI can also be assigned its own service access, or some container instance CIs can use the same service access, while other container instance CIs can use one or more other service accesses.

[0059] If the monolithic application (GA) or its container instance (CI) is to be stopped and / or unloaded on the execution environment via the management unit (VE), it is determined whether service access has been assigned to each container instance (CI). If so, the access control unit (ZBE) checks whether these service accesses were set by it and removes the granted permissions in the RBAC system (ZK) and the service access management unit (DAV) of the management unit (VE), provided that the permissions are app-specific (i.e., for the monolithic application or container instance). For service accesses shared across multiple profiles / monolithic applications, they are only removed if there are no further references to other profiles / monolithic applications and the corresponding error handling is performed by the access control unit (ZBE).

[0060] Figure 4 The process of initiating a complete application or generating service access in the Access Permission Determination Unit (ZBE) is illustrated. In step S0, the process is initiated first.

[0061] If, in steps S3 and S4, the entire application or description file and all relevant information (such as exposed services ED, desired privileges, etc.) are passed to the access control determination unit ZBE, and the access control determination unit determines privileges or access rights based on existing policies, then in step S4a, a conflict is checked among the determined privileges, as described above. If no conflict exists, the access control determination unit ZBE continues to execute steps S5 and S9 as described above. Otherwise, an error message is output in step S4b, also as described above. Then, the method ends in step S13 or restarts from step S0.

[0062] If a new policy package (RP) is provided, it can be applied only to newly installed containerized application GA, directly verifying the application during updates and causing service access permissions to be updated, or performing verification and outputting error messages to the operator regarding non-compliance of the application GA or APP running on it. The platform operator must consider the error messages within a specific time.

[0063] For the latter two variants, the verification information required must exist independently of the process of importing the application into the Management Unit (VE) or the Access Determination Unit (ZBE), so that the VE or ZBE can perform verification when importing a new Policy Package (RP). In principle, the Policy Package (RP) can be centrally provided by the platform manufacturer or generated specifically for the customer.

[0064] As mentioned above, environment-specific policy packages (RPs) can be used to export and set application-specific permissions for exposed service privileges (EDs) for each container instance (CI) of the overall application GA. If conflicting exported privileges are identified during the evaluation, they must be terminated (see, for example...). Figure 4 In step S4b), either the most stringent setting or the least certain setting is determined based on the policy package RP.

[0065] The nodes or execution environments within a centrally managed service can be categorized differently, allowing container instances (CI) to be granted different permissions specific to each node within the same cluster.

[0066] Within the overall application GA description file or metadata, developers can set the minimum access required for the exposed service ED for each instance CI. If this minimum access requirement cannot be set by the management unit VE, a corresponding error message can be output during deployment.

[0067] Exposed services (EDs) referenced by container instances (CIs) can be directly referenced or categorized. If the latter, the management unit (VE) assigns the categories to the actual required services.

[0068] Service access for container instance CI can be preset by the developers of the overall application GA, or dynamically generated and uniquely assigned by the management unit VE during the installation process.

[0069] Although the invention has been described in conjunction with embodiments, it can be modified in many ways.

[0070] List of reference numerals User A APP application CI container instance DAV Service Access Management Unit ED exposed services GA Overall Application LZ runtime environment RP strategy package S System VE Management Unit ZBE Access Permission Determination Unit ZK Access Control Unit S0-S13 Method Steps

Claims

1. A system (S) for managing access permissions to an exposed service (ED), comprising: a management unit (VE) for managing access permissions, at least one exposed service (ED), and an access permission determination unit (ZBE), wherein the management unit (VE) is configured as follows: - A request is received to launch a general application (GA), which consists of at least one component (CI), wherein the general application (GA) has a description file required for launch, the description file including at least one reference to the at least one exposed service (ED). - The overall application (GA) requests access rights to the at least one exposed service (ED) from the access permission determination unit (ZBE). - Obtain application-specific and / or environment-specific access permissions from the access permission determination unit (ZBE). - Based on the obtained access permissions, create service access for the at least one exposed service (ED) for the overall application (GA), and assign the service access to the overall application (GA), and - Use the acquired access permissions to launch the overall application (GA).

2. The system according to claim 1, characterized in that, The access permission determination unit (ZBE) is configured to retrieve the following access permissions from a database (RP), the access permissions conforming to a predefined policy for the at least one exposed service (ED), the policy being stored in the database (RP).

3. The system according to claim 2, characterized in that, The access permission determination unit (ZBE) is configured to update the access permissions of the overall application (GA) when a predefined policy is updated.

4. The system according to any one of the preceding claims, characterized in that, The access permissions include one or more access privileges.

5. The system according to claim 1, characterized in that, The management unit (VE) is configured to distribute the created service access to other general applications (GA) with the same access permissions.

6. The system according to claim 1 or 5, characterized in that, The management unit (VE) is configured to delete the corresponding service access and / or access permissions when the overall application (GA) is stopped or uninstalled.

7. The system according to any one of the preceding claims, characterized in that, The request to launch the overall application (GA) has a description file for the overall application (GA).

8. The system according to any one of the preceding claims, characterized in that, The request to launch the overall application (GA) has a reference to the exposed service (ED) and the target execution environment of the overall application (GA).

9. The system according to any one of the preceding claims, characterized in that, The request includes attributes of the target execution environment (LZ) and / or desired access privileges.

10. The system according to any one of the preceding claims, characterized in that, The request has a signature of the overall application (GA), wherein the access control determination unit (ZBE) is configured to determine one or more access privileges of the overall application (GA) based on the signature.

11. The system according to any one of the preceding claims, characterized in that, The request has one or more vulnerabilities in the overall application (GA), wherein the access permission determination unit (ZBE) is configured to determine the access permission based on the vulnerabilities.

12. The system according to any one of the preceding claims, characterized in that, The access permission determination unit (ZBE) is configured to determine the access permission based on the access privileges of at least one component (CI) of the overall application (GA) or the access privileges of an instance (CI) of the overall application (GA).

13. A method for managing access permissions to exposed services (ED), wherein the method comprises the following steps: A request is received (S1) to launch a general application (GA), the general application consisting of at least one component (CI), wherein the general application (GA) has a description file required for launch, the description file including at least one reference to at least one exposed service (ED). The management unit (VE) requests (S3) access rights for the at least one exposed service (ED) from the access permission determination unit (ZBE) for the overall application (GA). Obtain (S7) application-specific and / or environment-specific access permissions from the access permission determination unit (ZBE). Based on the obtained access permissions, create service access for the at least one exposed service (ED) for the overall application (GA), and assign the service access to the overall application (GA). The overall application (GA) is launched (S9) using the acquired access permissions.

14. A computer program product that causes execution of the method according to claim 13 on a program-controlled device.

Images