A Template-Based Policy Generation Interface for RESTful Web Services Philip Raschke and Sebastian Zickau Service-centric Networking Technische Universit¨ at Berlin, Berlin, Germany
[email protected],
[email protected]
Abstract. Cloud computing solutions imply chances for economic advantages concerning investment, administration and maintenance costs. On the downside these advantages are paid with a loss of autonomy; the service providers often predetermine configuration and authorization functionalities. The increase of participating actors represents recent privacy, security and legal issues for service providers and users. The different interests of all involved stakeholders raise a need for distributed access control functionalities, which consider the various restrictions of the stakeholders. The presented work designs and realizes a web interface, service users can use to express fine-grained access control policies concerning their resources. The increase of RESTful online services is addressed by a template approach that serves as a basis for the policy interface. A particular focus is set on the eXtensible Access Control Markup Language (XACML), a standard for distributed access control. Following the XACML standard the web interface is realized within the XACML component model. Users’ requirements are retrieved via the web interface and translated into a complete XACML policy. The generated policies are tested for syntactic and semantic correctness as well as usability. Keywords: Cloud Computing, Distributed Access Control, REST, Policy Administration, Policy Creation Interface.
1
Introduction
A recent growth of software as a service (SaaS) offers and a continual increase of SaaS users are observable. The possibilities of cloud computing solutions are broad and users accustom to new paradigms of accessing private data regardless of the device they use or the place they are located. Further, cloud computing solutions imply new possibilities for optimizing internal work processes by enhancing communication and resource sharing. Despite all advantages of applying cloud computing solutions a crucial drawback of SaaS offers arise. The private resources are stored within the service providers’ domain. Access restrictions to these resources can only be expressed if the service providers take these desires into account within the development and R. Meersman et al. (Eds.): OTM 2014 Workshops, LNCS 8842, pp. 137–153, 2014. c Springer-Verlag Berlin Heidelberg 2014
138
P. Raschke and S. Zickau
deployment of the service. In current implementations of access control solutions the service users’ requirements are sometimes not taken into account. Functionalities giving the users control over their resources need to be implemented by the service providers. Furthermore, specific rules can not be formulated by the service providers due to lack of knowledge about the users’ requirements, e.g., their user management realized with a Lightweight Directory Access Protocol (LDAP) server or Active Directory (AD) service. Additionally access control functionalities are complex to implement and therefore expensive. Shifting this complexity to other service providers requires open standards and trustful partners. Service users are not offered enough configuration settings to achieve optimal access control. More functionalities or a complete list of operations performed by the service on their resources are desirable in certain scenarios. The decisions to whether use a cloud computing solution or not is attached to the shortness of management capabilities [24]. These additional management capabilities should give the service users the possibility to configure, e.g., who can access the data complying with a set policy, with the integration of location and time restrictions as well as device constraints. These restrictions in particular are relevant for facilities that handle highly sensitive data, e.g., facilities in the healthcare domain such as hospitals, health centers, and medical practices. The article is structured into six sections. Following the introduction and motivation, Section 2 provides an overview of related work and used technologies, including an XACML overview. Section 3 presents the conceptual work on the interface together with the RESTful template approach. Implementation and evaluation results are represented in Section 4 and 5. The article concludes with a summary and an outlook. 1.1
Motivation
The presented work targets to offer a service for cloud computing users to regain management capabilities by expressing access control restrictions in a simplified way. The presented solution focuses exemplary on dynamic attributes regarding time and location. Further this article aims to deploy a standardized distributed access control technology enabled by a single interface to specify access control restrictions. As a positive side effect service providers can neglect complex implementations of access control functionalities since these are provided by a trusted third party (see Fig. 1). The presented solution follows the Representational State Transfer (REST) architectural style [1] for web services, which is a popular technology for modern cloud computing services. Within RESTful web services the usage of annotations provide additional information about resources and actions. Based on this information an XML template is generated which functions as a basis for the web interface. Service users have the possibility to explicitly permit or prohibit the users’ access to certain resources or actions by including local directory servers into the access control architecture (see Fig. 1). Furthermore, the web interface eases the process of policy creation concerning the XACML features by
A Policy Generation Interface for RESTful Web Services
139
utilizing maps on which polygons can be drawn specifying in which areas access is granted or denied. In the best case the service users are able to control every action performed on their resources. The service provider has no overhead by outsourcing access control implementations. The solution is realized within the TRESOR project1 in which a trusted third party ecosystem is deployed [24].
2
Related Work and Technologies
To give an overview of state-of-the-art technologies concerning the main problem of the work, it is of relevance to take a look at existing distributed authorization techniques, which are mostly realized by defining a policy language to enable interchangeability. Within the variety of policy languages [3] two of them stick out, namely the eXtensible Access Control Markup Language (XACML) [4] proposed by the Organization for the Advancement of Structured Information Standards (OASIS) [18] and the Enterprise Privacy Authorization Language (EPAL) [5] first introduced by IBM later advanced by the World Wide Web Consortium (W3C) [26]. Due to a high number of XACML implementations an overview of software using XACML for access control is given. EPAL. EPAL is an authorization language similar to XACML specified as markup language in XML. IBM first published it as Research Report in March 2003 later advanced by the W3C. The language was designed to easily describe and exchange authorization policies. It only describes a policy language, neither a component model nor a request-response format are specified. EPAL is one of a few completely standardized policy languages although due to a lack of implementations, employing EPAL is not feasible. 2.1
XACML
XACML is a representative of the attribute-based access control solutions and was first released in February 2003 by OASIS. XACML defines a component model, a request-response model and a policy language. The current version is 3.0, which was released in January 2013. XACML enables fine-grained access control [6] and due to the defined component model access control solutions can be shifted from the actual application to a third party, which is in charge of the compliance of defined access control policies. Since a policy is represented by an XML file stored at the Policy Retrieval Point (PRP) [8] rules within a policy can be defined by the service provider as well as by the service user. WSO2 Identity Server. The WSO2 Identity Server [27] is an open source identity management and security tool for enterprise web applications. It was also developed by the WSO2 Inc. and published under Apache2 license. It uses XACML for access control requirements and supports XACMLv2 and XACMLv3. It provides an interface for policy creation and editing and therefore addresses a simplification of the policy creation process. It further includes a tool called TryIt for exploring policy impact. 1
Trusted Ecosystem for Standardized and Open cloud-based Resources http://www.cloud-tresor.de/
140
P. Raschke and S. Zickau
ALFA. ALFA [2] is a policy language developed by Axiomatics Inc. It is a free closed source plugin for the Java IDE Eclipse, which can be obtained by registering at the Axiomatics website. The language was developed to ease the process of building XACML policies. Axiomatics claims that ALFA is syntactically similar to Java and C#. ALFA policies are converted to XACMLv3 policies, which can be directly used and applied. NoXACML. NoXACML is an open source project of independent developer Brad Cox published on code.google.com [17] first announced in June 2012 under Apache2 license. NoXACML targets the complexity of policy creation and editing similar to ALFA and the WSO2 Identity Server. Like ALFA, NoXACML defines a policy language, which is syntactically similar to Java. A complete XACMLv3 policy can be generated and used for access control. 2.2
XACML Engines
There are a number of implementations regarding different aspects of XACML. Some implementations offer a full functional XACML engine, which is designed to cover the whole functionality from formulating an incoming request, over the evaluation to the response formulation. Other implementations focus on the aspect of creating XACML policies and especially simplifying this process. Sun’s XACML implementation. Sun’s XACML implementation [23] (in the following also referred as Sun engine) is a XACML engine developed by Sun Microsystems and was last updated in June 2006. The Sun engine is an open source product, which supports XACMLv2. The engine contains the main implementation of XACMLv2 as well as tests. The engine can be used to evaluate XACML requests and policies, it formulates the response and transmits it back to the requesting entity. Balana. Balana [7] is an open source XACML engine implemented in Java, which supports XACMLv3 as well as XACMLv2. Balana is a derivative of Sun’s XACML implementation and was released by WSO2 Inc. under Apache2 license. The engine is composed of the different packages. The package balana-core is the actual implementation of the XACML standard. Noteworthy is that the package balana-utils provides utility methods to easily create XACMLv3 policies. The engine similar to the Sun engine is capable of retrieving and evaluating XACML requests, it subsequently formulates the respective XACML response. XEngine. The XEngine was developed by the Michigan State University in cooperation with the North Carolina State University [9]. It was released in 2008 under GNU General Public License. The XEngine is open source and written in Java. Similar to the other XACML engines the XEngine retrieves XACML requests and evaluates these by matching it against a set of XACML policy files. The response is returned to the requesting entity. The engine’s focus is exclusively on performance concerning the request processing. The XEngine uses techniques like conversion, normalization and tree structures to improve performance [9].
A Policy Generation Interface for RESTful Web Services
2.3
141
GeoXACML
GeoXACML [10] is an extension to the XACML standard. It was standardized by the Open Geospatial Consortium (OGC) [19] and first released in June 2005. The current version of GeoXACML is 1.0.1 released in May 2011. It extends the functionality of XACML by providing functions and data types for geospatial information to enable, e.g., location-based access control (LBAC). Some applications need to take the location of the requesting device into account to make an access control decision. Therefore, the Geography Markup Language (GML) [11] is used which was also formulated by the OGC in cooperation with the International Organization for Standardization (ISO) and was first released in May 2000. GML is used to define coordinates, polygons and shapes in two- and threedimensional space. GeoXACML enhances the features of XACML by enabling the formulation and evaluation of location information in XACML policies and requests.
3
Concept and Design Overview
Distributed architectures require standards to enable interoperability and interchangeability. The last section gave a few options for distributed access control standards in which XACML exposed as the currently most advanced standard available inasmuch as a variety of XACML realizations exist and the standard is constantly developed further. As much as users can benefit from the deployment of XACML with a web interface that is supposed to give them the feasibility to express precise policies to govern access to their resources. Service providers receive chances to save costs when outsourcing sophisticated authorization functionalities and mechanisms to a third party. To accomplish an advantage on the service providers’ side, a trusted third party is assumed whose focus is solely on authorization. As stated in the last section another benefit of XACML is that an XACML policy can represent both the users’ and the providers’ access restrictions and requirements. Yet an instance is needed that conflates the requirements of both sides and merges them into an XACML policy. Therefore an XML template is used that constitutes the service listing, the operations the service performs on the respective resources. Since this article targets in particular RESTful web services [1] the operations can be smartly mapped to the established methods of the Hypertext Transfer Protocol (HTTP) operations, i.e., GET for read, POST for write, PUT for create, and DELETE for delete. A resource is usually expressed as a Uniform Resource Identifier (URI), consequently the tuple containing an operation and a resource is declared as an action. For each action the web interface offers service users a possibility to specify a subject that is permitted to conduct a respective action. One service user is assumed to be an administrator of a larger enterprise or organization, hence a possibility to interconnect the web interface of the Policy Administration Point (PAP) to an LDAP server or to an Active Directory (AD) server. Owing to the capability of expressing precise policies with XACML the administrator furthermore can specify a time frame in which an access is
142
P. Raschke and S. Zickau
permitted, e.g., only for two weeks or daily between 9am and 5pm). Using the GeoXACML extension the policy administrator can define an area (or multiple areas, using polygons) from which an access is allowed, e.g., only within the facilities of the enterprise. An omitted statement is interpreted as no restriction. With the help of these two information sources (template and user input) a complete GeoXACML policy is generated. 3.1
Architecture Overview
The involved parties are the Service Provider, the Trusted Third Party and the Enterprise (Service User Domain). The service provider develops one or many web services and for each web service one template is generated listing each action of the service. The creation or generation and authenticity of named template is not in the scope of this work. Figure 1 gives an overview of the stakeholders and involved components. As stated above the presented work addresses enterprises or organizations with a set of employees with different roles and responsibilities ordinary connected within the same network (Service User Domain). Moreover a policy administrator is assumed who is in charge of the user management and the role assignment. Therefore an LDAP server is supposed to be in place, from which a list of employees and their roles can be retrieved. It is connected to the PAP web interface. Requests from the network proceed through the trusted third party’s Policy Enforcement Point (PEP) where an XACML compliant request is formulated and transmitted to the Policy Decision Point (PDP). The XACML conformable response is retransmitted to the PEP, which either proceeds or aborts the request. Besides the PEP the trusted third party runs a PDP at which a policy shall be evaluated. Generated policies can be delivered from the PAP to the PDP usually stored in a PRP. Generated policies contain user and service identifiers. A connection between the PAP and the LDAP of the service user is required to enable access to the service users’ information. The architecture of the service itself is open to the service providers’ restrictions and needs. Figure 1 generically outlines a typical service architecture. 3.2
Interface Procedure
The web interface is located at the PAP to create and modify existing policies. The use case Create Policy is performed by the administrators of the respective enterprise. They express the enterprise’s restriction via the web interface and generate the policy. The service providers are in charge of the use case Generate Template, which involves the creation of the template file and the transmission to the PAP. To summarize the main functions of the web interface enterprises need to be authenticated so policies created within a certain session can be related to them, the template file of a certain service must be parsed and converted into a web form and input of the user has to be verified and processed to a valid XACML policy.
A Policy Generation Interface for RESTful Web Services
143
Fig. 1. Architecture Overview
At first the users authenticate at the login page. If the provided credentials are correct the users are redirected to the service overview page. Within the service overview page the booked services are presented. From here they are able to logout again, switch to the LDAP configuration page, or select a service for which they intend to generate a policy. On the LDAP configuration page the users are asked to provide their enterprise’s LDAP information. In case of a logout, the users are directed to a blank page where their current session is destroyed. When selecting a specific service, the users are redirected to the service page where the template of the service is parsed and an appropriate form is generated (see Fig. 2). Nevertheless, if the users did not provide any LDAP information, they are immediately redirected to the LDAP configuration page without printing any content of the service page. The users are able to get back to the service overview page. After expressing their restrictions with the help of the provided form, they can start the process of generating the policy. A success page showing the generated policy is presented to the users. 3.3
REST Template Structure
Each service generates an XML template file listing all actions the service performs. As already stated the creation and authenticity of this file are not within the scope of this article.
144
P. Raschke and S. Zickau Listing 1. REST Template Schema (simplified)
Listing 1 shows the schema of the XML service templates. The root of the XML file is the element, which defines the three attributes id, name and url. The attribute id must be a unique numerical identifier. The attribute name simply gives the name of the service whereas the attribute url specifies the URL of the service. It is to note that the url attribute has to be given as regular expression starting with the character ˆ and ending with the $ sign. The element contains a element and a element. The element compromises a service description; the element contains a sequence of elements. A element specifies a methods attribute of type string, an attribute url of a regular expression type and an attribute params of type string. Further, the element contains a element, which describes the semantic meaning of the element. Listing 2 shows a REST example template for a simplified patient management service. Listing 2. REST Template Example (simplified) The Patient Management System (PMS) is a central system to manage patients and their treatment during their stay in your facility. View a patients file and diagnosis. Edit a patients file. Add or modify a patient’s list of blood pressures.
A Policy Generation Interface for RESTful Web Services
145
Add or modify a medicament to a patient’s medication.
methods contains one or many operations separated by whitespace, e.g. methods=”GET POST”. url specifies a URL given as regular expression, e.g., ^http://www.example.com/resource/*$ params specifies one or many HTTP GET parameters separated by whitespace, e.g. params="id query". The params attribute can be useful to involve the service provider’s restrictions and requirements. It can express that an operation performed on a certain resource is permitted or denied if a particular parameter is provided or matches a specific value. The following maps the REST template information to the XACML policy elements, such as actions, subjects, roles, time, dates, and locations. Action. To retrieve the essential information from a services template an action is defined as a single operation on a specific resource. All actions are aggregated in a set. For each element the cross product of the methods and url attribute is built, so a element defines as many actions as it lists operations within the methods attribute. User input. Each action is expanded by the three fields subject, time and location. These attributes are specified by the service user via the web interface. Subject and Role. To express that a certain person of the enterprise is permitted to execute a particular action, the service users (the enterprise’s administrators) are able to search their local LDAP server for the preferred employee (by uid). A set of employees can be stated. Further, the LDAP server can be searched for roles to express that a specific employee type is allowed to perform respective operation on the corresponding resource. The subject field is separated into roles and users. Both subfields can contain information, which are combined into a disjunction. Time. The time field is segmented into the subcategories date and time. The date field contains two dates whereby the second value is never situated in the past when compared to the first date. A further constraint is that either both values are empty or both have to be given. The date field can be used to express that a particular action is permissible within a period. The subfield time is analogously given to express that an action is permitted at specific hours (e.g. between 9 am and 5 pm). Limitations for the date field apply to the subfield time. The subfields do not exclude each other, information of both are conjunct. Location. The location field expresses that a specific action is feasible to conduct within a single or multiple areas. An area (or polygon) is defined as a set of points whereas a point consists of a latitude and longitude field. Multiple areas are merged into a disjunction (see Fig. 3).
146
3.4
P. Raschke and S. Zickau
XACML Rule
To finally transform the information into a valid GeoXACML policy, the information of the subject, time and location fields are merged into a single conjunction forming a predicate (see logic expression 1 below). (role ∨ users) ∧ (date ∧ time) ∧ (location1 ∨ location2 ∨ ... ∨ locationk )
(1)
As shown in Listing 3 a element contains at least a and a element whereas the element is the predicate, which must be satisfied to assign the rule’s decision its Effect attribute. The element is defined as the respective action including its operation and resource. Therefore a rule expresses that a specific access to a resource is permitted if the predicate is satisfied by the response context. A complete GeoXACML policy can be generated at this point since all relevant information is gathered. The policy then is used at runtime to control access to resources. Listing 3. XACML Rule Example (simplified) login
