1. 1 Grid/OGSA Authorization: What is it. Where is it going. (And why) Von Welch welch@mcs.anl.gov Software Architect, Globus Project Internet2/Educause AdvancedCAMP

2. 2 Copyright Copyright Von Welch, 2003. This work is the intellectual property of the author. Permission is granted for this material to be shared for non- commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.

3. 3 Partial Acknowledgements Grid computing, Globus Project, and OGSA –Ian Foster @ UC/ANL, Carl Kesselman @ USC/ISI, Steve Tuecke @ ANL –Talented team of scientists and engineers at ANL, USC/ISI, elsewhere (see www.globus.org) Open Grid Services Architecture (OGSA) –Karl Czajkowski @ USC/ISI, Jeff Nick, Steve Graham, Jeff Frey @ IBM, Peter Vanderbilt @ NASA, David Snelling @ Fujitsu Labs (see www.globus.org/ogsa) Grid security, OGSA Security, CAS –Frank Siebenlist, Sam Meder @ ANL, Von Welch @ UC, Laura Pearlman @ ISI, Nataraj Nagaratnam, Philippe Janson, John Dayka, Anthony Nadalin @ IBM Support from DOE, NASA, NSF, IBM, Microsoft, Fujitsu

4. 4 Overview Level Set: –What are Grids? Virtual Organizations? –What is Grid Authorization? What is it today? OGSA Authorization –What is OGSA? –What is OGSA Authorization? –Areas for collaboration?

5. 5 The Grid World: Current Status Many major Grid projects in scientific & technical computing/research & education Open source Globus Toolkit® a de facto standard for major protocols & services –Simple protocols & APIs for authentication, discovery, access, etc.: infrastructure –Large user and developer base –Multiple commercial support providers Global Grid Forum: community & standards Emerging Open Grid Services Architecture

6. 6 World-view Differences Differences I’ve noticed talking to you… Our directories tend to be mainly for resources Web browsers and portals are on the edge of our world - clients rather than part of service Resource owners (and their funding agencies) drive policy and anonymous access is feared. –High LOA (CPs important)

7. 7 Grids: Resource Sharing Non-trivial Reservation/Scheduling Matching of available time-windows for: Data Source, Bandwidth, Input/Output Storage Allocation, CPU Cycles, … etc. Depends on Resource Capabilities Associated Job Directives Language & Scheduling It’s all part of QoS Negotiation…

8. 8 Grids: Resource Virtualization Discovery of and searching for Resources’ Capabilities and Availability Resource Capabilities: Amount of RAM/Storage/MFLOPS, # of CPUs, max. bandwidth,… etc. Use of actual Resources is “Virtualized” It’s all part of QoS Negotiation…

9. 9 What is a Grid? We believe there are three key criteria: –Coordinates resources that are not subject to centralized control … –using standard, open, general-purpose protocols and interfaces … –to deliver non-trivial qualities of service. What is not a Grid? –A cluster, a network attached storage device, a scientific instrument, a network, etc. –Each is an important component of a Grid, but by itself does not constitute a Grid

10. 10 Grids: Multiple Independent Orgs Each Organization enforces its own access policy Identity Federation + Authorization Assertions Trusted Third Parties It’s all part of QoS/QoP Negotiation… Requestor Scheduling Service Data Service Data Source Raw Data Bandwidth Service Compute Service Bandwidth Service XYZ Service Input Data Output Data Result Data Compute Facility Post-processing Facility

11. 11 Grids: Multiple Independent Orgs To achieve cooperation, resources must become part of a common policy domain While still remaining in their home domain Can be seen as policy domain overlay Requestor Scheduling Service Data Service Data Source Raw Data Bandwidth Service Compute Service Bandwidth Service XYZ Service Input Data Output Data Result Data Compute Facility Post-processing Facility

12. 12 Trust Mismatch Cross “Certification” Issue 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. 13 Cross-Certification Cross-certification at corporate level difficult –Legal implications, liability, bureaucracy ðAddress trust & policy at user/resource level! –Many business relationships do not require involvement of President/CEO … Virtual organization as bridge –Federate through mutually trusted services or entities –Local policy authorities rule … Assertions languages for trust relationships –WS-Trust, WS-Federation, WS-Policy, SAML, XACML

14. 14 Grid Solution: Use Virtual Organization as Bridge Certification Domain A common mechanism Certification Authority Sub-Domain B1 Authority Federation Service Virtual Organization Domain No Cross- Domain Trust

