ES2411579B1 - SYSTEM AND PROCEDURE FOR USER CREDENTIALS CONTROL FOR ACCESS TO THIRD PARTY SERVICES IN MOBILE NETWORKS - Google Patents

Abstract

System and procedure for the control of user credentials for access to third-party services in mobile networks. # System and procedure to control credentials provided by a user, in a mobile network with a third-party server (2) and an application of client side (1) requesting access to the third party server (2) on behalf of the user, comprising: # - a credential administrator (21) to retrieve an unambiguous identity of the user and allow the identified user to provide authentic credentials for its use by third-party server protected services (2) and false credentials for use by the client-side application (1), # - a credential storage repository (23) in which the credential manager (21 ) stores both authentic and false credentials in association with the user's identity, # - a credential replacement (22) to detect authentication messages n in the communication between the application client side (1) and the third party server (2) and replace false credentials authentication messages detected by the authentic credentials associated repository credential storage (23).

Description

TECHNICAL FIELD OF THE INVENTION

The present invention relates to the secure handling and administration of private and confidential information (ie credentials) used by end users for access to a third party or third party service (in English, "third party services"), for example, Web 2.0 service, and more particularly, refers to a system and procedure for controlling user credentials from the mobile network side.

BACKGROUND OF THE INVENTION

The rise of web services implies an increase in private and confidential information deposited by individuals and companies in Internet service providers (ISPs). For example, web 2.0 services, associated with web applications that facilitate interactive systemic trends, interoperability, user-oriented design and development of the World Wide Web, use certain user information to uniquely identify a single individual or customer. Examples of web 2.0 selVices include social networking sites, such as Facebook, Twitter, Tuenti, Orkut, etc.

In the current landscape of mobile applications, there is a full spectrum of mobile applications (client side) that make use of third-party services (usual but not necessarily web 2.0 services), either as the primary functionality of the application or As a secondary functionality. Therefore, for example, there are several instant messaging applications that allow connections to Google Talk servers, and there are quite a few applications that allow the user to publish something on Facebook Twitter, directly from the application.

Since credentials are requested from the end user to enable access to the third-party service, and therefore the user must make an implicit statement of trust regarding the developer of the client-side application when providing this application with the user's credentials , this situation presents a possible security problem. In fact, the user entrusts his credentials to the developer of the application for the service of third parties. Even worse, in some cases, such as the one mentioned above from Google Talk, the same credential can be used to access more services from the same provider (for example, the credential

Google gives access to all Goog / e applications). This means that a dishonest developer can easily collect hundreds or thousands of user credentials for third-party services. Therefore, in the current scenario, end users lose effective control of their credentials each time they provide them.

5 In order to alleviate this problem, existing solutions establish a mechanism by which the user does not provide credentials directly to the application; instead, a three-way delegated authentication mechanism is implemented, as shown in Figure 1. When the end user from a client-side application (1) requests access (10) to a third-party server (2) ) to

10 through a web browser (3), which can be integrated or independent, the web browser (3) connects to a specific page in response to an access request (11) provided by the third-party server (2) . This page requires the credentials (12) to the user through the web browser (3). The user provides them to said web browser (3), which in turn sends the credentials (13) to the third party server

15 parts (2). After checking the validity of the user's credentials, the third party server (3) then generates an access token (14) that is transmitted (15) by the web browser (3) to the client side application (1) . Then the access token is used to access (16) the third party server (2) by the client side application

(1) as the user, without said application having access to the user's credentials.

20 Therefore, the mechanism just described, such as the one implemented by the OAuth community, attempts to allow a mobile application to gain access to a third-party service without having real access to the user's credential. As defined by the Internet Engineering Working Group (IETF) in the Request for Comments, RFC 5849 (April 2010), OAuth allows the user to grant access to

25 private user resources in one site (called the service provider), to another site (called consumer, not to be confused with the user). OAuth refers to giving access to a user's personal information or content without sharing the user's identity at all (or their secret parts, that is, credentials). OAuth is supported by several of the great actors of web 2.0, such as Google, Facebook or Twitter.

30 OAuth provides a procedure for clients to access server resources on behalf of a resource owner (such as a different client or an end user) and also provides a process for end users to authorize third-party access to their server resources without sharing your credentials (typically, a couple of username and password), using user agent redirects.

35 OAuth is the standardization and combined wisdom of many industry protocols well

established: similar to other protocols currently in use (Google AuthSub, BOJ OpenAuth, Yahoo BBAuth, Upcoming api, Flickr api, Amazon Web Services api, etc.). Each protocol provides a proprietary procedure to exchange user credentials for a token or access ticket.

