Self-describing authorization policy for accessing cloud-based resources

During approximately the last 30 years, dramatic advances in technology—for example, the development of the minicomputer, the rise of the personal computer, and the emergence of the Internet—have revolutionized the way information is created, stored, shared, and used. Today, as technology continues to advance and improve, new breakthroughs are transforming the world once again. The foundation for the current transformation is the combination of an increasing diversity of ever more powerful devices, and the expanding data storage capacity in large scale networked data centers (“the cloud”) that are accessed through the growing ubiquity of broadband networks that comprise the Internet. The capabilities of such technologies are supporting the movement of computing resources, including both consumer and business-oriented applications, from the desktop or enterprise environment out to the Internet as hosted services.

Under such a cloud-computing model, locally installed software on a client platform may be replaced, supplemented, or blended with a service component that is delivered over a network. Such models can often give customers more choices and flexibility by delivering software solutions and user experiences that can typically be rapidly deployed and accompanied by value-added services. Such solutions and experiences are delivered by the hosted service to various client platforms such desktop PCs (personal computers) or to portable devices like mobile phones or pocket PCs. In addition to providing application services, cloud-based computing can also typically provide data sharing and storage capabilities for users to access, collaborate in, and share rich data that leverages the global cloud computing footprint.

While service platforms in the cloud are expected to provide attractive, feature-rich solutions to customers that are well managed, robust, and cost-effective, it is desirable to have effective and efficient systems for determining how access to resources in the cloud will be controlled and managed for users and devices.

This Background is provided to introduce a brief context for the Summary and Detailed Description that follow. This Background is not intended to be an aid in determining the scope of the claimed subject matter nor be viewed as limiting the claimed subject matter to implementations that solve any or all of the disadvantages or problems presented above.

A ticketing system adapted for use with a cloud-based services platform is provided by a ticket-based authorization model in which the authorization requirements for traversing a mesh of resources associated with a cloud service are annotated in the links used by resources to refer to other resources. The meshes are thus self-describing with respect to the association (i.e., the links) between resources as well as the authorization required to access resources. Resource access employs a principal ticket which asserts that a caller at a client (e.g., a security principal representing a device or identity associated with a user) is authenticated, plus zero or more claim tickets. The claim tickets make additional assertions about the caller that the cloud service may use to check to determine that the caller is authorized to access the resource. The principal and claim tickets are signed so that their authenticity may be checked by the cloud service.

When a resource in a mesh requires a claim ticket for access, the requirement is expressed by including a URI (Universal Resource Identifier) that identifies where the claim ticket may be retrieved as an attribute on links to that resource. Optionally, a resource link may be arranged to include an inline value of the required claim ticket as an attribute which eliminates the extra step of retrieving the required claim ticket. By associating links to the resources with the authorization requirements for accessing the resources, a client can traverse a mesh and access its resources while obtaining the required claim tickets along the way. In the absence of an explicit claim ticket requirement, a caller need only supply its principal ticket when issuing a request against a resource in the service.

Claim tickets are typically optionally utilized within a given mesh, but can optimize performance by reducing the need for database lookups in the cloud when authorizing access to the resource by the client. However, when traversing neighboring meshes, a claim ticket will normally be used to establish peer connectivity. Claim tickets are identified by the URI of their associated resources so that they may be cached by a ticket manager at the client or in the cloud for subsequent use.

Advantageously, the present ticket-based authorization model decouples the authorization policy from the implementation of the client, the cloud service, and the resources themselves so that access control may be tightened or relaxed within a mesh or between meshes to meet the needs of a particular scenario. Thus, resource access authorization may be transformed in a way that is completely transparent to the service and its constituents. In addition, use of the model enables a client to be implemented in a straightforward manner that can navigate an arbitrary mesh without foreknowledge of what authorization is needed in order to do so.

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

FIG. 1 shows an illustrative cloud-computing environment in which the present ticket-based authorization for handling requests for resources may be implemented;

FIG. 2 shows how illustrative resources that are exposed by cloud-based platform services may be logically arranged in meshes;

FIG. 3 shows an illustrative architecture that includes client devices, mesh operating environment (“MOE”) runtimes, and cloud-based platform services;

FIG. 4 shows an illustrative resource handler and ticket resource handler that are associated with a resource;

FIGS. 5 and 6 show, respectively, an illustrative principal ticket and an illustrative claim ticket;

FIG. 7 is a data flow diagram that shows an illustration authentication between a security principal and an account service; and

FIG. 8 is a data flow diagram that shows an illustrative scenario in which a resource is accessed using a principal ticket and one or more claim tickets.

Like reference numerals indicate like elements in the drawings. Elements are not drawn to scale unless otherwise indicated.

FIG. 1 shows an illustrative cloud-computing environment 100 in which the present ticket-based authorization for handling requests for resources may be implemented. Environment 100 includes a cloud-based services platform 106 that exposes resources 112 to be accessed by client devices and users as services over a network such as the Internet 117 . Cloud-computing services (hereinafter referred to as “cloud service(s)”) are indicated in the abstract in FIG. 1 by the dashed oval 120 . By utilizing typically large scale data centers and associated network infrastructure (which together form the “cloud”), the cloud-based services platform 106 may provide a virtualized computing application layer that supports an implementation of a variety of service offerings under, for example, the “software as services” or “software plus services” models.

