Method for carrying out an authentication process on a field device, and corresponding system

Abstract

The invention discloses a method for carrying out an authentication process on a field device (FG), having the steps of: operating a ticket server (TS), the ticket server (TS) being designed as an identity provider (IDP) and thereby being designed to generate access tokens (JWT) and the ticket server (TS) being designed to generate field-device-specific tickets (T) with at least one transaction for the field device (FG), an access token (JWT) comprising at least one field-device-specific ticket (T); registering an operating unit (BE) on the ticket server (TS), the operating unit (BE) being designed to receive and process access tokens (JWT); logging in a user (BN) on the ticket server (TS) and selecting a transaction for a field device (FG); generating an access token (JWT) for the field device (FG), containing a field-device-specific ticket (T) for the corresponding transaction; transmitting the access token (JWT) to the operating unit (BE) and reading the access token (JWT) containing the field-device-specific ticket (T); transporting the ticket (T) to the field device (FG) via the operating unit (BE); and carrying out the transaction and carrying out the authentication process on the field device (FG). The invention also relates to a system for carrying out the method.

Description

[0001] Method for authentication on a field device and corresponding system

[0002] The invention relates to a method for authentication on a field device and a system designed to carry out the method.

[0003] Field devices are already known from the state of the art and are used in industrial plants. They are widely employed in process automation as well as in manufacturing automation. Field devices are defined as all devices that are used close to the process and that provide or process process-relevant information. Thus, field devices are used to acquire and / or influence process variables. Measuring instruments or sensors are used to acquire process variables. These are used, for example, for measuring pressure and temperature, conductivity, flow rate, pH, level, etc., and acquire the corresponding process variables such as pressure, temperature, conductivity, pH value, level, and flow rate. Actuators are used to influence process variables.These include, for example, pumps or valves that can influence the flow of a liquid in a pipe or the fill level in a container. In addition to the aforementioned measuring devices and actuators, field devices also include remote I / Os, radio adapters, and generally any devices located at the field level.

[0004] A large number of such field devices are produced and distributed by the Endress+Hauser Group.

[0005] In modern industrial plants, field devices are typically connected to higher-level units via communication networks such as fieldbuses (Profibus®, Foundation® Fieldbus, HART®, etc.). These higher-level units are usually control systems (DCS) or controllers, such as a PLC (programmable logic controller). The higher-level units are used, among other things, for process control, process visualization, process monitoring, and commissioning of the field devices. The measured values ​​acquired by the field devices, especially sensors, are transmitted via the respective bus system to one (or possibly several) higher-level unit(s). Data transmission from the higher-level unit to the field devices via the bus system is also necessary, particularly for configuring and parameterizing field devices and controlling actuators.

[0006] Mobile control units can also be used to operate field devices. For example, there are control units that connect to the fieldbus network. However, the control unit can also communicate with the field devices via a wireless connection, particularly based on a Bluetooth standard. The applicant manufactures and distributes devices that, as so-called Bluetooth gateways, allow the connection of control units to the field devices. The field device is connected to a Bluetooth gateway via a wired connection, particularly using the HART or CDI communication standards. Alternatively, the field devices themselves have their own Bluetooth interfaces.

[0007] In the case of using a mobile device, such as a smartphone or tablet, as an operating unit for wireless communication with the field devices, application programs, so-called apps, are available which provide the operating functions for the field device to the mobile device.

[0008] In industrial environments, most installed field devices have no or only very basic protection against unauthorized access. This means that all device parameters can usually be accessed directly or, for example, after entering an unlock code. Due to the Federal Security Act, field devices with individual user accounts and role-based authorization are increasingly coming onto the market. Access via a user or machine interface therefore requires a kind of "permanent" authorization, which is usually granted through prior authentication.

[0009] To reduce the administrative burden of managing individual field devices to an acceptable level, some efforts are being made to establish centralized management, similar to the long-standing practice in the IT sector for managing IT equipment (e.g., printers, workstations, etc.). An example of such a concept is disclosed in DE 10 2018 102 608 A1, which describes a transport mechanism to which user data is transferred from a user database. After verifying the user data, the field device is granted access to it.

