Collaborative Open Market to Place Objects at your Service

Transcription

1 Collaborative Open Market to Place Objects at your Service D5.2.1 Prototype providing identity management and provenance in COMPOSE Project Acronym Project Title COMPOSE Project Number Work Package WP5 Information and service security Lead Beneficiary UNI PASSAU Editor Juan David Parra UNI PASSAU Reviewer David Carrera BSC Reviewer Alessio Gugliotta INNOVA Dissemination Level PU Contractual Delivery Date 30/04/2014 Actual Delivery Date 30/04/2014 Version V1.0 c D5.2.1 Prototype providing identity management and provenance Page 1 of 39

2 Abstract With this document, we provide a description of the identity management system and the gathering of provenance data.the description includes the goals of these modules in COM- POSE and how they are archived. The document will not only describe the internal structure of these security components, but also sketch their interactions with other COMPOSE components, their functionalities, and a short description of what is being demonstrated in this deliverable. This document is divided in three main parts discussing Identity Management, Data Provenance, and future directions for both tasks. For the first two mentioned chapters, the main design decisions and architecture of the developed prototypes are also shown. c D5.2.1 Prototype providing identity management and provenance Page 2 of 39

3 Document History Version Date Comments V0.1 01/04/14 Initial document structure V0.4 07/04/14 Draft on Identity Management and Provenance V0.5 16/04/14 Revised version with respect to consistency of the document V0.6 17/04/14 First full version V0.7 28/04/14 Revised version based on comments from internal reviewers V0.8 28/04/04 Internal PASSAU review V0.9 29/04/04 Revised version based on comments from Internal PASSAU review V1.0 30/04/04 Final version Authors Author Wolfram Gottschlich Juan David Parra Daniel Schreckling Partner UNI PASSAU c D5.2.1 Prototype providing identity management and provenance Page 3 of 39

4 Contents 1 Introduction 9 2 Identity Management The Goal of Identity Management Main Design Choices Entities Attributes Authorities Access Control Creation of Users Creation of other Entities Update Entities Getting information for specific Entities Architecture Integration with Cloud Foundry Confidentiality of communications in Cloud Foundry Integration with COMPOSE components Service Object Registry Interaction with COMPOSE Entities Functionalities What is being demonstrated Interfaces Provenance Data Management Layer The Goal for Provenance in COMPOSE Design Instrumentation Modifying the runtime environment Static Analysis Design choice Approach Overall architecture Provenance data representation JSON Attributes Example Rhino Integration Interfaces What is being demonstrated c D5.2.1 Prototype providing identity management and provenance Page 4 of 39

5 4 Future directions Additional attributes Provenance c D5.2.1 Prototype providing identity management and provenance Page 5 of 39

6 List of Figures 1 Interaction between IDM and Cloud Foundry Interaction between IDM and Service Object Registry Interaction between entities and Identity Managment Architecture to gather provenance information for SU Different representations for provenance data User close by each other example c D5.2.1 Prototype providing identity management and provenance Page 6 of 39

7 List of Tables 1 Entities and their attributes c D5.2.1 Prototype providing identity management and provenance Page 7 of 39

8 Acronym Acronym API COMPOSE IDM JSON SO SU WP2 Meaning Application programming interface Identity Management JavaScript Object Notation Service Objects Sensor Update Work package 2: Objects as a service Terminology Term entity service source code Service instance Web Object Service Object Description entities can be services, service object, applications, users, or service source codes in COMPOSE. Source code for a service which can be potentially run in COM- POSE. a service running in COMPOSE platform. Real world object as that provides information about (via sensors), or initiates changes in its environment (via actuators), and communicates with COMPOSE platform via the Web Streams Model defined in D2.1.1 [1]. Standard internal COMPOSE representations in the data management layer for of Web Objects. c D5.2.1 Prototype providing identity management and provenance Page 8 of 39

9 1 Introduction When designing a Market-place for the Internet of things many security challenges arise; for example, how to define and enforce policies that let users have control over data generated by their devices, how to authenticate the different actors in the Marketplace, or how to let users decide which services should they use depending on the previous behaviour of them. As result, security is a subject that requires attention for such systems. In order to empower users to control where their data is flowing, first the groundings for identifying and authenticating different users and actors in COMPOSE are required. This is covered by the COMPOSE Identity Management component. On the other hand, additional support for security mechanisms can be provided by collecting and storing the history of data in COMPOSE. This will be achieved through the Data Provenance component. The results of the development of these two components is described in the following sections. For Identity Management, several changes have been made since the first version of the security architecture described in D5.1.1 [2]. This was done, in order to mitigate the negative impact on performance that the original mechanisms would have had on the runtime of services, and service objects running within COMPOSE. These modifications include, reduction of HTTP messages among entities, as well as replication between Identity Management and the Data Management Layer (WP2). In the case of Data provenance collection, different representation formats where discussed with other project partners in order to find a suitable starting point for data provenance storage and collection. Furthermore, a modification of the runtime environment used in the Data Management Layer was performed, in order to access runtime dependent information. This information will reveal information flows, and basic operations on the data. In addition to the data provenance module described here, inter- and intra-service information flow analysis will be performed in task 5.4 in the future. c D5.2.1 Prototype providing identity management and provenance Page 9 of 39

