System for managing authorizations for access to exposed services

Abstract

The invention relates to a system (S) for managing authorizations for access to exposed services (ED). The system (S) has a management unit (VE) for managing authorizations for access, at least one exposed service (ED), and an authorization-for-access determination unit (ZBE), wherein: the management unit (VE) is designed to receive a request for starting an overall application (GA) which consists of at least one component (CI); the overall application (GA) has a description file which is required for starting and which contains at least one reference to the at least one exposed service (ED); and the management unit (VE) is also designed to request, from the authorization-for-access determination unit (ZBE), an authorization for access to the at least one exposed service (ED) for the overall application (GA), to receive an application-specific and / or environment-specific authorization for access from the authorization-for-access determination unit (ZBE), and to start the overall application (GA) using the received authorization for access. Said system makes it possible to grant overall applications authorizations for access dynamically, on the basis of the current application-specific and environment-specific conditions, and centrally.

Description

[0001] Description

[0002] System for managing access permissions to exposed services

[0003] The present invention relates to a system for managing access authorizations to exposed services. Furthermore, the present invention relates to a method for managing access authorizations to exposed services. Furthermore, the present invention relates to a computer program product that initiates the execution of the method for managing access authorizations to exposed services on a program-controlled device.

[0004] In the area of ​​container visualization, container instances in centrally managed environments can be assigned so-called service accesses or service accounts, which allow the instances operating in the respective container to log in to a network-exposed application programming interface (API), generally referred to as an exposed service. When using such a service account, the orchestrator or management unit issues an access token to the container instance. The access token can then be used by the container instance to log in to the exposed service.

[0005] If a container instance needs to be granted access to a service centrally managed by the Orchestrator, requesting container instances can authenticate to this service using the service accounts mentioned above (see, for example, https: / / kubernetes.io / docs / tasks / configure-pod-container / configure-service-account / ). In the case of a Kubernetes API server, the assignment of access permissions or access tokens is implemented using the Kubernetes Role-Based Access Control system (https: / / kubernetes.io / docs / reference / access-authn-authz / rbac / ). The Orchestrator then performs the appropriate authorization for each service account.However, when launching an application, the individual container instances contained in the application must be assigned to a service account manually by adjusting the deployment configuration, also referred to as the description file or startup description information. The operator of the managed infrastructure must create and activate additional permissions for the respective service accounts using appropriate RBAC (role-based access control) configurations. It should be noted that regardless of the grammatical gender of a particular term, this includes persons with male, female, or other gender identities.

[0006] Container-based edge computing ecosystems exist in industrial environments. They use Docker Compose files and the container images referenced therein to define complete, standalone applications similar to a smartphone app. Such applications can be installed on a customer-specific runtime environment and reference existing services there. These services can either be centrally deployed by the execution environment or deployed by other apps. If applications from different vendors access a common exposed service or API service managed by a central management system or orchestrator, the problem arises that the app provider can independently assign arbitrary access privileges to the exposed service.

[0007] Entire applications, which can consist of multiple components, so-called container instances (possibly including the service account and access permissions of the exposed or remote service), can be deployed using so-called Helm charts (see https: / / helm.sh). All resources required to operate the components are distributed or deployed as an application bundle, hereinafter referred to as the entire application. In this case, the Helm chart is usually provided by the application provider and is only parameterized by the operator using appropriate transfer parameters. The operator does not perform any granular adjustments to the permissions or a graded check of the trustworthiness of an application and the resulting graded assignment of access permissions to a specific service.

[0008] Deployment configuration requirements can be checked and validated in solutions such as Kubernetes using dedicated admission controllers (see, for example, https: / / kubernetes.io / docs / reference / access-authn-authz / admission-controllers / ). A well-known variant is OPA-Gatekeeper (https: / / github.com / open-policy-agent / gatekeeper-library). This allows the operator of a platform to define requirements for settings within the deployment configuration that must be met by the user or application provider who implements the deployment configuration.

