1 / 119

Grid Authentication and Authorization

Grid Authentication and Authorization. Grid Middleware 2 David Groep, lecture series 2005-2006. Outline. Organisation and trust in virtual organisations separating authentication identity and authorisation entities, identities, identifiers and digital personae Authentication

alexis
Download Presentation

Grid Authentication and Authorization

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. Grid Middleware II 3 Essentials on Grid Security • Access to shared services • cross-domain authentication, authorization, accounting, billing • common generic protocols for collective services • 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’) • Leave resource owner always in control

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

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

  6. Grid Middleware II 6 Stakeholders in Grid Security Current grid security is largely user centric • different roles for the same person in the organic unit and in the VO • There is no a priori trust relationship between members or member organisations • 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

  7. Grid Middleware II 7 Virtual Organisations • Build a trust and attribute domain overlaid on top of the organisational structure • relationship between resource and a (set of) VOs • 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 RPbut not necessarily from the user’s home organisation…

  8. Grid Middleware II 8 FederatedCertificationAuthorities Org. Certification Authority Authority Policy Policy Authority Authority Sub-Domain B1 Sub-Domain A1 Domain B Task Server X Server Y Org. Certification Domain A AuthZFederation Service GSI Virtual Organization Domain

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

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

  11. Grid Middleware II 11 V i r t u a l C o m m u n i t y C P e r s o n E ( R e s e a r c h e r ) P e r s o n B F i l e s e r v e r F 1 ( A d m i n i s t r a t o r ) ( d i s k A ) C o m p u t e S e r v e r C 1 ' P e r s o n A P e r s o n D ( P r i n c i p a l I n v e s t i g a t o r ) ( R e s e a r c h e r ) P e r s o n B P e r s o n E ( S t a f f ) F i l e s e r v e r F 1 P e r s o n D ( F a c u l t y ) ( d i s k s A a n d B ) C o m p u t e S e r v e r C 2 C o m p u t e S e r v e r C 1 ( S t a f f ) P e r s o n A P e r s o n F ( F a c u l t y ) ( F a c u l t y ) P e r s o n C C o m p u t e S e r v e r C 3 ( S t u d e n t ) O r g a n i z a t i o n A O r g a n i z a t i o n B Virtual vs. Organic structure Graphic from Frank Siebenlist, ANL & Globus AllianceGGF OGSA Working Group

  12. Grid Middleware II 12 Alternative uses of the word VO • 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 • Users and providers • closer to the ‘original’ definition of a Grid VO • used in P2P or ‘grass-roots’ like scenarios • Virtual Enterprise-style definition • a set of (legally) independent organizations that share resources and skills to achieve its mission / goal

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

  14. Grid Middleware II 14 VO embedding today • as part of a Grid ‘ecosystem’where ecosystem takes care of end-to-end solution • Middleware • User support • ‘Infrastructure’ (a collective of Resource Centres) • a single VO per projectuser 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 • ‘non-aligned’ VOs • need to build their own hosting environment • maybe supported by a ‘big’ partner from another ecosystem

  15. Grid Middleware II 15 Separating Authentication and Authorization • 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 • 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 • A precise formal separation is difficult …

  16. Grid Middleware II 16 Building Virtual Organisations • VOs today are rather long-lived(but not too difficult to set up) • 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) • …

  17. Authentication Grid AuthN and PKI

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

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

  20. Grid Middleware II 20 Some Definitions • Entity • 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 • 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-processID

  21. Grid Middleware II 21 Definition of Authentication • ‘Intuitive’ notion of AuthN vs. AuthZ • but formally separating AuthN & AuthZ 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’ AuthZ 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).

  22. Interlude: RSA

  23. Grid Middleware II 23 How does RSA it work? public space • Example 1: (d,e,p,q) (e,n) (d,n) (e,n) n = pq Alice c m Dd,n(c) →m c=Ee,n(m) 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 Bob

  24. Grid Middleware II 24 6-bit RSA key generation • 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)

  25. Grid Middleware II 25 Message Exchange (3,55) Encryption: • Bob thinks of a plaintext m(<n) = 18 • Encrypt with Alice’s public key (3,55) • c=E3;55(18)=183 mod(55) = 5832 mod(55) = 2 • send message “2” Decryption: • Alice gets “2” • she knows private key (27,55) • E27;55(2) = 227 mod(55) = 18 ! • If you just have (3,55), it’s hard to get the 27… 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)

  26. Public Key Infrastructures

  27. Grid Middleware II 27 Certificates • 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, …)

  28. Grid Middleware II 28 Certificate Format • Abstract Syntax Notation 1 (ASN.1) • compact binary representation of structured data • eXtensible • with built-in Mark-up • a complete Language • standard defined in early ’90s • 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 • 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

  29. Grid Middleware II 29 CAs: Authentication and Trust • deployment of a PKI is not technical, but trust and policy based • Policy content • RFC2527 • RFC3647 • Results in AuthN Identity Assertion • to be useful for later independent AuthZ:must be ‘unique’i.e. subject name forever bound to the same individual entity • integrity must remain intact

  30. Grid Middleware II 30 Policy: topics of interest From RFC 3647: • Introduction • Publication and repository • Identification and authentication • Lifecycle operational requirements • Management and operational controls • Technical security controls • Certificate, CRL and OCSP profiles • Compliance • Business and legal matters

  31. Grid Middleware II 31 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 names3. a forum [to] participate and raise issues4. [operation of] a secure collection point for information about CAs which you accredit5. common practices where possible (list courtesy of the Open Science Grid, backed (and to be extended) by EGEE&LCG)

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

  33. Grid Middleware II 33 Authentication Factors • What you know • passphrase, PIN code • What you have • smart-cards, tokens, one-time pad calculators • What you are • 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

  34. Grid Middleware II 34 Authentication … academia, industry, and … Possible sources of authentication and identity • National PKI • 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 • because web browsers pre-install the roots of trust • WebTrust “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

  35. Grid Middleware II 35 CA 2 CA 1 relying party n CA n charter CA 3 relying party 1 guidelines acceptance process A Federation Model for Grid Authentication • A Federation of many independent CAs • 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

  36. Grid Middleware II 36 Building the Grid AuthN federations • 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 • single document to review and assess for all Authorities • collective acceptance of all accredited authorities • Reduce cost on the authorities • but participation in the federation comes with a price • … the ultimate decision always remains with the RP

  37. Grid Middleware II 37 Grid AuthN quality • 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. • 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 AuthZ level (in the VO)

  38. 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. • As its main activity the EUGridPMA • coordinates a Public Key Infrastructure (PKI) for use with Grid authentication middleware. • 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. Grid Middleware II 38 EUGridPMA: the Federation in Europe

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

  40. Grid Middleware II 40 Coverage of the EUGridPMA 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: • DoEGrids (.us) • GridCanada (.ca) • CERN • ASGCC (.tw)* • IHEP (.cn)* * Migrated to APGridPMA per Oct 5th, 2005

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

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

  43. Grid Middleware II 43 • APGridPMA • CA A1 • … • EUGridPMA • CA E1 • CA E2 • … • TAGPMA • CA T1 • … IGTF Federation Common Policy IGTF Federation Document trustrelations SubjectNamespaceAssignment DistributionNaming Conventions Common Authentication Profiles Classic(EUGridPMA) SLCS(TAGPMA) worldwide relying parties see a uniform IGTF “mesh”

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

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

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

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

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

  49. Authorization

  50. Grid Middleware II 50 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 • Variety of mechanisms • Variety of sources of authority • Integration and interoperability needs significant effort …

More Related