Grid Authentication and Authorization Grid Middleware 2 David

Grid Authentication and Authorization Grid Middleware 2 David Groep, lecture series 2005 -2006

Grid Middleware II Outline n Organisation and trust in virtual organisations § § n Authentication § n attribute authorities, VOMS and CAS model granting access to resources privacy preserving authorisation § § n authorisation models and RFC 2904 delegation and proxies authorisation middleware, TLS vs. MLS VO management § § n RSA, PKI, Federated Authentication Identity Authorisation § § § n separating authentication identity and authorisation entities, identifiers and digital personae pseudonyms shibboleth-style handle systems bridging to organisational identity systems § § federation based identity proxy CAs SWITCH-AAI and A-select 2

Grid Middleware II Essentials on Grid Security n Access to shared services cross-domain authentication, authorization, accounting, billing § common generic protocols for collective services § n Support multi-user collaboration may contain individuals acting alone – their home organization administration need not necessarily know about all activities § organized in one or more ‘Virtual Organisations’ (the grid is a ‘multi-authority world’) § n Leave resource owner always in control 3

Grid Middleware II Issues is making grid security work n Resources may be valuable & the problems being solved sensitive § n Resources and users are often located in distinct administrative domains § § n § Requires delegation of rights by user to service Services may be dynamically instantiated Policy from sites, VO, users need to be combined § n Large, dynamic, unpredictable, self-managed … Interactions are not just client/server, but service-to-service on behalf of the user § n Can’t assume cross-organizational trust agreements Different mechanisms & credentials Dynamic formation and management of communities (VOs) § n Both users and resources need to be careful Varying formats Want to hide as much as possible from applications! 4

Grid Middleware II Multi-domain trust issues No Cross. Domain Trust Org. Certification Authority Domain B Domain A Trust Mismatch Policy Authority Task Server X Sub-Domain A 1 Mechanism Mismatch Server Y Sub-Domain B 1 graphic: Frank Siebenlist, Argonne Natl. Lab, Globus Security with SAML, Shibboleth and Grid. Shib, May 2005 5

Grid Middleware II Stakeholders in Grid Security Current grid security is largely user centric § n There is no a priori trust relationship between members or member organisations § § § n different roles for the same person in the organic unit and in the VO Virtual Organisation lifetime can vary from hours to decades VO not necessarily persistent (both long- and short-lived) people and resources are members of many VOs … but a relationship is required § § as a basis for authorising access for traceability and liability, incident handling, and accounting 6

Grid Middleware II Virtual Organisations n n Build a trust and attribute domain overlaid on top of the organisational structure relationship between resource and a (set of) VOs § n resource provider has interest in supporting the VO (e. g. they pay, it is about a topic the provider cares about, it also contains the organisations’ own researchers, &c) users can act independently from their organisation § need attributes (authentication and authorization) from parties trusted by the user itself, VO and the RP but not necessarily from the user’s home organisation… 7

Grid Middleware II Org. Certification Authority Policy Authority Sub-Domain B 1 Sub-Domain A 1 Domain A Domain B Task Auth. Z Federation Service GSI Server X Virtual Organization Domain Federated Certification Authorities Server Y 8

Grid Middleware II Rights in the distributed system Compute Center Service Rights VO graphic: Frank Siebenlist, Argonne Natl. Lab, Globus Alliance Compute Center 9

Grid Middleware II Effective access policy for users in a VO 10

Grid Middleware II 11 Virtual vs. Organic structure Virtual Community C File server F 1 (disk A) Person B (Administrator) Compute Server C 1' Person A (Principal Investigator) Person D (Researcher) Person B (Staff) Compute Server C 2 Compute Server C 1 Person A (Faculty) Person C (Student) Organization A Person E (Researcher) Person D File server F 1 (Staff) (disks A and B) Person E (Faculty) Person F (Faculty) Compute Server C 3 Organization B Graphic from Frank Siebenlist, ANL & Globus Alliance GGF OGSA Working Group

Grid Middleware II Alternative uses of the word VO n Just a group of users typical definition convenient if you are operating (or selling) an infrastructure § this is the concept seen in EGEE, OSG, &c § n Users and providers closer to the ‘original’ definition of a Grid VO § used in P 2 P or ‘grass-roots’ like scenarios § n Virtual Enterprise-style definition § a set of (legally) independent organizations that share resources and skills to achieve its mission / goal 12

Grid Middleware II A Multi-VO world n Users are members of more than one VO at the same time § possibly in the same context § n need coordination of the auth. Z attributes amongst the VOs auth. Z decisions ultimately based on the identity of the user § have a common identity amongst these VOs § so that the name of the user can be used as a unique identifier § 13

