EP3970337A1

EP3970337A1 - Method for selectively configuring a container, and network arrangement

Info

Publication number: EP3970337A1
Application number: EP20726745.1A
Authority: EP
Inventors: Michael Menth; Frederik HAUSER; Mark Schmidt; Julian RILLI
Original assignee: Eberhard Karls Universitaet Tuebingen
Current assignee: Eberhard Karls Universitaet Tuebingen
Priority date: 2019-05-13
Filing date: 2020-05-13
Publication date: 2022-03-23
Also published as: US20230006988A1; DE102019112485A1; WO2020229537A1

Abstract

The invention relates to a method for selectively configuring a container that contains an application, wherein user-authentication data are received by a container management component and forwarded via a container applicant to an authorisation server. This server transmits an authorisation response, on the basis of which a decision is made as to whether the application is allowed to be run in the container.

Description

Method for the selective execution of a container and network arrangement

The invention relates to a method for selectively executing a container containing an application. The invention also relates to an associated network arrangement.

In general, the problem is considered here to allow users to run specific applications on managed hosts and to give them access to protected network resources. It is known in the prior art to execute applications in containers in order to achieve a certain separation from other applications or operating system components. However, so far there is a lack of further security and access control mechanisms.

It is therefore an object of the invention to provide a method for selectively executing a container containing an application which is alternative or improved compared to known designs. It is also an object of the invention to provide an associated network arrangement. This is achieved according to the invention by a method and a network arrangement according to the respective main claims. Advantageous refinements can

for example, can be found in the respective subclaims. The content of the claims is made part of the description by express reference.

The invention relates to a method for selectively executing a container containing an application, the method having the following steps:

Receiving user authentication data by a

Container management component,

Forwarding the user authentication data to a container submitter,

Sending, by the container applicant, an authorization request to an authorization server, the authorization request containing at least the user authentication data,

Receiving, by the container applicant, an authorization response from the authorization server, the authorization response at least one Contains release information, which can have either a positive or a negative value,

Forward the authorization response to the

Container management component,

Decide, by the container management component, whether the container is to be executed, the container to be executed if the

Release information has a positive value, and the container is not to be executed if the release information has a negative value, only if the container is to be executed, starting and executing the container.

The method according to the invention enables a user to be authorized by an authorization server, which is typically available centrally for a large number of users. This allows different users to be managed centrally, with users being able to be authenticated by the authorization server, for example by accessing identity management servers such as LDAP. There can be security functions such as in particular the authorization or

Execution prevention of a container are provided, which at

State-of-the-art designs are not possible.

In the method, an application is typically an integral part of a container. A container can be viewed as an application with dependencies. The application is typically executed in the container, which represents a suitable environment for the application. Other components of a

Operating systems are typically encapsulated from the application by the container. For example, the container can provide interfaces by means of which the application can access certain resources of the operating system. In this way, such access can be controlled and prevented if there is no authorization.

For example, user authentication data can be a combination of

Show username and password. Other versions of

However, user authentication data is possible. The

For example, user authentication information can be entered manually via a

User interface can be entered or can be made from an automatic or semi-automatic user authentication originate, for example by means of a card or fingerprint recognition, by which for example

User authentication data can be read out automatically from a vault or other memory created for this purpose.

The container management component is typically a software component which takes on administrative tasks for the container and typically runs outside the container. For example, it can start, stop and / or assign resources to the container. The container applicant is

typically a software component that runs outside of the container and communicates directly or indirectly with external components such as the authorization server, for example in order to provide the functionalities described

execute. The authorization request can be in addition to the

User authentication data also contain further data, for example those which are described in more detail below. In addition to the release information, the authorization response can also contain further information, for example that which is described in more detail below. The

Release information can be implemented, for example, in the form of a bit, which can assume two states which are each assigned to a positive or negative value. The container management component can in particular initiate the start of the container with the application.

It should be mentioned that, as far as described so far, the method can basically be carried out on only one electronic component such as a computer or a host. For example, it can also be executed in a virtual host, such as those offered by large data centers. As part of the method, communication takes place with components that can be external to this, for example with the authorization server. Such components can, for example, be located in the same network and communicate with one another accordingly via the network. The following also describes steps that must be carried out on external components such as the authorization server. In this case, it should be understood that the method relates to an arrangement which can also contain several components. According to a preferred embodiment, the authorization server determines the

Release information based at least on the user authentication data. This ensures that only users who correctly

Have user authentication credentials that applications can run in the container. For example, the authorization server can match the user authentication data with a database of authorized users.

In particular, it can be provided that the authorization server

Compares user authentication data with a number of user default values and sets the release information to a positive value only if the

User authentication data correspond to one of the user default values.

As a result, the user default values can be used to determine in a simple manner which users are authorized to run the container. The

For example, user default values can be found on the authorization server

can be saved or can also be obtained externally. It can

be provided that the release information is always set to a positive value when the user authentication data to one of the

Correspond to user default values. However, further criteria can also be provided which must be met for this. For example, the container can also be authenticated, as described further below.

Correspondence between data and default values can basically be understood to mean that the data is exactly identical to the default values, or that the data has a specific relationship to the default values. Such a relationship can be specified, for example, as an equation or an algorithm.

According to a preferred embodiment, the authorization response also contains authentication information. This can be generated, for example, by the authorization server or a component that works with it. The

Authentication information can be used in particular in the event that the

Release information assumes a negative value, so the user is not authorized to provide information about whether the user is authenticated, that is, is known and has identified himself with a correct password. This allows the user to receive feedback on his

To give authentication. For example, this can result in accidental

Incorrect entries are recognized, as in this case a user is not authenticated. In this way, however, feedback can also be given to the user that he is known but not authorized, for example due to a missing booking or other authorization problems.

The container applicant can in particular be an 802.1X supplicant. The

Authorization server can in particular be an 802.1X authorization server. The container management component can in particular be a

Be a container management daemon. As a result, known components for authentication and / or authorization of users can be used which are provided, for example, by the known IEEE 802.1X system. A new development of such components or an additional provision can thus advantageously be avoided. In particular, such systems are often already in place in institutions such as companies or universities

for example to ensure port-based access control. The adaptation of such systems to the method described herein typically only requires a small amount of effort.

The method can in particular have the following step:

Generation of container authentication data depending on the

Container or a container image of the container.

This means that the container can also be subjected to separate authentication. This allows you to specify which containers are allowed to run and prevent other containers from running.

A container image can in particular be a code which is present on a computer or another unit and by means of which the container is generated or executed. The container can thus be generated with the container image, for example. The container image can, for example, from a

Provisioning server to be downloaded.

The method can in particular have the following step:

Sending the container authentication data to the authorization server. This allows the authorization server to use the container authentication data in deciding whether to set the release information to a positive value or to a negative value.

In particular, the authorization request can contain the container authentication data. This allows the

Container authentication data to the authorization server. The

