Globus Security

1
Globus Security

• 200pm, Jun 16, NCSA, University of Illinois
• GT4 Tutorial, Jun 16-17, 2005, Urbana-Champaign
• Frank Siebenlist
• (Argonne National Laboratory / University of
  Chicago)
• franks_at_mcs.anl.gov - http//www.globus.or
  g/

2
Acknowledgements

• Eve Maler (Sun)
• Prateek Mishra (Netegrity)
• Tom Scavo (NCSA)
• Von Welch (NCSA)
• RL Bob Morgan (UofWashington)
• Steven Carmody (BrownU)
• Scott Cantor (OhioStateU)
• Tom Barton (UofChicago)
• Jim Basney (NCSA)
• Veronika Nefadova (ANL)
• Carl Kesselman (ISI)

• Sam Meder (Univa)
• Jarek Gawor (ANL)
• Rachana Ananthakrishnan (ANL)
• Olle Molmo (KTH)
• Takuya Mori (NEC/ANL)
• Kate Keahey (ANL)
• Tim Freeman (UofChicago)
• David Champion (UofChicago)
• Ian Foster (ANL)
• Laura Pearlman (ISI)

3
Outline

• Part One
• The Big Picture
• What is Grid Security?
• Current Grid Security
• Part Two
• 2004 The year we lost control of the desktop
• Leverage Security Service Implementations
• GTs Authorization Processing Framework
• Futures and Conclusion

4
Security Services Objectives

• Its all about Policy
• (Virtual) Organizations Security Policy
• Security Services facilitate the enforcement
• Security Policy to facilitate Business
  Objectives
• Related to higher level agreement
• Security Policy often delicate balance
• More security ? Higher costs
• Less security ? Higher exposure to loss
• Risk versus Rewards
• Legislation sometimes mandates minimum security

5
Agreement ? VO Security Policy
(Business) Agreement
Dynamic VO Security Policy
Price Cost Obligations QoS TCs Security

members resources roles Attribute mgmt Authz
mgmt
Static Initial VO Security Policy
trust anchors (initial) members (initial)
resources (initial) roles Access rules Privacy
rules
6
Virtual Organization Concept
7
What is Grid Security?

• The Grid problem is to enable coordinated
  resource sharing and problem solving in dynamic,
  multi-institutional virtual organizations.
• From The Anatomy of the Grid
• So Grid Security is security to enable VOs
• What is needed in terms of security for a VO?

8
Resource Sharing

• coordinated resource sharing and problem
  solving in dynamic, multi-institutional virtual
  organizations.
• Resources being used are still owned by their
  respective organization and subject to its
  policies
• Sharing may be controlled amongst a number of VOs
• Non-trivial policy in regards to QoS, QoP, etc.

9
Controlled Resource Sharing

• Globally
• User must agreeto Acceptable Usage Policy
  (AUP)
• User must use strong authentication

ComputeCenter
20 Mbytes/sec max
BIO VO
5pm-9amonly
HEP VO
100 Tbytes max
20 Tflops per month max
Chem EngVO
10
Requires Coordination by VO

• coordinated resource sharing and problem
  solving in dynamic, multi-institutional virtual
  organizations.
• Resources contributed to VO need to be
  coordinated by the VO in order to work together
  effectively.
• All need to have a coherent policy in order to
  interoperate
• Requires policy from VO back to resources

11
Dynamic Users, Resources, Policies

• coordinated resource sharing and problem
  solving in dynamic, multi-institutional virtual
  organizations.
• Users, resources may be large, unpredictable, and
  changing at any point
• Roles of both may also be distinct and dynamic
  (not all users are equal).
• Doesnt allow for static configuration

12
Multiple Organizations, Mechanisms, Policies

• coordinated resource sharing and problem
  solving in dynamic, multi-institutional virtual
  organizations.
• Each resource and user will have local policies
  and technologies that cannot be replaced by the
  VO
• Cannot assume cross-organizational trust
  relationships

13
Multi-Institution Issues
Certification
Certification
Authority
Authority
Domain B
Domain A
Policy
Policy
Authority
Authority
Task
Server Y
Server X
Sub-Domain A1
Sub-Domain B1
14
Why Grid Security is Hard

• Resources being used may be valuable the
  problems being solved sensitive
• Both users and resources need to be careful
• Dynamic formation and management of virtual
  organizations (VOs)
• Large, dynamic, unpredictable
• VO Resources and users are often located in
  distinct administrative domains
• Cant assume cross-organizational trust
  agreements
• Different mechanisms credentials
• X.509 vs Kerberos, SSL vs GSSAPI, X.509 vs.
  X.509 (different domains),
