EP3967009A1 - Verfahren zur authentisierung eines endnutzers gegenüber einem abhängigen dienst - Google Patents

Verfahren zur authentisierung eines endnutzers gegenüber einem abhängigen dienst

Info

Publication number
EP3967009A1
EP3967009A1 EP20725773.4A EP20725773A EP3967009A1 EP 3967009 A1 EP3967009 A1 EP 3967009A1 EP 20725773 A EP20725773 A EP 20725773A EP 3967009 A1 EP3967009 A1 EP 3967009A1
Authority
EP
European Patent Office
Prior art keywords
service
identity
dependent
intermediary
dependent service
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
EP20725773.4A
Other languages
English (en)
French (fr)
Inventor
Mustafa Killik
Kurt Stadler
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Giesecke and Devrient Mobile Security GmbH
Original Assignee
Giesecke and Devrient Mobile Security GmbH
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 Giesecke and Devrient Mobile Security GmbH filed Critical Giesecke and Devrient Mobile Security GmbH
Publication of EP3967009A1 publication Critical patent/EP3967009A1/de
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • 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/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/32—User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
    • 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/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • 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/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/41—User authentication where a single sign-on provides access to a plurality of computers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0861—Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan

Definitions

  • the subject of the invention is the management of digital identities.
  • the invention relates to providing an attribute of a verified digital identity in a federated system with multiple associated identifiers.
  • the invention integrates user accounts that are managed by different identity providers and allows dependent services a uniform and transparent use of attributes of a verified digital identity for authentication and establishment of access to a digital service.
  • the prerequisite for using the digital identity and thus for access to many digital services is proof that a user is the owner of a digital identity. This is done by authenticating the user. For this purpose, the user offers one or more factors for identification that the system uses with the digital identity
  • OpenIDConnect is an industry standard that enables login processes to be easily implemented using various services and systems. Another method is e.g. SAML.
  • Kerberos Specific authentication server solutions such as Kerberos are also known. At its core, these solutions are based on a data memory that supports the Retains user data and attributes persistently and is usually managed centrally. The service that stores the user's data and identifies and verifies the user when they log in is known as the identity provider.
  • the number of identity givers is significant and increasing. In addition to companies that specifically specialize in providing user identities, these are also the large social networks. Financial institutions and online retailers also have user accounts. In the enterprise environment, every company can manage the identities of its employees. In general, each provider autonomously manages the user accounts set up with them and the user identities associated with the accounts.
  • a user can only use a user identity associated with an account for authorization or a login for services that have a trust relationship with the provider who manages the account and if the service is supported by the identity provider.
  • a user wishes to use a plurality of services and accounts, he typically has to store his or her identity individually for each service in order to log into the respective service.
  • the concept of federated identities is also known.
  • a first approach to this is based on the exchange of user identities between grouped identity providers. The user accounts are replicated between different identity providers. This means that a user can log in to any service connected to an identity provider who has either managed or imported the user account in question. This approach is followed by the company Verimi, among others.
  • Another approach consists in the dynamic determination and connection with the identity provider, who manages a required user account, during the login process via a network layer. The requesting service trusts all identity providers that can be transferred. After the successful switching phase, the service either communicates directly with the identity provider in order to query the end user's attributes and to carry out the authorization, or it continues via the switching layer.
  • Another approach consists in the decentralized management of user accounts on a user's device or in a network.
  • the requesting service trusts the terminal or the network. Examples of this are approaches based on the blockchain.
  • US 2019/0010109100 Al a method for managing user identities is known, in which a central management server is connected to various facilities on which identities are stored in different forms. The management server accesses the connected facilities in order to establish, secure or release an identity.
  • the solution makes it possible in particular to provide an identity with a predetermined level of trustworthiness.
  • a system in which a user terminal with an authentication server is connected to a network via an access instance.
  • the user terminal is connected to several authentication devices.
  • Various authentication devices are registered with the authentication server.
  • the authentication server After successful authentication, the authentication server provides a short-lived certificate with which the user terminal issues a ticket from the access instance can pick up. With the ticket, the user terminal receives access to the network and the services that can be accessed via it.
  • US 2017/0289134 A1 discloses a consensus system based on a distributed database for providing identities among the system participants, the system using the concept of single sign-on or single sign-on (SSO).
  • the system comprises an identity provider server, a user computer and one or more servers from service providers.
  • a verified credential is stored with the identity provider server.
  • the identity provider server generates an identity token for this purpose and makes it available to a user computer. With the identity token, the user computer can gain access to a server of a service provider. To grant access, the server checks the access status with regard to another system participant under Access to the distributed database. This prevents access from being obtained due to an invalid credential.
  • the invention is based on the object of specifying a method which makes it possible to use an already verified digital identity that is stored with an identity generator belonging to a federation of identity providers to prove an identity when using a digital service.
  • the proposed method is characterized by an intermediary connected between the dependent services and the federated identity providers.
  • service which implements the transfer of identity inquiries that is transparent for all parties. Transparency here means that a dependent service does not know a specifically used identity giver and the identity giver in turn does not become aware of the dependent service or its use by an end user.
  • Dependent service and identity provider are decoupled in terms of information. When processing identity inquiries, the dependent service involved and the identity provider involved remain anonymous to one another. The transparency in particular prevents improper evaluation and analysis ("tracking") of exchanged data.
  • the intermediary service enables an end user to choose any federated identity giver associated with the intermediary service for proof of identity when accessing a dependent digital service.
  • the process allows dependent services to access verified digital identities for login and registration processes for user accounts, which are managed by different identity providers.
  • Dependent services only have to integrate themselves once into the federation, regardless of the number of identifiers that are united in the federation.
  • a dependent service only needs a trust relationship with the intermediary unit, but not with the individual identity providers. Rather, the dependent service neither needs to know the identity giver nor does a trust relationship need to exist.
  • a requesting dependent service does not have to reveal to an identity provider which customer account a request relates to.
  • the intermediary unit does not have any insight into or access to attributes of the end users and can only become active upon request from a dependent service.
  • attributes in which the intermediary unit are only available in encrypted form ensures that attributes of an end user cannot be changed, viewed or temporarily stored by the intermediary unit.
  • the intermediary unit cannot query attributes of an end user without an order from a dependent service.
  • the intermediary unit is fixed on a mediating role by the introduced technical measures and prevented from acting as an identity giver or actively calling up attributes of the end user in order to utilize them for other purposes.
  • end-to-end encryption ensures the confidentiality and integrity of attributes.
  • technical measures ensure that the intermediary unit cannot make a request to a dependent service without a specific request from a dependent service.
  • the proposed procedure leads to a strict separation of roles in a federal identity management system. This makes the concept particularly suitable for business applications with special confidentiality requirements, such as in the financial sector. Due to the strict role The concept particularly supports the protection of personal data and the regulated cooperation even in a highly competitive environment.
  • FIG. 3 shows a sequence of screen contents which are displayed to an end user at the user interface as part of a provision of identity
  • FIG. 1 shows schematically an embodiment of a federative identity management system 1 reduced to the main components.
  • Components of the system shown are an intermediary service 15, a dependent service 11, a federated identity provider 21 and a user agent 13.
  • All components 11, 13, 15, 21 are connected to the other components via data connections 24 for exchanging data.
  • the data connections 24 can be fixed or via the Fuft interface in the form or several networks.
  • the data connections 24 are protected by technical measures, for example VPN or TLS, so that only authorized components can enter into communication and the data are protected against falsification and spying.
  • the intermediary service 15 is composed of an intermediary unit 16 and a system certification body 18.
  • the system certification authority 18 is designed as a separate unit which is based on a separate data processing system.
  • the task of the system certification body 18 is to map the trust relationships between the components by issuing certificates or tokens. All other activities of the intermediary service 15 with respect to the identity management system 1 are carried out by the intermediary unit 16. In the following, therefore, only intermediary unit 16 is listed as representative of the entire intermediary service 15 when it performs a function.
  • the intermediary service 15 has a memory area 20 which is used in particular to receive tokens and attributes 9.
  • the memory area 20 is implemented in the averaging unit 16.
  • the user agent 13 has an end user interface 14 to an end user 10.
  • the end user interface 14 typically includes a display and a keyboard. Other and further input and output means are possible.
  • the end user interface 14 can contain sensors and biometric detection devices for recording authentication factors.
  • Dependent service 11, intermediary service 15 and federated identity generator 21 are typically implemented in the form of program sequences that are executed on common data processing systems. The data processing systems are the basis of every component.
  • the user agent 13 can be, for example, a browser running on a personal computer or the operating menu of a publicly accessible terminal.
  • the end user 10 is the owner of at least one verified digital identity 2, which is stored in a user account 22 with a federated identity provider 21.
  • the verified digital identity 2 consists e.g. from personal data and information of the end user 10 such as name, email address, delivery address or bank details, the accuracy of which has already been confirmed to an identity giver 21.
  • the personal data and information are attributes 9 of the digital identity 2.
  • Each attribute 9 consists of an attribute name 4 and an attribute value 3.
  • attributes 9 are not restricted to information typical for business transactions such as the ones listed. Rather, attributes 9 can be any information that is assigned to an end user 10, such as, for example, personal images or audio files.
  • each Weil a federated identity generator 21, a dependent service 11 and a user agent 13; real systems usually have one each A plurality of federated federated identifiers, dependent services and user agents.
  • the set of connected federated identifiers 21 together form the federation.
  • identity giver 21 In the following who the federated identity giver simply referred to as identity giver 21.
  • the operator of the dependent service 11 can be, for example, a bank, an authority or an Internet dealer.
  • the dependent service 11 typically consists in the provision of a digital service, service or function in connection with a digital resource for which access is restricted to a specific end user or a defined group of specific end users.
  • a digital service or function in connection with a digital resource can, for example, open or maintain a bank account, carry out a purchase transaction with an online retailer or perform an administrative act such as the use of an ID card at an examination office.
  • digital service 12 the performance, service or function provided by the dependent service is briefly referred to as digital service 12.
  • the dependent service 11 is access-protected.
  • an authentication of the end user 10 is required, which proves his authorization. This is typically done in a login process by submitting authentication data in the form of a verified digital identity 2 or individual attributes 9 of a verified digital identity 2.
  • the dependent service 11 uses the federative identity model. management system 1.
  • An identification IDM of the intermediary unit 16 is stored in the dependent service 11, which identifies it during registration.
  • a certificate ZTM of the intermediary unit 16 with a public key OKM of the intermediary unit 16 is also stored.
  • the identity generator 21 manages one or more user accounts 22 of one or more end users 10 and undertakes the identification and verification of end users 10.
  • the identity generator 21 can expediently be based on an ID provider corresponding to the OpenIDConnect de facto standard.
  • the identity generator 21 has a private key PPA for issuing and signing tokens, which is issued by a generally accessible certification body (not shown).
  • the corresponding public key OKI is transmitted to the intermediary unit 16 via a certificate.
  • the intermediary service 15 presents itself to the federation of identity generators 21 like an - individual - dependent service 11.
  • the intermediary service 15 has a customary interface with respect to the connected dependent services 11.
  • the intermediary service 15 provides a standard-compliant OpenIDConnect interface and shows its behavior.
  • a public key OKI is stored for each identity transmitter 21, with which a token of an identity transmitter 21 can be verified.
  • the keys OKI are transferred to the mediator unit 16 by certificate.
  • the intermediary unit 16 also has a private key PKV for signing tokens.
  • the corresponding public key OKV is transmitted to the dependent services 11 in certificates that originate from a generally accessible certification authority (not shown).
  • the components of the identity management system 1 communicate via secure communication channels that ensure the confidentiality of the data on the transport route and guarantee the authenticity of the communicating components.
  • the secured communication channels are set up via the data links 24 existing between the components.
  • Secured communication channels can be formed, for example, in the form of TLS connections.
  • the security is carried out, for example, by mutual TLS authentication.
  • the security of the identity management system 1 is achieved in particular with tokens and certificates.
  • Tokens 5, 6, 7, 8 are generated by the intermediary unit 16 and the identity transmitter 21.
  • a structured encrypted date is placed under a token understood that makes it possible to use identity and security information together across different security areas.
  • Token is issued by intermediary unit 16 or identity generator 21 and consumed by a trusted component that relies on its content to identify a subject of a token for a security-related purpose.
  • the 4 illustrates the structure of a token. It comprises a head part, a payload part and a signature part.
  • the header contains a unique identifier TKV, TKF of the respective token.
  • the payload part contains, for example, the name of a dependent service 11.
  • the signature part contains a signature created with the secret key of the issuer about the content of the header and the payload part.
  • a token is signed using a private key and cannot be changed. Its validity can be checked at any time using a corresponding public key or a certificate. It still has a specified service life. After it has expired, a token is no longer considered valid.
  • Each token also has a unique identifier TKV, TKF.
  • the token has an issuer; this is the component that generated and signed the token.
  • the publisher is the only one who has access to the private signing key.
  • JSON web tokens JWT
  • Other forms of representation of the tokens are also possible.
  • Certificates are signed data structures. As with tokens, the integrity of zeros is protected by a signature. This allows certificates cannot be changed after generation, or the change can easily be determined with a public key. Certificates can only be issued by a particular component, for example the system certification authority 18, which is trusted by all components. Only the special component has access to the private key that is used for signing. Certificates relate to a subject hn the procedure described here, the subject is the identifier TKV, TKF of a token. Certificates also have a lifespan. This is linked to the lifetime of the token, the identifier of which is called the subject. Certificates bind a public key to a subject.
  • certificates can also be replaced by tokens.
  • the system certification authority 18 generates a token with corresponding token attributes for authorized dependent services 11 so that the certification function can be mapped.
  • At least one ZIF certificate is stored in the intermediary unit 16 for each identity transmitter 21 integrated into the federation.
  • the ZIF certificates are expediently created when a new identity provider 21 is integrated into the federation.
  • a verified digital Identi ity 2 of the end user 10 with at least one attribute 9 is stored in the user account 22 at the identity generator 21, the correctness of which has already been confirmed to the identity generator 21.
  • Attributes 9 can be, for example, name, email address, delivery address or bank details or personal images or audio files for which specific data or information have been stored.
  • the user account 22 with the identity provider 21 is access-protected.
  • authentication is required as part of a login process, for example by presenting a password.
  • the end user 10 would like to access a protected digital service 12 which is provided by a dependent service 11 for which the end user 10 does not yet have an access account or to which he has not authenticated himself.
  • a protected digital service 12 which is provided by a dependent service 11 for which the end user 10 does not yet have an access account or to which he has not authenticated himself.
  • the end user 10 would like to use an already stored verified identity 2. This should be made available to the dependent service 11.
  • the implementation of the identity provision requires a secure communication channel between the dependent service 11 and the identity generator 21.
  • a secure communication channel can be set up with a usual method for setting up a secure transmission channel.
  • a key exchange can be provided by a “key wrapping” method in which a secret key is transmitted in a cryptogram.
  • the process of providing a verified digital identity 2 is triggered when an end user 10 would like to use a digital service 12 offered by a dependent service 11 which requires authentication to be carried out as part of a login process. The steps in the process are explained below.
  • Step 100 The end user 10 selects a desired dependent service 11 via the end user interface 14. To this end, the end user 10 clicks, for example, on a button that is provided on a selection page of the dependent service 11, with which the Internet address of the dependent service is selected.
  • Step 102 The user agent 13, e.g. a web browser, opens a connection to the public interface of the selected dependent service 11 and sends a request to this.
  • the request can, for example, be in the form of a login request to the internet address of the dependent service
  • Step 104 The dependent service 11 examines the request. If he determines that the request is directed to a protected digital service 12 which requires authentication, and if the corresponding authentication data is not available, he starts a login process. In the assumed scenario, the dependent service 11 establishes that the digital service 12 addressed by the request is protected and no authentication data is available. The dependent service 11 therefore starts a login process.
  • Step 106 The dependent service 11 generates a selection page (website) with a button, via which the establishment of a connection to the relay unit 16 is triggered.
  • the selection page expediently contains information on the dependent service 11. It can contain further information, for example names of the attributes required for the login process.
  • the dependent service 11 sends the selection page to the user agent 13.
  • Step 108 The selection page is displayed to the end user 10 via the end user interface 14.
  • 3a shows an example of a screen content with a displayed selection page. It contains a designation of the dependent service ("Dependent service”), a designation of the executed method step ("Sign-In Process”) and two buttons, one of which (“Sign-In with local account”) relates to a local one Set up an account with the dependent service and the other (“sign-in with ID federation”) triggers the provision of a digital identity via an identity provider.
  • Dependent service a designation of the executed method step
  • Sign-In Process a designation of the executed method step
  • two buttons one of which (“Sign-In with local account") relates to a local one Set up an account with the dependent service and the other (“sign-in with ID federation”) triggers the provision of a digital identity via an identity provider.
  • the end user 10 operates the control panel pointing to the identity transmitter.
  • the user agent 13 then establishes a connection to the intermediary unit 16.
  • the selection page causes the user agent 13 to establish a connection with the mediating unit 16 directly via a direct referral (redirection) without actuating the switch field.
  • the authorization request expediently contains information on the selected dependent service 11. It can also contain names of certain attributes that are presented to the dependent service 11 should. It can also contain further information that characterize the access to the dependent service 11 intended by the end user 10.
  • the authorization request can be made, for example, in the form of a GET command with which the transmission of a selection page for selecting an identity provider is requested.
  • Step 112 In response to the authorization request, the intermediary unit 16 generates a selection page in which all of the federated identity providers 21 are listed.
  • the external shape of the selection page and the representation of the identity giver can be freely designed.
  • a selection page with finks, buttons, icons or similar control elements is conceivable.
  • Fig. 3b shows an example of a screen content with a displayed selection page. It contains a designation of the intermediary unit ("ID Management Broker") and four buttons, three of which lead to different identifiers ("Authentication with ID-A”, "Authentication with ID-B”,
  • criteria For example, information on the selected dependent service 11, attribute names 4 or information on further known properties of the intended access sent with the authorization request can be used.
  • the end user 10 is requested to transmit his name or another personal date in order to generate a personalized selection page. Furthermore, other factors such as the location used to design the selection page.
  • Step 114 The intermediary unit 16 sends the selection page to the user agent 13.
  • the selection page is displayed to the end user 10 via the end user interface 14.
  • Step 200 The end user 10 selects an identity generator 21 on the displayed selection page, which can provide the attributes 9 required for the upcoming login process. It is assumed that the end user 10 knows which identity generator 21 is suitable. If necessary, the end user 10 can query the names 4 of the required attributes from the dependent service 11. If the selection page is personalized, only those identity transmitters 21 are expediently offered for selection that can provide the required attributes 9.
  • Step 202 After the end user 10 has selected an identity transmitter 21, the user agent 13 sends a request to the selected identity transmitter 21.
  • Fig. 3c shows an example of a screen content with a displayed selection page. It contains a designation of the identity provider ("ID-Pro many”), a designation of the process step carried out ("Identification & Verification"), interactive fields ("User Name”, “Password”, “OTP”) for entering authentication data and a Button for checking entered data (“Start authentication”).
  • ID-Pro many a designation of the identity provider
  • Identity & Verification a designation of the process step carried out
  • interactive fields (“User Name”, “Password”, “OTP” for entering authentication data
  • Button for checking entered data
  • Authentication data can also be entered, as shown in FIG. 3c, by means of an auxiliary device, such as a cell phone.
  • Biometric data for example a fingerprint, can also be used as authentication data.
  • Step 300 The end user 10 authenticates himself in a manner known per se by presenting one or more authentication factors which uniquely identify the end user 10. For example, he presents his name and / or a password and / or a biometric feature such as a fingerprint or an iris pattern via appropriate input means.
  • Step 302 The user agent 13 forwards the inputs to the identity generator 21.
  • the identity generator 21 checks the presented authentication factors. If the check is successful, the end user 10 is identified and it is certain that the end user 10 belongs to a user account 22 existing with the identity provider 21.
  • the identity generator 21 then generates an action code CAK, which enables the authentication that has taken place to be clearly identified.
  • the action code CAK is used in the further process to obtain a second date 7 in the form of an FI access token from an Identi ity generator 21 with which the identity generator 21 checks the authorization of a data exchange between the intermediary service 15 and the identity generator 21.
  • Step 304 The identity provider sends the action code CAK as a response to the user agent 13.
  • the response contains a referral.
  • Step 306 The user agent 13 forwards the response from the identity transmitter 21 with the action code CAK in a request to the intermediary unit 16.
  • the mediation unit 16 receives the request and the action code CAK as parameters.
  • Step 308 The mediator unit 16 contacts the identity generator 21 with the action code CAK as a parameter.
  • Step 310 The identity generator 21 checks the received action code CAK for correspondence with the action code CAK originally sent in step 302.
  • the identity generator 21 generates an FI access token 7.
  • the identity generator also generates an FI refresh token 8. Furthermore, the identity generator 21 generates a session identification IDS.
  • the FI access token 7 is used in the further course of the method to set up a secure attribute transmission channel 19 via which for the Access to a protected digital service 12 required attributes 3 are transmitted.
  • a new FI access token 7 can be generated automatically when the old one has expired.
  • Step 312 FI access token 7, FI refreshing token 8 and session identification IDS are passed by the identity transmitter 21 to the intermediary unit 16.
  • the identity transmitter 21 also appropriately transmits a list with the attribute names 4 that are available for the user account 22.
  • the list of attribute names 4 of the available attributes 9 is stored by the averaging unit 16 in its memory area 20. It expediently creates a table 23 into which further entries are added in the course of the further process.
  • Step 314 The intermediary unit 16 verifies the FI access token 7 and the FI refresh token 8 with the aid of the stored certificate ZIF of the identity provider. If the checking of the tokens 7, 8 is successful, the end user 10 is considered to be verified for the intermediary unit 16.
  • the mediator unit 16 stores the FI access token 7 and the FI refresh token 8 in its memory area 20. In a simple manner, the mediator unit 16 uses the table 23 for this and adds the tokens 7, 8. The tokens 7, 8 are not passed to the end user 10, the user agent 13 or the dependent service 11.
  • Step 316 The mediating unit 16 generates a selection page with a list with the attribute names 4 of the available attributes 9 and sends this to the user agent 13, where it is displayed to the end user 10 via the end user interface 14.
  • FIG. 3d shows, by way of example, a screen content of a selection page with a displayed list of attribute names. It contains a designation of the brokerage service ("ID-Manager ent Broker”), a designation of the procedural steps ("Consent to transfer to dependent service”), the name of a separate attribute in the form of an end user name (“John Doe” ), a two-column table with the names of additional attributes ("profile”, email ",” address ", phone”) and an approval box as well as a button (“approval”) for approving an attribute selection.
  • ID-Manager ent Broker a designation of the procedural steps
  • Consent to transfer to dependent service the name of a separate attribute in the form of an end user name
  • John Doe a two-column table with the names of additional attributes
  • approval box as well as a button
  • Step 400 The end user 10 selects the names 4 of the attributes for which a transfer of the attributes 3 to the dependent service 11 is to be allowed. By pressing a corresponding button in the selection page, the selected attributes 9 are released for transmission.
  • the end user 10 can also select all attributes 9 or the entire digital identity 2.
  • Step 402 The user agent 13 sends the attribute names 4 of the attributes 9 released for forwarding to the dependent service 11 to the mediator unit 16.
  • Step 404 The mediating unit 16 stores the attribute names 4 released for the selected dependent service 11 in its memory area 20.
  • the mediation unit 16 can access the one stored in the memory area 20 Access release. A renewed release by the end user 10 by executing step 400 is then not required.
  • Step 406 The mediator unit 16 generates a session code CSM.
  • the session code CSM is used in the further course of the method to receive a first date in the form of a V access token 5 from the mediator unit 16.
  • the intermediary service 15 uses this to check the authorization of a data exchange between the intermediary service 15 and the dependent service 11.
  • the mediator unit 16 further generates a referral response with the session code CSM and status information.
  • the mediation unit 16 expediently stores the session code CSM in its memory area 20; it is expediently added to Table 23.
  • Step 408 The user agent 13 forwards the referral response to the dependent service 11.
  • the session code CSM and the status information are transmitted as parameters.
  • Step 410 the dependent service 11 sends a token request to the mediator unit 16.
  • the session code CSM is transferred as a parameter.
  • Step 412 The mediator unit 16 identifies the session via the session code CSM and generates a V access token 5 with an identifier TKV and a V refresh token 6 using the signing key of the mediator unit.
  • the identifier TKV of the V access token 5 is formed by a hash function from the identifier TKF of the FI access token 7 of the identity generator. In this way, a technical link is established between the FI access token 7 and the V access token 5. An existing link can be checked on the basis of an FI access token 7.
  • the V-access token 5 and the V-refresh token 6 are issued to the dependent service 11.
  • the V-access token 5 is used in the further course of the method to set up a secure attribute transmission channel 19 via which the attributes 3 required for access to a protected digital service 12 are transmitted.
  • the V-access token 5 and the V-refresh token 6 are not transferred to the end user 10 or the user agent 13.
  • the dependent service 11 can apply for a new V-access token 5.
  • the mediating unit 16 also creates an entry in its internal memory area 20 which contains the attribute names 4 that the end user 10 has released.
  • the entry denotes the current provisioning session and also contains the FI access tokens 7, 8 and the V-access tokens 5, 6 generated by the mediating unit 16.
  • All entries in table 23 can be summarized in a simple manner. Further data are expediently stored in table 23, which are required in the context of providing the attributes. Table 23 can look like this, for example:
  • the intermediary unit 16 also generates a unique account identifier KID and stores it in its memory area 20.
  • the account identifier KID identifies the end user 10 or the user account 22 uniquely throughout the federation.
  • the account identifier KID is generated once for each user account 22 and cannot be changed.
  • the account identifier KID is expediently based on a concealed link between a user account 22 and an identity generator 21.
  • the concealment takes place in such a way that no inferences about the identity generator 21 are possible.
  • a hash function can be used with which a hash value is formed via an OpenldConnect identification of the intermediary unit 16 used with respect to the identity generator 21.
  • a hash value is formed in the master data of the intermediary unit 16 for the identity generator 21 via a constant that is determined by the intermediary unit 16 through configuration as part of the registration process for including an identity transmitter 21 in the federation.
  • Step 414 V-access token 5 and V-refresh token 6 are sent by the relay unit 16 to the dependent service 11.
  • Step 416 The dependent service 11 verifies the V-tokens 5, 6 received with the aid of the public key OKM from the previously stored certificate ZTM of the intermediary unit.
  • Step 498 An attribute transmission channel 19 is set up for the transmission of attributes 3 from the identity generator 21 to the dependent service 11 via the end-user information interface.
  • a secure connection with mutual authentication is set up between the dependent service 11 and the system certification authority 18, for example a TLS B2B connection.
  • the dependent service 11 generates a key pair with a public key OKA and a private key PKA.
  • the dependent service 11 also generates a session identification SZI.
  • the identifier TKV of the V access token 5 can serve as the session identification SZI in a simple manner.
  • the public key OKA and the session identification SZI are sent to the system certification authority 18 via the secure connection in a certificate request.
  • the private key PKA remains with the dependent service 11.
  • the certificate request can be made as a CSR (Certificate Signing Request) command, which contains the public key OKA and the session identification SZI from the V access token 5 with which a session is used certificate is requested.
  • Step 500 In response to the certificate request, the system certification authority 18 generates a session certificate ZSZ for the session identification SZI.
  • the ZSZ session certificate is only valid for a short time; its duration corresponds at least to the life of the V-access token 5.
  • the session certificate ZSZ contains the identifier TKV of the V-access token 5 and a public key for the SZI session identification.
  • the session certificate ZSZ also serves as proof that the dependent service 11 is authorized to send queries to the intermediary unit 16.
  • Step 502 The system certification instance 18 sends the session certificate ZSZ to the dependent service 11.
  • Step 504 The dependent service 11 initiates the establishment of a secure attribute transmission channel 19 via a call to the mediation unit 16.
  • the initiation can take place, for example, with the aid of a POST command that transfers the V access token and the ZSZ session certificate as parameters.
  • Step 506 The mediating unit 16 checks whether the V access token 5 is valid and has not expired. If this is the case, the intermediary unit 16 uses the directory 20 to determine the FI access token 7 of the identity provider that corresponds to the V access token 5.
  • the determined FI access token 7 sends the mediator unit 16 together with the session men Z ertificate ZSZ to the identity encoder 21st Step 508:
  • the identity sender 21 checks whether the FI access token 7 received from the intermediary unit 16 is valid and has not expired.
  • the identity generator 21 also checks the session certificate ZSZ.
  • the session certificate ZSZ is accepted as valid if it is a CA-IDP certificate and has been signed by the system certification authority 18, it has not expired and the identifier TKV of the V access token 5 contained in the subject of the session certificate ZSZ linked FI access token token 7 corresponds. For this check, the identity generator 21 calculates the hash using the token identifier ZKF of its own FI access token 7.
  • the ZSZ certificate can also provide the signature via a certificate chain.
  • Step 510 If the session certificate ZSZ is valid, the identity generator 21 generates a random, symmetrical session key KSY of sufficient length.
  • KSY symmetrical session key
  • a number of keys are expediently generated to ensure the integrity, the confidentiality and the sequence of the messages.
  • the keys are expediently generated by deriving the key from a random common starting value.
  • the identity generator 21 sets up the secure attribute transmission channel 19 to the dependent service 11 on its side.
  • Step 512 The session key KSY is encrypted with the public key OKA from the session certificate ZSZ to form a cryptogram and transferred to the intermediary unit 16. Since the private key PKA remains with the dependent service 11, the intermediary unit 16 has no access to the session key KSY.
  • Step 516 the dependent service 11 decrypts the cryptogram with its private key PKA and thus determines the session key KSY. With these, the dependent service 11 sets up the secure attribute transmission channel 19 on its side.
  • the dependent service 11 uses the same key derivation as the identity generator 21. The attribute transmission channel 19 is thus established.
  • the verified digital identity 2 or attributes 9 are provided by the identity generator 21 to the dependent service 11.
  • the intermediary unit 16 checks the authorization of the data exchange between the intermediary unit 16 and the dependent service 11 based on the V- Access token 5 and the identity generator 21 the authorization of the data exchange between intermediary unit 16 and identity generator 21 based on the FI access token 7.
  • the dependent service 11 retrieves the attributes 9 of the end user from the intermediary unit 16.
  • the call contains the V access token 5 for authentication purposes.
  • the call can take the form of a GET command, for example.
  • the mediator unit 16 determines the FI access token 7 that belongs to the V access token 5 generated by the mediator unit from the request. The assignment can be done directly through the V access token 5 or via the SZI session identification. Can he V access tokens 5 are not accepted, the mediation unit 16 returns an error message to the dependent service 11.
  • Step 604 the intermediary unit 16 sends a request to the identity transmitter 21.
  • the request contains the FI access token 7 and the attribute names 3 of the required attributes 9.
  • Step 606 The identity sender 21 checks the FI access token 7 to see whether it is valid and has a valid signature. If this is the case, the identity generator 21 generates a response with the requested attributes 9 of the end user, which are to be visible to the federation, and the attribute name 4. The attribute values 3 are encrypted with the session key KSY. The attribute names 4 of the attributes 9 are included in the response without encryption.
  • Step 608 The answer with the encrypted attributes 9 is sent by the identity transmitter 21 to the intermediary unit 16.
  • the data transmission between intermediary unit 16 and the identity transmitter 21 takes place via the secure attribute transmission channel 19.
  • Step 610 The mediating unit 16 uses the attribute names 4 to check whether the encrypted attributes 9 contained in the response have been released for transmission to the dependent service 11 by the end user 10. If this is the case, the mediating unit 16 generates a list with the released encrypted attributes 3.
  • Step 612 The mediator unit 16 returns the list to the dependent service 11 as a response.
  • Step 614 The dependent service 11 decrypts the encrypted attribute values 3 from the response using the session key KSY transmitted by the identity generator 21.
  • Step 616 Based on the then available attributes 9 of the end user, the dependent service 11 carries out the authorization and decides whether the use of the requested dependent service 11 is granted for the desired digital service 12. The result is displayed to the end user 10 on the end user interface 14. For example, the end user 10 is shown a user account with the transmitted attributes 9.
  • Fig. 3e shows an example of a screen content with a displayed results page.
  • the screen content contains a description of the dependent service ("Dependent Service”), a description of the process step ("User Account”), an end user name ("John Doe”) and a two-column table with the description of attributes ("Id”, “ email “,” email-status “,” phone ”) and associated values (" John-Doe “,” John, Doe @ .... de “, verified", “+ 1098922222”).
  • V-access token 6. V refresh token

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • General Health & Medical Sciences (AREA)
  • Storage Device Security (AREA)

Abstract

Vorgeschlagen wird ein Verfahren zu Authentisierung eines Endnutzers (10) gegenüber einem abhängigen Dienst (11) durch Bereitstellung eines Attributs (9) einer bei einem föderierten Identitätsgeber (21) hinterlegten verifizierten digitalen Identität (2) mit Hilfe eines Vermittlerdienstes (15). Ein Attribut (9) wird nur bereitgestellt, wenn der Endnutzer (10) sich gegenüber dem föderierten Identitätsgeber (21) erfolgreich als Eigentümer der verifizierten digitalen Identität (2) authentisiert und das Attribut (9) zur Verwendung durch den abhängigen Dienst (11) freigegeben hat.

Description

Verfahren zur Authentisierung eines Endnutzers gegenüber einem abhängi gen Dienst
Gegenstand der Erfindung ist das Management von digitalen Identitäten. Insbesondere betrifft die Erfindung die Bereitstellung eines Attributs einer verifizierten digitalen Identität in einem föderierten System mit mehreren verbundenen Identitätsgebern. Die Erfindung integriert Benutzer-Konten, die bei verschiedenen Identitätsgebern verwaltet werden und erlaubt abhän gigen Diensten eine einheitliche und transparente Nutzung von Attributen einer verifizierten digitalen Identität zur Authentisierung und Einrichtung eines Zugangs zu einer digitalen Dienstleistung.
Voraussetzung für die Nutzung der digitalen Identität und somit für den Zugang zu vielen digitalen Diensten ist der Nachweis, dass ein Nutzer der Eigentümer einer digitalen Identität ist. Dies geschieht durch Authentisie rung des Nutzers. Hierzu bietet der Nutzer einen oder mehrere Faktoren zur Identifikation an, die durch das System mit der digitalen Identität
werden. Alltägliche Beispiele für Faktoren zum Identitätsnachweis sind die Eingabe einer PIN oder eines Passwortes im Rahmen eines Login-Verfah- rens, aber auch die Präsentation von biometiischen Merkmalen.
Zur Realisierung von Login-Verfahren für mehrere Anwendungen sind so genannte Single Sign On-Lösungen bekannt. Diese basieren auf einer einma ligen Anmeldung, die anschließend für weitere Anwendungen bzw. Systeme gültig ist. OpenIDConnect ist ein Industriestandard, der die einfache Reali sierung von Login-Prozessen über verschiedene Dienste und Systeme er möglicht. Ein anderes Verfahren ist z.B. SAML.
Bekannt sind auch spezifische Authentisierungsserver-Lösungen wie Ker- beros. hn Kern basieren diese Lösungen auf einem Datenspeicher, der die Nutzerdaten und Attribute persistent vorhält und in der Regel zentralisiert verwaltet wird. Der Dienst, der die Daten des Nutzers speichert und die Identifikation und Verifikation des Nutzers beim Login durchführt, wird als Identitätsgeber oder Identity Provider bezeichnet.
Die Anzahl der Identitätsgeber ist erheblich und zunehmend. Neben explizit auf die Bereitstellung von Nutzeridentitäten spezialisierten Unternehmen sind dies auch die großen soziale Netzwerke. Daneben führen auch Finan zinstitute oder Online-Händler Benutzerkonten. Im Enterprise-Umfeld kann jedes Unternehmen die Identitäten seiner Angestellten verwalten. Im allge meinen verwaltet jeder Anbieter autonom die bei ihm eingerichteten Benut zerkonten und die mit den Konten verbundenen Nutzeridentitäten.
Ein Nutzer kann eine mit einem Konto verbundene Nutzeridentität nur für eine Autorisierung bzw. ein Login bei solchen Diensten nutzen, die eine Ver trauensbeziehung zu dem Anbieter haben, der das Konto verwaltet, und wenn der Dienst von dem Identitätsgeber unterstützt wird.
Möchte ein Nutzer eine Mehrzahl von Diensten und Konten nutzen, muss er typischerweise seine Identität bei jedem Dienst einzeln hinterlegen, um sich bei dem jeweiligen Dienst anzumelden.
Bekannt ist weiter das Konzept der Föderierten Identitäten. Ein erster Ansatz hierzu beruht auf dem Austausch von Nutzeridentitäten zwischen zusam mengeschlossenen Identitätsgebern. Die Benutzerkonten werden dabei zwi schen verschiedenen Identitätsgebern repliziert. Damit kann ein Nutzer ein Login bei jedem mit einem Identitätsgeber verbunden Dienst durchführen, der das betreffende Benutzer-Konto entweder selbst verwaltet oder impor tiert hat. Dieser Ansatz wird unter anderem von der Firma Verimi verfolgt. Ein anderer Ansatz besteht in der dynamischen Ermittlung und Verbindung mit dem Identitätsgeber, der ein benötigtes Benutzer-Konto verwaltet, beim Login-Prozess über eine Vermittlungsschicht. Der anfragende Dienst ver- traut allen Identitätsgebern, die vermittelbar sind. Nach der erfolgreichen Vermittlungsphase kommuniziert der Dienst entweder direkt mit dem Iden titätsgeber, um die Attribute des End-Nutzers abzufr agen und die Autorisie- rung durchzuführen, oder weiterhin über die Vermittlungs Schicht. Ein weiterer Ansatz besteht in der dezentralen Verwaltung von Nutzerkon ten auf einem Endgerät eines Nutzers oder in einem Netzwerk. Der anfra gende Dienst vertraut dem Endgerät oder dem Netz. Beispiele hierfür sind auf der Blockchain beruhende Ansätze. Aus der US 2019/ 0010109100 Al ist ein Verfahren zum Verwalten von Nut zeridentitäten bekannt, bei dem ein zentraler Management Server mit ver schiedenen Einrichtungen verbunden ist, auf denen Identitäten in unter schiedlichen Formen hinterlegt sind. Der Management Server greift auf die verbundenen Einrichtungen zu, um eine Identität zu errichten, abzusichern oder freizugeben. Die Lösung erlaubt es insbesondere, eine Identität mit ei nem vorgegebenen Grad an Vertrauenswürdigkeit bereitzustellen.
Aus der WO 2016/01010373 Al ist ein System bekannt, in dem ein Nutze rendgerät mit einem Authentisierungsserver über eine Zugangsinstanz mit einem Netzwerk verbunden ist. Das Nutzer endgerät ist mit mehreren Au- thentisierungseinrichtungen verbunden. Bei dem Authentisierungsserver sind verschiedene Authentisierungseinrichtungen registriert. Nach erfolgrei cher Authentisierung stellt der Authentisierungsserver ein kurzlebiges Zerti fikat bereit, mit dem das Nutzerendgerät von d er Zugangsinstanz ein Ticket abholen kann. Mit dem Ticket erhält das Nutzerendgerät Zugang in das Netzwerk und die darüber erreichbaren Dienste.
Aus der US 2017/0289134 Al ist ein auf einer verteilten Datenbank beruhen des Konsens-System zur Bereitstellung von Identitäten unter den Systemteil nehmern bekannt, wobei das System das Konzept der Einmalanmeldung bzw. Single Sign On (SSO) nutzt. Das System umfasst eine Identitätsgeber- Server, einen Nutzer-Computer sowie ein oder mehrere Server von Diens tanbietern. In einer Ausführungsvariante wird bei dem Identitätsgeber-Ser ver ein verifizierter Berechtigungsnachweis hinterlegt. Der Identitätsgeber- Server erzeugt dazu einen Identitäts-Token und stellt diesen einem Nutzer- Computer zur Verfügung. Mit dem Identitäts-Token kann der Nutzer-Com puter Zugang zu einem Server eines Dienstanbieters erlangen. Für die Ertei lung des Zugangs prüft der Server unter Zugriff auf die verteilte Datenbank den Zugangsstatus in Bezug auf einen anderen System teilnehmer. So wird verhindert, dass ein Zugang aufgrund eines ungültigen Berechtigungsnach weises erlangt wird. Der Erfindung liegt die Aufgabe zugrunde, ein Verfah ren anzugeben, das es erlaubt, für den Nachweis einer Identität bei der Nut zung eines digitalen Dienstes eine bereits verifizierte digitale Identität zu nutzen, die bei einem einer Föderation von Identitätsgebern zugehörigen Identitätsgeber hinterlegt ist.
Die Aufgabe wird gelöst durch ein Verfahren mit den Merkmalen des Hauptanspruchs. Vorteilhafte Ausgestaltungen und zweckmäßige Weiterbil dungen ergeben sich aus den Merkmalen der abhängigen Ansprüche.
Das vor geschlagene Verfahren zeichnet sich durch einen zwischen die ab hängigen Diensten und die föderierten Identitätsgeber geschaltete Vermitt- lerdienst aus, der eine für alle Parteien transparente Vermittlung von Identi tätsanfragen implementiert. Transparenz bedeutet hier, dass ein abhängiger Dienst einen konkret benutzten Identitätsgeber nicht kennt und dem Identi tätsgeber seinerseits der abhängige Dienst oder dessen Nutzung durch einen Endnutzer nicht bekannt werden. Abhängiger Dienst und Identitätsgeber werden informationsmäßig entkoppelt. Bei der Bearbeitung von Identitäts anfragen bleiben der beteiligte abhängige Dienst und der beteiligte Identi tätsgeber einander gegenüber anonym. Durch die Transparenz wird beson ders eine missbräuchliche Auswertung und Analyse („Tracking") von ausge tauschten Daten verhindert.
Der Vermittler dienst ermöglicht es einem Endnutzer, für den Nachweis der Identität beim Zugang zu einem abhängigen digitalen Dienst nach seiner Wahl auf alle föderierten Identitätsgeber zurückzugreifen, die mit dem Ver mittlerdienst verbunden sind.
Das Verfahren erlaubt es abhängigen Diensten, für Login- und Registrie rungsprozesse für Benutzerkonten auf verifizierte digitale Identitäten zu rückzugreifen, die von verschiedenen Identitätsgebern verwaltet werden.
Abhängige Dienste müssen sich nur einmal in die Föderation integrieren, unabhängig von der Anzahl von Identitätsgebern, die in der Föderation zu sammengeschlossen sind. Ein abhängiger Dienst braucht dabei eine Vertrau ensbeziehung nur zu der Mittlereinheit, jedoch nicht zu den einzelnen Iden titätsgebers. Die Identitätsgeber muss der abhängige Dienst vielmehr weder kennen noch muss eine Vertrauensbeziehung bestehen. Gegenüber einem Identitätsgeber muss ein anfragender abhängiger Dienst insbesondere nicht offengelegen, auf welches Kundenkonto sich eine An frage bezieht.
In vorteilhafter Weise erhält die Mittlereinheit keine Einsicht und keinen Zu griff auf Attribute der Endnutzer uns kann nur auf Anfrage eines abhängi gen Dienstes aktiv werden. Indem Attribute in der die Mittlereinheit nur ver schlüsselt vorliegen ist sichergestellt, dass Attribute eines Endnutzers nicht von der Mittlereinheit verändert, eingesehen oder zwischengespeichert wer den können. Zudem kann die Mittlereinheit nicht ohne Auftrag durch einen abhängigen Dienst Attribute eines Endnutzers abfragen.
Die Mittlereinheit wird durch die eingebrachten technischen Maßnahmen auf eine Vermittlungs rolle fixiert und daran gehindert, selbst als Identitäts geber aufzutreten oder aktiv Attribute des Endnutzers abzurufen, um sie selbst für andere Zwecken zu verwerten.
Zweckmäßig werden durch eine Ende-zu-Ende Verschlüsselung Vertraulich keit und Integrität von Attributen sichergestellt.
In zweckmäßiger Ausgestaltung wird durch technische Maßnahmen sicher gestellt, dass die Mittlereinheit nicht ohne konkrete Anforderung eines ab hängigen Dienstes eine Anfrage an einen abhängigen Dienst stellen kann.
Das vor geschlagene Verfahren führt zu einer strikten Trennung der Rollen in einem föderativen Identitäts-Management-System. Damit eignet sich das Konzept insbesondere für Geschäftsanwendungen mit besonderen Anforde rungen an Vertraulichkeit wie z.B. im Finanzbereich. Durch die strikte Rol- lentrennung unterstützt das Konzept besonders den Schutz von persönli chen Daten und die geregelte Kooperation selbst in einem wettbewerbs-in- tensiven Umfeld.
Unter Bezugnahme auf die Zeichnung wird ein Ausführungsbeispiel der Er findung nachfolgend näher erläutert.
Es zeigen:
Fig. 1 die Struktur eines föderativen Identitäten-Management-Systems;
Fig. 2 den Ablauf der Bereitstellung eines Attributes einer verifizierten digi talen Identität für einen abhängigen Dienst in einem föderativen Iden- titäten-Management-Sy stem ;
Fig. 3 eine Folge von Bildschirminhalten, die im Rahmen einer Identitätsbe reitstellung einem Endnutzer an der Benutzer-Schnittstelle angezeigt werden;
Fig. 4 den schematischen Aufbau eines Tokens.
Fig. 1 zeigt schematisch eine auf die Hauptkomponenten reduzierte Ausge staltung eines föderativen Identitäten-Management-Systems 1. Komponen ten des dargestellten Systems sind ein Vermittler dienst 15, ein abhängiger Dienst 11, ein föderierter Identitätsgeber 21 sowie ein Nutzer- Agent 13.
Alle Komponenten 11, 13, 15, 21 sind über Datenverbindungen 24 zum Aus tausch von Daten jeweils mit den anderen Komponenten verbunden. Die Da tenverbindungen 24 können fest oder über die Fuftschnittstelle in Form ein oder mehrerer Netze ausgeführt sein. Die Datenverbindungen 24 sind durch technische Maßnahmen abgesichert, z.B. VPN oder TLS, sodass nur autori sierte Komponenten in Kommunikation treten können und die Daten gegen über Verfälschung und Ausspähung abgesichert sind.
Der Vermittlerdienst 15 setzt sich zusammen aus einer Mittlereinheit 16 und einer System-Zertifizierungsstelle 18.
Die System-Zertifizierungsstelle 18 ist als separate Einheit ausgeführt, die auf einer separaten Datenverarbeitungsanlage basiert. Aufgabe der System- Zertifizierungs stelle 18 ist die Abbildung der Vertrauens beziehungen der Komponenten durch die Ausstellung von Zertifikaten oder Token. Die Durchführung aller weiteren Aktivitäten des Vermittlerdienstes 15 gegen über dem Identitäten-Management-System 1 erfolgt durch die Mittlereinheit 16. hn Folgenden wird deshalb stellvertretend für den gesamten Vermittler dienst 15 nur die Mittlereinheit 16 angeführt, wenn diese eine Funktion durchführt.
Der Vermittlerdienst 15 verfügt über einen Speicherbereich 20, der insbeson dere zur Aufnahme von Token und Attributen 9 dient. Der Speicherbereich 20 ist in der Mittlereinheit 16 realisiert.
Der Nutzer- Agent 13 besitzt eine Endnutzer-Schnittstelle 14 zu einem End nutzer 10. Die Endnutzer-Schnittstelle 14 beinhaltet typischerweise eine An zeige und eine Tastatur. Andere und weitere Ein- und Ausgabemittel sind möglich. Insbesondere kann die End-Nutzerschnittstelle 14 Sensoren und bi ometrische Erfassungseinrichtungen für die Aufnahme von Authentisie- rungsfaktoren beinhalten. Abhängiger Dienst 11, Vermittler dienst 15 und föderierter Identitätsgeber 21 sind typischerweise in Form von Programmabläufen realisiert, die auf gängi gen Datenverarbeitungsanlagen ausgeführt werden. Die Datenverarbei tungsanlagen sind die Basis jeder Komponente.
Der Nutzer- Agent 13 kann zum Beispiel ein auf einem persönlichen Compu ter ausgeführter Browser sein oder das Bedienungsmenü eines öffentlich zu gänglichen Terminals.
Der Endnutzer 10 ist Eigner mindestens einer verifizierten digitalen Identität 2, die in einem Nutzerkonto 22 bei einem föderierten Identitätsgeber 21 hin terlegt ist. Die verifizierte digitale Identität 2 besteht z.B. aus persönlichen Daten und Angaben des Endnutzers 10 wie Name, Email- Adresse, Zustellan schrift oder Bankverbindung, deren Richtigkeit gegenüber einem Identitäts geber 21 bereits bestätigt wurde.
Die persönlichen Daten und Angaben sind Attribute 9 der digitalen Identität 2. Jedes Attribut 9 besteht aus einem Attributnamen 4 und einem Attribut wert 3.
Die Attribute 9 sind nicht auf für den Geschäftsverkehr typische Angaben wie die angeführten beschränkt. Attribute 9 können vielmehr jegliche Anga ben sein, die einem Endnutzer 10 zugeordnet sind wie beispielsweise per sönliche Bilder oder Audiodateien.
Für eine bessere Übersichtlichkeit zeigt das in Fig. 1 dargestellte System je weils einen föderierten Identitätsgeber 21, einen abhängigen Dienst 11 und einen Nutzer- Agenten 13; reale Systeme weisen in der Regel jeweils eine Mehrzahl von zusammengeschlossenen föderierten Identitätsgebern, abhän gigen Diensten und Nutzer- Agenten auf. Die Menge der verbundenen föde rierten Identitätsgeber 21 bildet zusammen die Föderation. Im weiteren wer den die föderierten Identitätsgeber einfach als Identitätsgeber 21 bezeichnet.
Bei dem Betreiber des abhängigen Dienstes 11 kann es sich beispielsweise um eine Bank, eine Behörde oder um einen Internethändler handeln. Der ab hängige Dienst 11 besteht typischerweise in der Bereitstellung einer digitalen Leistung, Dienstleistung oder Funktion im Zusammenhang mit einer digita len Ressource, für die der Zugriff auf einen bestimmten Endnutzer oder ei ner definierten Gruppe von bestimmten Endnutzern beschränkt ist. Eine di gitale Dienstleistung oder Funktion im Zusammenhang mit einer digitalen Ressource kann beispielsweise die Eröffnung oder Führung eines Bankkon tos, die Durchführung eines Kaufgeschäftes bei einem Online-Händler oder die Vornahme einer Verwaltungshandlung wie z.B. die Nutzung einer Aus weiskarte gegenüber einer Prüfungs stelle sein. Im weiteren wird die von dem abhängigen Dienst erbrachte Leistung, Dienstleistung oder Funktion kurz als digitale Dienstleistung 12 bezeichnet.
Der abhängige Dienst 11 ist zugangsgeschützt. Für die Nutzung der digita len Dienstleistung 12 ist eine Authentisierung des Endnutzers 10 erforder lich, die seine Berechtigung nachweist. Dies geschieht typischerweise in ei nem Login-Vorgang durch Vorlage von Authentisierungsdaten in Form ei ner verifizierten digitalen Identität 2 bzw. von einzelnen Attributen 9 einer verifizierten digitalen Identität 2. Für die Bereitstellung der Authentisie rungsdaten nutzt der abhängige Dienst 11 das föderative Identitäten-Ma- nagement-System 1. Bei dem abhängigen Dienst 11 ist eine Identifikation IDM der Mittlereinheit 16 hinterlegt, die diese bei der Registrierung angibt. Bei dem abhängigen Dienst 11 ist weiter ein Zertifikat ZTM der Mittlereinheit 16 mit einem öf fentlichen Schlüssel OKM der Mittlereinheit 16 hinterlegt.
Der Identitätsgeber 21 verwaltet ein oder mehrere Nutzerkonten 22 eines o- der mehrerer Endnutzer 10 und nimmt die Identifikation und Verifikation von Endnutzern 10 vor. Zweckmäßig kann der Identitätsgeber 21 auf einem dem OpenIDConnect de-fakto Standard entsprechenden ID Provider basie ren.
Der Identitätsgeber 21 verfügt über einen von einer nicht gezeigten allge mein zugänglichen Zertifizierungs stelle ausgegebenen privaten Schlüssel PPA zur Ausgabe und Signierung von Token. Der korrespondierende öffent liche Schlüssel OKI wird über ein Zertifikat an die Mittlereinheit 16 übertra gen.
Der Vermittlerdienst 15 stellt sich gegenüber der Föderation der Identitätsge ber 21 wie ein - einzelner - abhängiger Dienst 11 dar. Zu den verbundenen abhängigen Diensten 11 hin weist der Vermittlerdienst 15 eine übliche Schnittstelle auf. In einer zweckmäßigen Ausgestaltung stellt der Vermittler dienst 15 eine standard-konforme OpenIDConnect-Schnittstelle zur Verfü gung und zeigt deren Verhalten.
In der Mittlereinheit 16 ist für jeden Identitätsgeber 21 ein öffentlicher Schlüssel OKI hinterlegt, mit dem ein Token eines Identitätsgebers 21 verifi ziert werden kann. Die Schlüssel OKI werden per Zertifikat an die Mitt lereinheit 16 übergeben. Die Mittlereinheit 16 verfügt weiter über einen privaten Schlüssel PKV zur Signierung von Token. Der korrespondierende öffentliche Schlüssel OKV wird in Zertifikaten, die von einer nicht gezeigten allgemein zugänglichen Zertifizierungs stelle stammen, an die abhängigen Dienste 11 übertragen.
Für die Bereitstellung einer Identität kommunizieren die Komponenten des Identitäten-Management-Systems 1 über gesicherte Kommunikationskanäle, die die Vertraulichkeit der Daten auf dem Transportweg sicherstellen und die Authentizität der kommunizierenden Komponenten gewährleisten. Die gesicherten Kommunikationskanäle werden über die zwischen den Kompo nenten bestehenden Datenverbindungen 24 eingerichtet. Gesicherte Kommu nikationskanäle können beispielsweise in Form von TLS-Verbindungen aus gebildet sein. Die Sicherung erfolgt beispielsweise durch Mutual TLS Au- thentication.
Zwischen dem abhängigen Dienst 11 und der Mittlereinheit 16 sowie zwi schen der Mittlereinheit 16 und dem Identitätsgeber 21 besteht jeweils ein gesicherter Datenkanal zu Übertragung von Token 5, 6, 7, 8. Zwischen dem abhängigen Dienst 11 und dem Identitätsgeber 21 besteht durch die Mitt lereinheit 16 hindurch ein gesicherter Attributeübertragungskanal 19, über die die gesicherte Übertragung von Attributen 9 einer verifizierten digitalen Identität 2 möglich ist.
Die Sicherheit des Identitäten-Management-Systems 1 wird besonders mit Token und Zertifikaten erreicht.
Token 5, 6, 7, 8 werden durch die Mittlereinheit 16 und die Identitätsgeber 21 erzeugt. Unter einem Token wird ein strukturiertes verschlüsseltes Datum verstanden, das es ermöglicht, IdenÜtäts- und SicherheitsinformaÜonen über verschiedene Sicherheits bereiche hinweg gemeinsam zu nutzen. Ein
Token wird durch die Mittlereinheit 16 oder die Idenhtätsgeber 21 ausgege ben und von einer vertrauenswürdigen Komponente konsumiert, die sich auf seinen Inhalt verlässt, um ein Subjekt eines Tokens für einen sicherheits relevante Zweck zu identifizieren.
Fig. 4 veranschaulicht die Struktur eines Tokens. Sie umfasst ein Kopfteil, ei nen Nutzlast-Teil sowie einen Signatur-Teil. Der Kopfteil enthält eine ein deutige Kennung TKV, TKF des jeweiligen Token. Der Nutzlast-Teil enthält zum Beispiel den Namen eines abhängigen Dienstes 11. Der Signatur-Teil enthält eine mit dem geheimen Schlüssel des Herausgebers erstellte Signatur über den Inhalt des Kopfteils und des Nutzlast-Teils.
Ein Token ist mittels eines privaten Schüssels signiert und kann nicht verän dert werden. Seine Gültigkeit kann jederzeit durch einen korrespondieren den öffentlichen Schlüssel bzw. ein Zertißkat überprüft werden. Es hat wei terhin eine vorgegebene Lebensdauer. Nach deren Ablauf wird ein Token nicht mehr als gültig angesehen. Jedes Token hat ferner eine eindeuhge Ken nung TKV, TKF. Das Token hat einen Herausgeber; dies ist die Komponente, die das Token erzeugt und signiert hat. Der Herausgeber hat als einziger Zu griff auf den privaten Signier-Schlüssel.
Struktur und Verwendung von Token sind bekannt. Im Rahmen dieser Be schreibung wird von Token in Gestalt von JSON Web Token (JWT) ausge gangen. Andere Darstellungsform der Token sind aber ebenso möglich.
Zertifikate sind signierte Datenstrukturen. Wie bei Token ist die Integrität von Zerhhkaten durch eine Signatur geschützt. Damit können Zertihkate nach der Erzeugung nicht mehr verändert werden, bzw. die Veränderung kann leicht mit einem öffentlichen Schlüssel festgestellt werden. Zertifikate können nur von einer besonderen Komponente, z.B. der System-Zertifizie rungsinstanz 18, ausgestellt werden, der von allen Komponenten vertraut wird. Nur die besondere Komponente hat Zugriff auf den privaten Schlüssel, der zur Signierung verwendet wird. Zertifikate beziehen sich auf ein Subjekt hn hier beschriebenen Verfahrens ist das Subjekt die Kennung TKV, TKF ei nes Tokens. Zertifikate haben ferner eine Lebensdauer. Diese ist an die Le bensdauer des Tokens gebunden, dessen Kennung als Subjekt bezeichnet ist. Zertifikate binden einen öffentlichen Schlüssel an ein Subjekt.
Wie Token können Zertifikate unterschiedliche Darstellungsformen aufwei sen. Für die Funktionsfähigkeit der beschriebene Lösung ist die konkrete Darstellungsform nicht relevant.
In einer Ausgestaltungsvariante können Zertifikate auch durch Token ersetzt werden. In diesem Fall erzeugt die System-Zertifizierungsinstanz 18 für au torisierte abhängige Dienste 11 ein Token mit entsprechenden Tokenattribu ten, sodass die Zertifikationsfunktion abgebildet werden kann.
In der Mittlereinheit 16 ist für jeden in die Föderation eingebundenen Identi tätsgeber 21 mindestens ein Zertifikat ZIF hinterlegt. Die Zertifikate ZIF wer den zweckmäßig angelegt, wenn ein neuer Identitätsgeber 21 in die Födera tion integriert wird.
Anhand des Ablaufdiagramms in Fig.2 wird nachfolgend der Ablauf der Be reitstellung einer verifizierten digitalen Identität 2 für einen abhängigen Dienst 11 in einem Identitäten-Management-System 1 erläutert. Für diese Beschreibung wird ein Endnutzer 10 angenommen, der bereits ein erstes Nutzerkonto 22 bei einem Identitätsgeber 21 eingerichtet hat. In dem Nutzerkonto 22 ist bei dem Identitätsgeber 21 eine verifizierte digitale Identi tät 2 des Endnutzers 10 mit mindestens einem Attribut 9 hinterlegt, deren Richtigkeit gegenüber dem Identitätsgeber 21 bereits bestätigt wurde. Attri bute 9 können zum Beispiel Name, Email-Adresse, Zustellanschrift oder Bankverbindung sein oder auch persönliche Bilder oder Audiodateien für die konkrete Daten oder Angabe hinterlegt wurden.
Das Nutzerkonto 22 bei dem Identitätsgeber 21 ist zugangsgeschützt. Um Zugang zu erhalten ist im Rahmen eines Login-Verfahrens eine Authentisie- rung erforderlich, zum Beispiel durch Präsentation eines Passwortes.
Der Endnutzer 10 möchte auf eine geschützte digitale Dienstleistung 12 zu greifen, die von einem abhängigen Dienst 11 bereitgestellt wird, bei dem der Endnutzer 10 noch kein Zugangskonto hat bzw. gegenüber dem er sich nicht authentisiert hat. Um die digitale Dienstleistung 12 bzw. den abhängigen Dienst 11 nutzen zu können, möchte der Endnutzer 10 eine bereits hinter legte verifizierte Identität 2 nutzen. Diese soll dem abhängigen Dienst 11 be reitgestellt werden.
Die Durchführung der Identitätsbereitstellung setzt einen sicheren Kommu nikationskanal zwischen dem abhängigen Dienst 11 und dem Identitätsgeber 21 voraus. Ein solcher sicherer Kommunikationskanal kann mit einem übli chen Verfahren zum Einrichten eines sicheren Übertragungskanals einge richtet werden. Beispielsweise kann ein Schlüsselaustausch durch ein„Key- Wrapping" Verfahren vorgesehen sein, in dem ein geheimer Schlüssel in ei nem Kryptogramm übertragen wird. Der Vorgang der Bereitstellung einer verifizierten digitalen Identität 2 wird ausgelöst, wenn ein Endnutzer 10 eine bei einem abhängigen Dienst 11 ange botene digitale Dienstleistung 12 nutzen möchte, die im Rahmen eines Lo- gin-Vorgangs die Durchführung einer Authentisierung erfordert. Nachfol gend werden die Schritte des Vorgangs erläutert.
Schritt 100: Der Endnutzer 10 wählt über die Endnutzer-Schnittstelle 14 ei nen gewünschten abhängigen Dienst 11 aus. Der Endnutzer 10 klickt dazu zum Beispiel auf ein auf einer Auswahlseite des abhängigen Dienstes 11 dar gestelltes Schaltfeld, mit dem die Internet-Adresse des abhängigen Dienstes ausgewählt wird.
Schritt 102: Der Nutzer- Agent 13, z.B. ein Web-Browser, eröffnet eine Verbin dung zu der öffentlichen Schnittstelle des ausgewählten abhängigen Diens tes 11 und schickt eine Anfrage an diesen. Die Anfrage kann beispielsweise die Form einer Login-Anfrage an die Internetadresse des abhängigen Diens tes sein
Schritt 104: Der abhängige Dienst 11 prüft die Anfrage. Stellt er fest, dass die Anfrage auf eine geschützte digitale Dienstleistung 12 gerichtet ist, die eine Authentisierung erfordert, und liegen entsprechende Authentisierungsdaten nicht vor, startet er einen Login-Vorgang. hn angenommenen Szenario stellt der abhängige Dienst 11 fest, dass die durch die Anfrage adressierte digitale Dienstleistung 12 geschützt ist und keine Authentisierungsdaten vorliegen. Der abhängige Dienst 11 startet des halb einen Login-Vorgang. Schritt 106: Der abhängige Dienst 11 erzeugt eine Auswahlseite (Website) mit einem Schaltfeld, über das die Herstellung einer Verbindung zu der Mitt lereinheit 16 ausgelöst wird. Zweckmäßig enthält die Auswahlseite Angaben zu dem abhängigen Dienst 11. Sie kann weitere Angaben enthalten, zum Bei spiel Namen der für den Login-Vorgang benötigten Attribute. Die Auswahl seite schickt der abhängige Dienst 11 an den Nutzer- Agenten 13.
Schritt 108: Die Auswahlseite wird dem Endnutzer 10 über die Endnutzer- Schnittstelle 14 angezeigt.
Fig. 3a zeigt beispielhaft einen Bildschirminhalt mit einer angezeigten Aus wahlseite. Sie enthält eine Bezeichnung des abhängigen Dienstes („Abhängi ger Dienst"), eine Bezeichnung des ausgeführten Verfahrens Schrittes („Sign- In Prozess") sowie zwei Schaltfelder, von denen eines („Sign-In mit lokalem Konto") sich auf ein lokales Konto bei dem abhängigen Dienst richtet und das andere („Sign-In mit ID-Föderation") die Bereitstellung einer digitalen Identität über einen Identitätsgeber auslöst.
Der Endnutzer 10 betätigt das auf den Identitätsgeber zeigende Schaltfeld. Der Nutzer- Agent 13 stellt daraufhin eine Verbindung zu der Mittlereinheit 16 her.
In einer alternativen Ausführung veranlasst die Auswahlseite den Nutzer- Agenten 13 über eine direkte Weiterverweisung (Redirection) ohne Betäti gung des Schaltfeldes unmittelbar zur Herstellung einer Verbindung mit der Mittlereinheit 16. Schritt 110: Über die hergestellte Verbindung schickt der Nutzer-Agent 13 eine Autorisierungsanfrage an die Mittlereinheit 16. Die Autorisierungsan- frage enthält zweckmäßig Angaben zu dem gewählten abhängigen Dienst 11. Sie kann weiterhin Namen von bestimmten Attributen enthalten, die dem abhängigen Dienst 11 vorgelegt werden sollen. Sie kann darüber hinaus wei tere Angaben enthalten, die den vom Endnutzer 10 beabsichtigten Zugriff auf den abhängigen Dienst 11 charakterisieren. Die Autorisierungsanfrage kann beispielsweise in Form eines GET-Kommandos erfolgen, mit dem die Übermittlung einer Auswahlseite zur Auswahl eines Identitätsgebers ange fordert wird.
Schritt 112: Auf die Autorisierungsanfrage hin erzeugt die Mittlereinheit 16 eine Auswahlseite, in der alle in der Föderation zusammengeschlossenen Identitätsgeber 21 aufgeführt sind.
Die äußere Form der Auswahlseite und die Darstellung der Identitätsgeber sind frei gestaltbar. Denkbar ist zum Beispiel eine Auswahlseite mit Finks, Buttons, Icons oder ähnlichen Steuerelementen.
Fig. 3b zeigt beispielhaft einen Bildschirminhalt mit einer angezeigten Aus wahlseite. Sie enthält eine Bezeichnung der Mittlereinheit („ID-Mana gement Broker") sowie vier Schaltfelder, von denen drei zu verschiedenen Identitäts gebern führen („ Authentifikation mit ID-A",„ Authentifikation mit ID-B",
„ Authentifikation mit ID-C") und eines zurück zu dem abhängigen Dienst („Zurück zum abhängigen Dienst").
Vorgesehen sein kann, dass die Auswahlseite personalisiert wird, indem eine Vorselektion von angebotenen Identitätsgebern erfolgt. Als Kriterien können zum Beispiel mit der Autorisierungsanfrage übersandte Angaben zu dem gewählten abhängigen Dienst 11, Attributnamen 4 oder Angaben zu weiteren bekannten Eigenschaften des beabsichtigten Zugriffs verwendet werden.
In einer weiteren Ausgestaltung kann vorgesehen sein, dass der Endnutzer 10 aufgefordert wird, seinen Namen oder ein anderes persönliches Datum zu übermitteln, um eine personalisierte Auswahlseite zu erzeugen. Ferner kön nen auch andere Faktoren wie z.B. der Ort zur Gestaltung der Auswahlseite verwendet werden.
Schritt 114: Die Auswahlseite schickt die Mittlereinheit 16 an den Nutzer- Agenten 13. Über die Endnutzer-Schnittstelle 14 wird die Auswahlseite dem Endnutzer 10 angezeigt.
Schritt 200: Der Endnutzer 10 selektiert in der angezeigten Auswahlseite ei nen Identitätsgeber 21, der die für den anstehenden Login-Vorgang benötig ten Attribute 9 bereitstellen kann. Es wird angenommen, dass dem Endnut zer 10 bekannt ist, welcher Identitätsgeber 21 geeignet ist. Gegebenenfalls kann der Endnutzer 10 die Namen 4 der benötigten Attribute von dem ab hängigen Dienst 11 abfragen. Ist die Auswahlseite personalisiert, werden zweckmäßig nur solche Identitätsgeber 21 zur Auswahl angeboten, die die benötigten Attribute 9 bereitstellen können.
Schritt 202: Nachdem der Endnutzer 10 einen Identitätsgeber 21 ausgewählt hat, schickt der Nutzer- Agent 13 eine Anfrage an den gewählten Identitäts geber 21. Schritt 204: Auf die Anfrage erzeugt der Identitätsgeber 21 eine Auswahl seite für die Identifikation und Verifikation des Endnutzers 10 und schickt diese an den Nutzer- Agenten 13, wo sie über die Endnutzer-Schnittstelle 14 dem Endnutzer 10 angezeigt wird.
Fig. 3c zeigt beispielhaft einen Bildschirminhalt mit einer angezeigten Aus wahlseite. Sie enthält eine Bezeichnung des Identitätsgebers („ID-Pro vieler"), eine Bezeichnung des ausgeführten Verfahrensschrittes („Identifikation & Verifikation"), interaktive Felder („Nutzer Name",„Password",„OTP") zur Eingabe von Authentisierungsdaten sowie ein Schaltfeld zur Prüfung von eingegebenen Daten („Starte Authentifizierung"). Die Eingabe von Authenti sierungsdaten kann auch, wie in Fig. 3c dargestellt, mittels eines Hilfsgerä tes, etwa eines Handys, erfolgen. Als Authentisierungsdaten kommen auch biometrische Daten, zum Beispiel ein Fingerabdruck, in Betracht.
Schritt 300: Der Endnutzer 10 authentifiziert sich in an sich bekannter Weise durch Präsentation eines oder mehrerer Authentisierungsfaktoren, die den Endnutzer 10 eindeutig identifizieren. Beispielsweise präsentiert er über ent sprechende Eingabemittel seinen Namen und/ oder ein Password und/ oder, ein biometrisches Merkmal wie einen Fingerabdruck oder ein Irismuster.
Schritt 302: Der Nutzer- Agent 13 leitet die Eingaben an den Identitätsgeber 21. Der Identitätsgeber 21 prüft die präsentierten Authentisierungsfaktoren. Bei erfolgreicher Prüfung ist der Endnutzer 10 identifiziert und es steht fest, dass der Endnutzer 10 zu einem bei dem Identitätsgeber 21 bestehenden Nutzerkonto 22 gehört. Der Identitätsgeber 21 erzeugt dann einen Aktions code CAK, der eine eindeutige Identifikation der erfolgten Authentifikation ermöglicht. Der Aktionsode CAK dient im weiteren Verfahren dazu, von einem Identi tätsgeber 21 ein zweites Datum 7 in Form eines FI-Zugangstokens zu erhal ten, mit dem der Identitätsgeber 21 die Berechtigung eines Datenaustausche zwischen dem Vermittlerdienst 15 und dem Identitätsgeber 21 überprüft.
Die Nutzung muss innerhalb einer kurzen Zeitspanne ab Ausgabe des Akti onscodes CAK erfolgen.
Schritt 304: Der Identitätsgeber schickt den Aktionscode CAK als Antwort an den Nutzer-Agenten 13. Die Antwort beinhaltet eine Weiterverweisung.
Schritt 306: Der Nutzer- Agent 13 leitet die Antwort des Identitätsgebers 21 mit dem Aktionscode CAK in einer Anfrage an die Mittlereinheit 16 weiter. Die Mittlereinheit 16 erhält die Anfrage und den Aktionscode CAK als Para meter.
Schritt 308: Die Mittlereinheit 16 kontaktiert den Identitätsgeber 21 mit dem Aktionscode CAK als Parameter.
Schritt 310: Der Identitätsgeber 21 prüft den erhaltenen Aktionscode CAK auf Übereinstimmung mit dem in Schritt 302 ursprünglich versandeten Akti onscode CAK.
Ist das der Fall, d.h. handelt es sich um dieselbe laufende Authentifikation, erzeugt der Identitätsgeber 21 einen FI-Zugangstoken 7. Weiter erzeugt der Identitätsgeber einen FI- Auffrischungstoken 8. Weiterhin erzeugt der Identi tätsgeber 21 eine Sitzungsidentifikation IDS.
Der FI-Zugangstoken 7 dient im weiteren Verlauf des Verfahrens dazu, ei nen sicheren Attributeübertragungskanal 19 aufzubauen, über den für den Zugriff auf eine geschützte digitale Dienstleistung 12 benötigte Attribute 3 übertragen werden.
Mit dem FI- Auffrischungstoken 8 kann automatisiert ein neues FI- Zugangstoken 7 generiert werden, wenn das alte abgelaufen ist.
Schritt 312: FI-Zugangstoken 7, FI- Auffrischungstoken 8 und Sitzungsidenti fikation IDS übergibt der Identitätsgeber 21 an die Mittlereinheit 16. Zweck mäßig übermittelt der Identitätsgeber 21 zudem eine Liste mit den Attribut namen 4, die zu dem Nutzerkonto 22 zur Verfügung stehen.
Die Liste der Attributnamen 4 der zur Verfügung stehenden Attribute 9 spei chert die Mittlereinheit 16 in ihrem Speicherbereich 20. Zweckmäßig legt sie eine Tabelle 23 an, in die im Verlauf des weiteren Verfahrens weitere Ein träge hinzugefügt werden.
Schritt 314: Die Mittlereinheit 16 verifiziert den FI-Zugangstoken 7 und den FI- Auffrischungstoken 8 mithilfe des hinterlegten Zertifikats ZIF des Identi tätsgebers. Ist die Prüfung der Token 7, 8 erfolgreich, gilt der Endnutzer 10 für die Mittlereinheit 16 als verifiziert.
Die Mittlereinheit 16 speichert den FI-Zugangstoken 7 und den FI- Auffrischungstoken 8 in ihrem Speicherbereich 20. In einfacher Weise nutzt die Mittlereinheit 16 dazu die Tabelle 23 und fügt die Token 7, 8 hinzu. Die Token 7, 8 werden nicht an den Endnutzer 10, den Nutzer- Agenten 13 oder an den abhängigen Dienst 11 übergeben.
Schritt 316: Die Mittlereinheit 16 erzeugt eine Auswahlseite mit einer Liste mit den Attributnamen 4 der zur Verfügung stehenden Attribute 9 und schickt diese an den Nutzer- Agenten 13, wo sie dem Endnutzer 10 über die Endnutzer-Schnittstelle 14 angezeigt wird.
Fig. 3d zeigt beispielhaft einen Bildschirminhalt einer Auswahlseite mit einer angezeigten Liste von Attributnamen. Sie enthält eine Bezeichnung des Ver mittlerdienstes („ID-Mana gern ent Broker"), eine Bezeichnung des Verfah rensschritte („Zustimmung zur Weitergabe an abhängigen Dienst"), den Na men eines gesonderten Attributs in Form eines Endnutzernamens („John- Doe"), eine zweispaltige Tabelle mit den Namen jeweils weiteren Attribute („profile", email",„address", phone") und Zustimmungsbox sowie ein Schaltfeld („Zustimmung") zur Zustimmung zu einer Attributeauswahl.
Schritt 400: Der Endnutzer 10 selektiert die Namen 4 der Attribute, für die eine Weitergabe der Attribute 3 an den abhängigen Dienst 11 erlaubt werden soll. Durch Betätigung eines entsprechenden Schaltfeldes in der Auswahl seite werden die ausgewählten Attribute 9 zur Weitergabe freigegeben.
Grundsätzlich kann der Endnutzer 10 auch alle Attribute 9 bzw. die gesamte digitale Identität 2 auswählen.
Schritt 402: Der Nutzer- Agent 13 sendet die Attributnamen 4 der zur Weiter gabe an den abhängigen Dienst 11 freigegebenen Attribute 9 an die Mitt lereinheit 16.
Schritt 404: Die Mittlereinheit 16 speichert die für den gewählten abhängigen Dienst 11 freigegebenen Attributnamen 4 in ihrem Speicherbereich 20.
Zweckmäßig fügt sie die Einträge in die Tabelle 23 ein.
Soll später erneut eine Autorisierung für denselben abhängigen Dienst 11 er folgen, kann die Mittlereinheit 16 auf die im Speicherbereich 20 abgelegte Freigabe zurückgreifen. Eine erneute Freigabe durch den Endnutzer 10 durch Ausführung des Schrittes 400 ist dann nicht erforderlich.
Schritt 406: Die Mittlereinheit 16 erzeugt einen Sitzungscode CSM. Der Sit zungscode CSM dient im weiteren Verlauf des Verfahrens dazu, von der Mittlereinheit 16 ein erstes Datum in Form eines V-Zugangstokens 5 zu er halten. Mit diesem überprüft der Vermittlerdienst 15 die Berechtigung eines Datenaustauschs zwischen dem Vermittlerdienst 15 und dem abhängigem Dienst 11.
Die Mittlereinheit 16 erzeugt weiter eine Weiterverweisungsantwort mit dem Sitzungscode CSM und einer Status-Information. Den Sitzungscode CSM speichert die Mittlereinheit 16 zweckmäßig in ihrem Speicherbereich 20; zweckmäßig wird er in die Tabelle 23 eingefügt.
Schritt 408: Der Nutzer- Agent 13 leitet die Weiterverweisungsantwort an den abhängigen Dienst 11 weiter. Als Parameter werden der Sitzungscode CSM sowie die Status-Information übertragen.
Schritt 410: Der abhängige Dienst 11 sendet eine Token-Anfrage an die Mitt lereinheit 16. Als Parameter wird der Sitzungscode CSM übergeben.
Schritt 412: Die Mittlereinheit 16 identifiziert über den Sitzungscode CSM die Sitzung und erzeugt mit dem Signier-Schlüssel der Mittlereinheit einen V- Zugangs-Token 5 mit einer Kennung TKV sowie einen V-Auffrischungs-To- ken 6. Der Kennung TKV des V-Zugangstokens 5 wird dabei durch eine Hash- Funktion aus der Kennung TKF des FI-Zugangstokens 7 des Identitätsge bers gebildet. Auf diese Weise wird eine technische Verknüpfung zwischen dem FI-Zugangstoken 7 und dem V-Zugangstoken 5 hergestellt. Ausgehend von einem FI-Zugangstoken 7 kann eine bestehende Verknüpfung überprüft werden.
Der V-Zugangs-Token 5 und der V-Auffrischungs-Token 6 werden an den abhängigen Dienst 11 ausgegeben. Der V-Zugangs-Token 5 dient im weite ren Verlauf des Verfahrens zum Aufbau eines sicheren Attributeübertgungs- kanals 19, über den für den Zugriff auf eine geschützte digitale Dienstleis tung 12 benötigte Attribute 3 übertragen werden. Der V-Zugangs-Token 5 und der V-Auffrischungs-Token 6 werden nicht an den Endnutzer 10 oder den Nutzer-Agenten 13 übergeben.
Mit dem V-Auffrischungs-Token 6 kann der abhängige Dienst 11 einen neuen V-Zugangs-Token 5 beantragen.
Weiter erzeugt die Mittlereinheit 16 einen Eintrag in ihren internen Speicher bereich 20, welche die Attributnamen 4 enthält, die der Endnutzer 10 freige geben hat. Der Eintrag bezeichnet die laufende Bereitstellungssitzung und enthält weiterhin die FI-Zugangstoken 7, 8 sowie die durch die Mittlereinheit 16 erzeugten V-Zugangstoken 5, 6. In einfacher Weise können alle Einträge in der Tabelle 23 zusammengefasst sein. Zweckmäßig sind in der Tabelle 23 weitere Daten hinterlegt, die im Rahmen der Bereitstellung der Attribute be nötigt werden. Die Tabelle 23 kann beispielsweise wie folgt aussehen:
Die Mittlereinheit 16 erzeugt weiterhin eine eindeutige Kontokennung KID und speichert sie in ihrem Speicherbereich 20. Die Kontokennung KID kenn zeichnet den Endnutzer 10 bzw. das Nutzerkonto 22 eindeutig in der gesam- ten Föderation. Die Kontokennung KID wird einmalig für jedes Nutzerkonto 22 erzeugt und ist unveränderlich.
Die Kontokennung KID basiert zweckmäßig auf einer verschleierten Ver knüpfung eines Nutzerkontos 22 und eines Identitätsgebers 21. Die Ver- schleierung erfolgt so, dass keine Rückschlüsse auf den Identitätsgeber 21 möglich sind. Beispielsweise kann eine Hash-Funktion angewendet werden, mit der ein Hashwert über eine gegenüber dem Identitätsgeber 21 genutzte OpenldConnect Identifikation der Mittlereinheit 16 gebildet wird. In einer anderen Ausführung wird ein Hashwert über eine von der Mittlereinheit 16 durch Konfiguration im Rahmen des Registrierungsprozesses zur Aufnahme eines Identitätsgebers 21 in die Föderation festgelegte Konstante in den Stammdaten der Mittlereinheit 16 für den Identitätsgeber 21 gebildet. Schritt 414: V-Zugangstoken 5 und V- Auffrischungstoken 6 schickt die Mitt lereinheit 16 an den abhängigen Dienst 11.
Schritt 416: Der abhängige Dienst 11 verifiziert die erhaltenen V-Token 5, 6 mithilfe des öffentlichen Schlüssels OKM aus dem vorab hinterlegten Zertifi kat ZTM der Mittlereinheit.
Schritt 498: Für die Übertragung von Attributen 3 von dem Identitätsgeber 21 an den abhängigen Dienst 11 über die Endnutzerinformationsschnittstelle wird ein Attributeübertragungskanal 19 eingerichtet.
Dazu wird zwischen dem abhängigen Dienst 11 und der System-Zertifizie rungsinstanz 18 eine gesicherte Verbindung mit wechselseitiger Authentifi- zierung auf gebaut, zum Beispiel eine TLS B2B Verbindung.
Der abhängige Dienst 11 erzeugt ein Schlüsselpaar mit einem öffentlichen Schlüssel OKA und einem privaten Schlüssel PKA. Der abhängige Dienst 11 erzeugt weiter eine Sitzungsidentifikation SZI. In einfacher Weise kann als Sitzungs Identifikation SZI die Kennung TKV des V-Zugangstokens 5 dienen. Der öffentliche Schlüssel OKA und die Sitzungsidentifikation SZI werden über die gesicherte Verbindung in einer Zertifikatsanfrage an die System- Zertifizierungsinstanz 18 gesendet.
Der private Schlüssel PKA verbleibt bei dem abhängigen Dienst 11. Die Zer tifikatsanfrage kann als CSR (Certificate Signing Request)-Kommando erfol gen, das als Parameter den öffentlichen Schlüssel OKA sowie die Sitzungsi dentifikation SZI aus dem V-Zugangstoken 5 enthält mit dem ein Sitzungs zertifikat angefordert wird. Schritt 500: Auf die Zertifikatsanfrage hin erzeugt die System-Zertifizie rungsinstanz 18 für die Sitzungsidentifikation SZI ein Sitzungszertifikat ZSZ.
Das Sitzungszertifikat ZSZ ist nur kurze Zeit gültig; seine Laufzeit entspricht mindestens der Lebensdauer des V-Zugangstokens 5. Das Sitzungszertifikat ZSZ enthält die Kennung TKV des V-Zugangstokens 5 und einen öffentli chen Schlüssel für die Sitzungsidentifikation SZI. Das Sitzungszertifikat ZSZ dient zudem als Nachweis, dass der abhängige Dienst 11 berechtigt ist, An fragen an die Mittlereinheit 16 zu stellen.
Schritt 502: Das Sitzungszertifikat ZSZ schickt die System-Zertifizierungs instanz 18 an den abhängigen Dienst 11.
Schritt 504: Der abhängige Dienst 11 initiiert den Aufbau eines sicheren At tributeübertragungskanals 19 über einen Aufruf an die Mittlereinheit 16.
Dies kann über einen eigenen Endpunkt erfolgen oder parametergesteuert über die Schnittstelle für einen Attributeübertragungskanal 19. Die Initiie rung kann beispielsweise mithilfe eines POST-Kommandos erfolgen, das als Parameter das V-Zugangstoken sowie das Sitzungszertifikat ZSZ übergibt..
Schritt 506: Die Mittlereinheit 16 prüft, ob der V-Zugangstoken 5 gültig und nicht abgelaufen ist. Ist das der Fall, ermittelt die Mittlereinheit 16 mithilfe des Verzeichnisses 20 das zu dem V-Zugangstoken 5 korrespondierende FI- Zugangstoken 7 des Identitätsgebers.
Den ermittelten FI-Zugangstoken 7 übersendet die Mittlereinheit 16 zusam men mit dem Sitzungs Zertifikat ZSZ an den Identitätsgeber 21. Schritt 508: Der Identitätsgeber 21 prüft, ob das von der Mittlereinheit 16 er haltene FI-Zugangstoken 7 gültig und nicht abgelaufen ist.
Weiter überprüft der Identitätsgeber 21 das Sitzungszertifikat ZSZ. Das Sit zungszertifikat ZSZ wird als gültig akzeptiert, wenn es ein CA-IDP Zertifikat ist und von der System-Zertifizierungsinstanz 18 signiert wurde, es nicht ab gelaufen ist und die im Subjekt des Sitzungszertifikats ZSZ enthaltene Ken nung TKV des V-Zugangstokens 5 dem damit verknüpften FI- Zugangstoken Token 7 entspricht. Für diese Prüfung rechnet der Identitäts geber 21 den Hash über die Token-Kennung ZKF des eigenen FI- Zugangstokens 7 nach. Die Bereitstellung der Signatur durch das Zertifikat ZSZ kann auch über eine Zertifikatskette erfolgen.
Schritt 510: Ist das Sitzungszertifikat ZSZ gültig, erzeugt der Identitätsgeber 21 einen zufälligen symmetrischen Sitzungsschlüssel KSY mit ausreichender Länge. Zweckmäßig werden mehrere Schlüssel zur Sicherung jeweils der In tegrität, der Vertraulichkeit und der Sequenz der Nachrichten erzeugt. Die Generierung der Schlüssel erfolgt zweckmäßig durch eine Schlüsselableitung aus einem zufälligen gemeinsamen Startwert.
Mit dem Sitzungsschlüssel KSY richtet der Identitätsgeber 21 auf seiner Seite den sicheren Attributeübertragungskanal 19 zu dem abhängigen Dienst 11 ein.
Schritt 512: Der Sitzungsschlüssel KSY wird mit dem öffentlichen Schlüssel OKA aus dem Sitzungszertifikat ZSZ zu einem Kryptogramm verschlüsselt und an die Mittlereinheit 16 übergeben. Da der private Schlüssel PKA beim abhängigen Dienst 11 verbleibt, hat die Mittlereinheit 16 keinen Zugriff auf den Sitzungsschlüssel KSY. Schritt 514: Die Mittlereinheit 16 gibt das Kryptogramm mit dem verschlüs selten Sitzungsschlüssel KSY an den abhängigen Dienst 11 weiter. Schritt 516: Der abhängige Dienst 11 entschlüsselt mit seinem privaten Schlüssel PKA das Kryptogramm und ermittelt so den Sitzungsschlüssel KSY. Mit diesen richtet der abhängige Dienst 11 den sicheren Attributeüber tragungskanals 19 auf seiner Seite ein. Der abhängige Dienst 11 verwendet die gleiche Schlüsselableitung wie der Identitätsgeber 21. Der Attributeüber- tragungskanal 19 ist damit hergestellt.
Nach Errichtung des Attributeübertragungskanals 19 erfolgt die Bereitstel lung der verifizierten digitalen Identität 2 bzw. von Attributen 9 vom Identi tätsgeber 21 an den abhängigen Dienst 11. Dabei überprüft die Mittlereinheit 16 die Berechtigung des Datenaustausche zwischen Mittlereinheit 16 und ab hängigem Dienst 11 aufgrund des V-Zugangstokens 5 und der Identitätsge ber 21 die Berechtigung des Datenaustausche zwischen Mittlereinheit 16 und Identitätsgeber 21 aufgrund des FI-Zugangstokens 7. Schritt 600: Der abhängige Dienst 11 ruft die Attribute 9 des Endnutzers von der Mittlereinheit 16 ab. Zur Authentisierung enthält der Aufruf den V-Zu- gangstoken 5. Der Aufruf kann zum Beispiel die Form eines GET- Kommandos besitzen. Schritt 602: Die Mittlereinheit 16 prüft den von dem abhängigen Dienst 11 er haltenen V-Zugangstoken 5. Im Gutfall ermittelt die Mittlereinheit 16 den FI- Zugangstoken 7, der zu dem von der Mittlereinheit erzeugten V-Zugangsto ken 5 aus der Anfrage gehört. Die Zuordnung kann direkt durch den V-Zu gangstoken 5 oder über die Sitzungsidentifikation SZI geschehen. Kann der V-Zugangstoken 5 nicht akzeptiert werden, gibt die Mittlereinheit 16 eine Fehlermeldung an den abhängigen Dienst 11 zurück.
Schritt 604: Die Mittlereinheit 16 schickt eine Anfrage an den Identitätsgeber 21. Die Anfrage enthält den FI-Zugangstoken 7 sowie die Attributnamen 3 der benötigten Attribute 9.
Schritt 606: Der Identitätsgeber 21 prüft den FI-Zugangstoken 7 darauf, ob er gültig ist und eine gültige Signatur aufweist. Ist das der Fall, erzeugt der Identitätsgeber 21 eine Antwort mit den angeforderten Attributen 9 des End nutzers, die für die Föderation sichtbar sein sollen, und den Attributnamen 4. Die Attributwerte 3 werden mit dem Sitzungsschlüssel KSY verschlüsselt. Die Attributnamen 4 der Attribute 9 werden unverschlüsselt in die Antwort aufgenommen.
Schritt 608: Die Antwort mit den verschlüsselten Attributen 9 sendet der Identitätsgeber 21 an die Mittlereinheit 16. Die Datenübertragung zwischen Mittlereinheit 16 und Identitätsgeber 21 erfolgt über den sicheren Attribute übertragungskanal 19.
Schritt 610: Die Mittlereinheit 16 prüft anhand der Attributnamen 4, ob die in der Antwort enthaltenen verschlüsselten Attribute 9 zur Weitergabe an den abhängigen Dienst 11 durch den Endnutzer 10 freigegeben wurden. Ist das der Fall erzeugt die Mittlereinheit 16 eine Liste mit den freigegebenen ver schlüsselten Attributen 3.
Schritt 612: Die Liste gibt die Mittlereinheit 16 als Antwort zurück an den ab hängigen Dienst 11. Schritt 614: Der abhängige Dienst 11 entschlüsselt aus der Antwort die ver schlüsselten Attributwerte 3 mit dem vom Identitätsgeber 21 übermittelten Sitzungsschlüssel KSY.
Schritt 616: Basierend auf den danach vorliegenden Attributen 9 des Endnut zers führt der abhängige Dienst 11 die Autorisierung durch und entscheidet, ob die Nutzung des angefragten abhängigen Dienstes 11 für die gewünschte digitale Dienstleistung 12 gewährt wird. Das Ergebnis wird dem Endnutzer 10 auf der Endnutzer-Schnittstelle 14 angezeigt. Beispielsweise wird dem Endnutzer 10 ein Nutzerkonto mit den übermittelten Attributen 9 angezeigt.
Fig. 3e zeigt beispielhaft einen Bildschirminhalt mit einer angezeigten Ergeb nisseite. Der Bildschirmeinhalt enthält eine Bezeichnung des abhängigen Dienstes („Abhängiger Dienst"), eine Bezeichnung des Verfahrensschrittes („Nutzer Konto"), einen Endnutzernamen ("John Doe") sowie eine zweispal tige Tabelle mit der Bezeichnung von Attributen („Id",„email",„email-sta- tus",„phone") und zugehörigen Werten („John-Doe",„John, Doe@....de", verified",„+1098922222"). hn Rahmen der grundlegenden Idee, mittels eines Vermittlerdienstes eine transparente Möglichkeit zur Bereitstellung einer verifizierten digitalen Identität in einem System mit einer Mehrzahl von abhängigen Diensten und einer Mehrzahl von Identitätsgebern gestattet das beschrieben Verfahren eine Vielzahl von Ausgestaltungsmöglichkeiten, die hier nicht im Einzelnen erläutert sind. Insbesondere ist es grundsätzlich möglich, die in den Figuren gezeigten und vorstehend beschriebenen Ausführungsbeispiele ganz oder in Teilen zu kombinieren. Einzelne Elemente können auch weggelassen oder zusammengefasst werden, z.B. einzelne der Verfahrensschrite. Auch kön nen Elemente durch vergleichbare andere Elemente ersetzt oder ergänzt werden. Beispielsweise ist zur gesicherten Übertragung von Attributen 9 die Einrich tung eines sichereren Übertragungskanals durch einfachen Schlüsselaus tausch beschrieben. Andere Verfahren kommen jedoch ebenfalls in Betracht. Dies gilt insbesondere auch für das konkrete Verfahren zur Schlüssel Verein barung und zur Ableitung der Sitzungsschlüssel. Einzelne Funktionen kön- nen auch anderen Komponenten zugeordnet sein. Beispielsweise können einzelne von der Mitlereinheit ausgeführten Funktionen auch ganz oder teilweise in der System-Zertifizierungsinstanz realisiert sein.
Datenstrukturbezeichnungen
IDM Identifikation der Mittlereinheit
ZTM Zertifikat der Mittlereinheit
OKM Öffentlicher Schlüssel der Mittlereinheit
CSM Sitzungscode der Mittlereinheit
PPA Privater Schlüssel einer allgemeinen Zer ti fi i er ungs stelle OKI Öffentlicher Schlüssel des Identitätsgebers
PKV Privater Schlüssel des Vermittler dienstes
KSY Symmetrischer Sitzungsschlüssel des Identitätsgebers ZIF Zertifikat des Identitätsgebers
TOK Kennung Token
CAK Aktionscode
IDS Sitzungsidentifikation
TKV Kennung TKV des V-Zugangstokens
TKF Kennung TKF des FI-Zugangstokens
KID Kontokennung KID
OKA Öffentlicher Schlüssel erzeugt vom abhängigen Dienst PKA Privater Schlüssel erzeugt vom abhängigen Dienst ZSZ Sitzungszertifikat ZSZ der Zertifikatsinstanz
SZI Sitzungsidentifikation SZI
Bezugszeichenliste
1. Identitäten-Management-Sy stem
2. Digitale Identität
3. Attributwerte
4. Attributnamen
5. V-Zugangstoken 6. V-Auffrischungstoken
7. FI-Zugangstoken
8. FI-Auffrischungstoken
9. Attribute
10. Endnutzer
11. Abhängiger Dienst
12. Digitale Dienstleistung
13. Nutzer-Agent
14. Endnutzer-Schnittstelle
15. Vermittler dienst
16. Mittlereinheit
18. System-Zertifizierungsinstanz
19. Attributübertragungskanal
20. Speicherbereich
21. Föderierter Identitätsgeber (ID Provider)
22. Nutzerkonto
23. Tabelle
24. Datenverbindungen

Claims

P a t e n t a n s p r ü c h e
1. Verfahren zur Authentisierung eines Endnutzers (10) gegenüber ei nem abhängigen Dienst (11) durch Bereitstellung wenigstens eines At tributs einer bei einem föderierten Identitätsgeber (21) hinterlegten ve rifizierten digitalen Identität (2) mit Hilfe eines Vermittlerdienstes
(15),
dadurch gekennzeichnet, dass
ein Attribut (9) bereitgestellt wird, wenn der Endnutzer (10) sich ge genüber dem föderierten Identitätsgeber (21) erfolgreich authentisiert und das Attribut (9) zur Verwendung durch den abhängigen Dienst (11) freigegeben hat,
wobei für die Bereitstellung des Attributs (9) von dem Vermittler dienst (15) ein Datenaustauch mit dem abhängigen Dienst (11) und ein Datenaustausch mit dem föderierten Identitätsgeber (21) durchge führt wird.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass
die Berechtigung eines Datenaustausche zwischen Vermittlerdienst (15) und abhängigem Dienst (11) von dem Vermittlerdienst (15) auf grund eines ersten Datums (5) überprüft (602) wird, das der Vermitt lerdienst (15) zuvor erzeugt hat, und
die Berechtigung eines Datenaustausche zwischen Vermittlerdienst (15) und föderiertem Identitätsgeber (21) von dem föderierten Identi tätsgeber (21) aufgrund eines zweiten Datums (7) überprüft (606) wird, das der föderierte Identitätsgeber (21) zuvor erzeugt hat.
3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass
von dem Vermittler dienst (15) als erstes Datum ein V-Zugangstoken (5) erzeugt wird (412) und die Berechtigung einer Anfrage durch den abhängigen Dienst (11) zur Bereitstellung von Attributen einer verifi zierten digitalen Identität (2) unter Verwendung des V-Zugangsto- kens (5) geprüft wird,
und von dem föderierten Identitätsgeber (21) als zweites Datum ein FI-Zugangstoken (7) erzeugt wird (310) und die Berechtigung einer Anfrage durch den Vermittlerdienst (15) zur Übergabe von Attributen (9) einer bei dem föderativen Identitätsgeber (21) hinterlegten verifi zierten digitalen Identität (2) unter Verwendung des FI- Zugangstokens (7) geprüft wird.
4. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass über den Vermittlerdienst (15) mehrere föderierte Identitätsgeber (21) erreich bar sind, wobei von dem Vermittlerdienst (15) nach Eingang einer Autorisierungsanfrage die erreichbaren föderierten Identitätsgeber (21) an einen Nutzer- Agenten (13) mit einer Endnutzer-Schnittstelle (14) geschickt und über diesen dem Endnutzer (10) zur Auswahl an- geboten werden (114).
5. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das zweite Datum (7) erzeugt wird, wenn sich der Endnutzer (10) erfolgreich ge gen den föderativen Identitätsgeber (21) authentisiert hat (300).
6. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass nach er folgreicher Prüfung des zweiten Datums (7) durch den Vermittler dienst (16) die Attributnamen (4) derjenigen Attribute (9) der verifi zierten digitalen Identität (2) als ausgewählt gespeichert werden (404), die für eine Übermittlung an einen abhängigen Dienst (11) freigege ben sind.
7. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das erste und das zweite Datum (5, 6, 7, 8) gebildet werden, indem eine Daten struktur mit einer nachprüfbaren Signatur versehen und mit einer be grenzten Lebensdauer versehen wird.
8. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass von einem abhängigen Dienst (11) eine Token- Anfrage an den Vermittlerdienst (15) geschickt wird und daraufhin das erste Datum (5) erzeugt wird (410).
9. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Token- Anfrage einen Sitzungscode (CSM) enthält, der vom Vermittlerdienst (15) nach Auswahl und Hinterlegung der für eine Übermittlung an den abhängigen Dienst freigegebenen Attribute der verifizierten digi talen Identität erzeugt wird (406).
10. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Über mittlung der Attribute (9) durch einen von dem abhängigen Dienst (11) erhaltenen Aufruf ausgelöst wird (600), der das erste Datum (5) enthält.
11. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass für die Auswahl der für eine Übermittlung an den abhängigen Dienst (11) freigegebenen Attribute der verifizierten digitalen Identität (2) die At tributnamen (4) der auswählbaren Attribut (9) an einen Nutzer- Agen ten (13) mit einer Nutzerschnittstelle (14) geschickt und über diese ei nem Endnutzer (10) zur Auswahl angeboten werden (316).
12. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Ver mittlerdienst (15) das erste Datum (5) und das zweite Datum (7) ei nander zuordnet und die Zuordnung hinterlegt wird (412).
13. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass zwischen dem abhängigen Dienst (11) und dem föderativen Identitätsgeber (21) unter Einschaltung einer System -Zertifizierungsin stanz (18) ein Schlüssel (KSY) ausgehandelt wird (510, 516), mittels dessen die Attri but-Werte verschlüsselt werden, wobei im Rahmen der Aushandlung das zweite Datum (7) vom Vermittlerdienst (15) geprüft wird.
14. Vermittler dienst zur Anordnung zwischen einem föderierten Identi tätsgeber (21) und einem abhängigen Dienst (1) zur Bereitstellung von Attributen (9) einer verifizierten digitalen Identität (2) für einen ab hängigen Dienst (11), welcher dazu eingerichtet ist
- ein erstes Datum (5) für eine Berechtigungsprüfung zu erzeugen, um die Berechtigung eines Datenaustausche zwischen dem Ver mittlerdienst (15) und einem abhängigen Dienst (11) zu überprü fen, und
- von einem föderierten Identitätsgeber (21) ein zweites Datum (7) anzufordern, um damit die Berechtigung für einen Datenaus tausch mit dem Identitätsgeber (21) nachzuweisen.
15. Föderierter Identitätsgeber zur Bereitstellung von Attributen (9) einer verifizierten digitalen Identität (2) zur Anordnung in einem System mit einem Vermittlerdienst (15), der mit einem abhängigen Dienst (11) verbunden ist, welcher dazu eingerichtet ist ein zweites Datum (7) für eine Berechtigungsprüfung zu erzeugen und damit die Berechtigung eines Datenaustauschs zwischen dem Vermittler dienst (15) und dem Identitätsgeber (21) zu überprüfen.
EP20725773.4A 2019-05-09 2020-05-08 Verfahren zur authentisierung eines endnutzers gegenüber einem abhängigen dienst Pending EP3967009A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102019003280.2A DE102019003280A1 (de) 2019-05-09 2019-05-09 Verfahren zur Authentisierung eines Endnutzers gegenüber einem abhängigen Dienst
PCT/EP2020/025215 WO2020224809A1 (de) 2019-05-09 2020-05-08 Verfahren zur authentisierung eines endnutzers gegenüber einem abhängigen dienst

Publications (1)

Publication Number Publication Date
EP3967009A1 true EP3967009A1 (de) 2022-03-16

Family

ID=70736779

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20725773.4A Pending EP3967009A1 (de) 2019-05-09 2020-05-08 Verfahren zur authentisierung eines endnutzers gegenüber einem abhängigen dienst

Country Status (3)

Country Link
EP (1) EP3967009A1 (de)
DE (1) DE102019003280A1 (de)
WO (1) WO2020224809A1 (de)

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8893230B2 (en) * 2013-02-22 2014-11-18 Duo Security, Inc. System and method for proxying federated authentication protocols
US9654473B2 (en) * 2013-06-28 2017-05-16 Bmc Software, Inc. Authentication proxy agent
WO2016010373A1 (ko) 2014-07-15 2016-01-21 씨제이씨지브이 주식회사 곡률을 갖는 스크린이 설치된 상영관 및 그 의자 제어 시스템
DE102015008881A1 (de) 2015-07-09 2017-01-12 Daimler Ag Integration von Starterstromsteuerung und Bordnetztrennschalter
US20170289134A1 (en) * 2016-03-30 2017-10-05 Ping Identity Corporation Methods and apparatus for assessing authentication risk and implementing single sign on (sso) using a distributed consensus database

Also Published As

Publication number Publication date
DE102019003280A1 (de) 2020-11-12
WO2020224809A1 (de) 2020-11-12

Similar Documents

Publication Publication Date Title
DE60214632T2 (de) Multidomäne Berechtigung und Authentifizierung
DE60221880T2 (de) System und verfahren zur erzeugung eines gesicherten netzes unter verwendung von beglaubigungen von verfahrensgruppen
DE602004012996T2 (de) Verfahren und vorrichtung zum authentifizieren von benutzern und websites
DE69838769T2 (de) System und Verfahren zum anonymen, personalisierten Browsen in einem Netzwerk
DE102014119363A1 (de) Autorisierungsverwaltungsserver und autorisierungsverwaltungsverfahren
DE102010030590A1 (de) Verfahren zur Erzeugung eines Zertifikats
DE102009027681A1 (de) Verfahren und Lesen von Attributen aus einem ID-Token
WO2009089943A1 (de) Verfahren zum lesen von attributen aus einem id-token
WO2010006822A1 (de) Verfahren zum lesen von attributen aus einem id-token
DE102014206325A1 (de) Verteiltes Authentifizierungssystem
EP2415228A2 (de) Verfahren zum lesen von attributen aus einem id-token über eine mobilfunkverbindung
DE10221665A1 (de) Gesichertes wechselseitiges Legalisierungssystem
DE602005003631T2 (de) Ausschluss der Passwortaufdeckung bei Attributzertifikatausgabe
DE602004012059T2 (de) Techniken zum dynamischen Aufbauen und Handhaben von Authentisierung und Vertrauensverhältnissen
EP3295354A1 (de) Verfahren und vorrichtung zur authentifizierung eines dienstnutzers für eine zu erbringende dienstleistung
EP4092958B1 (de) Ausstellen eines digitalen verifizierbaren credentials
EP4315117A1 (de) Verfahren und vorrichtung zum erzeugen, bereitstellen und weitergeben eines vertrauenswürdigen elektronischen datensatzes oder zertifikates basierend auf einem einen nutzer betreffenden elektronischen dokument
EP2932446A1 (de) Reputationssystem und verfahren
EP2454702A1 (de) Verfahren zur hsm migration
EP3540623B1 (de) Verfahren zur erzeugung eines pseudonyms mit hilfe eines id-tokens
DE202013007090U1 (de) Serverbasiertes Bezahlsystem
EP4254234A1 (de) Ausstellen eines digitalen credentials für eine entität
WO2020224809A1 (de) Verfahren zur authentisierung eines endnutzers gegenüber einem abhängigen dienst
WO2015135744A1 (de) Id-provider-computersystem, id-token und verfahren zur bestätigung einer digitalen identität
EP3937451B1 (de) Verfahren zu herstellung einer verschlüsselten verbindung

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20211209

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: GIESECKE+DEVRIENT MOBILE SECURITY GMBH

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230519

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: GIESECKE+DEVRIENT EPAYMENTS GMBH

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: GIESECKE+DEVRIENT MOBILE SECURITY GERMANY GMBH

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS