The Earth System Grid Security to enable Access

1
The Earth System Grid----- Security to enable
Access

• Frank Siebenlist
• Argonne National Laboratory / University of
  Chicago
• franks_at_mcs.anl.gov
• NSF Cybersecurity Summit 2007
• Arlington, VA - Feb 22-23, 2007

2
Making Climate Simulation Data Available Globally
ESG Computational/Data Sites and Collaborators
3
The ESG Team
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
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
4
ESG Architecture
5
ESG Portal
6
An Operational DataGrid for Climate Research
7
An Operational DataGrid for IPCC
8
Authentication Authorization Accounting/Metrics
9
(No Transcript)
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
Towards Global Earth System Modeling
CCM3 at T170 Resolution (about 70km)
1/10d POP Ocean Model
MOZART Chemistry Model
14
PMEL
ESG
15
TeraGrid
SAN MSS
RAID HPSS
16
The Earth System GridCenter for Enabling
Technologies
Funded for 2006-2010

• Petascale distributed climate data
• Global Grid of data producers (IPCC)
• Model experiment environment
• Analysis services (online archive)
• ESG-enabled analysis and visualization tools

17
(No Transcript)
18
ESG Securityin process of architecting next
phasereporting on design choices/challenges
19
Client gt Portal gt Resource Access
Resource
Portal
browserClient
20
Client gt Portal gt Resource Accessas Portal-ID
Resource
Portal
PortalAuthN AuthZ
ClientAuthZ
browserClient
ClientAuthN
As Portal-ID Resource only sees/knows AuthNed
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
Client gt Portal gt Resource Accessas
Portal-ID on behalf of Client-ID
Resource
Portal
PortalAuthN AuthZ Client AuthZ
Client-ID
ClientAuthZ
browserClient
ClientAuthN
As Portal-ID on behalf of Client-ID Resource sees
AuthNed Portal-ID Resource sees UnAuthNed
Client-ID Resource trusts Portal-ID to forward
Clients request No cryptographic proof of
delegation Clients AuthZ determined/enforced at
Resource (Clients AuthZ also determined/enforced
at Portal)
22
Client gt Portal gt Resource Accessas Portal
impersonating Client-ID
Client Creds Svc
Resource
Portal
ClientCreds
ClientAuthN AuthZ
browserClient
ClientAuthN
ClientAuthZ
As Client-ID through Impersonation Portal
maintains clients (proxy-)credentials Resource
only sees Client-ID Clients AuthZ
determined/enforced at Resource (Portal-ID only
for audit)
23
Portal gt Resource Access Methods

• As Portal-ID
• Resource only sees/knows AuthNed 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 AuthNed Portal-ID
• Resource trusts Portal-ID to forward Clients
  request
• Clients AuthZ determined/enforced at Resource
• As Client-ID through Impersonation
• Portal maintains clients (proxy-)credentials
• Resource only sees Client-ID
• Clients AuthZ determined/enforced at Resource
• As Portal-ID through fine-grained Delegation
• Resource sees AuthNed Portal-ID
• Client-IDs AuthZ assertion empowers Portal-ID
• Portals rights at Resource limited by Clients

COMPLEXITY
24
Light and Fat-Client Access
Resource
Portal
PortalAuthN AuthZ
browserClient
ClientAuthN
ClientAuthZ
Reuse Portals AuthZ through push/pull
Resource
ClientAuthN AuthZ
FatClient
Obtain datas URI after browsing
GridFTP, OpenDAP, SRM, ws-transfer, ???
25
Access Policy Taxonomy (1)
Physical User, AuthN-ID, DN, Username
Operation/Action
PUser Op Perm PRsrc
Permission Permit Deny NotApplicable
Physical Resource, FileName, URL, FQN
Identity-based, ACL-like, most simple policy
statement
26
Access Policy Taxonomy (2)
Physical User, AuthN-ID, DN, Username
User Group, Attribute, Role
PUser UGroup
UGroup Op Perm RGroup
RGroup PRsrc
Resource Group, Classification
Physical Resource, FileName, URL, FQN
Grouping Abstractions policy (mostly) defined on
groups
27
Access Policy Taxonomy (3)
Physical User, AuthN-ID, DN, Username
Logical Username, Access-ID
PUser LUser
LUser UGroup
UGroup Op Perm RGroup
RGroup LRsrc
LRsrc PRsrc
Logical Resource, Lfile, URN
Physical Resource, PFile, URL, FQN
Logical Abstractions support multiple
authN-mechsresource location transparencies
28
Access Policy Taxonomy (4)
PUser LUser
LUser UGroup
Luser/UGroup Role
Puser/Luser/UGroup/Role Op Perm
Rgroup/LRsrc/PRsrc
RGroup LRsrc
LRsrc PRsrc
Policy on physical, logical, roles and
groups plus hierarchical groups/roles, etc.,
etc
29
Access Policy Taxonomy (5)
Meta-Data Catalog integrated with access policy
PRsrc Meta-Data
LRsrc Meta-Data
PUser LUser
RGroup Meta-Data
LUser UGroup
UGroup Op Perm RGroup
RGroup LRsrc
LRsrc PRsrc
Meta-Data Catalog Integration allows for
secure-browsing
30
Access Determination (1)
Authenticated User-ID
??Permission??
PUser LUser
LUser UGroup
UGroup Op Perm RGroup
RGroup LRsrc
LRsrc PRsrc
Requested operation
Physical Resource to access
Can Subject invoke Operation on Resource? Can
AuthN-ID invoke Operation on Physical-Resource?
31
Policy Assertions from Everywhere
32
Access Determination (2)
MyProxy AuthN Svc - Usernamegt DN mapping
PUser LUser
VOMSRS/VOMS
LUser UGroup
Luser/UGroup Role
Puser/Luser/UGroup/Role Op Perm
Rgroup/LRsrc/PRsrc
RGroup LRsrc
LRsrc PRsrc
SAZ/PRIMA/GUMS
Meta-data catalog
Data-Service (after staging)
Policy components distributed
33
Policy Assertions from Everywhere
PERMIS XACML SAML SAZ PRIMA
Shib LDAP Handle
VOMS
CAS
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 casesnot 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, ???

COMPLEXITY
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)orSepa
  rate 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 immutablemaybe 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 filefile-namedigest-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