The Grid Virtual Organisations and their support via federations

1
The Grid Virtual Organisations and their
support via federations

• David Groep
• EUGridPMA
• Physics Data Processing group NIKHEF
• Informatics Institute University of Amsterdam

2
Outline

• The grid
• what is it, what are specific use cases?
• grid AA and the separation of Authentication and
  Authorisation
• A global authentication trust fabric
• federation origins
• growth of the global AuthN trust fabric
• authentication profiles and minimum requirements
• levels of assurance
• Authorisation in grids
• virtual organisation models and implementations
• multiple assertion sources
• Towards an integrated AAI
• leveraging home organisation attributes
• towards a multi-authority world in a single
  decision point

3
Grid from 10 000 feet
Scientific instruments, libraries and experiments
provide huge amounts of data
The GRID networked data processing centres and
middleware software as the glue of resources.
based on Federico.Carminati_at_cern.ch
4
What is Grid?

• The word grid has been used in many ways
• cluster computing
• cycle scavenging
• cross-domain resource sharing
• A clear definition for the grid?
• Coordinates resources not subject to centralised
  control
• Using standard, open and generic protocols
  interfaces
• fostered by the Open Grid Forum
• Provides non-trivial qualities of collective
  service
• www.ogf.org

Definition source Ian Foster in Grid Today, July
22, 2002 Vol. 1 No. 6, see http//www-fp.mcs.anl
.gov/foster/Articles/WhatIstheGrid.pdf
5
Grid characteristics

• Some things that may make a grid a bit special
  compared to other distributed efforts
• collaboration of individuals from different
  organisations
• most of the scientific grid communities today
  consist of people literally scattered over
  many home organisations internationally
• delegation programs and services acting on your
  behalf are an integral part of the architecture
• unattended operation
• resource brokering
• integrating compute, data access, and databases
  in the same task

6
VL-e medical imaging project

• On functional MRI studies run from a std workflow
• People and systems involved
• medical doctors and the fMRI apparatus AMC
  hospital
• shared data storage service Natl
  computing/network centre SARA
• algorithm developers University of Amsterdam
• Analysts (MD) AMC
• and a lone psychologist from the VU Free
  University of Amsterdam

?
SP1.3 Medical Imagingsimplified user scenario
7
Typical use case WISDOM

• Wide-area In-Silico Docking On Malaria
• people and organisations
• Bio-informaticians and grid development IN2P3
  (FR)
• Service systems (brokers) provided by RAL (UK),
  NIKHEF (NL)
• algorithms, and results analysed by SCAI (DE)
• Compute resources provided by over 45
  independent organisations in 15 countries, whose
  primary mission is usually HE Physics!
• VO management hosted by CERN (CERN), and the VO
  itself is managed by Vincent Breton (FR)
• Science done over 46 million ligands virtually
  docked on the malaria (and H5N1/avian flu)
  viruses in less than 1 month

8
Typical use case LHC (HEP) Computing

• Large Hadron Collider
• the worlds largest microscope
• looking at the fundamental forces of nature
• 27 km circumference
• Located at CERN, Geneva, CH/FR

9
W-LCG implementing LHC computing
20 years est. life span 24/7 global
operations 4000 person-years ofscience
software investment
5 000 physicists 150 institutes 53
countries/economic regions

• this VO shares two resource centres with the
  medical case
• LCG weird as VO affiliation usually outlives
  that of home organisation

10
Virtual Organisation

• What is a Virtual Organisation?
• A set of individuals or organisations, not under
  single hierarchical control, (temporarily)
  joining forces to solve a particular problem at
  hand, bringing to the collaboration a subset of
  their resources, sharing those at their
  discretion and each under their own conditions.

• Users are usually a member of more than one VO
• Any large VO will have an internal structure,
  with groups, subgroups, and various roles

graphic from Anatomy of the Grid, Foster,
Kesselman and Tuecke
11
Virtual organisation structure

• Lots of overlapping groups and communities

graphic OGSA Architecture 1.0, OGF GFD-I.030
12
Virtual vs. Organic structure

• Virtual communities (virtual organisations) are
  many
• An individual will typically be part of many
  communities
• has different roles in different VOs (distinct
  from organisational role)
• all at the same time, at the same set of
  resources
• but will require single sign-on across all these
  communities

graphic OGSA Architecture 1.0, OGF GFD-I.030
13
VOs and the infrastructure

• The word VO is used in many different ways
• Infrastructure projects (EGEE, VL-e PoC, )
  provide bus-like viewfor VOs, where VOs are
  essentially user communities

14
Trust relationships

