Systems and methods for providing access control to web services using mirrored, secluded web instances

Systems and methods are provided for providing access to data on a personalized basis. A service operating on a server is identified, where data at the service is associated with a first user and other users. Data associated with the first user is extracted. A network location is spawned for the first user. The extracted data is transferred to the spawned network location to make the extracted data available to the first user in a read-only fashion by accessing the spawned network location. Additional network locations are spawned for second and third users, respectively, wherein data associated with the second and third users is transferred such that they are available to the second and third users by accessing their respective additional network locations.

TECHNICAL FIELD

The technology described herein relates data communications and more particularly to control of data access through the use of secluded web instances.

BACKGROUND

Web services having interfaces that are known and accessible to multiple users are prone to abuse and attack. Disseminated knowledge of the location of the interface (e.g., an address) provides a gateway for unauthorized access attempts. Centralized storage of service data associated with multiple users (e.g., the users who are permitted to access the service) provides opportunities for abuse even by authorized users. For example, authorized users can access the service interface using their credentials and then can attempt to access service data to which they are not entitled (e.g., service data associated with other users) after entry to the system via their credentials.

SUMMARY

Systems and methods are provided for providing access to data on a personalized basis. A service operating on a server is identified, where data at the service is associated with a first user and other users. Data associated with the first user is extracted. A network location is spawned for the first user. The extracted data is transferred to the spawned network location to make the extracted data available to the first user in a read-only fashion by accessing the spawned network location. Additional network locations are spawned for second and third users, respectively, wherein data associated with the second and third users is transferred such that they are available to the second and third users by accessing their respective additional network locations.

As another example, a system for providing access to data on a personalized basis includes one or more data processors and a computer-readable medium encoded with instructions for commanding the processing system to execute steps of a method. In the method, a service operating on a server is identified, where data at the service is associated with a first user and other users. Data associated with the first user is extracted. A network location is spawned for the first user. The extracted data is transferred to the spawned network location to make the extracted data available to the first user in a read-only fashion by accessing the spawned network location. Additional network locations are spawned for second and third users, respectively, wherein data associated with the second and third users is transferred such that they are available to the second and third users by accessing their respective additional network locations.

As a further example, a computer-readable medium is encoded with instructions for commanding one or more data processors to execute a method for providing access to data on a personalized basis. In the method, a service operating on a server is identified, where data at the service is associated with a first user and other users. Data associated with the first user is extracted. A network location is spawned for the first user. The extracted data is transferred to the spawned network location to make the extracted data available to the first user in a read-only fashion by accessing the spawned network location. Additional network locations are spawned for second and third users, respectively, wherein data associated with the second and third users is transferred such that they are available to the second and third users by accessing their respective additional network locations.

DETAILED DESCRIPTION

FIG.1is a block diagram depicting a server that provides a web service accessible by multiple users. The server102(e.g., one or more servers) includes a web service104executing thereon. The web service104aggregates, calculates, generates, or otherwise acquires data associated with one or more users106and stores that data in a service data repository108for access by the users106. Web service104can take a wide variety of forms including a messaging service (e.g., email, SMS), a chat service, a database service. The server102includes an interface110via which users106access the service104and the associated service data108. The interface110is tasked with authenticating users106to determine whether that user has permission to access the service104and the service data108. For example, the interface110may challenge an accessing user106to provide credentials (e.g., a username/password combination, a token, a key) that verifies the user's identity and permission to access service104functionality and data108. Once authenticated, the interface110, the service104, or other controls mediate which service104functionality and data108an authenticated user106is permitted to access.

In the example ofFIG.1, service104has acquired data associated with User A and User B in the service data repository108. Accordingly, the interface110is informed that User A and User B are to be permitted access upon presentation of proper credentials. User C is not to be permitted access by the interface110.FIG.2is a diagram depicting an example authentication sequence for accessing a server that provides access to a server and associated service data. A user106(e.g. User A) at202attempts to access the service104directly. The user106is informed by the interface110at204of a requirement to authenticate. The user106presents credentials to the interface110at206and is presented confirmed identity information at208. The user106uses that identity information to again request access to the service at210, and based on the identity information, the user106is provided service information at212.

