Browse Prior Art Database

A Method and System to automatically detect an authorization issue in cloud

IP.com Disclosure Number: IPCOM000240196D
Publication Date: 2015-Jan-12

Publishing Venue

The IP.com Prior Art Database

Abstract

In cloud platform, a comprehensive security framework is significant for security control, tracking and mornitoring. It defines rules and principles which all cloud services in the platform are required to conform to. However, those cloud services are implemented by different developers, there is no validation mechanism to make sure each developer follows rules very well, so expections happen frequently. When an authorization issue occurs during runtime, it is hard for developers to determinate where is the root cause. This disclosure is to provide a method and system to record authorization token and request header for each request by leveraging exiting correlation id propogation mechanism in the system, and generate a visualized request flow diagram, then finally find potential authorization issues. With this approach, it helps to detect the root cause of authorization issues automatically in a cloud environment without breaking existing functions.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 21% of the total text.

Page 01 of 11

A Method and System to automatically detect an authorization issue in cloud

Cloud computing provides a distributed computing environment comprising of heterogeneous components as well as services . To serve one request, multiple cloud components are involved and interacted with each other. Those services have various authentication and authorization policy and security model, a comprehensive security framework which are applicable to all services in the cloud is significant to build up sufficient control on the entire system. Currently there is no common framework for all cloud systems, most security framework in cloud are borrowed from a traditional system, and there are some best practice for better security control, tracking and monitoring.

As for a typical security framework in a cloud environment, normally each component has its own authorization policies to define whether a component/service can access its certain resource with an action type. And the token stack in the request header is also used frequently. It contains multiple tokens including token of current request sender and also the previous request senders in the request flow . The token stack can be logged for tracing, monitoring and auditing usage. Here is an example to explain how this mechanism work. Component A and C are allowed to GET and LIST resource D1 in component D, and Component C is allowed to POST, PUT and DELETE resource D1. Other components except for A, C are forbidden to access resource D1. When one component launches a request to try to manage a certain resource of another component, it will generate a token stack in its request header for authorization. The component which serves the request validates the token stack to see whether one token inside it can pass the authorization policy, otherwise, an authorization exception will be thrown out. In addition, there are also some security rules in one system which requires developers to follow for auditing reason. e.g. Neither token should not be lost in a request flow; when sending out a request, the token of the sender should be added to the token stack.

Since those services are developed by various developers, there is no validation mechanism to make sure every developer follow those rules very well, so exceptions happen frequently. However, when a security issue occurs during the runtime interaction process, it is hard for developers to determinate where is exactly the root cause. The component where the authorization error occurs may not be the actual reason. There are various possibilities, e.g. incorrect token propagation, or improper authorization policy and etc.

Here is an example of a security issue. In the below figure, [X, Y, ...]/Z format is used to represent that the request is to access resource Z with token stack [X, Y...]. When component C is trying to delete resource D1 of component D with token stack [U, A, C], an authorization exception is thrown out, for based on the authorizati...