S In the present context, the following terminology is used (RFC 5849): Protected resource: A restricted access resource that can be obtained from the third-party server of the service provider. Resource owner: An entity that can access and control protected resources using credentials to authenticate with the third-party server.

10 Credentials: OAuth defines credentials as a pair of a unique identifier and a shared shared secret. OAuth specifies three types of credentials: client, temporary and witness, used to identify and authenticate the client making the request, the authorization request and the granting of access, respectively.

Witness: A unique identifier issued by the server and used by the client to

15 Associate authenticated requests with the resource owner whose authorization is requested or obtained by the client. Witnesses have a matching shared secret that is used by the client to establish their ownership of the witness, and their authority to represent the resource owner. Normally, OAuth 2.0 credentials consist of the following elements:

20 • Customer ID - Identifies the application uniquely.

•

Client secret -Used as part of the witness request by a client.

•

Redirect URI - A list of valid redirect URIs (uniform resource identifiers) allowed in an authorization request. The first time an application requests an authorization token, a request is sent that includes

25 a redirect URI. The redirect URI indicates where Google should redirect the browser after the user allows (or denies) the authorization request. Web-based applications provide the URI of a management page to call after the authorization request is completed; installed applications use a conventional URI string. If a request

30 web-based does not include a URI listed here, the user will get an authorization error.

• Brand information - This is information about the resource owner (an individual or a company) that is displayed when your application first requests an OAuth authorization.

35 Existing mechanisms, such as the implementation of OAuth, shown in Figure 1, present three main problems:

1) Support: It must be implemented and supported by the third party server. In addition, it must be supported on all server services. Although some of the greatest actors (Google, Facebook, Twitter)

5 support an authorization mechanism as described above, not all web 2.0 services support it. Moreover, some of Google's services do not support a delegated authentication mechanism (for example, Google Talk does not support it).

2) Verifiability by the user: It is practically impossible for the user,

10 even for an advanced user, verify if an integrated browser (or operating system browser) is actually being used to provide credentials to the web browser (3), in Figure 1, or if the user is actually providing them directly to the application, which will then implement the full authentication mechanism.

15 In addition, OAuth schemes implicitly rely on the browser, since credentials must be provided through it for the first access.

3) Verifiability by the third party server: Even worse, it is also impossible for the third party server to distinguish between an application

20 legit that implements the protocol correctly (that is, the legit application does not have access to the credentials) and a fraudulent application that directly implements the entire user interface and has access to the credentials. The objective technical problem is to allow end users to keep the

25 security and control in the use of their credentials to access third-party services, in any case independently of the third-party server and even if the client application that requests access in the name of the user to the third-party server is malicious.

SUMMARY OF THE INVENTION The present invention serves to solve the aforementioned problem by providing a system and method that resides on the mobile network side to allow the use of authenticated third-party services by any client-side (mobile) application. ) and maintain full credential security

35 of the user. In fact, this system and procedure prevent users from providing

their credentials directly to the applications, since the invention allows the mobile network to be the only one in charge of transparently introducing the credentials when needed by the service of third parties, based on the identity of a user (obtained from the mobile network subscriber identity) and credentials 5 previously provided to the mobile network provider. Therefore, end users never have to enter their credentials in their mobile terminals, in case they choose not to. The invention guarantees the security of the user's credentials even if the mobile application is malicious in nature since the application never accesses the user's credentials since they are directly entered into the flow of

10 communication outside the potentially compromised application or even the user's terminal.

According to one aspect of the invention, a system for controlling user credentials provided by a user is provided in a mobile network with a communication established between a third-party server and an application on the side of

15 client requesting access to the third party server on behalf of the user, which includes:

-

a credential administrator who understands means to retrieve a

user identity defined unequivocally (that is, it is unique and identifies the

user unequivocally) in the mobile network and means of access through which the

20 user provides authentic credentials for use in a third-party service protected from the third-party server and false credentials for use by the client-side application,

-

a repository or credential storage database in which the credential administrator stores both authentic credentials and false credentials in association with the identity of the retrieved (unique) user,

-

a credential replacement comprising data detection means for detecting authentication messages in the communication established between the client-side application and the third-party server, and replacement means for replacing false credentials in the detected authentication messages, what are they for

30 third-party service protected by the associated authentic credentials obtained from the credential storage repository. According to another aspect of the invention, a method is provided for controlling user credentials in a communication established between a third-party server and a client-side application requesting access on behalf of the user to

