Integration

The integration into the data layer consists basically of three steps: • Providing input data

• Calling the modified Rhino implementation

• Including the generated provenance data into the new SU

If no provenance data is gathered the variables in the source code to perform the calculations for new values are replaced by their values (see Listing 2).

Listing 2: Original input string 1 // Initial JavaScript code with replaced aliases

2 String computationCode1 = "Math.sqrt(channels$latitude$current-value)";

3 // JavaScript code with variables replaced by their values

4 // (values come form input SUs)

5 String computationCode2 =

6 computationCode1.replace("channels$latitude$current-value","42");

7 // Final result of computationCode2 is: "Math.sqrt(42)"

However to track the variables during runtime it is necessary that the JavaScript code still contains the variables and not only their values. Therefore, it is necessary to add a variable declaration with its initial value for each variable3 instead of replacing it with its value. Listing 3 shows a small example to illustrate this.

Listing 3: Requred input string 1 // Initial JavaScript code with replaced aliases

2 String computationCode1 = "Math.sqrt(channels$latitude$current-value)";

3 // Build map that maps variable names and there value

4 HashMap<String, String> inputVars = new HashMap();

5 inputVars.put("channels$latitude$current-value", "42"); 6 // JavaScript code required for to track variable accesses

7 // (values come form input SUs)

8 String computationCode3 = ProvenanceAPI.buildString(

9 inputVars, computationCode1); 10 // Final result of computationCode3 is:

11 // "var channels$latitude$current-value = 42; 12 // Math.sqrt(channels$latitude$current-value)"

A function that builds such an input string is provided by the provenance class (see Subsec- tion 3.4.5). It requires as inputs the string with replaced aliases and a map with the variable names as keys and its current-value as value. Besides this, a map should be built including the variable names as keys, where each key is mapped to a SU. The value corresponding to a specific key in the map is a String containing the JSON representation (including the provenance information) of the SU. This information is required for the third step.

The second step of the integration is to use the modified Rhino implementation to execute the JavaScript code. This has to be done by using the Rhino API, instead of using the ScriptEngineManager class.

Listing 4 shows a small example how to use the Rhino API to execute a JavaScript code String in Java.

Listing 4: Rhino API

1 // Code to execute JavaScript code inside a Java program 2 // using the Rhino API

3 String js_code = "1+1";

4 Context cx = Context.enter();

5 Scriptable scope = cx.initStandardObject();

6 Object result = (Object)cx.evaluateSring(scope, js_code,"<COMPOSE>",1,null); 7 List<Provelement> provList = (List<Provelement>)result;

A function that encapsulates the call to Rhino is also provided by the provenance module (see Subsection 3.4.5). The type of the returned result-object for the modified Rhino im- plementation is a list of ”ProvenanceElements”. This list contains the data gathered during the program execution.

In the third step this list of ”ProvenanceElements” is passed together with the above mentioned map (which maps variables to a SU) to the buildProvenanceJSON function (see Subsection 3.4.5). This function returns a string that contains the provenance data for the new SU in JSON format. This has to be added to the JSON file of the new SU.

The first two steps have to be performed during the pre-filer, post-filter and at the calculation for the new current-value. The third step has only to be performed when a new SU is actually generated. The provenance data for the new SU will then build based on all the gathered provenance data(pre-filter,post-filer and current-value computation) since they all had influence on the new SU.

Read accesses that lead to no new SU are not handled by the currently integrated prototype. Situations where such data accesses can appear are direct accesses to a SU in the data base (not via a SO) or if the pre- or post-filer of an SO returns false. The decision to exclude

this from the current prototype was done in consultation with WP2. It is based on the fact that the Data Management Layer uses a Couchbase database as storage for the SU which is a NoSQL database. As a result, there would be no guaranty that no accesses would be lost due to the database properties. Support for such read accesses might be added in a later step depending on the performance impact of the current prototype and the requirements of the modules that use the provenance information.

3.4.5 Interfaces

This subsection describes the application programming interface (API) of the provenance module. The following Listings 5, 6, 7 and 8 show the three above mentioned functions together with the function to access the actual result of a computation. The previously mentioned calls are required for the integration with WP2 . The behaviour of these functions is described in Subsection 3.4.4. The String value named ”security metadata” shown in Listing 8 contains the replicated information returned by Identity Management during the registration of a SO, and it is used to extract attributes such as the owner of the SO (see Subsection 2.5.2). Additionally, all functions exposed in the provenance API are static (see Seection 3.4).