Grid Middleware II VO embedding today n as part of a Grid ‘ecosystem’ where ecosystem takes care of end-to-end solution Middleware § User support § ‘Infrastructure’ (a collective of Resource Centres) § n a single VO per project user groups join up together and participate in a single project Implicit sharing agreement between users and centres § sharing across all user communities in the project § n ‘non-aligned’ VOs § § need to build their own hosting environment maybe supported by a ‘big’ partner from another ecosystem 14

Grid Middleware II Separating Authentication and Authorization n Single Authentication token (“passport”) issued by a party trusted by all (“CA”), § 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 § n Per-VO Authorisations (“visa”) granted to a person/service via a virtual organisation § based on the ‘passport’ name § acknowledged by the resource owners § providers can obtain lists of authorised users per VO, but can still ban individual users § n A precise formal separation is difficult … 15

Grid Middleware II Building Virtual Organisations n VOs today are rather long-lived (but not too difficult to set up) § § § n HEP physics experiments (10+ yrs) Earth Observation missions (10+ yrs) Earthquake engineering (10+ yrs) LIGO (Gravitational waves) (10+ yrs? ) Projects-based ‘aggregate working groups’ EGEE bio-medical application area (2+ yr), … … Future is likely to bring many shorter-lived VOs § § § ad-hoc collaborations of scientists (~weeks) commercial analysis outsourcing (~days) … 16

Authentication Grid Auth. N and PKI

Grid Middleware II Authentication Mechanisms n PKI model: trusted third party § GSI based on PKI (but allows a multi-authority world) § n Shibboleth model: trusted home organisation § mixes in authorisation assertions § n A-select § model: trusted home organisation w/ external validators 18

Grid Middleware II Public Key Infrastructure n Based on asymmetric cryptography Most often used crypto: RSA § Most often used hash: SHA-1 § n Strongly bind identifiers to a key pair n Subsequently used to exchange symmetric keys § typically ciphers like AES-256, 3 DES, Blowfish, … 19

Grid Middleware II Some Definitions n Entity § n a ‘real world’ thing, e. g. a person, organisation, software agent Identity a defined and specific instance of a specific entity, e. g. a particular person, or a process § at each point t in time, each individual entity has one identity § cannot be directly expressed as data § n Identifier a (group of) data item(s) that reliably distinguish the identity of an entity § an identity may have many identifiers (1: n) § e. g. a ‘name’, or a hostname-OSinstance-process. ID § 20

Grid Middleware II Definition of Authentication n ‘Intuitive’ notion of Auth. N vs. Auth. Z n but formally separating Auth. N & Auth. Z is hard both contain identifiers in an integrity-protected assertion § policy decisions could be made on trivia like name or issuer § § just like basing decisions on ‘real’ Auth. Z tokens cf. granting access only to citizens of a specific country alternate-day driving based on even/odd final digit on license plate Authentication Identifier (draft definition) Those identifiers of an individual entity that relate solely to the assertion itself (for example: the RSA public key embedded in a certificate, policy identifiers describing the protection level of the private data associated with such a RSA public key), as well as those identifiers of an entity that are invariant to the context in which they are used, i. e. , long term identifiers associated to an individual entity (examples: subject names, but these could possibly include e-mail address, or organisational affiliation). 21

Interlude: RSA

Grid Middleware II 23 How does RSA it work? n public space Example 1: (d, e, p, q) (d, n) (e, n) n = pq Alice (e, n) c Dd, n(c) → m c=Ee, n(m) = me mod(n) Dd, n(c) = cd mod(n) m = D(E(m)) = E(D(m)) (reversibility) if a. o. if de = 1 mod( (p, q)) where (p, q) = (p-1)(q-1) and (p-1) prime relative to e m Bob

Grid Middleware II 6 -bit RSA key generation n n n Take a (small) value e = 3 Generate a set of primes (p, q), each with a length of k/2 bits, with (p-1) prime relative to e. (p, q) = (11, 5) (p, q) = (11 -1)(5 -1) = 40; n=pq=55 find d, in this case 27 [3*27 = 81 = 1 mod(40)] Public Key: (3, 55) Private Key: (27, 55) Ee, n(m) = me mod(n) Dd, n(c) = cd mod(n) m = D(E(m)) = E(D(m)) (reversibility) if a. o. if de = 1 mod( (p, q)) where (p, q) = (p-1)(q-1) 24

Grid Middleware II 25 Message Exchange Encryption: n Bob thinks of a plaintext m(<n) = 18 n Encrypt with Alice’s public key (3, 55) n c=E 3; 55(18)=183 mod(55) = 5832 mod(55) = 2 n send message “ 2” Decryption: n Alice gets “ 2” n she knows private key (27, 55) n E 27; 55(2) = 227 mod(55) = 18 ! n (3, 55) Ee, n(m) = me mod(n) Dd, n(c) = cd mod(n) m = D(E(m)) = E(D(m)) if a. o. if de = 1 mod( (p, q)) where (p, q) = (p-1)(q-1) If you just have (3, 55), it’s hard to get the 27…