10 2 Identity Management Identity Management covers the administration of identities, as well as their authentication. Furthermore, Identity Management needs to enforce access control policies in order to prevent unauthorized modification to identities. In the following sections, the different aspects mentioned above will be addressed to show the functionality of Identity Management in COMPOSE, as well as how Identity Management fits in the overall architecture of COMPOSE. 2.1 The Goal of Identity Management Identity Management is the cornerstone for security mechanisms in COMPOSE. It administers identities for every actor in COMPOSE, such as service objects, applications, users, etc. Once there is a service to manage identities and authenticate principals in COMPOSE (i.e. Identity Management component), it is possible to start defining security policies for them, as well as defining the access control mechanisms required to enforce those policies within the platform. An important part of the research and innovation from the security perspective in COM- POSE is the definition of data-centric security policies in the Marketplace environment, as well as proper access control mechanisms to enforce them. As a result, Identity Management must not only handle simple constructs such as groups of entities, but also must provide mechanisms for more fined grained mechanisms 2.2 Main Design Choices To keep Identity Management as simple as possible for new users,they will be able to define groups. COMPOSE groups can be comprised of different kind of entities at the same time, such as services, users, and service objects; as a result, they can be used to define policies. However, in COMPOSE Identity Management, there needs to be additional support for other attributes related to identities which enable more fine grained security policies and enforcement mechanisms.due to the reasons exposed previously, Identity Management is based in Attribute Access Control since it is the most general model which covers Role Based Access Control model (RBAC) among others 1. There are a number of definitions for Attribute Based Access Control [4] [5] [6]. Luckily there is a fairly recent effort leaded by the National Institute of Standards and Technology (NIST) [3] that describes Attribute Based Access Control as follows: Attribute Based Access Control: An access control method where subject requests to perform operations on objects are granted or denied based on assigned attributes of the subject, assigned attributes of the object, environment conditions, and a set of policies that are specified in terms of those attributes and conditions 1 ACLs and RBAC are in some ways special cases of ABAC in terms of the attributes used. ACLs work on the attribute of identity. RBAC works on the attribute of role [3] c D5.2.1 Prototype providing identity management and provenance Page 10 of 39

11 Attributes constitute the basis for defining security policies in a flexible manner. For example, with attribute based access control it would be possible for a user to define a policy enabling services to act on his behalf only when they have a reputation value higher than a certain threshold, and they belong to a group, and they are accessible in a URI that starts with a certain domain. On the other hand, very simple policies could also be represented; for instance, it could also be possible to do access control decisions by just checking one attribute (e.g. group) and grant access depending on the value of only one attribute. As always, the complexity and expressiveness for policies downgrades the runtime performance, and makes enforcement mechanisms harder to implement. The previous examples of policies are mentioned to illustrate the potential achieved when representing identities as Entities with their own attributes; however, the different kinds of policies that users will define in COMPOSE as well as the language used for this purpose is still under investigation. Another advantage of attributes is that they can offer support for the definition of potentially very fined grained access control mechanisms, such as paralocks, which are a promising mechanism for information flow policy enforcement [7]. 2.3 Entities Entities in COMPOSE will have a fixed set of attributes representing them, and in the future additional attributes may be supported in a generic manner (see subsection 4.1). The list of entities and their attributes is show in Table Attributes As mentioned before attributes represent values for each entity. Those values are protected by predefined Access Control mechanisms, and therefore can be used for security related decisions such as access control among entities principals in COMPOSE. In COMPOSE there is a dedicated attribute to represent groups. They are non-hierarchical, and therefore every user can create new groups. For every entity, the groups to which it belongs constitutes another attribute. This attribute must be approved by a group administrator, and by the owner of the entity. Additionally, a user can have different memberships. Each membership represents a pair of (role, group) to specify that this user has a specific role, in a specific group. Roles assigned to the user must be one of the following: developer, service provider, object provider, admin, end-user. This attribute requires mutual agreement between the admin of the group where the user has the membership, and the user which includes this membership value among his attribute values. Service Objects have an API TOKEN (if they receive data from outside of COMPOSE). This token will be used to authenticate the Web Object from which the Service Object is receiving data. As a result, whenever the COMPOSE data layer receives data from outside of COMPOSE, it is possible to verify that the API TOKEN corresponds to the token for the given service object. The Identity Management API only reveal this token to the data layer component in COMPOSE, or to the Service Object owner. c D5.2.1 Prototype providing identity management and provenance Page 11 of 39

