Patent Description:
Organizations and their respective information technology and data systems often share information with each other. In a multi-tenanted system, it is desirable to facilitate sharing of data across multiuple organizations that are tenants. Each organization may have its own users and associated user account information, which may be private and proprietary. In addition, some user information may be restricted by law and regulations from being shared across multiple organizations.

Secured content owned by one of the organizations may be only allowed access when the user requesting access is authenticated. When an external user is requesting access to said secured content, it is desirable to authenticate the external user without having to comprise the privacy of the user, while still providing an audit trail.

<CIT> discloses an optimized token-based proxy authentication.

<CIT> relates to a data access method, device, and electronic device.

In accordance with an aspect of the present invention, a computer-implemented method for providing access to secured content on a provisioning entity system comprises the steps of claim <NUM>.

In accordance with another aspect of the invention, there is provided a computer-implemented system for providing access to secured content on a provisioning entity system in accordance with claim <NUM>.

In accordance with yet another aspect of the invention, there is provided a non-transitory computer-readable storage medium in accordance with claim <NUM>.

Further developments of the invention are recited in the dependent claims.

In the figures which illustrate example embodiments,.

Secured content owned by an organization may be accessed by an external user when the user requesting the secured content is properly authenticated. The organization may need a number of different types of information for proper authentication. However, the user requesting access to the secured content may wish to protect his or her own privacy and identity. For example, a retail store may grant access to its video surveillance system to the local police department upon a proper cause (e.g., potential crime investigation), but the police department may wish to protect the identity of its police officier(s) accessing the secured content (e.g., videos) in the video surveillance system.

A service provider or authenticating system that facilitates the secure access of secured content owned by a provisioning entity system (e.g., the retail store) to one or more users of a requesting entity system (e.g., the police department) may desire to facilitate the secured access while minimising both cost and liability. For instance, when a user is requesting access to said secured content, it is desirable to authenticate the external user without having to comprise the privacy of the user, while still providing an audit trail.

Currently, computer systems which store and manage access to data often keep records (e.g., logs) of data access for audit purposes. Authentication is often performed in a dedicated environment, including for example single sign-on (SSO) and centralized identity and access management (IAM). Example IAM platforms include Azure AD, Okta, Ping, Auth0, and so on. However, for separate and distinct enterprises and organizations, such as in the above example of retail store and police department, SSO and IAM can be difficult and costly to implement.

In some instances, if the requesting entity system makes a copy of and transmits the user data to the provisioning entity system, across multiple organizations and systems, the users who sign on through the requesting entity system may risk losing certain levels of privacy. From a privacy perspective, it is important for the users to be anonymous and not identifiable, and further not correlatable based on user activities or other indicators such as MAC address, IP address, and so on.

On the other hand, if a blanket permission is given from the provisioning entity system to the requesting entity system for data access, such as using a system-level account without specific user information, the provisioning entity system may lose visibility on content access, and it would be difficult to determine exactly which user(s) have accessed which content using audit trails.

The example embodiments described herein, including platform <NUM> in <FIG>, provides a technical solution configured to provide access to one or more secured content of a provisioning entity system, where user account information may be used to authenticate the user request and hidden from the provisoning entity system. The present disclosure provides non-correlation of actions performed by users between different login sessions at the requesting entity system, either through the same application interface (e.g., mobile application) or different application interface (e.g., web browser interface). The technical solution further provides the ability to reconstruct an accurate and precise activity log for audits of content access without compromising any user account information.

<FIG> is a high-level schematic diagram of an example computer-implemented platform <NUM> for providing access to secured content on a provisioning entity system <NUM>, exemplary of embodiments.

As detailed herein, in some embodiments, platform <NUM> includes features adapting it to perform certain specialized purposes, e.g., as a authetication platform to authenticate user requests from a requesting entity system <NUM> for access to secured content on a separate system (e.g., provisioning entity system <NUM>) and to provide trusted tokens in response to the user requests.

Referring now to the embodiment depicted in <FIG>, platform <NUM> can include an I/O unit <NUM>, a processor <NUM>, communication interface <NUM>, and data storage <NUM>. The I/O unit <NUM> can enable platform <NUM> to interconnect with one or more input devices, such as a keyboard, mouse, camera, touch screen and a microphone, and/or with one or more output devices such as a display screen and a speaker.

Platform <NUM> can connect to a requesting entity system <NUM> to receive input data such as user requests for accessing one or more secured content on a remote system, which may be, for example, the provisioning entity system <NUM>. A real world example of the requesting entity system <NUM> may be a system maintained by or associated with the local police department, and a real world example of the provisioning entity system <NUM> may be a system maintained by or associated with a retail store. The secured content may be videos or other media captured by a surveillance system installed throughout the retail store.