• X.509 attribute certs vs SAML assertions

15
Why Grid Security is Hard

• Interactions are not just client/server, but
  service-to-service on behalf of the user
• Requires delegation of rights by user to service
• Services may be dynamically instantiated
• Standardization of interfaces to allow for
  discovery, negotiation and use
• Implementation must be broadly available
  applicable
• Standard, well-tested, well-understood protocols
  integrated with wide variety of tools
• Policy from sites, VO, users need to be combined
• Varying formats
• Want to hide as much as possible from
  applications!

16
The Grid Trust solution

• Instead of setting up trust relationships at the
  organizational level (lots of overhead, possible
  legalities - expensive!) set up trust at the
  user/resource level
• Virtual Organizations (VOs) for multi-user
  collaborations
• Federate through mutually trusted services
• Local policy authorities rule
• Users able to set up dynamic trust domains
• Personal collection of resources working together
  based on trust of user

17
Grid SolutionUse Virtual Organization as Bridge
No Cross- Domain Trust
Certification
Domain A
Federation
Service
GSI
Virtual
Organization
Domain
18
Effective Policy GoverningAccess Within A
Collaboration
19
Use Delegation toEstablish Dynamic Distributed
System
ComputeCenter
Service
Rights
VO
ComputeCenter
20
Goal is to do this with arbitrary mechanisms
ComputeCenter
X.509AC
X.509/SSL
SAMLAttribute
X.509AC
Kerberos/ WS-Security
Rights
VO
ComputeCenter
SAMLAttribute
21
Security ofGrid Brokering Services

• It is expected brokers will handle resource
  coordination for users
• Each Organization enforces its own access policy
• User needs to delegate rights to broker which
  may need to delegate to services
• QoS/QoP Negotiation and multi-level delegation

22
Propagation of Requesters Rights through Job
Scheduling and Submission Process
Virtualization complicates Least Privilege
Delegation of Rights
Dynamically limit the Delegated Rights more as
Job specifics become clear
Trust parties downstream to limit rights for
youor let them come back with job specifics
such that you can limit them
23
Grid Security must address

• Trust between resources without organization
  support
• Bridging differences between mechanisms
• Authentication, assertions, policy
• Allow for controlled sharing of resources
• Delegation from site to VO
• Allow for coordination of shared resources
• Delegation from VO to users, users to resources
• ...all with dynamic, distributed user communities
  and least privilege.

24
Security Layers
Grid-Mapfile/SAML/X.509 AC/XACML
Authorization
X.509 Proxy Certificates/SAML/XACML
Delegation
Authentication
X.509 ID Certificates
Message Protection
WS-Security/TLS/WS-SecureConversation
Message Format
SOAP
25
Grid Security Infrastructure (GSI)

• Use GSI as a standard mechanism for bridging
  disparate security mechanisms
• Doesnt solve trust problem, but now things talk
  same protocol and understand each others
  identity credentials
• Basic support for delegation, policy distribution
• Translate from other mechanisms to/from GSI as
  needed
• Convert from GSI identity to local identity for
  authorization

26
Grid Security Infrastructure (GSI)

• Based on standard PKI technologies
• CAs allow one-way, light-weight trust
  relationships (not just site-to-site)
• SSL protocol or WS-Security for authentication,
  message protection
• X.509 Certificates for asserting identity
• for users, services, hosts, etc.
• Proxy Certificates
• GSI extension to X.509 certificates for
  delegation, single sign-on

27
Grid Identity, Local Policy
Map tolocal name

• In current model, all Grid entities assigned a
  PKI identity.
• User is mapped to local identities to determine
  local policy.
• .

Grid Identity
LocalPolicy
Map tolocal name
LocalPolicy
28
Kerberos to GSI Gateway

• To use Kerberos, a Kerberos-to-GSI gateway
  translates Kerberos credentials to GSI
  credentials to allow local Kerberos users to
  authenticate on the Grid.
• Kx509/KCA is an implementation of one such
  gateway.
• Sslk5/pkinit provide the opposite functionality
  to gateway incoming Grid credentials to local
  Kerberos credentials.

29
Local Identity,Grid Identity, Local Policy
KCA
Map tolocal name
Grid Identity
KerberosSite
LocalPolicy
SSLK5
KRB5 Resources
30
GSI Implementation
Services (running on users behalf)
Authz Callout
Access
ComputeCenter
Rights
VOUsers
Rights
VO
MyProxy
Rights
KCA
31
X.509 Proxy Certificates

• GSI Extension to X.509 Identity Certificates
• RFC 3820
• Support being added to OpenSSL
• Enables single sign-on
• Allow user to dynamically assign identity and
  rights to service
