WO2012045908A1

WO2012045908A1 - Arrangement and method for accessing a network service

Info

Publication number: WO2012045908A1
Application number: PCT/FI2011/050380
Authority: WO
Inventors: Martti PITKÄNEN
Original assignee: Aplcomp Oy
Priority date: 2010-10-06
Filing date: 2011-04-27
Publication date: 2012-04-12

Abstract

An arrangement (106), such as a server apparatus or a plurality of at least functionally connected server and/or other apparatuses, for controlling access to a network service, such as a cloud service, utilizing multi-factor, at least two- factor, authentication, comprising a processing entity (150) and a memory entity (152) for processing and storing data, respectively, and a data transfer entity (156) for receiving and sending data, the arrangement being configured to send an e-mail notice (128) to an e-mail address associated with a predetermined user, the e-mail notice including a preferably secure link for a browser, such as an Internet browser, receive an indication of the activation of the preferably secure link (134), such as a data request like a web resource request sent via a browser, in response to which the arrangement being further configured to send first browser data, such as web page data, requesting the user of the browser to input a secret (136), and a one-time password (OTP) to a mobile device associated with the predetermined user (138b), receive user input relative to the request for secret (140), determine whether the user input matches the sent OTP (142), and if that is the case, enable the user of the browser and related terminal device, thus authenticated as the predetermined user, to access the service (144, 144a, 186, 88).Enabling preferably includes transfer of enabling data such as program and/or password data to the terminal device. A corresponding method is presented.

Description

ARRANGEMENT AND METHOD FOR ACCESSING A NETWORK SERVICE FIELD OF THE INVENTION

Generally the invention pertains to computers and related communications infrastructure. In particular, however not exclusively, the invention concerns logging in to a service provided by a remote computer system and associated authentication.

BACKGROUND

Access control in conjunction with network services may imply user identification, which can be generally based on a variety of different approaches. For example, three categories may be considered including anonymous, standard and strong identification. Regarding anonymous case, the service users do not have to be and are not identified. Standard, or 'normal', identification may refer to what the requestor for access knows, such as a password, or bears such as a physical security token. Such a token may include password-generating device (e.g. SecurlD™), a list of one-time passwords, a smart card and a reader, or a one-time password transmitted to a mobile terminal. Further, strong identification may be based on a biometric property, particularly a biometrically measurable property, of a user, such as a fingerprint or retina, or a security token the transfer of which between persons is difficult, such as a mobile terminal including a PKI (Public Key Infrastructure) certificate requiring entering a ΡΓΝ (Personal Identification Number) code upon each instance of use.

On the other hand, network service -related authentication, i.e. reliable identification, may also be implemented on several levels, e.g. on four levels, potentially including unnecessary, weak, strongish, and strong authentication, wherein the strongish authentication, being stronger than weak, thus resides between the weak and strong options. If the user may remain anonymous, authentication is unnecessary. Weak authentication may refer to the use of single standard category identification means such as user ID/password pair. Instead, strongish authentication may apply at least two standard identification measures utilizing different techniques. With strong authentication, at least one of the identification measures should be strong. Notwithstanding the various advancements taken place during the last years in the context of user and service identification, authentication, and related secure data transfer, some defects still remain therewith and are next briefly and non- exhaustively reviewed with useful general background information.

Roughly, access control methods to network services include push and pull methods. In pull methods, a user may first identify oneself anonymously to a network service providing a login screen in return. The user may then type in the user ID and a corresponding password, whereupon he/she may directly access the service or be funneled into the subsequent authentication phase. In push methods, a network server may first transmit information to the e-mail address of the user in order to authorize accessing the service. Preferably only the user knows the password of the e-mail account. The users are often reluctant to manually manage a plurality of user IDs and corresponding passwords. As a result, they may utilize the very same user ID and/or password in multiple services and/or use rather obvious and thus easy-to- crack words, numbers or expressions as passwords. Even if the access control management systems require using a strong password, i.e. hard-to-remember password, a risk that the user writes the password down increases considerably and the authentication level turns ultimately weak.

Yet, the utilization of a password is typically enabled by access control management entity that also stores the password locally. If the security of the data repository is later jeopardized, third parties may acquire all the passwords stored therein. Also if the user forgets the password or it has to be changed for some other reason, actions have to be taken by the user and optionally service provider. The user has to memorize the new password. Further, the adoption of a personal, potentially network service-specific token such as a smartcard, e.g. SecurlD™, and a related reader device may require intensive training. The increase in the use of smart cards correspondingly raises the risk of thefts and provision of replacement cards. In case the personal tokens apply a common (distributed) secure algorithm, the theft of such algorithm would cause tremendous security issues and trigger massive update operations regarding the associated elements such as tokens in order to recover at least part of the original security. Particularly, in the context of cloud services such as cloud virtual-desktop services that may be regularly, e.g. daily, utilized by a user, the nowadays available access control procedures, especially identification and authentication solutions applied upon logging in to a service, are typically either inadequate in terms of the achieved data security or awkward from the standpoint of usability with reference to the aforesaid lengthy and strong, i.e. complex and thus hard-to- remember, passwords.

SUMMARY OF THE INVENTION

The objective is to at least alleviate one or more problems described hereinabove regarding the usability issues and security risks, such as authentication risks, associated with the contemporary remote computer systems and related network services.

The objective is achieved by the arrangement, such as an apparatus or a plurality of at least functionally connected apparatuses, and method in accordance with the present invention disclosing service access technology and technique, respectively, preferably incorporating e-mail account and mobile device -related communication resulting in at least two-factor authentication in conjunction with the overall procedure, which provides both trustworthy authentication and pleasant use experience. Various electronic services such as cloud computing services, remote desktop services, and customer portal services may be accessed and related documents programmatically transmitted from a database to registered recipients, for instance.