• For the VO model to work, parties need a trust
  relationship
• the alternative every user needs to register at
  every resource
• we need to provide a sign-on for the user that
  works across VOs

graphic from Frank Siebenlist, Argonne Natl.
Lab, Globus Alliance
15
Delegation
16
Specialised or restricted delegation
17
Separating responsibilities

• Single Authentication token (passport)
• key issue provide a persistent, trusted
  identifier
• issued by a party trusted by all,
• recognised by many resource providers, users, and
  VOs
• satisfy traceability and persistency requirement
• in itself does not grant any access, but provides
  a unique binding between an identifier and the
  subject
• Per-VO Authorisations (visa)
• granted to a person/service via a virtual
  organisation
• based on the identifier
• acknowledged by the resource owners
• today largely role-based access control
• but providers can also obtain lists of authorised
  users per VO,
• can still ban individual users
• most of the real liability and responsibility
  goes here

18
AuthenticationThe EUGridPMA and the IGTF

• solving stable issues first

19
Authentication model

• Design and implementation choices made with the
  emergence of production-oriented grids in
  2000urgent need and focus was on providing
  cross-national trustinitially, in the context of
  the EU FP5 DataGrid and CrossGrid projects
• National PKI
• in general uptake of 1999/93/EC and
  e-Identification is slow
• where available a national PKI could be leveraged
• Various commercial providers
• Main commercial drive secure web servers based
  on PKI
• Entrust, Global Sign, Thawte, Verisign,
  SwissSign,
• primary market is server authentication, not
  end-user identities
• use of commercial CAs solves the pop-up
  problem... so for (web) servers a pop-up free
  service is actually needed
• Grass-roots CAs
• usually project specific, and without any
  documented policies
• unsuitable for the production infrastructure
  envisioned in 2000

20
The first grid authentication infrastructures

• Grid (academic) PKIs
• started off with pre-existing CAs, and some new
  ones, late 2000
• reasonable assurance level based on
  acceptable procedures
• a single assurance level inspired by grid-relying
  party requirements
• using a threshold model minimum requirements
• The first Grid CA coordination was driven by the
  actual and current need to solve some
  cross-national authentication issues right now
  around 2000
• separation of AuthN and AuthZ allowed progress in
  the area
• the policies convinced enough resource providers
  to trust the AuthN assertions
• there were and are individuals all over Europe
  (and the world) that need access to these
  resource providers
• started with 6 authorities (NL, CZ, FR, UK, IT,
  CERN)

21
Federation Model for Grid Authentication
CA 2
CA 1
relying party n
CA n
CA 3
relying party 1

• A Federation of many independent CAs
• common minimum requirements (in various flavours)
• trust domain as required by users and relying
  partieswhere relying party is (an assembly of)
  resource providers
• defined and peer-reviewed acceptance process
• No strict hierarchy with a single top
• spread of reliability, and failure containment
  (resilience)
• maximum leverage of national efforts and
  complementarities

22
Grid Relying Parties resource providers

• In Europe
• Enabling Grid for E-sciencE (EGEE) ( 200 sites)
• Distr. Eur. Infrastructure for Supercomputer Apps
  (DEISA) (15 sites)
• South Eastern Europe SEE-GRID (10 countries)
• many national projects (NL BIG-GRID, VL-e, UK
  e-Science, Grid.IT, )
• In the Americas
• EELA E-infrastructure Europe and Latin America
  (24 partners)
• WestGrid (6 sites), GridCanada,
• Open Science Grid (OSG) ( 60 sites)
• TeraGrid ( 9 sites many users)
• In the Asia-Pacific
• AP Grid (10 countries and regions participating)
• Pacific Rim Applications and Grid Middleware
  Assembly (15 sites)

data as per mid 2006
23
Relying Party issues to be addressed

• Common Relying Party requests on the Authorities
• standard accreditation profiles sufficient to
  assure approximate parityeffectively, a single
  level of assurance sufficed then for relying
  parties is changing today, as more diverse
  resources are being incorporated
• monitor signing namespaces for name overlaps
• a forum to participate and raise issues
• operation of a secure collection point for
  information about CAs which you accredit
• common practices where possible
• list courtesy of the Open Science Grid

24
International Grid Trust Federation

• Federation of 3 Regional PMAs, that define
  common guidelines and accredit credential-issuing
  authorities

TAGPMA
EUGridPMA
APGridPMA
25
The EUGridPMA
26
Geographical coverage of the EUGridPMA

• Green EMEA countries with an Accredited
  Authority