[0010] There are also ideas for limiting the access permissions required by humans to a minimum. For example, German patent DE 10 2019 131 860 A1 discloses the use of a digital ticket, which is transmitted from a server ("ticket server") to the mobile device and contains the access rights and authorized tasks for the field device. This ticket is transmitted when a connection is established with the field device. With the appropriate authorization, the tasks specified in the ticket, such as parameterization actions or performing functional tests, can be processed using the field device.

[0011] For online field devices, meaning field devices that are permanently connected to an IP-enabled network, "Single Sign-On" (SSO) solutions are commonly used, for example via OIDC / OAuth2, as specified by OPC UA Security and CIP Security, and which are also prevalent on the internet. Established solutions also exist in enterprise IT environments, such as MS Active Directory or LDAP.

[0012] The vast majority of field devices have significant resource limitations (e.g., low permissible power consumption in explosive environments, limited storage capacity, low processing power, etc.) and are mostly connected to the control system via 4–20 mA or HART. Even in systems using the PROFINET fieldbus standard, for example, field devices are often decoupled from the system bus via remote I / Os. They therefore do not have a permanent connection to an IP-enabled network, unlike online field devices, which, however, are very rare in plants. Nevertheless, offline field devices also have additional digital configuration interfaces (e.g., a local display, Bluetooth interfaces, a point-to-point web server, etc.) that necessitate the access control for user accounts described above.

[0013] Secure access to offline field devices is typically achieved via manufacturer-specific operating tools. These applications, in combination with special hardware interfaces on the field devices, are optimally tailored to the respective device, its intended use, available resources, and security requirements. In a large plant with many different field devices, possibly from various manufacturers, managing these devices can be a complex and time-consuming process for the plant operator.

[0014] For example, the plant operator would like to manage all users and their access to the field devices as centrally as possible and ideally keep it consistent with the HR system (i.e., the personnel administration).

[0015] The invention is based on the objective of providing a simple and secure way to manage users of field devices.

[0016] The problem is solved by a method according to claim 1, and by a system according to claim 13.

[0017] Specifically, the solution is achieved through the following steps: Operating a ticket server, where the ticket server is configured as an identity provider and thus designed to generate access tokens, where the ticket server is configured to generate field-device-specific tickets with at least one transaction for the field device, where each access token comprises at least one field-device-specific ticket; Registering an operator unit with the ticket server, where the operator unit is configured to receive and process access tokens; Logging a user on to the ticket server and selecting a transaction for a field device; Generating an access token for the field device with a field-device-specific ticket for the corresponding transaction; Transferring the access token to the operator unit and reading the access token with the field-device-specific ticket; Transporting the ticket via the operator unit to the field device;and executing the transaction and performing authentication on the field device.;

[0018] Standard IT technologies are used on the ticket server side as identity providers, extending all the way to the manufacturer's respective operating tool. At the installation where the field device is used, the user employs a proprietary operating tool (usually an app on a control unit) optimized and tailored to the field device, with a specific interface, enabling maintenance work to be performed directly on the field device. This works successfully for the user only if they have previously successfully logged in to the ticket server as an identity provider.

[0019] To implement this idea, a ticket server is required that is designed as an identity provider.

[0020] One configuration involves a manufacturer of a field device operating the ticket server.

[0021] One design envisages that the identity provider is configured as an OpenID provider.

[0022] One design envisions the access token being designed as a JSON Web Token.

[0023] One implementation provides that the field device-specific ticket is stored in the payload, specifically as a field, in the access token.

[0024] One configuration provides for the identity provider to be designed as a SAML provider.

[0025] One configuration requires that the field device be registered with the ticket server.

[0026] One design provides for the field device to be in a mutual, cryptographic trust relationship with the ticket server.

[0027] One design provides for the operating device to be in a mutual, cryptographic trust relationship with the ticket server.