Accordingly, in an aspect of the devised solution an arrangement, such as a server apparatus or a plurality of at least functionally connected server and/or other apparatuses, for controlling access to a network service, such as a cloud service, utilizing multi-factor authentication, comprises a processing entity and a memory entity for processing and storing data, respectively, and a data transfer entity for receiving and sending data, the arrangement being configured to send an e-mail notice to an e-mail address associated with a predetermined user, the e-mail notice including a preferably secure link for a browser, such as an Internet browser, receive an indication of the activation of the preferably secure link, such as a data request like a web resource request sent via a browser, in response to which the arrangement being further configured to send

-first browser data, such as web page data, requesting the user of the browser to input a secret, and

-a one-time password (OTP) to a mobile device associated with the predetermined user, receive user input relative to the request for secret, determine whether the user input matches the sent OTP, and if that is the case, enable the user of the browser and related terminal device, the user being thus authenticated as the predetermined user, to access the service.

In some embodiments, the enablement may generally include sending data such as second browser data, e.g. a UI (web) page of the associated network service or other service data, which may further enable the user to access the service and/or fetch a desired electronic document via a download link, for instance. In a preferred embodiment the enablement incorporates or basically is about providing service access -enabling data to the user (terminal). The transferred enabling data may include at least one element selected from the group consisting of: a browser executable program, a Java entity such as a Java applet, an executable such as a binary executable, and a service password or related data required for generating it preferably in encrypted form.

The data may be transferred via the browser connection, and/or through other connection. The service password may be used for accessing such as logging in to the network service. Multiple data elements may be transferred substantially simultaneously, e.g. one substantially after each other, or during a longer period. The service password, the resulting authentication, e.g. log-in, action and/or the resulting service connection may be associated with a predetermined or dynamic validity or expiration condition such as a period. The service password may be user and/or terminal device -specific. In some embodiments, the service password may be embedded in the transferred other data such as transferred program or transferred (other) file. Depending on the embodiment, the utilization of the service password, or 'service code', may be substantially transparent or invisible from the standpoint of the user, i.e. it may be handled automatically for log-in purposes so that after providing the OTP the user may omit substantive further manual actions in order to access the service, or the required action(s) are minimal such as a number of simple confirmation actions like click or button press- type actions. The service password may also be lengthy, e.g. of available maximum length as advantageously, the user does not have to manually play with it or even know it. The password generation may be of 'black box' type, i.e. a specific entity may be configured to generate it in a non- transparent manner. Likewise, the password may be afterwards operated via a number of black box entities. The password may remain secret from the service operator even though the service operator may advantageously trigger resetting the password upon need. The password may be stored as encrypted. Preferably the password remains secret to the user, operator and third parties. In some embodiments, the tasks of password or related data provision, verification (receipt and checking) and/or service provision may be executed by different entities. A certain network entity comprising a number of network devices of the arrangement may thus take care of OTP and/or service password provision and/or verification. A certain other network entity may provide the network service. The entities may also overlap as to the included devices.

In a supplementary embodiment, also the service password may be a one-time password and/or a temporally limited password. It may be created dynamically. For example, a new service password may be created and/or transferred when necessary. In some embodiments, the new password may be provided upon each instance of a service log in procedure after the mobile-based OTP authentication as described herein.

In one supplementary or alternative embodiment, the established service connection (access) is maintained based on a number of security measures the outcome of which is used to determine the future of the service connection, i.e. let it remain, terminate it, or change it, for example. In some scenarios, fingerprint methodology may be applied. The client terminal may initially, upon service log-in, for instance, provide a fingerprint based on a number of predetermined elements, such as browser data such as version data, OS data such as version data, obtained Java entity data such as version data, and/or obtained executable data such as version data. Version data may include ID data such as version identifier or generally the identifier (application or software name, for example) of the associated element. The arrangement may be configured to request new fingerprint in response to an event such as a timer or other temporal event (timed requests, e.g. on a regular basis). Alternatively or additionally, the client may provide fingerprints independently based on timer and/or some other event, for instance.

In response to the received new fingerprint, the arrangement may utilize the most recent fingerprint and a number of earlier fingerprints, e.g. the initial one, in a procedure such as a comparison procedure. The procedure may be executed to determine the validity of the current access (user). For example, if the compared fingerprints match, a positive outcome may be determined indicating no increased security risk and the connection may remain as is. A mismatch may trigger a further security procedure or terminating the connection.

In another supplementary or alternative embodiment, the arrangement is location-aware advantageously in a sense it utilizes location information to authenticate the user. A number of predetermined locations may be associated with each user of the arrangement. For example, the location may refer to at least one element selected from the group consisting of: address, network address, sub-network, IP (Internet Protocol) address, IP sub-network, cell, cell-ID, street address, one or more coordinates, GPS coordinates, GLONASS coordinates, district, town, country, continent, distance to a predetermined location, and direction from a predetermined location. Each of the aforesaid addresses may refer to an address range.

Failed location-based authentication may result in a failed overall authentication (denied access), or alternatively, a limited functionality such as limited access to the service may be provided. The same applies to other authentication factors. Each authentication factor may be associated with a characterizing weight (effect) in the authentication process.

A certain location may be associated with a certain user by "knowing" the user, which may refer to optionally automatically profiling and learning the user via monitoring one's habits such as location and optionally movements. As a result, a number of common, or "allowed", locations may be determined and subsequently utilized for authentication purposes. Additionally or alternatively, the user may manually register a number of allowed locations for utilizing the solution in the arrangement. Generally, in various embodiments of the present invention, knowing the user and/or his/her gear and utilizing the related information such as location information in connection with access control, conducting automated attacks such as different dictionary attacks against the service may be made more futile.

In some scenarios, the location of the user (terminal) and/or data route may be estimated, e.g. by the arrangement, based on transit delay and/or round-trip delay. For example, delays relating to data packets may be compared with delays associated with a number of e.g. location-wise known references such as reference network nodes, which may include routers, servers, switches, firewalls, terminals, etc. In one other, either supplementary or alternative, embodiment the secure link may include a U I with an applicable scheme such as a HTTPS scheme implying the use of SSL/TLS (Secure Sockets Layer/Transport Layer Security) protocol for encrypting traffic between the browser and the server. Alternatively, the traffic may be encrypted utilizing some other method. The link may include an address of a web page including the first browser data for user input. The address may contain a secure element that is practically impossible to guess or deduce. The secure element may include a hash such as an MD5 (Message-Digest algorithm 5) hash, for instance, for the determination of which service or document data and secret key of the server may have been applied.

