invoke - Faculty of Computer Science

advertisement
AN INTEGRATED IDENTITY
AND ACCESS MANAGEMENT
SOLUTION FOR BUSINESS
PROCESSES
Federica Paci
Department of Engineering and Information Science
University of Trento
June 22 2009
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
WS-BPEL processes
WS-BPEL processes
WS-BPEL
Process
<process>
<sequence>
<receive
… />
<invoke
… />
</sequence>
</process>
Web service1
Published To
Issues
Web service2
BPEL Engine
Web service3
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?
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
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
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)
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 Based Role Provisioning
 RBAC-WS-BPEL prototype
RBAC-WS-BPEL
overview
Overview
Role
Provisioning
Policies
Permissions
Action
Human
Activity
Resiliency
Constraints
Roles
Authorization
Constraints
Users
Identity
Record
WS-BPEL
Business Process
Human Activities
Identity
Tuples
Automatic Activities
Identity Attributes
Handling human interactions
Handling human interactions
<receive>
submit
parallel
Review
Service
<invoke>
review1
<invoke>
review2
<invoke>
determine_status
Submission
Service
Rejected
<reply>
submit
Human activity
Approval
Service
Funded
<invoke>
approve1
<invoke>
approve2
<invoke>
assign funds
Funds
Assignment
Service
Role Provisioning Policies
Rolei  Cond1,……, Condn
Role Identifier
AttrName op l
Post Doctorate  PhdCertificate, Affiliation
= Purdue,
AttrName
SSN
Attribute
Condition
Example of Role Hierarchy
John
Dean
Chris, Irini
Tammy
Mary, Jane
Business Office
Manager
Business Office
Clerk
Robynne, Leslie
Full
Professor
Associate
Professor
Assistant
Professor
Post
Doctorate
Ellen, Doug
Anna, Dan
Phd Student
Ashish, Melanie, Kara
Authorizations Definition
<Role, (Activity, Action)>
Role Identifier
Type
of
Action
Activity Indentifier
Permission
Example of Authorizations
<receive>
submit
 Assistant professor,
<invoke>
review
,
execute

1
Review
 Associate professor,
<invoke> review , execute  parallel
Service
Human activity
1
<invoke>
review1
<invoke>
review2
<invoke>
Approval
determine_status
Service
 Full professor, <invoke> approve
, execute 
Submission
Service
Business Office Clerk, <invoke > approve2,1 execute 
Rejected
Dean, <invoke > Funded
approve2, execute 
<reply>
submit
<invoke>
approve1
<invoke>
approve2
<invoke>
assign funds
Funds
Assignment
Service
Authorization constraints
< D, (Activityi, Activityj ),  >
Set of Roles/Users
who have performed
Alternative
Activity
i
Consequent
Activity
specification in
XML- based language called
BPCL
Antecedent
Activity
Binary Relation
On the set of
Roles/Users
Example of Authorization Constraints
<receive>
submit
parallel
Review
Service
Human activity
<invoke>
<invoke>
U, (<invoke> reviewSOD
1, <invoke> review 2),  
review1
review2
<invoke>
determine_status
Submission
Service
Rejected
<reply>
submit
Approval
Service
Funded
<invoke>
approve1
<invoke>
2
U, (<invoke> approve2, <invoke> assign funds),approve
=
<invoke>
assign funds
Funds
Assignment
Service
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
Example of Resiliency Constraints
<receive>
submit
parallel
<invoke> review
Review
1, 3
Service
<invoke>
review1
Rejected
<reply>
submit
<invoke> approve
2, 2
<invoke> review2, 3
<invoke>
review2
<invoke>
determine_status
Submission
Service
Human activity
Approval
<invoke> Service
approve1, 2
Funded
<invoke>
approve1
<invoke>
approve2
<invoke>
assign funds
Funds
Assignment
Service
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
User
enrollment
User Enrollment
Registration of Pedersen commitment of
their identity attributes to be used later
as proofs of identity
Identity
Manager
Create
Identity Record
Identity Tuple
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
m and r
are known
Pedersen Commitment
only by
of Identity Attribute
the user
M=gmhr
Confidence
about the claim that
the user
presenting the Identity
Attribute is its true owner
Business process resiliency
<receive>
submitChris, Irini,
Anna,Dan
parallel
Review
<invoke>Service
review1, 3
<invoke>
review1
Chris, Irini,
Anna,Dan
Human activity
<invoke> review2, 3
<invoke>
review2
<invoke>
determine_status
Mary,
MaxRes
is equal
to 3
Rejected
Funded
Submission
Service
<invoke> approve1, 2
Jane,John
<reply>
submit
Robynne,
<invoke>
approve2, 2
Leslie,Tammy,
John
Approval
Service
<invoke>
approve1
<invoke>
approve2
<invoke>
assign funds
Funds
Assignment
Service
Configurations
Irini
<receive>
submit
parallel
Review
Service
Mary
Anna
<invoke>
review1
<invoke>
review2
<invoke>
determine_status
Submission
Service
Human activity
Rejected
Approval
Service
Funded
Jane
<invoke>
approve1
<reply>
submit
John
<invoke>
approve2
<invoke>
John
assign funds
Funds
Assignment
Service
How to evaluate resiliency
Compute
all configurations
Evaluate Resiliency
Constraints
NP Complete
Yes
No
Satisfied?
Business Process IS
Resilient
EXECUTE
Business Process IS
NOT Resilient
Our Approach
Our approach
Compute
a subset Conf
of
configurations
Yes
Business Process IS
Resilient
EXECUTE
| Conf |
==
MaxRes?
No
Business Process IS
NOT Resilient
How to compute the set Conf
Group business process’s activities
based on authorization constraints
Compute a sub-configuration for
each activity group
Merge sub-configurations
How to compute sub-configurations

