WO2010009896A1

WO2010009896A1 - Computer system with automatic access regulation of an application and access control to an application and corresponding access regulation and control method

Info

Publication number: WO2010009896A1
Application number: PCT/EP2009/005389
Authority: WO
Inventors: Mathias Dalheimer; Franz-Josef Pfreundt
Original assignee: Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e. V.
Priority date: 2008-07-24
Filing date: 2009-07-24
Publication date: 2010-01-28
Also published as: DE102008034492A1

Abstract

The invention relates to a computer system with automatic access regulation of an application and access control to an application, comprising a user computer (1), a licensing server (2) designed for bidirectionally exchanging data with the user computer and a resource computer (3) designed for bidirectionally exchanging data with the user computer, in which an application (4) can be installed and/or is installed. A licence descriptor (7) can be generated on the user computer based on first input data (5) for the application and/or on hardware characteristics (6) of the user computer. Said license descriptor can be transmitted to the license server and can be checked by the license server if access authorisation to the user computer and/or the first input data (5) is input into the application. If said access authorisation exists, the license server can generate a license token (8) allowing access to the application and can be transmitted to the user computer. The license token or the license information (8') based on said token and the second input data (5') for the application can be transmitted by the user computer to the resource computer that can check the license token or the licence information by the resource computer and/or the application as to whether the user computer and/or the second input data (5') can access the application.

Description

FRAUNHOFER SOCIETY ... E.V. 099PCT 0872

Computer arrangement with automated access control of one and access control to an application and corresponding access control and

Access control method

The present invention relates to a computer arrangement (hereinafter alternatively referred to as a computer network) with automated access control of and with automated access control to one or more application (s). The present invention also relates to a corresponding access control and access control method.

Today's computer networks, especially in so-called grid computing, exceed the limits of individual organizations in the use of computational resources. The use of pure computation time and storage space is nowadays no longer found only within a single organization, but also in other organizations, ie by the own organization with third instead. As a result, questions arise as to how the access control and the access control can be automatically made available to applications by external organizations or third parties. In particular, it must be clarified to what extent licenses can be used in such a computer network or in the grid environment. In this case, a license of a computer of its own organization (user computer) and / or of a user within its own organization for accessing an application program or an application which is (s) on another computer, in particular on a resource computer, which is provided by another organization within the computer network, is understood. Licenses thus allow access to remotely installed applications.

Basically, two scenarios are conceivable:

1. The user uses licenses that are available outside of their own organization, ie the resource provider or a corresponding resource calculator.

2. The user brings own licenses to the resource provider or to the resource calculator.

The automated access control and access control methods currently used in the prior art provide different licensing models, the implementations of which can be summarized as follows: 1. A software or application is provided with a so-called node-lock license, ie the application is bound to a fixed computer and can only be used there. This license form only permits on-site use, ie in

With respect to grid computing, a user can only use preinstalled licenses. It is therefore not possible to bring your own license to the resource provider.

2. A second technical realization of licensing is the so-called floating license: A central server is set up at the licensee and configured with the number of licenses or other specifications. Thus, for each task to be performed (for example: calculation job), the application (e.g., simulation or calculation software) queries at this central server whether a free license is currently available. If this is the case, this license can be used for the task currently being processed. If no free license is available, the task will not be processed.

3. A third form of licensing is known as "Named User": In this case, access to an application is only permitted to certain users, whereby the application is often linked to the local user name.

Obviously, a node-lock license is only available to resource providers who provide a fixed number of licenses for use in the grid. A user can not submit his own license here. The use of a floating license is possible in principle. The license can either be at job start are obtained from a user or resource server license server, but with some limitations:

1. The license server must be reachable from the location of the calculation so that the license can be released when starting the job. Depending on the configuration of the network environment of the resource provider, this is not possible and can not be checked before starting the computing job.

2. To start the calculation job, the corresponding license server must actually hold a license. If a job does not find a license, it will quit without performing the calculation. Under certain circumstances, the user thus loses the time that the job has been waiting in a batch queue. You may also be charged for reserving resources.

In the case of a "Named User" license, the identity of a user must be checked. In the grid environment, however, there is the problem of delegation: the local user is not necessarily the user who sent the job. In principle, it would be possible to identify the original user via his certificate when sending a job - however, this functionality is not provided in any grid middleware and therefore not easy to implement.

Starting from the prior art, it is therefore the object of the present invention to provide a computer arrangement for the automated access control and / or access control of applications, in which simple, fast, on exactly defined manner and with a high degree of protection against the evasion of access control or access control, the control of access to one or more applications by user computer connected to the computer arrangement or by users working on the computer arrangement is possible. It is also an object of the present invention to provide a corresponding automated access control and access control method.

This object is achieved by the computer arrangement according to claim 1 and by the access control and access control method according to claim 18. Advantageous embodiments of the computer arrangement according to the invention and of the method according to the invention can be found in the respective dependent claims. Advantageous uses of such an arrangement or method are described in the use claims.

Hereinafter, the present invention will first be described generally and then presented by means of a generally held embodiment. This is followed by a specific embodiment in which a concrete implementation or design of a computer network or access control and access control method according to the invention is described.

The concrete combination of the individual features, as described in the general and the specific exemplary embodiment, is not absolutely necessary for the execution of the invention, that is to say that in the context of the present invention individual features can be used. male of the combination shown according to the independent claims are also realized or realized in other combinations.

A computer arrangement according to the invention with automated access control from an access control to an application has a user component, a license server component designed for bidirectional data exchange with the user component, and a resource component designed for bidirectional data exchange with the user component, which controls an application that is designed as part of an application or on which an application is installed. Of course, in each case several user components are connected respectively to the license server component and the (or also the several) resource component (s). According to the invention, a license descriptor can be generated on the basis of the user component on the basis of first input data for the application and / or of hardware features of the user component. This license descriptor can then be transmitted to the license server component and can be checked by the latter as to whether the user component, a user and / or the first input data are authorized to access the application. In the case of such an access authorization, the license server component can then generate a license token which allows access to the application and can be transmitted to the user component. The user component then enables the license token (or licensing information based thereon) and second input data for the application to be transmitted to the resource component. The license token (or license information) is / are then represented by the resource component te and / or the application verifiable to whether the access authorization of the user component, the user and / or the second input data is given to the application. If this is the case, then the application can be the second transmitted

Use input data, for example, perform calculations with these input data and return the results of these calculations back to the user component.

As a rule, the first input data will be identical to the second input data (these data are therefore usually also referred to below as simplified input data without further specification). However, it is also conceivable that the user first generates a license descriptor based on the first input data for the application, then transmits it to the license server component and then receives the license token generated on the basis of the first input data and transmitted back.

The user can then exchange the first input data (for example, if he determines that additional calculations are still necessary) with other input data (second input data) suitable for the application and then, together with the license token (of such an exchange in this case admits) to which the actual calculations carry out the resource component.

The computer arrangement according to the invention can be used in particular in the field of simulation of technical systems: In the simulation of such systems (eg in the simulation of medical X-ray systems or also therapy systems, for example radiation therapy systems), the virtual imaging of the corresponding technical system is often necessary. In a computer system, systems require a large number of calculations (eg Monte Carlo simulation calculations or the like), which, so that the user does not have to wait too long for the calculation results, must be distributed over several individual resource components.

As is immediately clear to the person skilled in the art, the individual components can be used both as software elements and as a function of the specific system requirement

Hardware elements, or be designed as software and hardware elements. When talking about a client or a server, this is e.g. not limiting to the effect that the client must be designed as software and the server as hardware (for example, a client can be realized as a pure software solution, but it can also be a computer system with appropriately installed components, etc. ).

As a rule, the individual components, that is to say the user component (s), the resource component (s) and the license server component will each be installed on separate, separate individual computers (or designed as corresponding individual computers). However, it is alternatively also possible to design more than one component on the same individual computer (eg PC): For example, a user component and a resource component can be installed on a common user and resource computer. Likewise, it is conceivable to form the license server component and a resource component on a common license server and resource computer. In the first case, the license server component is on a license ver formed separately from the user and resource calculator. In the second case, at least one user component is then formed separately from the license server and resource computer on a separate individual computer, which is then connected via a network (for example the Internet) to the common license server and resource computer.

In the further description of the invention, therefore, the following synonyms are used below (each number denotes synonymously used expressions):

1. Computer arrangement, computer network, grid environment and grid environment;

2. user component, user computer, user, licensee, client, user client and user client;

3. License server component, license server, licensor and manufacturer of an application or software;

4. resource component, resource calculator, resource provider, resource provider, and calculation backend;

5. License Token, Token and License.

Thus, in the present invention, the license tokens are advantageously generated as needed and stored in the respective files, ie, they can be transferred to other computers. It is, as will be described below, no fear of misuse. They are the following Implementation scenarios can be realized:

1. The license token is linked to an input file for an application. The license preferably refers to the use of the application with exactly this input file (as described above, it is however also possible to obtain the license for use of the application with other, optionally exchanged or supplemented input data). For example, batch programs can be used as input files.

2. In addition (or additionally), the inventive system can also be used for the dynamic allocation of floating licenses. The license is not tied to an input file, but to the local hardware. For example, a user of a pre-processing tool for a simulation program for a

Business trip to create a license for his notebook, which is then bound to the hardware of the notebook (CPU ID, MAC address, etc.).

In the following, the present invention will first be described on the basis of the linking of licenses with the input data. Afterwards the necessary adjustments for hardware-bound licenses will be briefly described. This is followed by a specific embodiment with a concrete system design and with a concrete implementation.

Show it:

FIG. 1 shows a computer arrangement according to the invention, in which the user component, the license ver component and the resource component are each realized as separate individual computers (and therefore also be so called) in overview;

Figure 2 is an example of a license descriptor;

FIG. 3 shows the architecture of a concretely implemented license service in a computer network according to the invention;

FIG. 4 shows a concrete implementation of a license descriptor.

Figure 1 shows an example of the basic structure of a computer network according to the invention with automated access control and access control. The network has a user computer 1 embodied as a PC IPC (which forms the user component), which is designed for bidirectional data exchange with a license server 2 (which forms the license server component) designed as a PC 2PC (arrows above). In addition, the user computer 1 is also designed for bidirectional data exchange with a resource calculator 3 designed as a PC 3PC, which forms the resource component (arrows at the bottom of the picture). An application 4 is installed on the resource calculator, here a simulation program which performs simulation calculations on the basis of input data.

In Figure 1, only a user computer 1 is shown, but it is of course also possible to connect a plurality of appropriately trained user computer respectively for bidirectional data exchange with the license server. In addition, it is It is also possible to provide a multiplicity of resource computers 3 instead of the resource computer shown only one, with which the user computers can then be connected in each case for bidirectional data exchange. A user computer can be connected to several resource computers or vice versa.

In the user computer 1 input data 5 are stored, which are designed so that the application 4 can be made with them to start a simulation calculation and to transmit the corresponding simulation results. From this input data 5, the user computer 1 generates a license descriptor 7. In the present case, this is done by the user computer 1 calculating a cryptographic code in the form of a hash code from the input data 5. This calculated code is then used together with user identification data that identifies the user's computer 1 and a user acting on it

User Ia, summarized to the license descriptor.

Alternatively or cumulatively, however, it is also possible that the user computer 1 based on hardware features 6 of the user computer and / or information about the user Ia (for example, based on a CPU identification number of the CPU of the user's computer or a MAC address of the user computer) a cryptographic code in the form of a

Calculated hash codes. As described above, this cryptographic code can then be combined with user identification data for the license descriptor. In addition, data are added to the license descriptor which are necessary in order to enable the license server 2 to determine whether access authorization of the user computer (or of the user) to the application 4 is given for the corresponding input data 5.

In the present case, only the hash code calculated from the input data 5 is processed by the user computer

1 transmitted to the license server 2. However, it is also possible to transmit the input data 5 itself to the license server 2 in addition to this hash code (so that these can then be used for further checks, etc.).

The license descriptor 7 is then sent to the license server

2, which checks the above-described access authorization. If an appropriate access authorization is given (which the license server 2 can check, for example, on the basis of a previously stored table with user computer or customer data and data for the application 4), then the license server 2 cryptographically encrypts the license descriptor 7 with a secret key of a public key infra - Structure (for example, an X.509-based public key infrastructure) and forms by means of this encryption from the optionally suitably adapted or supplemented license descriptor 7 a license token 8. Since an appropriate access to the application 4 is given, is this license token 8 then transferred from the license server 2 back to the user computer 1. In the user computer 1, the input data 5 'to be used for starting the simulation calculations by means of the application 4 is then based on the license token 8 License information 8 'connected and transmitted to the resource calculator 3. In the present case, the user of the user computer 1 provides those input data for starting the simulation process of the application 4, from which the hash code of the license descriptor was also calculated. The data 5 thus correspond to the data 5 '(data equality is indicated by 5' = 5 in the figure). Also, the license token 8 itself is used as the license information 8 'transmitted to the resource calculator 3. This is indicated by 8 '= 8.

The license token 8 transmitted by the user computer 1 to the resource computer 3 is then checked by the application 4 in the resource computer 3 to determine whether access authorization of the input data 5 of the user computer 1 to the application 4 is given. For this purpose, the license token 8 is first decrypted by the application by means of the public key of the above-mentioned public-key infrastructure (which has been made available by the license server and has already been stored in the resource computer 3) and then checked accordingly. In addition, by the resource calculator (or by the application itself) a cryptographic code in the form of a hash code calculated in the same manner from the input data 5 as in the user computer 1. This calculated in the resource calculator 3 hash code is then with the hash Code, which was transmitted in the license descriptor 7 first from the user computer 1 to the license server 2 and then in the encrypted license descriptor, ie in the license token 8, from the license server 2 via the user computer 1 to the resource computer 3. Only if these two hash codes match (and after successful decryption and verification of the license token 8 with the public key), the application 4 starts with the transmitted input data 5 their simulation calculation. The output data 9 (simulation results) calculated by the application from the input data 5 are then transmitted from the resource computer 3 to the user computer 1.

In the case described, the bidirectional data transmission between the units 1, 2 and 3 takes place in the context of the computer network according to the invention via the Internet. Of course, a local computer network (intranet within an organization) can also be used.

Within the scope of the exemplary embodiment described, it is also possible for the license descriptor 7 to be generated by the user computer 1 with a duration desired by the user for the license for the application 4. The license descriptor 7 is then transmitted with this information to the license server 2, which determines whether a desired license period is possible (this can be done for example on the basis of a user account of a user 1 on the license server 2). The license token 8 is then generated by the license server 2 with a correspondingly determined license duration. The license duration is defined in such a way that ultimately a time window is transmitted to the resource computer 3, during which the application 4 can perform simulation calculations on the basis of the input data 5.

In addition, it is also possible, after execution of the simulation calculations by the application 4, to add to the license token 8 the time duration which the simulation calculations on the resource computer 3 required and to supplement the correspondingly supplemented license token. ken 8 together with the output data 9 back to the user computer 1 to transfer.

Thus, when the user 1 sends his input file 5 for a computational job to an external resource provider

4, he must have the manufacturer of the software or the license server create a license token 8 for his input data. The manufacturer assures through this mechanism that a license agreement exists for this calculation. The license token 8 is then combined with the input data

5 forwarded to the resource provider 3. When the application 4 is started, it can then check the license token and carry out the calculations.

A secure implementation must be v. A. Provide protection against tampering or prevent the reuse of keys for other calculations. This can be achieved, for example, simply by using an X.509-based Public Key Infrastructure (PKI): The licensee creates a license descriptor for the input data by sending a cryptographic hash of the input data to the licensor. At the same time, the licensee also adds a descriptor to the request with further personal data (user identification data). On this basis, the licensor can then decide, for example, whether the licensee is already known and whether he can be granted the access rights. It may also be possible to transmit information on the type of license granted here.

An example of such a license descriptor 7 is given in FIG. The corresponding information must of course be able to be processed by the licensor. If the customer request check satisfies the requirements of the licensor, he signs the license descriptor 7 with his secret X.509 key and returns it as a license token 8 to the licensee 1.

The licensee 1 then transmits his data together with the license token 8 to a resource provider 3. Although he has installed, for example, the software of the licensor, but may have. even no license for it.

The job is started normally via a batch system. The application now checks the license token with the help of the licensor's public key and thus has secured a precondition for the validity of the license. (Here it is checked whether the license token was actually issued by the license server, - the check whether the license subsequently also applies to this input data is carried out as described below.) Then it calculates the cryptographic hash of the input and compares it with the signed hash from the license token. This is possible because the license descriptor is transmitted with the user-generated hash to the license server, where it is adopted in the license token and then transmitted to the user and the resource computer. If these match, then there is a valid license for this input data and the calculation can start.

The license server thus checks whether the user Ia is allowed to use the application. In doing so, a license token dependent, for example, on the application data / input data is created. The user computer must check this license token to verify the existence of a license token ensure correct license for the given input data. The reason for this is that the resource calculator and the license server do not have any knowledge of each other, ie no communication to the outside must be made at the time the job starts. The license check can be done purely with locally available data. Thus, in the present case, several conditions must be met for a license to be valid for the input data (test procedure performed by the application and / or the resource calculator):

1. correct signature of the license token (the token itself is unmodified);

2. the token refers to the input data (here: the hash codes match) and

3. restrictions possibly encoded in the license token (for example, that the computations are limited to one

CPU of the resource computer may be executed) are fulfilled.

It is thus very easy for the licensor to generate user-specific license tokens in an automated process. This step may e.g. can also be integrated directly into the licensing preprocessing tools. A kind of "archive" for the submission to a resource provider can be created, which contains not only the input data but also the license for the application. The licensee then only has to send this archive to the resource provider.

From the point of view of resource providers, this licensing process has the advantage that the application checking the license from the input data itself. It is not necessary to maintain a permanent application license or to maintain a corresponding network configuration for each customer's license server. In the case of a failed job (eg due to computer failures), the provider can also independently restart the job without having to wait for a license.

In this solution, the user has to take the additional step of generating the license, which, however, can be handled completely in software. In terms of handling the input data, it is recommended to generate an archive file within the preprocessing tools to make the transfer to the resource provider easy.

In addition to binding the license token to an input file, it is also possible to bind the license to other circumstances. The method remains unchanged - only the generation of the hash is changed: In the section described so far, the hash is calculated from the input data. Of course, this is not an option for the user of an interactive preprocessing tool, as there may not be any input data yet. Instead of a hash on the input data, however, it is possible here to characterize the user environment with a hash. Together with other data, a license descriptor can be formed from this, which can then be used as usual to request a license (license token).

The hash represents an identification of the user's computer, eg a combination of CPU ID, MAC address, etc. The following deployment scenario is conceivable: The user would like to have a valid license for one week on his notebook, eg to be able to work independently of the network during a customer visit. He starts the license client on the notebook, whereupon he calculates a cryptographic hash from the hardware components of the notebook. Together with other data, such as the desired license period, a license descriptor is created, which can then be signed by the license server. This license token can then be saved in a file.

When the application is started, the license token is first checked for validity and then the current cryptographic hash is calculated from the hardware. If the two hashes match, the license conditions described in the license descriptor apply.

Based on floating licenses in a local

Network may require a user to return their license after use. Since it is generally not possible to communicate with the resource calculator on which the calculation is running, the return can only be indirect. To do this, the license will be issued for a longer time than the job really needed. After the calculation has expired, the application logs the used computing time.

This logging can be included as an additional field in the license token and provided with the signature of the application binaries. Together with the output data of the application, the license token is transferred back to the user. There, the license client can restore the changed license token. Send back to the license server.

The license server, in turn, checks the signature for the computation time. If the signature is correct, the unused computation time is transferred back to the user's account.

A concrete implementation of a computer network according to the invention is described below:

The licensing service consists of the already mentioned components User Client (on User Computer 1), License Server 2 and License Checker (part of Resource Calculator 3). In addition, a messaging service is required for the communication. For the following discussion of the components, it is assumed that the underlying application consists of a user component and a calculation backend and the license is to be bound to an input file. First, the components are displayed individually, followed by the communication protocol. An overview of the components used is given in FIG. 3.

The user client:

The user client is a software component that can be integrated directly into the end-user application. The purpose of the user client is to request a license key from the license server for a given input record.

For this purpose, the input data set is first characterized by a hash. In addition to a hash, further information regarding the application must be compiled, eg how many CPUs are used should be. An example of a license descriptor is shown in Figure 4. The internal flow of the user's client looks like this:

1. Depending on the configuration of the

Clients are charged a specific cryptographic hash from the input data.

2. The license descriptor is compiled. To determine the identity of the user, the license descriptor is provided with a digital signature.

3. The license descriptor is packaged with the signature in a request and sent to the license server.

4. The server's response contains an encrypted license token. The client asks the server again for the decryption key. With this the client decrypts the license token.

5. The license token is stored in a file and made available to the user.

If unused computation times are to be reversed, the modified license token is sent back to the license server after the computation has been completed. If an error occurs, the user will be notified. The license server:

The license server is a daemon that constantly waits for and answers incoming license requests. A valid license token is created by providing the license descriptor with the signature of the server from the user's client. The internal process looks like this:

1. The received license descriptor is opened and the identity of the user is checked by means of his digital signature. Thus, the request is authenticated, i. It is clear to whom the license request is to be assigned.

2. Then the user must be authorized, i. Based on a customer database, etc., it is decided whether the user may even request this license. Details of the requested license terms (for example number of CPUs, calculation modules) can be checked. This functionality is encapsulated in a separate license management plugin.

3. Finally, the license descriptor is signed with the secret key of the license server. The server assigns a symmetric key for this request and encrypts the license token with it. The license token will now be returned.

4. The server is waiting for the client's request for the key. If this request comes in, the server knows that the license token has arrived at the client. The server responds with the key to unlock the license. The license server's answer adds a signature to the license descriptor if the license is valid. This license token certifies the validity of a license under the terms specified in the license descriptor.

If the license client wants to return a signed license token after the end of the calculation job, it will be evaluated with regard to the used computing time.

The license examiner:

This component is integrated directly into the calculation bucket. Your job is to check the validity of a license token. For this the following steps are carried out:

1. The license token is opened and the signature of the license server is checked for validity.

2. The license terms of the descriptor are checked and the corresponding modules of the calculation block end are released.

3. The hash of the input data is calculated and compared with the value in the license descriptor. If all checks are successful, the license for this input record is valid.

It is important that the license examiner only has to know the public key of the license server. It is not necessary to establish network connections to the license server - the license descriptor can be checked locally. After the calculation has expired, the license examiner can document and sign the used up processing time in the license token. The token can then be copied back to the user with the results.

The license server and the user client exchange only compact messages, it is not necessary to exchange larger amounts of data. It is therefore possible to handle the communication via a messaging queue. Several physical license servers can be linked to a logical one to increase the reliability. In addition, only the messaging queue needs to be made accessible via the Internet so that no direct attacks on the license servers are possible.

The protocol:

Provided that messaging between the license client and the license server works correctly and reliably, you can implement a very simple protocol. However, the protocol must also work in case of faulty network connections.

Closer inspection revealed that the exchange of the license token can be traced back to the problem of Byzantine generals: how can two parties have a consistent view of the transfer of the license token? This problem is not generally solvable. To illustrate this, one can imagine what happens when individual messages get lost: Suppose the client requests a license from the server. He gets the license, but he does not answer. The server can not decide now whether the client the License or whether the license has never arrived at the client.

However, to ensure the transfer of the license token, an additional component (the

Key or key) in the protocol. The key encrypts the license token symmetrically. After the client has received the encrypted license token, he asks the license server for the corresponding key again. He specifies a transaction number that was transmitted by the server in the same data package as the license token. If the request for the key has been received by the server with the correct transaction number, then the license can be finally calculated.

However, the message with the key of the server can also be lost. In this case, the client can display to the user a message with the transaction number - with this the user can then contact the licensor and request the activation key.

In summary, although this case can not be ruled out, it is unlikely overall. It is not to be expected that the user often has to ask the licensor for an activation key.

ή

Claims

claims

1. Computer arrangement with automated access control of one and access control to an application, comprising

at least one user component (1), a license server component (2) designed for bidirectional data exchange with the user component and at least one resource component (3) designed for bidirectional data exchange with the user component, the resource component (3) controlling and / or comprising an application (4) in which a license descriptor (7) can be generated by the user component on the basis of first input data (5) for the application, hardware features (6) of the user component and / or information about a user (Ia) entitled to access the user component, this license descriptor can be transmitted to the license server component and can be checked by the license server component as to whether access authorization of the first input data (5), the user component and / or the user to the application is given;

wherein, if this access authorization is available from the license server component, a license token enabling access to the application

(8) can be generated and transmitted to the user component, wherein by the user component of the license token or license information based thereon (8 ') as well as second input data (5') for the application to the resource component can be transmitted and

wherein the license token or the license information can be checked by the resource component and / or the application to determine whether the access authorization of the second input data (5 '), the user component and / or the

User is given to the application.

2. Computer arrangement according to the preceding claim, characterized in that the license descriptor can be checked by the license server component to determine whether access authorization of the user component and / or the user to the application is given for the first input data (5)

and / or that the license token or the license information can be checked by the resource component and / or the application to determine whether the access authorization of the user component and / or of the user to the application is given for the transmitted second input data (5 ').

3. Computer arrangement according to one of the preceding claims,

characterized in that the license descriptor comprises a cryptographic code, in particular a hash code, calculated from the first input data (5), the hardware features (6) and / or the information about the authorized user

and / or that the license descriptor comprises user identification data for identifying the user component and / or the authorized user.

4. Computer arrangement according to one of the preceding claims, characterized in that the license descriptor based on hardware properties and / or hardware-based features of the user component, in particular a dongle, and / or electronic ID cards of the user, in particular a smart card can be generated.

5. Computer arrangement according to one of the preceding claims,

characterized in that

the license token of the license server component at least partially in cryptographically encrypted form, in particular in a secret key of a public-key infrastructure encrypted form, can be generated, the license token preferably by digital signature at least the license descriptor or a part thereof can be generated.

ά

6. Computer arrangement according to one of the preceding claims,

characterized in that the license token or the license information can be decrypted by the resource component and / or the application on the basis of cryptographic properties of the license token, in particular on the basis of a unique signature and / or on the basis of a provided by the license server component public key and / or to that effect is / are verifiable, whether the access authorization is given to the application and / or whether the license token has not been modified.

7. Computer arrangement according to one of the two preceding claims, characterized in that

a public-key infrastructure, in particular an X.509-based public-key infrastructure, can be used and / or realized as a cryptographic infrastructure.

8. Computer arrangement according to one of the preceding claims and according to claim 3, characterized in that by means of the resource component and / or the

Application, a cryptographic code, in particular a hash code, from the second input data (5 ') and / or from the user component to the resource component transmitted hardware features and / or information about the user can be calculated and with the kryp- tographic code, in particular the hash code, the first input data (5), the hardware features (6) and / or the information about the authorized user of the license descriptor transmitted to the license server component, which communicates with the license token via the user component to the resource component was comparable.

9. Computer arrangement according to one of the preceding claims, characterized in that

the first input data (5) are represented by a cryptographic code, in particular a hash code, and this can be communicated with and / or bound to the license descriptor by the user component to the license server component and / or

in that the second input data (5 ') or parts thereof together with and / or bound to the license token can be transmitted from the user component to the resource component.

10. Computer arrangement according to one of the preceding claims,

characterized in that

the license descriptor can be generated with a license duration desired by a user who is authorized to access the user component, and / or the license token can be generated with a license period determined by the license server component, preferably on the basis of the desired license duration, wherein a license duration defines a time window during which an access authorization to the application is given.

11. Computer arrangement according to one of the preceding claims, characterized in that

can be calculated by the resource component from the second input data (5 ') by means of the application output data (9) and transmitted to the user component.

12. Computer arrangement according to one of the preceding claims,

characterized in that

the first input data (5) and the second input data (5 ') are identical.

13. Computer arrangement according to the preceding claim,

characterized in that

the license descriptor comprises a cryptographic code calculated from the input data, in particular a cryptographic hash code, in that the license descriptor together with this code can be transmitted by the user component to the license server component, that the license descriptor together with

ύ Code in the license server component cryptographically signable and as a license token with integrated, encrypted cryptographic code from the license server component to the user component and from there together with the

Input data to the resource component is transferable, that from the resource component and / or the application, the cryptographic signature of the license server is verifiable and from the input from the user component to the resource component input data in the same manner as the code contained in the license descriptor a cryptographic That the code originating from the license token can be compared with the code calculated by the resource component and / or the application, and that in the case of matching codes, the access authorization of the input data, the user component and / or the user can be granted to the application, wherein preferably also in the license token coded and / or contained restrictions, in particular a license period, are considered in the grant.

14. Computer arrangement according to one of the preceding

Claims, characterized in that after an operation performed by the application with the second input data (5 '), the time duration of this operation is added by the resource component and / or the application to the license token and the license token, optionally together with output data (9) of the operation , from the resource component can be transferred to the user component.

15. Computer arrangement according to one of the preceding claims, characterized in that

at least two of the three components, ie the

User component, the license server component and the resource component, on two separate, different computers can be formed and / or formed and / or as two separate, different

Calculator can be formed and / or trained.

16. Computer arrangement according to the preceding claim,

marked by

three separate computers, wherein the user component on a user's computer (IPC), the license server component separately on a license server (2PC) and the resource component separately from the user computer (IPC) and the license server (2PC) on a resource calculator (3PC) can be formed and / or is embodied, and / or wherein the three components can be designed and / or formed correspondingly as three different computers or

by two separate computers, wherein the user component and the resource component can be formed on a common user and resource computer and the license server component separately on a license server is and / or is formed, and / or wherein the three components are formed as two different computers and / or formed accordingly

or by two separate computers, wherein the license server component and the resource component on a common license server and resource computer and the user component separately on a user computer can be formed and / or formed, and / or wherein the three components are formed as two different computers and / or or are trained.

17. Computer arrangement according to one of the preceding claims, characterized in that

the computer arrangement comprises at least two computers connected via a local and / or global network, in particular the Internet, in particular PCs.

18. Access control and access control method for an application in a computer arrangement,

wherein at least one user component (1) and a license server component (2) are set up for bidirectional data exchange with each other,

wherein at least one resource component (3) that controls and / or includes an application (4) for bidirectional data exchange with the user component is formed, wherein of the user component based on first input data (5) for the application, of hardware features (6) of the user component and / or information about a on the

User component (ia) a license descriptor (7) is generated, this license descriptor is transmitted to the license server component and is checked by the license server component to determine whether an access authorization of the first input data (5), the user component and / or the user to the Given that this access authorization by the license server component, a license token (8) enabling access to the application is generated and transmitted to the user component, whereby by the user component of the license tokens or license information based on this (8 ') and second Input data (5 ') for the application to the resource component, and wherein the license token or license information is provided by the resource component and / or the

Application is checked to see whether the access authorization of the second input data (5 '), the user component and / or the user is given to the application.

19. Access control and access control method according to the preceding claim, characterized in that the method is carried out with a computer arrangement according to one of claims 1 to 17.

20. Use of a computer arrangement and / or an access control and access control method according to one of the preceding claims for applications in which an access control on the basis of user information and / or input data is to take place independently of a network connection to a license server, for performing Simulation calculations, in particular simulation simulations in a simulation environment virtually simulating a complex technical system such as a plant for energy generation, a medical X-ray and / or irradiation system or a fluid transport system with a simulation program as an application formed on and / or by the resource component and / or controlled; / or to manage accessibility in virtualized environments, especially in VMWare environments or Xen-based environments.