In a further, either supplementary or alternative, embodiment the notice (e-mail) may be provided as digitally signed utilizing a substantially S/MIME-compliant (Secure/Multipurpose Internet Mail Extensions) identity certificate, OpenPGP (Pretty Good Privacy, RFC 4880)-compliant identity certificate, and/or X.509- compliant identity certificate. The options are not necessarily mutually exclusionary. E.g. X.509-compliant certificate may be utilized in connection with S/MIME e-mails.

Still in a further, either supplementary or alternative, embodiment a text message, such as an SMS-compliant (Short Message Service) message, is utilized as a carrier of the OTP. Alternatively other message such as a multimedia message, e.g. an MMS (Multimedia Messaging Service) message, may be exploited. Yet in a further, either supplementary or alternative embodiment, the network service is a cloud service (running in a cloud). Additionally or alternatively, the service may arrange virtual desktop and/or remote desktop to the user. In another aspect, a method for controlling access to a network service such as a cloud virtual-desktop service, utilizing multi-factor authentication, comprises sending an e-mail to an e-mail address associated with a predetermined user, said e-mail including a preferably secure link for a browser, receiving an indication of the activation of the preferably secure link, sending first browser data, such as web page data, requesting the user of the browser to input a secret, sending a one-time password (OTP) to a mobile device associated with the user, receiving user input relative to the request for secret, determining whether the user input matches the sent OTP, and if that is the case, enabling the user of the browser and related terminal, thus authenticated as the predetermined user, to access the service, wherein said enabling includes sending enabling data to the terminal optionally via the browser-related connection such as HTTP (Hypertext Transfer Protocol) connection.

Particularly, the actual execution order of the first browser data and OTP sending items may differ depending on the embodiment, which is also described in further detail hereinafter.

The previously presented considerations concerning the various embodiments of the arrangement may be flexibly applied to the embodiments of the method mutatis mutandis, and vice versa, as being appreciated by a skilled person. The utility of the present invention follows from a plurality of issues depending on each particular embodiment. The suggested solution potentially enables applying e.g. strongish authentication such that the use experience is improved, security risks are mitigated, and the supply chain of services and/or digitally transferable documents such as bills or account statements among numerous other options is shortened. Indeed, at least strongish if not strong authentication is achieved with minimal additional costs. Encryption may be flexibly utilized for information transfer. Existing, proprietary network services may be cultivated by adding at least two-factor authentication thereto as a front-end solution without necessarily causing a need to make major changes to the already established, underlying authentication/log-in practice of the service. A service may be practically ready for exploitation by the user as soon as the one has received the notification e-mail. As the e-mail contains only a link to access the OTP-requesting front-end of the network service, potential lack of e-mail encryption does not expose any confidential information. The password of e-mail account and the control over mobile account are used as authentication factors among other options such as location information. The risk of undesirably lowering the authentication level due to careless management of passwords practically disappears. Spyware-related risks may be overcome, for example. The arrangement may store information such as e-mail addresses and cell phone numbers of the users of the provided services, but such information is not typically considered as particularly confidential and would be stored anyway in respect of customer records as desirable contact details. As a relatively ordinary mobile device may be applied as a security token, proprietary new tokens do not have to be obtained.

The expression "a number of refers herein to any positive integer starting from one (1), e.g. to one, two, or three.

The expression "a plurality of refers herein to any positive integer starting from two (2), e.g. to two, three, or four.

The expression "data transfer" may refer to transmitting data, receiving data, or both, depending on the role(s) of a particular entity under analysis relative a data transfer action, i.e. a role of a sender, a role of a recipient, or both.

The terms "a" and "an" do not denote a limitation of quantity, but denote the presence of at least one of the referenced item.

The terms "first" and "second" do not denote any order, quantity, or importance, but rather are used to distinguish one element from another. Different embodiments of the present invention are disclosed in the dependent claims.

BRIEF DESCRIPTION OF THE RELATED DRAWINGS

Next the invention is described in more detail with reference to the appended drawings in which

Fig. la illustrates the concept of the present invention via both block and signaling diagram approaches relative to an embodiment thereof.

Fig. lb illustrates one possibility for providing remote service access to the user of a client terminal after successful OTP- capitalizing authentication.

Fig. lc is a block diagram representing an embodiment of selected internals of the arrangement according to the present invention.

Fig. 2 is a flow chart disclosing an embodiment of a method in accordance with the present invention.

Fig. 3 is a flow chart disclosing an embodiment of enabling the user to access a remote service in response to a successful authentication in accordance with the present invention.

DETAILED DESCRIPTION OF THE EMBODIMENTS

In the context of the present invention, the user preferably has an e-mail account (advantageously private e-mail), a browser application, network access such as Internet accessibility, a mobile (communications) device and a mobile subscription. Further, the user may have a desktop, a laptop, a thin-client or a hand-held computer for e-mail, browsing and/or various other purposes, for instance. Alternatively or additionally, the mobile device may be utilized also for such use. For example, many contemporary and forthcoming higher end mobile terminals such as so-called "smartphones" bear necessary capabilities for both e- mail and web surfing purposes. Also a number of various other software solutions, e.g. clients, may be run on the mobiles. Advantageously, the e-mail address and mobile number of the user are stored in the arrangement for future use.

The user may have to be supplied with service data such as virtual desktop and/or financial reports requiring at least strongish authentication. In the latter case, a related document may be, e.g. upon first instance of use (fetch by a recipient) converted into a target format such as the PDF format and/or digitally signed.

The potential users of the provided arrangement and method include different network service providers, operators, cloud operators, virtual and/or remote desktop service providers, software manufacturers, financial institutions, companies, and private persons in the role of a service provider/data sender, intermediate entity, or user/recipient, for example. The invention is thus generally applicable in a wide variety of different use scenarios and service/document delivery applications.

