gt 4 security goals & plans sam meder ([email protected])
TRANSCRIPT
GT 4 Security Goals & Plans
Sam Meder
The Ultimate Goal
Enable secure cross-organizational interactions
Least privilege rights delegation Support for multiple mechanisms -> translation Virtual Organization security fabric
Membership Policy etc
…
Trust Mismatch
Mechanism Mismatch
Multi-Institution Issues
CertificationAuthority
CertificationAuthority
Domain A
Server X Server Y
PolicyAuthority
PolicyAuthority
Task
Domain B
Sub-Domain A1 Sub-Domain B1
No Cross-
Domain Trust
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 Can’t 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
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!
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
Grid Solution:Use Virtual Organization as Bridge
Certification
Domain A
Server X Server Y
PolicyAuthority
PolicyAuthority
TaskDomain B
Sub-Domain A1
GSI
CertificationAuthority
Sub-Domain B1
Authority
FederationService
VirtualOrganization
Domain
No Cross-
Domain Trust
Effective Policy GoverningAccess Within A Collaboration
Use Delegation toEstablish Dynamic Distributed System
ComputeCenter
VO
Rights
ComputeCenter
Service
Goal is to do this with arbitrary mechanisms
ComputeCenter
VO
Rights
ComputeCenter
ServiceKerberos/
WS-Security
X.509/SSL
SAMLAttribute
X.509AC
SAMLAttribute
X.509AC
Security ofGrid Brokering Services
Data Source
Data SrcSvc
Post-ProcessingFacility
InputData
OutputData
ResultData
Requester
Svc X
ComputeFacility
Svc
SchedulingSvc
BandwidthSvc
BandwidthSvc
RawData
Compute Facility
• 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
Propagation of Requester’s Rights through Job Scheduling and Submission Process
Only DOE approved sites
Only NCSA resources
Only compute cluster ABC
All User's Rights & CapabilitiesRequester
ComputeResource
Scheduler
Scheduler
Scheduler
Dynamically limit the Delegated Rights more as Job specifics become clear
Trust parties downstream to limit rights for you…or let them come back with job specifics such that you can limit them
Virtualization complicates Least Privilege Delegation of Rights
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.
Functional Capabilities 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.
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
KeyManagement
UserManagement
PolicyManagement(authorization,
privacy,federation, etc)
Anti-virusManagement
IntrusionDetection
Policy Expression and Exchange
Bindings Security(transport, protocol, message security)
Tru
st M
odel
Sec
ure
Logg
ing
SecureConversations
Credential andIdentity Translation
(Single Logon)
Access ControlEnforcement
Audit &Non-repudiation
Service/End-pointPolicy
MappingRules
AuthorizationPolicy
PrivacyPolicy
Grid Security Services call-outs
RequestorApplication
VODomain
CredentialValidation
Service
AuthorizationService
Requestor'sDomain
Service Provider'sDomain
Audit/Secure-Logging
Service
AttributeService
TrustService
ServiceProvider
Application
Bridge/Translation
Service
PrivacyService
CredentialValidation
Service
AuthorizationService
Audit/Secure-Logging
Service
AttributeService
TrustService
PrivacyService
Secure ConversationWS-Stub WS-Stub
Grid Security Services with VO
RequestorApplication
VODomain
CredentialValidation
Service
AuthorizationService
Requestor'sDomain
Service Provider'sDomain
Audit/Secure-Logging
Service
AttributeService
TrustService
ServiceProvider
Application
Bridge/Translation
Service
PrivacyService
CredentialValidation
Service
AuthorizationService
Audit/Secure-Logging
Service
AttributeService
TrustService
PrivacyService
Secure Conversation
AuthorizationService
TrustService
AttributeService
CredentialValidation
Service
WS-Stub WS-Stub
Interaction with other Grid Services
All Grid services layered on Security Services All 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.
Security Policy derived from higher level agreements Enforcement 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
Authentication GSI Secure Message
Based on earlier WS-Security draft Support for signing and encrypting using X.509
certificates and X.509 Proxy Certificates Per message
GSI Secure Conversation Based on proprietary protocol (predates WS-
SecureConversation) GSSAPI
SSL + delegation + proxy cetificates (Kerberos)
Session based
GT 4 (3.9.2) Existing Features
Authorization Host Self Identity Gridmap Custom
GT 4 Plans-Authentication
Move to WSS4J Web Services Security 1.0 WS-I Basic Security Profile Support for Username/Password
Move to WS-Trust/WS-SecureConversation 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
Delegation Service Using WSRF
Delegated credentials modeled as resources 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 Requires modification of application protocol
GT 4 Plans - Authorization
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.)
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
Inclusion of MyProxy Non-WS to begin with