• Can name services created on the fly and give
  them rights (i.e. set policy)
• What is effectively happening is the user is
  creating their own trust domain of services
• Services trust each other with user acting as the
  trust root

32
Proxy Certificates
Create
F1
Service
CNJane Doe
CNJane Doe/9874 Rights Can access file
F1, Service S1,
X.509 Proxy Delegation
Use delegated rights to access resources.
X.509 Id certificate
X.509 Proxy certificate
S1
33
Community Authorization Service

• Question How does a large community grant its
  users access to a large set of resources?
• Community Authorization Service (CAS)
• Outsource policy admin to VO sub-domain
• Enables fine-grained policy
• Resource owner sets course-grained policy rules
  for foreign domain on CAS-identity
• CAS sets policy rules for its local users
• Requestors obtain capabilities from their local
  CAS that get enforced at the resource

34
Community Authorization Service
Domain A
Domain B
Sub-Domain B1
Sub-Domain A1
Policy
Authority
Community
Authorization Svc
enforcement
CAS identity
on CAS-identity and
"trusted"
requestor's capabilities
capability
assertions
request
CAS assertions
Server
Requestor
Virtual
Organization
Domain
35
MyProxyCredential Wallet/Converter

• MyProxy allows users to store GSI credentials and
  retrieve them
• With username/pass phrase or other credential
• Can act as a credential translator from
  username/passphrase to GSI
• Used by services that can only handle username
  and pass phrases to authenticate to Grid
• Services limited by client implementations
• E.g. web portals
• Also handle credential renewal for long-running
  tasks

36
MyProxy - One-Time-Password

• MyProxy now supports SASL and PAM for
  authentication
• PAM plugins for one-time passwords (OTP) allow
  for bridging between OTP and Grid security
• User authenticates to MyProxy via OTP and gets
  short-term Grid credential in return

37
Portal-based Grid Interface PURSE

• Portal extensions (CGI scripts) that automate
  user registration requests.
• Solicits basic data from user.
• Generates cert request from CA (implemented with
  simple CA from GT).
• Admin interface allows CA admin to accept/reject
  request.
• Generates a certificate and stores in MyProxy
  service.
• Gives user ID/password for MyProxy.
• Benefits
• Users never have to deal with certificates.
• Portal can get user cert from MyProxy when
  needed.
• Database is populated with user data.
• This can be reused in other projects!

38
Delegation Service

• Exposes delegated credentials as first class
  resource
• Allows for resource across multiple services
• E.g. multiple jobs, RFT requests
• Allows for explicit destruction and renewal

39
Part 2 Outline

• 2004 The year we lost control of the desktop
• MyProxy/GridLogon, OTP/Smart-Cards,
  Secure-Password Protocols, Virtual Machines,
• Leverage Security Service Implementations
• OpenSSL, OpenSAML, Shibboleth, Permis, Suns
  XACML, CNRIs Handle System, XKMS
• GTs Authorization Processing Framework
• VOMS/Permis/X509/Shibboleth/SAML/Kerberos
  identity/attribute assertions
• XACML/SAML/CAS/Permis/ProxyCert/SPKI
  authorization assertions
• Futures and Conclusion

40
2004 The Year we lost Control of the Desktop

• Compromised accounts, trojans, sniffers, viruses
• When compromised not if
• New paradigm
• Try to raise bar arms race
• Its about Detection and Limit Consequences
  of Compromise
• New emphasis
• No more long-lived secrets with the user
• MyProxy/GridLogon
• One-Time-Password Secure Password protocols
• Virtual Machine Sandboxes

41
MyProxy/GridLogon

• No long-lived secrets on the users
  workstationgt move secrets to a secure
  MyProxy-server
• Issue derived short-lived proxy-certificates
• gt issue short-lived identity certificates
• On-line Certificate Authority (CA)
• Need for bootstrap authentication
• Passwords
• One-Time-Passwords
• Need for true secure password protocol

42
OTP Secure Password Protocol

• One-Time-Password issues
• Exchange in the clear - hijacking risk
• No mutual authentication
• Password authentication issues
• Off-line dictionary attacks
• Clear-text over SSL relies on server trust root
  on (untrusted) client
• Need for true secure password protocol
• Integrate OTP

43
OTP Trust-Root Provisioning
Bootstrap Users Trust-Root Config from Secure
OTP Authentication
Enhanced MyProxy/GridLogon Svc
Secure mutual OTP-Authentication and Key-Exchange
OTP AuthN Server users security config
Short-Lived Cert Provisioning of CAs,
AuthZ/Attr Authorities
OTP
user-workstation (initially not configured)
44
Virtual Machines to the Rescue

