210 likes | 393 Views
Process-Based Access Control. Steve Taylor and Mike Surridge IT Innovation Centre 11/04/05. Security Objectives. Regulate service behaviour resist unacceptable usage e.g. permitting users access to resources only if they have agreed to pay first!
E N D
Process-Based Access Control Steve Taylor and Mike Surridge IT Innovation Centre 11/04/05
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
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)
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
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
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
Contexts Account 3 Resource Allocation 6 Job 24 Data 22 Data 19 Resource Allocation 7 Job 13 Data 11
Basic Architecture Authentication Authorisation
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
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
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
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
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
Process-Based Access Control Steve Taylor and Mike Surridge IT Innovation Centre 11/04/05