In some embodiments the service may include customer portal service and the service data may correspondingly include customer portal data. Through the portal, a user may inspect the available general data, company or other organization-related data or personal data such as data about rental assets, estate or other targets. Associated reports may be obtained via the service.

Figure 1 a illustrates the overall concept of the present invention according to an embodiment thereof. The embodiment may be related, by way of example only, to the provision of a network service such as a virtual desktop service or document delivery service, e.g. delivery of a bill including a notice of maturity regarding a bank loan. Entity 102 refers to the service user (recipient) and associated devices such as a desktop or laptop computer and/or a mobile device utilized for accessing the service in the role of a client, for instance. The device(s) preferably provide access to a network such as the Internet. The mobile device, such as a mobile phone (e.g. a smartphone) or a PDA (personal digital assistant) may preferably be wirelessly connected to a compatible network, such as a cellular network. Optionally the Internet may be accessed via the mobile device. Entity 106 refers to an arrangement of a number of at least functionally connected devices for user verification and service provision and/or document delivery. In some embodiments, the entity 106 may only participate in user authentication and thus service access, but the service provision is then taken care of by a number of further devices. In some other embodiments, the entity 106 may also contain a number of devices actually in charge of service (data) provision after authentication/log- in phase. Hereinafter the entity 106 is called as NAS (Network access server) without any limiting purpose, however. The communication between the entities 102 and 106 may take place over the Internet and underlying technologies, for example. Preferably the entity 106 is functionally also connected to a mobile network.

At 126, the NAS 106 stores information about a service to be provided to users and/or documents such as bills to be delivered to them in a number of databases for preferably permanent storage. Further, user data may be obtained and managed. At 128, a notice regarding the service and/or document is sent, as digitally signed by S/MIME, for example, and utilizing a first communication technique, preferably e-mail, to the registered e-mail address of the intended recipient. Further, the e-mail may be encrypted. With e-mail it is referred to Internet e-mail, for example. Also other electronic mail systems or platforms may be applied. The applied protocol may be SMTP (Simple Mail Transfer Protocol), for example. At 130, the user 102 receives the e-mail notice informing about a possibility to access the service or e.g. fetch a new bill via NAS 106. The notice may be received via a desktop computer or a portable, e.g. laptop or palm-top, computing device such as a smartphone as mentioned above. Optionally a plurality of authentication options may be provided to the user as described in more detail hereinafter. The user 102 may verify the sender of the e-mail by referring to the digital signature to avoid spammers' notices. Thereafter, the user 102 may select a secure link included in the notice and comprising a unique, optionally one-time accessible, URI for proceeding further with accessing the service or e.g. e-bill stored in the NAS server 106, which takes place in item 132 utilizing e.g. HTTPS for establishing a secure channel to the server 106. Item 148a illustrates the simplified screen view visualizing the notice and the embedded link(s) to the user 102. The used e-mail client may include a standalone application (UI) or e.g. a webmail application.

Alternatively or additionally, anonymous pull-type login could be applied by the user for accessing the service in some embodiments. The user may, for instance, first access the network server 106 anonymously. A related service (web) page may then provide a registration and/or login screen. The server 106 may subsequently send a notice such as the aforesaid e-mail notice to the e-mail address of the user. The notice may include a link such as an URI for service access. The URI may be stored as a bookmark for facilitated logins in case the link is substantially permanent or of a longer term/multiple uses anyway. In addition to service address provided by the URI the user 102 may have to utilize a personal user ID and/or password optionally each time upon entering the service. Even the use of OTPs may be omitted with the increased security risks. Thus the obtainable overall security level in the context of present invention is fully scalable ranging from the use of permanent service links and user ID/password pairs to one-time links, mobile-transferred OTPs and optional further security factors such as the location- factor.

Reverting to the embodiment visualized in Figure la, at 134 the server 106 preferably validates the URI address based on e.g. the secure element thereof. At 136, the server 106 sends browser data for representing an initial login screen to the user 102 (again e.g. HTTPS may be applied) and, optionally in response to a specific request by the user 102 e.g. via the login screen, an OTP preferably to the mobile device (e.g. cell phone number) associated with him/her e.g. in an SMS message delivered via an SMS gateway, for instance. At least part of the transmission path to the mobile device is preferably wireless and the air interface of a wireless, e.g. cellular, network compatible with the mobile device is applied. At least partially different (second) communications technique may be thus exploited in contrast to the delivery of the e-mail notice. Accordingly, 2-factor/2- channel authentication may be achieved. The message and/or the OTP may be encrypted utilizing a predetermined encryption technique. At 138, the user 102 receives the login screen that is visualized on his/her terminal device, see the example at 148b. At 138b, the OTP is received preferably with the mobile device. At 140, the user 102 types the OTP in the login screen. Again, the related communication may apply HTTPS (TTL/SSL), for instance. At 142, access control logic of the server 106 compares the received OTP and the reference OTP (correct OTP sent at 138b), and in case these two match and optional additional conditions are fulfilled as well, transmits, at 144, data for enabling the user to access the service or document received at 146.

In document service context, the procedure may include generating a new view enabling the user 102 to access a service, download a document such as a bill or view it directly, e.g. via HTML page(s) interpreted by compatible browser and necessary browser add-on(s), optionally with supplementary data such as indication of available functionalities like change of the presentation mode. In other service contexts such as cloud service, optionally cloud-based virtual- desktop service, contexts the enablement may refer to further, e.g. security- related, operations prior to gaining an access to the service. Such operations are explained in more detail hereinafter. Yet, HTTPS and/or SSH (Secure Shell) may be applied for securing the data transfer of e.g. the bill data as browser data, for instance. Optionally, a switchover from HTML to PDF or some other presentation may be triggered.

In some embodiments, location information 143 may be utilized in the authentication process. In one embodiment, the server 106 and/or other entities external to the user's 102 terminal gear may be configured to locate one or more of the terminals the user 102 applies for obtaining the document, i.e. a first terminal used for e-mail and browsing/login procedure, and a second terminal used for OTP reception, if different. The location of the terminal(s) typically gives a hint about the user's 102 location. Alternatively or additionally, the terminal devices may bear an own role in the positioning process and execute at least part of the necessary positioning actions locally. Actions required to position a terminal may be shared between the terminal(s) and at least one external entity.