• VMs provide additional insulation
• Consequences of VM compromise limited
• Host compromise virtually impossible
• Frozen VM-Image of stable, tested,
  uncompromised OSServices configuration
• Distribution of safe VM-images
• Allows for easy restart/resync after compromise
• Interesting open source VM-efforts Xen
• Exciting promising first results at ANL (Tim
  Freeman, Kate Keahey)

45
How do Grids and VMs play toghether?
VM Factory
create new VM image
VM EPR
Create VM image
VM Repository
inspect and manage
Client

Resource
VM Manager
VM
start program
46
Part 2 Outline

• 2004 The year we lost control of the desktop
• MyProxy/GridLogon, OTP/Smart-Cards,
  Secure-Password Protocols, Virtual Machines,
• Leverage Security Service Implementations
• OpenSSL, OpenSAML, Shibboleth, Suns XACML,
  Handle System, Permis, XKMS
• GTs Authorization Processing Framework
• VOMS/Permis/X509/Shibboleth/SAML/Kerberos
  identity/attribute assertions
• XACML/SAML/CAS/Permis/ProxyCert/SPKI
  authorization assertions
• Futures and Conclusion

47
Leverage (Open Source) Security Service
Implementations

• OpenSSL
• native Proxy Certificate support
  coming(thanks to OpenSSL hacker Richard Levitte
  and KTH!)
• Internet2s OpenSAML
• Part of GT - used by CAS/GridShib/AuthzCallout/
• Internet2s Shibboleth
• NSF funded GridShib project to Grid-enable
  Shibboleth
• Suns open source XACML effort
• Integrate sophisticated policy decision engine in
  the GT
• CNRIs Handle System
• Leverage robust, secure, global naming system for
  resource/subject attribute bindings
• Futures XKMS, XrML, Permis,

48
GT - Shibboleth Integration

• NSF-funded GridShib Project
• http//grid.ncsa.uiuc.edu/GridShib/
• Leverage Shibboleth implementations and
  deployments
• Sophisticated, policy controlled attribute
  service
• Client-server interactions through WS-protocols
• (optionally) preserve pseudonymity of client
• GridShib code will become part of GT
• Transparent use of Shib servers in GT-runtime

49
GridShib Grid-Shibboleth Integration(Identity
Federation and Grids)

• NSF NMI project to allow the use of
  Shibboleth-issued attributes for authorization in
  NMI Grids built on the Globus Toolkit
• Funded under NSF award SCI-0438424
• Goal GT 4.2 Shibboleth 1.3
• GridShib team NCSA, U. Chicago, ANL
• Tom Barton, David Champion, Tim Freeman, Kate
  Keahey, Tom Scavo, Frank Siebenlist, Von Welch
• Working in collaboration with Steven Carmody,
  Scott Cantor, Bob Morgan and the rest of the
  Internet2 Shibboleth Design team

50
Why?

• Leverage Shibboleth code base
• Someone else is writing and debugging it
• Leverage Shibboleth deployments
• Someone else is supporting them
• Leverage larger issues going on in Identity
  Federation world
• Someone else is helping to write them
• Even more someone elses will be writing and
  deploying them
• SAML standard, profiles
• Leverage someone elses attributes?
• Are campus attributes useful to Grids?

51
Shibboleth (Simplified)
SAML
Shibboleth
Attrs
Attributes
Handle
WWW
IDs
Handle
52
GridShib (Simplified)
SAML
Shibboleth
Attrs
Attributes
DN
Grid
IDs
DN
SSL/TLS, WS-Security
DN
53
GridShib Goals

• Work with others to standardize X509 profile for
  Shibboleth/SAML AA
• Change as little as possible on Shibboleth side
• Limit to installation of new NameMapper plug-in
  for Shibboleth to recognize and map DNs to local
  identities
• Privacy
• In GridShib V2

54
GridShib Goals (cont)

• Modifications to GT to request, receive and parse
  SAML attributes from Shib
• General PDP functionality
• Grid uses cases can be very complicated and
  varied in terms of authz policy
• Try to support union of many simple cases
• Allow for deployment of custom PDPs

55
GridShib Challenges

• Identity Provider Discovery
• Compounded by need in some grids to consult
  several identity providers for each user
• Distributed Attribute Administration
• What happens when the folks running the attribute
  authority are not the ones authoritative for the
  attributes?
• Some projects dont have resources to run a 7x24
  security service, but are the only ones who know
  the attribute space
• Explore Signet, Grouper

56
GridShib Integration Goals

• Use Shibboleth 1.3 out of box
• With additional NameMapper module to handle
  mapping X.509 identities to local names
