An INTEGRATED IDENTITY AND ACCESS MANAGEMENT SOLUTION for business PRocesses

1. Federica Paci Department of Engineering and Information Science University of Trento June 22 2009 An INTEGRATED IDENTITY AND ACCESS MANAGEMENT SOLUTION for business PRocesses

2. Outline • Motivation • IAM for WS-BPEL processes • How to handle human interactions • How to evaluate process resiliency to absence of users • How to verify users digital identities • How to enforce authorizations and authorization constraints • Prototype and Experimental results • Conclusions and Future Works

3. WS-BPEL processes WS-BPEL processes WS-BPEL Process Web service1 <process> <sequence> <receive … /> <invoke … /> </sequence> </process> Published To Issues Web service2 BPEL Engine Web service3

4. Issues Issues • How to involve humans in a business process? • How to verify business process users’ identity? • How to prevent potential misuse of users’ confidential information? • Does a user have the permission to perform a business process’s activity? • Can the execution of a business process complete?

5. Existing solutions Existing solutions • Humans inclusion in WS-BPEL processes • BPEL4People 2007 • Authorization • Koshutanski et al. 2003 • Xianpeng et al. 2006 • Resiliency to user absence • Wang et al. 2007

6. Why existing solutions are unsatisfactory Why existing solutions are unsatisfactory • Each solution tackles one specific problem. No comprehensive and feasible solution has been proposed • Important aspects that have not been considered: • Users digital identities management • Resiliency of a WS-BPEL process to users absence

7. The solution • Integrated approach to digital identity and access management: • Include human user interactions in WS-BPEL processes • Determine if a business process can complete even if some users become unavailable (resiliency) • Check if a user has the permission to execute a business process’s activity (authorization) • Flexible way to verify the identity of users who claim the execution of business process’s activity (identity attribute-based role provisioning)

8. The focus of this talk The focus of this talk • RBAC-WS-BPEL: Innovative IAM framework for WS-BPEL processes • New type of WS-BPEL activity to handle human interactions- <Human Activity> • Verification of WS-BPEL process resiliency to user absence • Specification and enforcement of authorizations and authorization constraints • Identity Attribute BasedRole Provisioning • RBAC-WS-BPEL prototype

9. RBAC-WS-BPEL overview Overview Role Provisioning Policies Permissions Roles Human Activity Users Action Identity Record WS-BPEL Business Process Authorization Constraints Human Activities Identity Tuples Automatic Activities Resiliency Constraints Identity Attributes

10. Handling human interactions <invoke> approve2 <invoke> assign funds <invoke> approve1 <invoke> review2 <invoke> review1 Handling human interactions <receive> submit Review Service Human activity parallel Approval Service <invoke> determine_status Submission Service Rejected Funded Funds Assignment Service <reply> submit

11. Role Provisioning Policies Rolei Cond1,……, Condn Role Identifier AttrName op l AttrName Post Doctorate  PhdCertificate, Affiliation = Purdue, SSN Attribute Condition

12. John Dean Chris, Irini Mary, Jane Tammy Associate Professor Full Professor Business Office Manager Assistant Professor Anna, Dan Post Doctorate Business Office Clerk Phd Student Ashish, Melanie, Kara Ellen, Doug Robynne, Leslie Example of Role Hierarchy

13. Authorizations Definition <Role, (Activity, Action)> Role Identifier Type of Action Activity Indentifier Permission

14. <invoke> approve2 <invoke> approve1 <invoke> review1 <invoke> assign funds <invoke> review2 Example of Authorizations <receive> submit Review Service Human activity  Full professor, <invoke> approve1, execute  parallel  Assistant professor, <invoke> review1, execute   Associate professor, <invoke> review1, execute  Approval Service <invoke> determine_status Submission Service Rejected Funded Funds Assignment Service <reply> submit Business Office Clerk, <invoke > approve2, execute  Dean, <invoke > approve2, execute 

15. Authorization constraints < D, (Activityi, Activityj),  > Alternative specification in XML- based language called BPCL Set of Roles/Users who have performed Activityi Consequent Activity Antecedent Activity Binary Relation On the set of Roles/Users