However, container authentication data can also be used in a

Authorization request separate message sent to the authorization server.

According to one embodiment, the method can have the following steps:

Receiving a nonce from the authorization server, and

Modifying the container authentication data based on the nonce before sending the container authentication data to the authorization server.

The nonce can in particular be received by the container management component and / or by the container applicant. They can also make the change. Such a procedure makes it possible to implement a challenge-response procedure. For example, the nonce can be sent to the

Container authentication data are appended and / or taken into account when calculating a checksum. This can be understood as a change. This ensures that only the container management component or only the container applicant can send the container authentication data in such a way that it is recognized as valid by the authorization server. Eventual

Manipulation or sending of such data by a unit that does not know the nonce could be detected by the authorization server.

The container authentication data can in particular be used as a checksum of the

Container or the container image can be determined. This gives a value which can distinguish containers from one another and which makes it possible to identify any changes to a container. A nonce mentioned above can also be included. An example of a calculation of a

Checksum across a container, rather than just a container image, would be a Resource access of a certain container, which can at least be configured in Docker by users (eg “Container A may only use one CPU core”). The calculation of a checksum of the container can, however, also be the calculation of a checksum of the container image.

The checksum can, for example, after receiving the

User authentication data is calculated. In particular, this can relate to receiving the user authentication data by the

Obtain container management components. This allows the checksum

calculated immediately prior to the intended use of the container. This minimizes the risk of any subsequent changes to the container or the container image before it is executed.

According to one embodiment, the container authentication data is a

Identification number of the container. This can for example be specified for each container. The calculation of a checksum can then advantageously be dispensed with.

In this case in particular, but also in general, the

Container management component can be configured to ensure a clear assignment between identification number and container. This will ensure the trustworthiness of the container on the

Relocated container management components, which typically have a high level of reliability anyway.

According to a preferred embodiment, the method also has the following step:

Generating container authentication data as a checksum of the container or a container image of the container, the authorization request containing the container authentication data.

As a result, in addition to the user authentication data, which are intended to uniquely identify a user, the container or the application can also be authenticated. This can, for example, prevent the container or application from running after being accidentally or maliciously modified. The checksum can in particular be created instantaneously or ad hoc when the method is carried out, so that it is basically up-to-date and not later Modification of the container or the application can take place or such a modification would be recognized and lead to a refusal of execution.

The authorization server preferably determines the release information based at least on the container authentication data. This can in particular take place in addition to the user authentication data. The authorization server could use the container authentication data, in particular the checksum, to recognize a possible modification of the container or the application and thus ensure that the application is only executed when it is not in the

Changed compared to an intended version. In particular, the release information can assume the negative value or be set to the negative value by the authorization server if the authorization server based on the

Container authentication data determines that there has been a change in the application or the container.

In particular, the authorization server can compare the container authentication data with a number of container default values and only then set the release information to a positive value if the container authentication data correspond to one of the container default values. The container default values can thus be used to determine which containers or types of containers may be executed. They can be stored on the authorization server or obtained externally.

If the nonce mentioned above is used, the

Authorization servers also calculate a checksum based on the nonce and a container image or container available to it. This enables a comparison to be made as to whether the container authentication data was received from a unit that knows the nonce. Alternatively, for example, checksums in

Authorization server which are assigned to the respective nonces must be stored.

The authorization response can in particular include authorization information

where the application is executed with rights which are determined based on the authorization information. This can be used, for example, to tell different users what different

User authentication data have to assign different rights. For example, certain users can be granted access to certain resources, but others can be denied. The authorization information can in particular be determined by the authorization server, for example based on the user authentication data and / or the container authentication data.

The method preferably also has the following step:

Assigning a network address to the container.

As a result, the container can be uniquely identified, which in particular makes it possible to unambiguously transfer a data stream to or from this container

Streams of data to or from other containers or other components

to delimit. This enables the assignment of certain rights for this data stream. The network address can in particular be an IPv6 address, although other addresses can also be used depending on the implementation.

The network address can in particular be assigned by the container management component. This can for example fall back on suitable address ranges. The authorization request can contain the network address, for example. As a result, other units, for example the container authenticator mentioned below, can be informed of the network address.

Alternatively or additionally, the container management component can use the

Send the network address separately to the authorization request. This can be done in a separate message or notification, for example.

The authorization request can in particular be sent to the authorization server via a container authenticator. The

Authorization response can be received from the authorization server via the container authenticator. The container authenticator is typically an additional component which, for example, is software and / or

in terms of hardware from the component that executes the container and the

Authorization server is disconnected. The container authenticator can add additional

Carry out tasks that are described in more detail below as examples. In particular, the container authenticator can be an 802.1X authenticator, which is the Access to an existing 802.1X system is simplified and extensive

Avoids new developments.

The method preferably also has the following steps:

Generate, by the container authenticator, a network release information based on the authorization request and / or the

Authorization response, and

Sending, by the container authenticator, the network release information to a network control component, wherein the network control component enables or blocks traffic to and / or from the container based on the network release information.

In particular, the method can also have the following steps:

Generate, by the container authenticator, network sharing information based on the authorization response, and

This enables a control of the data traffic from and / or to the container, so that the data traffic can also be controlled as a function of authenticated and / or authorized users. For example, access to certain resources or certain types of traffic can be released for certain users, but blocked for others. In the

The network control component can be, for example, a firewall or an SDN controller, the network control component

typically in terms of software and / or hardware can be distinguished from the other components already mentioned and / or mentioned below. It can also be a server or another computer.

Such an implementation represents an extension of authentication and

Authorization for a configuration of a network control component. According to a preferred embodiment, the authorization server generates the

Authorization response with network share information. The container authenticator can in particular the network release information based on the

Generate network share data. This can take place in the form of an identical transfer of the network release data or after modification. The authorization server can thus also be used to configure the network control component. This makes the configuration easier.

The authorization server can generate the network release data in particular as a function of the user authentication data and / or the container authentication data. This means that users or containers can be addressed individually and specific rights can be assigned.

The network control component can in particular be arranged such that any data traffic to and from the container and / or to and from a protected server is routed through the network control component. This enables complete control of the data traffic to and from the container or to and from a protected server. For example, the container can be shielded and / or the container can with certain

Access rights are provided, which can be controlled by the network control component. In addition, a protected server, which can be present in the network, for example, can be particularly protected against unauthorized access. A protected server can in particular be a server that stores particularly sensitive information or information that is worth protecting.

The network control component can also be a gateway which connects two networks. For example, it can be a gateway between a local network and the Internet. This means, for example, that only the container or only certain containers are allowed to communicate with the Internet, whereas other network elements are only allowed to communicate in the local network.

The container authenticator can preferably be the one assigned to the container

Send network address to the network control component. The

The container authenticator can use the network address, for example