[0009] In edge computing ecosystems, an OpenPolicyAgent solution (see https: / / www.openpolicyagent.org) can be used. This informs the user who deploys an Industrial Edge app via Industrial Edge Management about which checks were performed and the results. The status of an individual check can be Allow, Warn, or Block. However, the OpenPolicyAgent only checks or monitors whether the deployment configurations meet predefined criteria. It does not, however, assign user permissions based on this.

[0010] Against this background, one object of the present invention is to provide a way to automatically provide access authorizations to exposed services for entire applications, wherein the access authorizations are adapted to the respective current conditions and specifications.

[0011] Accordingly, a system for managing access permissions to exposed services is proposed.

[0012] The system has a management unit, the so-called orchestrator, for managing access authorizations, at least one exposed service, and an access authorization determination unit. The management unit is designed to receive a request to start an overall application. The overall application, also called an application bundle, consists of at least one component, i.e. at least one application, which can be designed as a container, or container instances. The overall application has a description file required for starting, the so-called deployment configuration or start description information, which includes at least one reference to the at least one exposed service. The exposed service can be, for example, an API server or the exposed service of any other app.The description file can contain one or more references, where one reference can refer to several exposed services or several references can refer to the same exposed service.

[0013] The management unit is further configured to request an access authorization, also called an access token, to the at least one exposed service for the overall application from the access authorization determination unit, to receive an application- and / or environment-specific access authorization from the access authorization determination unit, and to start the overall application using the received access authorization.

[0014] The respective unit, for example, an access authorization determination unit or a management unit, can be implemented in hardware and / or software. In a hardware implementation, the respective unit can be embodied as a device or as part of a device, for example, as a computer or a microprocessor or as a control unit on a server, a host system, or the like. In a software implementation, the respective unit can be embodied as a computer program product, as a function, as a routine, as part of a program code, or as an executable object.

[0015] The proposed system therefore makes it possible for a central administration unit to review the description file of the entire application during the installation process of a containerized application, the entire application, and, based on this, to assign access authorization to at least one referential exposed service to the entire application. The access authorization is created dynamically based on the respective overall application and the orchestrated environment. This means that the access authorization is adapted to the respective current overall application. Furthermore, the access authorization is created centrally by the administration unit and the access authorization determination unit, thus preventing the provider or user of the overall application from assigning themselves access rights to the exposed service.

[0016] According to one embodiment, the access authorization determination unit is configured to retrieve access authorizations from a database that correspond to policies predefined for the at least one exposed service, wherein the policies are stored in the database. The database can be any database that is provided separately from the management unit and the access authorization determination unit. Alternatively, the database can also be integrated into the access authorization determination unit.

[0017] Policies can be predefined for the exposed service that specify which access permissions are intended for the exposed service. In this way, it can be defined in advance which access permissions exist for which exposed service and under which circumstances, i.e., application- and environment-specific, these access permissions are granted. It should be noted that an access permission generally allows access to at least one exposed service, but the scope of this access permission can be adapted based on the policies. When granting access permission, a comparison of the entire application or its description file and the orchestrated environment can be made with the predefined policies. In this way, a dynamic access permission is granted that is adapted to the specific overall application and environment.

[0018] According to a further embodiment, the access authorization determination unit is configured to update the access authorization for the entire application when the predefined policies are updated. If the policies are updated, this can be transmitted to the management unit, which can then transmit an updated access authorization to the entire application. This ensures that the access authorization granted to the entire application always complies with the currently valid policies.

[0019] According to a further embodiment, the access authorization comprises one or more access privileges. The access privileges can be individual access rights. An access authorization can thus consist of several individual access rights, allowing a detailed design of the access authorization. This means that an access authorization can allow very precisely specified access to various subcomponents of the exposed service by adapting several individual access rights.