Public Key Infrastructures

Grid Middleware II Certificates n Certificate is a signed package containing a public key (e, n) § a set of identifiers § § § subject name usage attributes meta-data (revocation URL, policy, *) additional identifiers (email, …) 27

Grid Middleware II Certificate Format n Abstract Syntax Notation 1 (ASN. 1) § § § n compact binary representation of structured data e. Xtensible with built-in Mark-up a complete Language standard defined in early ’ 90 s X. 509 defines what goes in a certificate part of the ISO/ITU-T X. 500 series § should have gone together with X. 400 email § n popular and universal format timely: it was there with the early web § selected by Netscape for their SSL protocol (secure web sites) § endorsed by (national) PKI initiatives § 28

Grid Middleware II CAs: Authentication and Trust n deployment of a PKI is not technical, but trust and policy based n Policy content RFC 2527 § RFC 3647 § n Results in Auth. N Identity Assertion to be useful for later independent Auth. Z: must be ‘unique’ i. e. subject name forever bound to the same individual entity § integrity must remain intact § 29

Grid Middleware II Policy: topics of interest From RFC 3647: 1. Introduction 2. Publication and repository 3. Identification and authentication 4. Lifecycle operational requirements 5. Management and operational controls 6. Technical security controls 7. Certificate, CRL and OCSP profiles 8. Compliance 9. Business and legal matters 30

Grid Middleware II Relying Party issues to be addressed Key characteristics of the request by our Major Relying Parties 1. standard accreditation profiles sufficient to assure approximate parity in CAs 2. monitor [] signing namespaces for name overlaps and issue unique names 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, backed (and to be extended) by EGEE&LCG) 31

Grid Middleware II Levels of Assurance Quality Aim: convey ‘quality of authentication’ information to the RP for Auth. Z decision making E-Authentication Guidelines (NIST SP 800 -63) § § Use: Federal Bridge CA related efforts such as HEBCA http: //www. csrc. nist. gov/publications/nistpubs/800 -63/SP 800 -63 v 6_3_3. pdf n Defines 4 assurance levels § § both technical (eavesdropping protection, longevity) and procedurally (identity vetting, proofing) 32

Grid Middleware II Authentication Factors n What you know § n What you have § n smart-cards, tokens, one-time pad calculators What you are § n passphrase, PIN code biometrics such as voice, iris scan, fingerprints Academic grids today (still) accepts one-factor authentication software-based token (key file) with a passphrase § cannot be reliably protected § move to 2 -factor (USB HW tokens) in progress § 33

Grid Middleware II Authentication … academia, industry, and … Possible sources of authentication and identity n National PKI § § n in general uptake of 1999/93/EC and e-Identification is slow where available, a national PKI can be leveraged Several commercial providers § § § main commercial drive today: secure e-commerce based on SSL thus primary market is server authentication, not end-user identities are implicitly trusted by many § § n because web browsers pre-install the roots of trust Web. Trust “seal of approval” scope limited to a single Authority Academic Grid PKI today § § Provide end-user identities for secure mail and grid use generally provided by the NREN or national e-science project 34

Grid Middleware II 35 A Federation Model for Grid Authentication CA 1 CA 2 CA n CA 3 n guidelines acceptance process relying party 1 A Federation of many independent CAs § § n relying party n charter Policy coordination based on common minimum requirements (not ‘policy harmonisation’) Acceptable for major relying parties in Grid Infrastructures No strict hierarchy with a single top § § spread liability and enable failure containment (better resilience) maximum leverage of national efforts and subsidiarity

Grid Middleware II Building the Grid Auth. N federations n Providers and Relying Parties together shape the common minimum requirements § Several profiles for different identity management models § different technologies Authorities testify to compliance with profile guidelines § Peer-review process within the federation to (re) evaluate members on entry & periodically § § Reduce effort on the relying parties § § § Reduce cost on the authorities § n single document to review and assess for all Authorities collective acceptance of all accredited authorities but participation in the federation comes with a price … the ultimate decision always remains with the RP 36

Grid Middleware II Grid Auth. N quality n n n Single level, since resources are reasonably comparible Most Grid CAs come at e-Auth level 2, some at level 3 ‘equivalent quality to what a major centre would normally do to protect access to valuable site-central resources’ e. g. § § n super computer salary management or budgeting systems in Grid context today, the CA is last resort only § § § will not give out personal data without a court order even that requires vetting, so turn-around time is days thus: ban user at the Auth. Z level (in the VO) 37

