1. Grid Security: The Globus Perspective Frank Siebenlist (ANL) Von Welch (NCSA) GlobusWORLD 2004 http://www.globus.org/ Copyright (c) 2002 University of Chicago and The University of Southern California. All Rights Reserved. This 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.

2. GlobusWORLD 2004Security: The Globus Perspective2 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 GT3 Implementation and Futures

3. GlobusWORLD 2004Security: The Globus Perspective3 Security Terminology l Authentication: Establishing identity l Authorization: Establishing rights l Message protection u Message integrity u Message confidentiality l Digital signature l Auditing

4. GlobusWORLD 2004Security: The Globus Perspective4 Public Key Security Terminology l Private and Public Key l Certificate l Certificate Authority (CA) l Public Key Insfrastructure (PKI)

5. GlobusWORLD 2004Security: The Globus Perspective5 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 l So Grid Security is security to enable VOs l What is needed in terms of security for a VO?

6. GlobusWORLD 2004Security: The Globus Perspective6 LHC Data Distribution Tier2 Centre ~1 TIPS Online System Offline Processor Farm ~20 TIPS CERN Computer Centre FermiLab ~4 TIPSFrance Regional Centre Italy Regional Centre Germany Regional Centre Institute Institute ~0.25TIPS Physicist workstations ~100 MBytes/sec ~622 Mbits/sec ~1 MBytes/sec There is a “bunch crossing” every 25 nsecs. There are 100 “triggers” per second Each triggered event is ~1 MByte in size 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 Physics data cache ~PBytes/sec ~622 Mbits/sec or Air Freight (deprecated) Tier2 Centre ~1 TIPS Caltech ~1 TIPS ~622 Mbits/sec Tier 0 Tier 1 Tier 2 Tier 4 1 TIPS is approximately 25,000 SpecInt95 equivalents

7. GlobusWORLD 2004Security: The Globus Perspective7 Resource Sharing “…coordinated resource sharing and problem solving in dynamic, multi- institutional virtual organizations.” l Resources being used are still owned by their respective organization and subject to its policies u Sharing may be controlled amongst a number of VOs u Non-trivial policy in regards to QoS, QoP, etc.

8. GlobusWORLD 2004Security: The Globus Perspective8 Controlled Resource Sharing Compute Center HEP VO Chem Eng VO BIO VO 5pm-9am only 20 Tflops per month max 100 Tbytes max 20 Mbytes/sec max Globally: User must agree to AUP User must use strong authentication

9. GlobusWORLD 2004Security: The Globus Perspective9 Requires Coordination by VO “…coordinated resource sharing and problem solving in dynamic, multi- institutional virtual organizations.” l Resources contributed to VO need to be coordinated by the VO in order to work together effectively. u All need to have a coherent policy in order to interoperate u Requires policy from VO back to resources

10. GlobusWORLD 2004Security: The Globus Perspective10 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

11. GlobusWORLD 2004Security: The Globus Perspective11 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

12. GlobusWORLD 2004Security: The Globus Perspective12 Trust Mismatch Mechanism Mismatch Multi-Institution Issues Certification Authority Certification Authority Domain A Server X Server Y Policy Authority Policy Authority Task Domain B Sub-Domain A1 Sub-Domain B1 No Cross- Domain Trust

13. GlobusWORLD 2004Security: The Globus Perspective13 Why Grid Security is Hard l Resources being used may be valuable & the problems being solved sensitive u Both users and resources need to be careful l Dynamic formation and management of virtual organizations (VOs) u Large, dynamic, unpredictable… l VO Resources and users are often located in distinct administrative domains u Can’t assume cross-organizational trust agreements u Different mechanisms & credentials l X.509 vs Kerberos, SSL vs GSSAPI, X.509 vs. X.509 (different domains), l X.509 attribute certs vs SAML assertions

14. GlobusWORLD 2004Security: The Globus Perspective14 Why Grid Security is Hard… l Interactions are not just client/server, but service-to-service on behalf of the user u Requires delegation of rights by user to service u Services may be dynamically instantiated l Standardization of interfaces to allow for discovery, negotiation and use l Implementation must be broadly available & applicable u Standard, well-tested, well-understood protocols; integrated with wide variety of tools l Policy from sites, VO, users need to be combined u Varying formats l Want to hide as much as possible from applications!