12 Additionally, there is a boolean attribute dedicated to payment (in case COMPOSE covers payment mechanisms within it s lifespan). This attribute is not meant to be used to implement the payment functionality, but instead to serve as a flag that would trigger additional interactions with components that could handle these functionalities in the future. The Type column describes the data type of the attribute. In case the attribute is a reference to another entity, the type of the entity is stated Authorities It is recommended as best practice to ensure that attributes are provisioned by attribute authorities [3]. This proves to be essential in order to ensure the effectiveness of the Access control mechanisms. As a result, for every (modifiable) attribute mentioned in 1, a given authority is stated in the Authority column. The authority column specifies the context and the privileges required to modify the value. For example, when authority is blank this means the field cannot be changed after creation; when the authority column states runtime, reputation, or Identity Mgmt this means that this attribute can changed only by those COMPOSE components. Whenever the term m. agreement is displayed in authorities, this implies that mutual agreement is required; that is to say, the owner of the attribute (such as the owner of the group), and the entity for which the attribute is set need to agree to setting the value. This is required to prevent users from adding themselves to groups without the owner of the group permission, or to prevent group owners adding users to groups without their knowledge. Finally, for attributes that are only valid during a specific execution scope (request, thread, etc.) and are not persisted, a special authority is required. Such attributes are marked with the authority named transient, which represents that the attribute is determined during execution and it is only valid during the scope of the request or the thread execution in a service or a service object. 2.4 Access Control To protect the integrity of identities managed within COMPOSE, suitable Access Control mechanisms need to be defined. But in order to describe such mechanisms, proper terminology is required. For this purpose, a well established definition of the Fundamental Model for Access Control is taken from [8]. The very nature of access suggests that there is an active entity, a subject or a principal, accessing passive object with some specific access operation, while a reference monitor grants or denies access. Principals are subjects previously authenticated by Identity Management that can either store, read, update or delete objects representing identities in COMPOSE. On the other hand, The passive objects on which the access operations are taking place are named Entities from now on, and they are all the identities that exist in COMPOSE. Entities are described in more detail in the Table 1. However, the reader should keep in mind that there are 2 Only in these cases, there can be more than one attribute with the same name, but they are interpreted as an unordered list c D5.2.1 Prototype providing identity management and provenance Page 12 of 39

13 Entity Attribute Type Authority Group group id id - owner - - name string owner Application application id id - owner user - group 2 group m. agreement name string owner acting on behalf user transient Service instance service id id - URI String runtime owner user - group 2 group m. agreement service source code service source code - reputation integer reputation collect provenance boolean owner payment boolean owner acting on behalf user transient Service Composition service id id - owner user - group 2 group m. agreement service source code service source code id id - name string owner version string owner developer user - group 2 group m. agreement reputation integer reputation payment boolean owner service object service object id id - owner user:object provider - group 2 group m. agreement reputation integer reputation collect provenance boolean - payment boolean owner acting on behalf user transient api token string Identity Mgmt. User user id id - username string this membership 2 membership m. agreement reputation integer reputation Table 1: Entities and their attributes in COMPOSE c D5.2.1 Prototype providing identity management and provenance Page 13 of 39

14 certain operations, such as reading information for an entity, which are not subject to access control at the moment; therefore, it is not required that the access operation (reading data in this particular case) is executed by a principal, but instead they can be executed by any subject capable of communicating with the API. To conclude the terminology definition, the reference monitor mentioned in the previous definition is located inside the Identity Management system, and it implements the Access Control mechanisms described in this section ensuring that only principals with sufficient permissions can execute access operations (subject to access control) on COMPOSE entities. Many of the functionalities of Identity Management will be executed by COMPOSE components on behalf of a certain user. As a result, in many cases there will be two different credentials to authenticate the Principals on behalf of which the request should be processed, namely the authentication credentials for the COMPOSE entity, and the credentials for the user on behalf of whom the action is being executed. Once principals have been authenticated (it is ensured that they are who they claim to be), the decision on whether or not the principal should be authorised to execute certain action is taken. The following sections define the access control mechanisms enforced by the Identity Management component in COMPOSE. Creation of Users Creation of users is authorised for certain COMPOSE components; especially those facing users which are two COMPOSE components: the meta-marketplace, and the developers portal [9]. On the one hand there is the meta-marketplace; it is the component gathering applications hosted in different Marketplaces such as Android Google Play, Apple itunes App Store, etc. On the other hand there is the developers portal; which is where developers will create applications. Those two COMPOSE Components will require interaction with Identity Management since they need to register new users. Creation of other Entities Every authenticated user is able to create Groups, Applications, Service compositions, Service instances, Service s source code, and Service Objects. Update Entities Whenever an entity is updated, their attributes are changed; since both operations are equivalent this section will explain the access control mechanisms for modifying attributes. Before changing an attribute value, it is verified that the proper Authority is part of the principals executing the action (See Table 1). Additionally, whenever a user wants to add an entity (owned by him) to a group, an administrator (or the owner) of the group must approve this action; this is part of the mutual agreement defined for COMPOSE groups. c D5.2.1 Prototype providing identity management and provenance Page 14 of 39