• 23 of 25 EU member states (all except LU, MT)
• AM, CH, HR, IL, IS, NO, PK, RU, TR,
  SEE-catch-all
• Other Accredited Authorities
• DoEGrids (.us)
• GridCanada (.ca)
• CERN

27
EUGridPMA Membership

• EUGridPMA membership for Authorities(the
  European policy, needed to maintain a manageable
  trust fabric)
• single Authority per
• country,
• large region (e.g. the Nordic Countries), or
• international treaty organization
• serve the largest possible community with a
  small number of stable authorities(needed for
  both management and technical reasons today)
• operated as a long-term commitment
• many CAs are operated by the (national)
  NREN(CESNET, ESnet, Belnet, NIIF, EEnet, SWITCH,
  DFN, )
• or by the e-Science programme/science
  foundation(UK eScience, VL-e, CNRS, )
• Other members DEISA, EGEE, SEE-GRID projects,
  OSG, TERENA,

28
Growth of the European Grid trust fabric
29
Building the federation

• Trust providers (CAs) and relying parties
  (sites) together shape the common requirements
• Several profiles for different identity
  management models
• Authorities demonstrate compliance with profile
  guidelines
• Peer-review process within the federation to
  (re-) evaluate members on entry periodically
• reduces effort on the relying parties
• single document to review and assess for all CAs
  under a profile
• reduces cost for the authorities
• but participation does come at a cost of involved
  participation
• Ultimate trust decision always remains with the
  RP
• An authority is not necessarily limited to just
  grid use

30
Guidelines common elements in the IGTF

• Coordinated namespace
• Subject names refer to a unique entity (person,
  host)
• Usable as a basis for authorization decisions
• This name uniqueness is essential for all
  authentication profiles!
• Common Naming
• Coordinated distribution for all trust anchors in
  the federation
• Trusted, redundant, sources for download,
  verifiable via TACAR
• Concerns and incident handling
• Guaranteed point of contact
• Forum to raise issues and concerns
• Requirement for documentation of processes
• Detailed policy and practice statement
• Auditing by federation peers

31
Guidelines secured X.509 CAs

• Aimed at long-lived identity assertions, the
  traditional PKI world
• Identity vetting procedures
• Based on (national) photo IDs
• Face-to-face verification of applicants via a
  network of distributed Registration Authorities
• Periodic renewal (once every year)
• revocation and CRL issuing requiredand we have
  all RPs actually downloading the CRLs several
  times a day
• subject naming must be a reasonable
  representation of the entity name
• Secure operation
• off-line signing key or HSM-backed on-line
  secured systems
• Audit requirements
• data retention and audit trail requirements,
  traceability of certified entities
• Technical implementation
• need to limit the number of issuing authorities
  for technical reasons (most software and
  browsers cannot support O(1000) issuers)
• certificate profile and interoperability

32
Short-lived or member integrated services

• Aimed at short-lived translations, that are
  organisation/federation bound
• Identity vetting procedures
• based on an existing ID Management system of
  sufficient quality
• Original identity vetting must be of sufficient
  quality to trace the individual for as long as
  name is in active use
• If documented traceability is lost, the subject
  name can never be re-used
• revocation and CRL issuing not required for
  assertion lifetimes ltlt 1 Ms
• subject naming must be a reasonable
  representation of the entity name
• Secure operation
• HSM-backed on-line secured systems
• Audit requirements
• data retention and audit trail requirements,
  traceability of certified entities
• Technical implementation
• scaling of this model still needs to be
  demonstrated, and needs higher-level coordination
  
• most software and browsers cannot support O(1000)
  issuers
• and a peer-review based trust fabric cannot do
  that either
• certificate profile and interoperability

33
MICS ID management system requirements
Technical and IT security requirements

• The identity management (IdM) system containing
  the identity information used to issue the
  assertions must meet the following conditions
• Re-usable private information used to
  authenticate end-entities to the IdM system must
  only ever be sent encrypted over the network when
  authenticating to any system (including any
  non-CA systems) that are allowed to use the IdM
  for authentication.
• A not-published second authentication factor must
  be used to authenticate the end-entity for
  certificate issuance
• The end-entities must be notified of any
  certificate issuance, using contact information
  previously registered in the IdM (for example by
  electronic mail)
• From the information stored in the IdM it must be
  possible to determine if the requestors identity
  has originally been validated using a
  face-to-face meeting as described above