15. GlobusWORLD 2004Security: The Globus Perspective15 The Grid Trust solution 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 l Virtual Organizations (VOs) for multi-user collaborations u Federate through mutually trusted services u Local policy authorities rule l Users able to set up dynamic trust domains u Personal collection of resources working together based on trust of user

16. GlobusWORLD 2004Security: The Globus Perspective16 Grid Solution: Use Virtual Organization as Bridge Certification Domain A GSI Certification Authority Sub-Domain B1 Authority Federation Service Virtual Organization Domain No Cross- Domain Trust

17. GlobusWORLD 2004Security: The Globus Perspective17 Effective Policy Governing Access Within A Collaboration

18. GlobusWORLD 2004Security: The Globus Perspective18 Use Delegation to Establish Dynamic Distributed System Compute Center VO Rights Compute Center Service

19. GlobusWORLD 2004Security: The Globus Perspective19 Goal is to do this with arbitrary mechanisms Compute Center VO Rights Compute Center Service Kerberos/ WS-Security X.509/SSL SAML Attribute X.509 AC SAML Attribute X.509 AC

20. GlobusWORLD 2004Security: The Globus Perspective20 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 QoS/QoP Negotiation and multi-level delegation

21. GlobusWORLD 2004Security: The Globus Perspective21 Propagation of Requester’s Rights through Job Scheduling and Submission Process 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

22. GlobusWORLD 2004Security: The Globus Perspective22 Grid Security must address… l Trust between resources without organization support l Bridging differences between mechanisms u Authentication, assertions, policy… l Allow for controlled sharing of resources u Delegation from site to VO l Allow for coordination of shared resources u Delegation from VO to users, users to resources l...all with dynamic, distributed user communities and least privilege.

23. GlobusWORLD 2004Security: The Globus Perspective23 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 GT3 Implementation and Futures

24. GlobusWORLD 2004Security: The Globus Perspective24 Grid Security Infrastructure (GSI) l Use GSI as a standard mechanism for bridging disparate security mechanisms u 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 l Translate from other mechanisms to/from GSI as needed l Convert from GSI identity to local identity for authorization

25. GlobusWORLD 2004Security: The Globus Perspective25 Grid Security Infrastructure (GSI) l Based on standard PKI technologies u SSL protocol for authentication, message protection u CAs allow one-way, light-weight trust relationships (not just site-to-site) l X.509 Certificates for asserting identity u for users, services, hosts, etc. l Proxy Certificates u GSI extension to X.509 certificates for delegation, single sign-on

26. GlobusWORLD 2004Security: The Globus Perspective26 Grid Identity, Local Policy Local Policy Map to local name Grid Identity In current model, all Grid entities assigned a PKI identity. User is mapped to local identities to determine local policy..

27. GlobusWORLD 2004Security: The Globus Perspective27 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 Kx509/KCA is an implementation of one such gateway. l Sslk5/pkinit provide the opposite functionality to gateway incoming Grid credentials to local Kerberos credentials.

28. GlobusWORLD 2004Security: The Globus Perspective28 Local Identity, Grid Identity, Local Policy Local Policy Map to local name Grid Identity Kerberos Site KCA SSLK5 KRB5 Resources

29. GlobusWORLD 2004Security: The Globus Perspective29 GSI Implementation Compute Center VO Rights VO Users Services (running on user’s behalf) Rights’’ Rights’ Access Local Policy on VO identity or attribute authority CAS or VOMS issuing SAML or X.509 ACs SSL/WS-Security with Proxy Certificates Authz Callout KCA MyProxy

30. GlobusWORLD 2004Security: The Globus Perspective30 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 Can name services created on the fly and give them rights (i.e. set policy) l 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

31. GlobusWORLD 2004Security: The Globus Perspective31 Proxy Certificates Service CN=Jane Doe/9874 Rights: Can access file F1, Service S1, … CN=Jane Doe X.509 Proxy Delegation S1 F1 Use delegated rights to access resources. X.509 Id certificate X.509 Proxy certificate Create

32. GlobusWORLD 2004Security: The Globus Perspective32 Community Authorization Service l Question: How does a large community grant its users access to a large set of resources? l Community Authorization Service (CAS) u Outsource policy admin to VO sub-domain u Enables fine-grained policy l Resource owner sets course-grained policy rules for 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

33. GlobusWORLD 2004Security: The Globus Perspective33 Community Authorization Service Domain A Policy Authority Domain B Sub-Domain A1 Sub-Domain B1 CAS identity "trusted" Requestor Server request + CAS assertions Virtual Organization Domain capability assertions Community Authorization Svc enforcement on CAS-identity and requestor's capabilities