For instance, address information may be used in the positioning process to deduce the location of the particular terminal in question. Somewhat typically, terminal or access network addresses such as IP addresses are at least loosely associated with physical locations so that the address-based locating is at least limitedly possible. In connection with mobile devices, many other options are also available including roaming signal and data transmission -based positioning. For example, by checking the ID of the base station(s) the mobile device is communicating with, at least approximate location of the mobile device may be obtained. Yet, through more comprehensive signal analysis, such as TOA (Time- Of-Arrival), OTD (Observed-Time-Difference), or AOA (Angle-Of- Arrival), the mobile device may be located.

In some embodiments, a satellite navigation receiver, such as a GPS (Global Positioning System) or GLONASS (GLObal Navigation Satellite System), in connection with a terminal device may be exploited. The terminal may share the locally received satellite information with external entities as such or in cultivated form (e.g. ready-determined coordinates based on received satellite signal(s)). Further, data entity such as data packet transit times or TT times may be monitored, if possible, e.g. in relation to both the monitored user/terminal and e.g. location-wise known reference entities as described hereinbefore in order to assess the location of the user/terminal by associated comparison. On the basis of the terminal location, the server 106 may then introduce a further factor, i.e. a location -based factor, to the authentication procedure and verify, whether the current location of the terminal in question matches with predetermined location information defining a number of allowed locations and/or banned locations in the light of the service and/or document access. Depending on the embodiment, the status of the location-based factor may be evaluated prior to the evaluation of the fulfillment of other authentication factors, in conjunction with them, or as a final check before authorizing the user to access the service and/or electronic document.

One shall remember that in some embodiments, a communications technology different from mobile technology could be applied for delivering the OTP. This might take place upon "no service" situations relative to the mobile network, for instance, as a secondary, back-up connection. The arrangement may be configured to autonomously detect the fulfillment of a triggering condition, such as mobile connection failure, for utilizing the secondary connection for OTP transfer, and/or the user may request such by selecting a related (secure) link included in the e-mail notice, for example. The secondary connection may refer to transmitting the OTP via e-mail, for instance. When secondary connection is applied for OTP transfer, the information provided in or through the document and/or the associated network service may be scaled (down) accordingly to match the achieved authentication level. Less information, e.g. less confidential, may be available to the recipient, for example. The information may be pre- classified into a number of security classes for facilitating the scaling.

In some embodiments, the user rights for the network service provided by the arrangement may be flexibly scaled via the utilization of a plurality of authentication options. The options may be indicated in the e-mail notice via links, text, graphics, and/or other means, for example. In the case of weak authentication, in some embodiments the user receiving the receipt notice may directly access the related service and/or document by activating a relating link included therein. The achieved authentication level corresponds to a traditional e- mail communication such as a transfer of a bill. In response, the arrangement may be configured to offer merely a limited, low-level functionality of the overall service to the user, such as simple access to the bill in selected format such as PDF format, and no other functions. Correspondingly, if stronger authentication is implemented via the transfer of the OTP as a new e-mail, for example, average functionality may be offered. For instance, possibility to fetch and view previously received documents may be provided. In cases wherein a mobile connection is applied for the OTP transfer, further data and/or service options may be accessible and/or changeable, such as personal contact information and/or execution of payments. As a result of offering multiple authentication options, the reception costs may be minimized and/or reception made technically more reliable in view of possible connection problems. Therefore, the use of a mobile device may be optional only. Nevertheless, it is in many use scenarios preferred. Figure lb illustrates one possibility for enabling a remote service access to the user of a client terminal after successful, OTP- capitalizing authentication. The service may be a virtual or remote desktop service and/or a cloud service, for example. NoMachine™ products such as NoMachine NX may be optionally utilized for the purpose.

The disclosed items may be considered to incorporate the aforementioned items 144, 146, which is highlighted in the figure by naming the corresponding items with postfix a, i.e. 144a, 146a. At 144a, the arrangement may provide the client device with data necessary for accessing the service, i.e. enabling data. Data transfer may still exploit the encrypted connection (e.g. HTTPS: SSL/TLS, or SSH) via the browser, for instance. Between different instances of service access, the data may at least partially differ. For instance, upon first access, more data may be provided including e.g. software that may be stored in the terminal such that further downloads of the same software may be omitted in the future. In contrast, substantially one-time (use) data, such as a password, and/or data expiring automatically based on e.g. a temporal event such as timer expiry may be provided upon each access including the first and all or some of the subsequent accesses. Further data such as user ID may be provided. At least part of the provided data, such as the password, may be determined in response to the successful OTP-authentication just finished.

In one example, the arrangement 106 may provide data such as software for accessing the network service at 144a to the terminal 102 such as a desktop or portable computer. The software may include a Java language entity such as a Java applet or other entity that may be executable in the browser of the terminal. Additional or alternative software such as an executable may be provided. The different software entities such as the Java entity and the executable entity may cooperatively enable the user to access the network service. The data may be provided with signature(s) to facilitate verifying the source thereof at the receiving end.

At 146a, the terminal may receive the data, store it and/or take it into use/install it depending on the nature thereof. A Java entity such as applet may be obtained and executed. It may be stored in the cache of the browser for enabling rapid future use as well. In case the terminal does not contain JVM (Java Virtual Machine), it may be first instructed, by the arrangement, to install that with JRE (Jave Runtime Environment) via an internal or external link, or via automatic download, for example. The data may further include additional or alternative applications such as a client executable for accessing a predetermined network service. Yet, a password may be received, preferably in encrypted form. As the connection may itself be encrypted and the password may be separately encrypted as well (e.g. included in a .nxs file that may be generally plain text but still contain an encrypted password), very high level of overall security is achievable. At 184, the terminal 102 may, in response to the received data, process the data, executed an action associated therewith and/or transmit data 184 such as at least part of the processed data to a remote entity such as the arrangement 106. In some embodiments, a Java client such as at least one Java applet and optionally further software such as a binary executable may cooperatively handle and/or process a received password, such as decrypt the password, and transmit the processed version securely, preferably over e.g. SSH, to a remote system such as back to the arrangement for accessing the target service. Browser-based data transfer may again be utilized. The password may be input to the GUI (Graphical User Interface) in order to log in to a virtual or remote desktop service, for example. Some, most or all the related actions may be automated such that after providing the OTP, the user may, at most, validate the execution of a number of selected actions, if necessary.