[0020] According to the invention, the management unit is designed to create a service access to the at least one exposed service for the overall application based on the received access authorization and to assign the service access to the overall application. Thus, if the access authorization, possibly with corresponding access rights, for the overall application has been determined by the access authorization determination unit, this can be set up as a service access by a corresponding API call from the management unit. This provides the exposed service with the corresponding information for authorization, i.e., approval or response, of requests from the overall application. The determined service access is then assigned to the overall application and started by a corresponding API call on the management unit.The advantage of using such a service access is that it can be created once and reused by the overall application or other overall applications if necessary.

[0021] Accordingly, according to a further embodiment, the management unit is configured to assign the created service access to other applications with the same access authorization. This allows the required system resources, such as storage and computing capacity, to be reduced. Furthermore, the allocation of service access can be accelerated.

[0022] According to a further embodiment, the management unit is configured to delete the corresponding service access and / or access authorization when the execution of the overall application is stopped or the overall application is uninstalled. By deleting the service access and / or access authorization, access to the exposed service by the overall application can be easily prevented once it is no longer active.

[0023] For example, if the entire application on the execution environment is to be stopped and uninstalled via the administrative unit, the administrative unit can first determine whether individual instances of the overall application or the entire application have been assigned service access rights. If this is the case, the access authorization determination unit can check whether these service access rights were set up by it and deletes the granted authorizations stored in databases, for example, in an RBAC system and / or a service account management system, of the administrative unit, provided they were application-specific (i.e., created only for this application).If service accesses are shared for several deployment configurations / overall applications, these can, for example, only be deleted if no further references exist from other deployment configurations / overall applications and appropriate error handling is carried out by the access authorization determination unit.

[0024] According to a further embodiment, the request to start the overall application includes the description file of the overall application. This description file, i.e., deployment configuration, advantageously contains all data required for starting the overall application as well as the information required for creating access authorization and / or service access. For example, the request to start the overall application can include a reference to the exposed service and a target execution environment of the overall application. This information can be contained either in the request or in the description file in the request. Through the reference to the exposed service, the management unit can grant access authorization for the corresponding service. The target execution environment can, for example, specify the requirements of the desired target runtime environment.

[0025] According to a further embodiment, the request includes properties of the target execution environment and / or desired access privileges. This information can also be contained directly in the request or in the description file. In contrast to some previous systems in which the user, i.e., the creator of the overall application, could grant themselves access authorization, here it is provided that the overall application can specify which access privileges, i.e., access rights, it desires, or for example, requires. The actual selection of the access privileges to be granted, however, is carried out by the administration unit or the access authorization determination unit. In this way, it can be prevented that the overall application is granted access rights that exceed, for example, the access rights stored in the policies.

[0026] The properties of the target execution environment, i.e., runtime environment-specific information, can describe the criticality of the desired execution environment. These can be passed, for example, in the form of well-defined labels to the administration unit or the access authorization determination unit.

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

[0028] According to a further embodiment, the request, either directly or in the description file, includes a signature of the entire application, wherein the access authorization determination unit is configured to determine one or more access privileges for the entire application based on the signature. The signature can define the trust status of the entire application. Based on the signature, the access authorization determination unit can accordingly determine which access rights should be assigned to the entire application.

[0029] According to a further embodiment, the request has one or more vulnerabilities of the overall application, wherein the access authorization determination unit is designed to determine the access authorization based on the vulnerabilities.

[0030] These vulnerabilities may, for example, have been detected when uploading the 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. Such information can be secured for integrity using a signature, for example, and added to the description file by the app store operator or another trusted entity. The vulnerability, the so-called vulnerability status, can be provided either in the form of a score or as a URL that the access authorization determination unit can access to retrieve the latest score.By knowing about these vulnerabilities, access rights can also be adjusted more precisely and only those access rights can be granted that, based on the known vulnerabilities, do not pose a threat to the system.