35 any protected service of the third party server, including the

Procedure the following stages:

-Retrieve a user identity defined unequivocally on the network

mobile (for example, MSISDN, IMS1). This user identity is retrieved by a

credential manager that allows access to the identified user.

S

-Then, the user accesses and provides (for example, through a web portal),

to the credential administrator, authentic credentials for use in the services of

Protected third parties and false credentials for client side application.

-Store both authentic and false credentials in association with the

user identity in a database or storage repository of

10

credentials used by the credential manager.

-Detect authentication messages in the communication established between the

Client-side application and third-party server and replace credentials

false authentication messages detected for third party service

Protected by authentic credentials. This is done by a replacement of

fifteen

credentials that obtain authentic credentials, associated with credentials

false and the identity of the user, of the credential storage repository.

DESCRIPTION OF THE DRAWINGS

To complete the description that is being made and in order to help a

twenty

better understanding of the features of the invention, according to a preferred example of

practical realization of it, accompanying said description as a part

member thereof, a set of drawings is provided in which, by way of

illustration and in a non-restrictive manner, the following has been represented:

25

Figure 1. Shows a flow chart of an authentication procedure in

an Internet service provider system based on the use of credentials and

witnesses delegated to a web browser, as is known in the prior art.

Figure 2. - Shows a flow chart of a system for communication

30

between an end user and a third party service with control of the credentials of the

user in the mobile network, according to a possible embodiment of the invention.

FINISHED DESCRIPTION OF THE INVENTION

As shown in Figure 2, a preferred embodiment of the invention is

35

refers to a system (20) for the control of user credentials in a mobile network, in the

that a communication is established between a client-side application (1), which normally runs on a mobile terminal of an end user, and a third-party server (2) in order to access restricted or protected access resources from the third party server (2).

The client-side application (1) can be any existing application in the market that access authenticated third-party services, hosted on the third-party server (2).

The third party server (2) is a system managed by an Internet service provider that provides one or more restricted, authenticated or protected access services, that is, the third party server (2) requires a user to authenticate using credentials before allowing the use of the services. Additionally, the third party server (2) can provide access to unauthenticated services, for which no credentials are requested from users and therefore no credential management is required.

In addition and optionally, an encryption interceptor (30) may be in the middle of the established communication of the client side application (1), with the third party server (2), in order to intercept encrypted communications, from a a way that allows communications to also continue without being intercepted after a certain point. For example, current authentication schemes use an encrypted channel to protect the credential confidentiality in transit. This element is an external part (not part of the invention, but part of its use case).

The system architecture (20) for credential control in the mobile network comprises the following functional blocks:

A credential replacement (22) that analyzes all traffic flows between the client-side application (1) and the third-party server (2) in communication and performs two actions on the analyzed traffic: authentication message detection and replacement of credentials in authentication messages.

A credential administrator (21) that allows end users to provide their real, authentic credentials directly to the system (20), instead of to the third party server (2) or to the client side application (1). End users also provide a fake or fictitious credential in order to be used by the third party server (2) or the client side application (1), but the authentic user credentials are entered by the end user correctly through credential manager (21) in a credential storage repository

(23) And they are not provided directly to external elements such as the server

third parties (2) and the client side application (1). The credential replacement

(22) is responsible for replacing dummy credentials with authentic user credentials in the authentication messages detected.

A credential storage repository (23) is a database in which authentic and false credentials are stored, provided by end users using the credential manager (21).

The overall system operation procedure (20) for the control of user credentials is as follows:

Before using any client-side application (1) to access any of the protected third-party services provided by the third-party server (2), the user accesses the system (20) through a web portal provided by the credential manager (21), which automatically identifies the user based on a unique subscriber identity defined in the mobile network, for example, MSISDN or IMSI, and asks the user to enter the real credentials through the web portal, which The user wants the system (20) to protect when access to the services of protected third parties is requested. As part of the credential definition, the user also provides dummy or fake credentials for use by the system (20) later, when the user wants these credentials replaced. All credentials, real and false, are stored by the credential manager (21) in the credential storage repository (23).

At a later time, the user requires or provides access to a third-party service through a client-side application (1) installed in his mobile terminal. The client-side application (1) asks the user to provide credentials, directly or through a delegated authentication procedure such as Oauth, and the user simply provides only the dummy credentials previously previously in the credential storage repository (23) .

When the client-side application (1) attempts to access, or provides access, to the third-party service, the client-side application (1) connects to the third-party server (2) and sends a first authentication message ( To 1).