16. <invoke> approve2 <invoke> review2 <invoke> assign funds <invoke> review1 <invoke> approve1 Example of Authorization Constraints <receive> submit Review Service Human activity parallel SOD U, (<invoke> review1, <invoke> review2),  Approval Service BOD <invoke> determine_status Submission Service Rejected Funded Funds Assignment Service <reply> submit U, (<invoke> approve2, <invoke> assign funds), =

17. Resiliency constraints <Activity, n> Activity Identifier A user has the authorization to execute an activity Ai if he/she is assigned to a role which has the permission to perform Ai Minimum Number of Users who must have the authorization to perform Activityi

18. <invoke> approve2 <invoke> assign funds <invoke> review1 <invoke> approve1 <invoke> review2 Example of Resiliency Constraints <receive> submit Review Service Human activity parallel <invoke> review1, 3 <invoke> review2, 3 Approval Service <invoke> determine_status Submission Service <invoke> approve1, 2 Rejected Funded Funds Assignment Service <reply> submit <invoke> approve2, 2

19. IAM lifecycle Business process lifecycle Process Resiliency Evaluation Process Instance Execution Activity Request User Identity Verification Process Deployment Access control Enforcement Users Enrollment Process Instance Termination Activity Execution

20. User enrollment User Enrollment Registration of Pedersen commitment of their identity attributes to be used later as proofs of identity Identity Manager Enrollment Create Identity Record Identity Tuple

21. Identity Record (IdR) <tag, M, , validity-assurance, ownership-assurance> Confidence about the validity of the Identity Attribute Identity Attribute Identifier Signature of IdM on M Confidence about the claim that the user presenting the Identity Attribute is its true owner m and r are known only by the user Pedersen Commitment of Identity Attribute M = g m h r

22. <invoke> approve2 <invoke> assign funds <invoke> approve1 <invoke> review1 <invoke> review2 Business process resiliency <receive> submit Review Service Human activity Chris, Irini,Anna,Dan parallel <invoke> review1, 3 <invoke> review2, 3 Chris, Irini,Anna,Dan Approval Service <invoke> determine_status Submission Service Mary, Jane,John Rejected Funded <invoke> approve1, 2 Funds Assignment Service <reply> submit Robynne, Leslie,Tammy, John <invoke> approve2, 2 MaxRes is equal to 3

23. <invoke> approve2 <invoke> assign funds <invoke> approve1 <invoke> review2 <invoke> review1 Configurations <receive> submit Review Service Irini Human activity parallel Anna Approval Service Mary <invoke> determine_status Submission Service Rejected Funded Jane Funds Assignment Service <reply> submit John John

24. How to evaluate resiliency Compute all configurations Evaluate Resiliency Constraints NP Complete Yes No Satisfied? Business Process IS Resilient Business Process IS NOT Resilient EXECUTE

25. Our Approach Our approach Compute a subset Conf of configurations | Conf | = = MaxRes? Yes No Business Process IS Resilient Business Process IS NOT Resilient EXECUTE

26. How to compute the set Conf

27. Activity5 Activity4 Activity3 Activity2 Activity1 How to compute sub-configurations BoD   Users authorized to perform Activity3 Users authorized to perform Activity1 Users authorized to perform Activity2 = BoD John Heather John Allison John Heather John Iva Peter Allison Set of users that can be selected to perform Activity1, Activity2 and Activity3

28. Activity1 Activity2 Activity3 Activity4 Activity5 How to compute sub-configurations SoD SoD Second sub-configuration First sub-configuration Re-assignment User assignment fails Third sub-configuration

29. Enforcement Enforcement • The authorization to perform an activity Ai is granted to a user u if: • u is assigned to a role Rk which has the permission to execute Ai • No authorization constraint where Ai is the consequent activity is violated

30. Role Provisioning User Enforcement Point Request Activityi Select Roles Authorized to perform Activityi Requests Activityi {Attri| Condi  Pol , Condi = NameA op l , Attri= NameA} For each policy Pol Ri Cond1, …., Condn Computes sets Conditions and NoConditions {Attri| Condi  Pol , Condi = NameA, Attri= NameA} Select Policies Pol1, ….., Polk For each policy Poliverified if it is satisfied by carrying out AgZKPK/ OCBE protocol For AttrNoConditions Carry out AgZKPK Yes No Verified? Assign User to Role Denied For each Attr Conditions Carry out OCBE protocol Role Provisioning Certificate