[0031] According to a further embodiment, the access authorization determination unit is designed to determine the access authorization based on access privileges of the at least one component of the overall application or of instances of the overall application.

[0032] Thus, access authorization is granted or determined not only based on the overall application, but also based on the individual access privileges required by each application or component. Therefore, the individual desired access privileges can be taken into account, as well as the individual access privileges determined based on application- and environment-specific conditions.

[0033] According to a further aspect, a method for managing access authorizations to exposed services is proposed, the method comprising the following steps: receiving a request to start an overall application consisting of at least one component, the overall application having a description file required for starting, which includes at least one reference to at least one exposed service; requesting access authorization to the at least one exposed service for the overall application by a management unit from an access authorization determination unit; receiving an application- and / or environment-specific access authorization from the access authorization determination unit; creating a service access to the at least one exposed service for the overall application based on the received access authorization; and assigning the service access to the overall application.and starting the entire application using the received access authorization.,

[0034] Furthermore, a computer program product is proposed which causes the method as explained above to be carried out on a program-controlled device.

[0035] A computer program product, such as a computer program means, can be provided or delivered, for example, as a storage medium, such as a memory card, USB stick, CD-ROM, DVD, or in the form of a downloadable file from a server in a network. This can be done, for example, in a wireless communications network by transmitting a corresponding file with the computer program product or the computer program means.

[0036] The embodiments and features described for the proposed system apply accordingly to the proposed method.

[0037] Further possible implementations of the invention also include combinations of features or embodiments described above or below with respect to the exemplary embodiments that are not explicitly mentioned. In this case, the person skilled in the art will also add individual aspects as improvements or additions to the respective basic form of the invention.

[0038] Further advantageous embodiments and aspects of the invention are the subject of the dependent claims and the exemplary embodiments of the invention described below. The invention will be explained in more detail below using preferred embodiments with reference to the accompanying figures. Fig. 1 shows a schematic block diagram of a system for managing access authorizations to exposed services;

[0039] Fig. 2 shows a schematic block diagram of the system of Fig. 1 in more detailed view;

[0040] Fig. 3 shows a message flow diagram of a method for managing access authorizations to exposed services in a system according to Fig. 1 or Fig. 2; and

[0041] Fig. 4 shows a schematic flow diagram of the method for managing access authorizations to exposed services according to Fig. 3.

[0042] In the figures, identical or functionally equivalent elements have been given the same reference numerals unless otherwise stated.

[0043] Fig. 1 shows a system S for managing access authorizations to at least one exposed service ED. The system S comprises a management unit VE for managing the access authorizations and an access authorization determination unit ZBE.

[0044] If a user A (shown in Fig. 2) creates an overall application GA, a request can be submitted to the management unit VE to obtain access authorization to the exposed service ED. The overall application GA can consist of one or more components (e.g., applications) or instances and includes a description file required for startup. The description file contains a reference to the exposed service ED for which access authorization is requested.

[0045] As soon as the administrative unit (VE) receives the request, the administrative unit (VE) can request the corresponding access authorization for the entire application (GA) from the access authorization determination unit (ZBE). The access authorization is created both application-specifically and environment-specifically and transferred to the entire application (GA). This application can then be started by the administrative unit (VE) and access the exposed service using the granted access authorization.

[0046] As shown in Fig. 2, in addition to the overall application GA, the management unit VE can manage various applications APP with respective container instances. These applications APP can also be assigned access permissions to the exposed service ED. Each of these applications can run on different runtime environments LZ if it has been started by the management unit VE. After the overall application GA has been started, it can also run on one of the runtime environments LZ. Information about the runtime environment LZ to be used can be included in the request to start the overall application GA or in the description file.

