the grid virtual organisations and their support via federations david groep eugridpma physics data...

The Grid

Virtual Organisations and their support via federations

David Groep

EUGridPMA

Physics Data Processing group NIKHEF

Informatics Institute University of Amsterdam

2006-10-05 EuroCAMP: The Grid - Virtual organisations and their support via Federations 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


Grid from 10 000 feet

The GRID: networked data processing centres and ”middleware” software as the “glue” of resources.

Researchers perform their activities regardless geographical location, interact with colleagues, share and access data

Scientific instruments, libraries and experiments provide huge amounts of data

based on: [email protected]


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.orgDefinition source: Ian Foster in Grid Today, July 22, 2002; Vol. 1 No. 6, see http://www-fp.mcs.anl.gov/~foster/Articles/WhatIstheGrid.pdf


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


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


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


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 atom

10-15 m

nucleus

quarks


W-LCG: implementing LHC computing

~ 5 000 physicists

~ 150 institutes

53 countries/economic regions

20 years est. life span 24/7 global operations~ 4000 person-years ofscience software investment


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.

graphic from: Anatomy of the Grid, Foster, Kesselman and Tuecke

• Users are usually a member of more than one VO• Any “large” VO will have an internal structure,

with groups, subgroups, and various roles


Virtual organisation structure

Lots of overlapping groups and communities

graphic: OGSA Architecture 1.0, OGF GFD-I.030


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


VOs and the infrastructure

• The word “VO” is used in many different ways– Infrastructure projects (EGEE, VL-e PoC, …) provide “bus-like” view

for VOs, where VOs are essentially user communities


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

Org. Certification

Domain A

Server X Server Y

PolicyAuthority

PolicyAuthority

TaskDomain B

Sub-Domain A1

GSI

Org. CertificationAuthority

Sub-Domain B1

Authority

AuthZFederationService

VirtualOrganization

Domain

FederatedCertificationAuthorities

graphic from: Frank Siebenlist, Argonne Natl. Lab, Globus Alliance


Delegation


‘Specialised’ or restricted delegation


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

AuthenticationThe EUGridPMA and the IGTF

solving ‘stable’ issues first


Authentication model

Design and implementation choices made with the emergence of production-oriented grids in 2000:urgent 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


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)


Federation Model for Grid Authentication

• A Federation of many independent CAs– common minimum requirements (in various flavours)– trust domain as required by users and relying parties

where 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

CA 1CA 2

CA 3

CA n

authenticationprofiles

distribution

acceptanceprocess

relying party 1

relying party n


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


Relying Party issues to be addressed

Common Relying Party requests on the Authorities

1. standard accreditation profiles sufficient to assure approximate parity

effectively, a single level of assurance sufficed then for relying parties– is changing today, as more diverse resources are being incorporated

2. monitor [] signing namespaces for name overlaps

3. a forum [to] participate and raise issues

4. [operation of] a secure collection point for information about CAs which you accredit

5. common practices where possible

list courtesy of the Open Science Grid


International Grid Trust Federation

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

TAGPMA EUGridPMA APGridPMA


The European Policy Management Authority for Grid Authentication in e-Science (EUGridPMA) is a body

• to establish requirements and best practices for grid identity providers • to enable a common trust domain applicable to authentication of end-entities in inter-organisational access to distributed resources.

The EUGridPMA itself does not provide identity assertions, but instead asserts that - within the scope of this charter – the certificates issued by the Accredited Authorities meet or exceed the relevant guidelines.

The EUGridPMA


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


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, …


Growth of the European Grid trust fabric

0

10

20

30

40

Mar

-01

Sep-0

1

Mar

-02

Sep-0

2

Mar

-03

Sep-0

3

Mar

-04

Sep-0

4

Mar

-05

Sep-0

5

Mar

-06

Sep-0

6

acc

red

ited

CA

sFoundation of the IGTF

allows migration of CAs to proper Regional PMA


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


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


Guidelines: secured X.509 CAs

Aimed at long-lived identity assertions, the ‘traditional PKI’ world

• Identity vetting procedures– Based on (national) photo ID’s– Face-to-face verification of applicants

via a network of distributed Registration Authorities– Periodic renewal (once every year)– revocation and CRL issuing required

and 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


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 << 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


MICS ID management system 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 requestor’s identity has originally been validated using a face-to-face meeting as described above

Technical and IT security requirements


MICS ID management system requirements

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

Identity vetting requirementsconvincing the world that you’re OK


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,


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 doesn’t define anything in between…


Profile matrix: where we stand

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-3MICStime-shifted Id vetting

SLCStime-shifted Id vetting

…

Multiple Authentication Profiles: where the IGTF stands today

Authorization

A brief look at the prevalent models today


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. < 2001– in advance, by periodically pulling lists ‘toddler’ days, 2001–2006

VO LDAP directories– in VO-signed assertions pushed with thecurrent grids, 2002…5 –

request: VOMS, Community AuthZ Service

– in assertions, either pushed or pulled soon to be, 2007–leveraging new pluggable S/W frameworks


VO LDAP model (2001-2006)


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


VOMS model

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


OGSA AA model

• Grid (OGSA) AA architecture– explicitly acknowledges multiple sources of authority

in the authorization chain

Key Material

Group of unique names Organizational role

Server

UserAttributesVO

Policy

ResourceAttributesSite

Policy

Policy

Authorization PolicyArchitecture

Local SiteKerberosIdentity

PolicyEnforcement

Point

VOOther

Stakeholders

Site/Resource

OwnerAuthorization

Service/PDP

Policy andattributes.

Allow orDeny

Resource

Standardize

Delegation

User

Process actingon user’s behalf

PKI/KerberosIdentity

TranslationService

PKIIdentity

Delegation Policy

graphic: OGSA 1.0, GGF standard track document


Grid Middleware AA support

XACML PDP,or a SAML PIP, or …

runtime graphic: Globus Toolkit 4, Frank Siebenlist et al.


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

Towards an integrated AAI?


Integration scenarios with other AAIs

Interlinking of technologies can be cone at various points1. Authentication: linking (federations of) identity providers to

the existing grid AuthN systems– ‘Short-Lived Credential Services’ translation bridges

2. Populate VO databases with UHO Attributes3. Equip resource providers to also inspect UHO attributes4. Expressing VO attributes as function of UHO attributes5. 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 that’s recognisable– and the LoA attested to by ‘third parties’ (i.e. the federation)


SLCS–fronted federation

• 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

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

graphic from: Chistoph Witzig, SWITCH, GGF16, February 2006


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


Attribute collection at the resource

• 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

graphic from: Chistoph Witzig, SWITCH, GGF16, February 2006


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


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 library

directly, 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


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


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 campus–and 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


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

the grid virtual organisations and their support via federations david groep eugridpma physics data...

Documents

grid virtual organisations

grid virtual organisations

grid development

federations3 grid

grid aa

word grid

open grid forum

scientific grid communities