Received authorization request or a separate message. The Network control component can then in particular enable or block data traffic based on the network address. This is particularly useful because the container can be clearly identified by means of the network address and thus rights for the data traffic of this container can be reliably established and monitored.

The network address can in particular be sent from the container management component to the container authenticator. This allows the network address to be communicated easily.

In particular, a protected communication channel running through the network control component can be formed between the container and a network element. This can prevent a large number of attacks. For example, the network element to which the protected

Communication channel is formed, be a protected server to which only a specific container or several specific containers has access or have.

The protected communication channel can in particular be end-to-end encrypted. This can prevent unauthorized persons from reading along.

The protected communication channel can in particular be a VPN channel (Virtual Private Network). For example, IPsec can be used as a VPN technology. This has been found to be advantageous for such applications. However, other technologies can also be used.

The authorization server can preferably supply information and / or keys for setting up the protected communication channel to the container applicant. As a result, in addition to the information already mentioned or in addition to the functionality already described, the authorization server can provide information such as in particular keys for the protected connection. This enables such information and keys to be provided in a particularly simple and reliable manner, as well as shared management on the authorization server.

The information and / or key to build the protected

Communication channels can in particular be included in the authorization response. To this end, they can be included in the authorization response by the authorization server. This allows the authorization response to be sent to the Providing such information can be used. Also a separate one

However, provision is possible.

The network release information can in particular the

Configure the network control component so that only traffic to and from the container or several containers is allowed through. This can be used, for example, when the network control component is a gateway between two networks. A network can be shielded from another network, for example the Internet, in order to

to prevent unauthorized access. For example, in this case only one container or several containers can be authorized to pass the network control component with their respective data traffic.

for example to access the Internet. This means, for example, that a protected browser can be implemented for secure environments.

Traffic between the container and one or more others

Network elements can in particular take place via a protected and / or encrypted network. This can prevent a large number of possible attacks. The protected and / or encrypted network can in particular be encrypted using MACsec. This has proven to be advantageous for typical applications, although other designs are also possible.

According to a preferred embodiment, the container is configured to run only one application. This can further increase security, since each container is only assigned to one application and vice versa. In particular, containers with associated applications can also be provided centrally in this way, preventing users or other persons from executing additional applications in the respective container that may violate guidelines or

Violate security needs. In particular, this can be understood to mean that two or more applications cannot be executed in the container.

The method preferably also has the following step:

Download the application and / or the container from a

Provisioning server. This allows containers and / or associated applications to be provided centrally, for example within a facility such as a company or an educational institution. More preferably, the container is configured to run exclusively applications downloaded from the provisioning server. This ensures that only approved applications are running, which can avoid security problems. In particular, the execution of exclusively permitted applications and / or containers can also be carried out using the checksum already mentioned above and the associated processing

be ensured.

The authorization request and / or the authorization response are preferably EAP messages or EAPoUDP messages. The well-known EAP protocol can be used, which avoids additional administrative effort or development work. Such messages have proven to be advantageous for carrying out the method.

The container can in particular be a remote application container (RAC).

The invention also relates to a network arrangement which is configured to carry out a method according to one of the preceding claims. The network arrangement has a first computer unit which is used to execute the

Container management component, the container and the container applicant is configured, and a second computer unit that is used to execute the

Authorization server is configured. The computer units are networked with one another for data traffic. This applies to the computer units mentioned here as well as to other computer units. Regarding the procedure, all herein

described designs and variants can be used.

A computer unit can in particular be a physically delimitable computer or, for example, a virtual machine on a computer or a server farm. Networking can be wired or wireless and, in particular, provide a defined interface for data traffic.

The network arrangement can, in particular, be used to carry out the method

Container authenticator must be configured. In particular, it can also include a third Have computer unit configured to run the container authenticator.

The network arrangement can in particular be configured to carry out a method with network control components. It can also have a fourth

Computing unit configured to execute a network control component.

According to one embodiment, the network control component can be a gateway between the network arrangement and a separate network. In this way, for example, data traffic between a local or specific network and the Internet can be controlled, as described above. Internet access can, for example, be restricted to certain containers.

According to one embodiment, the network arrangement can have a protected server which can only be addressed via the network control component. This enables the

Network control components, for example as described above, the access to the protected server can be controlled, for example in such a way that only one container or certain containers have access to the server or have.

With regard to the method to be implemented in the respective components or computer units, all the embodiments and variants described herein can be used.

The invention also relates to an electronic device such as a computer, which is configured to carry out a method according to the invention. The invention also relates to a non-volatile computer-readable storage medium which contains program code, when it is executed

Processor executes a method according to the invention. With regard to the method, all of the embodiments and variants described herein can be used. The implementation disclosed herein, as well as the fundamentals thereof, are described below with reference to the accompanying drawing. Show it:

Fig. 1: A comparison of system virtualization and container virtualization,

Fig. 2: A Docker architecture,

Fig. 3: A port-based authorization model of 802.1X,

Fig. 4: A communication example of authentication and authorization

based on 802.1 X,

Fig. 5: A comparison of protocols,

Fig. 6: A managed host that has a RAC and a

Running operating system application,

7: An adaptation of 802.1X for the implementation of an inventive

Procedure,

Fig. 8: A data model,

Fig. 9: A data flow,

Fig. 10: Another data flow,

Fig. 1 1: A test environment,

Fig. 12: A network configuration of Docker in the test environment,

13: A two-step authorization process, and

Fig. 14: Experiments for evaluating communication between the

managed host, a RAC and two web servers.

In general, it should be mentioned that containers can implement virtualization at the operating system level. For example, you provide virtualized

Operating system environments that are isolated with regard to hardware resources and security. They typically share an operating system kernel and may contain libraries that are needed to run one or more of the contained applications. Containers that can be used in the context of the method described herein can also be referred to as xRAC. For example, only special applications with their dependencies and configurations in one

Containers included. Examples of container platforms are Docker, Kubernetes, System d-nspawn, BSD Jails, Linux Containers, Windows Containers, Solaris

Containers, Virtuozzo and rkt. Docker has proven to be particularly advantageous for the method disclosed herein.

Virtualization facilitates the efficient and flexible use of hardware resources, increases security through isolation and ensures fault tolerance and scalability through simple migration processes. In comparison to complete operating systems, containers also have the advantages described below. Due to the shared operating system, containers require less CPU, memory and

Hard drive resources. Container images, referred to as container images in English, are much smaller, which makes it easier to distribute them over numerous recipients. Containers simplify application distribution. Instead of providing support for complex combinations of applications, dependencies and

Having to provide user configurations, administrators can deploy containers that are tested in advance. In addition, containers have no boot times, which makes them particularly advantageous for applications that are only required for a short time.

1 compares the concepts of container virtualization and system virtualization.

Virtual machines (VMs) in system virtualization are typically operated on virtualized hardware components of a hypervisor system and emulated components. The hypervisor controls isolation in terms of resources and security. VMs run complete operating systems, all of which are binary