[0047] To create access authorization, the access authorization determination unit (ZBE) can access a policy package (RP). Policies for the exposed service (ED) or for the overall application (GA) can be stored in this package. These policies define the conditions (i.e., properties of the overall application (GA) such as vulnerabilities, instances, desired access rights, etc.) under which access rights are to be assigned to an application. If an access authorization, which can consist of multiple access rights, is assigned to the overall application (GA), the administration unit (VE) can create a service access, for example, via a service access administration unit (DAV), and store it in an access control unit (ZK). The overall application (GA) can then access the exposed service (ED) via this service access.Service access can be assigned either to the overall GA application or to the individual applications, components or container instances in the overall GA application.

[0048] Within the description file, the respective user or creator A (e.g., an app developer) can reference the exposed service ED either directly (by specifying the service name - e.g., API server) or indirectly by specifying a reference (e.g., a specific label). By specifying a shared label, several managed services can later be combined by the administration unit VE. Furthermore, user A can describe in the description file what they consider to be the minimum privileges required for the exposed service ED. If these privileges are not described, the overall application GA can accept the authorizations determined by the access authorization determination unit ZBE.

[0049] To assign the service access described above, user A can define it within the description file or the entire application GA, or the access authorization determination unit ZBE can determine it independently after determining the privileges. The disadvantage of the first method is a possible name collision with other container instances from other apps and also possible conflicts for determined privileges. However, it is advantageous that multiple container instances of different applications can specifically use the same service access names. When automatically providing service access, also called a service account, by the access authorization determination unit ZBE, it is advantageous if no name collisions are generated, but instead are determined in a unique way and generated for each instance.

[0050] If the reference to the exposed service ED is defined globally within the description file or the overall application and the respective container instances, i.e. the components of the overall application GA, are linked therein, a service access can also be unique within an application and shared across multiple instances within the application.

[0051] Fig. 3 shows an example of a method for managing access authorizations as can be carried out by the system S of Figures 1 and 2.

[0052] In step S1, the administrative unit VE first receives the request to create an access authorization. In particular, the request contains the description file of the entire application GA.

[0053] After the request has been submitted to the management unit (VE) for installation, the management unit (VE) detects whether and which references to the exposed service (ED) are contained (S2). In step S3, it passes these references, along with the identified target execution environment (e.g., by providing the Kubernetes namespace of the industrial edge device selected by the operator), to the access authorization determination unit (ZBE). Runtime environment-specific information describing the criticality of the desired execution environment can also be provided. This information can be passed to the access authorization determination unit (ZBE), for example, in the form of well-defined labels.

[0054] After all information has been transferred, the access authorization determination unit validates this ZBE in step S4 against a centrally provided policy package RP, which is implemented, for example, as an OpenPolicyAgent policy package.

[0055] By passing the requirements of the desired target runtime environment, the desired access permissions, and the entire description file or the entire application GA, it can be classified in step S4 which (process) privileges on the runtime environment the individual applications or the instances specified within the entire application GA request. Furthermore, a signature whose trust status is defined within the policy package RP can be present within the metadata of the description file or the entire application GA.

[0056] The validation result can be one or more well-defined authorization profiles known to the creator of the policy package (RP) and within the administrative unit (VE), or alternatively, it can represent access authorizations derived directly for the referenced exposed service (ED), from which an authorization profile can be created directly for the respective service access. For example, multiple validation functions can be executed within the policy package (RP), and these can also yield contradictory results (e.g., contradictory authorization assignments for the privilege "Container runs in the process namespace of the host" or the privilege "Container runs in the network namespace of the host"), since the different privileges requested for the application or individual instances can also occur in combination.

[0057] While it is assumed here that individual, well-defined access profiles do not contradict each other, a result can very well be generated within the RP policy package that allows an access profile in one validation function, but negates it in another validation function. If this occurs, the RP policy package must define whether the installation process of the entire GA application aborts with an error or whether the negation of a profile or, alternatively, its assignment takes priority.

