WO2020207517A1

WO2020207517A1 - Method of authenticating a user to a relying party in federated electronic identity systems

Info

Publication number: WO2020207517A1
Application number: PCT/CZ2020/050021
Authority: WO
Inventors: Libor Neumann
Original assignee: Aducid S.R.O.
Priority date: 2019-04-08
Filing date: 2020-04-07
Publication date: 2020-10-15
Also published as: CZ308358B6; CZ2019221A3

Abstract

The invention provides a method of authenticating a user to a relying party (4) through an identity provider (2) in federated identity system, in which a data channel (7) is first established between the user device (1) and the relying party (4), the user is subsequently authenticated with the identity provider (2), and the assertion (5,6) is transmitted from the identity provider (2) to the relying party (4), wherein the authentication with the identity provider (2) includes binding of the data channel (7), which is established between the user device (1) and the relying party (4), with the authentication of the user at the identity provider (2), and wherein the assertion (5,6) with the said bond to the said data channel (7) is transmitted from the identity provider (2) to the relying party (4) through a communication module (10); wherein the said communication module (10), optionally together with the identity provider (2), controls the authentication with the bond to the data channel (7).

Description

Method of authenticating a user to a relying party in federated electronic identity systems

Field of Art

The presented invention relates to a method of authenticating a user to a relying party in an environment of federated identity systems.

Background Art

Currently, federated electronic identity (or federated identity) systems are used in which a user authentication is performed by an Identity provider using an authentication means (such as softwares, applications, names, passwords).

The authentication result is used by the Relying Party to control the user's access to the target assets (services, data), while relying on the identity provided by the identity provider and on the user data provided by the identity provider.

Currently, federated identity systems based on principles such as "Bearer token based authentication", "Bearer authentication" or alternatively "Bearer Assertion" are used. The principle is that the user or his device used to access the services, respectively, proves his identity to the relying party by means of an assertion that does not allow the relying party to verify that the user is real subject of the assertion, i.e. the relying party must assume that the user is the authenticated person for whom the assertion is valid but the relying party cannot verify this assumption in any way (NIST Special Publication 800-63-2 Electronic Authentication Guideline p.7).

Redirection of the communication through the user's web browser is used to transmit the assertion between the identity provider system where the authentication was performed and the relying party system where the assertion is used. Redirecting can take place automatically, without the need for any action on the part of the user.