Grid Middleware II EUGrid. PMA: the Federation in Europe The European Policy Management Authority for Grid Authentication in e-Science (EUGrid. PMA) 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. As its main activity the EUGrid. PMA • coordinates a Public Key Infrastructure (PKI) for use with Grid authentication middleware. The EUGrid. PMA itself does not provide identity assertions, but instead asserts that - within the scope of this charter – the 38

Grid Middleware II EUGrid. PMA Membership EUGrid. PMA membership for Authorities n a single Authority per § country, large region or international treaty organization n ‘serve the largest possible community with a small number of stable CAs’ n ‘operated as a long-term commitment’ Relying Parties: major e-Infrastructures or partner organisations n DEISA, EGEE, SEE-GRID, TERENA, … 39

Grid Middleware II Coverage of the EUGrid. PMA Green: Countries with an accredited CA · The EU member states (except LU, MT) · + AM, CH, IL, IS, NO, PK, RU, TR, “SEE-catch-all” Other Accredited CAs: · · · Do. EGrids (. us) Grid. Canada (. ca) CERN ASGCC (. tw)* IHEP (. cn)* * Migrated to APGrid. PMA per Oct 5 th, 2005 40

Grid Middleware II History Growth of the EDG CACG and EUGrid. PMA 41

Grid Middleware II 2005: Extending Trust – the International Grid Trust Federation n n common, global best practices for trust establishment better manageability of the PMAs APGrid. PMA TAGPMA The Americas Grid PMA European Grid PMA Asia Pacific Grid PMA 42

Grid Middleware II IGTF Federation Common Policy IGTF Federation Document APGrid. PMA • CA A 1 • … EUGrid. PMA trust relations • CA E 1 • CA E 2 TAGPMA • … Subject Namespace Assignment • CA T 1 • … Common Authentication Profiles Classic (EUGrid. PMA) SLCS (TAGPMA) Distribution Naming Conventions worldwide relying parties see a uniform IGTF “mesh” 43

Grid Middleware II APGrid. PMA n n n 13 members from the Asia-Pacific Region, • AIST (. jp) • NPACI (. us) • APAC (. au) • Osaka U. (. jp) • BMG (. sg) • SDG (. cn) • CMSD (. in) • USM (. my) • HKU CS SRG (. hk) • IHEP Beijing (. cn) • KISTI (. kr) • ASGCC (. tw) • NCHC (. tw) Launched June 1 st, 2004, chaired by Yoshio Tanaka Minimum Requirements taken from EUGrid. PMA First face-to-face meeting on Nov 29 th, 2005 Today 6 ‘production-quality’ authorities in operation 44

Grid Middleware II TAGPMA n n To cover all of the Americas 8 members to date • Canarie (. ca) • OSG (. us) • TERAGRID (. us) • Texas H. E. Grid (. us) • DOEGrids (. us) Inclusion on many CAs from Latin America forthcoming Launched June 28 th, 2005 chaired by Darcy Quesnel, CANARIE • • • SDSC (. us) FNAL (. us) Dartmouth (. us) EELA pending: . br, . cl, . ar, … 45

Grid Middleware II Guidelines: common elements in the IGTF n Coordinated namespace Subject names refer to a unique entity (person, host) § Usable as a basis for authorization decisions § n Common Naming One-stop shopping for all trust anchors in the federation § Trusted, redundant, sources for download § n Concerns and ‘incident’ handling Guaranteed point of contact § Forum to raise issues and concerns § n Requirement for documentation of processes Detailed policy and practice statement § Open to auditing by federation peers § 46

Grid Middleware II Guidelines: secured X. 509 CAs n n Aimed at long-lived identity assertions Identity vetting procedures § § § n Secure operation § Timely revocation of compromised certificates CRL issuance required (downloaded up to 400 times/minute!) Last version: 4. 0, synchronised with Federation Document § n off-line signing key or HSM-backed on-line secured systems Response to incidents § n Based on (national) photo ID’s Face-to-face verification of applicants via a network of Registration Authorities Periodic renewal (once every year) The Annotated Minimum Requirements are on the Wiki Continues to evolve 47

Grid Middleware II Guidelines: short-lived credential service n Issue short-lived credentials based on another authentication system e. g. Kerberos CA based or existing administration § leverage existing federations, e. g. Shib-AAI CA § n Same common guidelines apply documented policies and processes § a reliable identity vetting mechanism § accreditation of the credential issuer with a PMA § n Same X. 509 format no new user-held secrets 48

Authorization

Grid Middleware II Grid Authorization today Leverages authentication provided by the PKI Identity management decoupled from access control § Creation of short-lived ‘tokens’ (‘proxy’ certificates) for single sign-on based on these identities § Status today n Variety of mechanisms n Variety of sources of authority n Integration and interoperability needs significant effort … 50