In some embodiments, platform <NUM> is an independent system that acts as an authetication authority, which can receive user requests from the requesting entity system <NUM>, and facilitate access to one or more secured content <NUM> stored on the provisioning entity system <NUM> based on authentication of the received user requests. In some embodiments, some or all of the secured content <NUM> owned by the provisioning entity system <NUM> may be stored on one or more databases, which in certain circumstances may reside in servers managed by the same entity which manages the platform <NUM>. In some other embodiments, the servers in which the secured content <NUM> resides may be managed by a party separate from that which manages the platform <NUM>.

Platform <NUM> can be operable to register and authenticate users (using a login, unique identifier, and password for example) prior to providing access to applications, a local network, network resources, other networks and network security devices.

In some embodiments, authentication performed by platform <NUM> may be claims-based authentication where an identity ascertained from a user request is defined as a set of claims (e.g., key value pairs), and a proof of identity is translated to a token containing these claims. The token may be cryptographically signed by a trusted authority such as platform <NUM>, and may be referred to as a trusted token. The provisioning entity system <NUM> may receive the trusted token and verify that it is legimatically issued by platform <NUM>, then grant user access to the requested secure content <NUM>.

Network <NUM> (or multiple networks) is capable of carrying data and can involve wired connections, wireless connections, or a combination thereof. Network <NUM> may involve different network communication technologies, standards and protocols, for example.

The requesting entity system <NUM> interacts with platform <NUM> and the provisioning entity system <NUM> to exchange data (including user commands) and, through an interface application, generates visual elements for display at a user device. The visual elements can represent elements configured to receive user commands for a user request for one or more secured content <NUM> at the provisoning entity system <NUM>, when appropriate. For eample, when a user wishes to request access to secured content <NUM> at the provisoning entity system <NUM>, the requesting entity system <NUM> may obtain a set of user information based on the account with which the user is currently logged in. The user information may include, for example, name, job title, a reason for the access request, e-mail address, phone number, work address, home address, and so on. These user information may be considered private by the user, because they may be identifiying of the user themselves, that is to say, revealing of their identity.

Memory <NUM> may include a suitable combination of any type of computer memory that is located either internally or externally such as, for example, random-access memory (RAM), read-only memory (ROM), compact disc read-only memory (CDROM), electro-optical memory, magneto-optical memory, erasable programmable read-only memory (EPROM), and electrically-erasable programmable read-only memory (EEPROM), Ferroelectric RAM (FRAM) or the like. Data storage devices <NUM> can include memory <NUM>, databases <NUM>, and persistent storage <NUM>.

The processor <NUM> can execute instructions in memory <NUM> to implement aspects of processes described herein. The processor <NUM> can execute instructions in memory <NUM> to configure a token generator <NUM>, an encryption module <NUM>, an auditing module <NUM>, and other functions described herein. The processor <NUM> can be, for example, any type of general-purpose microprocessor or microcontroller, a digital signal processing (DSP) processor, an integrated circuit, a field programmable gate array (FPGA), a reconfigurable processor, or any combination thereof.

The token generator <NUM> can be configured to generate and sign a trusted token based on an individual user request from the requesting entity system <NUM>. The user request may include one or more data items, including but not limited to: a timestamp, a domain identifier or system ID, a user ID, one or more user identifying information, and one or more content identifying information. The timestamp may indicate a time and date for when the user request is generated by the requesting entity system <NUM>. The domain identifier or system ID may indicate the requesting entity system <NUM>. The user ID may be an identifier associated with the requesting entity system <NUM>, or with the user associated with the user request provided to the platform <NUM>. In some embodiments, the user ID may be a so-called "stable ID", which is uniquely associated with the user, but not directly identifying thereof.

The user identifying information may include data representing at least one of: a name, a phone number, a physical address, an e-mail address, a media access control (MAC) address and/or an IP address of the device used to log into the requesting entity system <NUM>, and so on.

In some embodiments, the user request from the requesting entity system <NUM> may not include any specific user identifying information, as the requesting entity system <NUM> may be implemented to specifically shield any user identifying information from platform <NUM>. The user request from the requesting entity system <NUM> may still include other information such as described herein.

The content identifying information may include data representing at least one of: a provisioning entity system, a URL of the provisioning entity system, a type (e.g., video, audio, image or document) of the content being requested, specific identifiers of the content being requested, a URL of each content being requested, and so on.