• Work with Shib identity provider metadata
• Working with Shib developers to achieve
• Dont require modification to typical grid client
  applications for simple use cases
• Most of work going into Grid services

57
DOE Earth System Grid

• Goal address technical obstacles to the
  sharing analysis of high-volume data from
  advanced earth system models

www.earthsystemgrid.org
58

Major ESG Components

• Grid Services
• GRAM resource access
• GridFTP
• PURSE
• MDS (WebSDV, Trigger Service, Archiver)
• MyProxy credential repository
• SimpleCA
• RLS replica location service
• MCS metadata catalog service

• Other Services
• OpenDAPg
• HPSS
• SRM
• LAS
• Apache, Tomcat
• ESG-specific services
• Workflow Manager
• Registration Service
• Monitoring Service

59

Major ESG Components
60
ESG Authorization requirements

• Access to most data requires that the name of the
  requesting user be logged.
• Access to some private data is restricted to
  specific users.
• Some data is located on mass storage systems to
  which access is restricted to users with approved
  PKI credentials.
• Some data is located on HPSS storage behind
  GridFTP server
• Some data is located on disk storage behind HTTPS
  server.

61
ESG Authorization Requirements

• Access control for data accessed via portal
• Group-based control to data and metadata
• Variety of data return modalities, e.g.
• From portal as intermediary to servers
• Directly from GridFTP server
• Credentials of a variety of qualities
• Higher quality via formal CA (personal review)
• Lower quality via Web (email verification)
• Easy to use Web sign on
• MyProxy as credential repository
• GSI credentials for GridFTP server access

62
PURSE Portal-basedUser Registration Service

• Portal extensions (CGI scripts) that automate
  user registration requests.
• Solicits basic data from user.
• Generates cert request from ESG CA (implemented
  with simple CA from GT).
• Admin interface allows CA admin to accept/reject
  request.
• Generates a certificate and stores in MyProxy
  service.
• Gives user ID/password for MyProxy.
• Benefits
• Users never have to deal with certificates.
• Portal can get user cert from MyProxy when
  needed.
• Database is populated with user data.
• Users are assigned to one or several user groups
  (with different data access permissions)
• Soon to be released
• ESG first customer and provided requirements
• Integrated solution released through Grid Center

63
PURSe (contd.)
64
PURSe (Contd.)
65
ESG data access control
66
Earth Science Grids use of CAS-Assertions
MyProxy/GridLogon used for portal authentication
Password Username
MyProxy/GridLogon used for UserDN mapping
Username UserDN
Group membership assignment
UserDN Group
Access Policy expressed with groups, actions and
logical file names
Group Operation LFile
Mapping of logical file names to physical file
paths
LFile PFile
SAML Authorization Assertion signed by PortalId
User with UserDN is allowed to invoke
Operation on physical file Pfile
67
ESG Portal Access
Pfile
FileServer
PFile access integration
userDN group
Group Action LFile
LFile PFile
PFile
Portal
policy enforcement
userDN mapping
login
PFile retrieval
username/ password validation
username password
username userDN
browse
MyProxy
User
68
ESG External GridFTP Access

• User browses portal to identify file(s)
• Portal returns
• Physical file location (URL)
• SAML assertion in CAS format User can invoke
  requested operation on file(s)
• User
• Obtains proxy-certificate from MyProxy
• Embeds SAML-assertion in proxy-cert
• Uses GridFTP client to retrieve physical file(s)
  from CAS-enabled GridFTP server

69

Download with DML from any source locations

• DML Contact ESG authorizer, provides it with
  LFN TURL
• DML gets back SAML with long lifetime (days) for
  each file
• DML invokes GridFTP
• DML automatically releases files after it moves
  them

• User downloads DataMover-light(must contain
  GridFTP and GSI)
• User goes to portal, select files
• Portal does not get any file s
• Portal sends email to user
• Contains a text file of files to be moved
• Contains instructions and lifetime
• DML contacts source SRMs to get TURL(for GridFTP
  it is not necessary)

Note The datamover.txt file will contain a
header with the end-point of the ESG Portal
Authorizer
DataPortal
Users machine
ESG Portal
(1) Find file(s), Get SURLs (by email)
ESG Authorizer
Users browser
DRM
(3) Provide TURL
HRM
(4) get SAML
(2) Request file(s)
DataMover Light
HRM
(2) Request file(s) From NCARs MSS
GridFTP
(5) transfer file(s)
Disk Cache
Disk Cache
FTP
(5) transfer file(s)
NCARs MSS
70
ESG External GridFTP Retrieval
username password
username userDN
MyProxy
userDN group
Group Action LFile
LFile PFile
PFile
GridFTP Server
Portal
CAS policy enforcement
Login Proxycert Issuance
policy enforcement
gridftp access GSI-creds Portal authz assertion
login
PFile URL authz assertion
browse
User
71
Reuse of Fabric Plumbing from Community Auth.
Service (CAS)