34. GlobusWORLD 2004Security: The Globus Perspective34 MyProxy: Credential Wallet/Converter l MyProxy allows users to store GSI credentials and retrieve them u With username/pass phrase or other credential u Can act as a credential translator from username/passphrase to GSI l Used by services that can only handle username and pass phrases to authenticate to Grid u Services limited by client implementations l E.g. web portals l Also handle credential renewal for long-running tasks

35. GlobusWORLD 2004Security: The Globus Perspective35 MyProxy: Passphrase-X.509 Federation Service GSI RealmUsername/pass phrase Domain GSI Delegation Username & pass phrase GSI Delegation GSI Web Browser request

36. GlobusWORLD 2004Security: The Globus Perspective36 Beyond Local Identity for Authorization l Mapping to local identity works ok, but has limitations u Scalability, granularity, consistency… l Requirement for greater flexibility l GT2 has simple API callout to deployment- time libraries/services l GT3 will implement standardized version based on GGF/OASIS work

37. GlobusWORLD 2004Security: The Globus Perspective37 GT Authorization Callout Service Central Authz Svc VO Site VO Authz Svc Request ? Authz?

38. GlobusWORLD 2004Security: The Globus Perspective38 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 GT3 Implementation and Futures

39. GlobusWORLD 2004Security: The Globus Perspective39 Grid Evolution: Open Grid Services Architecture l Goals u Refactor Globus protocol suite to enable common base and expose key capabilities u Service orientation to virtualize resources and unify resources/services/information u Embrace key Web services technologies for standard IDL, leverage commercial efforts l Result = standard interfaces & behaviors for distributed system mgmt: the Grid service u Standardization within Global Grid Forum u Open source & commercial implementations

40. GlobusWORLD 2004Security: The Globus Perspective40 The Grid Service = Interfaces/Behaviors + Service Data Service data element Service data element Service data element Implementation GridService (required) Service data access Explicit destruction Soft-state lifetime … other interfaces … (optional) Standard: - Notification - Authorization - Service creation - Service registry - Manageability - Concurrency + application- specific interfaces Binding properties: - Reliable invocation - Authentication Hosting environment/runtime (“C”, J2EE,.NET, …)

41. GlobusWORLD 2004Security: The Globus Perspective41 The Grid Service = EPR + resourceId +Interfaces/Behaviors + Patterns + Properties WSR Property WSR Property WSR Property Implementation WS-Resource (required) WS-Addressing: EPR WSR-ReferenceProperties: resourceId WS-RenewableReference WSR-Lifetime WS-BaseFault WS-ServiceGroup … other interfaces … (optional) Standard: - WS-Notification - Authorization - Service creation - Service registry - Manageability - Concurrency + application- specific interfaces Binding properties: - Reliable invocation - Authentication Hosting environment/runtime (“C”, J2EE,.NET, …)

42. GlobusWORLD 2004Security: The Globus Perspective42 Leverage existing/emerging Security Standards l WS-Security/Policy/Trust/Federation/ Authorization/SecureConversation/Privacy l XKMS, XML-Signature/Encryption, SAML, XACML, XrML l But… u Need to OGSA’fy u Need to define Profile/Mechanisms u Need to define Naming conventions u Need to address late/missing specs u Support for delegation, transient services

43. GlobusWORLD 2004Security: The Globus Perspective43 WS Security Current/proposed WSS-specs proposed SOAP Foundation WS-Security WS-PolicyWS-TrustWS-Privacy WS-SecureConversationWS-Authorization In progress promised WS-Federation

44. GlobusWORLD 2004Security: The Globus Perspective44 Current/proposed specs Building on the SOAP Foundation Today: describes SOAP extensions for secure messaging, provides foundation for other building blocks SOAP Foundation WS-Security

45. GlobusWORLD 2004Security: The Globus Perspective45 Current/proposed specs Building on the SOAP Foundation Today: how to express capabilities and constraints of security policies. Along with WS- SecurityPolicy, WS- PolicyAsserts, WS- PolicyAttachment SOAP Foundation WS-Security WS-Policy

46. GlobusWORLD 2004Security: The Globus Perspective46 Current/proposed specs Building on the SOAP Foundation Today:describes the model for establishing both direct and brokered trust relationships (including third parties and intermediaries) Today: describes the model for establishing both direct and brokered trust relationships (including third parties and intermediaries) SOAP Foundation WS-Security WS-PolicyWS-Trust