Include components and databases for running applications.

One of the most widespread container platforms is currently Docker. Fig. 2 shows a simplified overview of the Docker platform and its operation. A host with a common operating system (OS = Operating System) contains the Docker CMD (Container Management Daemon), which creates and manages containers and container images. Container images are read-only templates, which applications and their dependencies such as binary components, databases and

Configurations include. Containers are runtime instances that the Extend read-only container images with a writable layer.

Therefore, different container instances can share a common picture. This leads to scalability with low hard disk requirements. The Docker CMD is controlled by the Docker client via a REST interface. The Docker client can be arranged in the host in which the Docker CMD is also located, or in a remote host. A Docker command line interface (CLI) is an example of user control through CLI calls. The Docker CMD can be connected to Docker registers that allow users to upload or download container images (push or pull). Such registers are available either privately or publicly. A Docker hub with more than 100,000 container images is an example of the latter. Common operations are build (1), pull (2) and run (3). With build, users can create individual container images. With pull, users can download existing container images from a Docker registry to become part of the local container image store. With run, container images can be executed from the local image store on the host system. A Docker registry can also be referred to as a provisioning server.

Docker uses different functions of the operating system kernel for

Provides isolation and resource limitation, and supports storage drivers such as AuFS, OverlayFS and ZFS to enable stacking of a file system. A container format and a runtime environment from Docker were adopted as open industry standards by the Open Container Initiative.

Container security platforms extend the Container Management Daemon (CMD) with security functions. For example, Twistlock and the Aqua Container Security platform enable a runtime environment based on

Machine learning mechanisms for the permanent monitoring of containers to detect compromising behavior and special network firewalls to filter container traffic. The Sysdig Secure platform allows the formulation of service specifications, for example specifications based on applications, containers, hosts or network activities. The platform delivers alarms and actions based on compliance violations, an event log and current

Events. The Atomicorp Secure Docker Kernel is a hardened Linux kernel that has security-relevant features such as outbreak prevention,

Memory modification prevention or prevention of direct user access provided by the kernel. All platforms focus on monitoring and controlling potentially unreliable containers that run on a shared container runtime environment. However, authentication and authorization (AA) features of users, containers and their network flows are not part of these platforms.

The Docker Authorization Framework has been part of Docker since version 1 .10. It expands the Docker CMD through a REST interface to external plug-ins for authorization. Requests from the Docker CMD, for example to start a container, are forwarded to a plug-in for authorization, which

Mechanisms for deciding whether the request is allowed or denied includes. The Docker Authorization Framework does not implement any security functions, but provides a basis for implementing such security concepts. The method disclosed herein extends this further.

Containers typically deliver applications or services without graphical

User interfaces (GUI = Graphical User Interface) that run in a cloud or on a data center infrastructure. Examples are containers which contain web applications and their needs, for example an nginx web server with a PHP runtime and a MySQL database.

The following is a description of 802.1X and an explanation of how it can be used to support authentication and authorization (AA). EAPoUDP is also presented, which is an alternative protocol for data traffic for AA in 802.1X. It is summarized how AA for applications is currently carried out in practice.

IEEE 802.1X introduces port-based network access control in wired Ethernet networks. Even so, it is mostly known today from the 802.11 wireless networks. One example is eduroam, which is an amalgamation of wireless campus networks from universities. Participants can connect to the Internet regardless of whether they are connected to their

Home university or at a foreign university.

Figure 3 shows the three components of 802.1X and the principle of port-based network access control. A supplicant system is a network host that uses the 802.1X supplicant includes (802.1XS), an authenticator system includes an 802.1X authenticator (802.1XA) and controls network access from network hosts. Examples are access switches or switches, which network hosts with the

Connect main network. Before authorization, the supplicant system can reach 802.1X A, but not the network. In the present case, an 802.1X AS (authorization server) is, for example, an authentication, authorization and accounting server. It stores authentication data for checking user identities and authorization data for allowing access to the network. It authenticates and / or authenticates the 802.1X S and provides authorization information to the 802.1X A.

802.1X extends the Extensible Authentication Protocol (EAP) and the remote

Authentication Dial-In User Service (RADIUS) for exchanging AA data. Both provide fixed request and response schemes for exchanging AA data. The diameter protocol is a less common alternative.

Authentication data are transmitted in Ethernet frames, called frames in English, as EAP-over-LAN (EAPoLAN) encapsulation between the 802.1X S and 802.1X A and as EAP-over-RADIUS (EAPoRADIUS) between 802.1X A and 802.1X AS. Fig. 5 shows the packet structure of EAPoL. Authorization data are transmitted between the 802.1X AS and 802.1X A in RADIUS frames.

Details of 802.1X are explained using a four-step procedure by AA according to FIG. In a first step (1) 802.1XS initializes the authentication by sending an EAPoL start message to the 802.1X A. In a second step, the 802.1XA queries the identity of the 802.1XS (2a) and forwards it to the 802.1X AS continue (2b). RADIUS supports large domains which contain several hierarchically organized RADIUS servers. Each identity is linked to a domain and is known to the RADIUS server of this domain, so that AA attempts can be forwarded in RADIUS infrastructures. In a third step (3)

Authentication performed between 802.1X S and 802.1X AS. The authenticator decapsulates EAP packets from EAPoL frames and encapsulates them again as EAPoRADIUS frames and vice versa. The flexible message structure of EAP allows the use of different authentication procedures. Simple approaches carry identity information in plain text or simple MD5 hashed information

Passwords, however, are also becoming more secure authentication procedures such as EAP Tunneled TLS and EAP-TLS supported. The authenticator only forwards EAP messages. Therefore, new EAP types only have to be implemented on the 802.1XS and 802.1X AS, but not in the 802.1 X A. In the fourth step, the RADIUS server can return authorization data to the 802.1XA after successful authentication and authentication. This can be roughly granular, for example a binary access decision as to whether the supplicant system gets access or not, or finely granular, for example VLAN tags, which are expected

User traffic or filter rules can be set, which are applied by the authenticator. The authenticator applies the authorization data to the specific physical port of the switch, for example it sets a VLAN tag. The authenticator then confirms successful AA for the supplicant with an EAP success message (4b).

EAPoUDP is a variation of EAP, which allows the transmission of EAP data via UDP and IP. Fig. 5 shows the associated packet structure in comparison with EAPoL. In contrast to EAPoL, EAPoUDP can be used to authenticate multiple applications running on a network host. UDP packets can also be transmitted using any connection technology, or they can even be routed within multi-domain networks. EAPoUDP was introduced as an Internet draft, which expired in 2002 without standardization in the PANA Working Group at IETF.

802.1X specializes in port-based access control for network hosts. In practice, AA is implemented for applications as part of the applications or using the Kerberos AA protocol.

Most network applications implement some type of AA mechanism. Examples are log-in forms on a start screen where users do this