Cloud services 120 may replace, supplement, or blend with features and capabilities provided by applications and software that run locally. Offerings may include, for example one or more of identity and directory services, device management and security, synchronized storage and data services across multiple devices or platforms, and services pertaining to activities and news. The cloud services 120 may be provided under a variety of different business models including free, advertising-supported, and subscription-based models.

As shown in FIG. 1 , different client devices are present in the environment 100 . In this example, a user has a PC 122 and a portable laptop computer 129 that are arranged to access the service resources 112 exposed by the cloud-based services platform 106 under the user's credentials, or identity (as indicated by reference numeral 125 ), which is trusted by the cloud services 120 . Another user maintains a trusted identity 130 so that that user may couple a PC 136 , a laptop computer 140 , and a smart phone 144 to the Internet 117 to utilize the cloud services 120 . For example, the first user might use the cloud services 120 for synchronizing the user's settings for favorite websites in a web browser application across both the PC 122 and laptop 129 . The second user may take advantage of a service where all that user's photographs are synchronized across the PC 136 , laptop 140 and phone 144 as well as with popular photo sharing sites on the Web that are maintained by third party providers.

It is emphasized that the client devices shown in FIG. 1 are merely illustrative and a variety of different devices may be utilized with the present ticket-based authorization model. These include for example, media center PCs, game consoles, set-top boxes, ultra-mobile computers, handheld game devices, mobile phones, PDAs (personal digital assistants), pocket PCs, personal media players such as MP3 players (Moving Pictures Expert Group, MPEG-1, audio layer 3), and similar devices.

As shown in FIG. 2 , the resources 112 that are exposed by the cloud services 120 may be logically arranged to form meshes. In this example, a mesh is associated with each of the identities 125 and 130 (and the client devices associated therewith) as respectively indicated by reference numerals 203 and 208 . The meshes include those resources which are utilized to implement a given service offering for the user and the devices which are associated with and can access the resource. In this example as shown, resources 112 1 , 112 2 , and 112 3 are associated with the user having identity 125 and the user's PC 122 and laptop 129 in mesh 203 . The user having identity 130 receives services that are implemented with mesh 208 which includes resources 112 3 , 112 4 , 112 5 and 112 N that are accessible to the user's PC 136 , laptop 140 and smartphone 144 . For a service to be rendered, the meshes 203 and 208 must be traversed by a client device so that the resources 112 contained therein are accessed.

Meshes can overlap as shown in FIG. 2 . In this example, resource 112 3 is commonly utilized in both meshes 203 and 208 . Resource 112 3 could be, for example, a folder on the cloud to which one user as an owner has given the other user permission to access as a member. It is noted that the number of and configuration resources shown here in this example is arbitrary, and the particular resources used in a given mesh to implement a specific service offering for a user can be expected to vary to meet the needs of a particular scenario.

To implement the present ticket-based authorization model, the illustrative architecture 300 shown in FIG. 3 is utilized. The architecture 300 distributes several functional components across the environment 100 ( FIG. 1 ). In particular, an instance of a mesh operating environment (“MOE”) runtime 310 1 is located in the cloud as well as on the thick client devices in the environment 100 . These thick clients 302 can include, for example, the PCs 122 and 136 and laptops 129 and 140 . The thin client devices 305 such as the smart phone 144 will typically interact with the cloud MOE runtime 310 1 while the thick client devices will host a client MOE runtime 310 2 .

Aside from their location in the environment 100 , cloud MOE 310 1 runtime and client MOE 310 2 runtime may be similar in function and are generally arranged to expose services to help the applications running on client devices to create cached or offline-based experiences to reduce round trip interactions with the cloud services 120 or to enable the clients to morph data into a more consumable form. An illustrative application 328 is shown on the thin client 305 which interacts solely with the cloud MOE runtime 310 . Applications on the thick client 302 in this example representatively include a client only application 332 which interacts only with the client MOE runtime 310 2 while a hybrid cloud/client application 336 interacts with both the client MOE runtime 310 2 and cloud MOE runtime 310 1 . A connected “cloud” application 340 on the thick client 302 interacts solely with the cloud MOE runtime 310 .

To support the present ticket-based authorization, the cloud MOE runtime 310 1 and client MOE runtime 310 2 expose a ticket manager (as respectively indicated by reference numerals 320 1 and 320 2 ), and associated ticket caches 325 1 and 325 2 . The ticket manager 320 is configured to interact with the resources 112 used to implement the cloud services 120 to be able to locate and retrieve the correct authorization tickets and cache them in the cache 325 for future calls to the service by the clients. The ticket manager 320 interacts with the resources 112 through a resource handler 406 and ticket resource handler 412 that are associated with a resource 112 as shown in FIG. 4 .

More specifically, the ticket manager 320 is arranged to work with two types of tickets. The first ticket type is a principal ticket which is used to authenticate a security principal which may represent either a device or an identity. The second ticket type is a claim ticket that may be optionally utilized in most cases, but will provide some performance benefits when they are used by avoiding the database lookups that are typically required when only using principal tickets.