15 Getting information for specific Entities For now, access to information about every entity and its attributes (except tokens) will be granted to every entity deployed in COMPOSE. This approach is followed for a simple reason: If access is restricted to specific entities, this can be harmful for some functionalities of the marketplace; for example, if COMPOSE Identity Management would only enable developers to query identity information for services that they can access, this would prevent developers from creating service compositions which may not be run by them, but could be executed by their clients (who have the proper rights for execution). Additionally, for policy evaluation, information about entities needs to be queried fairly often; as a result, limiting access to attributes or entities would only make the policy decision error-prone, and harder to debug for the users and developers. In the future, some additional support to include access control rules for reading entity s information could be implemented, if necessary. Since the querying of entities and attributes is open at the moment, COMPOSE Identity Management doesn t require any information that uniquely identifies a user, such as names, identification number, address of residence, etc. 2.5 Architecture Identity Management will be queried by different Compose components or entities in COM- POSE. This section covers interactions of Identity Management with Cloud Foundry components, Compose components, and Compose entities Integration with Cloud Foundry Cloud Foundry offers a centralised User Authentication and Authorisation Server (UAA [10]). It is mainly implemented as an OAuth2 [11] token provider, with additional extensions to support OpenId connect [12] endpoints, as well as The System for Cross-Domain Identity Management (SCIM) specification [13] for user management. Since every COMPOSE Service instance will be deployed in Cloud Foundry, achieving integration with Cloud Foundry s Identity Management will smooth integrations in the future. Therefore, the authentication endpoint from COMPOSE Identity Management piggybacks on UAA to manage Oauth2 tokens. Additionally, it also uses the OpenId endpoints to get user information from Oauth2 tokens, and it is using the SCIM endpoints to create users in the UAA whenever a user is registered in COMPOSE Identity Management. In figure 1 it is shown an example of how COMPOSE Meta-marketplace will communicate with COMPOSE Identity Management, and also the corresponding message flow between the different components, including the UAA Server from Cloud Foundry: 1. Some person interacts with the Marketplace, in order to register himself (this could happen through a different COMPOSE component too). 2. The credentials to authenticate the COMPOSE component creating the user are sent (credentials for the Marketplace). The username, and password for the user to be created are sent to the Identity Managment. c D5.2.1 Prototype providing identity management and provenance Page 15 of 39

16 3. Identity Management verifies with the UAA that username is free, and it creates it if possible. Once the user has been registered in the UAA, it is created in the local database. 4. Identity Management replies with a success code and points to the new user as a resource location with the Location HTTP header. Confidentiality of communications in Cloud Foundry At the moment, Cloud Foundry recommends the usage the Bosh release SSL Proxy [14] for authentication and confidentiality of information exchange between Cloud Foundry infrastructure and information systems accessing the cloud components. The aforementioned proxy should be placed in front of the Cloud Foundry gorouter, which is the entry point for http messages to the cloud infrastructure. This tackles the confidentiality problem towards the outside world, therefore allowing users to communicate with the Cloud Foundry infrastructure through a single SSL channel (the SSL proxy) in a secure manner. However, once the data reaches the cloud infrastructure, it is not common practice to add confidentiality measurements (protecting the data against eavesdroppers inside the infrastructure of the cloud provider);notwithstanding, there was an attempt to enable SSL communication among components deployed within Cloud Foundry infrastructure in the past [15]. This proposed modification constituted a pull request to include in the github code repository the capability for SSL communication in the Cloud Foundry VCAP component, which is now deprecated [16]. Afterwards, some Cloud Foundry customers started requesting to be able to install their own digital certificates for applications deployed in Cloud Foundry. According to a support forum from pivotal [17] it is planned to let applications use SSL by letting them configure their own certificates in the future. Those approaches would solve the confidentiality problem within the cloud infrastructure. However, in contrast to the functionality provided by the SSL proxy that ensures communication confidentiality from the Cloud Foundry infrastructure towards the outside world (and vice versa), at the moment there are no publicly available implementations providing confidentiality between internal Cloud Foundry components yet. c D5.2.1 Prototype providing identity management and provenance Page 16 of 39

17 Figure 1: Interaction between IDM and Cloud Foundry Integration with COMPOSE components There are different interactions between Identity Management and COMPOSE components, such as the Compose Controller (deployment component), the Service Object registry (data management layer), or the user interface components (Developers portal, Meta-marketplace). Service Object Registry Service Object infrastructure will enforce access policies between Service Objects. As a result, Identity Management information is required during execution in order to take decisions; besides, The data management layer in COMPOSE faces big challenges in terms of scalability. As a result, a particularly tight integration is required between the Data Management layer and Identity Management, in order to mitigate the negative impact that security mechanisms, such as access control, might bring therein. To achieve this tight integration, some replicated information will be kept in Identity Management and inside the Service Object Registry. Such information will include, but will not be limited to the attributes for the Service object (See step 4 in 2). Additionally, every change of Identity Management values will come through the Identity Management API, and will be then forwarded to the Service Object registry, therefore keeping consistency between the two repositories. The messages represented in figure 2 are described in the following steps: 1. User (through some application, or COMPOSE Component) calls the Service Object Registry to register a new Service Object. Here the user must provide an authorization token which he obtained after authenticating himself with the COMPOSE Identity Management. 2. The Service Object Registry forwards the token, and the generated Id for the Identity Management. c D5.2.1 Prototype providing identity management and provenance Page 17 of 39