prompted for valid access information to begin using an application. Other examples are client certificates, which are used together with TLS, and an infrastructure with public

Key. However, AA functionalities that are part of the application have an influence which is limited to the client and server side of the network application. Neither the start of the application nor the network infrastructure in between can be controlled. Kerberos is a network authentication protocol that enables different authentication for clients and servers over an insecure network. Clients are, for example, complete hosts, users or applications; Servers represent hosts that offer certain network applications. Kerberos adapts user tickets for the authentication of various

Network applications. Kerberos must be run through applications on both client and

Server-side implemented, which prevents the application for older applications, which cannot be used.

FlowNAC inserts fine-grained SDN network access control systems using 802.1X for AA from applications on network hosts. This enables different versions of AA for different applications on a network host. To enable different AA for different applications on a network host, EAPoL-over-EAPoLAN encapsulations are introduced. As shown in FIG. 5 in a comparison of data packets for EAPoL, EAPoUDP and EAPoL in EAPoL, FlowNAC inserts another variation of EAPoL. An EAPoL-in-EAPoL packet field identifies up to 64,000 different EAP processes, which are transmitted as encapsulated EAP payload. However, this deviation from the old 802.1X requires significant changes

Changes to 802.1X S and 802.1X A. The 802.1X S is part of a kernel of an operating system, and the 802.1X A is part of network switches, so only open source operating systems and firmware allow modifications. Nevertheless, it is difficult to carry out the modification in new versions of the operating system kernel or the firmware images. In the present case, EAPoL is set, i.e. AA data transfer is restricted to the Ethernet connection. EAPoUDP can basically also be used. FlowNAC also does not insert IP addresses for applications, nor is the start of applications restricted by AA.

RACs (Restricted Application Containers) and the method described here (xRAC) are described below. In addition, the operation of the

Control components explained in detail.

Restricted Application Containers (RACs) are generally executable

Container images, which are a single application whose

Dependencies and configuration data such as program settings and

Include software license information. As can be seen from Fig. 6, RACs in a container runtime environment running parallel to the operating system's own applications. The CMD controls the execution of RACs and provides an interface for users to create, delete and start or stop RACs. Each RAC has its own IPv6 address so that traffic on the network can be easily identified. RAC images are for example through

Network administrators generated and distributed via RAC registers. you will be

for example, either downloaded from such registers by users or automatically synchronized by managed hosts.

7 shows a user who can access a container management daemon (CMD), which represents a container management component. The CMD is located in a managed host, which also contains a remote application container (RAC) and a container applicant in the form of an 802.1X CS (container supplicant). These are corresponding software modules. An external one is required for authorization

Authorization server 802.1X AS available, this user data and

if necessary, also stores data about approved applications and / or containers as well as associated checksums. Between the managed host or the 802.1X CS contained therein and the authorization server, there is a container authenticator, which is designated as 802.1X CA. There is also a firewall FW, which controls and controls network traffic from and to the managed host. This controls access in particular to a protected server, which is shown below. The firewall FW is one

Network control component. For example, xRAC provides execution and access control for RACs on managed hosts. A RAC is thereby preferably authenticated and authorized, namely before an execution takes place. Figure 7 shows an AA process for RACs with 802.1X. First, a user tries to start a RAC via the CMD (1) and the CMD instructs the 802.1X CS for the AA (2). After successful authentication (3) and authorization, the 802.1X AS replies with authorization data or an authorization response via the 802.1X CA (4) to the 802.1X CS (4a). The 802.1X CS informs the CMD that the RAC should be started (4b). In addition, the 802.1X CA informs network control elements about the authorized RAC. In this example the firewall FW is configured to allow access to a to allow protected server (4c). Other examples are SDN controllers that program SDN switches. Now the authorized RAC, but not the managed host or other RACs, communicate with the protected server (5).

AA for RACs introduces two additional advantages compared to known ones

Application delivery and network security. First, for RACs, AA restricts RAC execution on managed hosts to predefined RAC images and permitted users. This allows network operators to ensure that only current and unmodified RAC images can be executed. This improves computer and network security as only valid RAC images can be executed on the managed hosts. In addition, network operators are able to distribute RAC images to managed hosts in advance, for example by synchronizing their set of RAC images with an internal RAC repository in the background. This gives users access to all available RAC images on managed hosts, but they are only able to start them after they have been authorized by AA. After all, every RAC has a globally uniform IPv6 address which can be used to identify data traffic to and from a specific RAC. RAC authorization data on the 802.1X AS includes information about how network elements should control the RAC's traffic. This allows a configuration of network elements or

Network control components from the authorization server AS.

Overall, the following process sequence can thus be implemented, for example.

First of all, the container management daemon CMD as

Container management component receiving user authentication data from the user. The user authentication data is forwarded to the container applicant 802.1X CS. This generates an authorization request which contains the user authentication data. In a preferred embodiment, it also generates a checksum of the container, the checksum

Represents container authentication data, which is also included in the

Authorization request can be included.

The authorization request is then transmitted to the 802.1X AS authorization server via the 802.1X CA container authenticator. This resembles both the

User authentication data as well as the checksum with corresponding Databases. This is known as authentication. If the result is positive, ie the user authentication data is assigned to an authorized user and the checksum indicates that container and / or

Application have not been changed, the authorization server generates a

Authorization response with positive release information and possibly also with authorization information. The authorization response is sent via the

Container authenticator 802.1X CA sent back to the container applicant 802.1X CS. The authorization response is then sent to the

Containermanagementdaemon CMD, which determines based on whether an application is allowed to be executed and, if necessary, with which

Permissions. If the answer is positive, the container management daemon starts the application and assigns it the appropriate authorizations. However, should the authorization server not be able to authenticate the user, or should it be able to authenticate the user but discover a lack of authorization, the authorization server generates an authorization response with negative release information and sends it back accordingly.

Furthermore, after the application has started, the RAC container is assigned a unique network address, for example an IPv6 address. This address is communicated to the firewall FW. Furthermore, the container authenticator 802.1X CA notifies the firewall FW of network release information relating to the container RAC, which comes in the form of network release data from the authorization server 802.1X AS. The firewall FW then controls data traffic from and to the container RAC depending on the network release information and identifies the container on the basis of its IPv6 address. In this way, for example, access to the protected server can be controlled. For this purpose, the firewall FW is arranged in the present case in such a way that all data traffic from and to the protected server runs through the firewall FW. In particular, a protected channel, in particular a VPN channel, can be formed between the container and the protected server. This means that exchanged data can be protected against changes and unauthorized reading.

The authorization request from the container applicant 802.1X CS to the authorization server 802.1X AS thus includes in particular

User authentication data (UAND) and container authentication data (CAND). The 802.1X AS authorization server authenticates the user and verifies the integrity of the RAC image. If the image is valid and the user is authenticated and if the user has permission to run the RAC, the 802.1X AS authorization server replies to the 802.1X CA container authenticator