47. GlobusWORLD 2004Security: The Globus Perspective47 Current/proposed specs Building on the SOAP Foundation Today:how to manage and authenticate message exchanges between parties including security context exchange and establishing and deriving session keys Today: how to manage and authenticate message exchanges between parties including security context exchange and establishing and deriving session keys SOAP Foundation WS-Security WS-PolicyWS-Trust WS-SecureConversation

48. GlobusWORLD 2004Security: The Globus Perspective48 Current/proposed specs Building on the SOAP Foundation Planned:will be a model for how users state privacy preferences, and for how Web Services state and implement privacy practices Planned: will be a model for how users state privacy preferences, and for how Web Services state and implement privacy practices SOAP Foundation WS-Security WS-PolicyWS-TrustWS-Privacy WS-SecureConversation

49. GlobusWORLD 2004Security: The Globus Perspective49 Current/proposed specs Building on the SOAP Foundation Planned:will describe how to manage and broker the trust relationships in a heterogeneous federated environment including support for federated identities Planned: will describe how to manage and broker the trust relationships in a heterogeneous federated environment including support for federated identities SOAP Foundation WS-Security WS-PolicyWS-TrustWS-Privacy WS-SecureConversationWS-Federation

50. GlobusWORLD 2004Security: The Globus Perspective50 Current/proposed specs Building on the SOAP Foundation Planned:will define how Web services manage authorization data and policies Planned: will define how Web services manage authorization data and policies SOAP Foundation WS-Security WS-PolicyWS-TrustWS-Privacy WS-SecureConversationWS-FederationWS-Authorization

51. GlobusWORLD 2004Security: The Globus Perspective51 WS Security Current/proposed WSS-specs proposed SOAP Foundation WS-Security WS-PolicyWS-TrustWS-Privacy WS-SecureConversationWS-Authorization In progress promised WS-Federation

52. GlobusWORLD 2004Security: The Globus Perspective52 WS Security (confusing picture) proposed SOAP Foundation WS-Security WS-Privacy WS-SecureConversation WS-Federation WS-Authorization In progress promised SAML Liberty Alliance WS-Trust WS-Policy-* XACML standardized

53. GlobusWORLD 2004Security: The Globus Perspective53 How WS-Security “fits”… Domain A Policy Authority Domain B Sub-Domain A1 Sub-Domain B1 CAS identity "trusted" Requestor Server request + CAS assertions Virtual Organization Domain capability assertions Community Authorization Svc enforcement on CAS-identity and requestor's capabilities WS-Trust WS-Security, WS-Trust/SecureConversation, WS-Authorization/XACML/XrML

54. GlobusWORLD 2004Security: The Globus Perspective54 How WS-Security fits… l Plus WS-Policy/XACML/XrML for expressing security constraints u What credentials (Kebreros, GSI) are accepted and preferred u Encryption supported? Required? Rejected? l WS-Authorization/XACML/XrML for managing authorization data u e.g. in CAS l WS-Privacy (?) for managing privacy

55. GlobusWORLD 2004Security: The Globus Perspective55 What’s actually in GT3? l Leveraging SOAP, WS-Security (XML-Signature, XML-Encryption) for wire protocol l Using our implementation of WS- SecureConversation u Designed before public specification u Still doing SSL handshake, just doing it over SOAP l Set up context and then use WS-Security l (recently published WS-Security-Kerberos includes patterns that we may be able to use… but not standardized and depends on WS- Trust/SecureConversation which are not standardized…when do we switch?)

56. GlobusWORLD 2004Security: The Globus Perspective56 Concerns about WS Security Specs (1) l Slooow submission & standardization of specs u publish some specs, freeze the industry, and wait, wait, wait… until momentum is lost (?) l 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…

57. GlobusWORLD 2004Security: The Globus Perspective57 Concerns about WS Security Specs (2) l Interoperability u WS-I: Hundred+ companies, hundreds of features with tens of implementations u 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 (so we can finally help MS to debug their security code ;-) l Saves enormous amount of money, time, agony, travel, meetings, money, lawyers, paper, bits, bandwidth, money… l There is no money in plumbing anyway (as it will end up in the OS … anyway) l All can concentrate on the added value on top

58. GlobusWORLD 2004Security: The Globus Perspective58 OGSA Security Roadmap Goal l Address the Grid Security Architecture Requirements l Make Implementations Possible l Address Interoperability l Address Pluggability/Replaceability l Address missing/late/insufficient Standards “OGSA Security Roadmap” submitted to GGF – co-authored with IBM