The assertion is transmitted using various standards such as SAML (OASIS: Security assertion Markup Language (SAML) V2.0 Technical Overview - http://docs. oasis- open. org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html), oAuth (IETF: RFC 6749 - The OAuth 2.0 Authorization Framework - https://tools.ietf.org/html/rfc6749), WS-federation (OASIS: Web Services Federation Language (WS -Federation) Version 1.2 - http://docs.oasis- open.org/wsfed/federation/vL2/ws-federation.html). The redirection functionality is standardized by international RFC standards (IETF: RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content - https://tools.ietf.org/html/rfc7231;

Other systems are used in the federated identity systems to transmit the result of the authentication (the Assertion). They are referred to alternatively as an Identity broker or an Identity node. Their goal is to allow the use of multiple identity providers for the relying party, thereby expanding the number of users. In this case, the user selects his identity provider or another identity broker in the identity broker system; and after performing the authentication, the assertion is always transmitted via the redirect functionality via the user's web browser back through the intermediary identity broker to the relying party system.

Each time an assertion is transmitted between two systems of different identity providers, identity brokers and relying parties, the user's redirect functionality is used for the transmission, and the assertion is thus transmitted at least twice over the Internet, over two - usually unauthenticated or insufficiently authenticated - data channels.

Thus, in federated identity systems, a method of authenticating a user to a relying party through an identity provider proceeds by: first creating a data channel between the user and the relying party, then authenticating the user to the identity provider, and passing the assertion from the identity provider to the relying party, optionally via further identity provider(s) or identity broker(s), whereby the assertion is passed from each identity provider or identity broker to another identity provider or identity broker, and further to the relying party always through the redirection functionality in the web browser or other user application. Furthermore, in current systems, the relying party has no possibility to verify that the user whose device submits the assertion is indeed the person to whom the assertion relates. The prior art processes are shown schematically in Fig. 1.

Existing authentication procedures in the environment of federated (electronic) identity systems have considerable disadvantages in practical application. First, they require the redirection functionality even when the user is not using a web browser. This is typical for mobile applications. This increases the costs and complicates the use of existing federated identity systems for mobile applications, because it is necessary to integrate the redirection functionality into applications, and to sufficiently secure the redirection functionality because the information needed to perform authentication and transmit the assertion is passed via this application. Furthermore, these procedures allow an attacker to intercept an assertion on any transmission via Internet between a user and one of the federated identity system components, and thus the attacker can impersonate the user and gain access to their services and data in the target applications.

The present invention aims to improve the current methods of authenticating a user to a service provider (relying party) through an identity provider in federated (electronic) identity systems so as to maintain the use of existing standards for assertions and their transmission, while significantly enhancing practicality, security and decreasing the risk of abuse of an intercepted assertion by an attacker.

Disclosure of the Invention

An object of the present invention is a method of authenticating a user to a relying party through an identity provider, in which a data channel is first established between the user device and the relying party, the user is subsequently authenticated with the identity provider, and the assertion is transmitted from the identity provider to the relying party, wherein the authentication with the identity provider includes binding of the data channel between the user device and the relying party with the authentication of the user at the identity provider, and wherein the assertion with the said bond to the said data channel is transmitted from the identity provider to the relying party through a communication module; wherein the said communication module, optionally together with the identity provider, controls the authentication with the bond to the data channel.

A„user“ is a user of services or data of the relying party who wishes to access such services or data. The user has a user device. The user device has access to a relying party application through which the user can initiate a login process which subseqently includes authentication. Furthermore, the user has authentication means.

The user's authentication means can be, for example, a smart phone, a computer, a tablet, a smart watch with an authentication application, a token, a smart card, or a PEIG.

A„relying party" (RP) is a server and/or a system of an entity which provides the services or data that the user wishes to access. An„identity provider" (IdP) is a server and/or a system of an entity which provides electronic identities and provides services for these electronic identities, i.e. authentication services.

An„identity broker" (node of an electronic identity system) is a server and/or a system through which an identity provider can be selected and through which the assertion can be transmitted between the identity provider and the relying party. This transmission of the assertion between the identity provider and the relying party is performed in the present invention by means of the communication module.

A„service provider" is a collective term including a relying party, an identity provider, and an identity provider.

An„assertion“ is an output data issued by an identity provider. The assertion proves that the user was authenticated by specified means at a specified time. The assertion is the result of the verification of identity performed by the identity provider. The identity provider transmits the assertion to the relying party. Based on the assertion, the relying party provides access to the services or data to the authorized user. The identity provider must have authentication means enabling the binding of the data channel with the authentication. Such means are known in the art (e.g., standards RFC 8472, RFC 6677, RFC 5056, relate to protocols for channel binding).

A communication module" is a server and/or a system which controls and manages the authentication and its binding with the data channel between the user device (user) and the relying party, and transmits the assertion between the identity provider and the relying party.

The communication module communicates with at least one relying party, at least one identity provider, and optionally one or more identity broker. On the side of the relying party, the communication module can communicate either directly with the target application of the relying party or can communicate with a reverse proxy server.

Thus, the communication module ensures the transmission of information necessary to control authentication between the relying party and the identity provider, including binding the data channel established between the relying party and the user device to the user authentication. It also ensures the creation of assertion request data according to the relevant standards, and the transmission of the generated assertion between all necessary service providers in the federated identity system according to the relevant standards. The communication module further provides for binding the assertion to the authentication and to the data channel between the relying party and the user device, and processing the content of the assertion and transmittal of the assertion including the user data to the target application of the relying party, optionally via a reverse proxy server.

The communication module may be operated by a relying party or other entity, for example, a separate operator of the communication module operation services for several relying parties.

Preferably, the communication module is configured to allow the user to select an identity provider and to allow the relying party to communicate with multiple identity providers.

Methods for binding a data channel with user authentication are known in the art. Authentication is usually part of the communication protocol of the data channel (e.g. using the client certificate for TLS authentication), authentication data can be transmitted directly between the relevant parts of the application (e.g. filling in a login form in a web browser on the target application webpage with username and password) or by a combination of transmission via another channel and transmission via an authenticated data channel (e.g. transcription of the code sent to the user via SMS). It may also be the transmission of data identifying the data channel from the user end of the data channel to the user authentication device (i.e., the device or application involved in the authentication on the user side) when external authentication is used. This data is then transmitted or processed as part of authentication.

Preferably, binding of a data channel with user authentication can be performed by assigning a unique identifier to the data channel between the user device and the relying party prior to the authentication, and using the said identifier as information transmitted by the above described methods. For example, the relying party or the identity provider can assign a data channel identifier.

For example, the data channel identifier may be a data channel session identifier or an authentication identifier. It is possible to additionally use an unauthorized data channel secret (or a cryptographic material derived from the data channel cryptographic material, e.g., from an unverified shared secret of both ends of the data channel, the creation of which is described, for example, in CZ PV 2013-373), in combination with the data channel identifier, to increase securinty and to avoid attacks on the channel.

The method of the present invention brings the following advantages: - Assertions are not transmitted via the user's web browser and therefore are not transmitted over the Internet via unprotected data channels, but they are transmitted directly between servers through the introduction of a communication module to the federated electronic identity system where they can be protected by standard security measures established between service providers.

- There is no need for redirection functionality on the part of the user because the assertion is transmitted via a communication module instead of through a web browser or user application. Therefore, the invention can be easily integrated into mobile applications without the need to introduce a new redirect feature.

- The use of existing assertion transmission standards is maintained.

- The data channel between the user and the relying party is bound to the assertion. The binding can also be cryptographic, thus eliminating even a sophisticated attack on the data channel between the user and the relying party.

- Shorter total time is taken.

- Less active involvement of the user is needed.

- The process uses fewer service environments with which the user needs to communicate.

In some embodiments of the invention, the target application of the relying party (i.e., the application providing the service or data requested by the user and to which the user authenticates) may preferably be located behind a reverse proxy server. Such location behind a reverse proxy server is sometimes used for web applications or server parts of mobile applications. In this case, the data channel between the user's device and the target application is terminated on the reverse proxy server. The reverse proxy server controls the user access to the appropriate resources of the target application (e.g., the respective website) and ensures the transmission of user data to the appropriate internal variables (eg, Remote_user).

In this case, the communication module can communicate directly with the reverse proxy server. In this case, both the data channel and the user will be authenticated invisibly from the viewpoint of the application creator. The programmer does not have to program the authentication, he can rely on the fact that only an authenticated user can use the relevant part of the application and that the application can read the user data directly from internal variables. Authentication and placement of user data in internal variables is ensured by the reverse proxy server with the assistance of the communication module according to the system configuration.

In more complex topologies of federated (electronic) identity systems, multiple identity providers are often involved. In such a case, the user typically selects an identity provider who can verify his/her identity, e.g., who has issued his or her authentication means (e.g., an electronic identity card in a particular state or an authentication token or a smart card).

In such systems, the communication module may preferably allow the user to select an identity provider using existing standards and utilizing the identity broker functionality known in the art.

One possible option to select an identity provider is that the user is redirected to a communication module, which at that moment functions as a standard http proxy server or http client, before authentication begins. Thus, the user can transparently use an identity broker functionality to select an identity provider. When the user completes the selection, the functionality of the http proxy server or http client on the communication module is terminated. The result of the selection, transmitted from the identity broker server to the communication module, is processed by the communication module, for example, using an algorithm, conversion table, etc., to create data needed to control the identity provider selection in the next step.

Another possible option is that the user communicates with a dedicated part of the relying party target application on the relying party's server prior to initiating authentication. This application communicates with an identity broker directly or through a communication module. Also in this case, the result of the mediated interaction of the user with the identity broker, i.e. the identity provider selection, is processed and the data necessary to control the identity provider selection is generated in the next step.

Yet another possible option is to create a separate identity provider selection module communicating with an identity broker, which is located behind the reverse proxy server analogously to the target application.

Once the identity provider selection control data is created, the data is used to route the authentication control communication with the selected identity provider via the communication module. The data can also be used to select a communication method (communication protocol) if different identity providers use different protocols. Further, the control data for the selection of the identity provider is used to create routing information transmitted in the binding of the data channel between the relying party and the user with the user authentication. This information may preferably take the form of a standard URI.

The present invention further provides a system for authenticating a user to a relying party through an identity provider, comprising at least one user device, at least one relying party, at least one identity provider, and at least one communication module adapted to communicate with the relying party and with the identity provider and equipped with means for control of authentication with binding of the authentication with the data channel between the user device and the relying party. The system may further include one or more identity brokers.

Brief Description of Drawings

Fig. 1 schematically illustrates authentication in a prior art federated electronic identity system.

Fig. 2 schematically shows authentication in a federated electronic identity system according to the invention, with binding of authentication with a data channel between a user and a relying party, and with the inclusion of a communication module.

Fig. 3 schematically shows authentication in a federated electronic identity system according to the invention, in a preferred embodiment using a reverse proxy server at the relying party.

Fig. 4 schematically shows authentication in a federated electronic identity system according to the invention, in a preferred embodiment with the selection of an identity provider.

Reference signs: 1 - user device, 2 - identity provider, 3 - identity broker, 4 - relying party, 5 - issued assertion, 6 - delivered assertion, 7 - data channel between user and relying party, 8 - data channel for authentication, 9 - open network (internet), 10 - communication module, 11 - binding of data channel with authentication (transmission of information between the end of data channel 7 at the user side and the user authentication means which is the end of the authentication data channel 8), 12 - control of authentication by the communication module, 13 - control of authentication by the communication module and transmission of assertion to the relying party, 14 - reverse proxy server at relying party, 15 - target application at relying party, 16 - communication for identity provider selection by the user, 17 - communication for selection of an identity provider.

Examples of carrying out the Invention

Example 1

The user selects a relying party service on his device 1, wherein the relying party requires authentication of the user. The relying party 4 identifies an unauthenticated user request and requests authentication of the user from an identity provider 2 by transmitting the authentication request to a communication module 10 via authentication control 13. The communication module 10 requests the authentication from the identity provider 2 using authentication control 12.

The identity provider 2 generates an authentication identifier for binding 11 the data channel 7 with the authentication. The authentication identifier is transmitted using controls 12 and 13 via communication module 10 to the target application the relying party 4.

The application transmits to the user via the yet unauthenticated data channel 7 of the target application all information necessary for binding the data channel 7 with authentication, including the identifier obtained from the identity provider 2. The user device 1 forwards the information 11 to the user authentication means, for example, by displaying and photographing the QR code, using URI calls within the operation system of the device 1, or by other means of communication between tasks in the user device 1.

The authentication means transmits the information 11, including the identifier, by the authentication data channel 8 to the authentication system of the identity provider 2, where it is bound based on the identifier with the result of the authentication.

Meanwhile, the communication module 10, while retaining the context, requests the issuance of an assertion 5 according to the relevant standard.

The assertion 5 is transmitted as a response to a communication module 10 in accordance with the relevant standard, and the communication module 10 processes the assertion as a standard browser (http redirect). Thus, the issued assertion 5 is delivered in standard form to the identity broker 3. The identity broker 3 processes the assertion 5 in a standard manner and transmits the response as a delivered assertion 6 to the communication module 10. The communication module handles all communication related to a single authentication in a single session, so it can link the original authentication request from the relying party 4 to the authentication identifier generated by the identity provider 2 as well as to the delivered assertion 6.

The communication module processes this information and transmits to the relying party 4 the complete result of user authentication via the control 13.

Example 2

The user selects on his device 1 a service provided by a relying party that requires authentication. The relying party 4 identifies an unauthenticated user request. The relying party 4 together with the user device 1 creates a yet unauthenticated data channel 7 of the target communication and creates a cryptomaterial and a channel identifier for the data channel 7.

The relying party 4 requests authentication to be performed by the identity provider 2 by passing the authentication request together with the identifier of the data channel 7 and derivative of the cryptomaterial of the data channel 7 to the communication module 10 via authentication control 13. The communication module 10 requests authentication by the identity provider 2 using authentication control 12.

The identity provider 2 uses the channel 7 identifier and the crypromaterial derivative to authenticate the user and the data channel 7.

Meanwhile, the user device 1 generates a derivative of the cryptomaterial of the data channel 7 and processes the channel 7 identifier, thereby creating all necessary information to bind the data channel 7 to the authentication and to perform the authentication.

The authentication means processes the information 11 including the identifier and the cryptomaterial, and, by means of the authentication data channel 8, performs the authentication, including the authentication of the data channel 7, using information transmitted from the relying party 4 via the communication module 10.

The procedure is continued as in Example 1.

Example 3

The user selects on his device 1 a service of a relying party that requires authentication. The relying party 4 uses a reverse proxy server 14 on which terminates the secure data channel of the target application, e.g., TLS. The reverse proxy server 14 identifies an unauthenticated user request. The reverse proxy server 14, together with the user device 1, creates an as yet unauthenticated data channel 7 for the target communication and creates the cryptomaterial and the channel identifier (for the channel 7).

The reverse proxy server 14 requests authentication from the identity provider 2 by transmitting the authentication request together with the data channel 7 identifier and the data channel 7 cryptomaterial derivative to the communication module 10 via the authentication control 13. The communication module 10 requests authentication by the identity provider 2 using authentication control 12.

The identity provider 2 uses the channel identifier and the crypromaterial derivative to authenticate the user and the data channel 7.

Meanwhile, the user device 1 generates a derivative of the cryptomaterial of the data channel 7 and processes the channel 7 identifier, thereby creating all the necessary information 11 for binding the data channel with authentication and for performing the authentication.

The authentication means processes the information 11 including the identifier and the cryptomaterial, and by means of the authentication data channel 8 performs the authentication, including the authentication of the data channel 7, using information transmitted from the reverse proxy server 14 via the communication module 10.

Next, the procedure proceeds as in Example 1 except that the assertion 6 is transmitted to the reverse proxy server 14.

The reverse proxy server processes the assertion 6 and based on the assertion, makes the desired page of the target application available or unavailable to the user, and optionally passes the processed information from the assertion 6 to the internal variables of the target application.

Example 4

The user has a client part of a mobile application of a relying party 4 installed on his mobile device 1. The relying party 4 has a list of trusted identity providers 2.

The user launches the mobile application. The mobile application requests a current list of trusted identity providers 2 from the relying party 4 server, to display the list to the user. The user selects his identity provider 2. The result of the selection is transmitted to the server part of the mobile application, which uses the result as a parameter when requesting authentication through the communication module 10 via authentication control 13. This parameter is used by the communication module 10 to communicate with the identity provider 2 via authentication control 12.

The procedure is continued as in Example 1.

Example 5

The user has installed the client part of the relying party 4 mobile application on his mobile device 1.

The relying party 4 uses a reverse proxy server 14 as a terminal of a secure data channel of the target application, e.g., TLS, and does not have a list of trusted identity providers 2. The list of trusted 2 identity providers is provided by an identity broker 3.

The user launches the mobile application. The mobile application uses an unauthenticated data channel 7 to communicate with the reverse proxy server 14. The reverse proxy server identifies an unauthenticated user and starts the server part of an identity provider selection application. The identity provider selection application requests, using the authentication control 13, from the communication module a current list of trusted identity providers 2. The communication module 10 requests a current list of trusted identity providers 2 from the identity broker 3 using standard communication 17 for selecting an identity provider. The list is transmitted up to the client part of the mobile application, where the user selects his identity provider 2. The result of the selection is forwarded to the reverse proxy server 14, which uses it as an authentication request parameter, which is transmitted to the communication module 10 via the authentication control 13. This parameter is used by the communication module 10 to communicate with the identity provider 2 using the authentication control 12.

The procedure is continued as in Example 3.

Claims

1. A method of authenticating a user to a relying party (4) through an identity provider (2) in federated identity system, wherein a data channel (7) is first established between the user device

(1) and the relying party (4), the user is subsequently authenticated with the identity provider

(2), and assertion (5,6) is transmitted from the identity provider (2) to the relying party (4), characterized in that the authentication with the identity provider (2) includes binding of the data channel (7), which is established between the user device (1) and the relying party (4), with the authentication of the user, and in that the assertion (5,6) with the said bond to the said data channel (7) is transmitted from the identity provider (2) to the relying party (4) through a communication module (10); wherein the said communication module (10), optionally together with the identity provider (2), controls the authentication with the bond to the data channel (7).

2. The method according to claim 1, wherein the binding of the data channel (7) between the user device (1) and the relying party (4) with user authentication is performed by assigning a unique identifier to the data channel (7) prior to the authentication, and using the said identifier as information transmitted between the user end of the data channel (7) and the authentication means of the user.

3. The method according to claim 2, wherein the identifier of the data channel (7) is a data channel session identifier or an authentication session identifier.

4. The method according to claim 2 or 3, wherein a cryptographic material derived from the data channel (7) cryptographic material is used together with the data channel (7) session identifier.

5. The method according to any one of the preceding claims, wherein the communication module (10) communicates with a reverse proxy server (14), and the data channel (7) between the user device (1) and the relying party (4) is terminated at the reverse proxy server (14), and wherein the reverse proxy server (14) controls the access of the users to the resources of the target application of the relying party (4).

6. The method according to any one of the preceding claims, wherein the communication module (10) is configured for selection of identity provider (2) and for communication with multiple identity providers (2), preferably via identity broker (3).

7. The method according to claim 6, wherein the user, before the authentication begins, utilizes the communication module (10), which at that moment functions as a standard http proxy server or http client, to select an identity provider (2) from a list provided by an identity broker (3), and when the user completes the selection, the functionality of the http proxy server or http client on the communication module (10) is terminated; and wherein the result of the selection, transmitted from the identity broker (3) to the communication module (10), is processed by the communication module (10) to create data needed to control the identity provider selection.

8. The method according to claim 6, wherein for performing the selection of the identity provider (2), the user communicates with a dedicated part of the relying party (4) target application on the relying party's (4) server prior to initiating authentication, the said part of the target application communicates with an identity broker (3) directly or through a communication module (10), and the result of the mediated interaction of the user with the identity broker (3) which is the identity provider (2) selection, is processed to create data necessary to control the identity provider (2) selection.

9. The method according to claim 6, wherein for performing the selection of the identity provider (2), the user communicates with a separate module for selection of identity provider (2) communicating with an identity broker (3), and the said module is located behind a reverse proxy server (14), wherein the result of the interaction of the user with the said module which is the identity provider (2) selection, is processed to create data necessary to control the identity provider (2) selection.

10. A system for authenticating a user to a relying party (4) through an identity provider (2), comprising at least one user device (1), at least one relying party (4), at least one identity provider (2), optionally at least one identity broker (3), characterized in that the system further comprises at least one communication module (10) configured to communicate with the relying party (4) and with the identity provider (2), and optionally with the identity broker (3), and the communication module (10) is equipped with means for control of authentication with binding of the authentication with the data channel (7) between the user device and the relying party.