Authorization data or an authorization response. To run the

Decision, for example, a new data model can be used, which is shown in FIG. It has, for example, user profiles (1), RAC profiles (2) and groups (3) which define whether a specific user is authorized to execute a specific RAC. Include user profiles (1)

User authentication data (UAND) which is used to authenticate the user. Examples are access data, such as username and passwords. RAC profiles (2) contain container authentication data (CAND) and container authorization data (CAZD). The first is used to verify the integrity of the RAC by computing the cryptographic hash function over the RAC image. CAZD contains all authorizations of a RAC, for example whether it can be started by the requesting user and whether it is authorized

To use network resources. This can also be referred to as an authorization response. In the example shown, the RAC is allowed to specify specified

To use network resources. The AA data of the described model is stored in the authorization server 802.1X AS. The data model is an example that can easily be extended to support other requirements. The container applicant 802.1 X CS authenticates RACs with the authorization server 802.1X AS via the container authenticator 802.1 X CA. It sends UAND and CAND to the 802.1X AS authorization server and receives CAZD from it

Container Authenticator 802.1X CA.

The managed host, container authenticator, authorization server, firewall and protected server components shown in FIG. 7 can be used as respective

Computer units are viewed. The entire arrangement represents a

Network arrangement configured to be one described herein

Procedure to carry out.

9 illustrates the process for AA from the perspective of the container applicant 802.1X CS. This runs on the managed host, offers an interface for the CMD and is linked to the IP address or URL of the container authenticator 802.1X CA configured so that it can initiate AA. In (1) the user asks the CMD to start a specific RAC on the managed host. The request includes UAND. The CMD asks the container applicant 802.1X CS whether this can be allowed to the user (2). The request contains UAND and CAND, which are received by the CMD, with CAND being calculated ad hoc as the checksum of the RAC container or from its container image. The container applicant 802.1X CS initiates AA by establishing an EAPoUDP session with the container authenticator 802.1X CA. Authorization is then carried out with the authorization server 802.1X AS via the container authenticator 802.1X CA (3). For example, in older versions of 802.1X, backend authentication can be carried out via EAPoRADIUS, with frontend authorization being carried out via EAPoUDP. In the case of a successful authorization, the container applicant receives 802.1X CS CAZD from the container authenticator 802.1X CA (4). Then he allows

Container applicant 802.1 X CS to the CMD to start the RAC (5).

The 802.1X CA container authenticator routes AA data between the

Container applicant 802.1X CS and the authorization server 802.1X AS. It also informs network control elements about authorized RACs.

In step (1) of FIG. 10, authentication data are transported via EAP between the container applicant 802.1X CS and the authorization server 802.1X AS for authentication. Between the container applicant 802.1X CS and the

Container Authenticator 802.1X CA, the EAP data is transmitted via UDP (EAPoUDP) and between the Container Authenticator 802.1X CA and the

Authorization server 802.1X AS they are transmitted via RADIUS. It is thus a task of the container authenticator 802.1X CA to modify the tunnel for EAP data. Furthermore, after successful authentication, the

Authorization server 802.1X AS CAZD via RADIUS to the container authenticator 802.1X CA back (2), which then informs the container applicant 802.1X CS about the successful authorization (3a). While the conventional 802.1X A only opens ports on a switch for authorized devices, the

Container Authenticator 802.1X CA general network control elements via authorized RACs. These can be ports on a switch, firewalls (3b) or SDN controllers (3c). The firewall is then programmed to allow all outgoing traffic with the IP address of the RAC and the SDN controller instructs SDN switches to allow all traffic with the IP address of the RAC through, provided that appropriate permissions have been granted. More specific flow descriptors are typically not needed, but can be implemented.

In the following, different application scenarios of the here disclosed or

procedure according to the invention described.

First, high-security environments are discussed on a web browser. This can be relevant, for example, for research institutions, government institutions or hospitals that work with highly sensitive data and have to shield their internal network from the Internet. However, web browsers are still required for different activities. It is suggested to use web browsers as RACs on managed hosts. The isolation of RACs prevents malicious users from misusing Internet access to reveal internal information or contaminating the internal network with infectious downloads. The network flow control of RACs ensures that only the web browser can reach the Internet. If the RAC's traffic is encrypted, such as DNS queries and website data, network control elements can still perform packet filtering based on the RAC's IP address.

Furthermore, applications that work with confidential data, for example regarding research activities, medical documentation or public bodies, are discussed. In doing so, confidential data from servers often has to be accessed. When such applications are deployed as RACs on managed hosts as described herein, only legitimate users can access these servers. The isolation feature of the RAC prevents remote hackers from accessing the server. Usually they get system access through gateways provided by a virus or a Trojan horse, whereby such malware is usually captured via browser downloads or e-mail attachments, which is not possible with RACs. Furthermore, malicious users of legitimate applications can use hacking tools to gain access to the server and reveal information about what is not possible in the digital domain with an isolated application. Isolating RACs prevents malicious users or applications from attacking the server. The

Network flow control ensures that the server is only served by legitimate RACs and User can be reached, but not through other RACs or the managed host itself. XRAC extends the benefits of virtualization and

Container virtualization are known and have been described above. In addition, xRAC can guarantee that only valid containers are executed on managed hosts and that they can only be used by legitimate users. Thus, xRAC performs AA (Authentication and Authorization) for applications without the need to modify them, which is a particular advantage for older applications. In addition, the 802.1X CA container authenticator can configure network controls so that authorized RACs have access to protected network resources. RACs enable this control because all network traffic on a RAC is identified by a single IPv6 address. This is a particular advantage because in today's networks there is no information about legitimate flow and numerous application flows can have the same IP address. Applications can even be invisible due to encryption. Thus, xRAC provides a solution to the serious problem of controlling legitimate traffic. xRAC is flexible because it implements software-defined network access control by interacting with other network control elements. In particular, it is not dependent on or limited to specific technologies.

A prototype implementation of xRAC is discussed below.

Fig. 1 1 shows a test environment. The managed host is running RACs. An SDN switch connects the managed host, a protected web server and a public web server and is controlled by an SDN controller. The 802.1X CA runs on the SDN controller as an SDN application that communicates with an 802.1X AS.

Nested virtualization can be used here, i.e. a virtual machine (VM) encapsulates all parts of the test environment, including the managed host. This approach allows the entire test environment to be transferred to others

Hardware platforms are migrated. In the present case, a KVM hypervisor with QEMU for hardware-assisted virtualization and libvirt for orchestration was used for a test. The managed host, both web servers and a RADIUS server run as nested VMs with Ubuntu 17.04. An Open vSwitch serves as an SDN switch, which is controlled by a Ryu SDN controller. In the present case, Docker version 17.05 is used as the container virtualization platform for implementing RACs. The Docker-CMD is configured in such a way that each RAC receives a globally unique IPv6 address that can be reached by other network hosts. Fig. 12 shows the network configuration used. It is preset that RACs only receive one link-local IPv6 address. A fixed IRnd subnet with routable addresses for RACs is therefore set up. In the present case, the managed host is configured with the IPv6 subnet 2001: db8 :: 1 1: 0/1 16 and the RACs receive an IPv6 address from this range. The first RAC receives 2001: db8:: 1 1: 1 and the second RAC receives 2001: db8 :: 1 1: 2. The Dockerdaemon automatically adds routes to a system's routing table and enables IPv6 forwarding so that all traffic to the IPv6 subnet can be routed via a dockerO interface. An NDP proxy daemon is used here to make the RACs accessible from other network hosts. It forwards L2 address resolution for IPv6 addresses of the RACs, ie it monitors neighboring requests for RAC addresses and replies with a MAC address of the managed host. Then packets are received which address a RAC and are forwarded by the Docker host via the dockerO device to the specific RAC.

The 802.1X CS is implemented as a plug-in for the Docker Authorization Framework, which was described above. The plug-in is programmed in Python and uses a Flask library to implement a REST interface. Fig. 13 shows the authorization process. In (1) the user requests the CMD to start a container. The request contains UAND, for example consisting of a user name and a password. The Docker Authorization Framework defines a two-stage authorization process, whereby only the second step is required here. The first authorization request (2) contains only minimal data, for example the name of the RAC picture. Since the present implementation is based only on the second authorization step, the 802.1X CS corresponds to a permission as a default. The second authorization request (3) includes UAND and CAND. The 802.1X CS performs authentication with the 802.1X AS by the 802.1X CA as described above (3). In (4) the 802.1X AS returns CAZD, which is forwarded to the 802.1X CS in the event of a successful AA.

The 802.1X CA is programmed as an SDN application for the Ryu SDN controller. The 802.1XA, which is known from the prior art, is expanded by adding support for authentication with the 802.1X CS using EAPoUDP. The 802.1X CA opens a UDP socket on port 5995 and waits for connections from the 802.1X CS. The 802.1X CA can still act as the legacy 802.1XA that does AA for network hosts in legacy 802.1X over EAPoL. As an example of network control with xRAC, a restricted MAC learning switch is implemented. It learns MAC addresses from connected hosts, but only forwards packets if the IP addresses of the sender and recipient are in a whitelist. The whitelist contains static

Entries, e.g. for public servers, and dynamic entries, which can be modified by the 802.1X CA after receiving CAZD from the 802.1X AS. The restricted MAC learning switch is implemented by extending the L2 switching SDN application from the Ryu SDN controller framework.

Furthermore, the frequently used software FreeRADIUS is used as 802.1X AS, with an AA data model being expanded to implement CAND and CAZD. In FreeRADIUS, additional attributes for AA and simple features can be implemented using specific attributes which are defined in the unlang processing language. The defined AA data model can easily be expanded and modified by adding several Vendor-Specific Attributes (VSAs).

Two web server VMs in the test environment operate a Python web server, which delivers HTML files via HTTP. The protected web server with the static IPv6 address 2001: db8 :: aa: 0 delivers an HTML page with the sentence “protected content”. The public web server with the static IPv6 address 2001: db8 :: bb: 0 delivers an HTML page with the sentence “public content”.

To verify functionality, the test environment described

Experiments carried out.

The experiments look in particular at the communication between the

managed host, a specific RAC, the protected web server, and the public web server. A wget tool is encapsulated as a RAC to receive files using HTTP. In the following experiments, the RAC is used to extract an HTML file from both the protected and

request public web server. There are UAND, CAND and CAZD on the Added RADIUS server to allow a specific user to run the RAC and access the protected web server.

The experiments shown in Fig. 14 are carried out. Before running the RAC, it shows that the managed host can reach the public but not the protected web server. Therefore, an ICMP echo request is sent from the protected host to the IRnd address of both the public web server and the protected web server. The public web server can be reached without authorization (1 a), but an attempt to contact the protected web server fails (1 b). It will now be demonstrated that the integrity of RACs is verified during authentication, i.e. that a RAC with a diverging checksum cannot be started. Another RAC image is generated, which encapsulates a patched version of wget and tries to start this, using the user access data as defined on the RADIUS server. The authorization fails, i.e. the RAC cannot start on the managed host. It is now demonstrated that the correct RAC can be started and that it can reach the protected web server after successful AA. After entering a command to start the RAC, it is authenticated and authorized as described above (2a). The SDN controller receives CAZD and programs the SDN switch to allow forwarding of packets between the RAC and the protected web server (2c). The RAC is now able to receive the received HTML file from the protected web server. An attempt to fetch the same HTML file directly from the managed host using wget fails (2e), i.e. the protected web server can be reached through the RAC but not through the managed host.

In summary, it should be noted that xRAC is proposed, a concept for implementing access control from Restricted Application Containers (RACs) on managed clients. It includes authentication and authorization (AA) for RACs such that only current RAC images can be executed by authorized users. Furthermore, the authorization is extended to protected network resources in such a way that authorized RACs can access them.

Traffic control is simplified by the fact that all traffic from a RAC is identified by its IPv6 address. The architecture of xRAC is presented and it is demonstrated through a prototype implementation that xRAC can be built using standardized technology, protocols and infrastructure. A prototype of xRAC uses Docker as a

Container virtualization platform for distributing and executing RACs, and signaling is based on 802.1X components. Modifications can be made to a supplicant, an authenticator and an authorization server so that both user and container AA data can be exchanged. Furthermore, the container authenticator is extended to include required

Inform network control elements of authorized RACs. xRAC supports software-defined network control and improves network security without modifying core components of applications, hosts and infrastructure.

Mentioned steps of the method according to the invention can preferably be carried out in the order given. However, a different order is also possible if this is technically sensible. The method according to the invention can be carried out in one of its embodiments, for example with a specific combination of steps, in such a way that no further steps are carried out. In principle, however, further steps can also be carried out, including those which are not mentioned.

It should be pointed out that features can be described in combination in the claims and in the description, for example to facilitate understanding, although they can also be used separately from one another. The person skilled in the art recognizes that such features can also be combined with other features or feature combinations independently of one another.

References back in subclaims can identify preferred combinations of the respective features, but do not exclude other combinations of features.

Claims

1. Method for selectively executing a container (RAC) that has a

Application includes, the method comprising the steps of:

Receiving user authentication data (UAND) by a

Container management component (CMD),

Forward the user authentication data (UAND) to a

Container applicant (CS),

Sending, by the container applicant (CS), an authorization request to an authorization server (AS), the authorization request containing at least the user authentication data (UAND),

Receiving, by the container applicant (CS), an authorization response (CAZD) from the authorization server (AS), the authorization response (CAZD) containing at least one release information, which can have either a positive or a negative value,

Forwarding the authorization response (CAZD) to the

Container management component (CMD),