15. 15 VO Characteristics: Multi- Institutional VOs span multiple institutions There institutions have significant investments in security mechanisms Must with with, rather than replace these mechanisms Kerberos PKI

16. 16 VO Characteristics: Dynamic VO membership is dynamic Users, resources coming and going Entities being created –User processes –Stateful services 11010

17. 17 VOs can be long-lived… 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

18. 18 Or short-lived… Compute Muscle Special Processing Data Trust Work together. Please! Distributed job as a form of VO.

19. 19 VO members are not equal VO Developers Data Processors Users PIs Sub-projects Just like normal orgs., VOs tend to have different roles, subgroups, etc. These have different rights in the VO. Admins

20. 20 What is Grid Authorization? Level Set: –What are Grids? Virtual Organizations? –What is Grid Authorization? What is it today? OGSA Authorization –What is OGSA? –What is OGSA Authorization? –Areas for collaboration?

21. 21 What is Grid Authorization? Grid authorization hence is supporting the VO and dealing with its characteristics: –Dynamic membership and entities –Multi-institutional –Scalable –Allow controlled sharing

22. 22 Multiple Dynamic Policy Sources Outsourcing of subset of policy space to VO VOs: Who is a member? What is their role in VO? Users: Delegation of rights to other entities Resource owner: Who is trusted? How much? Others…

23. 23 Policies from User, Vo, Owner… 011101 User Process X Request Resource Process X can do A,BC as me User VO User is a member of VO and has privileges A,B,C,D,E … Resource Owner User must have signed AUP. VO may grant user rights for A-J Organization Sec. Office User must be US citizen

24. 24 Original implementation : Grid Identity, Local Policy Local Policy Map to local name Grid Identity In initial model (GT2), all Grid entities assigned a PKI identity. User is mapped to local identities to determine local policy. Need way to distribute VO information for multiple resources.

25. 25 Proxy Certificates Developed X.509 Proxy Certificates. Short-term binding of identity to new key pair. Enables SSO. Enables delegation to remote entities. Allows user to assert policy. 11010

26. 26 VO Policy Proxy Certificates allow users to distribute policy. How do VOs distribute policy? Two methods have emerged: –Directory method - distribute membership information directly to resources –Assertion method - user authenticates to authority and get tokens asserting membership, role, etc

27. 27 The Directory Approach VO Mappings Initial solution to the scalability problem was to have VOs distribute their own set of identity mappings Via LDAP or pushing User can only be part of one VO on a given resource

28. 28 Authz Authority Services: CAS, VOMS CAS VOMS Site User Member, Role, Rights… Custom Authz Code VO attribute authorities issuing membership/ role/entitlement assertions. Works well with current proxy certificates and SSO. Solves WAYF. Currently everyone is using custom assertion formats and authz code. VO

29. 29 Site Authz Policies Level of Assurance of authn –How did user authenticate to get Grid credentials? Did user hold a long-term private key? User must use OTP –Site policies on trusted CAs –Prohibited/allowed users Callout in Globus Toolkit to allow sites to plug in custom authz PDP

30. 30 OGSA - What is it? Level Set: –What are Grids? Virtual Organizations? –What is Grid Authorization? What is it today? OGSA Authorization –What is OGSA? –What is OGSA Authorization? –Areas for collaboration?

31. 31 Grid Evolution: OGSA (Open Grid Services Architecture) Goals –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, leverage commercial efforts Result = standard interfaces & behaviors for distributed system mgmt: the Grid Service –Standardization within Global Grid Forum –Open source & commercial implementations

32. 32 What are Web Services? A Web Service is a service whose interface can be described in a web services description language (WSDL) document Lots of “usually”s involved past that: SOAP, XML, etc. Implies a separation of application logic from getting bytes in/out of the logic –Operations described abstractly, supported bindings –Allow for selection of protocol(s) at deployment Binding by client as late as possible

33. 33 WSDL person status college … SOAP, SMTP, IPC, etc. http://myhost.example.com/student_service/ App. Logic Protocols (deployment specific) (profiles define how messages map) Service-specific address

34. 34 The Grid Service = Interfaces/Behaviors + Service Data (OGSA = WebServices on Steroids) 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, …) Support for stateful services

35. 35 Time Success/Maturity/Acceptance DCE CORBA WebServices OGSA + WebServices Silver Bullet Hype-Curve…

36. 36 GT3: Initial OGSA implementation Globus Toolkit v3.0 is implementation of OGSA Uses WS-Security for authentication and message protection Security contained in Axis handlers Still GT2-style identity-mapping for authorization