• ESG-Portal uses no CAS server but generates its
  own authorization statements
• Statements are domain specific
• Same assertion format as CAS
• Standard SAML assertion signed by PortalId
• User deploys CAS-enabled GridFTP client
• Deploys identical GSI creds and proxy-certs
• Site uses CAS-enabled GridFTP server
• Remote site trusts Portal (instead of CAS)
• Portal makes access control decisions
• Usage Pattern applicable to many more projects

72
Part 2 Outline

• 2004 The year we lost control of the desktop
• MyProxy/GridLogon, OTP/Smart-Cards,
  Secure-Password Protocols, Virtual Machines,
• Leverage Security Service Implementations
• OpenSSL, OpenSAML, Shibboleth, Permis, Suns
  XACML, CNRIs Handle System, XKMS
• GTs Authorization Processing Framework
• VOMS/Permis/X509/Shibboleth/SAML/Kerberos
  identity/attribute assertions
• XACML/SAML/CAS/Permis/ProxyCert/SPKI
  authorization assertions
• Futures and Conclusion

73
Security Services with VO
74
GTs GGFs Authorization Call-Out Support

• GGFs OGSA-Authz WG Use of SAML for OGSA
  Authorization
• Authorization service specification
• Extends SAML spec for use in WS-Grid
• Recently standardized by GGF
• Conformant call-out integrated in GT
• Transparently called through configuration
• Permis interoperability
• Ready for GT4!
• Futures
• SAML2.0 compliance XACML2.0-SAML2.0 profile

75
GT-XACML Integration

• eXtensible Access Control Markup Language (XACML)
• OASIS standard
• Open source implementations
• XACML sophisticated policy language
• Globus Toolkit ships with XACML runtime
• Integrated in every client and server build on GT
• Turned-on through configuration
• can be called transparently from runtime and/or
  explicitly from application
• and were using the XACML-model for our Authz
  Processing Framework

76
GTs Assertion Processing Problem

• VOMS/Permis/X509/Shibboleth/SAML/Kerberos
  identity/attribute assertions
• XACML/SAML/CAS/XCAP/Permis/ProxyCert
  authorization assertions
• Assertions can be pushed by client, pulled from
  service, or locally available
• Policy decision engines can be local and/or
  remote
• Delegation of Rights is required feature
  implemented through many different means
• GT-runtime has to mix and match all policy
  information and decisions in a consistent manner