[0058] Once the access authorizations to be assigned for the entire application GA have been determined by the access authorization determination unit ZBE, the service access is set up in the service access management unit DAV in the next step S5. The service access is then mapped to the determined access privileges or access authorizations for the exposed service ED and stored in the access control unit ZK, for example, an RBAC system, in step S6.

[0059] In step S7, the access authorization determination unit ZBE finally reports the successful establishment of the service access to the administrative unit VE and then, in step S8, reports the assignment of the service access and requests the start of the overall application GA by the administrative unit VE.

[0060] In the next step S9, a corresponding API call is made by the

[0061] The management unit VE starts the overall application GA, whereby a container instance CI of the overall application GA is started with the determined service access. The container instance CI can then access the exposed service ED using the service access ED (step S10) or authenticate itself with the exposed service ED using the service access. The exposed service ED, in turn, can verify the authorization of the container instance or service access by querying the access control unit ZK in step S11. If this verification is successful, the exposed service ED can authorize access by the container instance CI in step S12.

[0062] Starting the CI container instance using the service access and the subsequent authorization can be performed for each container instance or application within the overall application. It is also possible for each CI container instance to be assigned its own service access, or for some CI container instances to use the same service access, while other CI container instances use one or more different service accesses.

[0063] If the overall application GA or its container instance CI is to be stopped and / or uninstalled on the execution environment via the administrative unit VE, it is determined whether service accesses have been assigned to individual container instances CI. If this is the case, the access authorization determination unit ZBE checks whether these service accesses were set up by it and deletes the granted authorizations in the RBAC system ZK and in the service access management unit DAV (Service Account Management) of the administrative unit VE, provided these were made app-specifically, i.e. for this overall application or container instance. For service accesses shared across multiple description files / overall applications, these are only deleted if no further references exist from other description files / overall applications and the access authorization determination unit ZBE performs appropriate error handling.

[0064] Fig. 4 shows the process of starting the entire application or generating the service access in the access authorization determination unit (ZBE). The process is first started in step 50.

[0065] If the entire application or the description file and all relevant information (such as exposed service ED, desired privileges, etc.) have been transferred to the access authorization determination unit ZBE in steps S3 and S4, and this unit has determined the privileges or access rights based on the existing policies, a check is carried out in step S4a to determine whether there is a conflict among the determined privileges, as described above. If there is no conflict, the access authorization determination unit ZBE continues with steps S5 and S9 described above. Otherwise, an error message is output in step S4b, as also described above. The method then ends in step S13 or begins again at step S0.

[0066] If a new policy package (RP) is provided, it can be applied exclusively to newly installed containerized applications (GA), can be validated directly during the update and lead to an update of the service access authorizations, or it can perform a validation and issue an error message to the operator regarding non-conformity of the applications (GA, APP) running on it, which the platform operator must take into account within a certain time.

[0067] For the last two variants, the validation information required for validation must be available to the administrative unit (VE) or the access authorization determination unit (ZBE) independently of the application import process, so that the latter can perform the validation when importing a new policy package (RP). The policy package (RP) can, in principle, be provided centrally by the platform manufacturer or generated on a customer-specific basis.

[0068] As already described, permissions for the exposed service ED can be derived and configured application-specifically for each container instance CI of the overall application GA using an environment-specific policy package RP. If conflicting derived privileges are identified during the evaluation, either the evaluation is aborted (see, for example, step S4b in Fig. 4) or, according to the policy package RP, it is determined whether the most or least restrictive setting is used.

[0069] Individual nodes or execution environments within a centrally managed service can be classified differently, so that container instances CI within the same cluster can be authorized differently on a node-specific basis.

[0070] Within the description file or the metadata of the overall application (GA), the developer can set the minimum required access for the exposed service (ED) for each CI instance. If this minimum required access cannot be configured by the administrative unit (VE), a corresponding error message can be issued during deployment. The exposed services (ED) referenced by a container CI instance can either be referenced directly or divided into individual classes. If the latter is the case, the classes are assigned to the actually required services by the administrative unit (VE).

