Presentation is loading. Please wait.

Presentation is loading. Please wait.

The Earth System Grid ----- Security to enable Access Frank Siebenlist Argonne National Laboratory / University of Chicago NSF Cybersecurity.

Similar presentations


Presentation on theme: "The Earth System Grid ----- Security to enable Access Frank Siebenlist Argonne National Laboratory / University of Chicago NSF Cybersecurity."— Presentation transcript:

1 The Earth System Grid Security to enable Access Frank Siebenlist Argonne National Laboratory / University of Chicago NSF Cybersecurity Summit 2007; Arlington, VA - Feb 22-23, 2007

2 Making Climate Simulation Data Available Globally PMEL ESG Computational/Data Sites and Collaborators

3 The ESG Tea m ANL - Ian T. Foster (PI) - Frank Siebenlist - Dan Fraser - Veronika Nefedova LBNL - Arie Shoshani - Alex Sim - Alex Romosan LANL - Phil Jones LLNL/PCMDI - Dean Williams (PI) - Bob Drach NCAR - David Brown - Luca Cinquini - Peter Fox - Jose’ Garcia - Rob Markel - Don Middleton (PI) - Gary Strand ORNL - Dave Bernholdt - Mei-Li Chen - Line Pouchard NOAA/PMEL - Steve Hankin - Roland Schweitzer USC/ISI - Ann Chervenak - Carl Kesselman - Rob Schuler

4 ESG Architectur e

5 ESG Portal

6 An Operational DataGrid for Climate Research

7 An Operational DataGrid for IPCC

8 Authentication Authorization Accounting/Metrics

9

10 Virtual Data Services

11 Moving Many Files: DML

12 A Few Metrics ESG General Climate Portal 4,000 registrations 160 TB of data available, 876 datasets and 840,000 files 30 TB downloaded in 92K files + virtual data services ESG IPCC Portal (U.S. Intergovernmental Panel on Climate Change (IPCC)) 1000 registered users 35 TB of data available in 67K files 125 TB downloaded in 548K files

13 1/10d POP Ocean Model MOZART Chemistry Model Towards Global Earth System Modeling CCM3 at T170 Resolution (about 70km)

14 ESG PMEL

15 Inside SAN + MSS RAID + HPSS InsideInside TeraGrid

16 The Earth System Grid Center for Enabling Technologies Petascale distributed climate data Global Grid of data producers (IPCC) Model experiment environment Analysis services (online & archive) ESG-enabled analysis and visualization tools Funded for

17

18 …ESG Security… …in process of architecting next phase… reporting on design choices/challenges

19 19 Resource “Client => Portal => Resource” Access browser Client Portal

20 20 Resource “Client => Portal => Resource” Access as Portal-ID browser Client Portal Portal AuthN & AuthZ Client AuthN Client AuthZ As Portal-ID Resource only sees/knows AuthN’ed Portal-ID Resource does not “know” Client-ID Resource enforces only Portal-ID access policy Fine-grained client AuthZ determined/enforced at Portal (Client-ID only for audit)

21 21 Resource “Client => Portal => Resource” Access as Portal-ID on behalf of Client-ID browser Client Portal Portal AuthN AuthZ & Client AuthZ Client AuthN Client AuthZ Client-ID As Portal-ID on behalf of Client-ID Resource sees AuthN’ed Portal-ID Resource sees UnAuthN’ed Client-ID Resource trusts Portal-ID to forward Client’s request No “cryptographic proof” of delegation Client’s AuthZ determined/enforced at Resource (Client’s AuthZ also determined/enforced at Portal)

22 22 Resource “Client => Portal => Resource” Access as Portal impersonating Client-ID browser Client Portal Client AuthN & AuthZ Client AuthN Client Creds Client Creds Svc Client AuthZ As Client-ID through Impersonation Portal maintains client’s (proxy-)credentials Resource only sees Client-ID Client’s AuthZ determined/enforced at Resource (Portal-ID only for audit)

23 23 “Portal => Resource” Access Methods l As Portal-ID u Resource only sees/knows AuthN’ed Portal-ID u Resource enforces only Portal-ID access policy u All fine-grained client AuthZ determined/enforced at Portal l As Portal-ID on behalf of Client-ID u Resource sees AuthN’ed Portal-ID u Resource trusts Portal-ID to forward Client’s request u Client’s AuthZ determined/enforced at Resource l As Client-ID through Impersonation u Portal maintains client’s (proxy-)credentials u Resource only sees Client-ID u Client’s AuthZ determined/enforced at Resource l As Portal-ID through fine-grained Delegation u Resource sees AuthN’ed Portal-ID u Client-ID’s AuthZ assertion empowers Portal-ID u Portal’s rights at Resource limited by Client’s

24 24 Light and Fat-Client Access browser Client Portal Resource Portal AuthN & AuthZ Client AuthN Client AuthZ “Fat” Client Resource Client AuthN & AuthZ Reuse Portal’s AuthZ through push/pull Obtain data’s URI after browsing GridFTP, OpenDAP, SRM, ws-transfer, ???