Decide, by the container management component (CMD), whether the container (RAC) is to be executed, the container (RAC) to be executed when the release information has a positive value, and the container (RAC) not to be executed when the release information has a negative value Has,

only if the container (RAC) is to be executed, starting and executing the container (RAC).

2. The method according to claim 1,

wherein the authorization server (AS) determines the release information based at least on the user authentication data (UAND).

3. The method according to any one of the preceding claims,

wherein the authorization server (AS) compares the user authentication data (UAND) with a number of user default values and the

Set release information to a positive value only if the

User authentication data (UAND) correspond to one of the user default values.

4. The method according to any one of the preceding claims,

where the container applicant (CS) is an 802.1X supplicant,

and or

wherein the authorization server (AS) is an 802.1X authorization server (AS), and / or

where the container management component (CMD) is a container management daemon.

5. The method according to any one of the preceding claims,

which further comprises the following step:

Generation of container authentication data (CAND) depending on the container (RAC) or a container image of the container (RAC).

6. The method according to claim 5,

which further comprises the following step:

Send the container authentication data (CAND) to the

Authorization server (AS).

7. The method according to any one of claims 5 or 6,

wherein the authorization request contains the container authentication data (CAND).

8. The method according to any one of claims 5 or 6,

the container authentication data (CAND) in a for

Authorization request separate message to be sent to the authorization server (AS).

9. The method according to any one of claims 5 to 8,

which also has the following steps:

Receiving a nonce from the authorization server (AS), and

Changing the container authentication data (CAND) based on the nonce before sending the container authentication data (CAND) to the

Authorization server (AS) are sent.

10. The method according to any one of claims 5 to 9,

where the container authentication data (CAND) is the checksum of the

Containers (RAC) or the container image.

1 1. Method according to claim 10,

wherein the checksum is calculated after receiving the user authentication data (UAND).

12. The method according to any one of claims 5 to 9,

where the container authentication data (CAND) is an identification number of the container (RAC).

13. The method according to claim 12,

whereby the container management component (CMD) is configured to ensure a clear assignment between identification number and container (RAC).

14. The method according to any one of claims 5 to 13,

wherein the authorization server (AS) determines the release information based at least on the container authentication data (CAND).

15. The method according to any one of claims 5 to 14,

wherein the authorization server (AS) compares the container authentication data (CAND) with a number of container default values and the

Set release information to a positive value only if the

Container authentication data (CAND) correspond to one of the container default values.

16. The method according to any one of the preceding claims,

where the authorization response (CAZD) contains authorization information,

wherein the application is executed with rights which are determined based on the authorization information.

17. The method according to any one of the preceding claims,

which further comprises the following step:

Assigning a network address to the container (RAC).

18. The method according to claim 17,

whereby the network address is assigned by the container management component (CMD).

19. The method according to any one of claims 17 or 18,

wherein the authorization request includes the network address.

20. The method according to any one of claims 17 or 18,

whereby the container management component (CMD) sends the network address separately to the authorization request.

21st Method according to one of the preceding claims,

The authorization request is sent to the authorization server (AS) via a container authenticator (CA),

and or

wherein the authorization response (CAZD) is received from the authorization server (AS) via a container authenticator (CA).

22. The method according to claim 21,

where the container authenticator (CA) is an 802.1X authenticator.

23. The method according to any one of claims 21 or 22,

which also has the following steps:

Generate, by the container authenticator (CA), a

Network Share Information Based on Authorization Response (CAZD), and

Send, through the container authenticator (CA), the

Network release information to a network control component (FW), wherein the network control component (FW) enables or blocks data traffic to and / or from the container (RAC) based on the network release information.

24. The method according to claim 23,

the authorization server (AS) with the authorization response

Network share data generated, and

wherein the container authenticator (CA) generates the network release information based on the network release data.

25. The method according to claim 24,

wherein the authorization server the network release data depending on the user authentication data (UAND) and / or the

Container authentication data (CAND) generated.

26. The method according to any one of claims 23 to 25,

wherein the network control component (FW) is arranged so that all data traffic to and from the container (RAC) and / or to and from a protected server is routed through the network control component (FW).

27. The method according to any one of claims 23 to 26,

wherein the network control component (FW) is a gateway which connects two networks.

28. The method according to any one of claims 17 to 20 and one of claims 23 to 27,

wherein the container authenticator (CA) sends the network address assigned to the container (RAC) to the network control component (FW), and wherein the network control component (FW) enables or blocks the data traffic based on the network address.

29. The method according to claim 28,

whereby the network address is sent from the container management component (CMD) to the container authenticator (CA).

30. The method according to any one of claims 23 to 29,

a protected one running through the network control component (FW) between the container (RAC) and a network element

Communication channel is formed.

31. Method according to claim 30,

the protected communication channel being end-to-end encrypted.

32. The method according to any one of claims 30 or 31,

where the protected communication channel is a VPN channel.

33. The method according to any one of claims 30 to 32,

wherein the authorization server (AS) supplies information and / or keys for setting up the protected communication channel to the container applicant (CS).

34. The method according to claim 33,

the information and / or key for setting up the protected communication channel are contained in the authorization response (CAZD).

35. The method according to any one of claims 23 to 34,

wherein the network release information configures the network control component so that only data traffic to and from the container (RAC) or several containers (RAC) is allowed through.

36. The method according to any one of the preceding claims,

data traffic between the container (RAC) and one or more other network elements takes place via a protected and / or encrypted network.

37. The method according to claim 36,

whereby the protected and / or encrypted network is encrypted using MACsec.

38. The method according to any one of the preceding claims,

where the container (RAC) is configured to have only one application

execute.

39. The method according to any one of the preceding claims,

which further comprises the following step:

Download the application and / or container (RAC) from a provisioning server.

40. The method according to claim 39,

whereby the container (RAC) is configured to only use the

Provisioning server to run downloaded applications.

41. Method according to one of the preceding claims,

wherein the authorization request and / or the authorization response (CAZD) are EAP messages or EAPoUDP messages.

42. having a network arrangement which is configured to carry out a method according to one of the preceding claims

a first computer unit that is responsible for executing the

The container management component (CMD), the container (RAC) and the container applicant (CS) is configured, and

a second computer unit configured to run the authorization server (AS),

wherein the computer units are networked with one another for data traffic.

43. Network arrangement according to claim 42,

which is configured to carry out the method of claim 21 or any claim dependent thereon, and

which further comprises a third computer unit which is configured to execute the container authenticator (CA).

44. Network arrangement according to claim 43,

which is configured to carry out a method according to claim 23 or any claim dependent thereon, and

which further comprises a fourth computer unit which is configured to execute a network control component (FW).

45. Network arrangement according to claim 44,

wherein the network control component (FW) is a gateway between the network arrangement and a separate network.

46. Network arrangement according to one of claims 44 or 45,

which also has a protected server that can only be addressed via the network control component (FW).