Grid authentication and authorization
Download
1 / 119

Grid Authentication and Authorization - PowerPoint PPT Presentation


  • 171 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Grid Authentication and Authorization' - alexis


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Grid authentication and authorization

Grid Authentication and Authorization

Grid Middleware 2

David Groep, lecture series 2005-2006


Outline

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


Essentials on grid security

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


Issues is making grid security work

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!


Multi domain trust issues

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


Stakeholders in grid security

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


  • Virtual organisations

    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…


    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


    Rights in the distributed system

    Grid Middleware II 9

    Rights in the distributed system

    ComputeCenter

    Service

    Rights

    VO

    ComputeCenter

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


    Effective access policy for users in a vo

    Grid Middleware II 10

    Effective access policy for users in a VO


    Virtual vs organic structure

    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


    Alternative uses of the word vo

    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


    A multi vo world

    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


    Vo embedding today

    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


    Separating authentication and authorization

    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 …


    Building virtual organisations

    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)


    Authentication

    Authentication

    Grid AuthN and PKI


    Authentication mechanisms

    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


    Public key infrastructure

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


    Some definitions

    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


    Definition of authentication

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



    How does rsa it work

    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


    6 bit rsa key generation

    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)


    Message exchange

    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)



    Certificates

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


    Certificate format

    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


    Cas authentication and trust

    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


    Policy topics of interest

    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


    Relying party issues to be addressed

    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)


    Levels of assurance quality

    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)


  • Authentication factors

    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


    Authentication academia industry and

    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


    A federation model for grid authentication

    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


    Building the grid authn federations

    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


    Grid authn quality

    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)


    • 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


    Eugridpma membership

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


    Coverage of the eugridpma

    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


    Growth of the edg cacg and eugridpma

    Grid Middleware II 41

    Growth of the EDG CACG and EUGridPMA

    History


    2005 extending trust the international grid trust federation

    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


    Igtf federation common policy

    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”


    Apgridpma

    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)


    Tagpma

    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)


    Guidelines common elements in the igtf

    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


    Guidelines secured x 509 cas

    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


    Guidelines short lived credential service

    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



    Grid authorization today

    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 …


  • Authorization models

    Grid Middleware II 51

    Authorization models

    • RFC2904: AAA Authorization Frameworkhttp://www.ietf.org/rfc/rfc2904.txt

    • Basic entities involved

      • User

      • User Home Organisation

      • Service Provider

      • Service Equipment


    Rfc2904 relationships

    Grid Middleware II 52

    RFC2904 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

    ‘contract’

    example: access to on-line journals


    Conveying authorization

    Grid Middleware II 53

    Conveying Authorization

    • Agent, Pull and Push models

    Pull

    Agent

    1

    4

    4

    2

    1

    2

    3

    3

    ‘provisioning’: agent is a broker for the service

    e.g. DU equipment


    Authz push model

    Grid Middleware II 54

    AuthZ push model

    • Uses ticket or other assertion to convey the “OK” decision

    • In the Grid model, the AuthZ Server is not (only) located at the Service Provider, but is distributed

    • handy in grid, as it puts the user in a central place as a collector of assertions

    1

    2

    3

    4


    Security models

    Security Models

    Architecture Level


    Grid security model authz

    Grid Middleware II 56

    TLS/MLS viadelegated ‘proxies’

    VO Attribute Assertions

    Local Policy

    on VO identity

    or attribute

    authority

    Grid Security Model (AuthZ)

    Services (running

    on user’s behalf)

    Authz Callout

    Access

    ComputeCenter

    Rights’’

    VOUsers

    Rights

    VO

    Natl. CA

    KCA

    Rights’

    graphic based on: Frank Siebenlist, Argonne Natl. Lab, Globus Alliance


    Grid authorization stakeholders

    Grid Middleware II 57

    Grid Authorization Stakeholders


    Delegation

    Grid Middleware II 58

    Delegation

    • agents and brokers act on behalf of users

    • with a (subset of) their rights

    • this leads to a push model with proxies

      • 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


    Proxy certificates rfc3820

    Grid Middleware II 59

    Proxy certificates (RFC3820)

    • Trust chain based on user cert

    • allowed to ignore the keyUsage and basicConstraints provided

      • subject name of proxy and issuer match for the first part

      • use unique serial number

      • Support: OpenSSL 0.9.7j+, 0.9.8


    Least privilege delegation concept

    Grid Middleware II 60

    Least Privilege delegation concept

    Graphic from: OGSA Specification version 1.0


    Least privilege delegation

    Grid Middleware II 61

    Least-privilege delegation

    • embedded in the assertions that are pushed ‘down the line’

    • net restriction is logical-AND of all constraints in the entire chain

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


    Restricted delegation status

    Grid Middleware II 62

    Restricted delegation status

    • Progress got stuck on policy language agreement

      • best we have is for GT only

        • “…/CN=proxy” – omnipotent, can be used to submit jobs

        • “…/CN=limited” – not accepted by gatekeeper

      • Note that the ‘XACML’ policy buzz-word is not enough

        • 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.)


    Proxies and web portals

    Grid Middleware II 63

    Proxies and web portals

    • 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


    Myproxy a credential wallet converter

    Grid Middleware II 64

    MyProxy: a Credential Wallet/Converter

    • MyProxy allows users to store GSI credentials and retrieve them

      • 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

        • E.g. web portals

    • Also handle credential renewal for long-running tasks


    Myproxy classic web flowchart

    Grid Middleware II 65

    MyProxy classic (web) flowchart

    First, user gets grid credentials

    • put proxy in the MyProxy store

      • protect w/ username, password

    • connect to the web server

    • server asks username,password

    • connect to MyProxy

    • obtains proxy

    • portal submits to grid


    Myproxy purse flow chart

    Grid Middleware II 66

    MyProxy ‘Purse’ flow chart

    • Hide the CA behind the MyProxy

    • user does not have to handle or protect credential data

      but keep in mind:

    • MyProxy now becomes a highly trusted service

      c.f. on-line CAs at the end of lecture


    Proxy renewal

    Grid Middleware II 67

    Proxy renewal

    • Why?

      • 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 MyProxy store

    • Current best practice

      • MyProxy gives out new proxies based on an old-but-still-valid one (i.e. not username-password)

      • but only from trusted places (registred RBs)


    Reciprocity in authz

    Grid Middleware II 68

    Reciprocity in AuthZ

    • In an (untrusted) grid world, mutual authN and AuthZ 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)

    • De facto, mutual authZ 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


    Implementing grid security

    Implementing Grid Security

    In the EGEE security infrastructure


    Egee baseline assumptions

    Grid Middleware II 70

    EGEE Baseline assumptions

    • Modularity

      • Allow for new functionality to be included as an afterthought

    • Agnostic

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


    Egee baseline assumptions cont

    Grid Middleware II 71

    EGEE Baseline assumptions (cont)

    • Common authentication infrastructure

      • EUGridPMA and IGTF

    • VOs self-govern the resources made available to them

      • Minimize VO management!!!

      • Use AuthN to tie policy to individuals/resources

      • CA “teething problems” have made this a bit cumbersome

    • Always retain local control

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


    Fact we can t do anything fancy

    Grid Middleware II 72

    Fact: We can’t do anything fancy

    ParadigmShift(SOA)

    Requirements on functionality

    Authentication

    Access control

    Credential mgmt

    Delegation

    Privacy

    Existing capabilities

    EUGridPMA

    X.509 Proxy Certs

    MyProxy

    VOMS

    GSI

    Other workalreadyunderway(LCG, OGSA,…)

    Slides: Olle Mulmo (KTH/PDC) et al. and EGEE JRA3


    Architecture in one picture

    Grid Middleware II 74

    Architecture in one picture

    Networkperimeter

    Sand-boxing

    user space

    Resource

    Site Proxy

    service

    Deleg.cert

    Credstore

    AA

    VOpolicy

    delegation

    Accesscontrol

    Authorization

    Sitepolicy

    ServiceContainer

    Proxycert

    Trustanchors

    ...

    Authentication

    Authentication

    Revo-

    cation

    Transport level security

    Logging

    Hostcert

    Slides: Olle Mulmo (KTH/PDC) et al. and EGEE JRA3


    Authentication1

    Grid Middleware II 75

    Authentication

    • IGTF Fabric

    • Validation Service

    • Managed credential storage

      • i.e., where access policy can be enforced

      • “Active” Certificate stores (smart cards, MyProxy)

      • organizationally rooted trust (KCA, SIPS)

      • Password-scrambled files in should go away

    • Host credentials accessible byservice container

    Slides: Olle Mulmo (KTH/PDC) et al. and EGEE JRA3


    Tls vs mls

    Grid Middleware II 76

    TLS vs MLS

    • Transport Level Security

      • Alias SSL, lots of experience

    • Message Level Security

      • The way to go in the Web Services world

      • Performance and support issues

    • So, TLS for now

      • SOAP over HTTPS with proxy certsupported path validation

      • WS interface for delegation

    • Integrate MLS as we go along

      • Use cases for MLS exist already (DM)

    Slides: Olle Mulmo (KTH/PDC) et al. and EGEE JRA3


    Tls and mls stacks

    Grid Middleware II 77

    TLS and MLS stacks

    Supported, Supported,Fastest,

    but slow but insecure so default


    Authorization1

    Grid Middleware II 78

    Authorization

    Slides: Olle Mulmo (KTH/PDC) et al. and EGEE JRA3


    Authorization cont

    Grid Middleware II 79

    Authorization (cont)

    • Service container integration of modular frameworks

      • LCAS, Java AuthZ framework, gpbox(?)

      • Common authorization callout interface(s)

    • Local integration

      • LCMAPS

      • Dynamic Account System (experimental)

    Part of the Site Access Control Lecture

    Slides: Olle Mulmo (KTH/PDC) et al. and EGEE JRA3


    Containment

    Grid Middleware II 80

    Containment

    • From the network

      • “Site proxy” (Dynamic Connectivity Service)

      • On-demand opening of inbound/outbound connectivity

      • Prototypes are there, but needs industry buy-in

    • From the local environment

      • Sandboxing: monitoring progress

    Slides: Olle Mulmo (KTH/PDC) et al. and EGEE JRA3


    Vo management

    Grid Middleware II 81

    VO management

    • VOMS

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


    Implementing grid authz

    Implementing Grid AuthZ

    Gridmapfile, VO-LDAP, VOMS and CAS


    Authn authz using static map files

    Grid Middleware II 83

    high frequency

    low frequency

    CA

    CA

    CA

    AuthN/AuthZ using static map files

    host cert(long life)

    service

    user

    crl update

    user cert(long life)

    grid-proxy-init

    proxy cert(short life)

    grid-mapfile

    authentication info


    Grid map file issues

    Grid Middleware II 84

    Grid map file issues

    ‘grid-mapfile’ is the most simple local policy engine

    • 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

  • Con

    • does not support to concept of VOs

    • does not scale

    • requires manual intervention to add/remove users


  • Directory supported grid mapfiles

    Grid Middleware II 85

    high frequency

    low frequency

    CA

    CA

    CA

    Directory supported grid-mapfiles

    host cert(long life)

    service

    user

    crl update

    user cert(long life)

    VO-LDAP

    registration

    VO-LDAP

    grid-proxy-init

    VO-LDAP

    mkgridmap

    proxy cert(short life)

    grid-mapfile

    VO-LDAP

    authentication info


    Vo ldap issues

    Grid Middleware II 86

    VO-LDAP Issues

    • Pro

      • VO can self-manage membership through the directory

      • No manual tasks for the resource providers

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

    • Note

      • must be supported by a system for creating local system identities on-the-fly, or use shared group local identities


    Attribute based authz

    Grid Middleware II 87

    Attribute-based authZ

    • Virtual Organisation Management System (VOMS)


    Voms model

    Grid Middleware II 88

    high frequency

    low frequency

    CA

    CA

    CA

    registration

    service cert(short life)

    authz cert(short life)

    VOMS model

    host cert(long life)

    service

    user

    crl update

    user cert(long life)

    VO-VOMS

    registration

    VO-VOMS

    voms-proxy-init

    VO-VOMS

    proxy cert(short life)

    VO-VOMS

    authz cert(short life)

    authentication & authorization info

    edg-java-security

    LCASLCMAPS


    Grid Middleware II 89

    VOMS

    • Pro

      • user can select (subset of) authZ 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 AuthZ structure by the VO

      • backward compatible with traditional GSI proxies

    • Con

      • allows for fine-grained AuthZ structure by the VO(what is the resource supposed to do with it?)

      • renewal of authZ tokens is needed andneed to remember now which rights belonged to which task(s)


    Voms format

    Grid Middleware II 90

    VOMS Format

    • X.509 attribute certificate (AC) embedded in proxy

    • uses VOMS-specific X.509v3 extension

    • must contain almost entire cert chain of the AC

      • makes for long proxies, ~16-32 kByte is typical

      • significant overhead in session establishment


    Related

    Grid Middleware II 91

    Related

    • CAS (Community AuthZ 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

    • PERMIS (Privilege Management)

      • X.509 AC,

      • policy language evaluation part of the system



    Preserving privacy

    Grid Middleware II 93

    Preserving privacy

    • PKI (and thus GSI) by default expose identifiers to the conversation participants

      • subjectName

      • subjectAltName

      • any AuthZ attributes

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


    What to preserve

    Grid Middleware II 94

    What to preserve?

    • (part of) dataset content

      • 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


    Data privacy simple example

    Grid Middleware II 95

    Data “privacy” simple example

    • encrypted long-term data storage with key server

    Figure: Olle Mulmo (KTH/PDC) et al. and EGEE JRA3


    Approaches to privacy preservation

    Grid Middleware II 96

    Approaches to privacy preservation

    • 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 SoAs)

    • 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 usedso the resource must know where to get all the attributes(simple in case it’s UHO only, complex in case of many VOs)


    Pseudonym based identity hiding

    Grid Middleware II 97

    CredentialStorage

    Obtain Grid credsfor Joe

    PseudonymityService

    1.

    “Joe → Zyx”

    2.

    3.

    AttributeAuthority

    4.

    Joe

    “The Grid”

    “User=Zyx Issuer=Pseudo CA”

    Pseudonym based identity hiding

    “Issue Joe’sprivileges to Zyx”

    Figure: Olle Mulmo (KTH/PDC) et al. and EGEE JRA3


    Pseudonymity service

    Grid Middleware II 98

    Pseudonymity Service

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

    • VO (the AA) needs to know both the real user and the pesudonym to grant attributes

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


    Shibboleth

    Grid Middleware II 99

    Shibboleth

    • Authorization system based on principles of privacy preservation

    • primary (initial) target: authorized web access

      • libraries

      • scientific journals


    Shibboleth1

    Grid Middleware II 100

    Shibboleth

    • Internet2/MACE project to enableinter-institutional sharing of web resources subject to access controls

      It is:

      • An Architecture

      • A Project

      • An Implementation

    • Concepts

      • Federation administration

      • Access control based on attributes released by the UHO


    Shib goals background

    Grid Middleware II 101

    Shib Goals & background

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

      • 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


    Shib architecture

    Grid Middleware II 102

    Shib Architecture


    Shib technology status

    Grid Middleware II 103

    Shib technology status

    • Uses SAML to convey assertions

    • Attempt to standardize attributes

      • I2 “eduPerson” (see also: intlEduPerson, SCHAC)

      • Recommended attributes for InCommon:

    • PS: extended beyond the web, some flows may not use all existing components in the same way


    Managing the idp content

    Grid Middleware II 104

    Managing the IdP content

    • IdP is ‘just’ an attribute authority

    • need to manage the internals

      • like VOMS-Admin for VOMS

    • and to protect the IdP content

      • 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’)

    • Grouper

      • organise people together so they can be assigned privs



    A select

    Grid Middleware II 106

    A-select

    • Pluggable framework for authentication providers

      • RADIUS

      • LDAP

      • SMS ([email protected])

      • SURFkey Bank (Rabo, ABN-AMRO)

      • PKI

    • Service can select the required strength


    A select applications

    Grid Middleware II 107

    A-select applications

    • Dutch HE (e.g. SurfSpot)

    • DigID

    • KennisNet secondary education

    • Public Libraries

    • Available as open source (framework, some of the AuthN providers)

    • www.a-select.org



    Merging different authz technologies

    Grid Middleware II 109

    Merging different authZ technologies

    Shibboleth national federations are the ‘thing of the year’ and need grid interoperation:

    • GridShib (Von Welch et al. ANL & I2)

    • ShibGrid (Andrew Martin, Oxford UK)

    • GridShibPermis (David Chadwick, BT)

    • MAMS MyProxy Shib (

    • SHEBANGS/Shib/gridSite (Mike Jones, Manchester)

    • SWITCH-AAI-CA (Christoph Witzig, SWITCH)

    • In NL also: A-select-enabled grid PKI


    Example gridshib options

    Grid Middleware II 110

    Example: GridShib options

    • For existing grid users that have X.509 credential

      • pass a Shib handle to the Grid Service Provider

      • enable a Grid PIP to obtain attributes from a Shib IdP

      • use these in the PDP

    • For new users

      • put up a ‘simple on-line CA’ (using MyProxy) that can issue credentials based on a handle

      • X.509 creds from this on-line CA are short-lived

      • two modes


    Myproxy modes

    Grid Middleware II 111

    C

    L

    I

    E

    N

    T

    IdP

    MyProxy

    1

    4

    5

    2

    3

    Grid SP

    6

    MyProxy Modes

    Myproxy First

    • MyProxy with Online CA

    • MyProxy inserts a SAML authN assertion into a short-lived, reusable EEC

    • IdP co-located with MyProxy(since the IdP needs to know the EEC subject)

      Or IdP-first

    • Needs no shared state between MyProxy and IdP

    • separate security domains possible

    • needs modification to the IdP and client


    Grid and shib interop

    Grid Middleware II 112

    Grid and Shib interop

    • See papers in the lecture bundle for more …


    Federation backed cas

    ‘federation-backed’ CAs

    at the national (production) scale


    Switch aai ca

    Grid Middleware II 114

    SWITCH AAI CA

    • Quite close to the DutchGrid SURFnet CA

    • based on Shibboleth


    Switchaai

    Grid Middleware II 115

    SWITCHaai

    • A national Shibboleth-based authentication and authorization infrastructure

    • Work initially started in 2002, entered production mode in 2005

    • About 2/3 of the members of the Swiss higher education sector have AAI accounts (130’000), there are about 16’000 active users

    • All kinds of web-based resources such as e-Learning, video-conferencing reservation system, Libraries, Wiki’s etc…

    slide by: Christoph Witzig, SWITCH Middleware Development


    What switch would like to do

    Grid Middleware II 116

    What SWITCH would like to do….

    Generation of X.509 by Shib Service Provider based on AuthN at IdP

    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


    Issue of certificates by switchpki

    Grid Middleware II 117

    Issue of certificates by SWITCHpki

    • Generation of server certificates as now (unchanged)

    • Generation of user certificates

      • if { Shib IdP 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


    Advantages

    Grid Middleware II 118

    Advantages

    • One set of requirements for all certificates

      • simplicity of policy

    • One infrastructure to handle all certificate requests

    • Only valid or revoked certificates at all times

    • 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


    Similar in nl an a select enabled ca

    Grid Middleware II 119

    Similar in NL: an A-select enabled CA



    ad