WO2010009896A1 - Rechneranordnung mit automatisierter zugriffssteuerung von einer und zugriffskontrolle auf eine applikation sowie entsprechendes zugriffssteuerungs- und zugriffskontrollverfahren - Google Patents

Rechneranordnung mit automatisierter zugriffssteuerung von einer und zugriffskontrolle auf eine applikation sowie entsprechendes zugriffssteuerungs- und zugriffskontrollverfahren Download PDF

Info

Publication number
WO2010009896A1
WO2010009896A1 PCT/EP2009/005389 EP2009005389W WO2010009896A1 WO 2010009896 A1 WO2010009896 A1 WO 2010009896A1 EP 2009005389 W EP2009005389 W EP 2009005389W WO 2010009896 A1 WO2010009896 A1 WO 2010009896A1
Authority
WO
WIPO (PCT)
Prior art keywords
license
component
user
application
input data
Prior art date
Application number
PCT/EP2009/005389
Other languages
English (en)
French (fr)
Inventor
Mathias Dalheimer
Franz-Josef Pfreundt
Original Assignee
Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e. V.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e. V. filed Critical Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e. V.
Publication of WO2010009896A1 publication Critical patent/WO2010009896A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • G06F21/121—Restricting unauthorised execution of programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2115—Third party
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2135—Metering

Definitions

  • 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.
  • 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.
  • the user uses licenses that are available outside of their own organization, ie the resource provider or a corresponding resource calculator.
  • the user brings own licenses to the resource provider or to the resource calculator.
  • 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
  • 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.
  • 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.
  • 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.
  • 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:
  • 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.
  • the corresponding license server 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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:
  • 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.
  • 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.
  • Hardware elements or be designed as software and hardware elements.
  • 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. ).
  • 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).
  • a user component and a resource component can be installed on a common user and resource computer.
  • the license server component and a resource component on a common license server and resource computer.
  • the license server component is on a license ver formed separately from the user and resource calculator.
  • 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.
  • user component user computer, user, licensee, client, user client and user client;
  • License server component License server, license server, licensor and manufacturer of an application or software
  • resource component resource calculator, resource provider, resource provider, and calculation backend
  • 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:
  • 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).
  • batch programs can be used as input files.
  • 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
  • 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.
  • FIG. 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).
  • 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.
  • 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.
  • the user computer 1 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
  • 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
  • this cryptographic code can then be combined with user identification data for the license descriptor.
  • 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.
  • the license descriptor 7 is then sent to the license server
  • 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.
  • a public key infra - Structure for example, an X.509-based public key infrastructure
  • 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.
  • 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 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.
  • 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.
  • the resource calculator or by the application itself
  • 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.
  • 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.
  • a local computer network intranet within an organization
  • the license descriptor 7 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.
  • 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):
  • PKI Public Key Infrastructure
  • the licensee creates a license descriptor for the input data by sending a cryptographic hash of the input data to the licensor.
  • the licensee also adds a descriptor to the request with further personal data (user identification data).
  • 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.
  • 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):
  • the token refers to the input data (here: the hash codes match) and
  • CPU of the resource computer may be executed) are fulfilled.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 checks the signature for the computation time. If the signature is correct, the unused computation time is transferred back to the user's account.
  • 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).
  • a messaging service is required for the communication.
  • the underlying application consists of a user component and a calculation backend and the license is to be bound to an input file.
  • 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:
  • 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.
  • the input data set is first characterized by 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:
  • Clients are charged a specific cryptographic hash from the input data.
  • the license descriptor is compiled. To determine the identity of the user, the license descriptor is provided with a digital signature.
  • the license descriptor is packaged with the signature in a request and sent to the license server.
  • 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.
  • the license token is stored in a file and made available to the user.
  • the license server 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:
  • the received license descriptor is opened and the identity of the user is checked by means of his digital signature.
  • the request is authenticated, i. It is clear to whom the license request is to be assigned.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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:
  • the license token is opened and the signature of the license server is checked for validity.
  • 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.
  • 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.
  • only the messaging queue needs to be made accessible via the Internet so that no direct attacks on the license servers are possible.
  • 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.
  • the message with the key of the server can also be lost.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Storage Device Security (AREA)

Abstract

Die vorliegende Erfindung bezieht sich auf ein Rechnernetzwerk mit automatisierter Zugriffssteuerung von einer und Zugriffskontrolle auf eine Applikation, aufweisend einen Anwender rechner (1), einen zum bidirektionalen Datenaustausch mit dem Anwenderrechner ausgebildeten Lizenzserver (2) und einen zum bidirektionalen Datenaustausch mit dem Anwenderrechner ausgebildeten Ressourcenrechner (3), auf dem eine Applikation (4) installierbar ist und/oder installiert ist, wobei auf dem Anwenderrechner auf Basis von ersten Eingabedaten (5) für die Applikation und/oder von Hardwaremerkmalen (6) des Anwenderrechners ein Lizenzdeskriptor (7) generierbar ist, wobei dieser Lizenzdeskriptor an den Lizenzserver übermittelbar und durch den Lizenzserver dahingehend überprüfbar ist, ob eine Zugriffsberechtigung des Anwenderrechners und/oder der ersten Eingabedaten (5) auf die Applikation gegeben ist, wobei bei Vorliegen dieser Zugriffsberechtigung vom Lizenzserver ein den Zugriff auf die Applikation ermöglichender Lizenztoken (8) generierbar und an den Anwenderrechner übermittelbar ist, wobei durch den Anwenderrechner der Lizenztoken oder auf diesem basierende Lizenzinformationen (8') sowie zweite Eingabedaten (5') für die Applikation an den Ressourcenrechner übermittelbar sind und wobei der Lizenztoken oder die Lizenzinformationen durch den Ressourcenrechner und/oder die Applikation dahingehend überprüfbar ist/sind, ob die Zugriffsberechtigung des Anwenderrechners und/oder der zweite

Description