The token generator <NUM> may be configured to first remove one or more data items from the user request prior to generating a token based on the user request. For example, some or all of the user identifying information present in the user request may be removed in order to improve the anonymity of user as represented in the trusted token to be produced based on the user request. Next, the token generator <NUM> can determine the user ID based on the user request. The user ID is typically associated with a particular user from the requesting entity system <NUM> without directly identifying them, and may be a string of numbers, alphabets, symbols or any combination thereof. Put differently, the user ID may not on its own be used by a third party to identify the user. However, the user ID may be uniquely associated with the user, and can be used by the requesting entity system <NUM>, to identify the specific user logged into the requesting entity system <NUM> when making the user request.

In some embodiments, platform <NUM> is configured to delete the user identifying information from all temporary and persistent data storage devices of the platform <NUM>, without permanently storing any of the user identifying information from any user request. In other embodiments, platform <NUM> may store part or all of the user identifying information in a secured database, in order to help with reconstruction of audit records without involvement of the requesting entity system <NUM>.

The token generator <NUM> can use the user ID and domain identifier, as well as other information from the user request to verify that the user request indeed has come from the specific requesting entity system <NUM>, and proceeds to issue a trusted token having at least one claim representing that the user sending the user request is a user or member of the requesting entity system <NUM>.

The token generator <NUM> can be configured to generate a variable term (also known as a pseudo-term) to be included in each trusted token based on the user ID from the user request, in order to prevent the user ID from being disclosed to other systems, including the provisioning entity system <NUM>. The token generator <NUM> can be configured to ensure that the respective variable term generated for the respective trusted token for each user request received by the platform <NUM> is uniquely generated. In some embodiments, the uniqueness of each variable term for each user request may be enforced during a specific time frame (e.g., in the past three months, the past six months, or in the past year). The uniquness of the variable term and thus of the trusted token helps to ensure that the provisioning entity system <NUM> cannot correlate activities of any specific user over time, as such correlation could lead to a deduction of the user's identity.

In some embodiments, the token generator <NUM> can be configured to ensure that the respective variable term for each user request is unique among all the user requests associated with a specific provisoning entity system <NUM>.

For example, the token generator <NUM> can be configured to generate a variable term by encrypting the user ID from the respective user request associated with the trusted token. The encryption process may add (concatenate) a random, pseudo-random, arbitrary, or predetermined term to the user ID, or may change the user ID in a similar fashion, to generate the variable term. The encryption may be performed by the encryption module <NUM>. In some embodiments, including embodiments in which the trusted token is used in a claims-based authentication environment, the trusted token may be structured such that the variable term acts as the claim indicating the identity of the user making the user request. In this fashion, the trusted token may be generated such that the variable term replaces the user ID, which would typically act as the claim indicating the identity of the user. Thus, the user ID itself may be absent from the trusted token, or included in a fashion which is not recoverable by the provisioining entity system <NUM>, having been replaced by the variable term.

In some embodiments, the variable term may change over time, per hour, per day, per week, or per any other given period of time. For instance, the term concatenated to the user ID may be varied over time.

In some embodiments, the variable term may include a timestamp generated based on the timestamp included in the user request, or a timestamp generated based on a clock time of platform <NUM>. For instance, the term concatenated to the user ID may be a timestamp of the user request, a timestamp at which the platform <NUM> processes the user request, or the like.

In some embodiments, the variable term may include a predetermined value, which may be, for example, a login count (e.g., this is the nth login from XYZ requesting entity system <NUM> today), or a timestamp at the time of token generation. For instance, the term concatenated to the user ID may a count of user requests or login attempts performed by the user using the user ID.

In some embodiments, the token generator <NUM> may be configured to include the user ID from the user request in the trusted token without randomizing or encrypting it. This way, the provisioning entity system <NUM> may be able to correlate user activities (e.g., multiple user requests for secured content) based on the received trusted tokens sent by the same user from the requesting entity system <NUM>. This may harm privacy of the users of the requesting entity system <NUM>, but may allow the provisioning entity system <NUM> to perform audits with the requesting entity system <NUM>, and without the involvement of platform <NUM>.

The token generator <NUM> may include other data in the trusted token, such as for example, one or more of: a type or scope of secure content being requested, specific URLs of the secure content being requested, a domain identifier identifying the requesting entity system <NUM> (but nothing identifying the specific user of the system <NUM>), an expiry date and time of the trusted token, and so on.

The token generator <NUM> can be configured to add a proof of authentication to the trusted token to allow the provisioning entity system <NUM> to validate the trusted token. For example, this can be the digital signature, which can be generated using a private key belonging to platform <NUM>, and verifiable with a corresponding public key provided by platform <NUM> to the provisioning entity system <NUM>. This way, when the provisioning entity system <NUM> receives the trusted token, it can use the public key corresponding to the private key to validate that the trusted token is generated by platform <NUM>, before granting access to the secured content to the user.