[0028] The ticket server therefore has a mutual cryptographic trust relationship with the field device and / or the operator unit required for offline operation. "Mutual cryptographic trust relationship" means that the components have been mutually acquainted beforehand. The ticket server and the field device / operator unit have thus performed mutual authentication. For this purpose, cryptographic information, such as the public key of a key pair, was exchanged (for example, via a Diffie-Hellman key exchange). The data exchange between the respective components that possess this trust relationship therefore fulfills the security objectives of "integrity," "confidentiality," and "availability." For example, tickets are exchanged between the devices.A ticket can include a digital signature to confirm its authenticity (the ticket has not been altered) and / or to verify the authenticity of the ticket server. In other words, the field device / operating unit "trusts" the ticket and its contents because the field device / operating unit and the ticket server have a mutual trust relationship.

[0029] Examples of field devices have already been listed in the introductory part of the description. Network components, such as edge devices and gateways, also fall under the definition of a field device within the scope of the invention described here.

[0030] One implementation provides that a field device-specific ticket is designed as an account ticket for the field device, i.e., an account for the user is created on the field device via the field device-specific ticket.

[0031] One implementation provides that a field device-specific ticket is designed as an access ticket for the field device, i.e., the user gains access to the field device via the field device-specific ticket.

[0032] One implementation provides that a field device-specific ticket is designed as a feature ticket for the field device, i.e., additional functions are unlocked on the field device via the field device-specific ticket.

[0033] One design provides that the field device in turn creates a ticket as a confirmation ticket with information on whether access to the field device was successful.

[0034] One design provides for the confirmation ticket to be cryptographically secured in the field device.

[0035] One design provides that the confirmation ticket is transferred to the control unit.

[0036] One embodiment provides that the confirmation ticket is transmitted to the ticket server. Regarding the system, it is provided that the system is designed to carry out the method according to the invention and comprises at least one field device, a ticket server, and an operator unit.

[0037] One design of the system provides that the control unit is a mobile device, in particular a tablet or a smartphone.

[0038] This will be explained in more detail using the following figure.

[0039] Fig. 1 shows the claimed system.

[0040] A user, for example a plant operator, typically operates a variety of different field devices; only a single field device FG is shown in Fig. 1. In the following, "field device" is used in the singular, but it always refers to multiple or a large number of field devices. In the case described in Fig. 1, the field device FG is an offline field device, meaning there is no direct communication connection with the ticket server TS. The user can also operate field devices from different manufacturers in their plant.

[0041] Figure 1 shows a ticket server TS, which is operated, for example, by the manufacturer of a field device FG. A ticket server TS can, for example, be implemented on the applicant's IoT infrastructure, such as the "Netilion" platform of the Endress+Hauser Group. Further services can also be provided via this platform.

[0042] The field device FG can be linked or registered with the ticket server TS and stored there with corresponding data, for example with the serial number, type, software version, link to datasheets, properties, etc. It is therefore a kind of digital twin of the field device FG stored in the ticket server TS.

[0043] The field device FG can be linked to the ticket server TS via a "join process," thus establishing a mutual cryptographic trust relationship, as shown below. This is illustrated in Fig. 1 by a dotted line between the field device FG and the ticket server TS. This linking process occurs, for example, during the production of the field devices, but in any case, before the field device FG is delivered to the respective user. The field device FG and the ticket server TS have performed a key exchange and, after a Diffie-Hellman key exchange, have determined the common symmetric key (secret). Cryptographically relevant information is exchanged beforehand, for example, in the form of a public key from each key pair, in order to then verify authenticity and integrity. The field device FG has modules that handle user access management on the field device side.The user access management allows the user to create multiple users per field device, each with different access rights. Furthermore, the field device (FG) is set to a mode in which it can receive field device-specific tickets (see below), specifically account tickets, access tickets, and feature tickets. Tickets are generally described, for example, in DE 10 2018 102 608 A1 and DE 10 2019 131 860 A1.

[0044] The field device FG includes a central security component, a so-called "Field Device Authentication Module" (FDAM). The FDAM in the field device FG verifies whether the ticket originates from the ticket server TS. Sensitive data, such as logs, account databases, keys, certificates, and interface configurations, are stored encrypted in this Field Device Authentication Module (FDAM). This data is encrypted, for example, using a key generated from a master key stored in the device's memory chip. Since this master key is unique for each manufactured memory chip, the encrypted data in this example is bound to this key. The FDAM is also responsible for decrypting the field device-specific ticket. If necessary, a hash is used as protection against modification.