77
Basic Access Control Policy
Ivans policy Alice is my friend and Ill share
my lemonade with her Mallory is not my friend and
he can go
Can I have glass of lemonade?
Sure, here is a glass
Can I have glass of lemonade?
No way, I dont like you
78
Basic Access Control Policy (2)
Ivans policy Alice is my friend and Ill share
my lemonade with her Mallory is not my friend and
he can go
Can I have glass of lemonade?
Sure, here is a glass
Resource Owner decides! (ultimate source of
authority for access)
Can I have glass of lemonade?
No way, I dont like you
79
Delegation of Rights (1)
80
Delegation of Rights (2)
Ivans policy Carol is my friend and Ill share
my lemonade with her Ill share my lemonade with
any friend of Carol I dont know any Bob(?)
Ivan likes Carol Carol likes Bob gt Ivan likes
Bob (non-normative delegation logic -) )
Carols policy Bob is my friend and Ill share
my lemonade with him
81
Delegation of Rights (4)
82
Delegation of Rights (5)
83
Delegation of Rights (6)
84
How to solve his AuthZ decision issue? (1)
Can I have glass of lemonade?
85
How to solve his AuthZ decision issue? (2)
Policy/Decision Issuers
Master PDP (Decision Orchestrator)
Can I have glass of lemonade?
Invocation request for operation on resource
Subject
Resource Owner Policy Issuer
86
How to solve his AuthZ decision issue? (3)
Standardized AuthZ Query Interface
All AuthZ Decision Queries are asked through
Standardized Interface All Decision Results are
PERMIT/NotApplicable(/DENY) All differences in
policy, policy language, kind/use of rules are
hidden behind the interface
Master PDP
Can I have glass of lemonade?
Invocation request for operation on resource
Subject
Resource Owner Policy Issuer
87
How to solve his AuthZ decision issue? (4)
Policy/Decision Issuers
Resources PEP asks Master-PDP for decision
Master PDP
Can subject invoke operation on resource?
Can I have glass of lemonade?
Invocation request for operation on resource
Subject
Resource Owner Policy Issuer
88
How to solve his AuthZ decision issue? (5)
Master-PDP asks Resource Owner for decision If
resource owner permits, then final decision is
PERMIT, because resource owner decides else
Policy/Decision Issuers
Can subject invoke operation on resource?
Master PDP
Can I have glass of lemonade?
Invocation request for operation on resource
Subject
Resource Owner Policy Issuer
89
How to solve his AuthZ decision issue? (6)
Policy/Decision Issuers
Can subject invoke operation on resource?
Master-PDP asks all possible policy issuers
one-by-one if they allow the subject to invoke
the operation on the resource
Master PDP
Can I have glass of lemonade?
Invocation request for operation on resource
Subject
Resource Owner Policy Issuer
90
How to solve his AuthZ decision issue? (7)
Policy/Decision Issuers
Can subject invoke operation on resource?
Master-PDP asks all possible policy issuers
one-by-one if they allow the subject to invoke
the operation on the resource
Master PDP
Can I have glass of lemonade?
Invocation request for operation on resource
Subject
Resource Owner Policy Issuer
91
How to solve his AuthZ decision issue? (8)
For each policy issuer that permits the
access, The Master-PDP asks the resource owner
if that policy issuer is allowed to administer
the access to the resource If so, final decision
is PERMIT, else
Policy/Decision Issuers
PERMIT!
Master PDP
Can Carol administer access to resource?
Can I have glass of lemonade?
Invocation request for operation on resource
Subject
Resource Owner Policy Issuer
92
How to solve his AuthZ decision issue? (9)
Policy/Decision Issuers
Carol permits Bob access
Can Carol administer access to resource?
Master PDP
For each policy issuer that permits the
access, The Master-PDP asks the other policy
issuers if that policy issuer is allowed to
administer the access to the resource
Can I have glass of lemonade?
Invocation request for operation on resource
Subject
Resource Owner Policy Issuer
93
How to solve his AuthZ decision issue? (10)
Policy/Decision Issuers
Laura permits Carol to administer access
PERMIT!
Carol permits Bob access
Can Laura administer access to resource?
Master PDP
For each policy issuer that permits the
administration, The Master-PDP asks the resource
owner if that policy issuer is allowed
to administer the access to the
resource If so, final decision is PERMIT, else
try next level of delegation until no
more
Can I have glass of lemonade?
Invocation request for operation on resource
Subject
Resource Owner Policy Issuer
94
What are the Grid/P2P issues with distributed
authorization? (1)

• Many different parties want to express their
  opinion about each others access rights
• Anybody can say anything about anyone else
• Expressed in many different languages
• Enforcement of single policy language
  impossible/not-desirable
• Some parties can be asked about their opinion
• Expose themselves as an AuthZ-oracle (PDP)
• Other parties send their opinion as statements
• Authenticated policy/decision statements/assertion
  s expressed in their favorite language

95
What are the Grid/P2P issues with distributed
authorization? (2)

• Some of that advise is from parties youve never
  met before
• So they must be empowered by those you do know
• Some advise does not apply, is mal-formed,
  malicious, fake, erroneous, .
• often you do not know that by looking at them
• Different parties will use different names for
  the same subject
• Need identity federation for mapping
• Different parties will use different groups/roles
  in their policy expressions
• Only the group/role that is actually used in a
  relevant policy expression is of interest

96
Identity/Attribute Federation Requirements (1)
This is Bill
Aunt calls him William
His sister Rita calls him Will
His big brother David calls him Billie
Bill doesnt want you to know what his girlfriend
Olivia calls him
Each of those policy issuers express their
policy-rules using theirname for Bill The
policy evaluator needs to map/federate those
different names in order to be able to apply the
rules correctly
Can I have glass of lemonade?
97
Identity/Attribute Federation Requirements (2)
These are Emmas friends
These are Lucys friends
The attribute/group friends is local to the
issuer The policy evaluator needs to maintain
issuer info with local attributes in order to be
able to apply the rules correctly At evaluation
time we need to understand what are the local
names, global names, or guaranteed unique
names within the context
Can I have glass of lemonade?
98
Negative Permissions are Evil!

• General advise dont use Deny
• clarity issues with understanding consequences
  of individual deny policy rules
• Policy becomes too complex too soon
• Pushing of Deny-assertions DoS gt
  Security Exposure
• but, but, but, . we need/want deny!
• No you dont -)
• You want black-lists!

99
Black List Services