In some embodiments, the public key(s) corresponding to the private key used to add the digital signature to the trusted token may be stored in a database accessible by the public, including the provisoning entity system <NUM>. The public keys may be managed by platform <NUM> and updated from time to time. The trusted token in some embodiments may include a URL for obtaining the corresponding the public key. In some embodiments, the provisioning entity system may obtain the relevant public key from the URL included in the trusted token. In some other embodiments, the provisioning entity may compare the URL included in the trusted token to a whitelist or other listing of approved URLs, and accept or reject the trusted token based on whether the URL included in the trusted token is also present in the whitelist.

The encryption module <NUM> can be configured to perform an encryption process, as appropriate, when called by components of platform <NUM>, such as the token generator <NUM>. For instance, the encryption module <NUM> can perform encryption of part of the trusted token (e.g., the variable term), or of the entire trusted token. The encryption may be performed with a random or pseudo-random encryption key generated by an algorithm, or in any other suitable fashion. For example, the variable term may be generated by hashing and encrypting the user ID from a user request.

When performed on the entire trusted token, the encryption may be decrypted, in some embodiments, with the appropriate key by the provisioning entity system <NUM>. The encryption process may be done with symmetric key schemes, or public key schemes (e.g., RSA).

The auditing module <NUM> can be configured to perform an auditing process based on a request received by platform <NUM>, with collaboration from one or more systems such as the requesting entity system <NUM> and the provisioning entity system <NUM>. For example, when platform <NUM> receives an auditing request, the auditing request may include a plurality of user IDs from an outside system such as the requesting entity system <NUM>. The auditing request also can include other information such as a domain identifier identifying the specific requesting entity system <NUM>, a provisioning entity system identifier of the provisioning entity system <NUM>, and optionally a time period during which some of the user IDs may be used to request secured content at the provisioning entity system <NUM>.

The auditing module <NUM> is configured to obtain a plurality of validated trusted tokens used to access one or more secured content <NUM> at the provisioning entity system <NUM>. In some embodiments, when a time period is given within the auditing request, the plurality of validated trusted tokens may be limited to those used to access content at the provisioning entity system <NUM> during the given time period. In other embodiments, when a time period is not specified by the auditing request, the time period may be assumed to be within any suitable past duration, e.g., the past week, the past month, the past year, since the inception of the provisioning entity system <NUM>, or since the inception of the provisioning of access to the provisioning entity system <NUM> for users of the requesting entity system <NUM>, and so on.

The auditing module <NUM> may then be configured to determine, based on the plurality of validated trusted tokens, one or more user IDs from the plurality of user IDs, the one or more user IDs used to access the one or more secured content at the provisioning entity system.

In some embodiments, the auditing module <NUM> may determine the one or more user IDs by decrypting the plurality of validated trusted tokens to obtain, for each of the plurality of validated trusted tokens, an intermediary term. The intermediary term may include one or more of: a respective user ID from the one or more user IDs and/or a respective variable term. The auditing module <NUM> may parse each intermediary term to obtain the respective user ID.

For example, in the case where the respective user ID has been previously encrypted by the encryption module <NUM> to become a variable term, the auditing module <NUM> may decrypt the intermediary term to obtain the respective user ID.

For another example, in the case where the respective user ID was concatenated by a random or pseudo-random term to become a variable term, the auditing module <NUM> may parse the intermediary term to obtain the respective user ID.

The auditing module <NUM> may then transmit the determined one or more user IDs to the requesting entity system <NUM> in response to the auditing request. Additionally, the auditing module <NUM> can provide information about the elements of the secured content <NUM> that were accessed by each of the user IDs, about the patterns of access (time, frequency, etc.), or other relevant information.

Referring back to <FIG>, the communication interface <NUM> can enable platform <NUM> to communicate with other components, to exchange data with other components, to access and connect to network resources, to serve applications, and perform other computing applications by connecting to a network (or multiple networks) capable of carrying data including the Internet, Ethernet, plain old telephone service (POTS) line, public switch telephone network (PSTN), integrated services digital network (ISDN), digital subscriber line (DSL), coaxial cable, fiber optics, satellite, mobile, wireless (e.g. Wi-Fi, WiMAX), SS7 signaling network, fixed line, local area network, wide area network, and others, including any combination of these.

The data storage <NUM> may be configured to store information associated with or created by the components in memory <NUM> and may also include machine executable instructions. The data storage <NUM> includes a persistent storage <NUM> which may involve various types of storage technologies, such as solid state drives, hard disk drives, flash memory, and may be stored in various formats, such as relational databases, non-relational databases, flat files, spreadsheets, extended markup files, etc..

<FIG> is an example schematic flow chart between the systems shown in <FIG>, in accordance with an embodiment.