[0045] The field device FG can be an online field device, meaning it communicates directly with the ticket server TS via a network, for example, via mobile network (3G, LTE, 5G, etc.). However, as mentioned, the field device FG in Fig. 1 is an offline field device, meaning there is no direct communication connection with the ticket server TS. The field device-specific tickets T are transmitted from the ticket server TS to the corresponding field device FG via an operator unit BE (see below). The ticket content is securely encrypted with the described key and is unreadable and unusable by third parties.

[0046] The ticket server TS is configured as an identity provider (IDP) and is therefore fundamentally designed to generate JWT access tokens. It is thus also referred to as an IDP server or identity provider server. An identity provider (IDP) provides a central access system where users can log in. The identity provider (IDP) authenticates the user and forwards this information. In this specific example, user BN can log in to the ticket server TS, and this data is then forwarded to the control unit (BE) (see below). Communication between the identity provider and the service provider takes place via appropriate security protocols, such as SAML, OpenID, or OAuth. Service providers can be services from companies, online shops, etc. In one configuration, the identity provider (IDP) is configured as an OpenID provider.In one configuration, the identity provider IDP is designed as a SAML provider.

[0047] An access token contains login data (for example, username) and identifies the user, their assigned groups (if applicable), and their permissions. In general, an access token is an object that contains a user's security identity. An access token is used to make security-related decisions, such as granting access.

[0048] In addition to security-relevant information, an access token can contain additional data that can be added during its creation. For the purposes of this document, this is referred to as a "field device-specific ticket".

[0049] An access token is generated by the identity provider (IDP) after the user BN logs in and the user's provided credentials (login data for the ticket server TS) are authenticated against the ticket server's authentication database. The authentication database contains the credentials required to create the initial token for the login session, including the user ID and, if applicable, group membership.

[0050] The ticket server TS is additionally designed to generate field-device-specific tickets T with at least one transaction for the field device FG. The access token JWT comprises at least one field-device-specific ticket T.

[0051] If the identity provider IDP is configured as an OpenID provider, the access token JWT can be configured as a JSON Web Token. In this case, the field-device-specific ticket T can be stored in the payload, specifically as a field, within the access token JWT.

[0052] JSON Web Tokens conform to the JWT standard and contain information about the user BN in the form of "claims." They are self-contained, so the operator BE, as the recipient, does not need to call the ticket server TS to validate the token. A JSON Web Token is a compact, URL-safe format for representing "claims" to be transmitted between two parties. The information in a JSON Web Token is encoded as a JSON object, which can be used as payload in a JSON Web Signature (JWS) structure or as plaintext in a JSON Web Encryption structure, allowing the information to be digitally signed or protected with a Message Authentication Code (MAC) and / or encrypted.

[0053] A JSON Web Token consists of three parts: the header, the payload, and the signature. The header is a JSON element that describes the token type and the signature method used. The "type" field always contains "JWT". The payload is a JSON element that describes the claims. Some claims are reserved, such as the "iss" field for the token issuer. Additional private or public fields can be used here (see above). The signature structure is defined by the JSON Web Signature Structure (JWS), a standard defined in RFC 7515.

[0054] How the Access Token JWT, including the field device-specific ticket T, reaches the control unit BE and the field device FG is described below.

[0055] The field device-specific ticket T can be configured as an account ticket for the field device FG; that is, an account for the user is created on the field device FG via the field device-specific ticket T. This is useful, for example, if the field device is delivered without an account.

[0056] The field device-specific ticket T can be designed as an access ticket for the field device FG, i.e., the user gains access to the field device FG via the field device-specific ticket T.

[0057] A ticket defines the task data for a "work order" to be carried out. This task data might include, for example, creating an account or granting access. Other possibilities include, for example, the following: unique identification of the service employee or user, the field device, the work order, etc.

[0058] Maintenance measure, activation of a defined parameter, calibration, replacement of the field device, etc., and, if applicable, the period in which the work order is to be carried out.