18 3. Identity Management generates an API TOKEN, and the default attributes for the Service Object being registered and sends them back to the Service Object Registry. 4. The Service Object registry stores the Identity Management information (returned in the security metadata JSON attribute in the response body), and forwards the API TOKEN to the user, so the Web Object using it can be properly configured. Figure 2: Interaction between IDM and Service Object Registry After the registration process, the Web Object can send data with the proper token and the corresponding Service Object id. Upon reception of data, the Service Object Registry will decide whether or not to accept this data by simply checking the API TOKEN provided by the Web Object against the API TOKEN stored in the Service Object registry. It is expected that the usage of tokens in Web Objects facilitates the adoption of COM- POSE due to its simplicity, and the previous adoption of API tokens by big companies such as Google (API server keys) [18] Interaction with COMPOSE Entities Interaction between the Identity Management and COMPOSE Entities, such as service objects, services, applications, is also required. In this section it will be shown how the different identities in COMPOSE will be able to query information about each other s identities. In COMPOSE, Services will be run with a modified runtime environment. This environment will inject attributes of the current service whenever communication is attempted between a service and another service, or a service object. Similarly, before data is delivered to a service, the attributes from the entity sending the request will be extracted, and this information will support the Policy decision Point when deciding whether or not the current request should be served. The rationale for this Runtime Environment modification is grounded in several reasons. First, information flow mechanisms will also enforce policies for outgoing flows of information in spite of the original program implementation; additionally, Attribute Based Access Control offers potential for considerable expressiveness, which in turn makes policy evaluation more complex, and therefore more pressing the necessity to bring such functionalities (when possible) close to the service functionality in order to avoid latency in remote calls. c D5.2.1 Prototype providing identity management and provenance Page 18 of 39

19 Furthermore, the information passed between services (which is then extracted) can not be subject to any modifications, protecting the integrity of the data for the identities. Since the proposed runtime modification is part of runtime enforcement instead of Identity Management, it is not yet implemented; however, it will be realised within Task 5.4 and will be reflected in the final COMPOSE Security framework. In Figure 3 it is shown the message flow to illustrate how Applications, and Services or the Service Object infrastructure will communicate among each other their own attributes: 1. A user sends his credentials to Identity Management through an application. 2. Identity Management verifies the credentials with the UAA, obtaining an access token for the user. 3. Identity Management replies to the application with the token. 4. The application sends the token to Service 1. Before giving the data to the service, the runtime modification intercepts the communication and collects the token, and invokes the Identity Management to query for additional information about the user (possibly). After this, the runtime determines whether or not to authorize the communication from Application to Service 1 depending security policies that may apply. 5. The modification calls the Identity Management to exchange the user s access token by information about the user s attributes. 6. The runtime packs attributes for the current Service, plus attributes from the user (to specify on behalf of which user is the service acting), and sends this data to the next service (e.g. Service 2 or possibly Service Object infrastructure). This step will happen, only if the runtime modification grants permissions to Service 1 to communicate with Service 2/Service Object infrastructure. 7. Service 2, or the Service Object Infrastructure may need additional information from Identity Management to enforce a certain policy; therefore, this message is marked as a optional message. In order to decrease the amount of messages from Service Object towards Identity Management, all the service object identity information is cached locally. c D5.2.1 Prototype providing identity management and provenance Page 19 of 39

20 Figure 3: Interaction between entities and Identity Managment The flow of messages for authentication of entities has been significantly decreased since the first version of the COMPOSE security architecture, proposed in [2], in order to improve the performance of services running in COMPOSE. 2.6 Functionalities Identity Management is implemented as a Java Spring application; as a result, it could either be deployed as a Cloud Foundry application or outside of the cloud infrastructure. Additionally, the Identity Management component is using a MySQL database to store information about the entities, and modification to those entities is achieved by calling a REST API exposed to COMPOSE components. The functionalities provided by Identity Management are: Creation of a user. Authentication of user. Creation of an entity (group, application, service instance, service composition, service source code, service Object). Get an entity by Id (group, application, service instance, service composition, service source code, service Object). Update attributes for entities (group, application, service instance, service composition, service source code, service Object). Attempt to add an entity to a group (group, application, service instance, service composition, service source code, service Object). List pending approvals group approvals for a given group. c D5.2.1 Prototype providing identity management and provenance Page 20 of 39