In some embodiments, the received data may include data such as a program and/or source data for generating and optionally preferably securely communicating (e.g. to the service) the service password. In some embodiments, the network service such as a virtual or remote desktop may be or include a Windows-based™ service. In some other embodiments, it may be or include a Linux, e.g. Ubuntu™, -based service. The arrangement 106 or other entity, such as a separate service entity, (this optional differentiation between access or authentication provision and subsequent service provision being highlighted in the figure by the broken horizontal line between item 144a and item 186) may then receive the data such as the decrypted service password at 186 and execute a related predetermined action 188 such as log the user in and provide the user with the desired target service such as virtual desktop service 188a. Associated service data may be transferred 188 between the parties. A selected method, such as device fingerprints, may be utilized to verify optionally regularly the user/terminal identity also during the service access.

Generally, different fingerprints may be rather versatilely applied also in the overall context of the present invention. Firstly, the link provided may be signed and the signature (and the related service) be verified. Secondly, the processes of user authentication may apply the various fingerprints available relating to location/address data such as IP address of the user, browser data relative to his/her terminal, OS (operating system) information, (session) cookie, calendar data, etc. to enhance the authentication accuracy. Service and authentication fingerprints may have their own validity rules. Figure 1 c is a block diagram illustrating the selected internals of an embodiment of the arrangement presented herein. The arrangement 106, such as a number of servers, may physically contain a number of at least functionally connected elements. The arrangement 106 is typically provided with one or more processing devices capable of processing instructions and other data, such as one or more microprocessors, micro-controllers, DSP's (digital signal processor), programmable logic chips, etc. The processing entity 150 may thus, as a functional entity, comprise a plurality of mutually co-operating processors and/or a number of sub-processors connected to a central processing unit, for instance. The processing entity 150 may be configured to execute the code stored in a memory 152, which may refer to instructions and data relative to the software logic and software architecture for controlling the arrangement 106. The processing entity may at least partially execute and/or manage the execution of the aforesaid receiving, sending, determining, and/or enabling tasks. Similarly, the memory entity 152 may be divided between one or more physical memory chips or other memory elements. The memory 152 may store program code and other data such as user contact information, electronic documents, various service data etc. The memory 152 may further refer to and include other storage media such as a preferably detachable memory card, a floppy disc, a CD- ROM, or a fixed storage medium such as a hard drive. The memory 152 may be non-volatile, e.g. ROM (Read Only Memory), and/or volatile, e.g. RAM (Random Access Memory), by nature. Software (product) 152 may be provided on a carrier medium such as a memory card, a memory stick, an optical disc (e.g. CD-ROM or DVD), or some other memory carrier.

The UI (user interface) may comprise a display or a data projector 154, and keyboard/keypad or other applicable user (control) input entity 154b such as a touch screen and/or a voice control input, or a number of separate keys, buttons, knobs, switches, a touchpad, a joystick, and/or a mouse, configured to provide the user of the arrangement with practicable data visualization and device control means, respectively. The UI may include one or more loudspeakers and associated circuitry such as D/A (digital-to-analogue) converter(s) for sound output, and optionally a microphone with A/D converter for sound input. A printer may be included in the arrangement for providing more permanent output.

The arrangement 106 further comprises a data interface 156 such as a number of wired and/or wireless transmitters, receivers, and/or transceivers for communication with other devices such as terminals and/or network infrastructure(s). For example, an integrated or a removable network adapter may be provided. Non-limiting examples of the generally applicable technologies include WLAN (Wireless LAN, wireless local area network), LAN, WiFi, Ethernet, USB (Universal Serial Bus), GSM (Global System for Mobile Communications), GPRS (General Packet Radio Service), EDGE (Enhanced Data rates for Global Evolution), UMTS (Universal Mobile Telecommunications System), WCDMA (wideband code division multiple access), CDMA2000, PDC (Personal Digital Cellular), PHS (Personal Handy-phone System), and Bluetooth. It is clear to a skilled person that the arrangement 106 may comprise numerous additional functional and/or structural elements for providing advantageous communication, processing or other features, whereupon this disclosure is not to be construed as limiting the presence of the additional elements in any manner. Entity 158 refers to such additional element(s) found useful depending on the embodiment.

Figure 2 discloses, by way of example only, a method flow diagram in accordance with an embodiment of the present invention. At 202 the arrangement of the present invention is obtained and configured, for example through loading and execution of related software, for managing the electronic service, related authentication and/or electronic document delivery system. At 204, an indication of a required authentication, such as an authentication request, is received from the current or future user of the service, or a related entity. User registration data for the service may be obtained now or it may have been obtained earlier. The data may include name/id, e-mail, and/or mobile number data, for instance. A service user may have several (sub-)accounts each optionally defining a valid e- mail address - mobile number combination. At 206, a notification regarding the service is transmitted towards the user based on contact information available. An e-mail account associated with the user may be applied, for example. The notification may include a link (typically a hyperlink), preferably also being a secure link, the activation of which funnels the client application such as the browser of the activator to the login/password entering page for proceeding further with service access. The link may refer to a one-time or temporally limited link. The link may be associated with e.g. location and/or device restrictions that limit the application of the link respectively to certain locations (e.g. geographical such as GPS or IP verification) and/or terminal devices. Thus in some embodiments, as described hereinbefore, the link could be applied successfully multiple times by the user without need to gain a new link upon each access.