Optionally, if the data flow and therefore the authentication message (A 1) is encrypted, an encryption interceptor (30) decrypts each message, data packet, and passes it to the credential replacement (22).

The credential replacement (22) detects if the message, decrypted, (A2) contains an authentication message, that is, checks if the following conditions are true:

the message (A2) comprises an authentication message,

The destination of the authentication message is a server / service

protected,

the user (automatically identified by the mobile network, by

example, using the MSISON) you have defined credentials for that

protected service,

the authentication message includes the dummy credentials

user-defined for that protected service

Then, the credential replacement (22) replaces the dummy credentials with the real credentials, the latter taken from the credential storage repository (23), in the authentication message; otherwise, if the message (A2) does not include authentication data, the data is left intact. The credential replacement (22) returns a modified message (81), or the original, if the message remains intact without authentication data.

In case the message (A2) comes from an encryption interceptor (30), the credential replacement (22) sends the modified message (81) to the encryption interceptor (30). The credential replacement (22) may further indicate to the third party server (2) that this communication flow should no longer be monitored.

The encryption interceptor (30) encrypts the modified message (B1) received from the credential replacement (22) and transmits a modified, encrypted, in this case, final (B2) message to the third party server (2). If the communication flow is marked / indicated as not to be monitored further, the encryption interceptor element (30) interrupts the decryption of the communication flow and therefore also stops the passage of more messages to the credential replacement (22).

Note that in this text, the term "comprises" and its derivations (such as "comprising", etc.) should not be understood in an exclusive sense, that is, these terms should not be construed as excluding the possibility that what described and defined may include elements, stages, etc. additional.

Claims (6)

1. A system (20) for controlling user credentials provided by a user, in a mobile network with a communication established between a third-party server (2) and a client-side application (1) requesting access to the server third parties (2) on behalf of the user, characterized in that it comprises: -a credential administrator (21) comprising means to retrieve an identity of the user defined unequivocally in the mobile network and means of access through which the user provides authentic credentials for use in a third-party service protected from the third-party server (2) and false credentials for use by the client-side application (1), -a credential storage repository (23) which is a database in which the credential manager (21) stores both credentials authentic as false credentials in association with the user's recovered identity, - a credential replacement (22) comprising data detection means for detecting authentication messages containing false credentials in the communication established between the client side application ( 1) And the third party server (2), and replacement means to replace, in the authentication messages detected for the protected third party service, the false credentials by the authentic credentials stored in association with the credential storage repository (2. 3).

2.

The system (20) according to claim 1, wherein the access means of the credential administrator (21) consists of a web portal.

3.

The system (20) according to any preceding claim, wherein the identity of the user retrieved by the credential administrator (21) is the MSISDN.

Four.

The system (20) according to any preceding claim, wherein the credential replacement data detection means (22) detect authentication messages when the following conditions are met: there is an authentication message indication in the data, the data is intended for a protected third party service, there are authentic credentials stored in the credential storage repository (23) provided by the user for the protected third party service, the data includes false credentials provided by the user and also

stored in the credential storage repository (23) for the protected third party service.

5.

A procedure for controlling user credentials provided by a user, in a mobile network with a communication established between a third-party server (2) and a client-side application (1) that requests access to the third-party server (2) on behalf of the user, characterized in that it comprises: -recovering through a credential administrator (2 1) an identity of the user defined unequivocally in the mobile network, -accessing through the user identified to the credential administrator (21), -provide by the identified user, to the credential administrator (21), authentic credentials for use in a third-party service protected from the third-party server (2) and false credentials for use by the client-side application (1), - store in a credential storage repository (23) used by the credential administrator (21) both authentic credentials and credentials false in association with the identity of the user retrieved by the credential administrator (21), -detect authentication messages containing false credentials in the communication established between the client-side application (1) and the third-party server (2) , checking if the following conditions are met: there is an authentication message indication in the data, the data is intended for a protected third party service, there are authentic credentials stored in the credential storage repository (23) provided by the user For the protected third-party service, the data includes false credentials provided by the user and also stored in the credential storage repository (23) for the protected third-party service; - replace the credentials (22) with false credentials, in the authentication messages detected for the protected third party service, with the authentic credentials that the credential replacement (22) obtains from the credential storage repository (23) and stored in association with such false credentials.

6.

The method according to claim 5, wherein the access by the user to the credential administrator (21) is through a web portal.

7_ The method according to any of claims 5-6, wherein the identity of the user retrieved by the credential administrator (21) is the MSISDN