31. Aggregate ZKPK protocol Aggregate ZKPK protocol • It allows to prove the possession of multiple identity attributes without revealing them • Pedersen commitment scheme Param = (G,p, g,h) • p is a prime number • G is finite cyclic group of order p such that the Diffie-Hellman problem is hard in G • g is a generator of G • h is a generator of G such that it is hard to find a number  such that h = g 

32. AgZKPK protocol steps Proof of possession Of m1 and m2 Enforcement Point User M1 = g m1  h r1 M2 = g m2hr2 Chooses challenge c in [1,..,p] Computes M = M1 M2  = m1  m2 M, , d Verifies guhv = = dMc Chooses y, s in [1,.., p] c Yes No u, v Verified? Computes d = g y h s Verifies  Denied No Computes u = y+ c *(m1+ m2) v = s+ c * (r1 + r2) Yes Verified? Grant Denied

33. OCBE protocols OCBE protocols • A user can open an encrypted message sent by a service provider if and only if the committed value of a specified identity attribute satisfies a predicate in the policy • The service provider does not learn anything about the user’s committed value • The service provider does not know if user ‘s identity attribute value satisfies its policy

34. GE-OCBE protocol GE-OCBE protocol • It allows to verify that a committed value satisfies a condition with a predicate  • Three main cryptographic primitives: • Pedersen commitment schemeParam = (G,p,g, h) • Additional parameter l such that 2 l < p/2 • symmetric-key encryption algorithm  • cryptographic hash function H(.) : {0, 1}∗ → {0, 1}k

35. GE-OCBE protocol steps GE-OCBE protocol steps Prove m  m0 Prover Enforcement Point Chooses Random Number N Select M = g m  h r  M,  c0 , ……,cl-1 Computes Envelope and Encrypts N Computes l commitments Env, k[N] Yes No N’== N OpensEnvelope Verifies  N’ Denied Decrypts C and obtains N’ No Yes Verified? Grant Denied

36. Role provisioning certificate Released to a user to avoid to perform multiple times the proof of possession of the same set of identity attributes Issuer Owner Attributes Roles Issuance Date Signature of the Verifier

37. Enforcement steps Enforcement steps 1º 2º 3º 4º 5º

38. RBAC-WS-BPEL framework BPEL Engine Identity Records BPEL Process WSDL Interface planning WSDL Interface RBAC-WS-BPEL Enforcement Service listActivity Identity Manager Service WSDL Interface claimActivity initiateActivity OnActivityResult XACML Policy Store Constraints Store History Store Planning Store Client Module Proof-of-Identity Cert

39. RBAC-WS-BPEL prototype RBAC-WS-BPEL prototype • Enforcement Web service – Java Web service (WSDL interface for users under development) • Identity Manager- Java Servlet • Application Service Apache Tomcat 6 • Client application – Java • ODE BPEL engine 1.5 • Oracle database 10g

40. Configuration tool interface

41. Experimental evaluation Experimental evaluation • Complexity of evaluating process resiliency: • Varying the number of SoD constraints • Varying the number of BoD constraints • Complexity of verifying user identity: • AgZKPK varying the number of identity attributes • OCBE varying the parameter l • Complexity of enforcement process • Enforcement varying the number of users

42. Test on resiliency • Two versions of the algorithm to compute configurations of users • Algorithm Not Optimized • Algorithm Optimized • Business process: 21 activities • No. SoD constraints : 6 • No. BoD Constraints: 6 • Role Hierarchy : 7 roles • No. potential users : 50

43. Tests on resiliency

44. Tests on resiliency

45. Test on role provisioning • Business process: 21 activities • No. SoD constraints : 6 • No. BoD Constraints: 6 • Role Hierarchy : 7 roles • No. potential users : 50 • No. of simple conditions: [1, 50] • Value of parameter l: [5, 20]

46. AgZKPK

47. Tests on OCBE protocols

48. Test on Enforcement • Business process : 30 • Role Hierarchy: 20 • Number of potential users: [500, 2500] • Number of users per role : Num users/Num Roles • Number of SoD constraints : 435

49. Test on Enforcement

50. Conclusions and Future Works • Innovative authorization framework for WS-BPEL processes • Evaluation of the resiliency of a business process • Specification and enforcement of authorizations and authorization constraints • Extend RBAC-WS-BPEL to cross-organizational business processes • Resiliency of a business process to change