FRAUNHOFER-GESELLSCHAFT...e.V. 099PCT 0872
Rechneranordnung mit automatisierter Zugriffssteuerung von einer und Zugriffskontrolle auf eine Applikation sowie entsprechendes Zugriffssteuerungs- und
Zugriffskontrollverfahren
Die vorliegende Erfindung bezieht sich auf eine Rechneranordnung (nachfolgend alternativ auch als Rechnernetzwerk bezeichnet) mit automatisierter Zugriffssteuerung von und mit automatisierter Zugriffskontrolle auf eine oder mehrere Applikation (en) . Die vorliegende Erfindung bezieht sich darüber hinaus auf ein entsprechendes Zugriffssteuerungs- und Zugriffskontrollverfahren.
Heutige Rechnernetzwerke überschreiten, insbesondere beim sog. Grid-Computing, die Grenzen von einzelnen Organisationen bei der Benutzung von Rechenressourcen. Die Nutzung von reiner Rechenzeit und von Speicherplatz findet heutzutage häufig nicht mehr nur in- nerhalb einer einzelnen Organisation, sondern auch bei anderen Organisationen, also durch die eigene Organisation bei Dritten statt. Hierdurch treten Fragestellungen zu Tage, wie die Zugriffssteuerung und die Zugriffskontrolle auf Applikationen bei fremden Orga- nisationen bzw. Dritten automatisch ermöglicht werden kann. Es ist insbesondere zu klären, in wiefern Lizenzen in einem solchen Rechnernetzwerk bzw. im Grid- Umfeld benutzt werden können. Unter einer Lizenz wird hierbei eine Erlaubnis eines Rechners der eigenen Or- ganisation (Anwenderrechner) und/oder eines Anwenders innerhalb der eigenen Organisation zum Zugriff auf ein Anwendungsprogramm bzw. eine Applikation, welche (s) auf einem anderen Rechner, insbesondere auf einem Ressourcenrechner, der von einer anderen Orga- nisation innerhalb des Rechnernetzwerkes zur Verfügung gestellt wird, installiert ist, verstanden. Lizenzen erlauben somit den Zugriff auf entfernt installierte Applikationen.
Grundsätzlich sind zwei Szenarien denkbar:
1. Der Anwender nutzt Lizenzen, die außerhalb der eigenen Organisation, also beim Ressourcenprovider bzw. auf einem entsprechenden Ressourcen- rechner, vorhanden sind.
2. Der Anwender bringt eigene Lizenzen mit zum Ressourcenprovider bzw. zum Ressourcenrechner.
Die gegenwärtig im Stand der Technik verwendeten automatisierten Zugriffssteuerungs- und Zugriffskontrollverfahren sehen dabei verschiedene Lizenzierungsmodelle vor, deren Realisierungen wie folgt zusammen gefasst werden können: 1. Eine Software bzw. Applikation wird mit einer sog. Node-Lock-Lizenz versehen, d.h. die Applikation wird an einen festen Rechner gebunden und kann nur dort benutzt werden. Diese Lizenzform erlaubt lediglich eine Nutzung vor Ort, d.h. in
Bezug auf Grid-Computing kann ein Anwender lediglich vorinstallierte Lizenzen verwenden. Eine Mitnahme einer eigenen Lizenz zum Ressourcenprovider ist somit nicht möglich.
2. Eine zweite technische Realisierung der Lizenzierung stellt die sog. Floating-Lizenz dar: Ein zentraler Server wird beim Lizenznehmer eingerichtet und mit der Anzahl der Lizenzen bzw. an- deren Vorgaben konfiguriert. So fragt bei jeder auszuführenden Aufgabe (beispielsweise: Berechnungsjob) die Applikation (z.B. Simulations- oder Berechnungssoftware) bei diesem Zentralserver an, ob momentan eine freie Lizenz verfügbar ist. Ist dies der Fall, kann diese Lizenz für die aktuell abzuarbeitende Aufgabe benutzt werden. Ist keine freie Lizenz verfügbar, so wird die Aufgabe nicht abgearbeitet.
3. Eine dritte Lizenzierungsform ist unter dem Namen „Named User" bekannt: Hierbei wird der Zugriff auf eine Applikation nur bestimmten Benutzern gestattet. Dabei wird die Applikation oft an den lokalen Benutzernamen gekoppelt.
Offensichtlich ist eine Node-Lock-Lizenz nur für Ressourcenanbieter möglich, die eine feste Anzahl von Lizenzen für die Nutzung im Grid bereitstellen. Ein Anwender kann hier nicht seine eigene Lizenz übermit- teln. Eine Nutzung einer Floating-Lizenz ist prinzipiell möglich. Die Lizenz kann beim Jobstart entweder von einem Lizenzserver des Anwenders oder des Ressourcenbetreibers abgerufen werden, unterliegt jedoch einigen Einschränkungen:
1. Der Lizenzserver muss vom Ort der Berechnung aus erreichbar sein, damit beim Jobstart die Lizenz freigegeben werden kann. Dies ist je nach Konfiguration der Netzwerkumgebung des Ressourcenproviders nicht gegeben und vor Beginn des Rechen- jobs auch nicht unbedingt überprüfbar.
2. Zum Start des Rechenjobs muss der entsprechende Lizenzserver auch tatsächlich eine Lizenz vorhalten. Sollte ein Job keine Lizenz vorfinden, so wird er sich beenden, ohne die Berechnung durchzuführen. Unter Umständen verliert der Anwender so diejenige Zeit, die der Job in einer Batchqueue gewartet hat. Eventuell fallen auch Kosten für die Reservierung der Ressourcen an.
Im Falle einer "Named User" -Lizenz muss die Identität eines Benutzers überprüft werden. Dabei ergibt sich im Grid-Umfeld jedoch das Problem der Delegation: Der lokale Benutzer ist nicht notwendigerweise auch der Benutzer, der den Job abgeschickt hat. Im Prinzip wäre es möglich, den ursprünglichen Benutzer über sein Zertifikat beim Abschicken eines Jobs zu ermitteln - diese Funktionalität ist jedoch in keiner Grid- Middleware vorgesehen und daher nicht einfach zu imp- lementieren.
Ausgehend vom Stand der Technik ist es daher die Aufgabe der vorliegenden Erfindung, eine Rechneranordnung für die automatisierte Zugriffssteuerung und/oder Zugriffskontrolle von Applikationen zur Verfügung zu stellen, in welcher einfach, schnell, auf genau definierte Art und Weise und mit einem hohen Schutz gegen die Umgehung der Zugriffssteuerung bzw. Zugriffskontrolle die Steuerung des Zugriffs auf eine oder mehrere Applikationen durch an die Rechneranord- nung angeschlossene Anwenderrechner bzw. durch an der Rechneranordnung tätige Anwender möglich ist. Aufgabe der vorliegenden Erfindung ist es darüber hinaus, ein entsprechendes automatisiertes Zugriffssteuerungsund Zugriffskontrollverfahren zur Verfügung zu stel- len.
Diese Aufgabe wird durch die Rechneranordnung gemäß Patentanspruch 1 sowie durch das Zugriffssteuerungsund Zugriffskontrollverfahren gemäß Patentanspruch 18 gelöst. Vorteilhafte Ausgestaltungsformen der erfindungsgemäßen Rechneranordnung bzw. des erfindungsgemäßen Verfahrens lassen sich dabei den jeweiligen abhängigen Ansprüchen entnehmen. Vorteilhafte Verwendungen einer solchen Anordnung oder eines solchen Verfahrens sind in den Verwendungsansprüchen beschrieben.
Nachfolgend wird die vorliegende Erfindung zunächst allgemein beschrieben und dann anhand eines allgemein gehaltenen Ausführungsbeispiels vorgestellt. Dem schließt sich ein spezielles Ausführungsbeispiel, in dem eine konkrete Implementierung bzw. Ausgestaltung eines erfindungsgemäßen Rechnernetzwerkes bzw. Zugriffssteuerungs- und Zugriffskontrollverfahrens beschrieben ist, an.
Die konkrete Kombination der einzelnen Merkmale, wie sie in dem allgemeinen und dem speziellen Ausführungsbeispiel beschrieben ist, ist für die Ausführung der Erfindung nicht unbedingt notwendig, d.h. im Rahmen der vorliegenden Erfindung können einzelne Merk- male der gezeigten Kombination gemäß den unabhängigen Patentansprüchen auch in anderen Kombinationen verwirklicht werden bzw. realisiert sein.
Eine erfindungsgemäße Rechneranordnung mit automatisierter Zugriffssteuerung von einer und Zugriffskontrolle auf eine Applikation weist eine Anwenderkomponente, eine zum bidirektionalen Datenaustausch mit der Anwenderkomponente ausgebildete Lizenzserverkom- ponente und eine zum bidirektionalen Datenaustausch mit der Anwenderkomponente ausgebildete Ressourcenkomponente, die eine Applikation steuert, die als Teil einer Applikation ausgebildet ist oder auf der eine Applikation installiert ist, auf. Selbstver- ständlich sind dabei in der Regel jeweils mehrere Anwenderkomponenten entsprechend mit der Lizenzserverkomponente und der (oder auch den mehreren) Ressourcenkomponente (n) verbunden. Erfindungsgemäß ist auf Basis von der Anwenderkomponente auf Basis von ersten Eingabedaten für die Applikation und/oder von Hardware-Merkmalen der Anwenderkomponente ein Lizenzdeskriptor generierbar. Dieser Lizenzdeskriptor ist dann an die Lizenzserverkomponente übermittelbar und durch letztere dahingehend überprüfbar, ob eine Zugriffsberechtigung der Anwenderkomponente, eines Anwenders und/oder der ersten Eingabedaten auf die Applikation gegeben ist. Bei Vorliegen einer solchen Zugriffsberechtigung ist dann von der Lizenzserverkomponente ein den Zugriff auf die Applikation ermög- lichender Lizenztoken generierbar und an die Anwenderkomponente übermittelbar. Durch die Anwenderkomponente sind dann der Lizenztoken (oder auf diesem basierende Lizenzinformationen) sowie zweite Eingabedaten für die Applikation an die Ressourcenkomponente übermittelbar. Der Lizenztoken (oder die Lizenzinformationen) ist/sind dann durch die Ressourcenkomponen- te und/oder die Applikation dahingehend überprüfbar, ob die Zugriffsberechtigung der Anwenderkomponente, des Anwenders und/oder der zweiten Eingabedaten auf die Applikation gegeben ist. Ist dies der Fall, dann kann die Applikation die ihr übermittelten zweiten
Eingabedaten verwenden, also beispielsweise mit diesen Eingabedaten Berechnungen durchführen und die Ergebnisse dieser Berechnungen an die Anwenderkomponente zurück übermitteln.
In der Regel werden dabei die ersten Eingabedaten mit den zweiten Eingabedaten identisch sein (diese Daten werden daher nachfolgend meist auch vereinfacht als Eingabedaten ohne weitere Spezifikation bezeichnet) . Es ist jedoch auch denkbar, dass der Anwender zunächst basierend auf ersten Eingabedaten für die Applikation einen Lizenzdeskriptor generiert, diesen dann an die Lizenzserverkomponente übermittelt und den dann auf Basis der ersten Eingabedaten generier- ten und zurück übermittelten Lizenztoken empfängt.
Der Anwender kann dann die ersten Eingabedaten (beispielsweise wenn er feststellt, dass noch zusätzliche Berechnungen notwendig sind) durch andere für die Applikation geeignete Eingabedaten (zweite Eingabeda- ten) austauschen und diese dann, zusammen mit dem Lizenztoken (der einen solchen Austausch in diesem Falle zulässt) an die die eigentlichen Berechnungen durchführende Ressourcenkomponente übermitteln.
Die erfindungsgemäße Rechneranordnung kann insbesondere im Bereich der Simulation von technischen Systemen eingesetzt werden: Bei der Simulation solcher Systeme (z.B. bei der Simulation von medizinischen Röntgensystemen oder auch Therapiesystemen, bei- spielsweise Strahlentherapiesystemen) sind häufig bei der virtuellen Abbildung des entsprechenden techni- sehen Systems in einem Rechnersystem eine Vielzahl von Berechnungen (z.B. Monte Carlo-Simulationsrech- nungen oder ähnliches) notwendig, die, damit der Anwender nicht zu lange auf die Rechenergebnisse warten muss, auf mehrere einzelne Ressourcenkomponenten verteilt werden müssen.
Wie dem Fachmann unmittelbar klar ist, können die einzelnen Komponenten je nach konkreter Systemanfor- derung sowohl als Software-Elemente, als auch als
Hardware-Elemente, oder als Software- und Hardware- Elemente ausgebildet sein. Wird von einem Client oder von einem Server gesprochen, so ist dies z.B. nicht einschränkend dahingehend zu verstehen, dass der Client als Software ausgebildet sein muss und der Server als Hardware (so kann beispielsweise ein Client als reine Software-Lösung realisiert sein, es kann sich dabei jedoch auch um ein Rechnersystem mit entsprechend installierten Komponenten handeln, usw. ) .
In der Regel werden die einzelnen Komponenten, also die Anwenderkomponente (n) , die Ressourcenkomponente (n) und die Lizenzserverkomponente jeweils auf ge- trennten, separaten Einzelrechnern installiert sein (bzw. als entsprechende Einzelrechner ausgebildet sein) . Es ist jedoch alternativ dazu auch möglich, mehr als eine Komponente auf ein und demselben Einzelrechner (z.B. PC) auszubilden: So können bei- spielsweise eine Anwenderkomponente und eine Ressourcenkomponente auf einem gemeinsamen Anwender- und Ressourcenrechner installiert sein. Ebenso ist es denkbar, die Lizenzserverkomponente und eine Ressourcenkomponente auf einem gemeinsamen Lizenzserver- und Ressourcenrechner auszubilden. Im ersten Fall ist dann die Lizenzserverkomponente auf einem Lizenzser- ver getrennt vom Anwender- und Ressourcenrechner ausgebildet. Im zweiten Fall ist dann mindestens eine Anwenderkomponente getrennt vom Lizenzserver- und Ressourcenrechner auf einem separaten Einzelrechner ausgebildet, der dann über ein Netzwerk (beispielsweise das Internet) mit dem gemeinsamen Lizenzserverund Ressourcenrechner verbunden ist.
Im Rahmen der weiteren Beschreibung der Erfindung werden daher nachfolgend die folgenden Synonyme verwendet (jede Nummer bezeichnet synonym verwendete Ausdrücke) :
1. Rechneranordnung, Rechnernetzwerk, Grid-Umgebung und Grid-Umfeld;
2. Anwenderkomponente, Anwenderrechner, Anwender, Lizenznehmer, Client, Anwenderclient und Benutzerclient;
3. Lizenzserverkomponente, Lizenzserver, Lizenzgeber und Hersteller einer Applikation bzw. Software ;
4. Ressourcenkomponente, Ressourcenrechner, Ressourcenprovider, Ressourcenanbieter und Berech- nungsbackend;
5. Lizenztoken, Token und Lizenz.
Bei der vorliegenden Erfindung werden die Lizenztoken somit vorteilhafterweise je nach Bedarf erzeugt und in den entsprechenden Dateien gespeichert, d.h. sie können auf andere Rechner transferiert werden. Dabei ist, wie nachfolgend noch beschrieben wird, kein Missbrauch zu befürchten. Es sind die folgenden Einsatzszenarien realisierbar:
1. Der Lizenztoken wird an eine Eingabedatei für eine Applikation gekoppelt. Die Lizenz bezieht sich dabei bevorzugt auf die Verwendung der Applikation mit genau dieser Eingabedatei (wie vorbeschrieben, ist es jedoch auch möglich, die Lizenz auf Verwendung der Applikation mit anderen, gegebenenfalls ausgetauschten oder ergänz - ten Eingabedaten zu beziehen) . Beispielsweise können Batch- Programme als Eingabedatei verwendet werden.
2. Daneben (oder auch zusätzlich) kann das erfin- dungsgemäße System auch zur dynamischen Zuweisung von Floating-Lizenzen verwendet werden. Dabei wird die Lizenz nicht an eine Eingabedatei, sondern an die lokale Hardware gebunden. So kann beispielsweise ein Benutzer eines Pre-Processing Tools für ein Simulationsprogramm für eine
Dienstreise eine Lizenz für sein Notebook erstellen, welche dann an die Hardware des Notebooks (CPU-ID, MAC-Adresse etc.) gebunden ist.
Im Folgenden wird die vorliegende Erfindung zunächst anhand der Verknüpfung von Lizenzen mit den Eingabedaten beschrieben. Danach werden kurz die notwendigen Anpassungen für Hardware-gebundene Lizenzen beschrieben. Es folgt ein spezielles Ausführungsbeispiel mit einem konkreten Systementwurf sowie mit einer konkreten Umsetzung.
Es zeigen:
Figur 1 eine erfindungsgemäße Rechneranordnung, bei der die Anwenderkomponente, die Lizenzser- verkomponente und die Ressourcenkomponente jeweils als separate Einzelrechner realisiert sind (und daher auch so bezeichnet werden) in Übersicht;
Figur 2 ein Beispiel für einen Lizenzdeskriptor;
Figur 3 die Architektur eines konkret implementierten Lizenzdienstes in einem erfindungsgemä- ßen Rechnernetzwerk;
Figur 4 eine konkrete Implementierung eines Lizenzdeskriptors .
Figur 1 zeigt ein Beispiel für den grundlegenden Aufbau eines erfindungsgemäßen Rechnernetzwerkes mit automatisierter Zugriffssteuerung und Zugriffskontrolle. Das Netzwerk weist einen als PC IPC ausgebildeten Anwenderrechner 1 auf (der die Anwenderkompo- nente bildet) , der zum bidirektionalen Datenaustausch mit einem als PC 2PC ausgebildeten Lizenzserver 2 (der die Lizenzserverkomponente bildet) ausgebildet ist (Pfeile oben) . Darüber hinaus ist der Anwenderrechner 1 auch zum bidirektionalen Datenaustausch mit einem als PC 3PC ausgebildeten Ressourcenrechner 3, der die Ressourcenkomponente bildet, ausgebildet (Pfeile unten im Bild) . Auf dem Ressourcenrechner ist eine Applikation 4 installiert, hier ein Simulationsprogramm, welches auf Basis von Eingabedaten Simula- tionsrechnungen durchführt.
In Figur 1 ist lediglich ein Anwenderrechner 1 gezeigt, es ist jedoch selbstverständlich auch möglich, eine Vielzahl entsprechend ausgebildeter Anwender- rechner jeweils zum bidirektionalen Datenaustausch mit dem Lizenzserver zu verbinden. Darüber hinaus ist es ebenso möglich, eine Vielzahl von Ressourcenrechnern 3 statt des lediglich einen gezeigten Ressourcenrechners zur Verfügung zu stellen, mit denen dann die Anwenderrechner jeweils zum bidirektionalen Da- tenaustausch verbindbar sind. Ein Anwenderrechner kann dabei mit mehreren Ressourcenrechnern verbunden werden oder umgekehrt .
Im Anwenderrechner 1 sind Eingabedaten 5 gespeichert, die so ausgebildet sind, dass die Applikation 4 mit ihnen zum Start einer Simulationsrechnung und zum Übermitteln der entsprechenden Simulationsergebnisse veranlasst werden kann. Aus diesen Eingabedaten 5 generiert der Anwenderrechner 1 einen Lizenzdeskriptor 7. Dies geschieht im vorliegenden Fall dadurch, dass der Anwenderrechner 1 aus den Eingabedaten 5 einen kryptographischen Code in Form eines Hash-Codes berechnet. Dieser berechnete Code wird dann zusammen mit Anwenderidentifikationsdaten, die der Identifika- tion des Anwenderrechners 1 und eines an ihm tätigen
Anwenders Ia dienen, zu dem Lizenzdeskriptor zusammen gefasst .
Alternativ oder kumulativ dazu ist es jedoch auch möglich, dass der Anwenderrechner 1 basierend auf Hardware-Merkmalen 6 des Anwenderrechners und/oder Informationen über den Anwender Ia (beispielsweise auf Basis einer CPU- Identifikationsnummer der CPU des Anwenderrechners oder einer MAC-Adresse des Anwender- rechners) einen kryptographischen Code in Form eines
Hash-Codes berechnet. Ebenso wie vorbeschrieben, kann dann dieser kryptographische Code mit Anwenderidentifikationsdaten zum Lizenzdeskriptor zusammengefasst werden. Zudem werden dem Lizenzdeskriptor Daten hinzugefügt, die notwendig sind, um dem Lizenzserver 2 zu ermöglichen, festzustellen, ob für die entsprechenden Einga- bedaten 5 eine Zugriffsberechtigung des Anwenderrechners (bzw. des Anwenders) auf die Applikation 4 gegeben ist.
Im vorliegenden Fall wird lediglich der aus den Ein- gabedaten 5 berechnete Hash-Code vom Anwenderrechner
1 an den Lizenzserver 2 übermittelt. Es ist jedoch auch möglich, zusätzlich zu diesem Hash-Code auch die Eingabedaten 5 selbst an den Lizenzserver 2 zu übermitteln (so dass diese dann für weitere Prüfungen etc. verwendet werden können) .
Der Lizenzdeskriptor 7 wird dann an den Lizenzserver
2 übermittelt, der die vorbeschriebene Zugriffsberechtigung überprüft. Ist eine entsprechende Zugriffsberechtigung gegeben (was der Lizenzserver 2 z.B. anhand einer vorab gespeicherten Tabelle mit Anwenderrechner- oder Kundendaten und Daten zur der Applikation 4 überprüfen kann) , so verschlüsselt der Lizenzserver 2 den Lizenzdeskriptor 7 kryptographisch mit einem geheimen Schlüssel einer Public-Key-Infra- struktur (beispielsweise einer X.509-basierten Public -Key- Infrastruktur) und bildet mittels dieser Verschlüsselung aus dem gegebenenfalls geeignet ange- passten oder ergänzten Lizenzdeskriptor 7 einen Li- zenztoken 8. Da eine entsprechende Zugriffsberechtigung auf die Applikation 4 gegeben ist, wird dieser Lizenztoken 8 anschließend vom Lizenzserver 2 zurück an den Anwenderrechner 1 übertragen. Im Anwenderrechner 1 werden dann die zum Start der Simulationsrech- nungen mittels der Applikation 4 zu verwendenden Eingabedaten 5' mit auf dem Lizenztoken 8 basierenden LizenzInformationen 8' verbunden und an den Ressourcenrechner 3 übermittelt. Im vorliegenden Fall werden vom Anwender des Anwenderrechners 1 diejenigen Eingabedaten zum Start des Simulationsvorganges der Appli- kation 4 vorgesehen, aus denen auch der Hash-Code des Lizenzdeskriptors berechnet wurde. Die Daten 5 entsprechen also den Daten 5' (Datengleichheit ist in der Figur durch 5' =5 gekennzeichnet) . Auch wird der Lizenztoken 8 selbst als diejenige Lizenzinformation 8' verwendet, die an den Ressourcenrechner 3 übertragen wird. Dies ist durch 8 '=8 gekennzeichnet.
Der vom Anwenderrechner 1 an den Ressourcenrechner 3 übermittelte Lizenztoken 8 wird dann durch die Appli- kation 4 im Ressourcenrechner 3 dahingehend überprüft, ob eine Zugriffsberechtigung der Eingabedaten 5 des Anwenderrechners 1 auf die Applikation 4 gegeben ist. Hierzu wird der Lizenztoken 8 durch die Applikation mittels des öffentlichen Schlüssels der oben erwähnten Public-Key-Infrastruktur (der vom Lizenzserver zur Verfügung gestellt wird und bereits im Ressourcenrechner 3 abgespeichert wurde) zunächst entschlüsselt und dann entsprechend geprüft. Zusätzlich wird durch den Ressourcenrechner (oder auch durch die Applikation selbst) ein kryptographischer Code in Form eines Hash-Codes auf dieselbe Art und Weise aus den Eingabedaten 5 berechnet wie im Anwenderrechner 1. Dieser im Ressourcenrechner 3 berechnete Hash-Code wird dann mit dem Hash-Code verglichen, der im Lizenzdeskriptor 7 zunächst vom Anwenderrechner 1 an den Lizenzserver 2 und dann im verschlüsselten Lizenzdeskriptor, also im Lizenztoken 8, vom Lizenzserver 2 über den Anwenderrechner 1 an den Ressourcenrechner 3 übermittelt wurde. Nur wenn diese beiden Hash-Codes übereinstimmen (und nach erfolgreicher Entschlüsselung und Überprüfung des Lizenztokens 8 mit dem öffentlichen Schlüssel) , startet die Applikation 4 mit den übermittelten Eingabedaten 5 ihre Simulationsrechnung. Die durch die Applikation aus den Eingabedaten 5 berechneten Ausgabedaten 9 (Simu- lationsergebnisse) werden dann vom Ressourcenrechner 3 an den Anwenderrechner 1 übertragen.
Im beschriebenen Fall geschieht die bidirektionale Datenübertragung zwischen den Einheiten 1, 2 und 3 im Rahmen des erfindungsgemäßen Rechnernetzwerkes über das Internet. Es kann jedoch selbstverständlich auch ein lokales Rechnernetzwerk (Intranet innerhalb einer Organisation) eingesetzt werden.
Im Rahmen des beschriebenen Ausführungsbeispiels ist es auch möglich, dass der Lizenzdeskriptor 7 vom Anwenderrechner 1 mit einer vom Anwender gewünschten Dauer für die Lizenz für die Applikation 4 generiert wird. Der Lizenzdeskriptor 7 wird dann mit dieser Information an den Lizenzserver 2 übertragen, der feststellt, ob eine gewünschte Lizenzdauer möglich ist (dies kann beispielsweise anhand eines Anwenderkontos eines Anwenders 1 auf dem Lizenzserver 2 geschehen) . Der Lizenztoken 8 wird dann vom Lizenzser- ver 2 mit einer entsprechend festgesetzten Lizenzdauer generiert. Die Lizenzdauer ist dabei so definiert, dass mit ihr dem Ressourcenrechner 3 letztendlich ein Zeitfenster übermittelt wird, während dessen die Applikation 4 auf Basis der Eingabedaten 5 Simulations- rechnungen durchführen kann.
Darüber hinaus ist es auch möglich, nach Durchführung der Simulationsrechnungen durch die Applikation 4 dem Lizenztoken 8 die Zeitdauer, die die Simulationsrech- nungen auf dem Ressourcenrechner 3 benötigt haben, hinzuzufügen und den entsprechend ergänzten Lizenzto- ken 8 zusammen mit den Ausgabedaten 9 zurück an den Anwenderrechner 1 zu übertragen.
Wenn somit der Anwender 1 seine Eingabedatei 5 für einen Rechenjob an einen externen Ressourcenprovider
4 übertragen möchte, muss er beim Hersteller der Software bzw. beim Lizenzserver einen Lizenztoken 8 für seine Eingabedaten erstellen lassen. Der Hersteller sichert über diesen Mechanismus zu, dass für die- se Berechnung eine Lizenzvereinbarung existiert. Der Lizenztoken 8 wird dann zusammen mit den Eingabedaten
5 an den Ressourcenprovider 3 weitergeleitet. Beim Start der Applikation 4 kann diese dann den Lizenztoken prüfen und die Berechnungen ausführen.
Eine sichere Implementierung muss v.a. Schutz vor Manipulationen bieten bzw. die Wiederverwendung von Schlüsseln für andere Berechnungen verhindern. Dies kann beispielsweise einfach durch die Verwendung ei- ner X.509-basierten Public-Key-Infrastruktur (PKI) erreicht werden: Der Lizenznehmer erstellt einen Lizenzdeskriptor für die Eingabedaten, indem er einen kryptographischen Hash der Eingabedaten zum Lizenzgeber schickt. Gleichzeitig fügt der Lizenznehmer der Anfrage auch einen Deskriptor mit weiteren Daten zur eigenen Person (Anwenderidentifikationsdaten) bei . Auf dieser Basis kann der Lizenzgeber dann beispielsweise entscheiden, ob der Lizenznehmer bereits bekannt ist und ob ihm die Zugriffsberechtigung gegeben werden kann. Eventuell können hier auch Angaben zur Art der gewährleisteten Lizenz übertragen werden.
Ein Beispiel für einen solchen Lizenzdeskriptor 7 ist in Figur 2 gegeben. Die entsprechenden Angaben müssen natürlich beim Lizenzgeber verarbeitet werden können. Sollte die Prüfung der Kundenanfrage den Anforderungen des Lizenzgebers genügen, so unterzeichnet er den Lizenzdeskriptor 7 mit seinem geheimen X.509- Schlüssel und schickt diesen als Lizenztoken 8 zum Lizenznehmer 1 zurück.
Der Lizenznehmer 1 überträgt dann seine Daten zusammen mit dem Lizenztoken 8 zu einem Ressourcenanbieter 3. Dieser hat zwar beispielsweise die Software des Lizenzgebers installiert, besitzt jedoch u.U. selbst keine Lizenz dafür.
Der Job wird ganz normal über ein Batchsystem gestartet. Die Applikation prüft nun mit Hilfe des öffent- liehen Schlüssels des Lizenzgebers den Lizenztoken und hat damit eine Vorbedingung für die Gültigkeit der Lizenz abgesichert. (Hier wird geprüft, ob der Lizenztoken tatsächlich vom Lizenzserver ausgestellt wurde,- die Prüfung, ob die Lizenz im Anschluss auch für diese Eingabedaten gilt, wird wie nachfolgend beschrieben durchgeführt.) Dann berechnet sie den kryp- tographischen Hash der Eingabe und vergleicht ihn mit dem signierten Hash aus dem Lizenztoken. Dies ist möglich, da der Lizenzdeskriptor mit dem von Anwender generierten Hash an den Lizenzserver übermittelt wird, dort in den Lizenztoken übernommen wird und anschließend an den Anwender- und den Ressourcenrechner übermittelt wird. Sollten diese übereinstimmen, dann liegt eine gültige Lizenz für diese Eingabedaten vor und die Berechnung kann starten.
Der Lizenzserver prüft somit, ob der Anwender Ia die Applikation benutzen darf. Dabei wird ein beispielsweise von den Applikationsdaten/Eingabedaten abhängi- ger Lizenztoken erstellt. Der Anwenderrechner muss diesen Lizenztoken prüfen, um das Vorliegen einer korrekten Lizenz für die gegebenen Eingabedaten sicherzustellen. Der Grund hierfür ist, dass der Ressourcenrechner und der Lizenzserver keine Kenntnis voneinander haben, d.h. es muss zum Zeitpunkt des Re- chenjobstarts keine Kommunikation nach außen erfolgen: Die Lizenzprüfung kann rein mit lokal vorhandenen Daten erfolgen. Im vorliegenden Fall müssen somit mehrere Bedingungen zutreffen, damit eine Lizenz für die Eingabedaten gültig ist (Prüfverfahren, das durch die Applikation und/oder den Ressourcenrechner durchgeführt wird) :
1. korrekte Signatur des Lizenztokens (der Token selbst ist unmodifiziert) ;
2. der Token bezieht sich auf die Eingabedaten (hier: die Hash-Codes stimmen überein) und
3. eventuell im Lizenztoken kodierte Einschränkun- gen (z.B. dass die Berechnungen nur auf einer
CPU des Ressourcenrechners ausgeführt werden dürfen) sind erfüllt.
Es ist somit für den Lizenzgeber sehr einfach, anwen- derindividuelle Lizenztoken in einem automatisierten Verfahren zu generieren. Dieser Schritt kann z.B. auch direkt in die Preprocessing-Tools der Lizenzgeber integriert werden. Es kann eine Art "Archiv" für die Submission zu einem Ressourcenprovider erstellt werden, welches neben den Eingabedaten auch die Lizenz für die Applikation beinhaltet. Der Lizenznehmer muss dann nur dieses Archiv zum Ressourcenprovider schicken.
Aus Sicht der Ressourcenprovider bietet dieses Lizenzierungsverfahren den Vorteil, dass die Applikation aus den Eingabedaten selbst die Lizenz prüft. Es ist nicht nötig, eine permanente Applikationslizenz vorzuhalten oder eine entsprechende Netzwerkkonfiguration für den Lizenzserver jedes Kunden zu pflegen. Im Falle eines fehlgeschlagenen Jobs (z.B. durch Rechnerausfälle) kann der Provider auch selbstständig den Job neu starten, ohne auf eine Lizenz warten zu müssen.
Der Anwender hat bei dieser Lösung den zusätzlichen Schritt der Lizenzgenerierung zu tragen, der jedoch komplett in Software abgewickelt werden kann. In Bezug auf das Handling der Eingabedaten empfiehlt es sich, innerhalb der Preprocessing-Tools eine Archiv- datei zu generieren, um den Transfer zum Ressourcenprovider einfach zu halten.
In Ergänzung zum Binden der Lizenztoken an eine Eingabedatei ist es auch möglich, die Lizenz an andere Gegebenheiten zu binden. Das Verfahren bleibt dabei unverändert - lediglich die Generierung des Hashes wird verändert: Im bisher beschriebenen Abschnitt wird der Hash aus den Eingabedaten berechnet. Für den Nutzer eines interaktiven Preprocessing-Tools ist dies natürlich keine Option, da womöglich noch keinerlei Eingabedaten existieren. Statt eines Hashes auf die Eingabedaten ist es hier jedoch möglich, die Benutzerumgebung durch einen Hash zu charakterisieren. Zusammen mit weiteren Daten kann daraus ein Li- zenzdeskriptor gebildet werden, welcher dann wie üblich zum Anfordern einer Lizenz (Lizenztoken) benutzt werden kann.
Der Hash stellt dabei eine Identifikation des Rech- ners des Benutzers dar, z.B. eine Kombination aus CPU-ID, MAC-Adresse etc. Folgendes Einsatzszenario ist dabei denkbar: Der Benutzer möchte eine für eine Woche gültige Lizenz auf seinem Notebook haben, z.B. um während eines Kundenbesuches unabhängig vom Netzwerk arbeiten zu können. Er startet den Lizenzclient auf dem Notebook, woraufhin dieser einen kryp- tographischen Hash aus den Hardware-Komponenten des Notebooks berechnet. Zusammen mit weiteren Daten, wie z.B. der gewünschten Lizenzdauer, entsteht ein Lizenzdeskriptor, der dann durch den Lizenzserver sig- niert werden kann. Dieser Lizenztoken kann dann in einer Datei abgespeichert werden.
Bei dem Starten der Applikation wird dann der Lizenztoken zunächst auf seine Gültigkeit geprüft und dann der aktuell kryptographische Hash aus der Hardware berechnet. Stimmen die beiden Hashes überein, so gelten die in dem Lizenzdeskriptor beschriebenen Lizenz - bedingungen .
In Anlehnung an Floating-Lizenzen in einem lokalen
Netzwerk kann es nötig sein, dass ein Benutzer seine Lizenz nach der Benutzung zurückgibt. Da es im Allgemeinen nicht möglich ist, mit dem Ressourcenrechner zu kommunizieren, auf dem die Berechnung läuft, kann die Rückgabe nur indirekt erfolgen. Dazu wird die Lizenz für eine längere Zeit ausgestellt, als der Job wirklich benötigt. Nach Ablauf der Rechnung protokolliert die Applikation die in Anspruch genommene Rechenzeit .
Diese Protokollierung kann als weiteres Feld in den Lizenztoken mit aufgenommen und mit der Signatur des Applikationsbinaries versehen werden. Zusammen mit den Ausgabedaten der Applikation wird der Lizenztoken wieder zurück zum Benutzer übertragen. Dort kann der Lizenzclient den veränderten Lizenztoken wieder zu- rück an den Lizenzserver schicken.
Der Lizenzserver prüft seinerseits die Signatur in Bezug auf die Rechenzeit. Falls die Signatur in Ord- nung ist, wird die unbenutzte Rechenzeit zurück auf das Konto des Benutzers transferiert.
Nachfolgend wird eine konkrete Implementierung eines erfindungsgemäßen Rechnernetzwerkes beschrieben:
Der Lizenzierungsdienst besteht aus den bereits genannten Komponenten Benutzerclient (auf Anwenderrechner 1) , Lizenzserver 2 und Lizenzprüfer (Teil des Ressourcenrechners 3) . Darüber hinaus wird zur Kommuni- kation noch ein Messaging-Dienst benötigt. Für die folgende Diskussion der Komponenten wird davon ausgegangen, dass die zugrunde liegende Applikation aus einer Benutzerkomponente und einem Berechnungsbackend besteht und die Lizenz an eine Eingabedatei gebunden werden soll. Dabei werden zunächst die Komponenten einzeln dargestellt, anschließend das Kommunikations- protokoll. Einen Überblick über die verwendeten Komponenten gibt Figur 3.
Der Benutzerclient:
Der Benutzerclient ist eine Softwarekomponente, welche direkt in die Endanwender-Applikation integriert werden kann. Die Aufgabe des Benutzerclients ist es, für einen gegebenen Eingabedatensatz einen Lizenz - Schlüssel vom Lizenzserver anzufordern.
Dazu wird der Eingabedatensatz zunächst durch einen Hash charakterisiert. Neben einem Hash müssen auch weitere Informationen bezüglich der Anwendung zusammengestellt werden, z.B. wie viele CPUs verwendet werden sollen. Ein Beispiel eines Lizenzdeskriptors zeigt Figur 4. Der interne Ablauf des Benutzerclients sieht so aus:
1. In Abhängigkeit von der Konfiguration des
Clients wird ein bestimmter kryptographischer Hash aus den Eingabedaten berechnet.
2. Der Lizenzdeskriptor wird zusammengestellt. Um die Identität des Benutzers feststellen zu können, wird der Lizenzdeskriptor mit einer digitalen Signatur versehen.
3. Der Lizenzdeskriptor wird mit der Signatur in eine Anfrage verpackt und zum Lizenzserver geschickt .
4. Die Antwort des Servers enthält einen verschlüsselten Lizenztoken. Der Client fragt den Server nochmals nach dem Entschlüsselungskey. Mit diesem entschlüsselt der Client den Lizenztoken.
5. Der Lizenztoken wird in einer Datei gespeichert und dem Benutzer zugänglich gemacht.
Falls unbenutzte Rechenzeiten wieder zurückgebucht werden sollen, wird der modifizierte Lizenztoken nach Abschluss der Berechnung wieder zum Lizenzserver übermittelt. Sollte hierbei ein Fehler auftreten, wird der Benutzer benachrichtigt. Der Lizenzserver:
Der Lizenzserver ist ein Dämon, der permanent auf eingehende Lizenzanfragen wartet und diese beantwor- tet. Ein gültiger Lizenztoken wird erzeugt, indem der Lizenzdeskriptor vom Benutzerclient mit der Signatur des Servers versehen wird. Der interne Ablauf sieht so aus :
1. Der empfangene Lizenzdeskriptor wird geöffnet und die Identität des Benutzers anhand seiner digitalen Unterschrift überprüft. Damit ist die Anfrage authentifiziert, d.h. es ist klar, wem die Lizenzanfrage zuzuordnen ist.
2. Dann muss der Anwender autorisiert werden, d.h. aufgrund einer Kundendatenbank etc. wird entschieden, ob der Anwender diese Lizenz überhaupt anfragen darf. Dabei können Details der ange- fragten license-terms (z.B. Anzahl der CPUs, Berechnungsmodule) überprüft werden. Diese Funktionalität ist in einem separaten Lizenzmanagement-Plugin gekapselt.
3. Schließlich wird der Lizenzdeskriptor mit dem geheimen Schlüssel des Lizenzservers signiert. Der Server vergibt für diese Anfrage einen symmetrischen Key und verschlüsselt den Lizenztoken damit. Der Lizenztoken wird nun zurückgeschickt.
4. Der Server wartet auf die Nachfrage des Clients nach dem Key. Falls diese Anfrage eingeht, weiß der Server, dass der Lizenztoken beim Client angekommen ist. Der Server antwortet mit dem Key, um die Lizenz freizuschalten. Die Antwort des Lizenzservers fügt dem Lizenzdeskriptor also eine Signatur hinzu, wenn die Lizenz gültig ist. Dieser Lizenztoken bezeugt die Gültigkeit einer Lizenz zu den Bedingungen, die im Lizenzdeskriptor genannt sind.
Wenn der Lizenzclient nach Ende des Rechenjobs einen unterschriebenen Lizenztoken zurückgeben will, so wird dieser im Hinblick auf die verbrauchte Rechen- zeit ausgewertet.
Der Lizenzprüfer:
Diese Komponente wird direkt in das Berechnungsba- ckend integriert. Ihre Aufgabe ist es, die Gültigkeit eines Lizenztokens zu überprüfen. Dazu werden folgende Schritte durchgeführt:
1. Der Lizenztoken wird geöffnet und die Signatur des Lizenzservers auf ihre Gültigkeit überprüft.
2. Die license-terms des Deskriptors werden geprüft und die entsprechenden Module des Berechnungsba- ckends freigegeben.
3. Der Hash der Eingabedaten wird berechnet und mit dem Wert im Lizenzdeskriptor verglichen. Wenn bis hierher alle Prüfungen erfolgreich sind, ist die Lizenz für diesen Eingabedatensatz gültig.
Wichtig hierbei ist, dass der Lizenzprüfer lediglich den öffentlichen Schlüssel des Lizenzservers kennen muss. Es ist nicht erforderlich, Netzwerkverbindungen zum Lizenzserver aufzubauen - die Prüfung des Lizenz- deskriptors kann lokal erfolgen. Nach Ablauf der Berechnung kann der Lizenzprüfer die verbrauchte Rechenzeit im Lizenztoken dokumentieren und signieren. Der Token kann dann mit den Ergebnissen zurück zum Anwender kopiert werden.
Der Lizenzserver und der Benutzerclient tauschen lediglich kompakte Nachrichten aus, es ist nicht erforderlich, größere Datenmengen auszutauschen. Es ist daher möglich, die Kommunikation über eine Messaging- Queue abzuwickeln. Dabei können mehrere physikalische Lizenzserver zu einem logischen verknüpft werden, um die Ausfallsicherheit zu erhöhen. Darüber hinaus muss lediglich die Messaging-Queue über das Internet zugänglich gemacht werden, sodass keine direkten An- griffe auf die Lizenzserver möglich sind.
Das Protokoll:
Unter der Voraussetzung, dass die Nachrichtenüber- mittlung zwischen Lizenzclient und Lizenzserver fehlerfrei und zuverlässig funktioniert, kann man ein sehr einfaches Protokoll realisieren. Das Protokoll muss jedoch auch bei fehlerhaften Netzwerkverbindungen funktionieren.
Bei genauerer Betrachtung stellte sich heraus, dass der Austausch des Lizenztokens auf das Problem der byzantinischen Generäle zurückgeführt werden kann: Wie können zwei Parteien eine konsistente Sicht auf die Übertragung der Lizenztoken haben? Dieses Problem ist nicht generell lösbar. Zur Veranschaulichung kann man sich vorstellen, was passiert, wenn einzelne Nachrichten verloren gehen: Angenommen, der Client fragt eine Lizenz beim Server an. Er erhält die Li- zenz, allerdings antwortet er nicht mehr darauf. Der Server kann nun nicht entscheiden, ob der Client die Lizenz erhalten hat oder ob die Lizenz nie beim Client angekommen ist.
Um dennoch die Übertragung des Lizenztokens sicher zu machen, wurde eine zusätzliche Komponente (der
Schlüssel bzw. Key) in das Protokoll eingefügt. Der Key verschlüsselt den Lizenztoken symmetrisch. Nachdem der Client den verschlüsselten Lizenztoken erhalten hat, fragt er nochmals beim Lizenzserver nach dem zugehörigen Key. Dabei gibt er eine Transaktionsnummer an, die im gleichen Datenpaket wie der Lizenztoken vom Server übermittelt wurde. Wenn die Anfrage nach dem Key beim Server mit der korrekten Transaktionsnummer empfangen wurde, dann kann die Lizenz end- gültig berechnet werden.
Die Nachricht mit dem Key des Servers kann allerdings auch verloren gehen. In diesem Fall kann der Client dem Benutzer eine Nachricht anzeigen mit der Transak- tionsnummer - mit dieser kann sich der Benutzer dann an den Lizenzgeber wenden und den Freischaltkey anfragen.
Zusammenfassend lässt sich sagen, dass dieser Fall zwar nicht ausgeschlossen werden kann, insgesamt jedoch recht unwahrscheinlich ist. Es ist nicht damit zu rechnen, dass der Benutzer oft beim Lizenzgeber nach einem Freischaltkey nachfragen muss.
ή

