GT 4 Security Goals & Plans
Sam Meder
(meder@mcs.anl.gov)
The Ultimate Goal
‹
Enable secure cross-organizational
interactions
z
Least privilege rights delegation
z
Support for multiple mechanisms -> translation
z
Virtual Organization security fabric
z
…
‹
Membership
‹
Policy
‹
etc
Multi-Institution Issues
No Cross-
Domain Trust
Certification
Authority
Certification
Authority
Domain B
Domain A
Trust Mismatch
Policy
Authority
Policy
Authority
Task
Server X
Sub-Domain A1
Mechanism Mismatch
Server Y
Sub-Domain B1
Why Grid Security is Hard
z
Resources being used may be valuable & the problems
being solved sensitive
‹
z
Dynamic formation and management of virtual
organizations (VOs)
‹
z
Both users and resources need to be careful
Large, dynamic, unpredictable…
VO Resources and users are often located in distinct
administrative domains
‹
‹
Can’t assume cross-organizational trust agreements
Different mechanisms & credentials
z
z
X.509 vs Kerberos, SSL vs GSSAPI,
X.509 vs. X.509 (different domains),
X.509 attribute certs vs SAML assertions
Why Grid Security is Hard…
z
Interactions are not just client/server,
but service-to-service on behalf of the user
‹
‹
z
z
Standardization of interfaces to allow for discovery,
negotiation and use
Implementation must be broadly available & applicable
‹
z
Standard, well-tested, well-understood protocols;
integrated with wide variety of tools
Policy from sites, VO, users need to be combined
‹
z
Requires delegation of rights by user to service
Services may be dynamically instantiated
Varying formats
Want to hide as much as possible from applications!
The Grid Trust solution
z
z
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
‹
z
Users able to set up dynamic trust domains
‹
Personal collection of resources working
together based on trust of user
Grid Solution:
Use Virtual Organization as Bridge
No CrossDomain Trust
Certification
Authority
Certification
Authority
Policy
Authority
Policy
Authority
Sub-Domain B1
Sub-Domain A1
Domain A
Domain B
Task
Federation
Service
GSI
Server X
Virtual
Organization
Domain
Server Y
Effective Policy Governing
Access Within A Collaboration
Use Delegation to
Establish Dynamic Distributed System
Compute
Center
Service
Rights
VO
Compute
Center
Goal is to do this
with arbitrary mechanisms
Compute
Center
X.509
AC
X.509/SSL
X.509
AC
Service
SAML
Attribute
Kerberos/
WS-Security
Rights
VO
SAML
Attribute
Compute
Center
Security of
Grid Brokering Services
Compute Facility
Raw
Data
Data Source
Input
Data
Bandwidth
Svc
Compute
Facility
Svc
Data Src
Svc
Output
Data
Scheduling
Svc
Bandwidth
Svc
Requester
• 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
Svc X
Result
Data
Post-Processing
Facility
Propagation of Requester’s Rights through
Job Scheduling and Submission Process
Virtualization complicates Least
Privilege Delegation of Rights
Compute
Resource
Only compute cluster ABC
Scheduler
Dynamically limit the
Delegated Rights
more as Job specifics
become clear
Only NCSA resources
Scheduler
Only DOE approved sites
Scheduler
Requester
All User's Rights & Capabilities
Trust parties
downstream to limit
rights for you…
or let them come
back with job
specifics such that
you can limit them
Grid Security must address…
z
z
Trust between resources without organization
support
Bridging differences between mechanisms
‹
z
Allow for controlled sharing of resources
‹
z
Delegation from site to VO
Allow for coordination of shared resources
‹
z
Authentication, assertions, policy…
Delegation from VO to users, users to resources
...all with dynamic, distributed user communities
and least privilege.
Functional Capabilities
w
w
w
w
Authentication service:
An authentication service is
concerned with verifying proof of an
asserted identity.
Identity mapping service:
The identity mapping service
provides the capability of
transforming an identity that exists
in one identity domain into a
identity within another identity
domain.
Authorization service:
The authorization service is
concerned with resolving a policy
based access control decision.
Credential Conversion service:
The credential conversion service
provides credential conversion
between one type of credential to
another type or form of credential.
w
w
w
w
w
Audit service:
The audit service is responsible for
producing records, which track
security relevant events.
Profile service:
The profile service is concerned with
managing service requestor’s
preferences and data which may not
be directly consumed by the
authorization service.
Privacy service:
The privacy service is primarily
concerned with the policy driven
classification of personally
identifiable information (PII).
VO Policy service:
The VO policy service is concerned
with the management of policies.
…
Security Components
Intrusion
Detection
Secure
Conversations
Credential and
Identity Translation
(Single Logon)
Access Control
Enforcement
Audit &
Non-repudiation
Anti-virus
Management
Authorization
Policy
Policy Expression and Exchange
User
Management
Key
Management
Bindings Security
(transport, protocol, message security)
Privacy
Policy
Secure Logging
(authorization,
privacy,
federation, etc)
Mapping
Rules
Trust Model
Policy
Management
Service/End-point
Policy
Grid Security Services call-outs
Requestor's
Domain
Attribute
Service
Trust
Service
Audit/
Secure-Logging
Service
Service Provider's
Domain
Authorization
Service
Authorization
Service
Privacy
Service
Trust
Service
Attribute
Service
Audit/
Secure-Logging
Service
Privacy
Service
Credential
Validation
Service
Credential
Validation
Service
Bridge/
Translation
Service
Requestor
Application
WS-Stub
Secure Conversation
VO
Domain
WS-Stub
Service
Provider
Application
Grid Security Services with VO
Requestor's
Domain
Attribute
Service
Trust
Service
Audit/
Secure-Logging
Service
Service Provider's
Domain
Authorization
Service
Authorization
Service
Privacy
Service
Trust
Service
Attribute
Service
Audit/
Secure-Logging
Service
Privacy
Service
Credential
Validation
Service
Credential
Validation
Service
Bridge/
Translation
Service
Requestor
Application
WS-Stub
Credential
Validation
Service
Secure Conversation
Trust
Service
VO
Domain
Authorization
Service
WS-Stub
Attribute
Service
Service
Provider
Application
Interaction with other Grid
Services
z
All Grid services layered on Security Services
‹ All
z
interactions are subject to policy enforcement
Grid Security Services leverage other Services
‹ Use
of registries/databases/QoS/discovery/migration/
meta-data-publication/fail-over/mirroring/provisioning/etc.
z
Security Policy derived from higher level agreements
‹ Enforcement
z
is means to meet “business” objectives
New agreements subject to governing security policy
‹ existing
access restriction override any new agreement
Security Services can not be seen in isolation!
GT 4 (3.9.2) Existing Features
z
Authentication
‹
‹
GSI Secure Message
z
Based on earlier WS-Security draft
z
Support for signing and encrypting using X.509
certificates and X.509 Proxy Certificates
z
Per message
GSI Secure Conversation
z
Based on proprietary protocol (predates WSSecureConversation)
z
GSSAPI
z
‹
SSL + delegation + proxy cetificates
‹
(Kerberos)
Session based
GT 4 (3.9.2) Existing Features
z
Authorization
‹
Host
‹
Self
‹
Identity
‹
Gridmap
‹
Custom
GT 4 Plans-Authentication
z
z
Move to WSS4J
‹
Web Services Security 1.0
‹
WS-I Basic Security Profile
‹
Support for Username/Password
Move to WS-Trust/WS-SecureConversation
‹
z
z
Make GSI-Secure Conversation compliant
with latest drafts
(Introduce secure Username/Password
session protocol (based on AuthA))
(https – XML Security performance…)
GT 4 Plans - Delegation
z
Delegation Service
‹
‹
‹
‹
Using WSRF
z
Delegated credentials modeled as resources
z
Lifetime management using WS-ResourceLifetime
Allows decoupling of delegation from
authentication
No problem with WS-I Basic Security Profile
Pushes delegation handling to application
level
z
Requires modification of application protocol
GT 4 Plans - Authorization
z
z
CAS WSRF port
Integration of new authorization
framework developed at KTH
‹
XACML engine
‹
Management interface
‹
Chaining of authorization decisions
‹
Per method granularity
GT 4 Plans – Authorization (cont.)
z
z
Port of SAML authorization callout
‹
Based on work in OGSA Authz WG
‹
Requires schema for resource id
CAS enabled grid services
‹
‹
Integration of SAML based CAS assertions
with XACML engine
Will lead to generic SAML/XACML delegation
of rights framework
GT 4 Plans - MyProxy
z
Inclusion of MyProxy
‹
Non-WS to begin with