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)
PBAC Origins: Comb-e-Chem
Authenticated
users
(New)
can send sample
Revoke users
(Data collection)
can request status
can monitor status
Unpack, enter data,
send confirmation
(Pending schedule)
can request status
Experiment finished + postprocess completed
(HKL available)
Schedule for tomorrow,
notify user
(Raw data available)
can request status
can download HKL
(Scheduled)
can request status
can monitor status
Structure determined
(structure data available)
Sample prepared,
notify user
(Structure available)
can request status
can download HKL
can download structure
(Ready to start)
can request status
can monitor status
(Prev. expt finishes)
Start new expt (launch control GUI),
notify user
Setup completed
New crystal ready
Publish data?
Archive data?
Timeout?
Discard unit cell
(Setup running)
can request status
can monitor status
can connect to conference
can download images
(Prep new crystal)
can request status
can conference?
can monitor?
Discard crystal
Abort
(Finished)
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
Example: GRIA Core Services
Client Organisation B
Client Organisation A
trust
trust
open
tender
upload
Account
Resources
Job
Service
Account
run
Data
Service
Service Provider Organisation X
download
Resources
transfer
Job
Service
Data
Service
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
Resource Allocation 7
Job 13
Data 11
Data 19
Basic Architecture
Authentication
Authorisation
Example Operation
Client
Service Provider
Account Web Service
Account
Manager
user
getStatement
(Account Manager ID, acct35)
getStatement
operation
if DENY
SOAP Fault (“Not authorised”)
if PERMIT,
generate
statement
statement
checkAuthorised
(Account Manager ID, acct35,
“accountService.getStatement”)
PERMIT / DENY
PBAC
Example Delegation Operation
Client
Service Provider
Account Web Service
Account
Manager
user
enableAccess
(Account Manager ID,
acct35, delegateID)
enableAccess
operation
if DENY
SOAP Fault (“Not authorised”)
if PERMIT
checkAuthorised
(Account Manager ID, acct35,
“accountService.enableAccess”)
PERMIT / DENY
openAuthorisation
(delegateID, acct35,
“accountService.useAccount”)
OK
OK
PBAC
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
GRIA/GEMSS Business Model
Credit
Bad
Start
Request
Account
Account
Requested
Credit
Good
No QoS
Confirmed
Request
QoS
Account
Opened
QoS
Settlement
Negotiating
QoS
Application(s)
Finished
QoS
Confirmed
Resource
Usage
Ends
Resources
Confirmed
Resource
Usage
Starts
Application(s)
Proceeding
Account
Closed
End
QoS
Settlement
Resources
Expired
QoS Terms
Breached
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
Account Service Deployment IP
IP: A0
Role: Service provider
Context: AcctService
Start
End
Open()
All Accounts
Settled
Deploy
Service
Waiting for
Customers
Withdraw
Service
Closing
Accounts
Account Management IP
IP: A2
Role: Account manager
Context: AcctService.Acct
Start
[A0:Open]
Checking
Credit
Credit
Bad
End
Get
Statement()
Get
Statement()
Account
Purged
Credit
Good
UnTrust
User(DN)
Settled
Trust
User(DN)
Account
Settled
[A0:Withdraw]
Open
UnTrust
Biller(DN)
Close():
request
Get
Statement()
Trust
Biller(DN)
Close():
response
UnTrust
Biller(DN)
Closing
Get
Statement()
Account Biller IP
Generalised Process Context
Account 4
Billing Ref 4.43
Resource Allocation 6
Job 24
Resource Allocation 7
Data 22
Data 19
Data 11
Job 13
Account 3
Billing Ref 3.12
Software
Licence 31
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