BoD
John
Allison
John
Peter
Activity
1
Users
authorized
to perform
Activity1
Heather
John
Users
authorized
to perform
Activity2
=
BoD
John
Heather
ActivityAllison
3
Iva 2
Activity
Activity5
Set of users
that can be selected to
perform Activity1,
Activity2 and Activity3

Users
authorized
to perform
Activity3
Activity4
How to compute sub-configurations
Second
sub-configuration
SoD
Activity1
Activity2
Activity3
First
sub-configuration
Activity5
Activity4
Third
sub-configuration
User assignment
fails
SoDRe-assignment
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
Role Provisioning
User
Requests
Activityi
Enforcement Point
Request Activityi
Select Roles
Authorized to
perform Activityi
{Attri | Condi  Pol , Condi = NameA op l , Attri = NameA}
For each policy Pol
Select Policies
Ri  Cond1, …., Cond
n | Cond  Pol , Cond = Name , Attr = Name }
{Attr
i
i
i
A
i
A
Computes sets
Conditions
and
For each policy Poli verified if it is
NoConditions
satisfied by carrying out AgZKPK/
OCBE protocol
For Attr  NoConditions
Carry out AgZKPK
Yes
No
Verified?
For each Attr  Conditions
Carry out OCBE protocol
Assign User to Role
Role Provisioning Certificate
Denied
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 DiffieHellman 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 
AgZKPK protocol steps
User
Computes
M = M1 M2
 = m1  m2
Enforcement
Point
Proof of possession
M1 = g m1  h r1
M2 = g m2  h r2Of
Chooses
challenge c in
[1,..,p]
m1 and m2
M, , d
Verifies
guhv = = dMc
Chooses
y, s in [1,.., p]
c
Computes
d = g y h s
Yes
u, v
No
Verified?
Verifies 
Computes
u = y+ c *(m1+ m2)
v = s+ c * (r1 + r2)
Denied
No
Yes
Verified?
Grant
Denied
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
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 scheme Param = (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
GE-OCBE protocol steps
GE-OCBE protocol steps
Prover
Select
M = g m h r

Prove
m  m0
Enforcement Point
M, 
Chooses
Random
Number N
c0 , ……, cl-1
Computes
Envelope and
Encrypts N
Computes l
commitments
Yes
Opens Envelope
Verifies 
N’
Decrypts
C and obtains N’
N’== N
Denied
No
Yes
Verified?
Grant
No
Denied
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
Enforcement steps
Enforcement steps
1º
Set user u as the user authorized
to perform Ai
2º
For each activity Aj compute the set
of roles and of users authorized to
perform the activity
3º
For each activity Aj compute the set
of roles and of users which satisfy
authorization constraints
4º
For each activity Aj compute the
intersection of the sets computed at
step 2 and step 3
5º
If for some activity Aj the
intersection set is empty, the
execution of Ai is not granted to u
RBAC-WS-BPEL framework
BPEL
Process
BPEL Engine
Identity Records
WSDL Interface
planning
Identity Manager
Service
WSDL Interface
WSDL Interface
initiateActivity
RBAC-WS-BPEL
Enforcement
Service
listActivity
claimActivity
OnActivityResult
Constraints
Store
XACML
Policy
Store
History
Store
Planning
Store
Client
Module
Proof-of-Identity
Cert
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
Configuration tool interface
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
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
Tests on resiliency
Algorithm 1
100000.00
NoN Optimized Algorithm
Time (ms)
10000.00
1000.00
100.00
10.00
1.00
0
1
2
3
4
Number of BoD Constraints
5
Tests on resiliency
NoN Optimized Algorithm
1000000.00
Algorithm 1
Time (ms)
100000.00
10000.00
1000.00
100.00
10.00
1.00
3
4
5
6
7
8
Number of SoD Constraints
9
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]
AgZKPK
Create AgZKP
Verification
0.1
Time(secs)
0.09
0.08
0.07
0.06
0.05
0.04
0.03
0.02
0.01
0
1
4
7 10 13 16 19 22 25 28 31 34 37 40 43 46 49
Number of simple conditions
Tests on OCBE protocols
Commitments Creation
TotalUserTime
Opening Envelope
CreateEnvelope
2000
1800
Time (ms)
1600
1400
1200
1000
800
600
400
200
0
5
6
7
8
9
10 11 12 13 14 15 16 17 18 19 20
Parameter l
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
Test on Enforcement
Enforcement Execution Time
160
140
138.86
Time (sec)
120
100
80
60
40
29
20
0.25
8.25
0
0
500
1000
1500
Number of Users
2000
2500
Conclusions and Future Works
Innovative authorization framework for WSBPEL processes
 Evaluation of the resiliency of a business
process
Specification
and
enforcement
of
authorizations and authorization constraints
Extend
RBAC-WS-BPEL
to
crossorganizational business processes
 Resiliency of a business process to change
References
References
1. Federica Paci, Rodolfo Ferrini, Elisa Bertino. Identity Attribute-based Role Provisioning
for Human WS-BPEL processes. In Proceedings of IEEE International Conference on
Web Services (ICWS), Los Angeles, USA, July 2009.
2. Elisa Bertino, Rodolfo Ferrini, Andrea Musci, Federica Paci, Kevin J Steuer. A
Federated Digital Identity Management Approach for Business Processes. Invited
paper. In Proceedings of the 4th International Conference on Collaborative Computing:
Networking, Applications and Worksharing (CollaborateCom), Orlando, Florida,
November 2008.
3. Federica Paci, Rodolfo Ferrini, Yuqing Sun, Elisa Bertino. Authorization and User
Failure Resiliency for WS-BPEL business processes. In Proceedings of International
Conference on Service Oriented Computing (ICSOC), Sidney, Australia, December
2008.
4. Federica Paci, Elisa Bertino, Jason Crampton. An Access Control Framework for WSBPEL. International Journal of Web Services Research, 5(3): 20--43, 2008.
5. Jacques Thomas, Federica Paci, Elisa Bertino, Patrick Eugster. User Tasks and
Access Control over Web Services. In Proceedings of IEEE International Conference
on Web Services (ICWS), Salt Lake City, USA, July 2007.
6. Elisa Bertino, Jason Crampton, Federica Paci. Access Control and Authorization
Constraints for WS-BPEL. In Proceedings of IEEE International Conference on Web
Services (ICWS), Chicago, USA, September 2006.
Thank you!
Any questions?
Contact information:
paci@disi.unitn.it
Back up
Form for Review Activity
<form name="input"
action="UserSide"
method="post">
Reviewer:
<input type="text"
name="reviewer"/>
<br/>
Comment:
<input type="text"
name="content"/>
<br/>
<input type="hidden"
name="instanceid"
value="#?instid?#"/>
<input type="hidden"
name="action"
value="execute"/>
<input type="submit"
value="Submit"/>
</form>
Download