25 25 Access Policy Taxonomy (1) “Physical” User, AuthN-ID, DN, Username Operation/Action Identity-based, ACL-like, most simple policy statement Permission Permit | Deny | NotApplicable “Physical” Resource, FileName, URL, FQN PUser | Op | Perm | PRsrc

26 26 Access Policy Taxonomy (2) “Physical” User, AuthN-ID, DN, Username Grouping Abstractions policy (mostly) defined on groups Resource Group, Classification “Physical” Resource, FileName, URL, FQN UGroup | Op | Perm | RGroup RGroup | PRsrc User Group, Attribute, “Role” PUser | UGroup

27 27 Access Policy Taxonomy (3) “Physical” User, AuthN-ID, DN, Username “Logical” Abstractions support multiple authN-mechs resource location transparencies “Logical” Resource, Lfile, URN “Physical” Resource, PFile, URL, FQN UGroup | Op | Perm | RGroup RGroup | LRsrc “Logical” Username, Access-ID LUser | UGroup PUser | LUser LRsrc | PRsrc

28 28 Access Policy Taxonomy (4) Puser/Luser/UGroup/Role | Op | Perm | Rgroup/LRsrc/PRsrc RGroup | LRsrc LUser | UGroup PUser | LUser LRsrc | PRsrc Luser/UGroup | Role Policy on physical, logical, roles and groups …plus hierarchical groups/roles, etc., etc…

29 29 Access Policy Taxonomy (5) Meta-Data Catalog Integration allows for “secure-browsing” Meta-Data Catalog integrated with access policy UGroup | Op | Perm | RGroup RGroup | LRsrc LUser | UGroup PUser | LUser LRsrc | PRsrc RGroup | Meta-Data LRsrc | Meta-Data PRsrc | Meta-Data

30 30 ??Permission?? Requested operation Access Determination (1) Authenticated User-ID Can Subject invoke Operation on Resource? Can AuthN-ID invoke Operation on Physical-Resource? “Physical” Resource to access UGroup | Op | Perm | RGroup RGroup | LRsrc LUser | UGroup PUser | LUser LRsrc | PRsrc

31 31 Policy Assertions from Everywhere

32 32 VOMSRS/VOMS SAZ/PRIMA/GUMS MyProxy AuthN Svc - Username=> DN mapping Access Determination (2) Puser/Luser/UGroup/Role | Op | Perm | Rgroup/LRsrc/PRsrc RGroup | LRsrc LUser | UGroup PUser | LUser LRsrc | PRsrc Luser/UGroup | Role Policy “components” distributed Meta-data catalog Data-Service (after staging…)

33 33 Policy Assertions from Everywhere CAS Shib LDAP Handle VOMS PERMIS XACML SAML SAZ PRIMA Gridmap XACML ???

34 34 Policy Evaluation Complexity l Single Domain & Centralized Policy Database/Service u Meta-Data Groups/Roles membership maintained with Rules u Only Pull/push of AuthZ-assertions l … l Challenge is to find right “balance” l (driven by use cases…not by fad/fashion ;-) ) l … l Split Policy & Distribute Everything u Separate DBs for meta-data, rules & attribute mappings u Deploy MyProxy, LDAP,VOMS, Shib, CAS, PRIMA, XACML, PRIMA, GUMS, PERMIS, ???

35 35 AuthZ & Attr Svcs Topology l Policy Enforcement Use Cases determine “optimal” AuthZ & Attr Svc Topology l Client pull-push versus Server pull u Network-hurdles/firewalls u Crossing of admin domains l Separate Attributes from Rules (VOMS/Shib) or Separate Policies from Enforcement Point (CAS) u Separation of duty - delegation of admin l Replicating of Policy-DB or Call-Out u Network overhead versus sync-mgmt overhead l !!! Choose “Most Simple” Deployment Option !!! (ideally, services and middleware should allow all options…)

36 36 Data Integrity Protection l Data “Corruption” u Many, many copies of the original data files and model-code u Many “opportunities” for undetected changes l Independent from normal integrity protection for storage and data moving u Accidental, script-kiddies or worse… l Integrity Protection u Identify and guard the “original” l Most files are immutable…maybe make them all immutable… u Use file-signatures/digests (SH-1/256, ???) l Tripwire-like u Digest part of meta-data, communicate expected digest with URL/URI, independent digest-services, embed digest in URI, use digest-value as “natural” name for file…file-name=digest-value l Learn from file-sharing P2P application! u Integrate integrity checks in file-moving apps l http, DataMoverLight, GridFTP, Opendap, RLS, etc. u Define procedures for data corruption detection

37 37 Conclusion l ESG is a very cool and challenging application! u Security goal is to enable not limit access… l Many challenges not unique to ESG u Leverage existing solutions u Collaborate on non-existing l Interoperability requirements with TG/OSG/??? u Limits technology/mechanism choices (creds, protocols, assertion-formats, interfaces, infrastructure-services, ontology, SSO, audit, etc.) u Requires (closer) collaboration l “Fighting” complexity is major challenge u Cost associated with splitting-up policies u Need better understanding & best practices l Data Integrity Protection u Feature-gap in tools and data management


Download ppt "The Earth System Grid ----- Security to enable Access Frank Siebenlist Argonne National Laboratory / University of Chicago NSF Cybersecurity."

Similar presentations


Ads by Google