37. 37 What is OGSA Authz? Level Set: –What are Grids? Virtual Organizations? –What is Grid Authorization? What is it today? OGSA Authorization –What is OGSA? –What is OGSA Authorization? –Areas for collaboration?

38. 38 OGSA Authz Goals Build on existing WS standards –SAML, XAMCL, WS Security Suite, XrML, etc. Support multiple mechanisms –But specify set for interoperability Remove Authz from application –Allow deployer to select Enable VO-driven policies –Limited delegation

39. 39 SAML and XACML Standards from OASIS SAML looks good for assertions XACML as language for policy exchange? Issues: –Don’t fit nicely together (NASA work). SAML 2.0 will hopefully help. –IP

40. 40 WS Security Current/proposed WSS-specs (IBM/MS) (1 year ago) proposed SOAP Foundation WS-Security WS-PolicyWS-TrustWS-Privacy WS-SecureConversationWS-FederationWS-Authorization In progress promised

41. 41 WS Security Current/proposed WSS-specs (IBM/MS) (As of Tuesday) proposed SOAP Foundation WS-Security WS-PolicyWS-TrustWS-Privacy WS-SecureConversationWS-FederationWS-Authorization In progress promised

42. 42 Liberty Alliance, XrML ???

43. 43 Support for Multiple Mechanisms Assertions Policy Language Authorization protocol ? To allow for OGSA security to work in and with as many places as possible, the goal is to keep it as agnostic as possible to the underlying mechanisms.

44. 44 OGSA Authorization Interoperability ? To allow for interoperability, define a small set of concrete bindings to existing assertion formats, policy languages and protocols. Assertions Policy Authz Protocol

45. 45 Authorization Negotiation Security Requirements Trust roots Formats (ACs, SAML) Security Services (Credential convert, protocol translator, etc.) (WS-Trust, WS-Policy, GWSDL) Allow services to publish their requirements Users can examine and figure out if/how they can meet requirements Use security services to convert credential format, trust root, etc. SAML AC

46. 46 Remove Authz from Applications 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

47. 47 Enable VO/User-driven polices Expressing delegation of policy space –Trusts roots and their constraints Exchange of policy –Assertions for simple statements –XACML in SAML for more complicated policy exchanges?

48. 48 GGF Activities in OGSA Authz Global Grid Forum (GGF) OGSA Security Working Group (ogsa-sec- wg) Proposed OGSA Authz WG

49. 49 OGSA-sec-wg Higher-level steering group for OGSA security activitites Creating OGSA Security Architecture and OGSA Security Roadmap http://www.cs.virginia.edu/~humphrey/ogsa-sec-wg/ Hung up on past year by WS Security suite

50. 50 OGSA-authz-wg Proposed group in process of forming –David Chadwick (permis), Mary Thompson (akenti), Rebekah Lepro (cardea), Von Welch (globus), Andrew McNabb (voms), and others Scope carefully - focused on OGSA, use existing standards, so might actually succeed

51. 51 OGSA-authz-wg Specify: –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

52. 52 OGSA-Authz-WG Goals Host. Env (PEP) App. Attribute Authority Authorization Decision Service (PDP) Standardized Stuff VOMS, CAS, Shib, etc Permis, Akenti, Cardea, etc. Allow push or pull.

53. 53 Areas for Collaboration Level Set: –What are Grids? Virtual Organizations? –What is Grid Authorization? What is it today? OGSA Authorization –What is OGSA? –What is OGSA Authorization? –Areas for collaboration?

54. 54 Firewalls Can’t deal with N*N*… different firewall implementations… –No standards for discovery, configuration, etc. –Is it a firewall or a network failure? OGSA will help –standardize message formats and ports to allow better policy-based filtering (e.g. on identity of sender) –allow advertising firewall presence Can we standardize on interfaces for firewall configuration, discovery, …?

55. 55 Leverage Campus Auth[nz] Initial work with kx509/kca looks good Issue with leveraging campus auth[nz] is again that we cannot handle many different mechanisms –Shib/SAML emerging as a standard? –Scott’s example scenario very interesting –Client push model?

56. 56 Leverage Campus Auth[nz] How does VO interact with Org? –Not clear current Org attributes are meaningful, or at least sufficient, for many VOs –“Multi-attribute-provider” problem Bob mentioned –Can VO administer part of attribute space?

57. 57 XACML, SAML, WS-* Encourage development of good quality open source implementations Feedback to specifications to improve

58. 58 The End Questions? Arguments?