Patent Application
20070226338
The invention relates generally to security and more particularly to techniques for registering for peer-to-peer (P2P) services.
Several years ago, online access to music was made popular and famous by the Napster® service. Essentially, Internet users identified one another using Napster® and identified songs that each user possessed. Next, a particular user's client machine would connect to another user's client machine directly in a peer-to-peer (P2P) fashion and the desired song was downloaded or shared between the users. The Napster® service brought to the attention of the general public the benefits and potential problems associated with P2P technology; although P2P technology existed prior to Napster®.
There is, of course, a variety of lawful and useful benefits to P2P technology. For example, with P2P technology users can directly connect to one another and share information, applications, share services, talk to one another, and/or video conference with one another. P2P technology has also been used to decrease bandwidth requirements needed to distribute popular media. That is, users can willingly or unwillingly facilitate the P2P delivery of media through their clients or devices. A disperse and cooperating network of clients, such as this, can rapidly and efficiently distribute media over the Internet and alleviate the bandwidth bottleneck associated with a single and central media distribution server.
One problem area with P2P technology is the security concern that information or media will be unlawfully appropriated from a user or that an unsuspecting client of a user may unwillingly participate in such a scenario. Generally, individuals like the idea of sharing information with others that are geographically dispersed but dislike and are concerned with the idea that their information or devices may be unlawfully accessed.
One example may be an employee of one organization who may want to share calendaring information with an employee of another organization. If a service (such as the calendar service in the present example) is enabled for P2P operation, a sharing user may not have the ability to limit access to the P2P service to a particular user. So, in the present example, the employee whose calendar is being shared may only be able to share his/her calendar service with all employees of the other organization or domain; although the employee may only want to share his calendar with a particular employee of the other organization.
Consequently, a P2P enabled service is typically enabled for a whole domain and is not capable of being limited to a particular user or a particular group of users. This creates a fairly significant security hole for P2P enabled services. As a result, users are either forced to expose P2P enabled services to individuals or groups that they do not want to access their services or they elect to not provide any P2P enabled services.
Therefore, there is a need for techniques that permit P2P services to be more securely and selectively enabled and distributed over a P2P network.
In various embodiments, techniques for registering of peer-to-peer (P2P) services are presented. More specifically, and in an embodiment, a method for registering a P2P service is provided. A registration for a peer-to-peer (P2P) service is received and processed from a first principal. The registration includes a criterion for accessing the P2P service. Next, a second principal is evaluated to determine if the second principal conforms to the criterion, and in response thereto an access token is supplied to the second principal for purposes of securely accessing the P2P service of the first principal over a P2P network connection.
A “resource” includes a user, service, system, device, directory, data store, user, groups of users, combinations of these things, etc. A “principal” is a specific type of resource, such as an automated service or user that acquires an identity. A designation as to what is a resource and what is a principal can change depending upon the context of any given network transaction. Thus, if one resource attempts to access another resource, the actor of the transaction may be viewed as a principal.
Another type of resource discussed herein is an identity service. The identity service can perform a variety of beneficial functions. Some example identity services may be found at U.S. patent Ser. No. 10/765,523 entitled “Techniques for Dynamically Establishing and Managing Authentication and Trust Relationships;” at U.S. patent Ser. No. 10/767,884 entitled “Techniques for Establishing and Managing a Distributed Credential Store;” and at U.S. patent Ser. No. 10/770,677 entitled “Techniques for Dynamically Establishing and Managing Trust Relationships.” All of these are incorporated herein by reference.
The network service provider discussed herein and below may be implemented as enhancements to these existing identity services with yet more beneficial features that provide secure registration of P2P services. This will be discussed in greater detail below.
Various embodiments of this invention can be implemented in existing network architectures. For example, in some embodiments, the techniques presented herein are implemented in whole or in part in the Novell® network and proxy server products, email products, identity service products, operating system products, and/or directory services products distributed by Novell®, Inc., of Provo, Utah.
Of course, the embodiments of the invention can be implemented in a variety of architectural platforms, operating and server systems, or applications. Any particular architectural layout or implementation presented herein is provided for purposes of illustration and comprehension only and is not intended to limit aspects of the invention.
Initially, a first principal desires to register a particular P2P service. For example, a first principal may be a user and the P2P service may be a GroupWise® calendaring operation, distributed by Novell, Inc. of Provo, Utah.
The purpose of the registration is to define specifically what other principals or single principal may communicate with the registered P2P service using P2P communications. Conventionally, P2P services are enabled or disabled for whole domains and cannot be selectively enabled for operation based on a registration that defines such access.
The registration service processes as an enhancement within or as an external service to a network service provider. The network service provider may be viewed as identity services (enhanced and described above), an Internet Service Providers (ISP's), etc. for the target principal(s) who are to be granted access to the first principal's P2P service during the registration process.
With this context, the processing of the registration service is now described in greater detail with reference to
According to an embodiment, at 111, the interactions with the first principal may have occurred within the context of the first principal authenticating to the registration service. This can occur via a single sign-on. For example, suppose the first principal is associated with a different network service provider or identity service and is actively logged into that different identity service when the first principal contacts the registration service to register the P2P service. Suppose further that the different identity service is trusted by and in secure communications with the registration service or the identity service of the registration service. In this scenario, the first principal's identity service may provide an assertion to the registration service that the first principal is who he/she purports to be and has been authenticated to the first principal's identity service. In this manner, the first principal may have logged into its own network service provider and securely be considered logged into the network service provider associated with the registration service.
In an embodiment, at 112, the registration service may similarly enforce authentication of the second principal's that desire to use the first principal's P2P service. Thus, not just any second principal can assert to be a valid second principal authorized to access the first principal's P2P service, because the registration service may enforce authentication mechanisms on the second principals before processing any request to access the first principal's P2P service.
At 120, the registration service determines that there is a second principal or set of second principals that conform to the criterion defined by the first principal in the registration of the P2P service.
As was discussed before, this determination can occur in a variety of manners some may be straightforward, such as when, at 121, the registration service recognizes an identifier with registration (via the criterion) that identifies the second principal. It may also occur in a more complex or dynamic manner, at 122, where attributes or values for attributes that are defined in the criterion are dynamically resolved by the registration service to determine if the second principal possesses the proper values for the attributes to access the P2P service.
Attributes may include a variety of information that may be manually supplied by a second principal or automatically acquired from the second principal. Additionally, attributes may include environmental information, temporal information, configuration information, profile information, network service provider information, role-based information, and the like. Attribute values may also include ranges, such as time range values between the times of 10:00 am and 6:00 pm. The attributes may be static (constants recorded in a data repository) and/or dynamic (resolved based on state at the time of a request for P2P access).
At 130, the registration service supplies a token to the second principal to access the P2P service assuming that the second principal successfully conformed to the criterion defined in the registration.
According to an embodiment, at 131, the registration service may also embed dynamic constraints in the token. These dynamic constraints may be dynamically and in real time evaluated by the P2P service itself when the second principal attempts to access the P2P service. So, the attributes or constraints may be evaluated by the registration service and also evaluated a second time by the P2P service itself. Furthermore, the second evaluation may include the same or different constraints or attributes from that which was included in the first evaluation. This situation may prevent a second principal from having a token stolen or a token distributed in an authorized fashion by the second principal to a different principal, since the P2P service is in a position to re-evaluate the constraints when access is attempted to the P2P service.
In an embodiment, at 132, the registration service may represent the token as an assertion. This assertion may be subsequently relied upon by the P2P service when it is presented to the P2P service by the second principal in an attempt to gain access.
Once a second principal has a valid token, that token may be presented to the P2P service of the first principal and a valid P2P connection or communication may be established.
So, in the initial example above where the P2P service is a calendaring service, consider the following scenario to further illustrate operation of the registration service. Cameron is a first principal associated with a domain of and network service provider of Novell®, Inc., of Provo, Utah (domain name “novell.com”). Joe is a second principal associated with a domain and network service provider of Road Runner® (domain name “rr.com”). Cameron logs into novell.com and contacts the registration service to register his GroupWise® calendaring service; during registration Cameron includes a criterion that identifies Joe as joe@rr.com. Next, Joe logs into rr.com and is supplied a token or key to access the calendaring service, since Joe's email (identifier) is Joe@rr.com. Joe then accesses his own version of GroupWise® and attempts to read Cameron's calendar for purposes of setting up a meeting between the two. Joe's GroupWise® calendaring service attempts to establish a P2P connection with Cameron's GroupWise® calendaring service and presents the key. Cameron's GroupWise® calendaring service identifies the key and sets up the P2P connection between the two services. Cameron provided selective access to his P2P service (GroupWise®) to just Joe and did not have to make it accessible to all users of the rr.com domain; this was achieved via the novel processing of the registration service described above.
At 210, the registered P2P service receives an access request from a first principal over a P2P connection. The registered P2P service was previously registered via interactions with the registration service described as the method 100 and depicted in the
At 220, the registered P2P service inspects the access request to determine if an access token is present with the request. The access token may be included with the request or may be acquired or derived from the request.
If the token is present, then at least an initial hurdle is satisfied with respect to the first principal that is requesting access to the registered P2P service. With respect to the discussion of
At 230, the mere presence of the token is sufficient to permit access to the registered P2P service. However, in some cases, at 240, the access to the registered P2P service may be dynamically terminated if attributes are not verified to provide certification of the first principal. That is, the token may define attributes that the registered P2P service dynamically resolves values for when access is attempted and if satisfied the registered P2P service certifies the first principal for access. Under some conditions, at 250, the certification of the first principal's access to the registered P2P service may be dynamically terminated if the attributes change or are not capable of being satisfactorily resolved.
According to an embodiment, at 260, the registered P2P service may recognize the access token as an assertion from an identity service or network service provider. So, a trusted identity service may assert that the first principal is authorized to access the registered P2P service in a P2P connection and the registered P2P service relies on this assertion based on its relationship with the identity service.
In still another embodiment, at 270, the registered P2P service may terminate P2P access if the first principal violates a defined policy. The policy may actually be dynamically identified as a component of the access token, as depicted at 271. At 272, the registered P2P service alternatively identifies the policy from a policy store using an identifier for the first principal to locate the proper policy from the policy store. The policy provides a mechanism by which the registered P2P service can constrain or self police access occurring via the first principal. Policies may be dynamically defined and evaluated or may be statically defined and dynamically evaluated.
The register service represented by the method 100 of the
The P2P registration system 300 includes a P2P service 301A and a network service provider 302. Each of these components and their interactions with one another will now be discussed in detail.
The P2P service 301A is a P2P enabled service over a network that has its access restricted based on prior established registration. An example of a modified P2P service 301A to facilitate selective P2P connectivity was presented above with respect to the method 200 of the
A first portion enforces access based on the presence of a token and/or dynamic confirmation of constraints or attributes possessed by a requestor (principal). The second portion is any intended service that is the core of the P2P service. So, if the P2P service 301A is calendaring services (as in the continuing example) then the second portion are the features and functions, which are available within that calendaring service. It is noted that there is no limitation as to what the second portion may be, it is constrained only by what service is desired to be made P2P compatible. Thus, it is the first portion that is a novel enhancement and that facilitates selective access to the second portion (legacy portion). Again, the first portion may be implemented as part of the second portion (integrated therewith) or it may be entirely separated from the second portion and implemented as a wrapper or script invoked when access is attempted to the second portion a first time.
The network service provider 302 manages access registrations made by first principals 303 to the P2P service 301A and distributes access tokens to second principal(s) 301B that satisfy criterion or attribute conditions defined by the registration performed by the first principals 303. Examples of the processing and interactions of the network service provider 302 vis-a-vis the first principals 303 and the second principals 301B were presented above with respect to the method 100 of the
The P2P registration system 300 also depicts a second P2P service 301C. This second P2P service 301C is the actual service that connects directly with the P2P service 301A in a P2P connection 301D. The two services 301A and 301C are P2P enabled. It is the initial P2P connection 301D that is selectively regulated by the processing of the P2P registration system 300, such that an access token is used by the P2P service 301A during initial communications between the P2P service 301A and the second P2P service 301C to determine if the P2P connection 301D may be continued and established for the first principal 303 and the second principal 301B associated with the second P2P service 301C.
In an embodiment, the network service provider 302 authenticates the second principals 301B for access to the network service provider 302 before any determination is made as to whether the second principals 301B are to receive or not to receive access tokens defined during a registration process of the P2P service 301A via interactions with a first principal 303.
According to an embodiment, during registration the first principal 303 may define the criterion for accessing the P2P service 301A by means of a list of identifiers. The identifiers are uniquely associated with the second principals 301B. In other cases or in complimentary cases, the first principal 303 may supply a list of attributes or other constraints during registration with the network service provider 302. During operation the network service provider 302 dynamically determines if the second principals 301B have the attributes before distributing the access tokens.
The P2P service 301A processes on a client or within a local environment on machines or devices associated with the first principal 303. Similarly, the second P2P service 301C processes on a client or within a local environment on machines or devices associated with the second principal 301B. The second principal 301B attempts to access the P2P service 301A in a P2P connection 301D via its P2P service 301C by supplying the access token acquired from the network service provider 302.
The P2P registration system 400 includes a first P2P service 401A and a second P2P service 402A. Each of these services 401A-401B and their interactions with one another will now be discussed in great detail.
The P2P registration system 400 reflects the perspective of two P2P services that interact in a selective manner, which is independent of domains associated with those two P2P service. Thus, the P2P registration system 400 may be viewed as the interactions occurring between the first principal's 303 P2P service 301A and the second principal's 301B P2P service 301C depicted with the P2P registration system 300 of the
The first P2P service 401A is registered by a first principal. The first principal is associated with a first network service provider 401B. The first network service provider 401B is in a trusted relationship with a second network service provider 402B. The first principal signs into the first network service provider 401B and obtains authentication and sign in status with the second network service provider by means of the trust relationship between the first network service provider 401B and the second network service provider 402B.
The first principal proceeds to interact with the second network service provider 402B in the manners described above with respect to the
Once an access token is acquired, the second P2P service 402A establishes a P2P connection 403 with the first P2P service 401A by presenting the access token. The processing of the first P2P service 401A is defined above with respect to the
One now appreciates how P2P connections and P2P enabled services may be selectively established and managed in a secure manner across multiple domains. Such has not been the case, where P2P access was largely controllable on a coarse-grain level and not at a fine-grain level, which has been presented herein.
It should also be noted that although the P2P interactions were discussed in terms of a first principal, such as a user, and a second principal, such as another user, that the P2P services may actually run on a different machine as a proxy for a particular principal. So, the P2P occurs between a proxy (a first principal) and another principal. In this case, three parties may be involved and the P2P occurs with a proxy (first party) or another service (first party) that acts on behalf of a user (second party) to interact with another service (third party).
The above description is illustrative, and not restrictive. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of embodiments should therefore be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.
The Abstract is provided to comply with 37 C.F.R. §1.72(b) and will allow the reader to quickly ascertain the nature and gist of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims.
In the foregoing description of the embodiments, various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting that the claimed embodiments have more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Description of the Embodiments, with each claim standing on its own as a separate exemplary embodiment.
