Controlling VO Access to
your Resources
David Chadwick
The Computing Laboratory
University of Kent, UK
d.w.chadwick@kent.ac.uk
http://sec.cs.kent,ac.uk/permis
Contents
• Conceptual Models
• Authorization and Access Control Model
• Authorization Architectural Model
• Trust Model
• Implementation Examples
• VOMS, XACML, Microsoft
• TrustCoM, PERMIS
• A quick look into the future
• Policies in controlled natural language
• Automated refinement and distribution of policies
‹#›
Access Control Model
• Hierarchical Role based Access Control (RBAC)
•
•
•
•
Permissions are allocated to roles
Superior roles inherit privileges of subordinate roles
Users are assigned role memberships
Role members acquire roles’ permissions
• Benefits
• Security
Remove a user’s roles and
all privileges are gone
• Manageability
Users change more
frequently than roles
UserA
RoleA
P2
UserB
RoleB
• Scalability
No of roles usually
much less than no
of users
P1
P3
Users
Role
Priviliges
‹#›
Authorization and Credential Model
• Subjects can be assigned roles (authorized) in one (or
more) domains and access targets in one or more
other domains
• Roles are distributed as digitally signed credentials
• Subjects ask to perform an action on a remote target
• Local site decides if subject is authorised to make an
outgoing call or not
• Local site may ensure subject’s request carries
sufficient credentials
• Remote target may pull extra user credentials in order
to decides if user has sufficient attributes to be granted
access or not
‹#›
Credential Model
• Must contain details of: holder, issuer,
attributes/roles, validity time and
signature of issuer
• Optionally may contain issuing policy
e.g. which targets it is designed for,
whether it can be delegated or not,
whether it will be revoked or not,
where to find certificates, CRLs etc.
• Format of credential is of secondary
importance
• Can be binary format e.g. X.509
attribute certificate
• Can be XML format e.g. SAML
attribute assertion
• Can be proprietary format e.g. as in
various EC projects such as GRASP
Issuer : Kent University
Holder : David Chadwick
Attribute/Role: Student
Valid from : 11 Jan 2005
Valid until : 30 June 2007
Optional Issuing Policy info
Signature of Issuer :
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
‹#›
Authentic vs Valid Credentials
• Authentic credentials are ones that have not been
tampered with and are received exactly as issued by
the AA
• Valid credentials are ones that are trusted for use by
the target resource
• Example: Monopoly money is authentic if obtained
from the Monopoly game pack. It was issued by the
makers of the game of Monopoly. Monopoly money is
valid for buying houses on Mayfair in the game of
Monopoly, but it is not valid for buying groceries in
Tesco’s or Sainsbury’s
‹#›
Architectural
Model
AR=Attribute Repository
CIS=Credential Issuing Service
CVS = Credential Validation Service
PDP = Policy Decision Point
PEP= Policy Enforcement Point
SOA = Source of Authority
Attribute
Authority
0
AR
CIS
Subject
SOA
0
0
Target SOA
PDP
CVS
PDP
5
3
4
1
PEP
Subject
2
Environment
5
6
6
8
7
9
11
12
PEP
Target
10
Environment
‹#›
Conceptual Model Architecture
•
PEP (Policy Enforcement Point)
•
•
•
PDP (Policy Decision Point)
•
•
•
Application dependent
Controls outgoing and incoming requests
Application Independent
Makes Access Control Decisions according to Access Control Policy
CIS (Credential Issuing Service)
• Issues Credentials to users
according to Issuing Policy
•
CVS (Credential Validation Service)
• Verifies received Credentials for
Authenticity and Trustworthiness
according to Validation Policy
•
SOA (Source of Authority)
•
•
•
Administrator. Writes policies
Manages Trust relationships
AA (Attribute Authority) IdP
•
Writes Issuing Policies for CIS
‹#›
Trust Model
• Root of Trust
• Resource owner (SOA) is always root of trust for who can
access his resources
• Policy
• Resource owner sets the policy for
• Which credentials are valid
• Which attributes/roles are needed for which types of access to
his resources
• Delegation of Authority
• Resource owner says which AAs he trusts to issue credentials
• And whether they are allowed to delegate further or not
• Over-ride issuing policies
• Resource owner can decide to ignore issuing policies in
credentials and trust them even if the AA did not intend this
‹#›
Dealing with Multiple Access Control Policies
• Resource may be controlled by multiple policies from:
Resource Owner, VO Manager, Regulatory Authority etc.
• This can be modelled as either
• The PEP calls a single PDP that reads in multiple policies
and a meta “combining policy” and returns a decision e.g.
as in the XACML model
• The PEP calls multiple PDPs in sequence, which each
read in a single policy, and the PEP has its own meta
“combining policy” e.g. as in the GT4 implementation
• Or a combination of the two
• Examples of combining policies: Deny overrides Grant,
Grant overrides Deny, First decision takes precedence etc.
‹#›
Example Implementations
•
•
•
•
•
VOMS
XACML
Microsoft STS
TrustCoM
PERMIS
‹#›
VOMS
• VOMS is a Credential Issuing Service
• Stores attributes in an LDAP directory
• Issues short lived X.509 Attribute Certificates on
demand
• Provides tools to VO manager to manage the user’s
attributes
‹#›
XACML
• OASIS specification for an access control policy
language and a PDP request-response dialogue
• Given the attributes of a user, a resource, an action
and the environment an XACML PDP returns: granted,
denied, “not me guv” (not applicable) and error
(indeterminate)
• SUN have built an open source XACML PDP which
can be used by either the subject’s PEP or the target’s
PEP to make access control decisions
‹#›
Microsoft’s STS (Security Token Service)
• Experimental software that can act as a Credential
Issuing Service and a Credential Validation Service
• First version used symmetric encryption and shared
secrets between the CIS and CVS. Current version
uses asymetric encryption
• Is being tested within the TrustCoM project
‹#›
TrustCoM Project
• Has integrated Microsoft’s STS (CIS-CVS) with Sun’s
XACML PDP (enhanced by SICS) to produce a
complete authorisation system
• Will test with PERMIS next
• Has specified protocols for the interactions between
the PEP and STS and PEP and PDP
• The author has taken (modified) versions of these to
the OGF for standardisation
‹#›
PERMIS
• Provides a complete authorisation system with
Credential Issuing, Credential Validation and a PDP
plus user interfaces for managing each of them
‹#›
Policy Management Tools
• Policy Editor – allows an SOA to create, edit and
update his PERMIS policies
• Policy Wizard – guides SOA step by step in creating a
new policy
• Both tools allow created/edited policy to be displayed
in natural language and/or XML
‹#›
Policy Editor
‹#›
Policy Wizard
‹#›
Natural Language Policy Output
‹#›
PERMIS : Credential Management
• Responsible for Issuing and Revoking subject credentials
• Attribute Certificate Manager
• Supports X.509 ACs creation and editing
• GUI interface
• LDAP and filestore storage capability
• Delegation Issuing Service
• Standard Web service
• Issues ACs on demand and stores them in LDAP entry of new
holder
• Policy controlled so that issuer cannot exceed their authority
• Bulk Loader
• Will bulk load ACs into a filtered set of entries in LDAP
‹#›
Attribute Certificate Manager
‹#›
Delegation Issuing Service
Authenticate
DIS Client
Map
identities
Authn
name
PDP
Authzn
name
PERMIS Decision
Engine
Request
DIS
PEP
Web service
interface
Authorisation
CVS
Issue AC
Delegation
Policy
Sign
AC
Publish AC
LDAP
server
Retrieve AC
‹#›
Apache front end to DIS
‹#›
PERMIS : Modular Credential Validation Service
Credential Validation Service
1. Request
attributes
6. Return
attributes
Credential
Validation Policy
Enforcer
5. Return authentic
transcoded credentials
Policy Admin
Point
0. Initialize with policy
2. Request credentials
Credential Retriever
3. Return credentials
Credential
Authenticator
4. Authenticate
credentials
Credential
Decoder
Credential
Provider
Credential provider
can either be
external (pull
mode) or passed
by caller (push
‹#›
mode)
Application Integration: OMII
• OMII
• A Web services based GRID Implementation Toolkit
• Authentication based on Web Service Security (XML signatures)
• Currently has no authorisation to protect web services
• PERMIS
• Is being integrated with OMII by LESC/Imperial College, London
• To provide standard PERMIS features of
• Policy controlled RBAC authorization
• X.509 ACs for user credentials
• Push/Pull Modes of operation
• IC are adding an SQL database to hold X.509 ACs instead of
LDAP
‹#›
GridShib PERMIS Architecture
‹#›
A Quick Look at the Future
• Specifying security policies in controlled natural
language. Software will convert these into machine
processable policies and then display them back to the
user in natural language
• Automated policy decomposition and distribution
around a grid.
‹#›
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Example Controlled Natural Language Policy
There are policies.
“My AC policy” is a policy.
There are resources and users.
David is a user.
Printer is a type of resource.
“HP Laserjet4” is a printer.
There are domains.
Kent is a domain.
There are “User Account Administrators”.
Peter is a User Account Administrator.
There are actions and parameters.
Print is an action.
Delete is an action.
Pause and resume are actions.
“No of pages” is a parameter.
Actions have parameters.
Print has action with value “No of pages”.
There are roles.
Student is a role.
Staff is a role.
Resources have actions.
“HP Laserjet4” has action with value print.
“HP Laserjet4”has action with value delete.
“HP Laserjet4” has action with value pause.
“HP Laserjet4” has action with value resume
‹#›
Legend
Visualisation
Service
Notifications
Job data
flows
Policy
transfers
PDP
Data
Repository
Gri
d
Job
Policy
Repository
PDP
PDP
PDP
Grid
Policy
Grid Manager
Processing Centre
Electron
Microscope
‹#›