As shown in FIGS. 5 and 6 , both the principal ticket 500 and claim ticket 600 are structured the same way and may be expressed using conventional data formats such as Security Assertion Markup Language (“SAML”) from the Oasis Security Services Technical Committee. Each ticket includes a signature field, respectively indicated by reference numerals 505 and 605 , expiration information 512 and 612 , and a URI 516 and 616 to identify the ticket by its associated resource. The tickets 500 and 600 are signed by an authority for the resource to enable the cloud services 120 to verify their authenticity. The expiration information typically specifies a date and time at which the ticket is no longer valid.

As shown in FIG. 7 , a call ( 701 ) such as an HTTP (Hypertext Transfer Protocol) GET call from the security principal 710 to an account or identity management service 720 will result in principal tickets being returned as inlined objects ( 702 ). Such service 720 may itself be arranged as a resource on either the cloud-based services platform 106 shown in FIG. 1 , or be supported by a separate cloud altogether. Principal tickets are configured to be standalone in the ticket-based authorization model in most cases (with the exception of mesh peer connectivity, as described below). So, if the caller (i.e., the security principal) has only principal tickets, the cloud service 120 will still be able to authenticate the principal and perform a database lookup to check if it has access to a given resource. For example, a storage service in the cloud can check if a client device (authenticated by its principal ticket) may access a storage resource (e.g., a folder) by looking up in the database if this device is claimed by the owner/member of this resource.

The authorization checks can be expensive in terms of overall performance of the cloud service 120 . To mitigate such performance loss, a claim ticket may be optionally utilized which describes certain facts about the security principal. When a resource handler receives a principal ticket along with the claim ticket, it can avoid a database lookup to see if a given caller has access to a device or the device has access to the resource. For example, the claim ticket may describe the fact that some user has claimed some device.

When a resource requires a claim ticket for access, the requirement is expressed by including the URI of the required ticket as an attribute on links to the resource. One example where a claim ticket is needed to access a resource is peer connectivity between meshes. For example, using the storage service example above, a claim ticket is used to enable an authorized, but restricted link to be established between a mesh for the retrieving device and a mesh for the target device. This allows the retrieving device to navigate a portion of the mesh of the target device, such as a folder employed by the storage service.

A link to a resource may also optionally include the inline value of the required claim ticket, as an attribute of the link. This eliminates the need for the client to issue an additional HTTP operation in order to obtain any tickets that it needs. In the absence of an explicit claim ticket requirement, a client simply supplies its principal ticket when issuing a request against a resource. An exemplary link is shown below:

<link href=http://host.com/SomeResources/ID  claimsUri=http://host.com/SomeResources/ID/SomeClaimTicketHandler  claimsValue=”<XML with SAML/> encoded for being embeddable into XML (with ampersands) />

where link attributes include:

claimsUri—a URI where a caller can retrieve a list of claims for a given resource (represented by its link); and

claimsValue—a set of claim tickets for a given resource (represented by its link) in SAML format (encoded in Base64) that should be used to access this resource. This set of claim tickets is passed along with a principal ticket in authorization header of an HTTP call. A principal ticket and following claim tickets are separated by commas in the authorization header.

If several links have the same claimsValue in them, then it is not necessary to add claimsValue to all links, and instead include it only on a first link. As all other links always have claimsUri attributes as pointers, the client will be able to find a correct claimsValue from previous links that have this attribute set.

FIG. 8 is a data flow diagram that shows an illustrative scenario in which a resource is accessed using a principal ticket and one or more claim tickets. When a security principal (i.e., an identity or device associated with a user) wishes to navigate to a resource supported by the cloud service 120 ( FIG. 1 ), the MOE runtime 310 will check the claim ticket requirements specified in the claimsUri attribute of the resourceURI ( 801 ) and will check with ticket manager 320 to fetch the specified claim ticket ( 802 ).

The ticket manager 320 will check its ticket cache 325 for the specified claim ticket ( 803 ) using the URIs in the claim tickets to identify them. If the claim ticket specified in the claimsURI is not cached, or a cached claim ticket has expired, then the ticket manager will fetch the claim ticket from the ticket resource handler ( 804 ). Otherwise, the process continues at step 7 shown in FIG. 8 .

The ticket resource handler 412 will return the claim ticket ( 805 ) which the ticket manager 320 will put into the ticket cache 325 ( 806 ). The authorization header of an HTTP call is populated with the principal ticket and claim ticket ( 807 ). The MOE runtime may then perform various HTTP CRUD (create, read, update, delete) operations against a resource with the authorization header set to the principal ticket and claim ticket ( 808 ) which will be received at the resource handler 406 .

The resource is returned ( 809 ) and the resource links may be annotated with claim tickets (i.e., claim ticket URIs plus optional inlined claim values) ( 809 ). The MOE runtime 310 will interface with the ticket manager 320 so that the claim tickets from the resource are cached in the ticket cache 325 ( 810 ). The ticket manager 320 will go over all the links in the resource and cache the claim values (if present) by associating them with the link URIs ( 811 ).

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.