[0059] In the claimed method, an operator unit BE is registered on the ticket server TS, wherein the operator unit BE is designed to receive and process access tokens JWT.

[0060] The control unit BE is, in particular, a mobile device, such as a smartphone or tablet. Like the field device FG, the control unit BE has a wireless interface, specifically a Bluetooth interface.

[0061] The operator device BE can be linked to the ticket server TS via a "join process," establishing a cryptographically secured, mutually trusted relationship between the ticket server TS and the operator device BE. This process is similar to the join process between the field device FG and the ticket server TS. The cryptographic trust relationship is symbolically represented by the dotted line in Fig. 1. The join process includes, for example, the exchange of cryptographic information, particularly for calculating (symmetric) keys, such as through a Diffie-Hellman key exchange. Cryptographically relevant information is exchanged beforehand, for example, in the form of a public key from each key pair, to then verify authenticity and integrity.The application on the BE control unit advantageously includes a cryptowallet W for the secure cryptographic storage of the cryptographic keys. The shared symmetric key calculated as a result of the join process is securely stored therein. Examples include Microsoft Wallet, Google Wallet, or Apple Wallet.

[0062] Using the control unit BE, a user BN logs on to the ticket server TS and selects at least one transaction for a field device FG.

[0063] User BN has an account on the ticket server TS. User BN logs into the ticket server TS using their login credentials (access data). These credentials include, for example, a username and password.

[0064] After registration, field devices (FG) are assigned to user BN's account, or the user can assign them themselves. This is done, for example, using the serial number or information from the control unit (BE). One or more apps (A) run on the control unit (BE), which are designed, among other things, to connect to and configure the field device (FG). Since user BN logs in with the control unit, this information can be used, for example, by transferring the data from app A to the ticket server (TS) to create the necessary connections. In one configuration, a connection to the ticket server (TS) can be established directly from app A to connect to the field device (FG).

[0065] The field device-specific ticket then comprises the one transaction, or possibly several transactions, to be executed by the field device FG. The ticket contains, or at least corresponds to, a transaction. A transaction is generally a sequence of program steps that are considered a logical unit because, after error-free and complete execution, they leave the data in a consistent state. Therefore, a transaction is required to be executed either completely and without errors or not at all.

[0066] A transaction includes, for example, the field device FG verifying that ticket T was indeed created by the ticket server TS, and creating an account for the user BN. This is referred to as an "account ticket".

[0067] The field device-specific ticket T can be configured as an "access ticket" for the field device FG, meaning that the user gains access to the field device FG via the field device-specific ticket T. A "transaction" then involves the field device FG verifying that the ticket T was indeed created by the ticket server TS and granting access to the field device FG to the user BN. The access ticket is also referred to as a single sign-on ticket or SSO ticket and is described in more detail below.

[0068] The field device-specific ticket T can be designed as a "feature ticket" for the field device FG. This means that the user receives additional functions ("features") for the field device FG via the field device-specific ticket T. These functions extend the functionality of the field device FG and were not present when the field device FG was purchased. A "transaction" then involves the field device FG verifying that the ticket T was indeed created by the ticket server TS and activating the additional functionality. For example, such a feature could be additional software functionality from the field device FG manufacturer. This could include optional device properties or ordering options.Other examples include hardware functionalities that are activated via software, such as enabling the display as a touchscreen or activating a specific hardware interface like a communication interface, for example, Ethernet or Profibus. This additional functionality (ZF) may be time-limited or subject to a subscription model. In the latter case, a fee is charged at regular intervals to keep the additional functionality (ZF) unlocked.

[0069] The ticket T therefore comprises one or more transactions, while the ticket T is part of the access token JWT.

[0070] The ticket server TS generates account tickets T for the linked field devices FG, specifically one account ticket T per field device FG. An account ticket T can be used to create an account, i.e., a login, on a field device. The account ticket preferably contains the same login credentials as the login credentials of user BN on the ticket server TS. Alternatively, second (different, possibly randomly generated) login credentials can be used. The account ticket T is encrypted with a shared symmetric key and secured, for example, with HMAC (e.g.,...).ChaCha20-Poly1305) and contains the specified validity period and login information, such as the username of user BN and, if applicable, a password verifier (an intermediate value for a cryptographic function used by the field device and operator panel to determine a common symmetric key for the field device and operator panel) from the ticket server TS database. Alternatively, a password in plaintext or a random temporary password may be included instead of the password verifier.