21 Confirm a pending approval to add an entity in a group. Attempt to add a membership (group,role pair) to a user. List pending approvals for memberships for a given group Confirm a pending approval to add a membership to a user. 2.7 What is being demonstrated In the demo for the the Identity Management prototype the following functionalities are demonstrated: Creation of a user: During this step the following functionalities will be shown during the user creation. Access control mechanism: show that only authenticated COMPOSE components are able to create users. how the creation of a user in COMPOSE Identity management is reflected in the Cloud Foundry User Authentication and Authorisation Server. how Identity Management ensures that usernames are unique. Getting information for a particular user by Id. Authentication of a user: Authentication by providing valid credentials for a user. Attempt for authentication providing invalid credentials. Creation of a group: Access control mechanism: show that a user is able to create a group. Show that when the group is created, it has the right owner (the user calling the API). Show that the system forbids a user from owning two groups with the same name. Getting information for a particular group by Id. Adding a user to a group: Show how an user can attempt to add himself to a group. Show that after he attempts to add himself to a group, the membership is not displayed until it has been approved by an administrator of the group, or the owner. c D5.2.1 Prototype providing identity management and provenance Page 21 of 39

22 Authorisation of group membership: Access control mechanism: show that only the administrator of a group can approve memberships related to his group. Show that after a membership is approved, it will appear through the API call that get data for a particular user information by id. 2.8 Interfaces Given the size of the COMPOSE Identity Management API, and the fact that it might change in the future. It has been published in a website, to make it also available to the consortium partners, in the following URLS: API for Groups: API for Applications: API for Service instances: API for Service Compositions: API for Service Source Code: API for Service Objects: API for Users: c D5.2.1 Prototype providing identity management and provenance Page 22 of 39

23 3 Provenance Data Provenance is concerned with the origin, the creator and the history of data. It also can describe the history of an item s ownership and of performed actions like creation, transformation and copying [19]. In short provenance data archives the information about when, where, who, and how a data item has been used. In the following sections different approaches to gather provenance data are mentioned and how they can and will be used in COMPOSE. Afterwards, the integration of the developed first prototype and the demonstration of this prototype is described. This deliverable focusses on provenance in the Data Management Layer (WP2). 3.1 Data Management Layer In the Data Management Layer Service Objects (SO), which are the standard internal COM- POSE representations of Web Objects, are the basic elements. New sensor values of those Service Objects are called sensor updates (SU), they are stored in the JavaScript Object Notation (JSON) format. Such sensor updates can come from outside of COMPOSE (Web Objects) or from service objects themselves. It is possible to build Service Objects which take inputs from several Service Objects [20]. To define the behaviour of service objects three options are provided: a pre-filter which returns a boolean value that indicates if the new input should trigger a new computation, which in turn generates new output the current-value computation which defines the output value to be computed for a given input a post-filer which returns a boolean value that indicates whether the new current-value will be stored as a new SU or not. The evaluation and computation source code for these three steps can be defined by a single JavaScript statement. This code will be executed by a JavaScript engine within the the Data Management Layer (Java). In the case of COMPOSE this engine is Rhino. 3.2 The Goal for Provenance in COMPOSE This section describes possible goals for provenance in COMPOSE. These goals lead to requirements for the provenance data. One goal of the generated and stored provenance information is to enable support for data-driven policy enforcement. The following simple example will show the benefit of provenance data. The user X is allowed to accesses variable a and c but not b or values that are derived from b. The output value in the example is calculated by the following JavaScript statement: a > 1?b : c The code shows that only b or c are influencing the output, depending on the value of a. To decide whether X is allowed to access the result, provenance information is required. Without c D5.2.1 Prototype providing identity management and provenance Page 23 of 39

24 such provenance information the most appropriated policy might not be enforceable for this example. A second scenario where provenance information provides the possibility to enforce other kinds of policies is the Chinese wall policy [21]. Without tracking read accesses it is not possible to support such policies. A third scenario is to enable the possibility for business policies that could be used for example for accounting purposes. For the sake of the argument, the following example is considered: A user that has 10 different sensors connected to COMPOSE allows other users to access values provided by his sensors, as long as each user reads data only from at most two of his sensors. This policy would be particularly useful because it would allow the sensor owner to let users choose freely among his sensors, but still restricting the access to a certain amount of them. Besides the support for the policy enforcement the provenance information can be used to support a reputation mechanisms, by providing information about the usage of Service Objects or services. Another possible goal of provenance information would be to provide the necessary data to detect when services could be building profile information about users in COMPOSE. Another goal, which comes from a different application area then the above mentioned, is to fulfil the legal requirements. In the European data protection law, everybody has the right to know where the organization accountable got his data from, what the data was used for, where it was transferred to and how long it is stored [22]. 3.3 Design This section explains different possible solutions for the challenges derived from data provenance collection; additionally, at the end of this section the design choices made are explained. Precise provenance information is often runtime dependent (see Section 3.2). In this case this means that the information depends on the execution of a program with a certain input value. There are several possibilities to get such runtime information. The two main approaches are: instrumenting the program under supervision, or modifying the runtime environment. These two dynamic 1 approaches are described further in the following sections; afterwards, a description of static 2 analysis is given. The aforementioned dynamic solutions could potentially be combined in a hybrid approach. Instrumentation Instrumentation could be done in two different levels: source code instrumentation, or binary instrumentation. The former consists of including additional instructions within the source code of the program under test, the latter consists of including additional binary instructions within the binary file of the program under test. Since the programming language used to compute the new sensor updates (SU) of service objects (SO) is JavaScript, and this is an interpreted language, the source code instrumentation would be more suitable in comparison to the binary instrumentation. 1 During execution of the program 2 Without or before executing the program c D5.2.1 Prototype providing identity management and provenance Page 24 of 39