Grid Middleware II Authorization models n RFC 2904: AAA Authorization Framework http: //www. ietf. org/rfc 2904. txt n Basic entities involved User § User Home Organisation § Service Provider § Service Equipment § 51

Grid Middleware II 52 RFC 2904 relationships Service Agreements in a networking and web access context Typical Agreements in a Grid-VO context: UHO left out of the picture relation contract relation example: access to on-line journals ‘contract’

Grid Middleware II 53 Conveying Authorization n Agent, Pull and Push models Pull Agent 1 4 4 3 2 ‘provisioning’: agent is a broker for the service 1 2 3 e. g. DU equipment

Grid Middleware II Auth. Z push model n Uses ticket or other assertion to convey the “OK” decision • In the Grid model, the Auth. Z Server is not (only) located at the Service Provider, but is distributed 1 • handy in grid, as it puts the user in a central place as a collector of assertions 2 3 4 54

Security Models Architecture Level

Grid Middleware II 56 Grid Security Model (Auth. Z) TLS/MLS via delegated ‘proxies’ Authz Callout Services (running on user’s behalf) Access Compute Center Rights’’ VO Attribute Assertions VO Users Rights Local Policy on VO identity or attribute authority Natl. CA VO graphic based on: Frank Siebenlist, Argonne Natl. Lab, Globus Alliance Rights’ KCA

Grid Middleware II Grid Authorization Stakeholders 57

Grid Middleware II Delegation n agents and brokers act on behalf of users with a (subset of) their rights n this leads to a push model with proxies n § § § you don’t know beforehand where your task will end up definition of attribute release policies to these ‘unknown’ entities is virtually impossible need to support restricted delegation 58

Grid Middleware II Proxy certificates (RFC 3820) n Trust chain based on user cert n allowed to ignore the key. Usage and basic. Constraints provided subject name of proxy and issuer match for the first part § use unique serial number § Support: Open. SSL 0. 9. 7 j+, 0. 9. 8 § 59

Grid Middleware II Least Privilege delegation concept Graphic from: OGSA Specification version 1. 0 60

Grid Middleware II Least-privilege delegation n embedded in the assertions that are pushed ‘down the line’ n net restriction is logical-AND of all constraints in the entire chain n In a GSI world, these restrictions are embedded in the proxy certificate alternatively, pass SAML policies are part of the assertion § or use SAML “obligations” § 61

Grid Middleware II Restricted delegation status n Progress got stuck on policy language agreement § best we have is for GT only § § § Note that the ‘XACML’ policy buzz-word is not enough § § n “…/CN=proxy” – omnipotent, can be used to submit jobs “…/CN=limited” – not accepted by gatekeeper need common semantics for the attributes common resource naming we cannot even revoke compromised proxies acceptable because of limited lifetime § ‘pragmatic’ requirements as per GFD. 32 (Site-AAA req. ) § 62

Grid Middleware II Proxies and web portals n n Traditional authentication to web portals does not support delegation need proxy-aware web server and clients (hard to modify IE, Firefox, Opera, …) § out-of-band way to push proxies § 63

Grid Middleware II My. Proxy: a Credential Wallet/Converter n My. Proxy allows users to store GSI credentials and retrieve them § § n With username/pass phrase or other credential Can act as a credential translator from username/passphrase to GSI Used by services that can only handle username and pass phrases to authenticate to Grid § Services limited by client implementations § n E. g. web portals Also handle credential renewal for long-running tasks 64

Grid Middleware II My. Proxy classic (web) flowchart First, user gets grid credentials 1. put proxy in the My. Proxy store n 2. 3. 4. 5. 6. protect w/ username, password connect to the web server asks username, password connect to My. Proxy obtains proxy portal submits to grid 65

Grid Middleware II My. Proxy ‘Purse’ flow chart n n Hide the CA behind the My. Proxy user does not have to handle or protect credential data but keep in mind: n My. Proxy now becomes a highly trusted service c. f. on-line CAs at the end of lecture 66

Grid Middleware II Proxy renewal n Why? § n long-running jobs Additional requirements Not only the user, but also agents (e. g. the WMS) need to be able to obtain a new proxy from the store § must not compromise the integrity of the My. Proxy store § n Current best practice My. Proxy gives out new proxies based on an old-but-still-valid one (i. e. not username-password) § but only from trusted places (registred RBs) § 67

Grid Middleware II Reciprocity in Auth. Z n In an (untrusted) grid world, mutual auth. N and Auth. Z is needed, so that the user known it is talking to the intended service § the user can verify whether this service is actually part of the VO (authenticity is not enough) § n n De facto, mutual auth. Z has hardly been implemented But it is essential for trusted applications § pharmaceutical research, where inadvertently running programs on ‘non-VO’ hosts may jeopardize patent applications &c 68

Implementing Grid Security In the EGEE security infrastructure