[0071] The service access for a container instance CI can either be specified by the developer of the overall application GA or dynamically generated and uniquely assigned by the administration unit VE during the installation process.

[0072] Although the present invention has been described using exemplary embodiments, it can be modified in many ways.

[0073] List of reference symbols

[0074] A user

[0075] APP application

[0076] Cl Container Instance DAV Service Access Management Unit

[0077] ED Exposed Service

[0078] GA overall application

[0079] LZ runtime environment

[0080] RP Guideline Package S System

[0081] VE administrative unit

[0082] ZBE access authorization management unit

[0083] ZK access control unit

[0084] S0-S13 procedural steps

Claims

Patent claims 1. System (S) for managing access authorizations to exposed services (ED), comprising a management unit (VE) for managing access authorizations, at least one exposed service (ED), and an access authorization determination unit (ZBE), wherein the management unit (VE) is designed to receive a request to start an overall application (GA) consisting of at least one component (CI), wherein the overall application (GA) has a description file required for starting, which includes at least one reference to the at least one exposed service (ED), - to request from the access authorization determination unit (ZBE) an access authorization to at least one exposed service (ED) for the overall application (GA), - to obtain an application- and / or environment-specific access authorization from the access authorization determination unit (ZBE), to create a service access to the at least one exposed service (ED) for the overall application (GA) based on the received access authorization and to assign the service access to the overall application (GA), and to start the overall application (GA) using the received access authorization.

2. System according to claim 1, characterized in that the access authorization determination unit (ZBE) is designed to retrieve access authorizations from a database (RP) which correspond to predefined guidelines for the at least one exposed service (ED) which are stored in the database (RP).

3. System according to claim 2, characterized in that the access authorization determination unit (ZBE) is designed to update the access authorization for the entire application (GA) when the predefined guidelines are updated.

4. System according to one of the preceding claims, characterized in that the access authorization comprises one or more access privileges.

5. System according to claim 1, characterized in that the administration unit (VE) is designed to assign the created service access to further overall applications (GA) with the same access authorization.

6. System according to claim 1 or 5, characterized in that the management unit (VE) is designed to delete the corresponding service access and / or the access authorization when the execution of the overall application (GA) is stopped or the overall application (GA) is uninstalled.

7. System according to one of the preceding claims, characterized in that the request to start the overall application (GA) comprises the description file of the overall application (GA).

8. System according to one of the preceding claims, characterized in that the request to start the overall application (GA) comprises the reference to the exposed service (ED) and a target execution environment of the overall application (GA).

9. System according to one of the preceding claims, characterized in that the request comprises properties of the target execution environment (LZ) and / or desired access privileges.

10. System according to one of the preceding claims, characterized in that the request has a signature of the overall application (GA), wherein the access authorization determination unit (ZBE) is designed to determine one or more access privileges for the overall application (GA) based on the signature.

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

12. System according to one of the preceding claims, characterized in that the access authorization determination unit (ZBE) is designed to determine the access authorization based on access privileges of the at least one component (CI) of the overall application (GA) or of instances (CI) of the overall application (GA).

13. A method for managing access authorizations to exposed services (ED), the method comprising the following steps: Receiving (S1) a request to start an overall application (GA) consisting of at least one component (CI), wherein the overall application (GA) has a description file required for starting, which includes at least one reference to at least one exposed service (ED), Requesting (S3) an access authorization to the at least one exposed service (ED) for the overall application (GA) by an administration unit (VE) from an access authorization determination unit (ZBE), Obtaining (S7) an application- and / or environment-specific access authorization from the access authorization determination unit (ZBE), based on the received access authorization, to create a service access to the at least one exposed service (ED) for the overall application (GA) and to assign the service access to the overall application (GA), and Starting (S9) the overall application (GA) using the received access authorization.

14. A computer program product which causes the method according to claim 13 to be carried out on a program-controlled device.

Images