At step <NUM>, the requesting entity system <NUM> may request a token from an authenticating system (e.g., platform <NUM>), which a user of the requesting entity system <NUM> can use to access resources such as secured content at the provisioning entity system <NUM>. The user may submit a user request for the secured content, the user request including at least a user ID and may optionally include certain types of user identifying information. The user ID may be referred to as a stable identifier, which allows platform <NUM> to correlate back to the original user request, but does not directly link back to the user himself without collaboration of the requesting entity system <NUM>.

At step <NUM>, platform <NUM> generates a digitally-signed trusted token through the token generator <NUM>, and transmits the trusted token to the requesting entity system <NUM>. The digital signature allows the provisioning entity system <NUM> to confirm that the platform <NUM> has issued the trusted token, thereby allowing the provisioning entity system <NUM> to trust the token. To prevent the provisioning entity system <NUM> from being able to identify or correlate the user based on the trusted token, platform <NUM> may first remove all the user identifying information from the user request (if any), and generate a variable term based on the user ID in accordance with processes described above performed by the token generator <NUM>. The variable term may be encrypted by the encryption module <NUM>.

The token generator <NUM> can be configured to add a proof of authentication to the trusted token to allow the provisioning entity system <NUM> to validate the trusted token. For example, this can be the digital signature, which can be generated using a private key belonging to paltform <NUM>, and verifiable with a corresponding public key provided by platform <NUM> to the provisioning entity system <NUM>. This way, when the provisioning entity system <NUM> receives the trusted token, it can use the public key corresponding to the private key to validate that the trusted token is generated by platform <NUM>, before granting access to the secured content to the user.

In some embodiments, the corresponding public key(s) to the private key used to add the digital signature to the trusted token may be stored in a database accessible by the public, including the provisoning entity system <NUM>. The public keys may be managed by platform <NUM> and updated from time to time. The trusted token may include a URL for obtaining the corresponding the public key.

At step <NUM>, the user, through an application or interface of the requesting entity system <NUM>, sends a request to the provisioning entity system <NUM> using the trusted token in order to access content at the provisioning entity system <NUM>. The provisioning entity system <NUM> may first verify, using for example a public key corresponding to the private key used to sign the trusted token by platform <NUM>, that the trusted token has been issued by platform <NUM>, a trusted authentication system.

At step <NUM>, the provisioning entity system <NUM> may decrypt, if necessary (e.g., if the trusted token has been encrypted by platform <NUM>), the trusted token to determine information such as the identity of the requesting entity system <NUM> using a domain identifier included in the trusted token. If the requested content can be shared with members of the requesting entity system <NUM>, the provisioning entity system <NUM> can facilitate the access to the requested content, and log the access event with part or all of the trusted token, which can be used in the auditing process later. For instance, the access event may be logged with the claims of the trusted token, including the claim indicating the identity of the user making the request using the trusted token. In some embodiments, the requested content may be specified within the trusted token. In some embodiments, the requested content may be specified within the request sending the trusted token.

The record or log of the access event by the provisioning entity system <NUM> may include information such as date and time of access, the trusted token in encrypted and/or decrypted form, the domain identifier linked to the requesting entity system <NUM>, and the exact files accessed.

An auditing process can be instantiated by either the provisioning entity system <NUM>, which may detect multiple access events to a particular content or multiple access events at similar times or within a set time frame, or by the requesting entity system <NUM>, which may detect that a given user has made multiple requests to the provisioning entity system <NUM> without knowing what was accessed. When the requesting entity system <NUM> sends an auditing request, the auditing request may include user IDs that may have been used to access content at the provisioning entity system <NUM>. The auditing request may include a specific time period for when the user IDs may have been used to access the content at the provisioning entity system <NUM>. In some embodiments, the auditing request may include all the user IDs of the requesting entity system <NUM>.

Based on the auditing request, platform <NUM> may request information from the provisioning entity system <NUM>, which can then provide records or logs of what content was accessed and what trusted tokens were used to access the content (which, by themselves, are not identifying or correlatable). In some embodiments, the logs may include all the trusted tokens used to access content from the specific requesting entity system <NUM> during a specific time period, which may be included in the auditing request, or an assumed time period (e.g., the past week, the past month, or the past year).

Platform <NUM> may then process each of the the trusted tokens to determine the user ID within each trusted token. Once all the user IDs in the trusted tokens are identified, the user IDs can be sent to the requesting entity system <NUM>, which can identifier particular users based on the user IDs.

In some embodiments, platform <NUM> may, based on its own record, determine which user IDs are used to request access for content at a provisioning entity system <NUM> during a specific time period. For example, platform <NUM> may store all the trusted tokens generated and the associated user IDs in a local database. Upon receiving an auditing request from either the requesting entity system <NUM> or the provisioning entity system <NUM>, platform <NUM> may determine, based on the stored trusted tokens which user IDs have been used to request content at the provisioning entity system <NUM> during a specific time period. The list of user IDs may be sent to the requesting entity system <NUM> for identifying the specific users behind the trusted tokens and user requests.