Grid Middleware II EGEE Baseline assumptions n Modularity § n Agnostic § n Allow for new functionality to be included as an afterthought Don’t settle on particular technologies if possible Standard Interoperate § Don’t roll our own, to the extent possible § Slides: Olle Mulmo (KTH/PDC) et al. and EGEE JRA 3 70

Grid Middleware II EGEE Baseline assumptions (cont) n Common authentication infrastructure § n EUGrid. PMA and IGTF VOs self-govern the resources made available to them § § § Minimize VO management!!! Use Auth. N to tie policy to individuals/resources CA “teething problems” have made this a bit cumbersome n Always retain local control n An open-ended system § § No central point of control Can’t tell where the Grid ends Slides: Olle Mulmo (KTH/PDC) et al. and EGEE JRA 3 71

Grid Middleware II Fact: We can’t do anything fancy Paradigm Shift (SOA) Requirements on functionality Existing capabilities Authentication Access control Credential mgmt Delegation Privacy … EUGrid. PMA X. 509 Proxy Certs My. Proxy VOMS GSI Other work already underway (LCG, OGSA, …) Slides: Olle Mulmo (KTH/PDC) et al. and EGEE JRA 3 72

Grid Middleware II 74 Architecture in one picture Network perimeter user space Sandboxing Resource Site Proxy service Cred store AA VO policy Deleg. cert delegation Authorization Proxy cert Authentication Service Container . . . Authentication Slides: Olle Mulmo (KTH/PDC) et al. and EGEE JRA 3 Site policy Trust anchors Revocation Transport level security Host cert Access control Logging

Grid Middleware II Authentication n IGTF Fabric n Validation Service n Managed credential storage i. e. , where access policy can be enforced § “Active” Certificate stores (smart cards, My. Proxy) § organizationally rooted trust (KCA, SIPS) § Password-scrambled files in should go away § n Host credentials accessible by service container Slides: Olle Mulmo (KTH/PDC) et al. and EGEE JRA 3 75

Grid Middleware II TLS vs MLS n Transport Level Security § n Alias SSL, lots of experience Message Level Security The way to go in the Web Services world § Performance and support issues § n So, TLS for now SOAP over HTTPS with proxy cert supported path validation § WS interface for delegation § n Integrate MLS as we go along § Use cases for MLS exist already (DM) Slides: Olle Mulmo (KTH/PDC) et al. and EGEE JRA 3 76

Grid Middleware II TLS and MLS stacks Supported, but slow Supported, but insecure Fastest, so default 77

Grid Middleware II Authorization Slides: Olle Mulmo (KTH/PDC) et al. and EGEE JRA 3 78

Grid Middleware II Authorization (cont) n Service container integration of modular frameworks LCAS, Java Auth. Z framework, gpbox(? ) § Common authorization callout interface(s) § n Local integration LCMAPS § Dynamic Account System (experimental) § Part of the Site Access Control Lecture Slides: Olle Mulmo (KTH/PDC) et al. and EGEE JRA 3 79

Grid Middleware II Containment n From the network “Site proxy” (Dynamic Connectivity Service) § On-demand opening of inbound/outbound connectivity § Prototypes are there, but needs industry buy-in § n From the local environment § Sandboxing: monitoring progress Slides: Olle Mulmo (KTH/PDC) et al. and EGEE JRA 3 80

Grid Middleware II VO management n VOMS § n modularity keeps it open for others Allow for lightweight VO deployment Proposed solution: VO policy service § Brainchild § Slides: Olle Mulmo (KTH/PDC) et al. and EGEE JRA 3 81

Implementing Grid Auth. Z Gridmapfile, VO-LDAP, VOMS and CAS

Grid Middleware II 83 Auth. N/Auth. Z using static map files high frequency low frequency user cert (long life) CA CA CA crl update host cert (long life) service grid-proxy-init proxy cert (short life) grid-mapfile authentication info

Grid Middleware II Grid map file issues ‘grid-mapfile’ is the most simple local policy engine § n just a list of authorized users Pro it’s trivial to set up a test bed with a few users § simple to comprehend § no additional infrastructure needed § n Con does not support to concept of VOs § does not scale § requires manual intervention to add/remove users § 84

Grid Middleware II 85 Directory supported grid-mapfiles high frequency low frequency CA CA user cert (long life) registration grid-proxy-init proxy cert (short life) CA crl update host cert (long life) service VO-LDAP mkgridmap VO-LDAP authentication info grid-mapfile

Grid Middleware II VO-LDAP Issues n Pro VO can self-manage membership through the directory § No manual tasks for the resource providers § n Con Update delays § Users can be member of only one VO at a time (per identifier) § Resulting automatic map file may grow exorbitantly large § (still) no mutual auth. Z § n Note § must be supported by a system for creating local system identities on-the-fly, or use shared group local identities 86