Claims

Patentansprüche
1. Rechneranordnung mit automatisierter Zugriffssteuerung von einer und Zugriffskontrolle auf eine Applikation, aufweisend
mindestens eine Anwenderkomponente (1) , eine zum bidirektionalen Datenaustausch mit der Anwenderkomponente ausgebildete Lizenzserverkomponente ( 2 ) und mindestens eine zum bidirektionalen Datenaustausch mit der Anwenderkomponente ausgebildete Ressourcenkomponente (3), wobei die Ressourcenkomponente (3) eine Applikation (4) steuert und/oder umfasst, wobei von der Anwenderkomponente auf Basis von ersten Eingabedaten (5) für die Applikation, von Hardwaremerkmalen (6) der Anwenderkomponente und/oder von Informationen über einen auf die Anwenderkomponente zugriffsberechtigten Anwender (Ia) ein Lizenzdeskriptor (7) generierbar ist, wobei dieser Lizenzdeskriptor an die Lizenzserverkomponente übermittelbar und durch die Lizenzserverkomponente dahingehend überprüfbar ist, ob eine Zugriffsberechtigung der ersten Eingabedaten (5) , der Anwenderkomponente und/oder des Anwenders auf die Applikation gegeben ist,
wobei bei Vorliegen dieser Zugriffsberechtigung von der Lizenzserverkomponente ein den Zugriff auf die Applikation ermöglichender Lizenztoken
(8) generierbar und an die Anwenderkomponente übermittelbar ist, wobei durch die Anwenderkomponente der Lizenztoken oder auf diesem basierende Lizenzinformationen (8') sowie zweite Eingabedaten (5') für die Applikation an die Ressourcenkomponente übermit- telbar sind und
wobei der Lizenztoken oder die Lizenzinformationen durch die Ressourcenkomponente und/oder die Applikation dahingehend überprüfbar ist/sind, ob die Zugriffsberechtigung der zweiten Eingabeda- ten (5'), der Anwenderkomponente und/oder des
Anwenders auf die Applikation gegeben ist.
2. Rechneranordnung nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass der Lizenzdeskriptor durch die Lizenzserverkomponente dahingehend überprüfbar ist, ob für die ersten Eingabedaten (5) eine Zugriffsberechtigung der Anwenderkomponente und/oder des Anwenders auf die Applikation gegeben ist
und/oder dass der Lizenztoken oder die Lizenzinformationen durch die Ressourcenkomponente und/oder die Applikation dahingehend überprüfbar ist/sind, ob für die übermittelten zweiten Eingabedaten (5') die Zugriffsberechtigung der Anwenderkomponente und/oder des Anwenders auf die Applikation gegeben ist.
3. Rechneranordnung nach einem der vorhergehenden Ansprüche ,
dadurch gekennzeichnet, dass der Lizenzdeskriptor einen aus den ersten Eingabedaten (5) , den Hardwaremerkmalen (6) und/oder den Informationen über den zugriffsberechtigten Anwender berechneten kryptographischen Code, insbesondere einen Hash-Code, umfasst
und/oder dass der Lizenzdeskriptor Anwenderidentifikati- onsdaten zur Identifikation der Anwenderkomponente und/oder des zugriffsberechtigten Anwen- ders umfasst.
4. Rechneranordnung nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Lizenzdeskriptor auf Basis von Hardwareei- genschaften und/oder hardwaregestützten Merkmalen der Anwenderkomponente, insbesondere eines Dongles, und/oder von elektronischen Ausweisen des Anwenders, insbesondere einer Smartcard, generierbar ist.
5. Rechneranordnung nach einem der vorhergehenden Ansprüche ,
dadurch gekennzeichnet, dass
der Lizenztoken von der Lizenzserverkomponente zumindest teilweise in kryptographisch ver- schlüsselter Form, insbesondere in mit einem geheimen Schlüssel einer Public-Key-Infrastruktur verschlüsselter Form, generierbar ist, wobei der Lizenztoken bevorzugt mittels digitaler Signatur zumindest des Lizenzdeskriptors oder eines Teils desselben generierbar ist.
ά
6. Rechneranordnung nach einem der vorhergehenden Ansprüche ,
dadurch gekennzeichnet, dass der Lizenztoken oder die Lizenzinformationen durch die Ressourcenkomponente und/oder die Applikation auf Basis von kryptographischen Eigenschaften des Lizenztokens, insbesondere auf Basis einer eineindeutigen Signatur und/oder auf Basis eines von der LizenzServerkomponente zur Verfügung gestellten öffentlichen Schlüssels entschlüsselbar und/oder dahingehend überprüfbar ist/sind, ob die Zugriffsberechtigung auf die Applikation gegeben ist und/oder ob der Lizenztoken nicht modifiziert wurde.
7. Rechneranordnung nach einem der beiden vorhergehenden Ansprüche, dadurch gekennzeichnet, dass
als kryptographische Infrastruktur eine Public- Key- Infrastruktur, insbesondere eine X.509 ba- sierte Public-Key-Infrastruktur einsetzbar ist und/oder realisiert ist.
8. Rechneranordnung nach einem der vorhergehenden Ansprüche und nach Anspruch 3 , dadurch gekennzeichnet, dass mittels der Ressourcenkomponente und/oder der
Applikation ein kryptographischer Code, insbesondere ein Hash-Code, aus den zweiten Eingabedaten (5') und/oder aus von der Anwenderkompo- nente an die Ressourcenkomponente übermittelten Hardwaremerkmalen und/oder Informationen über den Anwender berechenbar und mit dem kryp- tographischer Code, insbesondere dem Hash-Code, der ersten Eingabedaten (5) , der Hardwaremerkmale (6) und/oder der Informationen über den zugriffsberechtigten Anwender des an den Lizenz - Serverkomponente übermittelten Lizenzdeskriptors, der mit dem Lizenztoken über die Anwenderkomponente an die Ressourcenkomponente übermittelt wurde, vergleichbar ist.
9. Rechneranordnung nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass
die ersten Eingabedaten (5) durch einen kryp- tographischen Code, insbesondere einen Hash- Code, repräsentiert sind und dieser mit dem und/oder gebunden an den Lizenzdeskriptor von der Anwenderkomponente an die Lizenzserverkomponente übermittelbar ist und/oder
dass die zweiten Eingabedaten (5') oder Teile derselben zusammen mit dem und/oder gebunden an den Lizenztoken von der Anwenderkomponente an die Ressourcenkomponente übermittelbar sind.
10. Rechneranordnung nach einem der vorhergehenden Ansprüche ,
dadurch gekennzeichnet, dass
der Lizenzdeskriptor mit einer von einem auf die Anwenderkomponente zugriffsberechtigten Anwender gewünschten Lizenzdauer generierbar ist und/oder dass der Lizenztoken mit einer durch die Lizenz- serverkomponente bevorzugt auf Basis der gewünschten Lizenzdauer festgesetzten Lizenzdauer generierbar ist, wobei eine Lizenzdauer ein Zeitfenster definiert, während dessen eine Zugriffsberechtigung auf die Applikation gegeben ist.
11. Rechneranordnung nach einem der vorhergehenden Ansprüche , dadurch gekennzeichnet, dass
durch die Ressourcenkomponente aus den zweiten Eingabedaten (5') mittels der Applikation Ausgabedaten (9) berechenbar und an die Anwenderkomponente übermittelbar sind.
12. Rechneranordnung nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet, dass
die ersten Eingabedaten (5) und die zweiten Eingabedaten (5') identisch sind.
13. Rechneranordnung nach dem vorhergehenden Anspruch,
dadurch gekennzeichnet, dass
der Lizenzdeskriptor einen aus den Eingabedaten berechneten kryptographischen Code, insbesondere einen kryptographischen Hash-Code, umfasst, dass der Lizenzdeskriptor samt diesem Code von der Anwenderkomponente an die Lizenzserverkomponente übermittelbar ist, dass bei Vorliegen der Zugriffsberechtigung der Lizenzdeskriptor samt
ύ Code in der LizenzServerkomponente kryp- tographisch signierbar und als Lizentoken mit eingebundenem, verschlüsselten kryptographisehen Code von der Lizenzserverkomponente an die An- Wenderkomponente und von dieser zusammen mit den
Eingabedaten an die Ressourcenkomponente übertragbar ist, dass von der Ressourcenkomponente und/oder der Applikation die kryptographisehe Signatur des Lizenzservers überprüfbar ist und aus den von der Anwenderkomponente an die Ressourcenkomponente übertragenen Eingabedaten auf dieselbe Art und Weise wie beim in dem Lizenzdeskriptor enthaltenen Code ein kryptographi- scher Code berechenbar ist, dass der aus dem Li- zenztoken stammende Code mit dem von der Ressourcenkomponente und/oder der Applikation berechneten Code vergleichbar ist und dass bei übereinstimmenden Codes die Zugriffsberechtigung der Eingabedaten, der Anwenderkomponente und/oder des Anwenders auf die Applikation erteilbar ist, wobei bevorzugt auch gegebenenfalls im Lizenztoken codierte und/oder enthaltene Einschränkungen, insbesondere eine Lizenzdauer, bei der Erteilung berücksichtigbar sind.
14. Rechneranordnung nach einem der vorhergehenden
Ansprüche, dadurch gekennzeichnet, dass nach einer durch die Applikation mit den zweiten Eingabedaten (5') durchgeführten Operation die Zeitdauer dieser Operation von der Ressourcenkomponente und/oder der Applikation dem Lizenztoken hinzufügbar und der Lizenztoken anschließend, gegebenenfalls zusammen mit Ausgabedaten (9) der Operation, von der Ressourcenkomponente an die Anwenderkomponente übertragbar ist.
15. Rechneranordnung nach einem der vorhergehenden Ansprüche , dadurch gekennzeichnet, dass
mindestens zwei der drei Komponenten, also der
Anwenderkomponente, der LizenzServerkomponente und der Ressourcenkomponente, auf zwei voneinander getrennten, unterschiedlichen Rechnern ausbildbar sind und/oder ausgebildet sind und/oder als zwei voneinander getrennte, unterschiedliche
Rechner ausbildbar sind und/oder ausgebildet sind.
16. Rechneranordnung nach dem vorhergehenden Anspruch,
gekennzeichnet durch
drei voneinander getrennte Rechner, wobei die Anwenderkomponente auf einem Anwenderrechner (IPC) , die Lizenzserverkomponente getrennt davon auf einem Lizenzserver (2PC) und die Ressourcen- komponente getrennt vom Anwenderrechner (IPC) und vom Lizenserver (2PC) auf einem Ressourcenrechner (3PC) ausbildbar ist und/oder ausgebildet ist, und/oder wobei die drei Komponenten entsprechend als drei unterschiedliche Rechner ausbildbar sind und/oder ausgebildet sind oder
durch zwei voneinander getrennte Rechner, wobei die Anwenderkomponente und die Ressourcenkomponente auf einem gemeinsamen Anwender- und Res- sourcenrechner und die Lizenzserverkomponente getrennt davon auf einem Lizenzserver ausbildbar ist und/oder ausgebildet ist, und/oder wobei die drei Komponenten entsprechend als zwei unterschiedliche Rechner ausbildbar sind und/oder ausgebildet sind
oder durch zwei voneinander getrennte Rechner, wobei die Lizenzserverkomponente und die Ressourcenkomponente auf einem gemeinsamen Lizenzserverund Ressourcenrechner und die Anwenderkomponente getrennt davon auf einem Anwenderrechner ausbildbar ist und/oder ausgebildet ist, und/oder wobei die drei Komponenten entsprechend als zwei unterschiedliche Rechner ausbildbar sind und/oder ausgebildet sind.
17. Rechneranordnung nach einem der vorhergehenden Ansprüche , dadurch gekennzeichnet, dass
die Rechneranordnung mindestens zwei über ein lokales und/oder ein globales Netzwerk, insbe- sondere das Internet, verbundene Rechner, insbesondere PCs, umfasst.
18. Zugriffssteuerungs- und Zugriffskontrollverfahren für eine Applikation in einer Rechneranordnung,
wobei mindestens eine Anwenderkomponente (1) und eine Lizenzserverkomponente (2) zum bidirektionalen Datenaustausch miteinander eingerichtet werden,
wobei mindestens eine Ressourcenkomponente (3) , die eine Applikation (4) steuert und/oder umfasst, zum bidirektionalen Datenaustausch mit der Anwenderkomponente ausgebildet wird, wobei von der Anwenderkomponente auf Basis von ersten Eingabedaten (5) für die Applikation, von Hardwaremerkmalen (6) der Anwenderkomponente und/oder von Informationen über einen auf die
Anwenderkomponente zugriffsberechtigten Anwender (Ia) ein Lizenzdeskriptor (7) generiert wird, wobei dieser Lizenzdeskriptor an die Lizenzserverkomponente übermittelt und durch die Lizenz - Serverkomponente dahingehend überprüft wird, ob eine Zugriffsberechtigung der ersten Eingabedaten (5) , der Anwenderkomponente und/oder des Anwenders auf die Applikation gegeben ist, wobei bei Vorliegen dieser Zugriffsberechtigung von der Lizenzserverkomponente ein den Zugriff auf die Applikation ermöglichender Lizenztoken (8) generiert und an die Anwenderkomponente übermittelt wird, wobei durch die Anwenderkomponente der Lizenzto- ken oder auf diesem basierende Lizenzinformationen (8') sowie zweite Eingabedaten (5') für die Applikation an die Ressourcenkomponente übermittelt werden, und wobei der Lizenztoken oder die Lizenzinformatio- nen durch die Ressourcenkomponente und/oder die
Applikation dahingehend überprüft wird/werden, ob die Zugriffsberechtigung der zweiten Eingabedaten (5'), der Anwenderkomponente und/oder des Anwenders auf die Applikation gegeben ist.
19. Zugriffssteuerungs- und Zugriffskontrollverfahren nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass das Verfahren mit einer Rechneranordnung nach einem der Ansprüche 1 bis 17 durchgeführt wird.
20. Verwendung einer Rechneranordnung und/oder eines Zugriffssteuerungs- und Zugriffskontrollverfah- rens nach einem der vorhergehenden Ansprüchen für Applikationen, bei denen eine Zugriffskontrolle auf Basis von Anwenderinformationen und/oder Eingabedaten unabhängig von einer Net- werkverbindung zu einem Lizenzserver stattfinden soll, zur Durchführung von Simulationsrechnungen, insbesondere von Simulationsrechnungen in einer ein komplexes technisches System wie beispielsweise eine Anlage zur Energieerzeugung, ein medizinisches Röntgen- und/oder Bestrahlungssystem oder ein Fluidtransportsystem virtuell abbildenden Simulationsumgebung mit einem auf und/oder durch die Ressourcenkomponente ausgebildeten und/oder angesteuerten Simulationsprogramm als Applikation und/oder zum Management von Zugriffsmöglichkeiten in vir- tualisierten Umgebungen, insbesondere in VMWare- Umgebungen oder Xen-basierten Umgebungen.
PCT/EP2009/005389 2008-07-24 2009-07-24 Rechneranordnung mit automatisierter zugriffssteuerung von einer und zugriffskontrolle auf eine applikation sowie entsprechendes zugriffssteuerungs- und zugriffskontrollverfahren WO2010009896A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102008034492.3 2008-07-24
DE102008034492A DE102008034492A1 (de) 2008-07-24 2008-07-24 Rechneranordnung mit automatisierter Zugriffssteuerung von einer und Zugriffskontrolle auf eine Applikation sowie entsprechendes Zugriffssteuerungs- und Zugriffskontrollverfahren

Publications (1)

Publication Number Publication Date
WO2010009896A1 true WO2010009896A1 (de) 2010-01-28

Family

ID=41259446

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2009/005389 WO2010009896A1 (de) 2008-07-24 2009-07-24 Rechneranordnung mit automatisierter zugriffssteuerung von einer und zugriffskontrolle auf eine applikation sowie entsprechendes zugriffssteuerungs- und zugriffskontrollverfahren

Country Status (2)

Country Link
DE (1) DE102008034492A1 (de)
WO (1) WO2010009896A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3062255A1 (de) * 2015-02-25 2016-08-31 Siemens Aktiengesellschaft Lizensierung von Softwareprodukten
US20210319896A1 (en) * 2020-04-14 2021-10-14 Drägerwerk AG & Co. KGaA System, medical devices, network components, devices, processes and computer programs for medical devices and for network components

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5204897A (en) * 1991-06-28 1993-04-20 Digital Equipment Corporation Management interface for license management system
WO2004086264A1 (de) * 2003-03-21 2004-10-07 Deutsche Telekom Ag Verfahren und kommunikationssystem zur freigabe einer datenverarbeitungseinheit
US20060004668A1 (en) * 2004-07-01 2006-01-05 Hamnen Jan H Method of distributing electronic license keys
EP1626323A2 (de) * 2004-08-11 2006-02-15 Andreas Hopp Zugriffskontrolle und Kopierschutz

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100834752B1 (ko) * 2006-02-17 2008-06-05 삼성전자주식회사 컨텐츠의 라이센스를 전달하기 위한 장치 및 방법

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5204897A (en) * 1991-06-28 1993-04-20 Digital Equipment Corporation Management interface for license management system
WO2004086264A1 (de) * 2003-03-21 2004-10-07 Deutsche Telekom Ag Verfahren und kommunikationssystem zur freigabe einer datenverarbeitungseinheit
US20060004668A1 (en) * 2004-07-01 2006-01-05 Hamnen Jan H Method of distributing electronic license keys
EP1626323A2 (de) * 2004-08-11 2006-02-15 Andreas Hopp Zugriffskontrolle und Kopierschutz

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3062255A1 (de) * 2015-02-25 2016-08-31 Siemens Aktiengesellschaft Lizensierung von Softwareprodukten
US20210319896A1 (en) * 2020-04-14 2021-10-14 Drägerwerk AG & Co. KGaA System, medical devices, network components, devices, processes and computer programs for medical devices and for network components

Also Published As

Publication number Publication date
DE102008034492A1 (de) 2010-01-28

Similar Documents

Publication Publication Date Title
DE112011101729B4 (de) Verwaltung von Ressourcenzugriff
DE102007033615B4 (de) Verfahren und Vorrichtung zum Umwandeln von Authentisierungs-Token zur Ermöglichung von Interaktionen zwischen Anwendungen
DE102011089580B3 (de) Verfahren zum Lesen von Attributen aus einem ID-Token
EP2159653B1 (de) Verfahren zur Einräumung einer Zugriffsberechtigung auf ein rechnerbasiertes Objekt in einem Automatisierungssystem, Computerprogramm und Automatisierungssystem
DE102009013384B4 (de) System und Verfahren zur Bereitstellung einer sicheren Anwendungsfragmentierungsumgebung
DE112011100182T5 (de) Transaktionsprüfung für Datensicherheitsvorrichtungen
DE102011084728B4 (de) Verfahren zum Starten einer externen Applikation und bidirektionaler Kommunikation zwischen einem Browser und einer externen Applikation ohne Browsererweiterungen
DE112013007160T5 (de) Entwicklungsumgebungssystem, Entwicklungsumgebungsvorrichtung, Entwicklungsumgebungsbereitstellungsverfahren und Programm
DE112018005203T5 (de) Authentifizierung unter Verwendung von delegierten Identitäten
DE112010004135T5 (de) Sicherung Asynchroner Client-Server-Transaktionen
EP3245607B1 (de) Verfahren zum lesen von attributen aus einem id-token
EP2454704A1 (de) Verfahren zum lesen von attributen aus einem id-token
EP3763089B1 (de) Verfahren und steuersystem zum steuern und/oder überwachen von geräten
EP3743844B1 (de) Blockchain-basiertes identitätssystem
DE102011077218A1 (de) Zugriff auf in einer Cloud gespeicherte Daten
WO2018162109A1 (de) Sicherheitseinheit insbesondere ein für iot-gerät und verfahren zur ausführung einer oder mehrerer applikationen zum gesicherten datenaustausch mit einem oder mehrere web-dienste bereitstellenden servern
EP3767513B1 (de) Verfahren zur sicheren durchführung einer fernsignatur sowie sicherheitssystem
DE202020005753U1 (de) Verwalten von Benutzeridentitäten in einem verwalteten Multi-Tenant-Dienst
WO2010009896A1 (de) Rechneranordnung mit automatisierter zugriffssteuerung von einer und zugriffskontrolle auf eine applikation sowie entsprechendes zugriffssteuerungs- und zugriffskontrollverfahren
EP3435265A1 (de) Verfahren zur sicheren authentifizierung bei mit einem server verbindbaren geräten, insbesondere bei zugangskontrollvorrichtungen oder bezahl- bzw. verkaufsautomaten eines zugangskontrollsystems
EP3244331B1 (de) Verfahren zum lesen von attributen aus einem id-token
DE112021002747T5 (de) Sicheres wiederherstellen von geheimen schlüsseln
EP2923264B1 (de) Verfahren und system zur applikationsinstallation in einem sicherheitselement
WO2017108192A1 (de) Validierung und ausführung von provisionierungsdaten auf appliances
EP3244332A1 (de) Verfahren zum lesen von attributen aus einem id-token

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09777426

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09777426

Country of ref document: EP

Kind code of ref document: A1