• BL-PDPs return Deny or Not-Applicable
• Master-DPD treats Permit as Not-Applicable
• Only interested whether the black-list services
  deny access to the subject
• They are not to be used for rendering of general
  purpose policy decisions
• Query the configured black-list services before
  the general purpose PDPs
• Pushing of black-list assertions or EPRs not
  allowed
• Deny-Override rules for the black-list services
• pragmatic way to address deny-requirements
• note that you are still allowed to shoot yourself
  in the foot with deny-policies behind the PDP
  interface

100
Black-List PDPs/Services
General PDPs
Black-List PDPs
Master PDP
For each decision query, Master-PDP consults
Black-List PDPs before querying General PDPs
Can I have glass of lemonade?
Subject
Resource Owner Policy Issuer
101
Different Policy Languages Issue
102
Requirement for an Policy Evaluation Service
(PES)

• Like a PDP, but in addition, you also supply the
  policy rules/statements to evaluate
• PES is an (external) service that the relying
  party trusts to evaluate an AuthZ decision
• Solves the issue that not all runtimes have the
  evaluation engines available to determine whether
  received policy decisions/statements/assertions
  apply
• One PES implementation for each policy language
  flavor
• the PDP interface could be extended to
  accommodate policy statements as an input
  parameter

103
Attribute/Authorization Processing
104
Authz Processing Assumptions (1)

• All Policy Statements, PDPs and Authz-Decisions
  have Issuer associated with them
• someone has to take responsibility for
  statements and associated decisions
• Resource Owner is the Ultimate Authority
• Any statement/decision that can not be directly
  traced back to the owner is NotApplicable
• traced back delegation chain that starts with
  owner
• Two different Policy Statements and Queries
• Admin Policy Statements
• Issuer states that certain admin-subject are
  allowed to administer the rights of certain
  access-subjects to invoke certain operations on
  certain resources.
• Access Policy Statements
• Issuer states that certain access-subject are
  allowed to invoke certain operations on certain
  resources.

105
Authz Processing Assumptions (2)

• Push-Pull Equivalence
• Pushing authz-assertion and evaluating it locally
  renders same decision as evaluating the same
  policy statements remotely behind an external PDP
  
• Authz-Decisions are Policy Statements
• Folded over the request context
• Could optimize by only considering the attributes
  used to render a decision
• If attributes dont specify a invocation
  context, then only the invokers identity would
  suffice
• Conservative mandate that all request contexts
  attributes values are equal to the ones that
  rendered the decision.

106
Attribute Collection Framework
107
GTs Authorization Processing Model (1)

• Use of a Policy Decision Point (PDP) abstraction
  that conceptually resembles the one defined for
  XACML.
• Normalized request context and decision format
• Modeled PDP as black box authorization decision
  oracle
• After validation, map all attribute assertions to
  XACML Request Context Attribute format
• Create mechanism-specific PDP instances for each
  authorization assertion and call-out service
• The end result is a set of PDP instances where
  the different mechanisms are abstracted behind
  the common PDP interface.

108
GTs Authorization Processing Model (2)

• The Master-PDP orchestrates the querying of each
  applicable PDP instance for authorization
  decisions.
• Pre-defined combination rules determine how the
  different results from the PDP instances are to
  be combined to yield a single decision.
• The Master-PDP is to find delegation decision
  chains by asking the individual PDP instances
  whether the issuer has delegated administrative
  rights to other subjects.
• the Master-PDP can determine authorization
  decisions based on delegated rights without
  explicit support from the native policy language
  evaluators.

109
GT Authorization Framework (1)
110
GT Authorization Framework (2)
AAA token
111
GT Authorization Framework (3)
112
GT Authorization Framework (3)

• Master-PDP accessed all mechanism-specific PDPs
  through same Authz Query Interface
• SAML-XACML-2 profile
• Master PDP acts like XACML Combinator
• Permit-Overrides rules
• Negative permissions are evil
• Delegation-chains found through exhaustive search
• with optimization to evaluate cheap decisions
  first
• Blacklist-PDPs are consulted separately
• Statically configured, call-out only PDPs
• Deny-Overrides only for the blacklist-PDPs
• Pragmatic compromise to keep admin simple

113
Big Picture Conclusion

• GT4 is security buzzword compliant!
• probably the most full-featured-security
  ws-toolkit
• WebServices technologies provide low-level
  plumbing
• following all relevant standards
• Portals growing as a user interface
• Clients use http, but portals will use
  WS-protocols!
• PURSE, ESG,
• New Deployment Paradigms (GridLogon, VMs)
• Driven by inability to protect
• Authorization still the big focus
• unification framework needed to support
  different mechanisms and formats gt GT4.2