Controlling VO Access to your Resources

1
Controlling VO Access to your Resources

• David Chadwick
• The Computing Laboratory
• University of Kent, UK
• d.w.chadwick_at_kent.ac.uk

2
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

3
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 users roles and
• all privileges are gone
• Manageability
• Users change more
• frequently than roles
• Scalability
• No of roles usually
• much less than no
• of users

4
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 subjects 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

5
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

6
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 Tescos or Sainsburys

7
ArchitecturalModel
ARAttribute Repository CISCredential 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
6
3
4
5
6
8
9
11
12
1
Subject
PEP
Target
PEP
7
2
10
Environment
Environment
8
Conceptual Model Architecture

• PEP (Policy Enforcement Point)
• Application dependent
• Controls outgoing and incoming requests
• PDP (Policy Decision Point)
• 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

9
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

10
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.

11
Example Implementations

• VOMS
• XACML
• Microsoft STS
• TrustCoM
• PERMIS

12
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 users
  attributes

13
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 subjects PEP or the
  targets PEP to make access control decisions

14
Microsofts 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

15
TrustCoM Project

• Has integrated Microsofts STS (CIS-CVS) with
  Suns 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

16
PERMIS

• Provides a complete authorisation system with
  Credential Issuing, Credential Validation and a
  PDP plus user interfaces for managing each of them

17
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

18
Policy Editor
19
Policy Wizard
20
Natural Language Policy Output
21
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

22
Attribute Certificate Manager
23
Delegation Issuing Service
Authenticate DIS Client
Map identities
PERMIS Decision Engine
PDP
Authn name
Authzn name
Request Authorisation
DIS PEP
CVS
Issue AC
Web service interface
Delegation Policy
Sign AC
Retrieve AC
Publish AC
LDAP server
24
Apache front end to DIS
25
PERMIS Modular Credential Validation Service
1. Request attributes
6. Return attributes
Credential provider can either be external (pull
mode) or passed by caller (push mode)
26
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

27
GridShib PERMIS Architecture
28
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.

29
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.

30
Legend
Visualisation Service
Notifications
Job data flows
Policy transfers
Data Repository
Grid Job
Policy Repository
Grid Manager
Electron Microscope