Listing 5: Rhino API ”buildString”

1 // Build input string containig variable declarations and inizialisations

2 String ProvenanceAPI.buildString(

3 Map<String, String> variableAndValue, //Maping variable names there value

4 String computation) //Single JavaScript statement

Listing 6: Rhino API ”executeWithProv” 1 // Execute code with the modified Rhino

2 List<Provelement> ProvenanceAPI.executeWithProv(

3 String code) //JavaScript statement together with

4 // variable declaration and inizialisation

Listing 7: Rhino API ”getResultValue” 1 // Returns the actual "return value" of the computation

2 Object ProvenanceAPI.getResultValue(

3 List<Provelements> provData) //Contains all information

4 // gathered during runtime

Listing 8: Rhino API ”buildProvenanceJSON” 1 // Convert provenance data into JSON format

2 String ProvenanceAPI.buildProvenanceJSON(

3 String securityMetaData, //Identity Management data for SO (JSON)

5 // gathered during runtime

6 Map<String, String> VarNameSuPath) //Maping between variable names and SU

3.5

What is being demonstrated

In the demo for the provenance prototype the following functionalities are demonstrated: • Generation of provenance data

• The advantage of runtime dependent provenance information will be illustrated by an example. The example will have similar structure like the one described in Section 3.2 (a >1?b:c). This will show that only actually (during runtime) accessed data will be added to the provenance information.

• The generated JSON files will be shown. These files include the used operation like sqrt or addition to calculate the values.

4

Future directions

In the following subsections the future work for Identity Management, and Data Provenance is described.

4.1

Additional attributes

A direction to extend Identity Management in the future is to let users define additional attributes associated to them or the entities they administer. An example to show the usefulness of such attributes is given below:

Lets assume there is a well known company developing sensors called ”MySensor.Co”, and COMPOSE users are starting to notice these sensors have an extraordinary precision, and therefore they start choosing them over others. As a result, companies deploying service objects in COMPOSE will want to be able to specify that their sensor is developed by a particular brand (such as ”MySensor .Co”). In order to support this, users should be able to create arbitrary additional attributes which represent such concepts.

For the sake of the argument, lets say that users start specifying additional attributes called ”device brand” with the value ”MySensor. Co”, and their devices are chosen; it won’t be long until some users start tagging COMPOSE Service Objects with such attributes, even though their sensors are not really manufactured by ”MySensor .Co”, taking advantage of the name of the sensor company.To prevent this, a ’generic’ (up to some extent) mechanism should be provided to enable authorities to manage such additional attributes. In the partic- ular given example, this should be achieved by assigning some entity as the authority which approves that an entity is able to place an additional attribute named ”device brand” with the value ”MySensor .Co”.

If Compose Identity Management were to implement the extension to support additional attributes, it would be required to answer many questions; for example, who can define the authority responsible for approving a certain value for a given attribute?. Which would be a suitable policy language to represent the verification of an authority once a Principal attempts to change or approve some attribute value? How to solve policy conflicts between authorities?.

Since there is not a specific requirement for supporting Additional Attributes in COM- POSE at the moment, and due to the complexity of the posed questions, the necessity of the implementation of such mechanisms (additional attributes) is still under investigation.

4.2

Provenance

The extension and refinement of the current provenance prototype can have multiple direc- tions and aspects in the future. The impact of provenance collection, mainly with respect to performance (runtime and persistent memory consumption), of the current prototype on the data layer (WP2) has to be examined. This could lead to adjustments to the prove- nance data representation, and collection mechanisms. These modifications are foreseen at

the moment, and therefore, are already shortly addressed in Subsection 3.4.2. Another issue that will be addressed in the future is data provenance between services respectively.

As shown in Section 3.2 there are plenty of possibilities to use provenance data. For instance, provenance could be used for debugging and auditing purposes. Additionally, the usability of provenance information for policy enforcement could also be addressed in the future. Some possible use-cases are already mentioned in Section 3.2. Also, provenance could support trust and reputation mechanisms in COMPOSE. Another possibility would be to investigate the different kinds of information flow policies that could be defined using provenance information.

References

[1] Vlad Trifa and Iker Larizgoitia. Design of the object virtualization specification. COM- POSE Deliverable D2.1.1, October 2013.

