Patent Application
20100223462
The present invention relates to data communication systems, and in particular the access and use of files and services residing on a local network computer system from remote computers, Personal Digital Assistants (PDA) or mobile phones.
Nowadays, more and more households are acquiring broadband Internet connections to their home. On the home local network they may have several computers running various services and hosting private documents and files. It is hence quite desirable to be able to access these services and files from outside their home via stationary computers is or mobile devices like cellular phone or PDA.
Unfortunately, to be connected to the Internet does not bring only advantages but also drawbacks. The user home networks as other networks connected to the Internet are exposed to fraudulent attacks and misuses. For protection against frauds and intrusions, more and more users are installing firewalls. While protecting the user home network, the firewalls may also prevent the legitimate users to access their files and services located on the user home network.
In order to establish a secure connection to a local network from outside, solutions such as Virtual Private Networks (VPN) can be used. The firewall of the local network is configured to also operate as a VPN server, and the mobile device could be used as a VPN client to connect to this VPN server. Having connected to this server, the mobile device becomes part of the local network that resides behind the firewall/VPN server. This Virtual Network (realised with an encrypted tunnel) will allow traffic of any service to flow back and forth between the local network and the mobile device.
The VPN solution has, however, many limitations. The VPN solution requires high resource consumption in terms of processing power and network bandwidth, which is usually not available in mobile devices and wireless networks.
Another drawback is that it takes times to start up a VPN and it does time out when there is no activity. This is not convenient for the mobile user that sporadically accesses his home network.
These limitations call for a simplified solution which can adapt to both user's technical skills and the resource constraints in networks and devices.
The present invention provides a solution for accessing services and files residing on a computer in a local network from stationary or mobile devices outside said local network without compromising security.
The invention requires only minimal technical skills to take into use. All that is needed is to download and install an application on the computer where services reside (in the home network), as well as to download and install a client on the device in use.
In addition, the invention allows several (all) computers on the local network to provide services, thus every person having their own computer can access their own personal services from their mobile device.
The scope of the invention appears from the appended patent claims.
In particular, the present invention relates to a method for providing access to services and files on a computer in a local network from a stationary or mobile device outside said local network. Said local network is equipped with a networked file system, and said stationary or mobile device is able to communicate with said local network over a wide area network. For any networked file system message that is to be transmitted over said wide area network, at least some fields of said networked file system message are mapped into corresponding fields in an XML message representing said networked system message. Any XML message that is received over said wide area network, said XML message is parsed, and if said XML message represents a networked file system message, a networked file system message is reconstructed by mapping each field of said XML message into a corresponding field of said reconstructed networked file message.
The invention also relates to a device for providing access to services and files on a computer in a local network, from a stationary or mobile device outside said local network. Said local network is equipped with a networked file system, and said stationary or mobile device is connected to said local network over a wide area network. Said device is adapted to map at least some fields of a networked file system message to be transmitted over said wide area network into corresponding fields in an XML message representing said networked file system message. Said device is further adapted to parse a XML message received over said wide area network, and if said XML message represents a networked file system message to reconstruct a networked file system message by mapping each field of said XML message into a corresponding field of said reconstructed networked file message.
The invention will now be described in detail in reference to the appended drawings, in which:
The solution according to the present invention will allow access to any files or services residing on computers 4 on a LAN 1 behind a firewall 3, typically a private Local Area Network (LAN). The solution as shown
Based on the nature of the local network IP address, there are four different configurations:
Case 1: Local Network using Permanent Global IP Address
In this case, the Mobile Access to local network solution does require only two components:
The Home Access Web Service client 7 interacts with the Home Access Local Web Service 5 to allow the user to access his files and services on his local network.
Case 2: Local Network using Dynamic Global IP Address
In this case, the Mobile Home Access requires all the three components:
The Home Access Local Web Service 5, in addition to the functions as described in case 1 must be equipped with the following functions:
As shown in
Case 3: Local Network using Permanent Local IP Address
In this case, illustrated in
To access a file or a service located on his local network 1, the user issues a command to the Home Access Web Service Client 7. The Client 7 will invoke the appropriate method on the Home Access Global Web Service 6, which has a permanent URI. Some of the input parameters should be subscriber id and password.
Upon successful authentication, the Home Access Global Web Service 6 will invoke appropriate methods on the Home Access Local Web Service 5 residing on the user's local network 1. It is worth noting that the Home Access Global Web Service 6 must know the local network's IP address and use it to invoke methods on the Home Access Local Web Service 5. The approach for acquiring the Home Access Local Web Service IP address is the same as previously described in case 2.
Case 4: Local Network using Dynamic Local IP Address
In this case, also illustrated by the
Functionality of the Components
Home Access Local Web Service
The role of the Home Access Local WS 5 is to expose the relevant operations of the native file system on the World Wide Web such a mobile client 8, 9 can use them to access files and services located within the local network 1.
As shown in
In addition to the file access functionality the Home Access Local Web Service 5 has also the functionality to periodically query the IP address of the local network 1 and uploads it to the Home Access Global Web Service 6 or a defined globally accessible storage area.
The Native File Interface
At the local network, there could be several users sharing several heterogeneous computers and peripheral devices. It is assumed that the local network is equipped with a networked file system that allows the users to view and to access remote files located on other computers from one computer. Examples of such a networked file system can be Sun Network File System (NFS) [1] [2] or Common Internet File System (CIFS) [3]. However, only CIFS will be considered further since it is incorporated in Microsoft Windows that are installed in most private households.
CIFS is a file sharing protocol. Client systems use this protocol to request file access services from server systems over a network. It is based on the Server Message Block (SMB) protocol widely in use by personal computers and workstations running a wide variety of operating systems.
The protocol supports the following features:
Although CIFS is independent of the transport layer, the common transports today across this interface is through NBT (NetBIOS over TCP) or across raw TCP connections.
Raw TCP Transport
This mode of operation is the simplest, where SMB messages can be sent immediately to port 445 on the server. Based on the response to a TCP connection request to this port, and possibly a reply to the SMB message, either RAW transport can used further or an NBT session can be initiated as described below.
NBT Transport
In this mode, additional messages must be sent to gain access to the file server and to initiate a session. Also, a valid NetBIOS name of the file server is needed in the message that requests a new session. The need for NBT support completely relies on the servers that should be supported and whether these are expecting correct NBT semantics.
The Web Service File Interface
Since the goal is to enable file and service access from outside devices, especially mobile phones, which have several limitations, the requirements on the Web Service Interface are as follows:
To cope with these requirements the Web Service File Interface consists of the following sub-interfaces:
Before allowing access to home files and services, it is important that the identification, authentication and authorisation are carried out properly. The Web Service File Interface must have an Authentication Interface.
The Tunnelling Interface is more suitable for access from remote personal computer, which has a CIFS client installed. The Reduced Mapping Interface is intended formobile devices with limited capabilities.
Authentication Interface
This interface controls identification, authentication and authorization to shared resources.
IAUTHMustAuthenticate(Challenge)—This method is used to notify the client that it is required to authenticate itself prior to accessing any resources through the service access point. This method can be used as a response to any type of request from an unauthenticated client.
IAUTHAuthenticateReguest(Credentials)—This method is used by the client to request authentication by providing proper credentials.
IAUTHAuthenticateResponse( )—This method is used by the service access point to notify the client about the outcome of the authentication process.
The Administrative Interface
Access to administration methods requires successful authentication through the interface described earlier. The administrative interface can be used both from remote clients as well as from clients on the local network which could be an administration application.
The Administrative Interface allows a user to specify:
In addition it allows a System Administrator to configure:
IADMListHosts( )—Lists all hosts on the local network
IADMListUsers( )—Lists all registered users
IADMListDirectoriesOnHost(String host)—Lists all accessible directories on the specified host
IADMSetAccessRights(URI resource, Int accessrights)—Sets the specified access rights on the specified file or directory
IADMGetUserConfiguration(String user id)—Retrieves the specified user's configuration
IADMSetUserConfiguration(String user id, Configuration c)—Sets the specified user's configuration
Each user's access rights to resources and preferences are controlled through two methods (IADMGetUserConfiguration and IADMSetUserConfiguration). By defining a generic method which passes the configuration as a parameter to the Home Access Local Web Service, maximum flexibility is achieved, and new features can easily be added later on.
A Configuration contains at least the following definitions:
Tunnelling Interface
In tunnelling mode, a complete CIFS message is encapsulated in a Simple Object Access Protocol (SOAP) message by the Home Access Local Web Service using binary attachments. At the Web Service client side (on the terminal), the CIFS content is extracted from the SOAP message and exposed through a CIFS server. This way, an ordinary CIFS enabled browser (e.g. Windows Explorer) can be used to access the remote file system.
There are basically two approaches to embedding binary data into SOAP messages.
The first approach is to use the XML CDATA element type for embedding the CIFS message into the XML message. The drawback of this solution is that the data must be base64 encoded to avoid the content conflicting with e.g. the terminating CDATA tag. Using base64 encoding results in an increase in size of ⅓ of the original size. For SMB messages containing only signalling information, this might not be a problem, but for the messages containing file contents it is.
The other approach is to use SOAP with Attachments (SwA) [4][5][6], but this is not yet supported by all SOAP platforms. It is however supported with JAX-RPC [7] through SAAJ [8]. SwA will, utilising one of the referenced specifications, be supported by all SOAP platforms in the near future.
Also, the client application exposing the file system is required to authenticate itself towards the service access point before access to the remote file system is granted and the file system can be exposed. Except for this authentication process, all other commands follow the network file system protocol.
The Tunnelling Interface has two methods:
ITUNReqCommand(CIFSAttachment)—Transports a complete request command from client to host with network file system
ITUNResCommand(CIFSAttachment)—Transports a complete response command from host with network file system to client
Reduced Mapping Interface
Every CIFS message can be replaced by a corresponding SOAP message. In theory, each field of a CIFS message could be mapped into an entry of a SOAP message by the Home Access Local Web Service. At the client side (terminal), the SOAP message is parsed and the original CIFS message reconstructed and exposed through a CIFS server. However, such a full mapping scheme introduces a lot of overhead and it is not sure that the mobile device is capable to receive and process all the data that it gets. A reduced mapping scheme is more efficient and has the following advantages:
Only the most important parts of native network file system messages are mapped to an XML format. In addition, a set of management interfaces that are used between the client and the service access point, are defined.
These interfaces control connection establishment towards shares, as well as maintenance of sessions and teardown of connections.
IACCListResources(URI uri, String pattern, Boolean recursive)—Lists all resources on the specified URI matching the specified pattern. If pattern is left empty, all resources on the specified URI are listed. Setting recursive to true allows this method to be used for searching for specific named resources throughout the entire tree defined by uri.
IACCReadResource(URI uri)—Reads the contents of the specified resource as specified in the user configuration described previously. This method incorporates several methods of the network file system, such as protocol negotiation, session setup etc., see the enclosed example.
IACCWriteResource(URI uri, WriteSpecification ws)—Writes to the specified resource the content specified by ws (e.g. create/offset/append, data, length etc.). This method incorporates several methods of the network file system, such as protocol negotiation, session setup etc., see the enclosed example.
Home Access Global Web Service
The Home Access Global Web Service is required for the three cases:
It is collaborating with several Home Access Local Web Services belonging to different users. It must have a list of users to serve. Before establishing the connection of a Home Access Local Web Service of a user, sufficiently strong authentication must be carried out.
It has the following functionality:
It has the following interfaces:
The two first interfaces are the same as the ones defined for the Home Access Local Service.
The IP update interface has the following method:
IUpdateIP(user_id, IP address)—To update the IP address of the specified user
IGetCurrentIP(user_id)—Returns the current IP address of the specified user
Home Access Web Service Client
There are two types of Home Access Web Service Client:
The Tunnelling Client will use the Tunnelling Interface to interact with either the Home Access Local Web Service or the Home Access Global Web Service. This Client is suitable for regular PCs. It incorporates also a CIFS server such that a regular CIFS client like Windows Explorer can be used to access the remote files and services.
The Reduced Mapping Client will use the Reduced Mapping Interface to interact with the Home Access Local Web Service and Home Access Global Web Service. This Client is suitable for mobile devices such as mobile phones or PDA (Personal Digital Assistant). It incorporates also a file browser and a User interface (UI) which are designed for devices with limited display and navigation ability.
As
The previous sections of this document have described the generic interfaces necessary to expose a file system on a LAN behind a router/firewall to remote hosts through an XML Web Service. This example details how this can be done using the Common Internet File System (CIFS) as a network file system on the LAN.
This example will provide XML Schema Definitions (XSDs) for transforming CIFS messages into appropriate SOAP messages.
The namespace for all schemas should be http://www.ongx.org/CIFS2XML.
Common Interfaces
This section defines the interfaces that are shared between all modes of operation.
Authentication Interface
The parameters in the following messages employ the Digest Authentication mechanisms described in RFC2617 [9]. This is for illustrative purposes only and other (stronger) authentication mechanisms could/should be employed. The message exchange described below is illustrated in
IAUTHMustAuthenticate(Challenge)
The XSD for this message is defined in IAUTHMustAuthenticate.xsd as (and in this case represents the RFC2617 WWW-Authenticate request):
IAUTHAuthenticateRequest(Credentials)
The XSD for this message is defined in IAUTHAuthenticateRequest.xsd as (and in this case represents the RFC2617 Authorisation request):
IAUTHAuthenticateResponse( )
The XSD for this message is defined in IAUTHAuthenticateResponse.xsd as:
Tunnelling Mode
In tunnelling mode, a complete binary CIFS message is attached to a SOAP message. In addition to the binary part, the SOAP header must also be present to denote the type of attachment that is included (i.e., a CIFS message) and its identifier (according to the SOAP 1.2 with Attachments defined by World Wide Web Consortium [3]).
By making the SMBMessage element a complexType, additional information can be added later on if needed.
A SOAP message with a CIFS message attached would look like this:
The cid value in the Message element refers to the Content-ID tag in the second MIME boundary, and should be unique for each SOAP message. It might be necessary to add a pseudo-random value to this identifier to allow several CIFS messages to be attached to one SOAP message.
Reduced Mapping Mode
Content-type for attachments (i.e., file contents) must be application/octet-stream. In addition, the SOAP envelope must contain the *real* MIME type of the file being transferred to allow proper handling of the attachment on the receiver end (e.g. determine which program should be used to open it). Unless this is decided based on the file extension (e.g. *.jpg etc.).
<AttachmentRealMIMEType>image/jpeg</AttachmentRealMIMEType>< . . . Description of each element in the messages . . . >
Administration Interfaces
a. IADMListHOsts( )
The request message in this interface must conform to IADMListHostsRequest.xsd:
A response must conform to IADMListHostsResponse.xsd:
b. IADMListUsers( )
A request must conform to IADMListUsersRequest.xsd:
A response must conform to IADMListUsersResponse.xsd:
IADMListDirectoriesOnHost(Host)
A request must conform to IADMListDirectoriesOnHostRequest.xsd:
A response must conform to IADMListSharesOnHostResponse.xsd:
d. IADMSetAccessRights(URI resource, Int accessrights)
A request must conform to IADMSetAccessRightsRequest.xsd:
A response must conform to IADMSetAccessRightsResponse.xsd:
e. IADMGetUserConfiguration(User)
A request most conform to IADMGetUserConfigurationRequest.xsd:
A response must conform to IADMGetUserConfigurationResponse.xsd:
f. IADMSetUserConfiguration(String user_id, Configuration c)
A request most conform to IADMSetUserConfigurationRequest.xsd:
A response must conform to IADMGetUserConfigurationResponse.xsd:
Connection Establishment, Maintenance and Teardown interfaces
These functions are transparent to the Home Access Client, and will be performed only by the Home Access Local Web Service. The mapping is thus one-to-one between client calls and file system calls. This is already discussed above.
Resource Access Interfaces
a. IACCListResources(URI uri String pattern, Boolean recursive)
A request on this interface must conform to IACCListResourcesRequest.xsd:
A response on this interface must conform to IACCListResourcesResponse.xsd:
b. IACCReadResource(URI uri)
A request on this interface must conform to IACCReadResourceRequest.xsd:
A response on this interface must conform to IACCReadResourceResponse.xsd:
c. IACCWriteResource(URI uri, WriteSpecification ws)
A response on this interface must conform to IACCListResourcesResponse.xsd:
[1] Sun Microsystems Inc. (1989). NFS: Network File System Protocol Specification. IETF. March 1989. http://www.ietf.org/rfc/rfc1094.txt?number=1094
[2] Callaghan, B., et.al. (1995). NFS Version 3 Protocol Specification. IETF. June 1995. http://www.ietf.org/rfc/rfc1813.txt?number=1813
[3] Storage Networking Industry Association (SNIA). (2002). Common Internet File System (CIFS) Technical Reference Revision 1.0. February 2002.
[4] Barton, J., et.al. (2000). SOAP Messages with Attachments. World Wide Web Consortium (W3C). December 2002. http://www.w3.org/TR/SOAP-attachments
[5] Gudgin M., et.al. (editors) (2005). SOAP Message Transmission Optimization Mechanism. World Wide Web Consortium (W3C). January 2005. http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/
[6]Ferris, C., et.al. (editors) (2004). Attachments Profile Version 1.0. Web Services Interoperability Organization (WS-i). August 2004. http://www.ws-i.org/Profiles/AttachmentsProfile-1.0-2004-08-24.html
[7] Sun Microsystems, Inc. (2003). JSR-67: Java APIs for XML Messaging 1.0. Java Community Process (JCP). http://www.jcp.org/en/jsr/detail?id=67
[8] Sun Microsystems, Inc. (2003). JSR-101: Java APIs for XML based RPC. Java Community Process (JCP). http://www.jcp.org/en/jsr/detail?id=101
[9] Franks, J., et.al. (1999). HTTP Authentication: Basic and Digest Access Authentication. IETF. June 1999. http://www.ietf.org/rfc/rfc2617.txt?number=2617
| Number | Date | Country | Kind |
|---|---|---|---|
| 20051487 | Mar 2005 | NO | national |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/NO06/00108 | 3/21/2006 | WO | 00 | 11/20/2007 |