At 208, the data transmission (e.g. HTTP(S) request, such as GET) initiated by the activator reaches the arrangement and the arrangement responds by supplying an password request or potentially a more comprehensive login page (e.g. user ID may be requested) back at 210 as e.g. a web page matching the received request, for example. At 209, an OTP may be optionally specifically requested by the user. E.g. associated control functionality such as a button may be activated or triggered by the user on the associated service page potentially also provided at 209. At 212, an OTP to be provided by the user as a response to the password query is supplied utilizing e.g. cellular communication to a mobile device associated with the user and advantageously with the e-mail whereto the notification was sent. Preferably the addresses whereto the e-mail and OTP are transmitted are indeed different to enhance the security of the overall arrangement. More preferably, the transmission techniques also at least partially differ, e.g. TCP/IP vs. cellular communication. In addition to the OTP, further data such as user ID may be provided. The order of items 210 and 212 may be reversed, or substantially simultaneous execution thereof may be preferred, as being clear to a skilled person. The issue is highlighted in the figure by the bi-directional broken arrow between the two items 210, 212. Likewise, the order of items 209 and 210 could in some embodiments be reversed or the items be combined as the password query towards the user generated at 210 may also include provision of a user- controllable functionality such as a web page control (button) for requesting the OTP, for instance. In some embodiments, item 212 could be executed even prior to or upon item 208.

As the user authentication OTP is provided to the login screen, a corresponding data transmission is triggered towards the arrangement that, at 214, receives the transmission. At 215, further authentication factors such as location factor may be optionally considered. Optionality of the further factors is depicted by the broken outline of item 215. As deliberated hereinbefore, the exact execution instant of further authentication checks may be determined per each particular embodiment, and the illustrated position is just one feasible option. For instance, one other applicable position could reside between items 216 and 218 such that the location check would be the ultimate verification prior to authorizing access to the service and/or related electronic document.

At 216, the password entered by the user is compared against the archived one. In case the passwords do not match, a further possibility may be given to the user to enter a correct password, which is indicated by a dotted loop-back arrow. In some embodiments, a limited number of retries may be permitted. If the maximum number of tries is met without success and/or a predetermined timer is exceeded for entering a proper password, a predetermined action may be executed. For example, the service administrator or e-document sender may be informed about the service access/document delivery failure and its cause via e- mail or other electronic communication.

Provided the password given is correct and optional further authentication checks have been successfully executed, access to the electronic service and/or document may be authorized at 218, e.g. via the browser through which OTP was input, etc. The arrangement may transmit, in response to the correct OTP input, data enabling service access, either directly or automatically, or via optional user intervention -requiring phase(s). An embodiment of related method items is given in Figure 3 described later below. The data may generally include software required for accessing the service, e.g. Java-based software, and/or preferably user-specific service password data (e.g. password or data for generating it) optionally in encrypted form. In document delivery services, the desired electronic document(s) may be transmitted to the user via the browser connection. A separate authorization display may be first provided, for example, implying that the password was correct (and optionally that further authentication factor checks were successful as well) and access to the document is now allowed. A link to enter the service or download the document may be simultaneously or successively presented. At 220, the method execution is ended. The execution of various method items may be naturally repeated upon need. As already alluded above, the execution order may be changed depending on the needs of the embodiment at issue.

Fig. 3 is a flow chart disclosing an embodiment of enabling the user to access a remote service in response to a successful OTP-based authentication in accordance with the present invention. The embodiment is also feasible with proprietary network services by adding at least two-factor authentication thereto without necessarily creating a need to make changes to the already established authentication/log-in interface and/or internal practice of the service. At 304, enabling data is provided to the terminal as disclosed hereinbefore. The data may include software and e.g. password or password-generation data. The password data, such as an encrypted password provided in .nxs file with reference to e.g. NoMachine™ virtual desktop solutions, may be meant for one access or log-in event only, or be applicable for a longer period such as for the time being if not substantially perpetually relative to e.g. the life cycle of the service. Software may include a number of software entities such as a browser-based entity, e.g. a Java applet, and/or a (binary) executable. The elements may be configured to communicate with each other. At 306, the obtained data may be utilized in the terminal. In one scenario, the Java applet may access the password and provide it to the executable. The executable may optionally decrypt the password. Then the Java applet and/or other software entity such as the executable may be configured to address the optionally decrypted password to the network service for gaining access thereto, i.e. log in to the service. The network service may operate at least tangentially through the arrangement with a number of common elements or independently as mentioned hereinbefore. In more general terms, an access request utilizing the data may be provided 308 by the terminal to the network service operated through and/or by the arrangement or some other entity. The terminal may perform these actions automatically or alternatively, at least some of them may require user intervention such as confirmation. The service side, i.e. the arrangement and/or service entity external thereto, may verify the credentials and if satisfied, begin serving the terminal 310 according to the service practices. For example, a visual GUI for a virtual desktop may be provided to the terminal in connection with a corresponding kind of a network service. If the user in question is provided with associated user rights (e.g. the role of an organization superuser), he/she may be able to modify or even add new user accounts including e.g. related e-mail - mobile number combinations and other information to the service portion, such as organization-related portion, under his/her control. As a result, new users may be conveniently added to the userbase of the service. In some embodiments, when the service is to be accessed for the second time by the same user and terminal, the OTP authentication may be again executed generally in accordance with the embodiment of Figure 2, for instance, followed by the actual service log- in as, by way of example, represented in Figure 3. However, all the data such as Java applet or binary executable may not be necessary to re-transfer. If the service access password is of OTP nature or has expired for some other reason, a new, optionally encrypted (recalling the fact that as the connection may be encrypted itself, the password may be actually multiple times encrypted during the transfer) service password may be provided to the terminal for local use and subsequent service log-in request (308). The suggested solution may add to overall security level of the network service as an OTP- based multi-factor, at least two-factor, authentication is provided thereto.

A computer program, comprising a code means adapted, when run on a computer, to execute an embodiment of the desired method steps in accordance with the present invention, may be provided. A carrier medium such as an optical disc, floppy disc, or a memory card, comprising the computer program may further be provided. The program may be delivered over a communication network and a communication channel. Consequently, a skilled person may on the basis of this disclosure and general knowledge apply the provided teachings in order to implement the scope of the present invention as defined by the appended claims in each particular use case with necessary modifications, deletions, and additions. For example, instead of HTML, a variation thereof, such as XHTML (extensible HTML), or e.g. WML (Wireless Markup Language) may be applied for document presentation, transfer and/or storage. In some embodiments, instead of a true OTP, a multi-times (still preferably a limited-times (authorizing e.g. two or three log-ins)) and/or a merely temporally limited-life password may be utilized for the mobile-enhanced authentication.

