Grid Security: The Globus Perspective Frank Siebenlist (ANL) Von Welch (NCSA) Globus. WORLD 2004 http: //www. globus. org/ Copyright (c) 2002 University of Chicago and The University of Southern California. All Rights Reserved. presentation is licensed for use under the terms of the Globus Toolkit Public License. See http: //www. globus. org/toolkit/download/license. html for the full text of this license. This
Outline l Part One: Von Welch, NCSA l Security basics l What is Grid Security? What makes it different? l Current Grid Security l Part Two: Frank Siebenlist, ANL l OGSA Grid Evolution l OGSA Security and Web Services Security l Web Service Security Landscape l GT 3 Implementation and Futures Globus. WORLD 2004 Security: The Globus Perspective 2
Security Terminology l Authentication: l Authorization: l Message Establishing identity Establishing rights protection u. Message integrity u. Message confidentiality l Digital signature l Auditing Globus. WORLD 2004 Security: The Globus Perspective 3
Public Key Security Terminology l Private and Public Key l Certificate Authority (CA) l Public Key Insfrastructure (PKI) Globus. WORLD 2004 Security: The Globus Perspective 4
What is Grid Security? The Grid problem is to enable “coordinated resource sharing and problem solving in dynamic, multiinstitutional virtual organizations. ” From The Anatomy of the Grid l So Grid Security is security to enable VOs l What is needed in terms of security for a VO? Globus. WORLD 2004 Security: The Globus Perspective 5
LHC Data Distribution ~PBytes/sec Online System ~20 TIPS There are 100 “triggers” per second Each triggered event is ~1 MByte in size ~622 Mbits/sec or Air Freight (deprecated) France Regional Centre Spec. Int 95 equivalents Offline Processor Farm There is a “bunch crossing” every 25 nsecs. Tier 1 1 TIPS is approximately 25, 000 ~100 MBytes/sec Tier 0 Germany Regional Centre ~100 MBytes/sec CERN Computer Centre Italy Regional Centre Fermi. Lab ~4 TIPS ~622 Mbits/sec Tier 2 ~622 Mbits/sec Institute ~0. 25 TIPS Physics data cache Institute ~1 MBytes/sec Tier 4 Caltech ~1 TIPS Tier 2 Centre Tier 2 Centre ~1 TIPS Physicists work on analysis “channels”. Each institute will have ~10 physicists working on one or more channels; data for these channels should be cached by the institute server Physicist workstations Globus. WORLD 2004 Security: The Globus Perspective 6
Resource Sharing “…coordinated resource sharing and problem solving in dynamic, multiinstitutional virtual organizations. ” l Resources being used are still owned by their respective organization and subject to its policies Sharing may be controlled amongst a number of VOs u Non-trivial policy in regards to Qo. S, Qo. P, etc. u Globus. WORLD 2004 Security: The Globus Perspective 7
Controlled Resource Sharing Compute Center Globally: • User must agree to AUP • User must use strong authentication 20 Mbytes/sec max 5 pm-9 am only HEP VO BIO VO 20 Tflops per month max 100 Tbytes max Chem Eng VO Globus. WORLD 2004 Security: The Globus Perspective 8
Requires Coordination by VO “…coordinated resource sharing and problem solving in dynamic, multiinstitutional virtual organizations. ” l Resources contributed to VO need to be coordinated by the VO in order to work together effectively. u u All need to have a coherent policy in order to interoperate Requires policy from VO back to resources Globus. WORLD 2004 Security: The Globus Perspective 9
Dynamic Users, Resources, Policies “…coordinated resource sharing and problem solving in dynamic, multi-institutional virtual organizations. ” l Users, resources may be large, unpredictable, and changing at any point l Roles of both may also be distinct and dynamic (not all users are equal). l Doesn’t allow for static configuration Globus. WORLD 2004 Security: The Globus Perspective 10
Multiple Organizations, Mechanisms, Policies “…coordinated resource sharing and problem solving in dynamic, multi-institutional virtual organizations. ” l Each resource and user will have local policies and technologies that cannot be replaced by the VO l Cannot assume cross-organizational trust relationships Globus. WORLD 2004 Security: The Globus Perspective 11
Multi-Institution Issues No Cross- Domain Trust Certification Authority Domain B Domain A Trust Mismatch Policy Authority Task Server X Sub-Domain A 1 Globus. WORLD 2004 Mechanism Mismatch Server Y Security: The Globus Perspective Sub-Domain B 1 12
Why Grid Security is Hard l Resources being used may be valuable & the problems being solved sensitive u l Dynamic formation and management of virtual organizations (VOs) u l Both users and resources need to be careful Large, dynamic, unpredictable… VO Resources and users are often located in distinct administrative domains u u Can’t assume cross-organizational trust agreements Different mechanisms & credentials l l X. 509 vs Kerberos, SSL vs GSSAPI, X. 509 vs. X. 509 (different domains), X. 509 attribute certs vs SAML assertions Globus. WORLD 2004 Security: The Globus Perspective 13
Why Grid Security is Hard… l Interactions are not just client/server, but service-to-service on behalf of the user u u l l Standardization of interfaces to allow for discovery, negotiation and use Implementation must be broadly available & applicable u l Standard, well-tested, well-understood protocols; integrated with wide variety of tools Policy from sites, VO, users need to be combined u l Requires delegation of rights by user to service Services may be dynamically instantiated Varying formats Want to hide as much as possible from applications! Globus. WORLD 2004 Security: The Globus Perspective 14
The Grid Trust solution l l 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 u Local policy authorities rule u l Users able to set up dynamic trust domains u Personal collection of resources working together based on trust of user Globus. WORLD 2004 Security: The Globus Perspective 15
Grid Solution: Use Virtual Organization as Bridge No Cross. Domain Trust Certification Authority Policy Authority Sub-Domain B 1 Sub-Domain A 1 Domain A Domain B Task Federation Service GSI Server X Globus. WORLD 2004 Virtual Organization Domain Server Y Security: The Globus Perspective 16
Effective Policy Governing Access Within A Collaboration Globus. WORLD 2004 Security: The Globus Perspective 17
Use Delegation to Establish Dynamic Distributed System Compute Center Service Rights VO Globus. WORLD 2004 Compute Center Security: The Globus Perspective 18
Goal is to do this with arbitrary mechanisms Compute Center X. 509 AC Service SAML Attribute Kerberos/ WS-Security Rights VO SAML Attribute Globus. WORLD 2004 X. 509 AC X. 509/SSL Compute Center Security: The Globus Perspective 19
Security of Grid 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 • Qo. S/Qo. P Negotiation and multi-level delegation Globus. WORLD 2004 Security: The Globus Perspective 20
Propagation of Requester’s 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 you… or let them come back with job specifics such that you can limit them Globus. WORLD 2004 Security: The Globus Perspective 21
Grid Security must address… l Trust between resources without organization support l Bridging differences between mechanisms u l Allow for controlled sharing of resources u l Delegation from site to VO Allow for coordination of shared resources u l Authentication, assertions, policy… Delegation from VO to users, users to resources . . . all with dynamic, distributed user communities and least privilege. Globus. WORLD 2004 Security: The Globus Perspective 22
Outline l Part One: Von Welch, NCSA l Security basics l What is Grid Security? What makes it different? l Current Grid Security l Part Two: Frank Siebenlist, ANL l OGSA Grid Evolution l OGSA Security and Web Services Security l Web Service Security Landscape l GT 3 Implementation and Futures Globus. WORLD 2004 Security: The Globus Perspective 23
Grid Security Infrastructure (GSI) l Use GSI as a standard mechanism for bridging disparate security mechanisms Doesn’t solve trust problem, but now things talk same protocol and understand each other’s identity credentials u Basic support for delegation, policy distribution u l l Translate from other mechanisms to/from GSI as needed Convert from GSI identity to local identity for authorization Globus. WORLD 2004 Security: The Globus Perspective 24
Grid Security Infrastructure (GSI) l Based on standard PKI technologies u u l CAs allow one-way, light-weight trust relationships (not just site-to-site) X. 509 Certificates for asserting identity u l SSL protocol for authentication, message protection for users, services, hosts, etc. Proxy Certificates u GSI extension to X. 509 certificates for delegation, single sign-on Globus. WORLD 2004 Security: The Globus Perspective 25
Grid Identity, Local Policy Map to local name • In current model, all Grid entities assigned a PKI identity. • User is mapped to local identities to determine local policy. Grid Identity Local Policy Map to local name . Local Policy Globus. WORLD 2004 Security: The Globus Perspective 26
Kerberos to GSI Gateway l To use Kerberos, a Kerberos-to-GSI gateway translates Kerberos credentials to GSI credentials to allow local Kerberos users to authenticate on the Grid. u l Kx 509/KCA is an implementation of one such gateway. Sslk 5/pkinit provide the opposite functionality to gateway incoming Grid credentials to local Kerberos credentials. Globus. WORLD 2004 Security: The Globus Perspective 27
Local Identity, Grid Identity, Local Policy Map to local name KCA Kerberos Site Grid Identity Local Policy SSLK 5 KRB 5 Resources Globus. WORLD 2004 Security: The Globus Perspective 28
GSI Implementation SSL/WS-Security with Proxy Services (running Certificates Authz Callout on user’s behalf) Access Compute Center Rights’’ CAS or VOMS issuing SAML or X. 509 ACs VO Users Rights Local Policy on VO identity or attribute authority Globus. WORLD 2004 My. Proxy VO Rights’ Security: The Globus Perspective KCA 29
X. 509 Proxy Certificates l GSI Extension to X. 509 Identity Certificates u On RFC track l Enables single sign-on l Allow user to dynamically assign identity and rights to service u l 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 u Services trust each other with user acting as the trust root Globus. WORLD 2004 Security: The Globus Perspective 30
Proxy Certificates Create Service CN=Jane Doe X. 509 Id certificate X. 509 Proxy Delegation CN=Jane Doe/9874 Rights: Can access file F 1, Service S 1, … X. 509 Proxy certificate F 1 Use delegated rights to access resources. S 1 Globus. WORLD 2004 Security: The Globus Perspective 31
Community Authorization Service l Question: How does a large community grant its users access to a large set of resources? l Community u. Outsource u. Enables Authorization Service (CAS) policy admin to VO sub-domain fine-grained policy l Resource owner sets course-grained policy rules foreign domain on “CAS-identity” l CAS sets policy rules for its local users l Requestors obtain capabilities from their local CAS that get enforced at the resource Globus. WORLD 2004 Security: The Globus Perspective 32
Community Authorization Service Domain A Domain B Sub-Domain B 1 Sub-Domain A 1 Community Authorization Svc Policy Authority CAS identity "trusted" enforcement on CAS-identity and requestor's capabilities capability assertions request + CAS assertions Requestor Globus. WORLD 2004 Server Virtual Organization Domain Security: The Globus Perspective 33
My. Proxy: Credential Wallet/Converter l My. Proxy allows users to store GSI credentials and retrieve them u u l 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 u Services limited by client implementations l l E. g. web portals Also handle credential renewal for long-running tasks Globus. WORLD 2004 Security: The Globus Perspective 34
My. Proxy: Passphrase-X. 509 Federation Service GSI Realm Username/pass phrase Domain My. Proxy GSI Delegation Username & pass phrase Requestor Web Browser request Web Portal/ Server GSI Grid Resource Globus. WORLD 2004 Security: The Globus Perspective 35
Beyond Local Identity for Authorization l Mapping to local identity works ok, but has limitations u l l l Scalability, granularity, consistency… Requirement for greater flexibility GT 2 has simple API callout to deploymenttime libraries/services GT 3 will implement standardized version based on GGF/OASIS work Globus. WORLD 2004 Security: The Globus Perspective 36
GT Authorization Callout Request Service A VO Authz Svc ? hz? ut Central Authz Svc Site VO Globus. WORLD 2004 Security: The Globus Perspective 37
Outline l Part One: Von Welch, NCSA l Security basics l What is Grid Security? What makes it different? l Current Grid Security l Part Two: Frank Siebenlist, ANL l OGSA Grid Evolution l OGSA Security and Web Services Security l Web Service Security Landscape l GT 3 Implementation and Futures Globus. WORLD 2004 Security: The Globus Perspective 38
Grid Evolution: Open Grid Services Architecture l Goals u u u l Refactor Globus protocol suite to enable common base and expose key capabilities Service orientation to virtualize resources and unify resources/services/information Embrace key Web services technologies for standard IDL, leverage commercial efforts Result = standard interfaces & behaviors for distributed system mgmt: the Grid service u Standardization within Global Grid Forum u Open source & commercial implementations Globus. WORLD 2004 Security: The Globus Perspective 39
The Grid Service = Interfaces/Behaviors + Service Data Service data access Explicit destruction Soft-state lifetime Binding properties: - Reliable invocation - Authentication Grid. Service (required) Service data element … other interfaces … (optional) Service data element Implementation Standard: - Notification - Authorization - Service creation - Service registry - Manageability - Concurrency + applicationspecific interfaces Hosting environment/runtime (“C”, J 2 EE, . NET, …) Globus. WORLD 2004 Security: The Globus Perspective 40
The Grid Service = EPR + resource. Id +Interfaces/Behaviors + Patterns + Properties WS-Addressing: EPR WS-Resource WSR-Reference. Properties: (required) resource. Id WS-Renewable. Reference WSR-Lifetime WS-Base. Fault WSR Property WS-Service. Group Binding properties: - Reliable invocation - Authentication … other interfaces … (optional) WSR Property Implementation Standard: - WS-Notification - Authorization - Service creation - Service registry - Manageability - Concurrency + applicationspecific interfaces Hosting environment/runtime (“C”, J 2 EE, . NET, …) Globus. WORLD 2004 Security: The Globus Perspective 41
Leverage existing/emerging Security Standards l l l WS-Security/Policy/Trust/Federation/ Authorization/Secure. Conversation/Privacy XKMS, XML-Signature/Encryption, SAML, XACML, Xr. ML But… u u u Need to OGSA’fy Need to define Profile/Mechanisms Need to define Naming conventions Need to address late/missing specs Support for delegation, transient services Globus. WORLD 2004 Security: The Globus Perspective 42
WS Security Current/proposed WSS-specs WS-Secure Conversation WS-Federation WS-Authorization WS-Policy WS-Trust WS-Privacy WS-Security In progress SOAP Foundation proposed promised Globus. WORLD 2004 Security: The Globus Perspective 43
Current/proposed specs Building on the SOAP Foundation WS-Security Today: describes SOAP extensions for secure messaging, provides foundation for other building blocks SOAP Foundation Globus. WORLD 2004 Security: The Globus Perspective 44
Current/proposed specs Building on the SOAP Foundation WS-Policy WS-Security SOAP Foundation Globus. WORLD 2004 Security: The Globus Perspective Today: how to express capabilities and constraints of security policies. Along with WSSecurity. Policy, WSPolicy. Asserts, WSPolicy. Attachment 45
Current/proposed specs Building on the SOAP Foundation WS-Policy WS-Trust WS-Security Today: describes the model for establishing both direct and brokered trust relationships (including third parties and intermediaries) SOAP Foundation Globus. WORLD 2004 Security: The Globus Perspective 46
Current/proposed specs Building on the SOAP Foundation WS-Secure Conversation WS-Policy WS-Trust WS-Security Today: how to manage and authenticate message exchanges between parties including security context exchange and establishing and deriving session keys SOAP Foundation Globus. WORLD 2004 Security: The Globus Perspective 47
Current/proposed specs Building on the SOAP Foundation WS-Secure Conversation WS-Policy WS-Trust WS-Privacy WS-Security Planned: will be a model for how users state privacy preferences, and for how Web Services state and implement privacy practices SOAP Foundation Globus. WORLD 2004 Security: The Globus Perspective 48
Current/proposed specs Building on the SOAP Foundation WS-Secure Conversation WS-Federation WS-Policy WS-Trust WS-Privacy WS-Security Planned: will describe how to manage and broker the trust relationships in a heterogeneous federated environment including support for federated identities SOAP Foundation Globus. WORLD 2004 Security: The Globus Perspective 49
Current/proposed specs Building on the SOAP Foundation WS-Secure Conversation WS-Policy WS-Federation WS-Authorization WS-Trust WS-Privacy Planned: will define how Web services manage authorization data and policies WS-Security SOAP Foundation Globus. WORLD 2004 Security: The Globus Perspective 50
WS Security Current/proposed WSS-specs WS-Secure Conversation WS-Federation WS-Authorization WS-Policy WS-Trust WS-Privacy WS-Security In progress SOAP Foundation proposed promised Globus. WORLD 2004 Security: The Globus Perspective 51
WS Security WS-Privacy (confusing picture) WS-Authorization WS-Federation Liberty Alliance WS-Secure Conversation WS-Trust WS-Policy-* XACML SAML WS-Security standardized In progress SOAP Foundation proposed promised Globus. WORLD 2004 Security: The Globus Perspective 52
How WS-Security “fits”… Domain A WS-Trust Sub-Domain B 1 Sub-Domain A 1 Community Authorization Svc Domain B Policy Authority CAS identity "trusted" enforcement on CAS-identity and requestor's capabilities capability assertions request + CAS assertions Requestor Server Virtual Organization Domain WS-Security, WS-Trust/Secure. Conversation, WS-Authorization/XACML/Xr. ML Globus. WORLD 2004 Security: The Globus Perspective 53
How WS-Security fits… l Plus WS-Policy/XACML/Xr. ML for expressing security constraints u u l Encryption supported? Required? Rejected? WS-Authorization/XACML/Xr. ML for managing authorization data u l What credentials (Kebreros, GSI) are accepted and preferred e. g. in CAS WS-Privacy (? ) for managing privacy Globus. WORLD 2004 Security: The Globus Perspective 54
What’s actually in GT 3? l l Leveraging SOAP, WS-Security (XML-Signature, XML-Encryption) for wire protocol Using our implementation of WSSecure. Conversation u u l l Designed before public specification Still doing SSL handshake, just doing it over SOAP Set up context and then use WS-Security (recently published WS-Security-Kerberos includes patterns that we may be able to use… but not standardized and depends on WSTrust/Secure. Conversation which are not standardized…when do we switch? ) Globus. WORLD 2004 Security: The Globus Perspective 55
Concerns about WS Security Specs (1) l Slooow submission & standardization of specs u l publish some specs, freeze the industry, and wait, wait… until momentum is lost (? ) IP and RF and RAND u Positive: most wss specs are submitted as RF u Clarifications take too long u Too many vendors involved with different T&Cs u Maybe authoring companies synchronize their lawyers and have single contracts… Globus. WORLD 2004 Security: The Globus Perspective 56
Concerns about WS Security Specs (2) l Interoperability u u WS-I: Hundred+ companies, hundreds of features with tens of implementations A permutation matrix nightmare… l But we really have to interoperate only with Microsoft’s… Alternative: u Open Source Reference Implementations l One from Microsoft and one from IBM u l l l (so we can finally help MS to debug their security code ; -) Saves enormous amount of money, time, agony, travel, meetings, money, lawyers, paper, bits, bandwidth, money… There is no money in plumbing anyway (as it will end up in the OS … anyway) All can concentrate on the added value on top Globus. WORLD 2004 Security: The Globus Perspective 57
OGSA Security Roadmap Goal l l Address the Grid Security Architecture Requirements Make Implementations Possible Address Interoperability Address Pluggability/Replaceability Address missing/late/insufficient Standards “OGSA Security Roadmap” submitted to GGF – co-authored with IBM Globus. WORLD 2004 Security: The Globus Perspective 58
OGSA Security l Security implemented by pluggable security services u l Usable by clients and services Allow for more agnostic approach to security mechanisms u u As implementations are created for a mechanism they can be plugged into existing tools to enable use. Applications and services can examine published security policies and convert/acquire credentials as needed Globus. WORLD 2004 Security: The Globus Perspective 59
OGSA Security Services Globus. WORLD 2004 Security: The Globus Perspective 60
Transport vs Message Protection Client SSL Application Router SSL context Client-application end-to-end context • SSL Security Context determined by endpoints of socket connection => Application Router becomes part of Trust Chain • Message level protection => end-to-end client-app security context (“tunneled” through the routing elements) Globus. WORLD 2004 Security: The Globus Perspective 61
GT 3 Secure Conversation: Context Establishment GSS-Token context Context Element Context Establishment Port. Type Impl. GSS-Token Client Context Element ws-stub context ws-stub App. port. Type Impl. • New security context is established if none exists • Dedicated context establishment port. Type • Transparent from client and service application Globus. WORLD 2004 Security: The Globus Perspective 62
GT 3 Secure Conversation: Message Protection Context Establishment Port. Type Impl. context Client App-msg SSign/SEnc ws-stub App-msg context ws-stub SSign/SEnc App. port. Type Impl. • Application messages protection through established context • Integrity and confidentiality protection through shared session key • Transparent from client and service application Globus. WORLD 2004 Security: The Globus Perspective 63
GT 3 Secure Conversation l Based on GT 2’s TLS/GSSAPI implementation l Based on a poor-man’s “interpretation” of WS-Trust/WS-Secure. Conversation specs plus XML-Signature/XML-Encryption/WS-Security l Waiting for WS-Trust & WS-Secure. Conversation & WSKerberos specs to be submitted to standards body l Need a standardized message-layer, session-based authentication and key-exchange protocol u l Maybe a GGSAPI-like equivalent, based on WS-Trust/WS-Secure. Conversation/XML-Signature/ XML-Encryption/WS-Security ? Work in GGF’s OGSA-Security on hold… Globus. WORLD 2004 Security: The Globus Perspective 64
Least Privilege l In Globus Toolkit implementation we follow least privilege model u l All code only has smallest amount of privileges required to do it’s job In GT 2 model, the Gatekeeper was the privileged piece of GRAM u u Had all privileges on local system Also acted as trust end-point for user by virtue of having access to host keys Globus. WORLD 2004 Security: The Globus Perspective 65
Trusted by server and user GT 2 GRAM Root est Requ nd e, espo ticat en te, R Auth ntica e Auth Requestor Gatekeeper Host Creds Server Invoke Job. Manager User Account Globus. WORLD 2004 Security: The Globus Perspective 66
GT 3 Least Privilege Model l GT 2 Model good, but u u l Gatekeeper accepts network connections - possible to attack Gatekeeper could be broken down into smaller pieces GT 3 model u u Make network services non-privileged Break up privileged pieces into smallest chunks of functionality with smallest privileges - 2 setuid programs: l l User Hosting Environment starter - starts pre-configured hosting environment for user GRIM - gets credentials for accounts to use to authenticate to requestors Globus. WORLD 2004 Security: The Globus Perspective 67
GT 3’s Resource Management • Job execution environments are created dynamically • Account credentials are derived dynamically from “host” creds • All trust derived from initial requester resource trust relationship • Resource policy enforcement through GRIM’s azn-assertions • Requester allows jobs to work on its behalf => issues azn-assertions Globus. WORLD 2004 Security: The Globus Perspective 68
GT 3 GRAM Globus account (non-privileged) Trusted by server MMJFS est qu d Re ne Sig Requestor Invoke Sig ned Root Res Host. Env Starter GRIM pon d Server Job. Manager GRIM Creds User Account Globus. WORLD 2004 Host Creds Security: The Globus Perspective Trusted by server 69
Dynamic Resource Management l Dynamic account/sandbox creation u X. 509 identity registration procedure doesn’t work… u Identity assertion not very useful… l Newly created key pair are “the” identity creds l Currently use proxy-certs to issue azn-assertions u GRIM asserts that requester can be trusted by account u GRIM asserts account can be trusted by requester u Requester asserts account can work on behalf of requester l Future: XACML policy statements wrapped in SAML authorization assertions on bare keys issued by more permanent identities like host-identity and requester l Leverage on GGF’s OGSA-Authorization WG work Globus. WORLD 2004 Security: The Globus Perspective 70
OGSA Authz Goals l Build on existing WS standards u l Support multiple mechanisms u l But specify set for interoperability Remove Authz from application u l SAML, XAMCL, WS Security Suite, Xr. ML, etc. Allow deployer to select Enable VO-driven policies u Limited delegation Globus. WORLD 2004 Security: The Globus Perspective 71
SAML and XACML l Standards from OASIS l SAML looks good for assertions l XACML as language for policy exchange? l Issues: u Don’t fit nicely together (NASA work). l u SAML 2. 0 will hopefully help. XACML delegation of rights? Globus. WORLD 2004 Security: The Globus Perspective 72
Remove Authz from Applications l l l Allow deployment-time selection of supported mechanisms and policies OGSA resource virtualization allows for policy on application-independent operation invocation Place as much security functionality as possible into sophisticated hosting environments Globus. WORLD 2004 Security: The Globus Perspective 73
Transparent Call-outs from WS-Stubs Globus. WORLD 2004 Security: The Globus Perspective 74
Enable VO/User-driven polices l Expressing delegation of policy space u l Trusts roots and their constraints Exchange of policy u u Assertions for simple statements XACML in SAML for more complicated policy exchanges? Globus. WORLD 2004 Security: The Globus Perspective 75
OGSA Security related activities in GGF l Global Grid Forum (GGF) l OGSA Security Working Group u l ogsa-sec-wg OGSA Authz WG u ogsa-authz-wg Globus. WORLD 2004 Security: The Globus Perspective 76
OGSA-sec-wg l Higher-level steering group for OGSA security activities l Creating OGSA Security Architecture and OGSA Security Roadmap l http: //www. cs. virginia. edu/~humphrey/ogsa-sec-wg/ l Hung up on past year by slow progress on WS Security suite Globus. WORLD 2004 Security: The Globus Perspective 77
OGSA-authz-wg l Specify: u u OGSA authz use cases/requirements Protocol/interface for OGSA service-to-PDP. At least one binding to real protocol or API. Assertions - what is needed for OGSA and VOs? At least one binding to real mechanism Language for OGSA authz policy Globus. WORLD 2004 Security: The Globus Perspective 78
OGSA-Authz-WG Goals Standardized Protocols and Interfaces Attribute Authority VOMS, CAS, Shib, etc Permis, Akenti, Cardea, etc. Authorization Decision Service (PDP) Allow push or pull. Globus. WORLD 2004 Security: The Globus Perspective App. Host. Env (PEP) 79
OGSI and resource. Id Resolution l End Point Reference + Reference. Property resource. Id u u u Grid Service Handle (GSH) Permanent network pointer to a Grid service URI scheme indicates resolution mechanism WS-Addressing: End Point Reference u u u l WS-Renewable. Reference u l Service port. Type to resolve GSH => GSR Service Locator structure u u l Grid Service Reference (GSR) Network endpoint info to access the service Binding-specific (for SOAP, GSR=WSDL doc) Includes service GSHs, GSRs and port. Types Factory/Find communicate Locators Enables transparent fail-over, load-balancing, (re-) activation, instance migration, moving services, etc. Globus. WORLD 2004 Security: The Globus Perspective 80
Service Migration Handle. Resolver Requester 4. find. By. Handle(GSH) GSH. . . GSR. . . hdl: 1. 2/abc <wsdl> . . . GSR <wsdl> Service Locator . . . 2. new network endpoint (GSR) registration for same GSH hdl: 1. 2/abc 5. new GSR with new network endpoint 6. successful access to moved service through new GSR Service 3. failed access with old network endpoint info (old GSR) Service 1. Service Migration Hosting Environment B Globus. WORLD 2004 Security: The Globus Perspective Hosting Environment A 81
Service Instance Migration and Security l Identity/Key “normally” associated with hosting environment and not with Instance u l What about policies for that instance? u u l Users that were allowed to access, can they still access moved instance? Hosting environment able to override (? ) Where to maintain policy info? u u l Moving instance => change of secure identity Maybe in same naming/registry svc? Move with instance state? Need more real-world requirements… u u Learn from mobile agent systems… No “real” efforts yet at GGF. Globus. WORLD 2004 Security: The Globus Perspective 82
OGSA/GT 3 Security Futures (1) l Authorization is “KEY” for the coming year u l VO Security Policy life-cycle framework u l Leverage authz policy work Message-based, context-based pure XML security protocols u l Includes communicating/sharing/matching of authzpolicies and capabilities Seems a missing link…(SSL/GSI will work for now) “Secure” Password/One-Time-Password authentication/key-exchange integration u Please let us get away from the clear-text passwords over SSL Globus. WORLD 2004 Security: The Globus Perspective 83
OGSA/GT 3 Security Futures (2) l Integration of Group authentication/key-exchange protocols u l Securely route through firewalls/network-hurdles u l Tackle the firewall/NAT traversal issues transparently in the runtime On-line Security “Policy” Registries u l Going from 2 parties to N parties should be “seamless” Policies, capabilities, attributes, assertions: we need real-time registries… Secure Logging and Audit u Another undefined, unstandardized missing link… while the requirements are there! Globus. WORLD 2004 Security: The Globus Perspective 84
Conclusion l Grid’s requirements maybe few years ahead, but industry will face same challenges soon u l Our security requirements are conceptually 1 -2 levels above what is available now as specifications, standards and open source u l And distracting and time consuming… Come help us at the Global Grid Forum u u l Ideally, we want to be end-users of WSS not plumbers… The standards circus is very worrisome u l Few “new” distributed computing requirements… Exciting security stuff! We need your help… (www. ggf. org) Play with the “secure” new Globus Toolkit (GT 3) u Downloaded 100 k+ times already Globus. WORLD 2004 (www. globus. org) Security: The Globus Perspective 85
Скачать презентацию Grid Security The Globus Perspective Frank Siebenlist ANL
cde91cd13e58a819e0944bc9878fd389.ppt