The implementations described above allow the provisioning entity system <NUM> to be assured of the validity of a request without revealing identifying information about the user at the requesting entity system <NUM>. The implemetations also facilitate audit of file accesses which may require collaboration of two or three entities to determine which user(s) performed the access to one or more secured content at the provisioning entity system <NUM>.

<FIG> is annother example schematic flow chart between the systems shown in <FIG>, in accordance with an embodiment. A user device <NUM> of a user of the requesting entity system <NUM> may send an unauthenticated request <NUM> to the provisioning entity system <NUM> requesting access to one or more secured content stored at the provisioning entity system <NUM>. The user may request access to a particular file, or to a particular group of files (e.g., video files on date X for location Y). The user device <NUM> may be, for example, a computer or a mobile device.

The provisioning entity system <NUM> may send a request <NUM> to platform <NUM> to authenticate the the user account associated with user device <NUM>. Platform <NUM> may send an query <NUM> to the user device <NUM> requesting the user to indicate if the user is a member of a requesting entity system <NUM>, and the response <NUM> from the user device <NUM> may indicate that the user is a member of requesting entity system <NUM> (e.g., "Organization B"). Next, platform <NUM> may send a request <NUM> to the requesting entity system <NUM> to perform a pseudonymous authentication of the user account associated with user device <NUM>.

The requesting entity system <NUM> may then send a request <NUM> to the user device <NUM> requesting user credentials, and the user may send back requested credentials <NUM> to the requesting entity system <NUM>. Based on the user credentials <NUM>, the requesting entity system <NUM> may generate a first token <NUM> with at least a user ID (e.g., "Bob ID") associated with the user account used to send the user credentials <NUM>. The first token <NUM> may include an encrypted form of the user ID (e.g., a hash of ["Bob ID" + salt]). The first token <NUM> may be signed with a digital signature by the requesting entity system <NUM>.

Next the requesting entity system <NUM> may send the signed first token <NUM> to platform <NUM>, which may first verify that the signed first token <NUM> is legitimate, by for example verifying the digital signature with a public key. Once platform <NUM> has authenticated the first token <NUM> to come from the requesting entity system <NUM>, it may obtain a intermediary ID from the first token <NUM>. In some embodiments, the intermediary ID may be the user ID in the first token <NUM>. In other embodiments, the intermediary ID may be the encrypted or hashed form of the user ID in the first token <NUM>.

Platform <NUM> may next generate a trusted token <NUM> with the stable ID, for example, it may add a random or pseudo-random term "rsalt" to the stable ID, and then encrypt "stable ID + rsalt" with an encryption scheme. The random or pseudo-random term "rsalt" can be uniquely generated for each user request or first token <NUM> received by platform <NUM>, even if multiple user requests came from the same user device <NUM>.

The trusted token <NUM> may further include a domain identifier identifying the requesting entity system <NUM> (e.g., "Organization B"). The trusted token <NUM> may include other information such as a timestamp, an expiry date, a scope of content being requested, and so on. The trusted token <NUM> may be digitally signed by using a private key owned by platform <NUM> and sent to the provisioning entity system <NUM>. The trusted token <NUM> may be encrypted before digitally signed.

The provisoning entity system <NUM> may first verify, using for example a public key corresponding to the private key used to sign the trusted token <NUM> by platform <NUM>, that the trusted token <NUM> has been issued by platform <NUM>, a trusted authentication system.

The provisioning entity system <NUM> may decrypt, if necessary (e.g., if the trusted token <NUM> has been encrypted by platform <NUM>), the trusted token <NUM> to determine information such as the identity of the requesting entity system <NUM> using a domain identifier included in the trusted token. If the requested content can be shared with members of the requesting entity system <NUM>, the provisioning entity system <NUM> can facilitate the access to the requested content <NUM>, and store the access event with the trusted token in an record or log <NUM>, which can be used in the auditing process later.

The record or log <NUM> of the access event by the provisioning entity system <NUM> may include information such as date and time of access, the trusted token in encrypted and/or decrypted form, the domain identifier linked to the requesting entity system <NUM>, and the exact secured content <NUM> accessed, which is then provided by the provisioning entity system <NUM> to the user device <NUM>.

<FIG> is a schematic diagram of another example computing device <NUM> that implements a system (e.g., platform <NUM> from <FIG>) for providing access to secured content stored at a provisoning entity system <NUM>, in accordance with an embodiment. As depicted, computing device <NUM> includes one or more processors <NUM>, memory <NUM>, one or more I/O interfaces <NUM>, and, optionally, one or more network interfaces <NUM>.

