WWW

286 views
218 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
286
On SlideShare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

WWW

  1. 1. Security Issues in a SOA-based Provenance System Victor Tan, Paul Groth, Simon Miles, Sheng Jiang, Steve Munroe, Sofia Tsasakou and Luc Moreau PASOA/EU Provenance University of Southampton www.pasoa.org www.gridprovenance.org IPAW May 2006, Chicago
  2. 2. Provenance in a SOA context <ul><li>Interactions through message exchange between services ( actors ) </li></ul><ul><li>Execution of a workflow: process </li></ul><ul><li>Provenance of a piece of data is the process that led to that piece of data . </li></ul><ul><li>P-assertion : specific piece of information documenting some step of a process </li></ul><ul><li>p-assertions are stored in a provenance store , to be queried by actors in the system </li></ul>
  3. 3. Access control on process documentation <ul><li>Useful provenance information obtained from aggregation of p-assertions </li></ul><ul><li>Granularity of access control: on groups of p-assertions </li></ul><ul><li>Problem: combination of certain p-assertions may provide unintentional access to provenance information </li></ul>
  4. 4. Access control on process documentation PA2 PA1 PA3 PA4 PA5 PA6 To answer provenance query X To answer provenance query Y To answer provenance query Z User A has access to answer provenance query X User A is given access to answer provenance query Y Unintentionally, User A is given access to answer provenance query Z
  5. 5. Access control on process documentation <ul><li>Expose access only at level of provenance queries </li></ul><ul><ul><li>Tools/services aggregate p-assertions and process them </li></ul></ul><ul><ul><li>Potential provenance queriers only access tools/services </li></ul></ul><ul><li>Use cryptographic protocols </li></ul><ul><ul><li>Use appropriate algorithms to encrypt p-assertions </li></ul></ul><ul><ul><li>Assign keys corresponding to different groups </li></ul></ul><ul><ul><li>Information obtainable only if user has access to p-assertions as well as keys to decrypt groups of p-assertions. </li></ul></ul>
  6. 7. Accountability for p-assertions <ul><li>P-assertion is a subjective view of actor </li></ul><ul><li>Need to establish accountability for the creation of an assertion ( non-repudiation ) </li></ul><ul><li>Ensure that p-assertions are not altered after being created ( integrity ) </li></ul><ul><li>Directly implemented by signing p-assertions </li></ul>
  7. 8. Trust framework for actors and provenance stores <ul><li>Distributed systems: cannot ensure that all possible actors creating p-assertions are doing so correctly </li></ul><ul><li>Establish trust model to reflect relationships: </li></ul><ul><ul><li>between actors creating p-assertions and actors using them </li></ul></ul><ul><ul><li>between actors and provenance stores </li></ul></ul><ul><ul><li>e.g. ratings system, e-Bay, mySpace </li></ul></ul>
  8. 9. Information sensitivity in p-assertions <ul><li>Relevant with regards to legal requirements, e.g. patient records </li></ul><ul><li>Information recorded in p-assertions may be obscured: </li></ul><ul><ul><li>One way anonymization </li></ul></ul><ul><ul><li>Encryption with a shared key </li></ul></ul>
  9. 10. Long term storage <ul><li>P-assertions may be archived </li></ul><ul><li>If signed and/or encrypted, appropriate certificate/key archival facilities is also required </li></ul><ul><li>May need to ensure algorithms remain updated </li></ul>
  10. 11. Relating access control for data and p-assertions <ul><li>P-assertions may describe or relate to data with existing access control restrictions (authorizations) </li></ul><ul><li>How do we relate authorizations for data and p-assertions that is derived from that data ? </li></ul><ul><ul><li>No relation </li></ul></ul><ul><ul><li>Allow actor creating p-assertion to specify its authorization </li></ul></ul><ul><ul><li>Allow automated generation of authorizations from existing authorizations </li></ul></ul>
  11. 12. Distributed provenance stores PS PS PS - Bandwidth - Access Control - Storage
  12. 13. Federated identity – approach 1 Provenance store – Security domain 1 Provenance store – Security domain 2 Actor Security token service Security token Security token
  13. 14. Federated identity – approach 2 Provenance store – Security domain 1 Provenance store – Security domain 2 Actor Security token service Security token Security token Security token
  14. 15. Conclusion <ul><li>Many security issues: most analogous to standard access control issues, some possibly new </li></ul><ul><li>Important to consider if provenance systems are to become industrial strength </li></ul><ul><li>EU Provenance project – security features in GT4, WS-Security for authentication, proxy certificates for delegating access control, CAS for role-based authorization and federated identity </li></ul>

×