34
MICS ID management system requirements
Identity vetting requirementsconvincing the
world that youre OK
Documentation of how the IdM is populated,
maintained and cleaned MUST be documented and
agreed to by the PMA. Two modes By example The
IdM used by the CA should be a system that is
also used to protect access to critical
resources, e.g. payroll systems, for use in
financial transactions, granting access to
highly-valuable resources, and be regularly
maintained. By review Alternatively,
equivalent security mechanisms must be provided,
described in detail and presented to the PMA and
are subject to PMA agreement. and again the data
for those entities in the IdM that qualify for
MICS assertions must be of a quality that
allows unique tracing, name uniqueness and
persistency and a mechanism to clean stale
entries must be defined. Example the UvAmsterdam
does not trust its own system even for grading!
tries to catch the quality of the system
without having to report to formal audits
35
MICS/SLCS deployment model in Europe

• Grid AuthN interface based on national
  federations
• use of MICS AP by pushing down the requirements
  onto its members
• maximum leverage of national efforts
• in line with the complementarity principle
• needed for scalability of the PMA itself!
• Example SWITCH-aai
• from entire existing federation with a single
  SLCS front-end
• introduce concept of entitlement so only
  appropriately vetted users can us the
  translation service
• issue grid compatible credentials automatically
• with life time few days
• similar efforts in NL, UK/NGS

graphic courtesy Christoph Witzig,
36
Profile matrix towards multiple LoAs

• All grid technical security mechanisms meet the
  technical protocol requirements of level 3 (but
  even soft tokens meet level 3 )
• Identity vetting requirements for Classic and
  MICS meet level 2
• only in-person allowed (remote option is not
  allowed, Authorities cannot check financial
  records c)
• except that address and DoB are not necessarily
  retained by the RA to ease data protection
  issues, and copies not always retained
• but the ID number (and issuing country) is
  recorded, so relevant agencies can get to the
  applicant
• VOs need to collect this information and more
  anyway for incident response
• Both more stringent and looser LoAs needed for
  other resource classes
• but e-Auth level 1 is too low, and NIST doesnt
  define anything in between

37
Profile matrix where we stand
Multiple Authentication Profiles where the IGTF
stands today
Identity vetting With govt photo-ID Only by in-person F2F meeting of RA With govt photo-IDWith proven documented traceability to individual at any time (no definite F2F requirement)
Subject soft-tokens allowed Issuer off-line or online HSM 140.2-3 Classic APnear-inline Id vetting
Subject soft-tokens allowed Issuer online HSM 140.2-3 MICStime-shifted Id vetting SLCStime-shifted Id vetting

38
Authorization

• A brief look at the prevalent models today

39
Modelling VOs

• VO is a directory (database) with members,
  groups, roles
• based on identifiers issues at the AuthN stage
• Membership information is to be conveyed to the
  resource providers
• configured statically, out of band early days,
  i.e. lt 2001
• in advance, by periodically pulling
  lists toddler days, 20012006 VO LDAP
  directories
• in VO-signed assertions pushed with the current
  grids, 20025 request VOMS, Community AuthZ
  Service
• in assertions, either pushed or pulled soon to
  be, 2007 leveraging new pluggable S/W frameworks

40
VO LDAP model (2001-2006)
41
VOMS X.509 as a container

• Virtual Organisation Management System (VOMS)
• developed by INFN for EU DataTAG and EGEE
• used by VOs in EGEE, Open Science Grid, NAREGI,
• push-model signed VO membership tokens
• using the traditional X.509 proxy certificate
  for trans-shipment
• fully backward-compatible with only-identity-based
  mechanisms

42
VOMS model
43
Technical interoperation

• Software has become flexible over the past few
  years
• supports push and pull of attributes and
  assertions
• becoming syntax-agnostic
• acknowledges multiple sources of policy

44
OGSA AA model

• Grid (OGSA) AA architecture
• explicitly acknowledges multiple sources of
  authority in the authorization chain

graphic OGSA 1.0, GGF standard track document
45
Grid Middleware AA support
runtime graphic Globus Toolkit 4, Frank
Siebenlist et al.
XACML PDP, or a SAML PIP, or
46
Maybe software (soon) no longer the issue?

• middleware support for both push/pull
• SAML/X.509/X.509AC side by side for conveying
  assertions
• best model depends on application
• is largely orthogonal to the trust and policy
  issues
• if you do it right, and all assertions are
  actually signed, by the proper SoA, etc.
• keeping in mind that support is needed
• for rights delegation (typically to processes)
• rights/role selection based on the session,
  and not the target resource per se
• on-demand creation of new sources of authority
  (VOs)
• and grid communities cut through organisations

47
Towards an integrated AAI?
48
Integration scenarios with other AAIs

• Interlinking of technologies can be cone at
  various points
• Authentication linking (federations of) identity
  providers to the existing grid AuthN systems