The configuration ofFIGS.1and2is vulnerable to attack and abuse in at least two ways. First, the location (e.g., address) of one or more of the server102, the service104, or the interface110is known to multiple people. This wide dissemination of location information provides a greater likelihood that the location information will be misappropriated by others. For example, User C, who has no rights to access service104or its associated service data108, could acquire the location information surreptitiously from User A or User B or with their assistance. Knowing the location information, User C could then attempt to access the service104or service data repository108(e.g., via a hack, using User A or User B's credentials) to access data to which User C is not entitled.

In a second example, an authorized user (User A) could use their legitimate credentials to access the service104and service data108. Once through the interface110, certain systems' internal security is not as robust as that of the interface110. After authentication, the authorized user could attempt to access service data108to which they are not entitled (e.g., User A accessing messages of User B) by improperly upgrading their access permissions or taking advantage of another security flaw. Housing service data108of users (e.g., User B) in a location that will be accessed by other users (e.g., User A) provides another potential security weakness.

FIG.3is a block diagram depicting a system for providing access to data on a personalized basis. The system includes a service302operating on a server304. Data associated with the service302is stored as service data in a service data repository306. But, no user310is permitted to access service data306directly via an interface318of the service302/server304. This is indicated by the “X” on the lines connecting the users310to the interface318. In fact, it is preferable that no user be provided the location (e.g., address) of the server304, service302, or interface318to prevent any attempt at access. Instead, each user310(or group of users) is provided access to a network location (e.g., a physical server location, a virtual server location) that is separate from the service302and contains only service data306that that user is permitted to access.

Specifically, in one example, a data extraction module308is configured to extract data associated with users310, such as User A and User B. A network control engine312is configured to spawn network locations314,316for users who are to be provided access to service data306(i.e., one spawned network location A314for User A and one spawned network location B316User B). The spawned network locations314,316may be spawned at a random or pseudo-random address in an available address space324that the network control engine312controls. That address space324may be substantial in size in order to help protect the spawned network locations314,316from detection. In one embodiment, spawned network locations314,316may be kept operational for a limited period of time (e.g., a threshold period of time, a random or pseudo-random period of time), after which a replacement spawned network location may be provisioned at a new address in the address space324and its predecessor disabled.

The data extraction module308is configured to transfer the extracted service data for a particular user (e.g., the data associated with User A) to the spawned network location associated with that particular user (e.g., spawned network location A314), such as via a reverse proxy connection. The data extraction module308is further configured to transfer the extracted service data for other users310(e.g., the data associated with User B) to respective spawned network locations (e.g., spawned network location B316). Thus, one spawned network location314,316is provided to hold service data (e.g., a read only copy of User A's service data320from repository306is stored on spawned network location A314) that a particular user is permitted to access but no more. In one embodiment, the data extraction module periodically (e.g., after a pre-determined period of time, upon a user command, on occurrence of an event) determines whether the service data306of a user (e.g., User B) has changed. If that service data306has changed, the data extraction module308transmits updated data to the repository (e.g., data store322for User B) stored on that user's spawned network location.

Location data for accessing interfaces of spawned network locations is then provided on a user by user basis via an out of channel communication (e.g., a link embedded in an email or a text message). The location data may be accompanied with credential information (e.g., an embedded password or token), or a user's existing credentials may be used to access the noted location. Should a user's spawned network location's address change (e.g., as may be periodically done in order to obfuscate locations of such spawned network locations), an updated location may be sent to that user via another out of channel communication.

The above-described network configuration mitigates the two security weaknesses described above with respect toFIGS.1and2. First, because no user310is provided locations of the service302, server304, or the interface318, attacks on those entities become more difficult. Where, in the example ofFIGS.1and2, User C could have misappropriated such locations from User A or User B, that behavior is not possible in theFIG.3implementation because User A and User B preferably do not have or need the location of those entities. Further, authorized users accessing their spawned network location are not able to access more service data306than they are entitled. Because User A's spawned network location A314only contains User A's service data at320, User A is not able to access User B or any other user's data because no other user's service data is stored at spawned network location A.

Malicious behavior by unauthorized User C is also substantially mitigated. User C has no knowledge of the locations of the spawned network locations314,316. And in implementations where spawned network locations are periodically moved, even if User C did discover a spawned network location's address, that address would change after a period of time (e.g., minutes, hours, days), halting access. Further, even if User C was able to break into a spawned network location (e.g., spawned network location A314), User C would only be able to access data associated with a single user because only a single user's service data (e.g., User A's data at320) is stored at a spawned network location.

FIG.4is a diagram depicting an example authentication sequence for accessing a system for providing access to data on a personalized basis. A web service302operates on a server304, and a process periodically operates to collect updates to the service data306. That service data306is transmitted to an isolated server (e.g.,314,316) associated with a particular user as described above. A user (e.g., User A) tries unsuccessfully and then successfully to access his data as follows. At402, the user attempts to directly access the web service302. Because some persons, such as a system administrator, may be able to access the web service302in this manner, a message is returned at404requesting authentication. (In some embodiments, it is preferred that User A not know the location of the web service302at all.) The user attempts to authenticate using his credentials (e.g., his work network username and password) at406. Because User A is not permitted to access the web service302directly, an unauthorized indication is returned at408.

At410, User A attempts to access his spawned network location (e.g., using a link sent directly to User A only via a text or email message). At412, User A is informed that he must authenticate. At414, User A presents his correct credentials, and at416identity information is provided to User A's client system. At418, User A uses that identity information to request data from the spawned network location, and at420, User A's service data306is returned to User A's client.

Other examples and variations fall within the scope of this disclosure. For example, similar to how systems and methods as described herein can be used to distribute login credentials, those systems and methods can also be used to distribute generic data payloads (e.g., software updates) in a manner that makes it such that every client or user who wishes to receive such updates would be issued his/her own service (microservice) instance.

In one example, whenever a new data distribution is to be made, a specific version of that data distribution would be built for that third party, encrypted either using that third party's cryptographic Public Key, or using a pre-shared cryptographic key, such that only that particular third party can decrypt that particular data payload. Then, that payload would be loaded into the microservice instance associated with that particular third party.

In this way, there exists no single server or network location that multiple third parties must contact in order to download software updates and so forth; each third party would instead download its software updates from its particular microservice instance, decrypt it with its unique cryptographic key, and have access to the updated data.

As a further example, certain services as described herein may, in some instances, make use of fixed URLs, given to a third party, who can then access the service provided by the Portal Proxy (e.g., as depicted in U.S. patent application Ser. No. 15/189,053, the entirety of which is herein incorporated by reference) by visiting that URL. In those examples, the URL is either generated at random as a string of characters or as a grouping of words, or is designated manually. That string is prepended to a fixed string representing the base URL of the provider that will be hosting the instance (e.g. “.ric.jelastic.vps-host.net”) to create a full URL.

In example, this URL generation may incorporate a time-based element, similar in concept to Time-based One Time Passwords (TOTP) as described in RFC 6238.

Rather than the Portal Proxy for a particular third party being instantiated and remaining at a single URL, when the Portal Proxy is initially created, a secret phrase would be generated and shared with the third party. Thereafter, the URL for the Portal Proxy could be calculated on a time-associated basis, assuming some agreed-upon granularity.

For instance, once a day, a discrete communication engine might calculate a new URL for Party A's Portal Proxy, using the pre-shared secret phrase associated with Party A, as well as the absolute time in seconds since Epoch (00:00 UTC Jan. 1, 1970), and some form of cryptographic hash designed to render an alphanumeric string, and then append the provider URL string. The Engine would destroy the previous day's PP, and generate a new one at the new URL generated in this manner.

Whenever Party A wishes to make use of its PP, it would follow the same method of calculation, combining its pre-shared secret phrase, the current time value, and the same cryptographic hashing algorithm, and then appending its known provider URL string. In this way, Party A would generate the same compete URL that the Engine had generated, and would therefore be able to access the service provided by the Portal Proxy at that URL.