59. GlobusWORLD 2004Security: The Globus Perspective59 OGSA Security l Security implemented by pluggable security services u Usable by clients and services l Allow for more agnostic approach to security mechanisms u As implementations are created for a mechanism they can be plugged into existing tools to enable use. u Applications and services can examine published security policies and convert/acquire credentials as needed

60. GlobusWORLD 2004Security: The Globus Perspective60 OGSA Security Services

61. GlobusWORLD 2004Security: The Globus Perspective61 Transport vs Message Protection 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) Application Router Client SSL SSL context Client-application end-to-end context

62. GlobusWORLD 2004Security: The Globus Perspective62 ws-stub Context Element GT3 Secure Conversation: Context Establishment GSS-Token Context Establishment PortType Impl. context App. portType Impl. Client ws-stub Context Element GSS-Token context New security context is established if none exists Dedicated context establishment portType Transparent from client and service application

63. GlobusWORLD 2004Security: The Globus Perspective63 ws-stub SSign/SEnc GT3 Secure Conversation: Message Protection App-msg Context Establishment PortType Impl. context App. portType Impl. Client ws-stub SSign/SEnc App-msg context Application messages protection through established context Integrity and confidentiality protection through shared session key Transparent from client and service application

64. GlobusWORLD 2004Security: The Globus Perspective64 GT3 Secure Conversation l Based on GT2’s TLS/GSSAPI implementation l Based on a poor-man’s “interpretation” of WS-Trust/WS-SecureConversation specs plus XML-Signature/XML-Encryption/WS-Security l Waiting for WS-Trust & WS-SecureConversation & WS- Kerberos specs to be submitted to standards body l Need a standardized message-layer, session-based authentication and key-exchange protocol u Maybe a GGSAPI-like equivalent, based on WS-Trust/WS-SecureConversation/XML-Signature/ XML-Encryption/WS-Security ? l Work in GGF’s OGSA-Security on hold…

65. GlobusWORLD 2004Security: The Globus Perspective65 Least Privilege l In Globus Toolkit implementation we follow least privilege model u All code only has smallest amount of privileges required to do it’s job l In GT2 model, the Gatekeeper was the privileged piece of GRAM u Had all privileges on local system u Also acted as trust end-point for user by virtue of having access to host keys

66. GlobusWORLD 2004Security: The Globus Perspective66 GT2 GRAM Requestor Root Gatekeeper User Account Server Host Creds Authenticate, Request Authenticate, Respond JobManager Invoke Trusted by server and user

67. GlobusWORLD 2004Security: The Globus Perspective67 GT3 Least Privilege Model l GT2 Model good, but u Gatekeeper accepts network connections - possible to attack u Gatekeeper could be broken down into smaller pieces l GT3 model u Make network services non-privileged u Break up privileged pieces into smallest chunks of functionality with smallest privileges - 2 setuid programs: l User Hosting Environment starter - starts pre-configured hosting environment for user l GRIM - gets credentials for accounts to use to authenticate to requestors

68. GlobusWORLD 2004Security: The Globus Perspective68 GT3’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

69. GlobusWORLD 2004Security: The Globus Perspective69 GT3 GRAM Requestor Globus account (non-privileged) MMJFS User Account Server Host Creds Signed Request Signed Respond JobManager Invoke HostEnv Starter Root GRIM GRIM Creds Trusted by server Trusted by server

70. GlobusWORLD 2004Security: The Globus Perspective70 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

71. GlobusWORLD 2004Security: The Globus Perspective71 OGSA Authz Goals l Build on existing WS standards u SAML, XAMCL, WS Security Suite, XrML, etc. l Support multiple mechanisms u But specify set for interoperability l Remove Authz from application u Allow deployer to select l Enable VO-driven policies u Limited delegation

72. GlobusWORLD 2004Security: The Globus Perspective72 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 SAML 2.0 will hopefully help. u XACML delegation of rights?

73. GlobusWORLD 2004Security: The Globus Perspective73 Remove Authz from Applications l Allow deployment-time selection of supported mechanisms and policies l OGSA resource virtualization allows for policy on application-independent operation invocation l Place as much security functionality as possible into sophisticated hosting environments

74. GlobusWORLD 2004Security: The Globus Perspective74 Transparent Call-outs from WS-Stubs