Grid Middleware II Attribute-based auth. Z n Virtual Organisation Management System (VOMS) 87

Grid Middleware II 88 VOMS model CA high frequency low frequency CA user cert (long life) registration voms-proxy-init proxy cert (short life) authz cert (short life) CA host cert (long life) service crl update VO-VOMS registration VO-VOMS service cert (short life) VO-VOMS authz cert (short life) authentication & authorization info edg-java-security LCAS LCMAPS

Grid Middleware II VOMS n Pro § § § n user can select (subset of) auth. Z rights for each transaction effect of VO registration is in real-time user can be member of multiple VOs at the same time allows for fine-grained Auth. Z structure by the VO backward compatible with traditional GSI proxies Con allows for fine-grained Auth. Z structure by the VO (what is the resource supposed to do with it? ) § renewal of auth. Z tokens is needed and need to remember now which rights belonged to which task(s) § 89

Grid Middleware II VOMS Format n n n X. 509 attribute certificate (AC) embedded in proxy uses VOMS-specific X. 509 v 3 extension must contain almost entire cert chain of the AC makes for long proxies, ~16 -32 k. Byte is typical § significant overhead in session establishment § 90

Grid Middleware II Related n CAS (Community Auth. Z Service) developed by ANL (Globus Alliance) § SAML assertions § old style CAS: based off community identity instead of user identity, so ‘outer identity’ is of the community, not the individual § n PERMIS (Privilege Management) X. 509 AC, § policy language evaluation part of the system § 91

Privacy preservation

Grid Middleware II Preserving privacy n PKI (and thus GSI) by default expose identifiers to the conversation participants subject. Name § subject. Alt. Name § any Auth. Z attributes § n inherent property of a non-directed push model all attributes are carried as target resource evaluates policy § only in a directional system can attributes be selectively hidden (by encryption to a key of only the intended recipient) § 93

Grid Middleware II What to preserve? n (part of) dataset content § n identifying information embedded in data (e. g. patient data headers in DICOM medical images) Identity of the participants § submitting user, e. g. in case of patent-sensitive searches in ‘public’ genome databases by the pharmaceutical industry § seed to expose minimal identifiers to get access to the desired resources 94

Grid Middleware II Data “privacy” simple example n encrypted long-term data storage with key server Figure: Olle Mulmo (KTH/PDC) et al. and EGEE JRA 3 95

Grid Middleware II Approaches to privacy preservation n Identity hiding via pseudonyms like the anonymous re-mailers in the 1990’s § can be technically supported (easily) by the GSI infrastructure § pseudonyms can carry attributes (e. g. from VOMS) § supports push-mode (easy to support multiple So. As) § n Attribute release on demand (‘Shib’ model) anonymous access as a base premise § enforcement point requests specific attributes till it is satisfied § user can set policies on attribute release § in privacy preservation pull-mode should be used so the resource must know where to get all the attributes (simple in case it’s UHO only, complex in case of many VOs) § 96

Grid Middleware II Pseudonym based identity hiding Credential Storage Obtain Grid creds for Joe 1. 2. 3. Joe 4. “The Grid” Figure: Olle Mulmo (KTH/PDC) et al. and EGEE JRA 3 Pseudonymity “Joe → Zyx” Service Attribute Authority “Issue Joe’s privileges to Zyx” “User=Zyx Issuer=Pseudo CA” 97

Grid Middleware II Pseudonymity Service n Role comparable to the trusted parties in a PKI § RPs require support for traceability for the pseudonym users § Needs CP/CPS statement at the complexity level of a CA Minimum requirements and auditing (again) § n VO (the AA) needs to know both the real user and the pesudonym to grant attributes § § n user <-> VO relation is assumed trusted VO does not expose the user’s identity in the attributes (binding to the pseudonym) Can issue a new pseudonym for each request (to the same user) 98

Grid Middleware II Shibboleth n Authorization system based on principles of privacy preservation n primary (initial) target: authorized web access libraries § scientific journals § … § 99

Grid Middleware II Shibboleth n Internet 2/MACE project to enable inter-institutional sharing of web resources subject to access controls It is: § An Architecture § A Project § An Implementation n Concepts Federation administration § Access control based on attributes released by the UHO § 100

Grid Middleware II Shib Goals & background n n Use federated administration as the lever; have the enterprise broker most services (authentication, authorization, resource discovery, etc. ) in inter-realm interactions Provide security while not degrading privacy. § n n Attribute-based Access Control Foster inter-realm trust fabrics: federations and virtual organizations Leverage campus expertise and build rough consensus Influence the marketplace; develop where necessary Support for heterogenity and open standards 101

Grid Middleware II Shib Architecture 102