[0071] In one configuration, the ticket server TS also generates a single sign-on ticket (SSO-T) for the operator unit BN, with the SSO tickets containing the login credentials (for the ticket server TS); preferably, the same login credentials. A separate SSO ticket is created for each field device (FG) linked to the ticket server TS.

[0072] The account ticket T and / or the SSO ticket may be time-limited. In one configuration, after the time limit expires, the operator unit BE automatically logs out of the corresponding field devices FG.

[0073] The access token JWT, along with the field device-specific ticket T (and, depending on the configuration, possibly also the SSO ticket; not shown), is transferred to the operating unit BN. This is indicated by reference numeral (1) in Fig. 1.

[0074] If available (depending on the configuration), the SSO ticket is stored in a cryptographically secured area of ​​the BN control unit, for example in a Wallet W (see above). Figure 1 shows an SSO ticket already stored in Wallet W.

[0075] The data transfer from the ticket server (TS) to the operator unit (BE) therefore follows standards, specifically access tokens generated by an identity provider. The manufacturer of the field devices is irrelevant in this respect. However, field device-specific details may be proprietary and depend on the respective manufacturer.

[0076] Thus, the present invention enables the plant operator to run a central server, the ticket server, as an identity provider. This server utilizes common IT technologies and adapts them to specific offline solutions within the process automation industry. The identity provider server distributes access tokens to the operator devices. These devices then execute the conversion to the manufacturer-specific offline solution. The implementation effort for the device manufacturers is low, as not every field device needs to be adapted.

[0077] The field device-specific ticket T can, in principle, be transmitted to the field device FG via any means of transport, i.e., any data transmission channel – e.g., manually, via an operating unit, via a wireless or wired network (e.g., HART, Bluetooth) – or it can be stored on a storage medium, e.g., a USB stick or SD card, and then transferred to the field device FG. The transport method via the operating unit BE is shown and preferred, and this will be explained in more detail below.

[0078] The field device-specific ticket T is transported and transferred to the field device FG via the control unit BN. The user BN therefore walks to the field device FG with the control unit BN. This is indicated by reference numeral (2) in Fig. 1. A connection is then established, for example via Bluetooth, using the app A between the field device FG and the control unit BE, and the field device-specific ticket T is transferred in this way. The field device FG has, for example, an integrated Bluetooth interface. This may also occur via the app A, and in one configuration, even in the background without any action required from the user BN.

[0079] Then, the one or more transactions containing the field device-specific ticket T are executed. For example, the field device FG checks whether the ticket T was actually created by the ticket server TS. More precisely, the FDAM in the field device FG validates and decrypts the ticket T.

[0080] If the test is positive, additional functionality for the field device FG will be activated in the case of a "feature ticket".

[0081] In another case, and if the check is positive, an account for user BN will be created on the field device FG in the event of an "account ticket" with the specified login data, access rights and, if applicable, the stored validity period.

[0082] Finally, user BN logs in via their account on the field device FG. User BN can then generally log in with the same password as on the ticket server TS. Furthermore, user BN has access to the field device FG with the permissions they have configured on the ticket server TS.

[0083] To log in as user BN to the field device FG, user BN must be physically present at the field device FG and select it to establish a connection (for example, by selecting it from a LiveList). Login is performed using the username and password. If the field device FG can verify these credentials as valid and the login time falls within the defined validity period, user BN logs in to the field device FG using their control unit BE. Access to the field device FG is then granted according to the assigned access rights.

[0084] In one configuration, user BN logs in automatically to the field device FG via the operator panel BE using the SSO ticket SSO-T stored in Wallet W or the login credentials stored in the SSO ticket. User BN does not need to do anything. Depending on the operator panel BN's settings, proof of identity is required for successful login, for example, the operator panel PIN, a fingerprint on the operator panel, an iris scan, or similar.

[0085] If the operating device is designed as an iPhone, for example, “Face ID” can be used.

