Source: https://patents.google.com/patent/US8910255B2/en
Timestamp: 2019-09-19 11:13:04
Document Index: 503426098

Matched Legal Cases: ['Application No. 200980120235', 'Application No. 200980120235', 'Application No. 200980120235', 'Application No. 200980120235', 'Application No. 200980120235', 'Application No. 200980120235', 'Application No. 200980120235', 'Application No. 200980120235', 'Application No. 2011', 'Application No. 2011', 'Application No. 2011', 'Application No. 2011']

US8910255B2 - Authentication for distributed secure content management system - Google Patents
Authentication for distributed secure content management system Download PDF
US8910255B2
US8910255B2 US12/127,803 US12780308A US8910255B2 US 8910255 B2 US8910255 B2 US 8910255B2 US 12780308 A US12780308 A US 12780308A US 8910255 B2 US8910255 B2 US 8910255B2
US12/127,803
US20090300739A1 (en
2008-05-27 Priority to US12/127,803 priority Critical patent/US8910255B2/en
2008-05-27 Assigned to MICROSOFT CORPORATION reassignment MICROSOFT CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: TEPLITSKY, ALEXANDER, ANANIEV, OLEG, FINKELSTEIN, AMIT, NICE, NIR, WOHLFERT, JOHN F.
2009-12-03 Publication of US20090300739A1 publication Critical patent/US20090300739A1/en
2014-12-09 Publication of US8910255B2 publication Critical patent/US8910255B2/en
Aspects of the subject matter described herein relate to authentication for a distributed secure content management system. In aspects, a request to access a resource available through the Internet is routed to a security component. The security component is one of a plurality of security components distributed throughout the Internet and responsible for authenticating entities associated with an enterprise. The security component determines an authentication protocol to use with the entity and then authenticates the entity. If the entity is authenticated, the entity is allowed to use a forward proxy.
Traditionally, enterprises have employed functionality included in various security products and appliances to protect company information technology assets. Such functionality may include, for example, filtering network traffic into and out of the enterprise for malicious code such as malware, limiting access to inappropriate external content, preventing attacks and other intrusions on the enterprise network, and so forth.
With the widespread availability of mobile, home, and other computing devices, employees have taken work to locations outside the corporate network. To obtain the same level of protection and to enforce policies as provided on the enterprise network, some enterprises have required such employees to log on to or otherwise access the enterprise network and to access resources outside of the enterprise network through the enterprise network. For various reasons, this becomes non-optimal when a roaming user is not close to the enterprise network.
Briefly, aspects of the subject matter described herein relate to authentication for a distributed secure content management system. In aspects, a request to access a resource available through the Internet is routed to a security component. The security component is one of a plurality of security components distributed throughout the Internet and responsible for authenticating entities associated with an enterprise. The security component determines an authentication protocol to use with the entity and then authenticates the entity. If the entity is authenticated, the entity is allowed to use a forward proxy.
FIG. 3 is a block diagram that represents an exemplary apparatus configured with security components in accordance with aspects of the subject matter described herein; and
FIGS. 4-5 are flow diagrams that generally represent actions that may occur in conjunction with authentication in accordance with aspects of the subject matter described herein.
Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile discs (DVDs) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the computer 110.
The computer 110 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only, FIG. 1 illustrates a hard disk drive 141 that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive 151 that reads from or writes to a removable, nonvolatile magnetic disk 152, and an optical disc drive 155 that reads from or writes to a removable, nonvolatile optical disc 156 such as a CD ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile discs, other optical discs, digital video tape, solid state RAM, solid state ROM, and the like. The hard disk drive 141 is typically connected to the system bus 121 through a non-removable memory interface such as interface 140, and magnetic disk drive 151 and optical disc drive 155 are typically connected to the system bus 121 by a removable memory interface, such as interface 150.
The drives and their associated computer storage media, discussed above and illustrated in FIG. 1, provide storage of computer-readable instructions, data structures, program modules, and other data for the computer 110. In FIG. 1, for example, hard disk drive 141 is illustrated as storing operating system 144, application programs 145, other program modules 146, and program data 147. Note that these components can either be the same as or different from operating system 134, application programs 135, other program modules 136, and program data 137. Operating system 144, application programs 145, other program modules 146, and program data 147 are given different numbers herein to illustrate that, at a minimum, they are different copies. A user may enter commands and information into the computer 20 through input devices such as a keyboard 162 and pointing device 161, commonly referred to as a mouse, trackball, or touch pad. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, a touch-sensitive screen, a writing tablet, or the like. These and other input devices are often connected to the processing unit 120 through a user input interface 160 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB). A monitor 191 or other type of display device is also connected to the system bus 121 via an interface, such as a video interface 190. In addition to the monitor, computers may also include other peripheral output devices such as speakers 197 and printer 196, which may be connected through an output peripheral interface 190.
As mentioned previously, employees often work outside of a business network. At the same time, however, a business would like to be able to provide the same level of protection, provide reports based on user activity, and to apply the same policies as are applied when the user uses the business network to access remote network resources.
In accordance with aspects of the subject matter described herein, there are provided one or more forward proxies that are located in the cloud. Logically, a forward proxy sits between a client and a network resource the client is attempting to access. A forward proxy receives requests from a client, provides connectivity to the client to resources requested, and may provide other functions identified above, as appropriate, to these requests. A forward proxy may be associated with one or more security components that authenticate entities and log activity associated therewith. These components may authenticate an entity using a variety of authentication protocols and may communicate with an identity system located at an enterprise site to perform this authentication. The components may also obtain an identifier to use in logging entity activity.
Being associated with a security component means that the forward proxy may include all or a portion of the security component or that all or a portion of the security component may be located outside of the forward proxy.
FIG. 2 is a block diagram that generally represents an exemplary environment in which aspects of the subject matter described herein may be implemented. The environment illustrated in FIG. 2 may include roaming devices 205-206, a home device 207, enterprise devices 208, a network access device 209, and an identity system 210 (hereinafter sometimes collectively referred to as the entities) and may include other entities (not shown). The various entities may communicate via various networks including intra- and inter-office networks and the network 215.
In an embodiment, the network 215 may comprise the Internet. In an embodiment, the network 215 may comprise one or more local area networks, wide area networks, direct connections, some combination of the above, and the like.
The devices 205-208 may comprise one or more general or special purpose computing devices. Such devices may include, for example, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microcontroller-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, personal digital assistants (PDAs), gaming devices, printers, appliances including set-top, media center, or other appliances, automobile-embedded or attached computing devices, other mobile devices, distributed computing environments that include any of the above systems or devices, and the like. An exemplary device that may be configured to act as one or more of the devices 205-208 comprises the computer 110 of FIG. 1.
The roaming devices 205-206 may comprise computing devices that are taken from location to location. For example, an employee may take a notebook computer on a business trip. As another example, an employee may travel with a cell phone, PDA, or some other handheld device which the employee may use almost anywhere.
The home device 207 may comprise, for example, a personal computer or other electronic device located at an employee's home.
The enterprise devices 208 may comprise devices that are located at one or more business sites and connected to a business network. For example, the enterprise devices 208 may include workstations, servers, routers, mobile devices, and other of the general and special purpose computing devices mentioned previously.
The network access device 209 may comprise one or more devices and/or software components configured to permit, deny, proxy, transmit, cache, or perform other actions on computer traffic. Configured as a firewall, the network access device 209 may act to provide protection to the enterprise devices 208 and the identity system 210 and other devices, if any, connected behind the network access device 209. The network access device 209 may be configured as an endpoint to a virtual private network. In such a configuration, the network access device 209 may provide a secure communication channel to one or more of the forward proxies 220-222 as well as to other components attached to the network 215, such as the local identity system 230. A secure communication channel with the local identity system 230 may be used to establish one way or two way trust relationship between the identity system 210 and the local identity system 230. In one embodiment, the network access device 209 may comprise, for example, the computer 110 of FIG. 1 configured with the appropriate hardware and software. In another embodiment, the network access device 209 may comprise a special purpose appliance.
The identity system 210 may comprise one or more processes hosted on one or more devices such as the devices mentioned above. The identity system 210 may be utilized to identify users and/or devices as will be described in more detail below. In one embodiment, the identity system 210 may comprise an Active Directory produced by Microsoft Corporation of Redmond, Wash. Other examples of identity systems include RADIUS based ID systems, LDAP based ID systems, generic database ID systems, and the like.
As illustrated in FIG. 2, in one embodiment, the identity system 210 resides on an enterprise network accessible through the network access device 209. In another embodiment, the identity system 210 may reside on a network external to an enterprise's network. For example, the identity system 210 may reside or be distributed at various locations within the network 215. In one embodiment, the identity system 210 may be a service hosted by a server attached to the network 215.
Forward proxies 220-222 are located at various locations accessible via the network. These forward proxies may provide various functions such as connectivity, anti-virus, spyware, and phishing protection, URL filtering, firewall, intrusion detection, information leakage prevention (ILP), and the like that are sometimes provided by devices in an enterprise network. The forward proxies 220-222 may also provide centralized management to roaming devices connected to the network 215. The forward proxies 220-220 may also provide other functions to various devices, such as rendering for mobile devices, caching of Web pages and other content, and any other connectivity and/or security functions that may be desired by an enterprise.
When a device attempts to access a resource connected to the network 215, traffic to and from the device may be routed to a forward proxy to provide one or more of the functions described above, for example. Before a device is provided these functions, however, a security component associated with the forward proxy authenticates the device and/or a user using the device. In the context of authentication, the term entity is sometimes used herein to indicate a device and/or a user using the device.
Authenticating an entity may be done for various reasons. For example, it may be desired that only registered entities be allowed to use the forward proxy. To ensure that this occurs, authentication may be performed. As another example, authenticating an entity may be used for identification to know what policies to apply to traffic routed to and from the device. As yet another example, authenticating an entity may be used for reporting, auditing, and otherwise tracking activities of the entity.
The example reasons for authenticating an entity mentioned above are not intended to be all-inclusive or exhaustive. Neither is it intended to limit aspects of the subject matter described herein to implementations that involve one or more of the examples above. Indeed, based on the teachings herein, those skilled in the art may recognize many other scenarios in which concepts presented herein may be applied without departing from the spirit or scope of aspect of the subject matter described herein.
In authenticating an entity based on enterprise credentials, information from the identity system 210 may be transmitted to a security component that is attempting to authenticate an entity. In one embodiment, a security component may not maintain its own database of credentials for entities that are authorized to use the forward proxy. Instead, credentials may be stored at an enterprise-controlled location such as on a credentials database accessible via the identity system 210. This may be done for various reasons. For example, with no credentials databases in the cloud, the system can avoid maintaining and synchronizing credential databases stored in the cloud and credential databases stored on an enterprise network. Also, as a cloud credential database may be controlled by a party other than the enterprise, having the credential database stored on the enterprise network may pose less of a security risk. As another benefit, new entities that are recently created on the enterprise network may immediately access the forward proxy as these entities do not need to wait for synchronization. In addition, entities that are no longer allowed to access a forward proxy may be immediately denied access to a forward proxy by removing their credentials from the credential database. Furthermore, reports generated regarding network activity of an entity can track the entity regardless of the location from which the entity accesses a forward proxy.
In this embodiment, to authenticate an entity, a security component may communicate as needed with the identity system 210 to obtain enough information to authenticate the entity. Such information may include, for example, the entity credentials, challenge/response data, certificate-related information, or any other information usable to authenticate the entity.
In another embodiment, a security component may have access to a local identity system 230 that is synchronized with the identity system 210 using a one-way or two-way trust relationship. In a one-way trust relationship, entities that are authenticated using the enterprise credentials synchronized to the local identity system 230 are allowed to access resources via a forward proxy.
Communication between a security component and the identity systems 210 and 230 may be done in a variety of ways, including, for example, a virtual private network (VPN), Multi Protocol Label Switching (MPLS), Internet Protocol security (IPSec), Internet Protocol version 6 (IPv6) global addressing, other communication protocols, and the like.
In one embodiment, only the port(s) needed by the particular communication protocol may be involved in a virtual private network between an identity system and a security component. In other words, messages to ports that are involved in the communication protocol may be forwarded, while messages to ports that are not involved in the communication protocol may not be forwarded. This may assist in maintaining the security of the enterprise network as the attack surface (e.g., number of ports forwarded) may be greatly reduced.
The forward proxies and the identity systems may be configured to communicate via IPv6. In conjunction with IPsec and configured policy, this may be used to guarantee that only specified forward proxies are allowed to communicate with the identity systems.
To authenticate an entity, a security component associated with a forward proxy may use one or more of many different mechanisms. For example, a virtual private network (VPN) may be established between a security component and a device. In such a configuration, that the VPN was successfully established may serve to authenticate an entity. As other examples, Integrated Windows® authentication, IPSec, form based authentication, RADIUS, MPLS, Basic access authentication, Kerberos, client certificate based authentication, some other authentication protocols, or the like may be used to authenticate an entity. In one embodiment, an authentication may be initiated as part of an HTTP proxy authentication.
The type of authentication protocol may be negotiated between a security component and the device. For example, if a device supports a first set of authentication protocols and a security component supports a second set of authentication protocols, an authentication protocol that both the device and the security component support may be selected to authenticate the entity. As another example, if the device supports an authentication protocol that allows the device to authenticate itself and/or a user without user interaction (e.g., such as Integrated Windows® Authentication), this protocol may be selected.
There are many ways to authenticate an entity. For example, to authenticate an entity, a security component may ask for the entity credentials (e.g., username and password or other credentials associated with the entity). Using these credentials, the security component may communicate with the identity system 210 to verify the credentials. To do this, the entity may use Basic, form, RADIUS, or some other authentication protocol, for example.
If the credentials are valid, the identity system 210 may indicate this to the security component and send an identifier associated with the entity to the security component. This identifier may comprise an enterprise identity of the entity. This identifier may be used in logging subsequent activity by the entity.
As another example to authenticate an entity, a security component may authenticate credentials without receiving the credentials. For example, the security component may provide a challenge to the entity and may use the response to the challenge to authenticate the entity. The security component may involve the identity system 210 in determining a challenge and/or validating a response to a challenge.
As another example, a security component may be associated with a local identity system 230 that is synchronized with the identity system 210 using a one-way or two-way trust relationship. The security component may utilize the local identity system 230 to authenticate an entity.
As another example, secure socket layer (SSL) and/or transport layer security (TLS) capabilities may be added to the proxy capabilities defined in the HTTP protocol. The current HTTP protocols for HTTP proxies do not provide for using SSL or TLS in an HTTP proxy. An HTTP proxy may be enhanced to use SSL and/or TLS when communicating with a client. SSL/TLS may also be used for mutual authentication. As part of the establishment of a connection, the client may be authenticated via SSL or TLS. In this authentication method, the security component may authenticate the client, for example, by verifying that the client certificate is signed by a trusted Certificate Authority. Adding SSL/TLS to an HTTP proxy may also enable secure (e.g., encrypted) communication between an end-point and the forward proxy.
In one embodiment, after the first authentication between a client and a security component, a cookie may be provided to the client to use with subsequent requests. The current HTTP protocol allows for a target server to provide a cookie to a client but does not allow an HTTP proxy to independently generate and supply a cookie to the client. Furthermore, in the current HTTP protocol, the client is to provide the cookie only when communicating with the target server that sent the cookie to the client.
When a forward proxy functions as an HTTP proxy, the forward proxy (or a security component associated therewith) may generate and send the client a cookie after the client has been authenticated. In subsequent requests, the client may then send this cookie to the forward proxy (or a security component associated therewith) that provided the cookie to the client or to another forward proxy. The client may also send this cookie even when the client seeks to access a resource on a different target server.
When the client sends the cookie in a subsequent request, the forward proxy (or a security component associated therewith) may examine the cookie to determine that the client is already authenticated. This may avoid overhead associated with re-authenticating with each request received from the client. The cookie may be configured with a time to live parameter such that it expires after a set time.
A cookie as used herein includes any data that may be used to verify that an entity has been already been authenticated. For example, a cookie may include an identifier that may be used by a security component to access a record of a database. The record may indicate whether the entity has been authenticated. As another example, a cookie may include encrypted information that the security component is capable of decrypting to determine whether the entity has been authenticated.
A cookie may also include other data regarding an entity. For example, a cookie may include an identifier associated with the entity. This identifier may correspond to an identifier the entity uses when accessing an enterprise network, for example. This identifier may be used when logging entity activity. As another example, the cookie may include policy information associated with the entity. For example, the cookie may include information that indicates what sites the entity is allowed to access.
Another mechanism that may be used to authenticate an entity is via a connection component (e.g., the connection component 125). A connection component is a component that resides on a device and that monitors connections from the device. For example, a connection component may monitor TCP traffic sent to and from a device. When the connection component sees a connection request that is to be routed to a forward proxy, the connection component may authenticate with a security component associated with the forward proxy and encrypt the connection. This may be done in such a way as to be transparent to the user using the device. When the user enters a request (e.g., a URL request) that needs to be routed through a forward proxy, the connection component may authenticate with a security component associated with the forward proxy and then forward the request to the forward proxy over a secure channel.
In one embodiment, when a cookie is provided to an entity for use in authentication in subsequent requests, a connection component may handle the cookie and provide it in subsequent requests. In another embodiment, when a cookie is provided to an entity for use in authentication in subsequent requests, the connection component may allow the entity to handle the cookie and to provide the cookie in subsequent requests.
Although examples of some mechanisms for authenticating an entity have been provided above, these examples are not intended to be all-inclusive or exhaustive. Indeed, aspects of the subject matter described herein are not limited to the authentication method as virtually any authentication method, existing or to be developed, may be employed without departing from the spirit or scope of aspects of the subject matter described herein.
As a result of authentication process, an identifier may be obtained that may then used for logging, auditing, applying policy, and the like. This identifier may be provided by the identity system 210, by the local identity system 230, or by some other component without departing from aspects of the subject matter described herein. The identifier may by the same identifier used to identify the entity to an enterprise network associated with the entity.
Although the environment described above includes various numbers of each of the entities and related infrastructure, it will be recognized that more, fewer, or a different combination of these entities and others may be employed without departing from the spirit or scope of aspects of the subject matter described herein. Furthermore, the entities and communication networks included in the environment may be configured in a variety of ways as will be understood by those skilled in the art without departing from the spirit or scope of aspects of the subject matter described herein.
FIG. 3 is a block diagram that represents an exemplary apparatus configured with security components in accordance with aspects of the subject matter described herein. The components illustrated in FIG. 3 are exemplary and are not meant to be all-inclusive of components that may be needed or included. In other embodiments, the components or functions described in conjunction with FIG. 3 may be included in other components or placed in subcomponents without departing from the spirit or scope of aspects of the subject matter described herein. In some embodiments, the components or functions described in conjunction with FIG. 3 may be distributed across multiple devices that are accessible to the apparatus 305.
Turning to FIG. 3, the apparatus 305 may include security components 310, a store 340, and communications mechanism 345. The security components 310 may include a protocol selector 315, a client component 320, an identity validator 325, a proxy informer 330, a history tracker 335, and a reporting component 337. The security components 310 may be associated with the forward proxies described in conjunction with FIG. 1. Associated with context means included on the same device, located on one or more devices that do not host a forward proxy but can communicate with a forward proxy, and the like.
The store 340 is any storage media capable of storing history information regarding activities engaged in by entities. The store 340 may comprise a file system, database, volatile memory such as RAM, other storage, some combination of the above, and the like and may be distributed across multiple devices. The store 340 may be external or internal to the apparatus 305.
The protocol selector 315 is operable to determine an authentication protocol to utilize in conjunction with authenticating an entity seeking to gain access to a resource available via a first network. For example, referring to FIG. 2, a protocol selector may determine an authentication protocol to use to authenticate one of the devices 205-208 when these devices seek to access a resource accessible via the network 215.
The client component 320 is operable to authenticate an entity using the authentication protocol determined by the protocol selector 315. The entity may comprise a user using the device and/or the device. For example, referring to FIG. 2, a client component may use mutual TLS protocol to authenticate a user using the roaming device 205.
The identity validator 325 is operable to obtain an identifier associated with the entity from an identity system. The identity system may be located on a local network or network external to the client component 320 as previously indicated. The identity system may have access to a database that includes identifiers for entities that are associated with an enterprise that controls this network (e.g., an enterprise network) that is external to the client component 320. For example, referring to FIG. 2, an identity validator may communicate with the identity system 210 to obtain the identifier.
The proxy informer 330 is operable to indicate to a forward proxy whether an entity is authenticated based on results obtained from the client component 320. For example, referring to FIG. 2, a proxy informer may indicate to one of the forward proxies 220-222 that an entity is authenticated to use the security functions provided by the forward proxy.
The history tracker 335 is operable to store information identifying an entity and resources accessed by the entity. For example, referring to FIG. 2, a history tracker may store a username with each URL sent to the forward proxy 220 by the user using the roaming device 205. The history tracker 335 may utilize the store 340 to store history information.
The reporting component 337 is operable to provide the history information in a form that identifies the entity and the resources (e.g., URLs, network addresses, and so forth) accessed by the entity. This form may include a username or other identifier together with a resource identifier. Because the information includes enough information to identify an entity on the enterprise, if the device becomes contaminated (e.g., via malware), when the user brings the device to the enterprise network, a report may indicate that the device has been contaminated and needs to be cleaned before being allowed to access the corporate network.
FIGS. 4-5 are flow diagrams that generally represent actions that may occur in conjunction with authentication in accordance with aspects of the subject matter described herein. For simplicity of explanation, the methodology described in conjunction with FIGS. 4-5 is depicted and described as a series of acts. It is to be understood and appreciated that aspects of the subject matter described herein are not limited by the acts illustrated and/or by the order of acts. In one embodiment, the acts occur in an order as described below. In other embodiments, however, the acts may occur in parallel, in another order, and/or with other acts not presented and described herein. Furthermore, not all illustrated acts may be required to implement the methodology in accordance with aspects of the subject matter described herein. In addition, those skilled in the art will understand and appreciate that the methodology could alternatively be represented as a series of interrelated states via a state diagram or as events.
Turning to FIG. 4, at block 405, the actions begin. At block 407, a trust relationship may be established. For example, referring to FIG. 2, the local identity system 230 may establish a trust relationship with the enterprise identity system 210. At block 410 a device attempts to access a resource on a network external to the device (e.g., the Internet). For example, referring to FIG. 2, the roaming device 206 attempts to access a resource (e.g., a Web page) available via the network 215.
At block 415, the request is routed to a security component associated with a forward proxy. For example, referring to FIG. 2, the connection component 125 routes the request to a security component associated with the forward proxy 222.
At block 420, the security component receives the message from the device. For example, referring to FIG. 3, the security component 310 receives the request.
At block 425, an authentication protocol by which an entity associated with the device is to be authenticated is determined. For example, referring to FIG. 310, the protocol selector 315 determines an authentication protocol to use in authenticating the user associated with the roaming device 206 of FIG. 2.
At block 430, the security component authenticates an entity associated with the device. For example, referring to FIGS. 2 and 3, the client component 320 authenticates a user associated with the roaming device 206.
At block 435, when cookies are used, a cookie is sent to the device to use in subsequent requests. For example, referring to FIG. 2, a security component associated with the forward proxy 222 sends a cookie to the roaming device 206.
At block 440, the device sends the cookie in subsequent requests. For example, referring to FIG. 2, the roaming device 206 sends the cookie it received in subsequent requests for resources accessible via the network 215.
At block 445, other actions, if any, may occur. For example, periodically, the entity may be re-authenticated.
Turning to FIG. 5, at block 505, the actions begin. At block 510, a request to access a resource on a second network is sent from an entity associated with a device attached to a first network. For example, referring to FIG. 2, a request to access a resource accessible via the network 215 is sent from an entity associated with the device 206.
At block 515, the request is received at a communication component. For example, referring to FIG. 2, the communication component 125 receives the request.
At block 520, the entity is authenticated via the communication component. For example, referring to FIG. 2, the communication component 125 communicates with a security component associated with the forward proxy 222 to authenticate a user using the device 206.
At block 525, the request is sent to a forward proxy. For example, referring to FIG. 2, the request from the device 206 is sent to the forward proxy 222.
At block 530, a cookie may be received at the device. The cookie indicates that the entity has been previously authenticated by the security component. This may occur, for example, to speed subsequent authentications.
At block 535, the cookie is sent in subsequent requests. For example, referring to FIG. 2, the communication component 125 may send the cookie in subsequent requests for resources.
At block 540, other actions, if any, may occur.
As can be seen from the foregoing detailed description, aspects have been described related to authentication in a distributed security content management system. While aspects of the subject matter described herein are susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit aspects of the claimed subject matter to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of various aspects of the subject matter described herein.
receiving, at a security component, a message sent from a device, the security component being associated with a forward proxy that is logically between the device and a resource to which the device seeks access;
authenticating, via the security component, an entity associated with the device;
sending a cookie to the device, the cookie indicating that the entity has been previously authenticated by the security component, the device to present the cookie with subsequent requests for access to resources accessible via the forward proxy, the forward proxy providing connectivity of the device to the resource;
establishing a time to live for the cookie, the cookie being no longer useful for authentication after the time to live has expired, wherein the cookie includes policy information associated with the entity usable to enforce a policy for the subsequent requests, the policy information comprising indication of sites the entity is allowed to access; and
storing information identifying the entity.
2. The method of claim 1, wherein the forward proxy operates at least as a HyperText Transfer Protocol (HTTP) proxy and wherein authenticating an entity associated with the device comprises establishing a secure connection between the forward proxy and the device.
3. The method of claim 2, wherein the secure connection comprises a secure socket layer connection.
4. The method of claim 2, wherein the secure connection comprises a transport layer security connection.
5. The method of claim 1, wherein the forward proxy operates at least as a HyperText Transfer Protocol (HTTP) proxy and wherein authenticating an entity associated with the device comprises using a client certificate.
6. The method of claim 1, wherein the cookie indicates an identity associated with the entity, the identity identifying the entity on a network controlled by a business entity associated with the entity associated with the device.
7. The method of claim 6, further comprising storing a history of subsequent requests sent by the device along with an identifier.
8. The method of claim 1, further comprising establishing a trust relationship between a first identity system located on a first network local to the forward proxy and a second identity system on a network external to the first network.
9. The method of claim 8, wherein establishing a trust relationship comprises synchronizing credentials between the first and second identity systems.
10. The method of claim 1, further comprising obtaining an identifier used for the storing information identifying the entity.
11. A computer storage memory having computer-executable instructions, which when executed perform actions, comprising:
sending, from an entity associated with a device attached to a first network, a request to access a resource from a second network;
receiving the request at a component residing on the device, the component monitoring traffic between the device and the second network;
before sending the request to the second network, using a protocol that allows the device to authenticate itself without user interaction, transparent to a user of the device, authenticating the entity via the component by communicating with a security component associated with a forward proxy attached to the second network, the forward proxy being logically between the device and the second network;
sending the request to the forward proxy over a secure channel; and
receiving a cookie from the forward proxy, the cookie indicating that the entity has been previously authenticated by the security component.
12. The computer storage memory of claim 11, wherein the forward proxy operates at least as a HyperText Transfer Protocol (HTTP) proxy and wherein authenticating, via the component, an entity associated with the device comprises using a client certificate.
13. The computer storage memory of claim 11, further comprising handling the cookie via the component, wherein handling the cookie comprises storing the cookie and sending the cookie in a subsequent request for a resource that is accessible via the second network.
14. The computer storage memory of claim 11, wherein the entity comprises the device and/or a user.
15. In a computing environment, an apparatus comprising:
a protocol selector operable to negotiate an authentication protocol with a device associated with an entity, the authentication protocol utilized in conjunction with authenticating the entity seeking to gain access to a resource available via a first network;
a client component operable to authenticate the entity using the authentication protocol via the device associated with the entity;
an identity validator operable to obtain an identifier for the entity from a first identity system having a trust relationship with a second identity system, the first identity system residing on the first network, the second identity system residing on a second network, wherein the second network is different than the first network;
a proxy informer operable to indicate to a forward proxy whether the entity is authenticated, the forward proxy being one of a plurality of forward proxies distributed across one or more networks, the forward proxies structured to allow authenticated entities to access resources available via the one or more networks;
a history tracker operable to store information identifying the entity and information identifying resources accessed by the entity that are available via the first network; and
a reporting component operable to provide the information in a form that identifies the entity and the resources accessed.
16. The apparatus of claim 15, the history tracker further operable to store a username with each Universal Resource Locator (URL) accessed by the entity.
US12/127,803 2008-05-27 2008-05-27 Authentication for distributed secure content management system Active 2029-12-17 US8910255B2 (en)
US12/127,803 US8910255B2 (en) 2008-05-27 2008-05-27 Authentication for distributed secure content management system
PCT/US2009/038673 WO2009151730A2 (en) 2008-05-27 2009-03-27 Authentication for distributed secure content management system
CN200980120235.1A CN102047262B (en) 2008-05-27 2009-03-27 Authentication for distributed secure content management system
JP2011511664A JP5539335B2 (en) 2008-05-27 2009-03-27 Authentication for distributed secure content management system
EP09763023.0A EP2304639A4 (en) 2008-05-27 2009-03-27 Authentication for distributed secure content management system
JP2013228511A JP5714078B2 (en) 2008-05-27 2013-11-01 Authentication for distributed secure content management system
US20090300739A1 US20090300739A1 (en) 2009-12-03
US8910255B2 true US8910255B2 (en) 2014-12-09
ID=41381539
US12/127,803 Active 2029-12-17 US8910255B2 (en) 2008-05-27 2008-05-27 Authentication for distributed secure content management system
US (1) US8910255B2 (en)
EP (1) EP2304639A4 (en)
JP (2) JP5539335B2 (en)
CN (1) CN102047262B (en)
WO (1) WO2009151730A2 (en)
US20130160144A1 (en) * 2011-12-14 2013-06-20 Microsoft Corporation Entity verification via third-party
US9794227B2 (en) 2014-03-07 2017-10-17 Microsoft Technology Licensing, Llc Automatic detection of authentication methods by a gateway
US9769661B2 (en) 2015-04-06 2017-09-19 Qualcomm, Incorporated Wireless network fast authentication / association using re-association object
CN1516833A (en) 2001-05-10 2004-07-28 国际商业机器公司 Method and apparatus for serving content from semi-trusted server
CN1540944A (en) 2003-04-21 2004-10-27 日本电气株式会社 Network insertion system
JP2004355073A (en) 2003-05-27 2004-12-16 Nippon Telegr & Teleph Corp <Ntt> Network authentication, batch authentication method for single sign-on, and system therefor
JP2005011098A (en) 2003-06-19 2005-01-13 Fujitsu Ltd Proxy authentication program, method, and device
CN1581771A (en) 2003-08-14 2005-02-16 国际商业机器公司 Authentication system, server, and authentication method and program
JP2005184463A (en) 2003-12-19 2005-07-07 Toshiba Corp Communication apparatus and communication method
US20060015645A1 (en) 2004-07-13 2006-01-19 Teneros, Inc. Network traffic routing
US20060026683A1 (en) 2004-07-30 2006-02-02 Lim Keng Leng A Intrusion protection system and method
JP2006526184A (en) 2003-05-12 2006-11-16 株式会社エヌ・ティ・ティ・ドコモ Network security methods and network security system
US20070033641A1 (en) 2005-07-07 2007-02-08 Acenet Technology Inc. Distributed Network Security System
US20070067847A1 (en) 2005-09-22 2007-03-22 Alcatel Information system service-level security risk analysis
JP2007164661A (en) 2005-12-16 2007-06-28 Fuji Xerox Co Ltd Program, device and method for user authentication
US20070194097A1 (en) 2006-02-23 2007-08-23 Rockwell Automation Technologies, Inc. Data acquisition and processing system for risk assessment
JP2007241717A (en) 2006-03-09 2007-09-20 Bps Kk Portal server system
CN101064604A (en) 2006-04-29 2007-10-31 西门子公司 Remote access process, system and equipment
US20070294749A1 (en) 2006-06-15 2007-12-20 Microsoft Corporation One-time password validation in a multi-entity environment
JP2008003745A (en) 2006-06-21 2008-01-10 Sharp Corp Authentication system and authentication method
US20080052771A1 (en) 2004-06-29 2008-02-28 Frederic Delmond Method and System for Certifying a User Identity
JP2008083937A (en) 2006-09-27 2008-04-10 Ntt Data Corp Information processor, management method and computer program
US20080127333A1 (en) 2006-08-04 2008-05-29 Gabriel Raffi T Verification Authentication System and Method
US20080159313A1 (en) 2006-12-28 2008-07-03 Nokia Corporation Interworking policy and charging control and network address translator
US20080229385A1 (en) 2007-01-31 2008-09-18 Feder Peretz M Mobility Aware Policy and Charging Control in a Wireless Communication Network
US7496658B2 (en) 2003-07-08 2009-02-24 Hewlett-Packard Development Company, L.P. Systems and methods for testing network services
US20100106599A1 (en) 2007-06-26 2010-04-29 Tyler Kohn System and method for providing targeted content
2008-05-27 US US12/127,803 patent/US8910255B2/en active Active
2009-03-27 EP EP09763023.0A patent/EP2304639A4/en active Pending
2009-03-27 JP JP2011511664A patent/JP5539335B2/en active Active
2009-03-27 WO PCT/US2009/038673 patent/WO2009151730A2/en active Application Filing
2009-03-27 CN CN200980120235.1A patent/CN102047262B/en active IP Right Grant
2013-11-01 JP JP2013228511A patent/JP5714078B2/en active Active
US20040255166A1 (en) 2003-04-21 2004-12-16 Hiroshi Shimizu Network access system
"Comprehensive Computer Network Security Assessment", Tech Genix Ltd., Published Oct. 16, 2002, pp. 1-12.
"Configuring Stirling to Work with Forefront Threat Management Gateway", retrieved at <<http://www.google.co.in/search?hl=en&q=Configuring+Stirling+to+Work+with+Forefront+Threat+Management+Gateway&btnG=Google+Search&meta=>>, Microsoft Corporation, 2008, pp. 1-6.
"Content Management Solutions", retrieved at <<http://www.netrust.com.sg/products—contentmgmt.html>>, Jun. 5, 2008, p. 1.
"Content Management Solutions", retrieved at >, Jun. 5, 2008, p. 1.
"Entrust GetAccess Named as Approved E-Authentication Solution for Government Web Portal Applications", Entrust Inc., pp. 2.
"Global Content Management Solution", retrieved at <<http://www.rsd.com/en/global-content-management.html, Jan. 31, 2008 pp. 1-2.
"HP Assessment Management Platform Software", Hewlett-Packard Development Company, retrieved at <<http://h10078.www1.hp.com/cda/hpms/display/main/hpms—content.jsp . . . >>, Copyright 2008, p. 1.
"HP Assessment Management Platform Software", Hewlett-Packard Development Company, retrieved at >, Copyright 2008, p. 1.
"Identity Management Solutions", 1994-2008, Sun Microsystems, Inc., pp. 2.
"Information Security-Network Assessment", White Paper, Computer Technology Associates, Inc., Published Mar. 2002, pp. 1-12.
"Information Security—Network Assessment", White Paper, Computer Technology Associates, Inc., Published Mar. 2002, pp. 1-12.
"Introducing Stirling—Walkthroughs", Microsoft Forefront System Security, retrieved at <<http://technet.microsoft.com/en-us/library/cc441338.aspx>>, May 12, 2008, p. 1.
"Introducing Stirling-Walkthroughs", Microsoft Forefront System Security, retrieved at >, May 12, 2008, p. 1.
"Leveraging Two-Factor Authentication to Provide Secure Access to Corporate Resources from Blackberry Devices", White Paper, retrieved at <<http://ww.rsaconference.com/uploadfiles/RSA365/Security-Topics/Wireless/White-Papers/RSA/RSA-Authentication-Blackberry-Devices.pdf>>, downloaded Jun. 4, 2008, pp. 1-8.
"Leveraging Two-Factor Authentication to Provide Secure Access to Corporate Resources from Blackberry Devices", White Paper, retrieved at <<http://ww.rsaconference.com/uploadfiles/RSA365/Security—Topics/Wireless/White—Papers/RSA/RSA—Authentication—Blackberry—Devices.pdf>>, downloaded Jun. 4, 2008, pp. 1-8.
"Mutual Authentication", retrieved at <<http://en.wikipedia.org/wiki/Mutual-authentication, pp. 2.
"Mutual Authentication", retrieved at <<http://en.wikipedia.org/wiki/Mutual—authentication, pp. 2.
"On-demand Web security service", Jan. 30, 2007, pp. 1-4, Copyright SurfControl pic.
"Policy.Net: Policy Based Network Traffic Management", Net Veda LLC, 2003-2005, pp. 1-24.
"Remote Authentication Dial in User Service", retrieved at <<http://en.wikipedia.org/wiki/RADIUS>>, pp. 6.
"Remote Authentication Dial in User Service", retrieved at >, pp. 6.
"Secure Enterprise Content Management for Government Agencies", 2005, EMC Corporation, pp. 2.
"Security and Authentication in Content Management Server", Microsoft Corporation, 2008, pp. 13.
Abstract of CN1540944A, 1 page.
Burke et al., "Secure Content Management Market Definition", IDC, vol. 1, Sep. 2005, pp. 1-8.
Chappell, David, "A Short Introduction to Cloud Platforms", Microsoft Corporation, 2008, 13 pages.
Chinese Patent Application No. 200980120235.1, Amendment dated Fourth Office Action dated Jul. 14, 2014, 13 pages (including English translation of claim amendments
Chinese Patent Application No. 200980120235.1, Amendment dated Office Action dated Feb. 5, 2013, 14 pages (including English translation of claims).
Chinese Patent Application No. 200980120235.1, Amendment dated Third Office Action dated Jan. 2, 2014, 3 pages (including English translation).
Chinese Patent Application No. 200980120235.1, Fourth Office Action dated Apr. 19, 2014, 14 pages (including English translation).
Chinese Patent Application No. 200980120235.1, Office Action dated Oct. 9, 2012, 11 pages (including English translation).
Chinese Patent Application No. 200980120235.1, Response to Second Office Action dated Jul. 10, 2013 , 5 pages (including English translation).
Chinese Patent Application No. 200980120235.1, Second Office Action dated May 9, 2013, 12 pages (including English translation).
Chinese Patent Application No. 200980120235.1, Third Office Action dated Oct. 18, 2013, 14 pages (including English translation).
English Translation of Abstract of CN 101064604, 1 page.
English Translation of Abstract of JP2005-11098, 1 page.
Hausheer et al., "Design of a Distributed P2P-based Content Management Middleware", retrieved at http://www.tik.ee.ethz.ch/~mmapps.org/papers/euromicro03-camera-ready.pdf>>, downloaded Jun. 4, 2008, pp. 1-8.
Hausheer et al., "Design of a Distributed P2P-based Content Management Middleware", retrieved at http://www.tik.ee.ethz.ch/˜mmapps.org/papers/euromicro03-camera-ready.pdf>>, downloaded Jun. 4, 2008, pp. 1-8.
International Search Report and Written Opinion Received for PCT Application No. PCT/US2009/038673, mailed on Nov. 27, 2009, 11 pages.
Japanese Patent Application No. 2011-511664, Amendment dated Nov. 1, 2013, 6 pages, including English translation of claims.
Japanese Patent Application No. 2011-511664, Letters Patent issue date May 9, 2014, 3 pages.
Japanese Patent Application No. 2011-511664, Notice of Allowance dated Apr. 1, 2014, 3 pages.
Japanese Patent Application No. 2011-511664, Notice of Rejection dated Jul. 2, 2013, 4 pages.
Komura Takaaki et al. "Design and Implementation of Web Forward Proxy with Shibboleth Authentication." 2011 IEEE/IPSJ 11th International Symposium on Applications and Internet (SAINT), pp. 321-326. *
Non-Final Rejection, U.S. Appl. No. 12/192,107, dated Jun. 20, 2011, pp. 1-16.
Non-Final Rejection, U.S. Appl. No. 12/192,113, dated Apr. 14, 2011, pp. 1-20.
Non-Final Rejection, U.S. Appl. No. 12/193,070, dated Mar. 28, 2011, pp. 1-20.
U.S. Appl. No. 12/164,078, Amendment After Final Office Action dated Mar. 1, 2012, 8 pages.
U.S. Appl. No. 12/164,078, Amendment filed Dec. 2, 2011, 9 pages.
U.S. Appl. No. 12/164,078, Final Office Action dated Dec. 14, 2011, 10 pages.
U.S. Appl. No. 12/164,078, Non-Final Rejection mailed Sep. 2, 2011, 10 pages.
U.S. Appl. No. 12/164,078, Office Action dated May 5, 2014, 11 pages.
U.S. Appl. No. 12/192,107, Amendment After Final Office Action dated Nov. 28, 2012, 13 pages.
U.S. Appl. No. 12/192,107, Amendment dated Jul. 30, 2012, 13 pages.
U.S. Appl. No. 12/192,107, Amendment mailed Oct. 20, 2011, 13 pages.
U.S. Appl. No. 12/192,107, Final Office Action dated Aug. 28, 2012, 17 pages.
U.S. Appl. No. 12/192,107, Office Action dated Mar. 29, 2012, 13 pages.
U.S. Appl. No. 12/192,111, Amendment After Final Office Action dated Nov. 28, 2012, 11 pages.
U.S. Appl. No. 12/192,111, Amendment dated Jul. 13, 2012, 14 pages.
U.S. Appl. No. 12/192,111, Amendment filed Oct. 31, 2011, 14 pages.
U.S. Appl. No. 12/192,111, Final Office Action dated Aug. 28, 2012, 20 pages.
U.S. Appl. No. 12/192,111, Non-Final Rejection mailed Jun. 30, 2011, 16 pages.
U.S. Appl. No. 12/192,111, Notice of Allowance dated Jul. 2, 2014, 14 pages.
U.S. Appl. No. 12/192,111, Office Action dated Apr. 13, 2012, 16 pages.
U.S. Appl. No. 12/192,113, Amendment After Final Office Action dated Feb. 10, 2012, 8 pages.
U.S. Appl. No. 12/192,113, Amendment filed Aug. 15, 2011, 8 pages.
U.S. Appl. No. 12/192,113, Final Rejection mailed Nov. 10, 2011, 9 pages.
U.S. Appl. No. 12/192,113, Notice of Allowance dated Jun. 13, 2012, 7 pages.
U.S. Appl. No. 12/192,113, Notice of Allowance dated Mar. 27, 2012, 8 pages.
U.S. Appl. No. 12/193,070, Amendment After Final Office Action dated Mar. 5, 2012, 10 pages.
U.S. Appl. No. 12/193,070, Amendment After Final Rejection dated Jan. 13, 2014, 10 pages.
U.S. Appl. No. 12/193,070, Amendment dated Jul. 3, 2014, 10 pages.
U.S. Appl. No. 12/193,070, Amendment dated Jun. 7, 2013, 10 pages.
U.S. Appl. No. 12/193,070, Amendment filed Aug. 29, 2011, 11 pages.
U.S. Appl. No. 12/193,070, Final Rejection dated Sep. 13, 2013, 21 pages.
U.S. Appl. No. 12/193,070, Final Rejection mailed Dec. 5, 2011, 20 pages.
U.S. Appl. No. 12/193,070, Non-Final Rejection dated Mar. 7, 2013, 20 pages.
U.S. Appl. No. 12/193,070, Office Action dated Apr. 3, 2014, 17 pages.
U.S. Appl. No. 61/019,739, filed Jan. 8, 2008, pp. 1-49.
Warnock, et al., "The GridAuth Credential Management System", ACM, 2005, pp. 6.
Zitzlsberger, "Security of Content Management Systems Principles of Secure Development and Administration", retrieved at <<http://cms.hs-augsburg.de/report/2004/Zitzlsberger—Georg/security—of—cms.pdf>>, Jul. 9, 2004, pp. 1-9.
Zitzlsberger, "Security of Content Management Systems Principles of Secure Development and Administration", retrieved at >, Jul. 9, 2004, pp. 1-9.
US20090300739A1 (en) 2009-12-03
CN102047262A (en) 2011-05-04
JP5539335B2 (en) 2014-07-02
JP2011522326A (en) 2011-07-28
WO2009151730A3 (en) 2010-02-04
JP5714078B2 (en) 2015-05-07
EP2304639A2 (en) 2011-04-06
WO2009151730A2 (en) 2009-12-17
EP2304639A4 (en) 2014-12-10
JP2014041652A (en) 2014-03-06
CN102047262B (en) 2015-07-22
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:NICE, NIR;ANANIEV, OLEG;WOHLFERT, JOHN F.;AND OTHERS;SIGNING DATES FROM 20080515 TO 20080526;REEL/FRAME:021005/0382