25 The main advantage of the source code instrumentation approach is that it provides the possibility to develop a portable solution, it would not depend on the runtime environment. However, a disadvantage of instrumentation is that the analysis part has no control over the actual execution; therefore, it is difficult to deal with self-modifying code. With respect to security another disadvantage is that protection mechanisms are required to ensure that the instrumented code is neither changed nor replaced before the actual execution. For source code instrumentation it is beneficial to use a framework. The framework should parse the program to instrument; afterwards, it should generate the instrumented code that can be compiled or executed. For this purpose, a possible candidate would be LLVM [23]. LLVM is a widely used and powerful framework, which allows source code instrumentation for multiple programming languages. The support for different languages is implemented by different front-ends. Each frontend compiles the source code into an intermediate language (LLVM-IR), in order to instrument and compile tllvm-ir to the final representation with the help of an LLVM-backend [24]. An LLVM-back-end for JavaScript is available [25]. Unfortunately, there is not a publicly available JavaScript front-end at the moment [23]. With the existing front-ends, it is possible however to use several steps to convert Javascript code into LLVM-IR (e.g. JavaScript to Java, and then Java to LLVM-IR). These steps decrease the runtime performance, and increase the compilation time, not to mention they make the whole process error-prone. Modifying the runtime environment By modifying the runtime environment the analysis part has full control during the actual execution of the program under test. Besides this advantage, no separate instrumentation step has to be performed. Therefore, it is not required to protect the instrumented code from being changed or replaced before the actual execution. Furthermore, from a runtime point of view, modifying the runtime environment has several benefits. First of all, the code has only to be parsed once (to compile/interpret); moreover, the analysis overhead is only spent on analysing the code which is actually being executed, instead of spending time by analysing code which might not be executed (as it usually happens with Instrumentation frameworks). A general disadvantage of modifying the runtime environment is that it is not portable. As a result, the modification has to be performed in all runtime environments separately. Static Analysis With Static analysis it is possible to build a complete control flow graph, enabling the analysis framework to detect branches in the code, which are potentially harmful. Those branches would not be detected until their execution is actually attempted if only dynamic analysis would be performed (input sensitivity). Most static analysis approaches have also a runtime advantage in comparison to dynamic analysis approaches since they are dependent on the length of source code (of the program under test) and not on the runtime (of the program under test). This is especially an c D5.2.1 Prototype providing identity management and provenance Page 25 of 39

26 advantage for programs that contain many repetitions of code sections like loops or recurrent function calls. On the other hand, with static analysis it is not manageable to gather all kinds of runtime dependent information, especially for pointer operations or self-modifying code. Design choice Since ensuring integrity of the instrumented code in JavaScript is a complex task, given the properties of the language. Also, due to the lack of availability of mature instrumentation frameworks a runtime environment modification is chosen for the current prototype. As mentioned previously it is possible to combine static analysis with instrumentation or with a runtime environment modification in order to combine the advantages of a static and dynamic analysis. This could be done for example by performing a static analysis and only analyse dynamically the parts that could not be determined by the static analysis. This would reduce the runtime overhead during execution, and it would still be possible to gather runtime dependent information. Such an hybrid approach can be implemented in a future prototype. 3.4 Approach This section describes the approach to gather and store provenance information for SU generated by SO since this is the place where data is processed in the Data Management Layer (WP2). Moreover, the concept of this approach is applicable for COMPOSE services. Runtime dependent provenance information is produced at three points in the case of SU generated SO (see Section 3.1): During the calculation of the new current-value During the evaluation of the pre-filter During the evaluation of the post-filter Currently, the evaluation of a pre-filter, and a post-filter, as well as the calculation of the current-value in a Service Object, is described by a single JavaScript statement. However, in order to execute this single statement, declaration and initialisation for all used variables is required, and therefore needs to be included in the JavaScript code that is actually executed by the underlying JavaScript engine (Rhino). In order to gather provenance data, the JavaScript code is executed in a modified Rhino version in order to return provenance data with the actual result of the JavaScript computation. This Rhino version is part of the provenance module inside the Data Management Layer, and will be explained in more detail in the following section. This Rhino version monitors the execution to track all variable accesses. This includes storing all read and write accesses of variables during the execution (excluding the added c D5.2.1 Prototype providing identity management and provenance Page 26 of 39

27 initialisations). This provides the necessary information to fulfil the goals described in Section 3.2. The returned provenance information contains only information about the relevant variables which are the variables actually used to compute the pre-filter, post-filer and current-value. Also the performed operations like sqrt or addition will be retuned for variable accesses. The provenance module is designed stateless to reduce dependencies with respect to integration purposes and performance (possible parallelisation of the analysis for pre-filter, postfilter and current-value computation). The data model described in Subsection for the provenance information is not only suitable for SU but also for other entities like services. Therefore, the data-model does not have to be changed to represent service s provenance information. Since the gathering of provenance has to be done at least partially during runtime, it is necessary to make similar modifications, like the one performed on Rhino, to the runtime environment for services to extract the required information. In the case of Services another difference is that the JavaScript code that can be used to calculate the output is not restricted to a single JavaScript statement. This enables for example the opportunity to define loops and the declaration of additional variables. In the case of a single JavaScript statement all accessed variables have either direct or indirect influence on the actual result. On the contrary, when analysing more complex JavaScript code sections, it would be necessary to build a data structure that enables the possibility to unroll which variables actually had influence on the returned value. Since the return value is not available until the end of the execution, this data structure is required Overall architecture The overall architecture to gather provenance information for SU is shown in the flowing figure The architecture to gather provenance information for services will look similar. The class in the Data Management Layer to compute new SU of a SO gets a JSON file of the SO and the JSON file(s) of the required SU as input to generate the resulting new SU. This class then calls the modified Rhino implementation to execute the JavaScript code to calculate the pre-filer, current-value or post-filer. The result of this calculation contains provenance information and the actual result. With this provenance information the JSON file for the new SU is generated. For integration details and interfaces see Section Provenance data representation This section describes the how provenance data is represented and stored. The provenance data is stored in the JSON file of its corresponding SU. The reader should keep in mind that in this section the term entity is used for all data items containing provenance information. c D5.2.1 Prototype providing identity management and provenance Page 27 of 39