• Short-Lived Credential Services translation
  bridges
• Populate VO databases with UHO Attributes
• Equip resource providers to also inspect UHO
  attributes
• Expressing VO attributes as function of UHO
  attributes
• Make VO appear as (sub-) organisation in a
  federation
• and most probably many other options as well
• Leads to assertions with multiple LoAs in the
  same decision
• thus all assertions should carry their LoA
• expressed in a way thats recognisable
• and the LoA attested to by third parties (i.e.
  the federation)

49
SLCSfronted federation
A (national) federation as a source of trusted
identity vetting in the international grid
context

• Characteristics
• The federation as a whole assumes responsibility
  for correctness of the identity vetting and
  AuthN quality
• single interface point hides complexity of the
  internal structure
• federation must enforce LoA down to the
  participating organisationsor provide way to
  identify eligibility for the translation service
• Simple to implement, if the federation is up to
  speed
• first federation to do this is the SWITCH-aai
• accreditation by EUGridPMA foreseen Jan 2007

graphic from Chistoph Witzig, SWITCH, GGF16,
February 2006
50
Putting home attributes in the VO

• Characteristics
• The VO will know the source of the attributes
• Resource can make a decision on combined VO and
  UHO attributes
• but for the outside world, the VO now has
  asserted to the validity of the UHO attributes
  over which the VO has hardly any control

51
Attribute collection at the resource
graphic from Chistoph Witzig, SWITCH, GGF16,
February 2006

• Characteristics
• The RP (at the decision point) knows the source
  of all attributes
• but has to combine these and make the informed
  decision
• is suddenly faced with a decision on quality from
  different assertions
• needs to push a kind of session identifier to
  select a role at the target resource

52
VO attributes expressed as UHO query

• Characteristics
• The VO has to trust the assertions by the UHO
  but has a valid reason to control quality, and
  deals with a limited number of UHOs
• The VO, by mapping to a VO group/role,
  unambiguously assumes liability for its users
  with respect to the resource provider
• The RP sees at the high level only one assertion
  level but in different decisions will see of
  course many

53
Adopting a VO as part of a UHO

• By equipping the VO
• with an interface that talks your favourite
  federation language
• agreeing on a mapping of the VO roles groups to
  your federation
• agreeing on the assurance level in the VO
• VO can
• join any federation directly
• or the VO can be sponsored into any federation
  by an existing (physical) organisation
• example grant LHC collaborators access via the
  CERN librarydirectly, instead of through a VPN
  link
• model will again depend mainly on policy issues
  and licensing
• In reality, this may be quite a long way away

54
Many interesting issues to be addressed

• Technical issues solvable policy harmonisation
  is non-trivial
• first example of eduroam access using IGTF certs
  was technically easy to do but as a test only,
  no policies yet
• far wider range of qualities in the attributes
• different incentives for keeping information
  current
• responsibility for attributes resides with
  different parties
• VO to manage community membership but can small
  VOs maintain such an infrastructure? a task for
  an (independent) e-Infrastructure providers
• home organisation to manage organic attributes
  but not attributes are usually considered
  equally valuable, and there is lots of variety
  between the UHOs
• access rights may suddenly depend on attributes
  with different quality

55
Outlook

• Confederation is a must for grids
• the user scenarios require it, as the user
  community is international
• national federations, leveraging home
  organisation identity vetting or eGov IDs, are a
  must for scalability
• e-Infrastructure needs the campusand your
  researchers need e-Infra
• with a need for defined and verifiable LoAs (at
  high and low levels)
• the homeless will be a permanent feature
• IGTF today provides an international trust fabric
  for AuthN
• a source for trusted identifiers
• definition of multiple LoAs is starting, and we
  want to reach out and co-leverage other efforts
  as much as possible
• by structure, we are geared towards catering for
  the homeless
• we continue to have pressing urgent needs for
  federation today
• but we are a long way from the O(10M) users mark

56
Realising the roadmap together

• The e-IRG encourages work towards a common
  federation for academia and research institutes
  that ensures mutual recognition of the strength
  and validity of their authorization assertions.
• e-IRG RecommendationDutch EU Presidency 2004
• Trans-disciplinary (Grid projects, NRENs, other
  user communities) and trans-continental forums
  that move towards the establishment of a global,
  seamless AA infrastructure for e-Science
  applications should be encouraged.
• The e-IRG wishes to acknowledge the efforts made
  in this direction by the IGTF and the open
  information exchange point provided by TERENA
  task forces.
• Recommendation to the e-IRGAustrian EU
  Presidency 2006