75. GlobusWORLD 2004Security: The Globus Perspective75 Enable VO/User-driven polices l Expressing delegation of policy space u Trusts roots and their constraints l Exchange of policy u Assertions for simple statements u XACML in SAML for more complicated policy exchanges?

76. GlobusWORLD 2004Security: The Globus Perspective76 OGSA Security related activities in GGF l Global Grid Forum (GGF) l OGSA Security Working Group u ogsa-sec-wg l OGSA Authz WG u ogsa-authz-wg

77. GlobusWORLD 2004Security: The Globus Perspective77 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

78. GlobusWORLD 2004Security: The Globus Perspective78 OGSA-authz-wg l Specify: u OGSA authz use cases/requirements u Protocol/interface for OGSA service-to-PDP. At least one binding to real protocol or API. u Assertions - what is needed for OGSA and VOs? At least one binding to real mechanism u Language for OGSA authz policy

79. GlobusWORLD 2004Security: The Globus Perspective79 OGSA-Authz-WG Goals Host. Env (PEP) App. Attribute Authority Authorization Decision Service (PDP) Standardized Protocols and Interfaces VOMS, CAS, Shib, etc Permis, Akenti, Cardea, etc. Allow push or pull.

80. GlobusWORLD 2004Security: The Globus Perspective80 OGSI and resourceId Resolution l End Point Reference + ReferenceProperty resourceId u Grid Service Handle (GSH) u Permanent network pointer to a Grid service u URI scheme indicates resolution mechanism WS-Addressing: End Point Reference u Grid Service Reference (GSR) u Network endpoint info to access the service u Binding-specific (for SOAP, GSR=WSDL doc) l WS-RenewableReference u Service portType to resolve GSH => GSR l Service Locator structure u Includes service GSHs, GSRs and portTypes u Factory/Find communicate Locators l Enables transparent fail-over, load-balancing, (re-) activation, instance migration, moving services, etc.

81. GlobusWORLD 2004Security: The Globus Perspective81 Service Migration Hosting Environment B GSH... hdl:1.2/abc... GSR...... Service Hosting Environment A Service 1. Service Migration Requester HandleResolver 2. new network endpoint (GSR) registration for same GSH 3. failed access with old network endpoint info (old GSR) 6. successful access to moved service through new GSR 5. new GSR with new network endpoint 4. findByHandle(GSH) GSH hdl:1.2/abc GSR Service Locator

82. GlobusWORLD 2004Security: The Globus Perspective82 Service Instance Migration and Security l Identity/Key “normally” associated with hosting environment and not with Instance u Moving instance => change of secure identity l What about policies for that instance? u Users that were allowed to access, can they still access moved instance? u Hosting environment able to override (?) l Where to maintain policy info? u Maybe in same naming/registry svc? u Move with instance state? l Need more real-world requirements… u Learn from mobile agent systems… u No “real” efforts yet at GGF.

83. GlobusWORLD 2004Security: The Globus Perspective83 OGSA/GT3 Security Futures (1) l Authorization is “KEY” for the coming year u Includes communicating/sharing/matching of authz- policies and capabilities l VO Security Policy life-cycle framework u Leverage authz policy work l Message-based, context-based pure XML security protocols u Seems a missing link…(SSL/GSI will work for now) l “Secure” Password/One-Time-Password authentication/key-exchange integration u Please let us get away from the clear-text passwords over SSL

84. GlobusWORLD 2004Security: The Globus Perspective84 OGSA/GT3 Security Futures (2) l Integration of Group authentication/key-exchange protocols u Going from 2 parties to N parties should be “seamless” l Securely route through firewalls/network-hurdles u Tackle the firewall/NAT traversal issues transparently in the runtime l On-line Security “Policy” Registries u Policies, capabilities, attributes, assertions: we need real-time registries… l Secure Logging and Audit u Another undefined, unstandardized missing link… while the requirements are there!

85. GlobusWORLD 2004Security: The Globus Perspective85 Conclusion l Grid’s requirements maybe few years ahead, but industry will face same challenges soon u Few “new” distributed computing requirements… l Our security requirements are conceptually 1-2 levels above what is available now as specifications, standards and open source u Ideally, we want to be end-users of WSS not plumbers… l The standards circus is very worrisome u And distracting and time consuming… l Come help us at the Global Grid Forum u Exciting security stuff! u We need your help… (www.ggf.org)www.ggf.org l Play with the “secure” new Globus Toolkit (GT3) u Downloaded 100k+ times already (www.globus.org)