Grid Middleware II Shib technology status n n Uses SAML to convey assertions Attempt to standardize attributes § § n I 2 “edu. Person” (see also: intl. Edu. Person, SCHAC) Recommended attributes for In. Common: Attribute Name Attribute Value given. Name Mary sn (surname) Smith cn (common name) Mary Smith edu. Person. Scoped. Affiliation student@example. org edu. Person. Principal. Name mary. smith@example. org edu. Person. Targeted. ID ? PS: extended beyond the web, some flows may not use all existing components in the same way 103

Grid Middleware II Managing the Id. P content n n Id. P is ‘just’ an attribute authority need to manage the internals § n and to protect the Id. P content § n like VOMS-Admin for VOMS with similar security level as an on-line CA SIGnet manage privileges § delegation of these at any granularity (‘buying authority up to $5000 for the next three weeks’) § n Grouper § organise people together so they can be assigned privs 104

Some Other systems

Grid Middleware II A-select n Pluggable framework for authentication providers § § § n RADIUS LDAP SMS (Niegefoon/Mob@c) SURFkey Bank (Rabo, ABN-AMRO) PKI Service can select the required strength 106

Grid Middleware II A-select applications n n n Dutch HE (e. g. Surf. Spot) Dig. ID Kennis. Net secondary education Public Libraries Available as open source (framework, some of the Auth. N providers) www. a-select. org 107

Integration projects

Grid Middleware II Merging different auth. Z technologies Shibboleth national federations are the ‘thing of the year’ and need grid interoperation: n Grid. Shib (Von Welch et al. ANL & I 2) Shib. Grid (Andrew Martin, Oxford UK) Grid. Shib. Permis (David Chadwick, BT) MAMS My. Proxy Shib ( SHEBANGS/Shib/grid. Site (Mike Jones, Manchester) SWITCH-AAI-CA (Christoph Witzig, SWITCH) n In NL also: A-select-enabled grid PKI n n n 109

Grid Middleware II Example: Grid. Shib options n For existing grid users that have X. 509 credential § § § n pass a Shib handle to the Grid Service Provider enable a Grid PIP to obtain attributes from a Shib Id. P use these in the PDP For new users § § § put up a ‘simple on-line CA’ (using My. Proxy) that can issue credentials based on a handle X. 509 creds from this on-line CA are short-lived two modes 110

Grid Middleware II 111 My. Proxy Modes Myproxy First n My. Proxy with Online CA n My. Proxy inserts a SAML auth. N assertion into a short-lived, reusable EEC n Id. P co-located with My. Proxy (since the Id. P needs to know the EEC subject) 1 My. Proxy 2 Or Id. P-first n Needs no shared state between My. Proxy and Id. P n separate security domains possible n needs modification to the Id. P and client Id. P C L I E N T 4 5 3 Grid SP 6

Grid Middleware II Grid and Shib interop n See papers in the lecture bundle for more … 112

‘federation-backed’ CAs at the national (production) scale

Grid Middleware II SWITCH AAI CA n n Quite close to the Dutch. Grid SURFnet CA based on Shibboleth 114

Grid Middleware II SWITCHaai n A national Shibboleth-based authentication and authorization infrastructure n Work initially started in 2002, entered production mode in 2005 n About 2/3 of the members of the Swiss higher education sector have AAI accounts (130’ 000), there about 16’ 000 active users n All kinds of web-based resources such as e-Learning, videoconferencing reservation system, Libraries, Wiki’s etc… slide by: Christoph Witzig, SWITCH Middleware Development 115

Grid Middleware II What SWITCH would like to do…. Generation of X. 509 by Shib Service Provider based on Auth. N at Id. P User generates key pair and submits certificate signing request Admin. Procedures are key for quality of user management System (EUGRIDPMA compliant) Different kinds of assurance levels slide by: Christoph Witzig, SWITCH Middleware Development 116

Grid Middleware II Issue of certificates by SWITCHpki n Generation of server certificates as now (unchanged) n Generation of user certificates § § n if { Shib Id. P EUGRIDPMA compliant } then { automatic generation } else { user follows “standard” procedures (e. g. picture id) } Example: § § User management of HEP staff physicists of University of Berne follows EUGRIDPMA compliant norms They have access to Shib resource to obtain their user certificate (with varying lifetime) slide by: Christoph Witzig, SWITCH Middleware Development 117

Grid Middleware II Advantages n One set of requirements for all certificates § simplicity of policy n One infrastructure to handle all certificate requests n Only valid or revoked certificates at all times n Capitalize on the high standards of the user management system of SWITCHaai § for those institutions who follow the more stringent requirements slide by: Christoph Witzig, SWITCH Middleware Development 118

Grid Middleware II Similar in NL: an A-select enabled CA 119

Next: on to the Resource