Claims

1. An arrangement (106), such as a server apparatus or a plurality of at least functionally connected server and/or other apparatuses, for controlling access to a network service, such as a cloud service, utilizing multi-factor, at least two- factor, authentication, comprising a processing entity (150) and a memory entity (152) for processing and storing data, respectively, and a data transfer entity (156) for receiving and sending data, the arrangement being configured to send an e-mail notice (128) to an e-mail address associated with a predetermined user, the e-mail notice including a preferably secure link for a browser, such as an Internet browser, receive an indication of the activation of the preferably secure link (134), such as a data request like a web resource request sent via a browser, in response to which the arrangement being further configured to send -first browser data, such as web page data, requesting the user of the browser to input a secret (136), and

-a one-time password (OTP) to a mobile device associated with the predetermined user (138b), receive user input relative to the request for secret (140), determine whether the user input matches the sent OTP (142), and in the case of a match, enable the user of the browser and related terminal device, the user being thus authenticated as the predetermined user, to access the service (144, 144a, 186, 188).

2. The arrangement of claim 1, configured to send enabling data (144a) to the terminal device, such as second browser data, wherein the enabling data preferably includes at least one element selected from the group consisting of: a browser executable program, a Java entity, a Java applet, an executable, a binary executable, a password, data for generating a password, and an encrypted password.

3. The arrangement of any preceding claim, configured to further utilize the estimated location of the user as an authentication factor (143).

4. The arrangement of claim 3, wherein the location estimate is based on the estimated location of the terminal device applied for activating the link.

5. The arrangement of any of claims 3-4, wherein the location estimate is based on the estimated location of the mobile device.

6. The arrangement of any of claims 3-5, wherein the location estimate is compared against one or more predetermined locations.

7. The arrangement of claim 6, wherein in the case of a match between the location estimate and a predetermined location deemed as allowable, the authentication is considered successful in the light of the location-related authentication factor.

8. The arrangement of any of claims 6-7, wherein in the case of a match between the location estimate and a predetermined location not deemed as allowable, the authentication is considered unsuccessful in the light of the location-related authentication factor.

9. The arrangement of any of claims 3-8, configured to trace user behavior, said tracing including monitoring locations and/or movements, whereupon said arrangement is configured to determine a number of allowed or banned locations for accessing electronic documents at least partially based on the behavior.

10. The arrangement of any of claims 3-9, wherein the location refers to at least one element selected from the group consisting of: address, network address, sub-network, IP (Internet Protocol) address, IP sub-network, cell, cell-ID, street address, one or more coordinates, GPS (Global Positioning System) coordinates, GLONASS (GLObal Navigation Satellite System) coordinates, district, town, country, continent, distance from a predetermined location, and direction from a predetermined location.

1 1. The arrangement of any of claims 3-10, wherein the location is estimated utilizing an indication of data transmission delay such as data packet transit or round-trip delay relating to the terminal device of the user, such as the mobile device or other terminal device, optionally a desktop or laptop computer.

12. The arrangement of any preceding claim, wherein the e-mail is provided as digitally signed utilizing at least one certificate selected from the group consisting of: S/MIME-compliant (Secure/Multipurpose Internet Mail Extensions) identity certificate, OpenPGP (Pretty Good Privacy, RFC 4880) - compliant identity certificate, and X.509-compliant identity certificate.

13. The arrangement of any preceding claim, configured to send enabling data (144a) to the terminal device including at least one program, such as a browser- executable program optionally including a Java applet, and password data, optionally including encrypted password data, the sent data being required by the terminal device to access the network service.

14. The arrangement of any preceding claim, configured to send enabling data (144a) including at least part of a network service session file, such a file with nxs extension, to the terminal, said part optionally including password data for accessing the network service such as a plain text password or encrypted password.

15. The arrangement of any preceding claim, configured to send enabling data(144a) to the terminal device including password data for accessing the service, wherein the password data is indicative of a limited-times password, such as one-time (OTP) password, and/or a temporally automatically expiring password.

16. The arrangement of any preceding claim, configured to apply a predetermined digital fingerprint technique to verify the identity of the terminal during the service usage, after log in.

17. The arrangement of any preceding claim, configured to send enabling data (144a) to the terminal device including password data and other data for accessing the service, wherein the password data is dynamic and to be created and sent for each instance of service access by the user and the other data is static such as computer program and to be used multiple, optionally subsequent, times for accessing the service by the user.

18. The arrangement of any preceding claim, configured to send the OTP embedded in a text or multimedia message, such as an SMS-compliant (Short

Message Service) or an MMS-compliant (Multimedia Messaging Service) message, respectively.

19. The arrangement of any preceding claim, configured to host the network service, preferably a virtual or remote desktop service.

20. A system comprising the arrangement of any preceding claim and the terminal device (102) for accessing the network service.

21. A method for controlling access to a network service such as a cloud virtual- desktop service, the method utilizing at least two-factor authentication and comprising sending an e-mail to an e-mail address associated with a predetermined user, said e-mail including a preferably secure link for a browser (206), receiving an indication of the activation of the preferably secure link (208), optionally further receiving a user request for one-time password (OTP) (209), sending first browser data, such as web page data, requesting the user of the browser to input a secret (210), sending a one-time password (OTP) to a mobile device associated with the user (212), receiving user input relative to the request for secret (214), determining whether the user input matches the sent OTP (216), and in the case of a match, enabling the user of the browser and related terminal, the user being thus authenticated as the predetermined user, to access the service, wherein said enabling includes sending enabling data to the terminal (218, 304) optionally via the browser-related connection such as HTTP (Hypertext Transfer Protocol) connection.

22. A computer program comprising code means adapted to, when run on a computer, to execute the method items of claim 21.

23. A carrier medium comprising the computer program according to claim 22.