1. Process-Based Access Control Steve Taylor and Mike Surridge IT Innovation Centre 11/04/05

2. Security Objectives • Regulate service behaviour • resist unacceptable usage • e.g. permitting users access to resources only if they have agreed to pay first! • Ensure only the right users can use services • resist unauthorised access • Ensure services can provide resources • resist denial of service

3. Process-Based Access Control (PBAC) • Enforces business processes • Authorisation system • authentication of user ID performed externally • Protects Web Services • Access is determined by an authorisation triple: • user ID (subject) • process context (resource) • Web Service operation (action)

4. PBAC Origins: Comb-e-Chem

5. Business Process Enforcement • Stateful sequences • “you must pay before you can use my resource” • Contextualised process identifiers • “which crystal sample are we talking about?” • Authorisation depends on: • process state • user requesting access • requested operation • Business logic encoded in Web Service operations • all operations consult authorisation store • operations may update authorisation store • state transitions, new access rights

6. trust trust open tender download upload run transfer Example: GRIA Core Services Client Organisation A Client Organisation B Account Account Resources Resources Job Service Data Service Job Service Data Service Service Provider Organisation X Service Provider Organisation Y

7. Contexts • A context references a particular resource at a service provider, e.g: • account number, order number, crystal sample ID, etc • Quoted in communications • “your ref” • Contexts are hierarchical • “parent – child” relationships • e.g. an “order” context may be a sub-context of an account context and thus will bill the account

8. Contexts Account 3 Resource Allocation 6 Job 24 Data 22 Data 19 Resource Allocation 7 Job 13 Data 11

9. Basic Architecture Authentication Authorisation

10. Example Operation

11. Example Delegation Operation

12. PBAC Features Summary • Highly flexible means of process enforcement • based on dynamic authorisation • Contextualised • hierarchical context relationships • Fine grained control of access • Supports server-side delegation

13. PBAC Version 2 • Developed in Semantic Firewall project • Explicit dynamic policy representation • simpler API • helps protect against service errors • More flexible context model • not limited to hierarchical “factory” patterns • Standardised implementation • XACML for policy representation and authorisation API • X.509 / SAML for subject tokens

14. GRIA/GEMSS Business Model

15. Interaction Protocols • Process role • specifies a resource user type • e.g. “Service Provider” or “Account Manager” • real users may be assigned process roles • Interaction Protocols • link between resource & process role • describe resource states, permitted actions and associated state transitions for a process role

16. Account Service Deployment IP

17. Account Management IP

18. Account Biller IP

19. Generalised Process Context Account 4 Billing Ref 4.43 Resource Allocation 6 Job 24 Data 22 Data 19 Data 11 Account 3 Billing Ref 3.12 Resource Allocation 7 Software Licence 31 Job 13

20. Conclusion • PBAC addresses: • authorisation via business process enforcement • PBAC 1 is complete: • evaluated in GRIA • has proved flexible & powerful • PBAC 2 now being designed by SFW project • PBAC 2 will provide: • explicit process-based policies • more flexible context model • standards-based implementation

21. Process-Based Access Control Steve Taylor and Mike Surridge IT Innovation Centre 11/04/05