Each processor <NUM> may be, for example, any type of general-purpose microprocessor or microcontroller, a digital signal processing (DSP) processor, an integrated circuit, a field programmable gate array (FPGA), a reconfigurable processor, a programmable read-only memory (PROM), or any combination thereof.

Memory <NUM> may include a suitable combination of any type of computer memory that is located either internally or externally such as, for example, random-access memory (RAM), read-only memory (ROM), compact disc read-only memory (CDROM), electro-optical memory, magneto-optical memory, erasable programmable read-only memory (EPROM), and electrically-erasable programmable read-only memory (EEPROM), Ferroelectric RAM (FRAM) or the like. Memory <NUM> may store code executable at processor <NUM>, which causes platform <NUM> to function in manners disclosed herein. Memory <NUM> includes a data storage. In some embodiments, the data storage includes a secure datastore. In some embodiments, the data storage stores received data sets, such as textual data, image data, or other types of data.

Each I/O interface <NUM> enables computing device <NUM> to interconnect with one or more input devices, such as a keyboard, mouse, camera, touch screen and a microphone, or with one or more output devices such as a display screen and a speaker.

Each network interface <NUM> enables computing device <NUM> to communicate with other components, to exchange data with other components, to access and connect to network resources, to serve applications, and perform other computing applications by connecting to a network such as network (or multiple networks) capable of carrying data including the Internet, Ethernet, plain old telephone service (POTS) line, public switch telephone network (PSTN), integrated services digital network (ISDN), digital subscriber line (DSL), coaxial cable, fiber optics, satellite, mobile, wireless (e.g. Wi-Fi, WiMAX), SS7 signaling network, fixed line, local area network, wide area network, and others, including any combination of these.

The methods disclosed herein may be implemented using a system that includes multiple computing devices <NUM>. The computing devices <NUM> may be the same or different types of devices.

Each computing devices may be connected in various ways including directly coupled, indirectly coupled via a network, and distributed over a wide geographic area and connected via a network (which may be referred to as "cloud computing").

For example, and without limitation, each computing device <NUM> may be a server, network appliance, set-top box, embedded device, computer expansion module, personal computer, laptop, personal data assistant, cellular telephone, smartphone device, UMPC tablets, video display terminal, gaming console, electronic reading device, and wireless hypermedia device or any other computing device capable of being configured to carry out the methods described herein.

<FIG> shows an example process performed by platform <NUM> in <FIG> (or the system <NUM> in <FIG>), in accordance with an embodiment. At operation <NUM>, platform <NUM> may receive, through a communication interface from a requesting entity system <NUM>, a plurality of user requests to access secured content stored at a provisioning entity system <NUM>. The plurality of user requests may be stored in database <NUM>, for example.

At operation <NUM>, platform <NUM> may, determine, for each of the plurality of user requests, a respective user ID.

At operation <NUM>, platform <NUM> may generate, for each of the plurality of user requests, a respective trusted token based on the respective user request, the trusted token comprising at least a variable term different for each of the trusted tokens generated for the plurality of user requests.

In some embodiments, the variable term may be uniquely generated for each trusted token.

In some embodiments, the variable term may be generated by encrypting the user ID from the respective user request associated with the trusted token.

In some embodiments, the method may include, prior to generating the respective trusted token, removing user identifying data from the respective user request.

In some embodiments, the user identifying data may include at least one of, a name, a phone number, a physical address, an e-mail address, a media access control (MAC) address, and an IP address.

In some embodiments, the respective trusted token may include data representing an expiry period of the respective trusted token.

In some embodiments, the respective token may include data representing a scope of the requested secured content stored at the provisioning entity system.

At operation <NUM>, platform <NUM> may add a proof of authentication to each of the trusted tokens to enable the provisioning entity system to validate the respective trusted token.

In some embodiments, adding the proof of authentication to a respective trusted token may include adding a digital signature produced using a private key, and wherein the respective trusted token is verifiable using a public key corresponding to the private key.

At operation <NUM>, platform <NUM> may transmit at least one of the trusted tokens to the requesting entity system <NUM>, which may send the trusted token to the provisioning entity system <NUM>. The provisioning entity system <NUM> may verify that the trusted token(s) are issued by platform <NUM> using the public key corresponding to the private key used to add the digital signature to the trusted token. Once verified, the provisioning entity system <NUM> may process the trusted token to determine a domain identifier associated with the requesting entity system <NUM>, and allow access of the requested content by the user of the requesting entity system <NUM>. This access may be logged by the provisioning entity system <NUM> for future auditing purposes.