[0086] The field device FG can then be operated by user BN using the usual tickets (see, for example, DE 10 2019 131 860 A1). This document makes it possible to use an identity provider's access token containing field device-specific tickets and send them to the operating unit. Specific procedures are used from the operating unit onwards, namely via the field device-specific tickets. Each field device manufacturer can use either the same or a similar procedure, or even a completely different one (for connecting the operating unit to the field device). Only the identity provider's procedures for communicating with the operating unit are standardized and coordinated across manufacturers.

[0087] Furthermore, a "feedback channel" can be established: the field device FG creates a ticket as a "confirmation ticket" with information on whether the corresponding action was successful, for example, who logged in and whether this was successful, whether the account was generated, or whether a feature was activated. This ticket is transmitted to the control unit BE and, if necessary, onward to the ticket server TS. It can be collected in an aggregated logbook compliant with national standards and used for auditing purposes.

[0088] A claimed system comprises the ticket server TS, one or more field devices FG and one or more operator units BE.

[0089] Reference symbol list

[0090] An App

[0091] BE control unit

[0092] BN Users

[0093] FG Field Device

[0094] IDP Identity Provider

[0095] JWT Access Token

[0096] SSO-T Single-Sign-On Ticket

[0097] T Ticket

[0098] TS Ticketserver

[0099] W Wallet

Claims

Patent claims 1. Procedure for authentication on a field device (FG), comprising the steps: - Operating a ticket server (TS), wherein the ticket server (TS) is designed as an identity provider (IDP) and is thus designed to generate access tokens (JWT), wherein the ticket server (TS) is designed to generate field device-specific tickets (T) with at least one T-transaction for the field device (FG), wherein an access token (JWT) comprises at least one field device-specific ticket (T); - Registering an operator unit (AU) with the ticket server (TS), wherein the operator unit (AU) is designed to receive and process Access Tokens (JWT); - Logging a user (BN) on to the ticket server (TS) and selecting a transaction for a field device (FG); - Generating an Access Token (JWT) for the field device (FG) with a field device-specific ticket (T) for the corresponding transaction; - Transferring the Access Token (JWT) to the operating unit (BE) and reading the Access Token (JWT) with the field device-specific ticket (T); - Transporting the ticket (T) via the control unit (BE) to the field device (FG); and - Executing the transaction and performing authentication on the field device (FG).

2. Method according to claim 1, wherein a manufacturer of a field device (FG) operates the ticket server (TS).

3. Method according to claim 1 or 2, wherein the identity provider (IDP) is designed as an OpenID provider.

4. Method according to the preceding claim, wherein the Access Token (JWT) is designed as a JSON Web Token.

5. Method according to the previous claim, wherein the field device-specific ticket (T) is stored in the payload, in particular as a field, in the access token (JWT).

6. The method of claim 1 or 2, wherein the identity provider (IDP) is configured as a SAML provider.

7. Method according to one of the preceding claims, wherein the field device (FG) is registered on the ticket server (TS).

8. Method according to the previous claim, wherein the field device (FG) is in a mutual cryptographic trust relationship with the ticket server (TS).

9. Method according to one of the preceding claims, wherein the operating device (BE) is in a mutual cryptographic trust relationship with the ticket server (TS).

10. Method according to one of the preceding claims, wherein a field device-specific ticket (T) is designed as an account ticket for the field device (FG), i.e., an account for the user is created on the field device (FG) via the field device-specific ticket (T).

11. Method according to one of the preceding claims, wherein a field device-specific ticket (T) is designed as an access ticket for the field device (FG), i.e., the user gains access to the field device (FG) via the field device-specific ticket (T).

12. Method according to one of the preceding claims, wherein a field device-specific ticket (T) is designed as a feature ticket for the field device (FG), i.e., additional functions are unlocked on the field device (FG) via the field device-specific ticket (T).

13. System designed to carry out the method according to any one of claims 1 to 11, comprising at least one field device (FG), one ticket server (TS) and one operating unit (BE).

14. System according to the previous claim, wherein the control unit (CU) is a mobile terminal, in particular a tablet or a smartphone.

Images