28 Figure 4: Architecture to gather provenance information for SU JSON Attributes The provenance data consists of the following attributes: provenance.agent: (SO service) Contains the type of the provenance.entity. provenance.type: (sensor update file service object update etc) Represents the type of the current object to which the provenance data belongs. provenance.entity: (sensor update unique id path of file location of the actual data... ) This contains a reference to the corresponding entity. This is not necessary for SO since this id is available in the JSON document containing the provenance info. However, for provenance in services this is different. provenance.activity: (creation derived from etc.) Describes how the current object is generated from the sources. provenance.timestamp: (time in ms) Contains the time when the current object is created. provenance.accessed: {[userid groupid other entities with delegation, time in ms]} Map that contains the id of the entity that accessed the current object with the time of its first access of this object. c D5.2.1 Prototype providing identity management and provenance Page 28 of 39

29 provenance.onbehalf of: (user) The id of the user, on-behalf of whom this object is created. provenance.sources: (if activity == creation > web object id. If activity == derived from > list of data items) List of all sources that were used to create the current object, represented by there provenance data. The sources are stored in a tree structure. For the data representation of the source attribute multiple possibilities are suitable. There are basically two main approaches for its representation: storing references or coping the provenance data of the source(s) storing only information to the direct sources or storing information to all sources (in for example a tree structure) Figure illustrates how for the two approaches would represent provenance information. In the figure, it is assumed that the first sensor update (ID=1) is used to generate the second sensor update (ID=2), and so on. Figure 5: Different representations for provenance data c D5.2.1 Prototype providing identity management and provenance Page 29 of 39

30 JSON files for objects of the data layer will be stored in a Couchbase database. This kind of database will perform better on a provenance representation without intensive use of references. Additionally, at the moment there is on-going research in WP2 considering the possibility to include ElasticSearch, and since ElasticSearch will perform better when searching within one single file including provenance data, than when searching in multiple small files with several references among them. For the exposed reasons, the current prototype is storing the whole provenance data of all sources in a tree structure (see second example of Figure 3.4.2). The impact of the current prototype on the Data Management Layer (WP2) has to be monitored. The size of the JSON files has also to monitored to check if the current solution is also scalable in the sense of memory usage. This mainly regards the source attributes in the JSON format for the current prototype. The size of this value heavily depends on the number of nodes contained in source tree. Depending on the measurements mentioned above, modifications in the representation and the collection of provenance will be made in order to find solutions which improve runtime and memory consumption for storing provenance data. Example This paragraph illustrates the above described provenance data model by showing an example. Figure 6 shows structure of the example. For the following example, two users want to Figure 6: User close by each other example meet each other, and each one of them has a service object (red) processing their location. There is another service object calculating the distance between the two users. The SO that is calculating the distance is highlighted in green. The Listing 1 shows the provenance information for a SU generated by the green SO. This provenance information would be part of the SU. 1 "provenance":{ Listing 1: Example provenance data 2 "agent" : location.distence.so, 3 "type": sensor_update, c D5.2.1 Prototype providing identity management and provenance Page 30 of 39