Operations <NUM>, <NUM><NUM> may be performed for each user request in the plurality of user requests received from the requesting entity system <NUM>.

In some embodiments, platform <NUM> may be further configured to perform: receiving an auditing request including a plurality of user IDs from the requesting entity system; obtaining a plurality of validated trusted tokens used to access one or more secured content at the provisioning entity system; determining, based on the plurality of validated trusted tokens, one or more user IDs from the plurality of user IDs, the one or more user IDs used to access the one or more secured content at the provisioning entity system; and transmitting the one or more user IDs to the requesting entity system in response to the auditing request.

In some embodiments, the auditing request may include a given time period, and the plurality of trusted tokens are used to access the one or more secured content at the provisioning entity system during the given time period.

In some embodiments, determining the one or more user IDs may include: decrypting the plurality of validated trusted tokens to obtain, for each of the plurality of validated trusted tokens, an intermediary term comprising a respective user ID from the one or more user IDs and a respective variable term; and parsing each intermediary term to obtain the respective user ID.

In some embodiments, parsing each intermediary term may include decrypting the respective variable term to obtain the respective user ID.

Embodiments performing the operations for anomaly detection and anomaly scoring provide certain advantages over manually assessing anomalies. For example, in some embodiments, all data points are assessed, which eliminates subjectivity involved in judgement-based sampling, and may provide more statistically significant results than random sampling. Further, the outputs produced by embodiments of system are reproducible and explainable.

The embodiments of the devices, systems and methods described herein may be implemented in a combination of both hardware and software. These embodiments may be implemented on programmable computers, each computer including at least one processor, a data storage system (including volatile memory or non-volatile memory or other data storage elements or a combination thereof), and at least one communication interface.

Program code is applied to input data to perform the functions described herein and to generate output information. The output information is applied to one or more output devices. In some embodiments, the communication interface may be a network communication interface. In embodiments in which elements may be combined, the communication interface may be a software communication interface, such as those for inter-process communication. In still other embodiments, there may be a combination of communication interfaces implemented as hardware, software, and combination thereof.

Throughout the disclosure, numerous references will be made regarding servers, services, interfaces, portals, platforms, or other systems formed from computing devices. It should be appreciated that the use of such terms is deemed to represent one or more computing devices having at least one processor configured to execute software instructions stored on a computer readable tangible, non-transitory medium. For example, a server can include one or more computers operating as a web server, database server, or other type of computer server in a manner to fulfill described roles, responsibilities, or functions.

The disclosure provides many example embodiments. Although each embodiment represents a single combination of inventive elements, other examples may include all possible combinations of the disclosed elements. Thus if one embodiment comprises elements A, B, and C, and a second embodiment comprises elements B and D, other remaining combinations of A, B, C, or D, may also be used.

The embodiments and examples described herein are illustrative and nonlimiting. Practical implementation of the features may incorporate a combination of some or all of the aspects, and features described herein should not be taken as indications of future or existing product plans. Applicant partakes in both foundational and applied research, and in some cases, the features described are developed on an exploratory basis.

Although the embodiments have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the scope as defined by the appended claims.

Moreover, the scope of the present application is not intended to be limited to the particular embodiments of the process, machine, manufacture, composition of matter, means, methods and steps described in the specification. As one of ordinary skill in the art will readily appreciate from the disclosure of the present invention, processes, machines, manufacture, compositions of matter, means, methods, or steps, presently existing or later to be developed, that perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein may be utilized.

Claim 1:
A computer-implemented method for providing access to secured content (<NUM>) on a provisioning entity system (<NUM>), comprising:
receiving, from a requesting entity system (<NUM>), a plurality of user requests to access the secured content (<NUM>) stored at the provisioning entity system, each of the plurality of user requests received from a user of the requesting entity system (<NUM>) and comprising a respective user ID and respective user identifying data, the user ID identifying the user with the requesting entity system (<NUM>) without identifying the user with the provisioning entity system (<NUM>);
determining, for each of the plurality of user requests, the respective user ID;
deleting the respective user identifying data from each of the plurality of user requests;
generating, for each of the plurality of user requests having the respective user identifying data deleted therefrom, a respective trusted token (<NUM>) based on the respective user request, the trusted token (<NUM>) comprising at least a variable term different for each of the trusted tokens (<NUM>) generated for the plurality of user requests;
adding a proof of authentication to each of the trusted tokens (<NUM>) to enable the provisioning entity system (<NUM>) to validate the respective trusted token (<NUM>); and
transmitting at least one of the trusted tokens (<NUM>) to the requesting entity system (<NUM>) for use by the requesting entity system (<NUM>) in a subsequent request to the provisioning entity system (<NUM>) to access the secured content.