WO2007059169A2 - Methode d'acces a une application faisant appel a un code d'authentification genere par un client - Google Patents

Methode d'acces a une application faisant appel a un code d'authentification genere par un client Download PDF

Info

Publication number
WO2007059169A2
WO2007059169A2 PCT/US2006/044261 US2006044261W WO2007059169A2 WO 2007059169 A2 WO2007059169 A2 WO 2007059169A2 US 2006044261 W US2006044261 W US 2006044261W WO 2007059169 A2 WO2007059169 A2 WO 2007059169A2
Authority
WO
WIPO (PCT)
Prior art keywords
address
message
user
request
server
Prior art date
Application number
PCT/US2006/044261
Other languages
English (en)
Other versions
WO2007059169A3 (fr
Inventor
Peter H. C. Madams
Joseph H. Salesky
Ayelet Zadok
Original Assignee
Clairmail Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US11/280,140 external-priority patent/US7844674B2/en
Priority claimed from US11/422,317 external-priority patent/US7870201B2/en
Priority claimed from US11/422,318 external-priority patent/US7870202B2/en
Application filed by Clairmail Inc filed Critical Clairmail Inc
Priority to EP06837611A priority Critical patent/EP1955183A2/fr
Priority to JP2008541294A priority patent/JP2009516305A/ja
Priority to CA002627530A priority patent/CA2627530A1/fr
Publication of WO2007059169A2 publication Critical patent/WO2007059169A2/fr
Publication of WO2007059169A3 publication Critical patent/WO2007059169A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/563—Data redirection of data network streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/082—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying multi-factor authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/58—Message adaptation for wireless communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/35—Network arrangements, protocols or services for addressing or naming involving non-standard use of addresses for implementing network functionalities, e.g. coding subscription information within the address or functional addressing, i.e. assigning an address to a function
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/168—Implementing security features at a particular protocol layer above the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels

Definitions

  • Email Used throughout the enterprise and across organizational boundaries, email is used to communicate and request information or action.
  • email Much like the telephone for voice communication, email has been adopted as a primary application for business, in particular for both remote and mobile access.
  • email tends to be the primary business communication platform and, hence, is almost always open on a user's desktop. It also tends to be the primary application for wireless users.
  • Email was originally developed as an electronic extension to regular physical mail, and as such is principally asynchronous and freeform.
  • Asynchronous generally means that a process (e.g., sending an email) operates independently of other processes (e.g. receiving an email), whereas synchronous means that the process runs only as a result of some other process being completed or handing off operation (e.g., voice telephone conversation).
  • An email message is generally composed by a first user, and sent to a second user, where it is queued in the second user's inbox to be subsequently read and possibly responded to at a later time.
  • Freeform refers to the relatively small amount of standardized information in an email message. That is, aside from a few fixed fields (e.g., destination address, origin address, and subject etc.), the majority of the email document itself comprises the content or body. This is comparable to a physical mail message which generally only requires the destination address.
  • Mobile devices generally present the user with a relatively poor user interface for applications other than voice, because of both battery duration and form-factor requirements.
  • receiving messages is easy, with the exception of voice, small displays and keyboards make transmitting messages awkward and problematic.
  • sending a text message may take a substantial effort because of the relatively small size mobile keyboards.
  • devices without full keyboards (such as the numeric keypads on most cell phones) practically restrict data transmission to short messages (e.g., SMS, etc.).
  • Screen size also tends to limit the use of conventional client/server applications and browsers.
  • Existing applications and Web-sites generally do not work with the small screens on mobile devices despite attempts at screen panning or automatic conversion from HTML to WML.
  • Some vendors have chosen to write new versions of their applications or Web-sites especially for the mobile worker but this is non-trivial (one screen must become many mobile-screens) and therefore expensive to implement.
  • the invention relates, in one or more embodiments to a method for effecting the execution of an application function on an application server from a client device.
  • the client device is coupled to a proxy server, the proxy server being further coupled to the application server that executes an application implementing the application function.
  • the method includes selecting a request to execute the application function from a set of application function requests on the client device.
  • the method further includes transmitting a first text message pertaining to the request to the proxy server, the first text message including a text message destination address and a text message origination address, the first text message pertaining to a request to execute the application function.
  • the method additionally includes authenticating a user associated with the first text message origination address by sending an authentication message to the user at a text message confirmation address that is different from the text message origination address and receiving confirmation from the user responsive to the authentication message. If the user is authenticated by the authenticating, the method also includes executing the application function at the application server as specified by the first text message, whereby the first application function is ascertained based at least on the text message destination address.
  • One or more embodiments of the present invention involve a system for facilitating a user to use a client device to access one or more applications residing on one or more servers with an authentication code generated in at least one of the client device and a second device.
  • the system includes a message module configured to receive a first user message from the user and, in response to the first user message, create an authentication address and send a first request to a confirmation address for requesting the authentication code to be generated.
  • the confirmation address corresponds to the at least one of the client device and the second device.
  • the system also includes a parser configured to extract an instruction from at least one of the first user message and a second user message sent from one of the client device and the second device, if a positive reply message including the authentication code is received at the authentication address.
  • the system further includes a connector configured to communicate the instruction to the one or more servers for triggering one or more responses to be generated by the one or more applications and to be sent to the client device, if the instruction is extracted.
  • FIG. 1 shows a simplified block diagram of an application/information access arrangement in according to one or more embodiments of the present invention.
  • FIG. 2 shows a simplified block diagram illustrating an authentication mechanism processing a user request according to one or more embodiments of the invention.
  • FIG. 3 shows a simplified block diagram illustrating the authentication mechanism of FIG. 2 processing a rogue request according to one or more embodiments of the invention.
  • FIG. 4 shows a simplified block diagram illustrating scalability of the access arrangement according to one or more embodiments of the invention.
  • FIG. 5 shows a simplified block diagram illustrating a message protection mechanism according to one or more embodiments of the invention.
  • FIG. 6 illustrates application/information access types according to one or more embodiments of the current invention.
  • FIG. 7 shows a simplified block diagram illustrating a configuration of an access system according to one or more embodiments of the invention.
  • FIG. 8 shows a simplified block diagram illustrating administration of an access system according to one or more embodiments of the invention.
  • FIG. 9 shows a simplified block diagram illustrating the use of Web services with the access arrangement according to one or more embodiments of the invention.
  • FIG. 10 shows a flowchart of a method for executing an application utilizing the access arrangement according to one or more embodiments of the invention.
  • FIG. 11 shows a simplified block diagram of an access server according to one or more embodiments of the invention.
  • the invention might also cover an article of manufacture that includes a computer readable medium on which computer-readable instructions for carrying out embodiments of the inventive technique are stored.
  • the computer readable medium may include, for example, semiconductor, magnetic, opto-magnetic, optical, or other forms of computer readable medium for storing computer readable code.
  • the invention may also cover apparatuses for practicing embodiments of the invention. Such apparatus may include circuits, dedicated and/or programmable, to carry out operations pertaining to embodiments of the invention. Examples of such apparatus include a general purpose computer and/or a dedicated computing device when appropriately programmed and may include a combination of a computer/computing device and dedicated/programmable circuits adapted for the various operations pertaining to embodiments of the invention.
  • an application and/or information access arrangement is advantageously employed to facilitate enhanced information access and retrieval.
  • text-based messaging e.g., email, SMS, etc.
  • text-based messaging may be extended beyond the person to person communication form, providing both a platform and service directed access to "things" such as transactions, application data or resources on the Web.
  • Information access and retrieval can generally be either trusted or non-trusted. Trust generally refers to the degree of confidence that a first party has as to a second party's intent to abide by stated system of rules (e.g., privileges, restrictions, rights, etc.).
  • the access arrangement generally distinguishes between three types of requests: non trusted, trusted origin, and highly trusted. If the information being transferred between two parties is not particularly valuable in comparison to its general disclosure, or is generally non sensitive in nature, a non-trusted relationship is generally established. Non trusted request may be accepted from anyone/anywhere and results are returned to the sender. This is the simple open or public type of transaction.
  • the access arrangement may be employed to create non-trusted services in which a text-based messaging address returns non-sensitive information (e.g., news, weather, traffic, etc.). For example, by sending an email message to an email address, such as cmNews@ClairMail .com, with a news topic as the subject of the email, a response may be received containing news on that topic.
  • Trusted origin requests may be accepted only from a provisioned user (including a set of trusted user addresses) maintained on a registered user list, or derived from an external source (e.g., LDAP, MS Active Directory, etc.). Any request not properly authenticated is subsequently rejected (e.g., spam, etc.), and any reply may only be returned to the appropriate trusted address (and not necessarily to the sender).
  • An SMS address is particularly useful as a reply address since it is unique to the device.
  • a trusted user address scheme is also resistant to a man-in-the-middle attack. That is, a situation in which a third party, unknown to the other parties, intercepts a message from one party and forwards the message to a second party.
  • Highly trusted requests are trusted origin requests that require further sender authentication of transaction confirmation. For example, a highly trusted request may be used to transfer funds between bank accounts.
  • a confirmation message may initially be sent to the pre-arranged 'authentication address. 1 As in a trusted request, a registered user defines an address where these confirmation messages are sent, which is not necessarily the same device or protocol from which the request originated.
  • a confirmation message or authentication token (including a timestamp) that is valid for a short period of time may then be encrypted.
  • a duration is chosen such that the time required to break the encryption is substantially larger than the time window in which the message is valid.
  • the user may then reply to the confirmation message, perhaps adding some additional information, a personal identification number (PIN) for example, again making the system more secure. That is, if the encrypted message were intercepted and returned without the PIN, the transaction would not be authorized.
  • PIN personal identification number
  • the transaction is authenticated and executed and 'marked complete'.
  • this final step is used to secure against a man-in-the-middle attacks, since a transaction may only be executed once. For example, by typing an email address, such as cmTransfer@ClairMail .com, with a transfer amount as the subject of the email, and replying to a confirmation, a user can initiate a transfer of funds between two pre-specified accounts.
  • a robust authentication mechanism also helps to substantially reduce spam (e.g., unsolicited bulk messages, etc.). Spam has unfortunately encouraged fraudulent advertising and solicitation using electronic messages, since virtually anyone can transmit a substantial number of emails at virtually no cost. Rising to a significant level of concern, most businesses must now protect their messaging systems from floods of spam, as well as avoiding becoming a source of spam themselves, by bouncing bad messages to wrong places.
  • spam e.g., unsolicited bulk messages, etc.
  • the spammer may send a message with a forged but valid sender address to an invalid destination address at a third site. Consequently, the third site's email server, unable to deliver the message, may in turn send a copy of the undelivered (spam) message back to who it believes is the sender, which in this case is to the forged sender address.
  • an invalid destination address may be used in order to execute a denial of service attack.
  • a message from an attacker may be sent to an email server with both an invalid destination address and an invalid return address.
  • the email server replies to the non-existent sender, which in turn causes the message to bounce back to the original email server. Consequently, a message transmission loop may be created, eventually consuming sufficient network resources such that legitimate traffic can not be transmitted.
  • the access arrangement also uses authentication techniques to ensure that information is accessed and transactions executed on behalf of genuine users only.
  • the access arrangement may utilize an encrypted token which is sent to the client device. The user must reply or submit the token quickly and correctly. The token expires within a few minutes, so an eavesdropper does not have time to decrypt. Once the user replies (optionally with additional password or PIN) the token is canceled, so an eavesdropper cannot use a replicated message to affect a transaction.
  • This technique assures authentic operations using only a simple device, without the need for encryption/decryption in the mobile device.
  • relatively low performance processors are often used in mobile devices in order to increase battery life. Consequently, mobile devices tend not to be optimized for computationally intensive encryption/decryption tasks.
  • the access arrangement may allow hosted access infrastructure for managed enterprise access to both internal and external sources. It further may provide a manageable infrastructure for directed transactional access to applications and Web services allowing enhanced productivity and owner (total cost of ownership) TCO.
  • a simple request access (SRA) protocol gives secure directed text-based messaging access to applications and information, enhancing user productivity and reducing support and training costs. That is, no additional software need be installed on the user's desktop computer, laptop computer, mobile device, PDA, smart-phone, wireless-email- device, etc.
  • text-based messaging addresses can be created for "actions" or “transactions” within a platform that enables complex actions to be performed from a simple directed request.
  • a single request or message may span multiple applications and provide a consolidated or coordinated result
  • the results of multiple application queries, each using the same or disparate access credentials may be consolidated into a unified result.
  • Text-based messaging addresses stored in the users address book can now define request types.
  • the requester associated information may come from the profile database at an information/application access server (access server), such as a simple request access (SRA) server, and history of requests can be logged.
  • access server such as a simple request access (SRA) server
  • SRA simple request access
  • client log may be maintained at a client device inbox, where copies of all the sent and received messages are stored, to be accessed and searched later.
  • a server log may be maintained at the access server.
  • the server log records transaction information such as the user name, the task, the time, etc. Consequently the access server may provide a substantially high level of auditability that is often required by corporate governance guidelines and regulations, such as the Sarbanes-Oxley Act.
  • the access arrangement optimizes traditional text-based messaging applications (e.g., email, SMS, etc.) with a SRA (simple request access) addresses, avoiding the limitations of many other approaches such as synchronization, mini-browsers and expensive specialized client applications.
  • Access functions traditionally missing in text-based messaging may be provided as simple alphanumeric text messages (or other sets of indicia) sent to the access server which, in turn, acts upon the messages and returns the required results using a simple electronic message. That is, a ClairMail server may act as the user's personal assistant, by acting as a proxy on the user's behalf.
  • each SRA message has its own unique address.
  • Commonly used SRAs may be kept with the other traditional text-based messaging addresses in an address book for quick access with minimum key strokes. For example, a request might be "What is the credit limit for customer XYZ?", "Get a quote for stock symbol XXX?", "Place order for 100 units of YYY for customer XYZ?”, or "Sell 100 shares of stock XXX?”.
  • each of these requests could be sent to an appropriate address such as, for example, address@server.com along with additional appropriate parameters (e.g., customer number/name XYZ, Stock Symbol XXX, number of units or shares to buy/sell, item number/name YYY, etc.).
  • address@server.com along with additional appropriate parameters (e.g., customer number/name XYZ, Stock Symbol XXX, number of units or shares to buy/sell, item number/name YYY, etc.).
  • additional appropriate parameters e.g., customer number/name XYZ, Stock Symbol XXX, number of units or shares to buy/sell, item number/name YYY, etc.
  • the structure of email in particular, generally offers a large set of addresses which, in turn, provides a large namespace for transaction names.
  • the request can be sent as a SMS message.
  • the request can be sent as a Web service message.
  • the request can be sent as IM (instant message).
  • a Web interface may be used to send a detailed request, hi one or more embodiments, multiple protocols may be combined for a given request.
  • the request may utilize a given protocol for a request, and a different protocol to return the results of the request.
  • a URL Universal Resource Locator
  • SRA provides a relatively powerful yet simple secure user interface.
  • enterprise applications demand security and authenticity.
  • Security requires that confidential information be kept private and away from eavesdroppers.
  • authenticity requires that the message is from who it purports to be from.
  • the access arrangement enables substantially robust message authentication by generally accepting messages that contain trusted addresses. That is, unwanted messages or rogue senders can be detected and avoided.
  • a private key (which may be very hard to guess) also tends to be relatively long and hard to remember, it is often secured on a mobile device with a relatively short and memorable PIN or personal identification number (which may be relatively easy to guess).
  • PIN personal identification number
  • the local storage of a relatively strong private key with a relatively weak PIN may inadvertently expose the rights and privileges of the device owner to anyone using the device who correctly guesses the PIN.
  • the access arrangement may obviate problems of key management in the mobile devices and may obviate problems associated with differences between devices such as, for example, different memory sizes (e.g., some have a lot of memory and some only little), different programming languages (e.g., some are programmed with C/C++ and some with Java), different components (e.g., some have SIM cards and some do not), etc.
  • the access arrangement may build upon a simple message protocol (such as SMTP) with a message exchange that passes an encrypted token with the option of using a PIN as well to secure requests. Consequently, computationally intensive encryption may be done at an access server (which may have powerful sets of processors) instead of at the client device (which may have a relatively weak processor).
  • SMTP simple message protocol
  • the access arrangement also comprises a hardware/software combination that may be delivered either as a managed service or as an enterprise appliance installed within a firewall.
  • the "front-end” of the access arrangement may be a message server (or message module) that receives and responds to requests from clients.
  • the "back-end” of the access arrangement comprises a request server (or request module), which processes the requests, and accesses the appropriate applications on behalf of the requestor.
  • the combination of the message server and the response server in general may function as a proxy server for each client. That is, the application may not necessarily be aware that it is interacting with the access arrangement, as opposed to directly interacting with the client itself.
  • the message server is the gateway between the external and internal system components, in addition to running message services, e.g., one or more of SMTP, SMS, MMS, IM, XMPP, Web service, SOAP, XML, WAP, WML, HTTPS, HTTP, etc.
  • message servers can be replicated for scalability and availability.
  • the message server may run the authentication system using data stored in the profile database. Invalid messages are discarded or rejected. Valid messages may be acted upon immediately however, most messages are added to one of the persistent message queues, also stored in the database or on the file system.
  • message queues may be spread across different nodes of a computer cluster in a manner that is optimized for both data consistency and performance. That is, a particular message queue may be simultaneously modified from more than one source (e.g., add, delete, etc.), and yet still maintain a consistent state within the access arrangement.
  • source e.g., add, delete, etc.
  • the request server takes messages from the persistent queues, extracts the input data/parameters from the message, adds profile information such as user credentials, and passes them to the client application. That is, the request server makes the desired information-access or executes the transaction specified by the request and returns results.
  • the request server formats the results into a simple message and returns them to the user.
  • Request servers can be replicated for scalability and availability. Each server takes the next message from the queue, and does not interfere with others.
  • Request servers can often use one or more client application machines to run the applications. Client machines can also specialized to run only one or a few applications. This is useful when the client applications need a lot of computing resources, or perhaps need dedicated access to external network connections or databases. In these cases, different queue are used.
  • the message servers direct messages to the appropriate queue and only that set of request servers take messages from that queue.
  • the resulting system is substantially scalable in all aspects (e.g., message servers, request server and client application machines can all be replicated) ensuring substantially high availability, substantial scalability (from low-cost to high-capacity at the right price) with substantially easy maintenance and upgrade paths.
  • small, low-cost systems are needed for organizations with a small mobile workforce, yet large enterprises will exceed the capacity of a single computer.
  • the access arrangement also enables substantially parallel operations.
  • the message server can be run on a single computer or a set of parallel computers. Additional computers can be added simply, at any time.
  • a single logical database is used to hold the user-profile data and conventional database replication is employed to scale the capacity and performance as required.
  • the request servers can run alongside the database in small installations or can be distributed across a set of servers to meet the needs of the largest. Client applications may be added to meet the workload and response times required.
  • the access arrangement also enables 24-by-7 availability. By enabling inherent redundancy, access arrangement allows both scalability and system availability in the event of failure of any one component. Messages can be processed by any of the message servers. For example, should any request server or client application machine fail, others will be available to continue the service. If one fails while processing a request, a timeout will occur and the next request server will take over automatically.
  • the access arrangement may also be reliable. Reliability is a measure of the difference between expected system behavior and actual system behavior, including unexpected system input.
  • the access arrangement enables false messages to be rejected by for example, forward and reverse DNS lookup checking to ascertain whether the sender's IP address and domain match. Also, false message detection may be accomplished using modern techniques such as Sender Policy Framework (SPF) where valid sending IP addresses are listed in the domain DNS.
  • SPF Sender Policy Framework
  • DoS denial-of-service attacks
  • the access arrangement has special techniques to detect and respond to such attacks. Early identification of bad senders ensures that little computer resources (CPU time, memory, log files) are wasted and "tarpit" techniques are used to slow down multiple inputs from one place.
  • System monitoring and administration is also automated in order to keep costs low. When required, these monitoring and administration functions are available remotely using secure-Web access. Suitably authorized users can manage the access server (including the message server and the request server according to one or more embodiments) from any Web browser.
  • FIG. 1 shows a simplified block diagram of an application/information access arrangement in according to one or more embodiments of the present invention.
  • a user may operate a client device 102.
  • Client device 102 may represent a mobile device such as a mobile phone, mobile email device (e.g., Blackberry), PDA, or laptop computer.
  • Client device 102 may also represent a non-mobile computer.
  • a mobile phone, especially one of today's smart-phones, may be fast becoming the mobile device of choice.
  • Client device 102 connects to a simple request access server 106 (SRA server 106) through a network, such as wide area network 104, which may represent a combination of a wireless network and the Internet.
  • SRA server 106 may represent a proxy server.
  • SRA server 106 may include a message server [described below] and a request server [described below].
  • SRA messages are used to communicate the request much like a remote procedure call (RPC) mechanism that is used with client APIs.
  • RPC remote procedure call
  • the access arrangement may use human readable addresses and text for these messages. This substantially ensures access from all devices, since a simple messaging capability is all that may be required for security and authenticity.
  • SRA server 106 may maintain a user profile database 108 which is used for user authentication, request augmentation, and personalization, wherein information such as user preferences, default values, and credentials may be stored and encrypted.
  • a user profile database 108 which is used for user authentication, request augmentation, and personalization, wherein information such as user preferences, default values, and credentials may be stored and encrypted.
  • non- trusted requests like "Get a quote for Stock with Ticker Symbol XXX" or "Look up a phone number" do not require authentication.
  • Trusted request are verified against registered user list.
  • Highly trusted requests as previously described, usually require both verification against a registered user list, as well as a confirmation message or authentication token may initially be sent to the pre-arranged 'authentication address,' optionally with an additional PIN.
  • SRA server 106 may act upon it directly, it may connect over a WAN (wide area network) 111 (e.g., Internet, etc.) to publicly available internet servers 116a-b or it may pass the request on via LAN (local area network) 114 or a wireless network (not shown) to one or more application servers 120, which may in turn be coupled to a persistent data store, such as database 112.
  • WAN wide area network
  • application servers 120 may in turn be coupled to a persistent data store, such as database 112.
  • the SRA server will act upon behalf of the requestor and uses data from the user profile database to access private information over the Internet or login to a client application 110 on behalf of the user.
  • access to client application 110 is done through the user interface, as the user themselves would do.
  • SRA server 106 may intercept GUI (graphical user interface) based transactions (e.g., text, mouse movement and clicks, etc.) that would normally be used by client application 110 to interact with a human user.
  • GUI graphical user interface
  • the requesters profile contains user names and optionally, passwords for each request, ensuring that private information (e.g., user names, passwords, etc.) may not be sent over the public WAN 111.
  • the user profile database may be secured behind appropriate firewalls.
  • SRA server 106 may only have three or four ports open to the WAN (e.g. for one or more of SMTP SMTP, SMS, MMS, IM, XMPP, Web service, SOAP, XML, WAP, WML, HTTPS, HTTP, etc.) in order to maintain security.
  • the client application is part of a typical client/server enterprise application; the client connects over a local area network, probably inside the enterprise firewall, to the application servers and databases.
  • FIG. 2 shows a simplified block diagram illustrating an authentication mechanism processing a user request according to one or more embodiments of the invention.
  • Client device 102 may send a SRA message (a first user message) to get permission for the access or transaction at step 211.
  • SRA server 106 may use the name of the message sender to look up the user's profile in a database 108 at step 212. Part of the user's profile is the user's address used to get permission.
  • the address may be the client device 102. Alternatively or additionally, the address may represent a different device.
  • the different device and SRA server 106 may utilize the same messaging protocol or different messaging protocols.
  • SRA server 106 may then create an encrypted token and an associated temporary mailbox (temporary address, e.g., an email address, phone number, Web address or URL, or instant messaging address) using that token.
  • the system may then send an authentication request back to the user at step 213.
  • this mailbox address may never existed before and may expire in a few minutes, so an eavesdropper may not be able to learn about this beforehand and may have only a few minutes to try to crack the encrypted token.
  • the choice of token key length and short time-to-expire substantially ensures security.
  • Client device 102 may reply positively (in a second user message) to the authentication request (adding an additional identification information such as a PIN, personal identification number, for more secure requests) at step 214.
  • SRA server 106 may then pass the request on to the appropriate client application 110 at step 215.
  • Client application 110 may return results from client application 110 to the SRA server 106 at 216.
  • SRA server 106 may send the results to client device (and the user) at 217.
  • FIG. 3 shows a simplified block diagram illustrating the authentication mechanism of FIG. 2 processing a rogue request according to one or more embodiments of the invention.
  • a rogue client 302 may attempt to penetrate the access arrangement by sending a (fake) request to SRA server 106 with a forged "From:" address at step 311. SRA server 106 may then look up the address in database 108 for authentication. An encrypted token and a temporary mailbox may then be created.
  • the authentication request is forwarded to one of the trusted addresses of a genuine client 304 (genuine user 304) at step 313. That is, genuine user 304 may receive a spurious authentication request and sending address. Genuine user 304 may simply ignore it. Genuine user 304 may also reply negatively at 314, and subsequently receive a confirmation message from SRA server 106 indicating that client application 110 is protected at step 315. This negative reply may be used to identify and block rogue client 302 from further access. As previously described, the use of a set of trusted address allows SRA server 106 to operate as a spam-free message server, particularly when used with common internet protocols, such as SMTP, that can easily be forged.
  • SMTP common internet protocols
  • FIG. 4 shows a simplified block diagram illustrating scalability of the access arrangement according to one or more embodiments of the invention.
  • SRA server 106 shown in FIG. 1
  • message servers and request servers may be scaled up to meet arbitrary demands for performance and availability.
  • the scalability may be important not only to meet the needs of a large enterprise but also to deploy the right-sized system at the lowest cost with simple growth paths.
  • Message servers may distribute load with conventional IP-spraying techniques such as round-robin DNS or other load balance solutions or equipment, such as Local Director available from Cisco Systems, Inc. (www.cisco.com).
  • Database 108 may store message queues that may be designed for multiple-readers and writers accessing over a network at the same time, with the minimum of necessary locking. This ensures high performance with high reliability. Capacity can be expanded by storing different queues on different systems.
  • Request servers 404a-c may take messages from their designated message queues, process them in turn, and subsequently forward the messages to appropriate client applications, such as one or more of client applications 406a-b. As soon as one request is finished, the next message is processed, the load may be naturally distributed. Fewer request servers may offer a lower-cost system that may have higher latency in response times when the system is busy. More request servers 404a-c may keep latency to the minimum even when systems are busy, at additional cost. In addition, it may be easy to add request servers on-the- fly (in real time), so systems can be scaled to meet the processing and performance needs.
  • FIG. 5 shows a simplified block diagram illustrating a message protection mechanism according to one or more embodiments of the invention.
  • Incoming messages may be screened so that minimal computing resources are wasted on rogue or error messages.
  • the message protection mechanism may help to prevent Denial of Service (DoS) attacks as well.
  • DoS Denial of Service
  • the message protection mechanism may be implemented in a message server, such as SMTP server 402a.
  • the source addresses (e.g., IP addresses) of the incoming messages may be compared against blacklist 508 of known spam sources, and those messages shown on blacklist 508 are dropped immediately without even accepting the messages into the system.
  • several additional checks are made on the message protocol and header information for items that are often wrong in forged messages, such as no DNS MX record for the source IP address, no DNS entry for the source, etc., and those messages detected as forged messages are immediately rejected.
  • the access arrangement (or SMTP server 402a) may be configured to send 'bounce' messages back to the source - yet when the source is forged, the bounce message 'bounces' again. These double-bounce messages are generally errors (sometimes transient errors) so they are logged but processed no further.
  • These early checks may reduce the load on components in the access arrangement and help protect the components from DoS attacks. Each check may be enabled or disabled for every source address, for one or more specific IP addresses, or one or more ranges of IP addresses. The early checks may be especially important where organizations fail to set up message sending servers correctly (e.g. missing DNS entries, no reverse DNS, missing MX entries), yet the organizations are genuine message sources and need to be accepted. An administrator of the access arrangement may enable and/or disable checks dynamically. Additional spam filtering may also be utilized.
  • authentication messages from previously unknown users may be checked. If a message is addressed to a specific mailbox with an encrypted name and, if it is a valid response (within timeout, with PIN if required, etc.), that user is 'authenticated' and the user's profile is added/updated in database 108.
  • an "authenticated” confirmation message may be returned to the client device [not shown] of the user.
  • the particular details of who may be authenticated may vary from system to system.
  • a system open to the public may authenticate all users (unless blacklisted).
  • a private system might only allow users known in some other database/directory (e.g., LDAP, MS Active Directory, etc.) and may not need to utilize "authenticated” confirmation messages.
  • the message may be checked to see if the user is known (i.e., the source address of the message matches one in the user profile database) and if non-trusted access to this request is allowed. If the user is not known, control is transferred to logic 516; if the user is known or non-trusted access is allowed, control is transferred to logic 517.
  • an authentication (welcome) message may be generated (with an encrypted key) and returned to the user. If the source address is forged or and invalid, this authentication message might be queued, lost or will bounce, so the source address remains unknown.
  • the message/request may be parsed and dispatched for appropriate processing. Some requests may cause an immediate reply at logic 518, while others may be placed on a persistent queue 510, where they may be deferred for further action.
  • FIG. 6 illustrates application/information access types (request types) and request processing according to one or more embodiments of the current invention.
  • the request processing may be implemented in a request server, such as request server 404a shown in FIG. 4.
  • the request server may take the next request from a request queue 602 and process the request according to the type of the request.
  • the access arrangement may utilize rapid development techniques, usually in the form of simple scripts that match input and output parameters from the request message with the application interface. Complex requests may be built up from combinations of simple scripts. For example, "lookup product from UPC" and “get price quote for product” may be combined to create a new request “get price quote from UPC”. Note that the access arrangement may be configured to allow multiple request servers running in parallel. Parallel processing may be important for scaling systems to meet capacity requirements.
  • individual request servers may be specialized to handle specific requests which are important when special software or hardware installations are required.
  • a Type 611 request may represent a request for one or more modern Web services that require structured requests.
  • the request server may match the unstructured input parameters from the Type 611 request message and copy the unstructured input parameters into a structured XML document as defined by the WSDL (Web Service Definition Language) parameters.
  • Results from the XML document returned from the Web Service request may be extracted using the WSDL output parameters, formatted into text appropriately using XSLT, and put into the reply message for the user.
  • a script may be used for this parameter matching and formatting permitting rapid script development and simple maintenance.
  • a Type 612 request may represent a request for one or more IP services that accept unstructured or less structured requests such as fetching a Web page.
  • the request server may copy input parameters from the Type 612 request into an appropriate request (such as an HTTP GET or POST, for instance) and may also direct the extractions of returned results. Wherever possible, the HTML results are converted into XML, and the same structured extraction and formatting techniques of Type 611 may be used.
  • Type 612 scripts may be a little more complex than Type 611 scripts in order to deal with variations inherent in using less structured requests and replies. Nevertheless, the Type 612 scripts may be simpler than Type 3 requests (discussed below) and may still offer the benefits of the Rapid Development techniques.
  • a Type 613 request may represent a conventional way to access application data from a new application— write a new client program.
  • a program is written to take the input parameters from the request and pass them to the application using the API provided by vendor and then return the results. It is generally known that development and maintenance of new client programs may be substantially expensive, and so Type 613 requests may usually be avoided in the access arrangement. Nevertheless, they may be made available as and when required, for example, if Type 611 and Type 612 are not available.
  • a Type 4 request may represent a new, rapid-development approach to solve the problem of application access. It may use a novel "Visual API" using screen-scraping, cut and paste, and OCR techniques.
  • a script may direct the matching of input and output parameters to the input and output fields on the screens of an existing application.
  • the request server may paste the input parameters into the input fields and extracts output parameters as directed by the script.
  • Type 4 requests may be used to access existing and legacy applications without the need for expensive programming.
  • Type 4 requests may leverage browser based or terminal session applications including one or more of Citrix, VNC, MS Terminal Server, VTlOO, etc.
  • Type 4 scripts are generally simple, quick to write, and easy to maintain. ,
  • FIG. 7 shows a simplified block diagram illustrating a configuration of an access system 700 according to one or more embodiments of the invention.
  • the front end (facing communication network 790, e.g., the Internet) of access system 700 may comprise one or more computers, such as SMTP servers 702a-b, running message software (e.g., SMTP, etc.).
  • the one or more computers may run the firewall and may run Web servers for administration. A minimum of two servers may be preferred for continuous availability in the event of failure or during maintenance.
  • the back end may run database server 708 and/or RAID (redundant array of independent disks) file system 704.
  • RAID redundant array of independent disks
  • Large access systems may duplicate the database server 708 and replicate the associated database using conventional database techniques for high availability, such as RAID file system 704. Additional machines may be included as required to run the client applications. Some of these client applications may require access to the enterprise servers. The access may usually be done using a private network connection, or perhaps via a virtual private network (VPN), over the public internet.
  • VPN virtual private network
  • the front end and back end of the access system may run on a well-known operating system, such as Linux or Microsoft® Windows®, the Linux operating system, client application 110 may also run on a well-known operating system, such as Linux or Microsoft® Windows®, that may be the same as or different from the operating system that the front end and/or the back end of the access system runs on.
  • a well-known operating system such as Linux or Microsoft® Windows®
  • the Linux operating system client application 110 may also run on a well-known operating system, such as Linux or Microsoft® Windows®, that may be the same as or different from the operating system that the front end and/or the back end of the access system runs on.
  • FIG. 8 shows a simplified block diagram illustrating administration of an access system according to one or more embodiments of the invention.
  • One or more server functions of the access system may have remote administration built-in.
  • a secure network interface e.g., HTTPS, SSH, etc.
  • Web server administration applications 802a-b may be configured for managing a simple request access database, the message queues, system logs, blacklists, etc. stored, for example, in database server 708 and/or RAID file system 704.
  • client application 804 may also have integrated remote control functionality. Remote administration of these machines may be implemented, for example, utilizing a remote control client application or via the Web utilizing a remote control applet.
  • One or more of the message servers and request servers of the access system may run un-attended. For example, log file rollover may be automatic, and message queues may grow and shrink as required. When it is required, system monitoring and administration functions may be easily performed by any suitable authorized administrator from a Web browser or management console.
  • An access service provider may run a public access service which is open to the public and registered users.
  • An enterprise may also adopt an access system for providing application access to users of the enterprise, and the access system may be operated by the access service provider on behalf of the enterprise as a managed service.
  • the access system may be installed at a site of the enterprise and may be operated by the enterprise.
  • FIG. 9 shows a simplified block diagram illustrating the use of Web services with the access arrangement according to one or more embodiments of the invention.
  • a Web service may represent a standardized way of integrating applications into a SOA (services oriented architecture) utilizing one or more of XML, SOAP, WSDL and UDDI open standards over an Internet protocol backbone.
  • XML may be utilized to tag the data
  • SOAP may be utilized to transfer the data
  • WSDL may be utilized for describing the services available
  • UDDI may be utilized for listing what services are available.
  • Web services allow different applications from different sources to communicate with each other without time-consuming custom coding, and because all communication is in XML, Web services are not tied to any one operating system or programming language. For example, Java can talk with Perl, Windows applications can talk with UNIX applications, without special programming.
  • access server 906a-b may be represent one or more SRA servers, such as SRA server 106 shown in FIG. 1.
  • Access server 906a-b may allow users 902a-c to access Web services from Web service providers 908a-c.
  • access server 906a-b may be configured to translate incoming text messages from users 902a-c into the appropriate Web service protocol.
  • an access service such as access service 906b, may enable a user, such as user 902c, to access multiple Web services (or service providers), such as service providers 908a and 908c through one request.
  • Access server 906a-b may be configured to process a variety of input message types and protocols (SMTP, SMS, etc) from users 902a-c. Access server 906a-bmay also be configured to process XML messages in the form of Web Service calls from service providers 908a-c. Access server 906a-bmay also be configured to publish the availability of associated Web services (e.g., service providers 908a and 908c associated with access service 906b) in a standard way utilizing UDDI.
  • Web services e.g., service providers 908a and 908c associated with access service 906b
  • Fig. 9 shows multi-tier services where users 902a-c send a message to access server 906a-b, which in turn access one or more of service providers 908a-c.
  • the access arrangement may provide significant advantages for the both users 902a-c and service providers 908a-c, such as user profile caching.
  • user 902a may have registered with access server 906a, and necessary profile and preference information of user 902a may have been stored in a user profile database 108a.
  • Access server 906a can in turn access a Web service from service provider 908b, and subsequently transfer a copy of the profile of user 902a from user profile database 108a to service provider 908b and user profile database 910b.
  • the protocol between the access servers 906a-b may be secure and trusted. Once authenticated, the message may be passed securely (e.g. encrypted using SSL connections) to another server which can trust the user's authenticity.
  • user 902a may direct access server 906a to connect to a new service provider using a Web service protocol, and again transfer the profile of user 902a from user profile database 108a to the new service provider.
  • Benefits to the user include avoidance of re-entering the same registration information, as well as maintaining a single copy of a user's profile (i.e., names, preferences, passwords, etc.).
  • Benefits to the Web service provider include a simplified security interface in which to interact with users.
  • control point a single place where user's access can be monitored, managed and logged.
  • the control point might used for billing or reporting or auditing, for example.
  • FIG. 10 shows a flowchart of a method for executing an application utilizing the access arrangement according to one or more embodiments of the invention.
  • the method may be implemented for effecting the execution of an application function on an application server from a client device.
  • the client device may be coupled to a proxy server.
  • the proxy server may be coupled to the application server that executes an application implementing the application function.
  • a text message is received at a text message destination address at the proxy server from the client device.
  • the client device is coupled to the proxy server via a first network
  • proxy server is coupled to the application server via a second network.
  • the first network is one of a wide area network, and a wireless network.
  • the second network is one of a wide area network, a wireless network, and a local area network.
  • an authentication message is sent to a user (e.g., genuine client 304 shown in the example of FIG. 3 or client device 102 shown in the example of FIG. 2) at a text message confirmation address that is different from the text message origination address (e.g., rogue client 302 shown in FIG. 3).
  • the authentication message is transmitted to the user using a first protocol that is different from a second protocol employed to transmit the text message from the user.
  • the first protocol and the second protocol includes at least one of SMTP, SMS, MMS 5 IM, Web service, SOAP, XML, HTTPS, and HTTP.
  • the text message confirmation address represents a non-persistent text message address that is configured to be inactivated after said authenticating.
  • the text message destination address is stored in a messaging address book on the client device.
  • FIG. 11 shows a simplified block diagram of an SRA server 106, e.g., SRA server 106, according to one or more embodiments of the invention.
  • client device 102 such as a mobile device (i.e., mobile phone, Blackberry, or PDA), laptop computer, or non-mobile computer.
  • SRA server 106 may connect to client devices 102 over a wide area network 104 (e.g., wireless network, Internet, etc.) to a set of applications and services 1124a-d.
  • SRA server 106 may include a set of logical modules, as discussed below.
  • Service guard module 1104 may protect SRA server 106 from intrusion and denial-of- service attack from hostile devices on wide area network 104.
  • An intrusion may represent a set of actions that attempt to compromise the integrity, confidentiality, or availability of a residing resource on or coupled to SRA server 106.
  • a denial-of-service attack may represent a type of attack designed to substantially incapacitate SRA server 106 by flooding it with useless traffic.
  • service guard module 1104 may function as a firewall for preventing unauthorized access to or from wide area network 104, to (and from) SRA server 106. All messages to or from client devices 102 are generally filtered by service guard module 1104. For example, service guard module 1104 may use a packet filtering technique, in which each packet entering or leaving the wide area network 104 is accepted or rejected based on a set of defined rules. In addition, service guard module 1104 may further include sub-modules, such as email guard 1104a, SMS guard 1104b, IM guard 1104c, HTML guard 1104d. Email guard 1104a may be configured to protect SRA server 106 from electronic mail. In general, because email allows a message to be broadcast to a large group or recipients at once, email messages are often used to transport viruses between computers, commonly as "attachment" to the message that contains a malicious program which executes when opened.
  • SMS guard 1104b may be configured to protect SRA server 106 from potentially hostile SMS messages.
  • SMS or short message service, allows short text messages to be sent to mobile phones, fax machines, and/or IP addresses.
  • short messages may be no longer than 160 alpha-numerical characters and contain no images or graphics.
  • IM guard 1104c may be configured to protect against IM messages.
  • IM or instant message, is a type of communications service that enables substantially real time communication over the Internet.
  • HTML guard 1104d may be configured to protect against message containing HTML code.
  • HTML or HyperText Markup Language, is commonly an authoring language used to create documents on the World Wide Web. HTML generally defines the structure and layout of a Web document by using a variety of tags and attributes.
  • Service guard module 1104 may be coupled to request parser module 1106.
  • Request parser module 1106 may include email parser 1106a, SMS parser 1106b, IM parser 1106c, and HTML parser 1106d to parse email, SMS, IM, and HTML messages, respectively.
  • request parser module 1106 may divide the text of a request from client device 102 into small components that can be analyzed.
  • a request may be structured in the format instruction— variable@server.com, where instruction may represent the request to be executed by SRA server 106, such as the location of nearest restaurant, the current weather, or the transfer of funds; variable may represent additional information , such as a location, name, account number, encrypted tokens as previously described, etc.; and server.com is the name of the particular SRA server 106 upon which the user wishes to execute the instruction. Parsing may be divided into lexical analysis and semantic parsing. Lexical analysis may concentrate on dividing strings into components, called tokens, based on punctuation and other keys. Semantic parsing may then attempt to determine the meaning of the string or instruction.
  • Access control manager module 1108 may be coupled to request parser module 1106, and may control the mechanisms and policies that restrict access to computer resources on SRA server 106 (and/or applications and services 1124a-d).
  • an ACL, or access control list may be used.
  • An ACL may represent a set of data that informs the SRA server 106 which permissions, or access rights, that each user or group has to a specific system object, such as one or more of applications and services 1124a-d.
  • Each object may have a unique security attribute that identifies which users have access to it, and the ACL may represent a list of each object and user access privileges (such as read, write, or execute).
  • Request action bus module 1110 may couple access control manager module 1108 to service connector module 1112. Once users are authenticated by access control manager module 1108, user requests may be queued in request action bus module 1110, where they may be pulled off by service connector module 1112, based on scripts in service scripts modulel 132, when the appropriate application(s) or service(s), for example, one or more of applications and services 1124, becomes available.
  • a script may represent a macro or batch file with a list of SRA server 106 commands that can be executed without user interaction.
  • a particular script language may be employed to write scripts for service scripts 1132.
  • the order in which SRA server 106 executes user requests on request action bus module 1110 may be the same order that they were placed on the queue. In one or more embodiments, some user requests may be given higher priority than others.
  • Inbound messages from a user may be augmented with user profile information, such as one or more of credentials, preferences, default values, trusted reply path, reply protocol, response formatting, authentication method required, etc. This may allow concise requests to minimize user typing yet provides rich data for the processing which may perform complex operations. This method avoids the need to send credentials over the network or even to put the credentials at risk to malicious software or the sending device.
  • Service connector module 1112 may include a set of connectors and/or adapters for connecting to applications and services 1124a-d.
  • WSDL connector 1112a may enable SRA server 106 to connect to one or more of Web services 1124a.
  • WSDL is generally an XML-formatted language used to describe a Web service's capabilities as collections of communication endpoints capable of exchanging messages.
  • WSDL connector 1112a may connect to a UDDI directory.
  • UDDI or universal description, discovery and integration, is generally a Web-based distributed directory that enables businesses to list themselves on the Internet and discover each other, similar to a traditional phone book's yellow and white pages.
  • HTML connector 1112b may enable SRA server 106 to connect to one or more of Web applications 1124b. As previously described, HTML is commonly an authoring language used to create documents on the World Wide Web. HTML connector 1112b may allow portions of previously created Web pages to be extracted and delivered to client devices 102.
  • UI connector 1112c may enable SRA server 106 to connect to one or more of client applications 1124c through a UI, or user interface.
  • the UI may represent an interface with a set of commands or menus through which a human user communicates with a program.
  • UI connector 1112c may be configured to mimic a human user, automatically querying and extracting relevant information from remote user applications, such as a CDROM encyclopedia or map program.
  • API connector 1112d may enable SRA server 106 to connect to one or more of application servers 1124d.
  • API, or application program interface may represent a set of routines, protocols, and tools for building software applications.
  • An app server, or application server is generally a program that handles application operations between users and backend applications or databases. App servers are typically used for complex transaction-based applications.
  • API connector 1112d may connect SRA server 106 to a SAP application server, allowing a user to query customer order status from client device 102.
  • Service admin module 1114 may enable a SRA server 106 administrator to securely manage a collection of networks, computers, and databases.
  • Profile management module 1116 may enable SRA server 106 to maintain a set of service and resource profiles for each user. For example, a user may desire requests to be customized depending on the type client device 102 through which the request is made.
  • Service provisioning module 1118 may enable a SRA server 106 administrator to provide users with access to one or more of services and applications 1124a-d.
  • provisioning comprises allowing a particular user access to one or more particular services and/or applications, based on user identity and a particular profile stored in profile management module 1116.
  • Service monitoring module 1120 may enable a SRA server 106 administrator to create an inventory of all the hardware and software on the network and to perform diagnostic tests.
  • Usage reporting module 1122 may monitor and report resource utilization within SRA server 106, as well as user access to services and applications 1124.
  • transaction state may be maintained through the use of temporal mailboxes.
  • transaction state is often maintained through the use of browser cookies.
  • a cookie is typically a small message given to a Web browser by a Web server. The browser stores the message in a text file, and sends the message back to the server each time the browser requests a page from the server.
  • cookies may provide a rudimentary form of transaction security. That is, the particular browser that begins the transaction (i.e., a user purchasing a book from Amazon.com) should be the same browser that completes the transaction.
  • mobile device applications are generally optimized for communication and not transactions. That is, although mobile devices are fairly good at sending and receiving voice and text messages, such as email and SMS, the physical size and computational capabilities of many mobile devices may make them less effective as a user interface to Internet applications, such as Web servers. Subsequently, there is generally no equivalent to a cookie for maintaining transaction state in mobile device messaging applications.
  • a service mailbox (service address) may be used as a substitute for a cookie in order to maintain transaction state, in one or more embodiments. That is, instead of locally storing a cookie, the client device is granted a set of unique return address or service mailbox es.
  • a response to a specific service mailbox signals a particular change in state for a particular client device to the SRA server 106. For example, for a transaction that may involve multiple requests, such as selecting a path through a menu tree, responding to a particular service mailbox corresponds to a specific menu choice, which may cause the next level of choices to be transmitted to the client device.
  • a menu may include authentication queries in one or more embodiments.
  • Service mailboxes are used in messages as simple links to click.
  • the state information associated with the particular service mailbox conveys all the necessary navigation and transaction information. Using service mailboxes in the manner makes the messaging system as easy to use as the Web.
  • a user may wish to access a SAP application through a SRA server 106, in order to view the total amount of the most recent order for a particular customer.
  • the user may be able to send a first text message to a particular email address at the SRA server 106, which subsequently instructs the SRA server 106 to communicate with the SAP application, based on previously defined profile information and scripts.
  • the server address (service address) may be entered as cm-SAP @server.com, with a subject of name-customername, where customername is the name of the particular customer of interest, and server.com is the name of the particular SRA server 106 upon which the user wishes to execute the instruction.
  • the SRA server 106 would then return a text message to the client device with a simplified menu in the body of the message:
  • Each menu item includes service identification information, such as SAP-10000, SAP- 20000, SAP-30000, etc.
  • service identification information such as SAP-10000, SAP- 20000, SAP-30000, etc.
  • Sending a text message to cm-SAP-44000 @server.com, will instruct the SRA server 106 to transmit the total amount of the last order for customer customername.
  • service mailbox name may be encrypted for added security. Since the user can click the link and does not need to type the address, a long encrypted key can be used if such is desired.
  • two-factor authentication may be used with the access arrangement.
  • highly trusted requests may require the sender to confirm the transaction, such as with a confirmation message or authentication token.
  • an intruder may intercept the confirmation message or authentication token and correctly respond, causing the SRA server 106 to believe that the real user has properly confirmed the transaction.
  • at least two communication channels may be used, a primary transaction channel and a secondary confirmation channel.
  • a bank may have an access server coupled to an ATM machine for authentication purposes.
  • a customer wanting to withdraw above a fixed amount from an ATM i.e., > $300
  • a SMS message with one-time identification information such as a particular OTP (one time PIN)
  • the user's client device i.e., mobile phone, PDA, etc.
  • a short period of time e.g., three minutes after the OTP is sent
  • a customer using a browser and wanting to transfer money from the bank's Website to a third-party account would receive the SMS message with an OTP that would need to be entered into the browser window.
  • the ATM machine or bank Website generates an authentication code (e.g., a security serial number, alphabetical code, or alphanumeric code) that must be transmitted from the client device to the access server via SMS or email, before the transaction is authorized.
  • the authentication code (e.g., a security serial number, alphabetical code, or alphanumeric code) may be generated by a smart card, such as a RSA SecurID Authenticator device, utilizing a key (or seed) provided, for example, by the access server.
  • the authentication code may then be displayed to the user (or a second entity, such as the user's supervisor), and the user (or the second entity) may need to enter the authentication code and send the authentication code to the access server for authentication.
  • the content of the authentication code may be changed (or regenerated) periodically, e.g., every 60 seconds, by the smart card. A correct authentication code for a certain time needs to be sent to the access server so that the user may be authenticated.
  • the smart card may represent a small electronic device about the size of a credit card that contains electronic memory, and possibly an embedded integrated circuit (IC). Smart cards containing an IC are sometimes called Integrated Circuit Cards (ICCs).
  • ICCs Integrated Circuit Cards
  • a message may be received on the client device requesting the then current token.
  • the confirmation message is sent to a user other than the user who is making the access server request. For example, before an employee can transfer or withdraw funds, a confirmation message is sent to the employee's supervisor for authorization.
  • an access arrangement can use a mobile device SIM for transaction authorization.
  • a SIM Short for subscriber identity module, a SIM is generally, a removable smart card inside of a GSM cellular phone that encrypts voice and data transmissions and stores data about the specific user so that the user can be identified and authenticated to the network supplying the phone service.
  • the SIM also stores data such as personal phone settings specific to the user and phone numbers.
  • a SIM can be moved from one phone to another and/or different SIMs can be inserted into any GSM phone. Since identity information on each SIM is generally unique, a transaction may be securely authorized by first transmitting a confirmation message to the mobile device, encrypting the confirmation message with the SIM card, and returning the confirmation (or a cryptographic hash of the confirmation) to the access server.
  • an access server may provide single signon functionality.
  • An authentication process in a client/server relationship, single signon allows the user, or client, to enter one name and password and have access to more than one application or access to a number of resources within an enterprise.
  • Single signon generally reduces the need for the user to enter further authentications when switching from one application to another.
  • an access server may connect with client devices that are enabled with XForms, a W3C standard.
  • XForms enabled applications may allow a set of forms to be processed locally and then subsequently transmitted to a Web server as an XML document.
  • XForms enabled applications may be customized for different user interfaces, such as mobile phones, handheld devices, and Braille readers for the blind.
  • an access sever may communicate with a RFID-enabled mobile device.
  • an RFID system generally consists of an antenna and a transceiver, which radiates the radio frequency and transfer the information to a processing device, and a transponder, or tag, which is an integrated circuit containing the RF circuitry and information to be transmitted.
  • RFID eliminates the need for line-of-sight reading and can be done at greater distances. There is significant advantage for the user who would otherwise have to type the information. There may be also significant advantage for the mobile RFID device; it needs to communicate with some server, and access arrangement according to one or more embodiments of the present invention may offer a simple, low cost and effective solution to this problem.
  • an RFID-enabled mobile device may first read RFID information on or in each medicine container. This RFID information is then be transmitted to the access server which, in turn, queries a drug interaction database service. The access server may then send the specific drug interaction information as a reply to the mobile device as a customized text message.
  • an access sever may communicate with a GPS-enabled mobile device.
  • GPS is generally a worldwide satellite navigational system formed by 24 satellites orbiting the earth and their corresponding receivers on the earth. The GPS satellites continuously transmit digital radio signals that contain data on the satellites location and the exact time to the earth-bound receivers.
  • GPS can calculate the longitude and latitude of the receiver based on where the three spheres intersect.
  • GPS can also determine altitude. For example, if a user wants location specific information, such as the location of a restaurant, the user's current location may be automatically transmitted to the access server by the GPS-enabled mobile device, instead of manually entered by the user. The access server may then respond with a text message including directions to the desired address from the current address. As with the mobile RFID reader, this may represent a significant advantage to the user, who does not to enter the location information manually, which tends to be tedious and error prone.
  • address book entries in the mobile device may be used for command syntax help and/or hints.
  • a user can query an access server for a general help menu by sending a message to a help address, such as crnhelp@server.com , where cmhelp is the particular help request, and server.com is the name of the particular access server at which the user wishes to execute the help instruction.
  • a help address such as crnhelp@server.com
  • cmhelp is the particular help request
  • server.com is the name of the particular access server at which the user wishes to execute the help instruction.
  • the following simplified general help menu may be returned as the body of a text message: mailto:cmCurrency@server.com
  • More specific help can be obtained, for example, by sending a particular request with the word "Help" in the subject.
  • a set of abbreviations may be used in order to reduce the amount of user typing.
  • a user can query an access server for a set of abbreviations by sending a message to cmkeyget@server.com , where cmkeyget is the abbreviation or key request, and server.com is the name of the particular access server at which the user wishes to execute the help instruction.
  • cmkeyget is the abbreviation or key request
  • server.com is the name of the particular access server at which the user wishes to execute the help instruction.
  • the following simplified general help menu may be returned as the body of a text message:
  • a user can then modify existing keys, or add new ones, and then transmit the text to cmkey@server. com. Subsequently, the user can request directions from his home to the San Francisco Airport by sending a text message to cmdirection:HOME:SFO@server.com.
  • the key of LOCN may be assumed to be the default key for requests that involve location, when a required key is missing.
  • the user's present location if known (i.e., by a GPS-enabled user device, previously entered by the user, etc.) may be assumed to be the current location key for requests that involve location. For example, sending a message to cmstarbucks@server.cotn , with no subject, will generally cause the access server to return directions to the nearest Starbucks from what it believes is the user's current location.
  • Advantages of the invention include architecture for general purpose trusted personal access system and methods therefore. Additional advantages include a hosted access infrastructure for managed enterprise access to both internal and external sources, a manageable infrastructure for directed transactional access to applications and Web services, and enhanced productivity and lower total cost of ownership (TCO).
  • TCO total cost of ownership

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)
  • Communication Control (AREA)
  • Telephonic Communication Services (AREA)

Abstract

L'invention concerne une méthode pour exécuter une fonction d'application sur un serveur d'application, à partir d'un dispositif client, par l'intermédiaire d'un serveur mandataire. Cette méthode consiste à transmettre, au serveur mandataire, un premier message textuel concernant une demande d'exécution de la fonction d'application. Cette méthode consiste également à authentifier un utilisateur associé avec le premier message textuel, par l'authentification de cet utilisateur, à l'aide d'une adresse de confirmation qui est différente de l'adresse d'origine du message textuel. Après l'authentification, la méthode consiste également à exécuter la fonction d'application, au niveau du serveur d'application, comme spécifié par le premier message textuel, la première fonction d'application étant déterminée au moins en fonction de l'adresse de destination du message textuel.
PCT/US2006/044261 2005-11-15 2006-11-14 Methode d'acces a une application faisant appel a un code d'authentification genere par un client WO2007059169A2 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP06837611A EP1955183A2 (fr) 2005-11-15 2006-11-14 Methode d'acces a une application faisant appel a un code d'authentification genere par un client
JP2008541294A JP2009516305A (ja) 2005-11-15 2006-11-14 クライアントによって発生される認証コードを用いるアプリケーションアクセス
CA002627530A CA2627530A1 (fr) 2005-11-15 2006-11-14 Methode d'acces a une application faisant appel a un code d'authentification genere par un client

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US11/280,140 2005-11-15
US11/280,140 US7844674B2 (en) 2004-12-03 2005-11-15 Architecture for general purpose trusted personal access system and methods therefor
US11/422,317 US7870201B2 (en) 2004-12-03 2006-06-05 Apparatus for executing an application function using a mail link and methods therefor
US11/422,317 2006-06-05
US11/422,318 2006-06-05
US11/422,318 US7870202B2 (en) 2004-12-03 2006-06-05 Apparatus for executing an application function using a smart card and methods therefor

Publications (2)

Publication Number Publication Date
WO2007059169A2 true WO2007059169A2 (fr) 2007-05-24
WO2007059169A3 WO2007059169A3 (fr) 2009-04-30

Family

ID=38049255

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/US2006/044284 WO2007059183A2 (fr) 2005-11-15 2006-11-14 Acces a une application au moyen d'une liaison de message
PCT/US2006/044261 WO2007059169A2 (fr) 2005-11-15 2006-11-14 Methode d'acces a une application faisant appel a un code d'authentification genere par un client

Family Applications Before (1)

Application Number Title Priority Date Filing Date
PCT/US2006/044284 WO2007059183A2 (fr) 2005-11-15 2006-11-14 Acces a une application au moyen d'une liaison de message

Country Status (4)

Country Link
EP (2) EP1955183A2 (fr)
JP (2) JP2009516306A (fr)
CA (2) CA2627530A1 (fr)
WO (2) WO2007059183A2 (fr)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7711359B2 (en) 1998-10-02 2010-05-04 Telespree Communications Portable cellular phone system having automatic initialization
WO2014152076A1 (fr) * 2013-03-15 2014-09-25 Microsoft Corporation File d'attente de communication synchronisée inter-plateformes à capacité de relance et de copie instantanée
EP2120490A3 (fr) * 2008-05-13 2014-11-12 Sony Corporation Dispositif de communication, procédé de communication, système de communication et procédé d'émission du service
EP2165488A4 (fr) * 2007-06-05 2015-08-26 Secure Mailbox Sweden Ab Canal d'information direct et sécurisé
US9906499B1 (en) 2013-09-11 2018-02-27 Talati Family LP Apparatus, system and method for secure data exchange
CN111984958A (zh) * 2020-08-06 2020-11-24 成都安恒信息技术有限公司 一种支持vnc双因子的认证方法
US10861090B2 (en) 2013-11-27 2020-12-08 Apple Inc. Provisioning of credentials on an electronic device using passwords communicated over verified channels
US20230084273A1 (en) * 2015-06-15 2023-03-16 Adidas Ag Systems and Techniques for Computer-Enabled Geo-Targeted Product Reservation for Secure and Authenticated Online Reservations

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4902633B2 (ja) * 2008-12-17 2012-03-21 日本電信電話株式会社 Ｗｅｂシステムおよびリクエスト処理方法
US20120110011A1 (en) * 2010-10-29 2012-05-03 Ihc Intellectual Asset Management, Llc Managing application access on a computing device
GB2499360B8 (en) * 2011-10-12 2016-01-27 Technology Business Man Ltd Secure ID authentication
CN103209198B (zh) * 2012-01-13 2016-06-15 深圳市腾讯计算机系统有限公司 一种网络应用之间的切换方法和系统
JP2013205604A (ja) * 2012-03-28 2013-10-07 Toshiba Corp 通信装置および鍵管理方法
JP5853890B2 (ja) * 2012-07-25 2016-02-09 カシオ計算機株式会社 ソフトウェア実行制御装置、実行制御方法、及び実行制御プログラム
AU2014264204B2 (en) * 2013-05-10 2019-04-18 Truteq International (Pty) Ltd A method and system for communicating banking-related security messages
JP6753728B2 (ja) * 2016-08-23 2020-09-09 Ｌｉｎｅ株式会社 プログラム、情報処理方法、及び端末
JP6560649B2 (ja) * 2016-09-30 2019-08-14 Kddi株式会社 認証サーバ、端末装置、システム、認証方法、及びプログラム
JP7223196B1 (ja) 2022-03-07 2023-02-15 ＰａｙＰａｙ株式会社 情報処理装置、情報処理方法、およびプログラム
US20230319017A1 (en) * 2022-03-30 2023-10-05 Seclore Technology Pvt Ltd. System and method for automatic document protection using information rights management

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6490627B1 (en) * 1996-12-17 2002-12-03 Oracle Corporation Method and apparatus that provides a scalable media delivery system
US20040255329A1 (en) * 2003-03-31 2004-12-16 Matthew Compton Video processing

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6292833B1 (en) * 1998-07-17 2001-09-18 Openwave Systems Inc. Method and apparatus for providing access control to local services of mobile devices
GB2346766A (en) * 1999-02-12 2000-08-16 Nokia Mobile Phones Ltd Routing messages between a client and a selected server
US20040193694A1 (en) * 1999-11-10 2004-09-30 Randy Salo Application gateway systems
US6938087B1 (en) * 2000-09-12 2005-08-30 Hewlett-Packard Development Company, L.P. Distributed universal communication module for facilitating delivery of network services to one or more devices communicating over multiple transport facilities
US7631084B2 (en) * 2001-11-02 2009-12-08 Juniper Networks, Inc. Method and system for providing secure access to private networks with client redirection
GB0204589D0 (en) * 2002-02-27 2002-04-10 Gordano Ltd Filtering E-mail messages
US8032592B2 (en) * 2002-04-18 2011-10-04 Intuit Inc. System and method for data collection and update utilizing surrogate e-mail addresses using a server

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6490627B1 (en) * 1996-12-17 2002-12-03 Oracle Corporation Method and apparatus that provides a scalable media delivery system
US20040255329A1 (en) * 2003-03-31 2004-12-16 Matthew Compton Video processing

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7711359B2 (en) 1998-10-02 2010-05-04 Telespree Communications Portable cellular phone system having automatic initialization
US7869800B2 (en) 1998-10-02 2011-01-11 Telespree Communications Portable cellular phone system having automatic initialization
EP2165488A4 (fr) * 2007-06-05 2015-08-26 Secure Mailbox Sweden Ab Canal d'information direct et sécurisé
EP2120490A3 (fr) * 2008-05-13 2014-11-12 Sony Corporation Dispositif de communication, procédé de communication, système de communication et procédé d'émission du service
WO2014152076A1 (fr) * 2013-03-15 2014-09-25 Microsoft Corporation File d'attente de communication synchronisée inter-plateformes à capacité de relance et de copie instantanée
US9264414B2 (en) 2013-03-15 2016-02-16 Microsoft Technology Licensing, Llc Retry and snapshot enabled cross-platform synchronized communication queue
US9906499B1 (en) 2013-09-11 2018-02-27 Talati Family LP Apparatus, system and method for secure data exchange
US10861090B2 (en) 2013-11-27 2020-12-08 Apple Inc. Provisioning of credentials on an electronic device using passwords communicated over verified channels
US20230084273A1 (en) * 2015-06-15 2023-03-16 Adidas Ag Systems and Techniques for Computer-Enabled Geo-Targeted Product Reservation for Secure and Authenticated Online Reservations
US11961129B2 (en) * 2015-06-15 2024-04-16 Adidas Ag Systems and techniques for computer-enabled geo-targeted product reservation for secure and authenticated online reservations
CN111984958A (zh) * 2020-08-06 2020-11-24 成都安恒信息技术有限公司 一种支持vnc双因子的认证方法
CN111984958B (zh) * 2020-08-06 2024-02-02 成都安恒信息技术有限公司 一种支持vnc双因子的认证方法

Also Published As

Publication number Publication date
CA2627534A1 (fr) 2007-05-24
WO2007059183A3 (fr) 2009-04-30
JP2009516305A (ja) 2009-04-16
JP2009516306A (ja) 2009-04-16
WO2007059169A3 (fr) 2009-04-30
CA2627530A1 (fr) 2007-05-24
EP1955184A2 (fr) 2008-08-13
EP1955183A2 (fr) 2008-08-13
WO2007059183A2 (fr) 2007-05-24

Similar Documents

Publication Publication Date Title
US7870201B2 (en) Apparatus for executing an application function using a mail link and methods therefor
US7870202B2 (en) Apparatus for executing an application function using a smart card and methods therefor
US7844674B2 (en) Architecture for general purpose trusted personal access system and methods therefor
WO2007059169A2 (fr) Methode d'acces a une application faisant appel a un code d'authentification genere par un client
US10084791B2 (en) Evaluating a questionable network communication
US9015090B2 (en) Evaluating a questionable network communication
US9674145B2 (en) Evaluating a questionable network communication
US9912677B2 (en) Evaluating a questionable network communication
EP2375688B1 (fr) Gestion de la connexion automatique de ressources cibles sur Internet
US8122251B2 (en) Method and apparatus for preventing phishing attacks
US8621604B2 (en) Evaluating a questionable network communication
US8019995B2 (en) Method and apparatus for preventing internet phishing attacks
US8775524B2 (en) Obtaining and assessing objective data ralating to network resources
US10846432B2 (en) Secure data leak detection
EP3033865A1 (fr) Évaluation d'une communication réseau douteuse
US11165768B2 (en) Technique for connecting to a service
WO2023166336A1 (fr) Système et procédé pour empêcher une attaque sur une interface de programmation d'application
Perišić Web Services Security: an Overview
Pendlimarri et al. Ancillary Resistor leads to Sparse Glitches: an Extra Approach to Avert Hacker using Syndicate Browser Design

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
ENP Entry into the national phase

Ref document number: 2627530

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 2008541294

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2006837611

Country of ref document: EP