the earth system grid ----- security to enable access

The Earth System Grid-----

Security to enable Access

Frank SiebenlistArgonne National Laboratory / University of

[email protected]

NSF Cybersecurity Summit 2007; Arlington, VA - Feb 22-23, 2007

Making Climate Simulation Data

Available GloballyPMEL

ESG Computational/Data Sites and Collaborators

The ESG Team

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

ESG Architecture

ESG Portal

An Operational DataGrid for Climate Research

An Operational DataGrid for IPCC

AuthenticationAuthorization

Accounting/Metrics

Virtual Data Services

Moving Many Files: DML

A Few MetricsA 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

1/10d POP Ocean Model

MOZART Chemistry Model

Towards GlobalEarth SystemModeling CCM3 at T170 Resolution

(about 70km)

QuickTime™ and aYUV420 codec decompressor

are needed to see this picture.





ESG

PMEL

Inside

SAN + MSS RAID + HPSS

Inside

TeraGrid

The Earth System GridCenter 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 2006-2010

…ESG Security……in process of architecting

next phase…reporting on design choices/challenges

19

Resource

“Client => Portal => Resource” Access

browserClient

Portal

20

Resource

“Client => Portal => Resource” Accessas Portal-ID

browserClient

Portal

PortalAuthN&

AuthZ

ClientAuthN

ClientAuthZ

As Portal-IDResource only sees/knows AuthN’ed Portal-IDResource does not “know” Client-IDResource enforces only Portal-ID access policyFine-grained client AuthZ determined/enforced at Portal(Client-ID only for audit)

21

Resource

“Client => Portal => Resource” Accessas Portal-ID on behalf of Client-ID

browserClient

Portal

PortalAuthNAuthZ&

ClientAuthZ

ClientAuthN

ClientAuthZ

Client-ID

As Portal-ID on behalf of Client-IDResource sees AuthN’ed Portal-IDResource sees UnAuthN’ed Client-IDResource trusts Portal-ID to forward Client’s requestNo “cryptographic proof” of delegationClient’s AuthZ determined/enforced at Resource(Client’s AuthZ also determined/enforced at Portal)

22

Resource

“Client => Portal => Resource” Accessas Portal impersonating Client-ID

browserClient

Portal

ClientAuthN&

AuthZ

ClientAuthN

ClientCreds

ClientCredsSvc

ClientAuthZ

As Client-ID through ImpersonationPortal maintains client’s (proxy-)credentialsResource only sees Client-ID Client’s AuthZ determined/enforced at Resource(Portal-ID only for audit)

23

“Portal => Resource” Access Methods As Portal-ID

Resource only sees/knows AuthN’ed Portal-ID Resource enforces only Portal-ID access policy All fine-grained client AuthZ determined/enforced at Portal

As Portal-ID on behalf of Client-ID Resource sees AuthN’ed Portal-ID Resource trusts Portal-ID to forward Client’s request Client’s AuthZ determined/enforced at Resource

As Client-ID through Impersonation Portal maintains client’s (proxy-)credentials Resource only sees Client-ID Client’s AuthZ determined/enforced at Resource

As Portal-ID through fine-grained Delegation Resource sees AuthN’ed Portal-ID Client-ID’s AuthZ assertion empowers Portal-ID Portal’s rights at Resource limited by Client’s

24

Light and Fat-Client Access

browserClient

Portal

Resource

PortalAuthN&

AuthZClientAuthN

ClientAuthZ

“Fat”Client

Resource

ClientAuthN&

AuthZ

Reuse Portal’s AuthZ through push/pull

Obtain data’s URI after browsing

GridFTP, OpenDAP, SRM, ws-transfer, ???

26

Access Policy Taxonomy (2)“Physical” User, AuthN-ID, DN, Username

Grouping Abstractionspolicy (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

Access Policy Taxonomy (3)“Physical” User, AuthN-ID, DN, Username

“Logical” Abstractionssupport multiple authN-mechs

resource location transparencies

“Logical” Resource, Lfile, URN

“Physical” Resource, PFile, URL, FQN


RGroup | LRsrc

“Logical” Username, Access-ID

LUser | UGroup

PUser | LUser

LRsrc | PRsrc

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


RGroup | LRsrc

LUser | UGroup

PUser | LUser

LRsrc | PRsrc

31

Policy Assertions from Everywhere

33

Policy Assertions from Everywhere

CAS

ShibLDAPHandleVOMS

PERMISXACMLSAMLSAZPRIMA

Gridmap

XACML

???

34

Policy Evaluation Complexity Single Domain & Centralized Policy Database/Service

Meta-Data Groups/Roles membership maintained with Rules Only Pull/push of AuthZ-assertions

…

Challenge is to find right “balance”(driven by use cases…not by fad/fashion ;-) )

… Split Policy & Distribute Everything

Separate DBs for meta-data, rules & attribute mappings Deploy MyProxy, LDAP,VOMS, Shib, CAS, PRIMA, XACML, PRIMA, GUMS, PERMIS, ???

35

AuthZ & Attr Svcs Topology Policy Enforcement Use Cases determine “optimal” AuthZ & Attr Svc Topology

Client pull-push versus Server pull Network-hurdles/firewalls Crossing of admin domains

Separate Attributes from Rules (VOMS/Shib)orSeparate Policies from Enforcement Point (CAS) Separation of duty - delegation of admin

Replicating of Policy-DB or Call-Out Network overhead versus sync-mgmt overhead

!!! Choose “Most Simple” Deployment Option !!!(ideally, services and middleware should allow all options…)

36

Data Integrity Protection Data “Corruption”

Many, many copies of the original data files and model-code

Many “opportunities” for undetected changes Independent from normal integrity protection for storage and data moving

Accidental, script-kiddies or worse… Integrity Protection

Identify and guard the “original” Most files are immutable…maybe make them all immutable…

Use file-signatures/digests (SH-1/256, ???) Tripwire-like

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

Learn from file-sharing P2P application!

Integrate integrity checks in file-moving apps http, DataMoverLight, GridFTP, Opendap, RLS, etc.

Define procedures for data corruption detection

37

Conclusion ESG is a very cool and challenging application!

Security goal is to enable not limit access… Many challenges not unique to ESG

Leverage existing solutions Collaborate on non-existing

Interoperability requirements with TG/OSG/??? Limits technology/mechanism choices(creds, protocols, assertion-formats, interfaces, infrastructure-services, ontology, SSO, audit, etc.)

Requires (closer) collaboration “Fighting” complexity is major challenge

Cost associated with splitting-up policies Need better understanding & best practices

Data Integrity Protection Feature-gap in tools and data management

the earth system grid ----- security to enable access

Documents

portalas portalid

clientid clients authz

behalf of client

clients requestclients

resourceclients authz

files30 tb

files125 tb

intergovernmental panel