[2] Daniel Schreckling, Juan David Parra, Marko Vujasinovic, Alessio Gugliota, and Rizwan Asghar. Security requirements and architecture for compose. COMPOSE deliverable D5.1.1, 11 2013.

[3] Vincent C Hu, Karen Scarfone, Rick Kuhn, and Kenneth Sandlin. Guide to Attribute Based Access Control ( ABAC ) Definition and Considerations DRAFT NIST Special Publication 800-162 Guide to Attribute Based Access Control ( ABAC ) Definition and Considerations.

[4] Lingyu Wang, Duminda Wijesekera, and Sushil Jajodia. A logic-based framework for attribute based access control. In Proceedings of the 2004 ACM Workshop on Formal Methods in Security Engineering, FMSE ’04, pages 45–55, New York, NY, USA, 2004. ACM.

[5] IsabelF. Cruz, Rigel Gjomemo, Benjamin Lin, and Mirko Orsini. A constraint and attribute based security framework for dynamic role assignment in collaborative envi- ronments. In Elisa Bertino and JamesB.D. Joshi, editors, Collaborative Computing: Networking, Applications and Worksharing, volume 10 of Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering, pages 322–339. Springer Berlin Heidelberg, 2009.

[6] E. Yuan and J. Tong. Attributed based access control (abac) for web services. InWeb Services, 2005. ICWS 2005. Proceedings. 2005 IEEE International Conference on, pages –569, July 2005.

[7] Niklas Broberg and David Sands. Paralocks: Role-based information flow control and beyond. In Proceedings of the 37th Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, POPL ’10, pages 431–444, New York, NY, USA, 2010. ACM.

[8] Dieter Gollmann. Computer Security. John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester West Sussex, England, 2006.

[9] Robert Kleinfeld and Lukasz Radziwonowicz. Functional requirements and specification of open marketplace developers api. COMPOSE Deliverable D6.1.1, October 2013. [10] Cloudfoundry user account and authentication (uaa) server. https://github.com/

cloudfoundry/uaa. Accessed: 2014-03-30.

[12] Openid connect. http://openid.net/connect/. Accessed: 2014-03-30.

[13] Simple cloud identity management: Core schema 1.0. http://www.simplecloud.

info/. Accessed: 2014-03-30.

[14] Bosh release for a ssl proxy. https://github.com/cloudfoundry-community/

sslproxy-boshrelease. Accessed: 2014-04-10.

[15] Setup internal ssl communication. https://github.com/

cloudfoundry-collaboration/vcap/wiki/Setup-internal-SSL-communication.

Accessed: 2014-03-30.

[16] Setup internal ssl communication. https://github.com/cloudfoundry-attic/vcap/

pull/101. Accessed: 2014-03-30.

[17] Pivotal web services forums: Ssl certificate for custom domain. http://support.run.

pivotal.io/entries/24453417-SSL-certificate-for-custom-domain. Accessed:

2014-03-30.

[18] Api keys. https://developers.google.com/console/help/new/

#generatingdevkeys. Accessed: 2014-03-30.

[19] Kiran-Kumar Muniswamy-Reddy, David A Holland, Uri Braun, and Margo I Seltzer. Provenance-aware storage systems. In USENIX Annual Technical Conference, General Track, pages 43–56, 2006.

[20] David Carrera and Alvaro Villalba. Design of the object composition specification and components. COMPOSE deliverable D2.3.1, 10 2013.

[21] David FC Brewer and Micheal J Nash. The chinese wall security policy. 1989.

[22] Christoph Bier. How usage control and provenance tracking get together-a data protec- tion perspective. InSecurity and Privacy Workshops (SPW), 2013 IEEE, pages 13–17. IEEE, 2013.

[23] The llvm compiler infrastructure. http://llvm.org/. Accessed: 2014-04-17.

[24] Chris Lattner and Vikram Adve. Llvm: A compilation framework for lifelong program analysis & transformation. In Code Generation and Optimization, 2004. CGO 2004. International Symposium on, pages 75–86. IEEE, 2004.

[25] Alon Zakai. Emscripten: an llvm-to-javascript compiler. In Proceedings of the ACM international conference companion on Object oriented programming systems languages and applications companion, pages 301–312. ACM, 2011.

[26] Rhino hacker guide. http://ringojs.org/documentation/rhino_hacker_guide. Ac- cessed: 2014-04-17.