Site access control
1 / 78

Site Access Control - PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

Site Access Control. Grid Middleware 3 David Groep, lecture series 2005-2006. Outline. Authorisation Framework Policies, policy combination and enforcement PDP, PIP and PEP LCAS, GridSite, JavaTrustManager Credential Mapping and local policies unix domain for jobs

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

Download Presentation

Site Access Control

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

Site Access Control

Grid Middleware 3

David Groep, lecture series 2005-2006

Grid Middleware III2


  • Authorisation Framework

    • Policies, policy combination and enforcement

    • PDP, PIP and PEP

    • LCAS, GridSite, JavaTrustManager

  • Credential Mapping and local policies

    • unix domain for jobs

    • account mapping across clusters (LDAP, or NSS-JR)

    • workspace service and virtualisation

  • Policy languages

    • SAML and XACML

  • Scheduling and batch systems

    • getting into the mess: preserving priorities?

  • Network and firewall issues

Grid Middleware III3

Authorization Stakeholders, a reminder

Grid Middleware III4

Site Access Control



user space


Site Proxy


















Transport level security



Grid Middleware III5

What Problems should we solve

  • Fit ‘external’ users into existing infrastructure

    • fork jobs, batch queuing systems, disks & mass stores, …

  • enforce (local) security policies

    • e.g. a panic button, blacklisting of users

  • ensure that global (VO) policies are satisfied locally

    • in as far as possible, given local mechanisms

Grid Middleware III6

What To Do?

  • collect policies that need to be enforced

  • collect the information on which to base the decision

  • make the decision

Grid Middleware III7

Distinct pieces in the process flow

  • Authentication

  • Authorization

    • results in a yes/no decision

    • possibly with obligations

  • Service access

    • For legacy job execution services (Unix, Win32), need an execution environment with a system credential:Credential Mapping needed (site-local, to preserve autonomy)

    • For hosted servicesexecute the service request, taking into account service-specific access controls (such as ACLs for file catalogue access)

Grid Middleware III9

Context cache

PEPService ormessageinterceptor






User inblacklist?

RetrieveVO info

Retrievelocal info


Chain 1



Chain 2


= PAP accessible interface

Architecture for Local Access Control

Grid Middleware III10

Authorization Framework components

  • Policy Decision Point (PDP)

    • makes a binary “yes/no” decision

    • based on a policy, that can be nested

  • Policy Information Point (PIP)

    • extract information from sources, needed to provide the assertions for making the decision

    • Policies can be ‘hybrid’

      • “SAML with obligations”, where the policy evaluates to Yes/No, but a Yes carries specific obligations for the PEP to enforce (such as an account mapping)

  • Policy Enforcement Point (PEP)

    • enforce the yes/no decision of a PDP

Grid Middleware III11

A ‘perfectly’ integrated model

  • Collect policies and assertions through PIPs

    • attributes pushed by the client, e.g. VOMS-enabled proxies

    • attributed retrieved via a pull mode (Shib-style, e.g. via WAYF)

    • policies that constrain usage (restricted delegation)

    • site-local policies

    • resource-local policies

  • Assert their authenticity and validity

    • incoming policies and assertions should be signed (authentic)

    • not expired and recognised by the deciding party (valid)

  • Evaluate all these policies together in a (single) PDP

  • Possibly, return obligations for e.g. unix system integration

Grid Middleware III12

Context cache

PEPService ormessageinterceptor






User inblacklist?

RetrieveVO info

Retrievelocal info


Chain 1



Chain 2


= PAP accessible interface

Issues with an integrated model

  • Requires harmonisation (or translation via a context cache)

  • Should include precedence information (site prevalence)

  • In practice, some ‘quick’ decision should be made earlier for performance reasons (black-listing, for instance)

  • today a mixture of

    • course-grained only (compute)

    • ACL based (storage)

    • simple binary (brokering)

Grid Middleware III13

Issues with the model (2)

  • AuthZ cannot always be cleanly separated from the service

  • Example: data access

    • access to the service ‘read file’ can be allowed, but access to any specific file restricted by ACLs on the file

    • so the AuthZ front-end should either ‘snoop’ into the service and use the ACLs

    • or the business logic should do the AuthZ (again)

      see access control to services slide later

Grid Middleware III14

Local Policy today: mapping credentials

  • Grid user is mapped to local identities to determine policy

  • At the site, policies are expressed in these local identities (like unix groups)

Map tolocal name




Map tolocal name


graphic: Frank Siebenlist, Argonne Natl. Lab, Globus Securitywith SAML, Shibboleth and GridShib, May 2005

Grid Middleware III15

Implementations today

  • All separate authN and authZ

  • most separate mapping from authZ

    • where necessary, e.g. for databases and legacy execution

    • in most general sense, it is a handle for local policy

    • Faced with two worlds: Java and native (C)

    • Need a solution for both, but no unification yet

  • Examples:

    • C world: LCAS & LCMAPS(so this talk misses out on Prima, GUMS, gPlazma, …)

    • Java: GT4 Authorization Framework(so this talk misses out on Generic AAA, PERMIS, …)

  • papers on the others are in the bundle!

Grid Middleware III17

The C World: job submission and GridFTP

  • LCAS

    • authorization based on credentials and job information (RSL)

    • returns a yes/no answer

    • pluggable framework of PDPs, using dlopen(3) system


    • credential mapping based on user credential and additional handle information

    • enforcement within the process space needed

  • GUMS: access based on a site-local database of grid-to-local creds

  • gPlazma: gid and uid assignments for ACLs on storage

Grid Middleware III18

Job submission components

most simple case

  • make access decision

  • figure out a local policy mapping (unix account)

  • log what you did

  • run the job

Grid Middleware III19







Context+ JobInfo


LCAS authZ call out


  • LCMAPS open, learn,&run:

  • … and return legacy uid

C=IT/O=INFN /L=CNAF/CN=Pinco Palla/CN=proxy

Job Manager

fork+exec args or submit


Job Submission (classic case)

  • user authenticates to a gatekeeper

    • provides proxy with identity & attributes

    • provides job information (RSL)

  • gatekeeper verifies integrity and authN

  • do an authZ callout(in our case LCAS)

    • the AuthZ frameworkcalls PDPs

  • do credential mapping

  • run the job manager

Grid Middleware III20

Policy Decision modules

Typical PDPs

  • Blacklist and whitelist

  • VOMS attributes (group/role based access)

  • Proxy lifetime constraints

  • Checking quality of authentication tokens (OIDs)

  • timeslots

    As many of these PDPs are (still) local, the grid is missing the ‘big red button’ …

Grid Middleware III21

PDP configuration

  • A PDP is driven by a policy language

    • typical choice is XACML

Policy languages

Driving the PDP

Grid Middleware III23

Policy Evaluation (a reminder)

Grid Middleware III24

Policy Languages

  • Home-grown languages

    • infinite number out there …


    • structured “Subject, Resource, Action” triplets

    • supports logical constructs (and, or)

    • also includes a retrieve/push operation**

  • SAML

    • assertion mark-up, but can also be used to express policies**

    • not typically used as such (XACML has a preference in the community, since it is more expressive for ACLs)

  • GACL (Grid ACL)

    • semantically a subset of XACML

    • can be translated back and forth

    • comprehensible for sysadmins 

Grid Middleware III25

SAML – conveying assertions

  • Security Assertion Mark-up Language

    • XML format for exchanging assertions over the wire

    • a message exchange protocol: how to ask and get assertions

    • OASIS standard

    • in itself, SAML does not define the integrity of the assertion

    • SAML assertion itself is typically signed using XML Signature when travelling between untrusted end-points

Grid Middleware III26

SAML assertion types

  • Authentication Assertion

  • Attribute Assertion

  • Authorisation Decision

Grid Middleware III27

All assertions have some common information

  • Issuer and issuance timestamp

  • Assertion ID

  • Subject

    • Name plus the security domain

    • Optional subject confirmation, e.g. public key

  • “Conditions” under which assertion is valid

    • SAML clients must reject assertions containing unsupported conditions

    • Special kind of condition: assertion validity period

  • Additional “advice”

    • E.g., to explain how the assertion was made

Grid Middleware III28

Attribute Assertion

  • An issuing authority asserts that:

    • subject S

    • is associated with attributes A, B, …

    • with values “a”, “b”, “c”…

  • Typically this would be gotten from an LDAP repository

    • “john.doe” in “”

    • is associated with attribute “Department”

    • with value “Human Resources”

Grid Middleware III29

SAML Attribute Assertion

  • <saml:Assertion …> <saml:Conditions …/> <saml:AttributeStatement> <saml:Subject> <saml:NameIdentifierSecurityDomain=“” Name=“joeuser” /> </saml:Subject> <saml:Attribute AttributeName=“PaidStatus” AttributeNamespace=“”> <saml:AttributeValue>PaidUp </saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement></saml:Assertion>

Grid Middleware III30

AuthZ Decision Assertion

  • An issuing authority decides whether to grant the request:

    • by subject S

    • for access type A

    • to resource R

    • given evidence E

  • The subject could be a human or a program

  • The resource could be a web page or a web service, for example

Grid Middleware III31

SAML Authorization Decision Assertion

  • <saml:Assertion …> <saml:Conditions …/> <saml:AuthorizationStatement Decision=“Permit” Resource=“”> <saml:Subject> <saml:NameIdentifierSecurityDomain=“” Name=“joeuser” /> </saml:Subject> </saml:AuthorizationStatement></saml:Assertion>

Grid Middleware III32

XACML: access control

  • XACML well suited to express local policies

    • can interoperate with incoming SAML assertions by translation

    • works on triplet (subject, resource, action) – RULE –> (decision [,obligation])

Grid Middleware III33

XACML policy type

Grid Middleware III34

XACML rules

  • a (set of) conditions that evaluate the incoming triples and result in a decision

Grid Middleware III35

XACML request example

  • <AAARequest>

  • <Subject Id="subject">

  • <Attribute AttributeId="subject:subject-id" Issuer="">

  • <AttributeValue></AttributeValue>

  • </Attribute>

  • <Attribute AttributeId="subject:role" Issuer="">

  • <AttributeValue>Analyst</AttributeValue>

  • </Attribute>

  • </Subject>

  • <Resource>

  • <Attribute AttributeId="resource:resource-id" Issuer="">

  • <AttributeValue></AttributeValue>

  • </Attribute>

  • </Resource>

  • <Action>

  • <Attribute AttributeId="action:token" Issuer="">

  • <AttributeValue>SubmitJob</xacmlcontext:AttributeValue>

  • </Attribute>

  • </Action>

  • <Environment>

  • <Attribute AttributeId="environment:issue-time" Issuer="">

  • <AttributeValue>2001-12-17T10:30:00</AttributeValue>

  • </Attribute>

  • </Environment>

  • </AAARequest>

XACML example from Yuri Demchenko,

Grid Middleware III36

XACML policy: login from 9 AM to 5 PM

<Policy PolicyId="SamplePolicy" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable">


<Subjects> <AnySubject/> </Subjects>



<ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">


<ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"/>




<Actions> <AnyAction/> </Actions>


<Rule RuleId="LoginRule" Effect="Permit">

<!-- Only use this Rule if the action is login -->


<Subjects> <AnySubject/> </Subjects>

<Resources> <AnyResource/> </Resources>

<Actions> <Action>



<ActionAttributeDesignator AttributeId="ServerAction"/>


</Action> </Actions>


<Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:and">

<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:time-greater-than-or-equal">

<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:time-one-and-only">

<EnvironmentAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:environment:current-time"/>




<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:time-less-than-or-equal">

<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:time-one-and-only">

<EnvironmentAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:environment:current-time"/>







Grid Middleware III37

Simpler policy languages

  • XACML is too expressive to be understood by people

  • so

    • lots of graphical editors (not so handy for large-scale adminstration)

    • translators from and to simpler languages

  • Example: GACL, the Grid ACL language

Grid Middleware III38

GACL example

<?xml version="1.0"?><gacl version="0.0.1"><entry><person><dn>/O=dutchgrid/O=users/O=nikhef/CN=Willem van Leeuwen</dn></person><allow><read/><write/></allow><deny><admin/></deny></entry>


This piece of GACL is for use with the SlashGrid filesystem, i.e. is geared towards file system operations.see

Credential mapping

and virtual workspaces

Grid Middleware III40

Credential Mapping

For legacy jobs, need to privision an environment

  • Unix account

    • persistent (grid-mapfile)

    • group account (looses tracability/accountability)

    • dynamic assignment pool-accounts

    • pool-accounts with expiration (**)

  • Virtual machines

Grid Middleware III41


  • static mapping between grid user and local uid

  • cannot support multiple-VO membership

    • or user needs a new identity for each VO

  • combines authZ and mapping

Grid Middleware III42


  • minimal modification to the gridmap-file code

    • same file format

    • uses a state directory where DNs are associated with unix accounts (using hard links, as they are atomic across NFS)

    • account mapping to “.pool” -> pool000, pool001, pool002, …

  • when the account mapping is requested

    • look in a state directory if this DN has an account mapping

    • if so, return this mapping

    • otherwise, pick next unused account from the pool and make a hardlink between DN and accountname file

    • return that mapping

  • periodic clean up of the gridmapdir is possible

    • but dangerous, as jobs may still be running or files left

Grid Middleware III43

Gridmapdir associations

  • $ ls -li /share/grid-security/gridmapdir/

  • ...

  • 7635756 –rw-r--r-- 2 Jan 8 19:44 %2fo%3ddutchgrid%2fo%3dusers%2fo%3dnikhef%2fcn%3ddavid%20groep

  • 7635756 -rw-r--r-- 2 Jan 8 19:44 dteam060

  • ...

Grid Middleware III44


  • There are many ways to collect credentials in a site

    • /etc/passwd, NIS, NIS+, LDAP, Hesiod, MySQL

    • need a extensible, pluggable framework

  • Backward compatible with existing systems (grid-mapfile)

  • Support for multiple VOs per user (and thus multiple UNIX groups)

  • Mimimum system administration

    • Poolaccounts

    • Pool”groups”

  • Boundary conditions

    • Has to run in privileged mode

    • Has to run in process space of incoming connection (for fork jobs)

Grid Middleware III45

LCMAPS – functionality view

  • Unix mapping based on VOMS groups, roles

  • Supports pool groups as well as pool accounts

  • Granularity set by the site administrator (see example)

  • Primary group set to first VOMS group

    • for accounting purposes

    • for use by schedulers in setting priority

  • Identity set before job gets to batch system

    • accounting based on batch system data needs specific USER id for each job submitted

    • traceability of system/network activity inside the job or ~wrapper

    • limit impact of a compromised identity (so as not to hurt production)

Grid Middleware III46

LCMAPS – control flow



Credential Acquisition

  • User authenticates using (VOMS) proxy

  • LCMAPS library invoked

    • Acquire all relevant credentials

    • Enforce “external” credentials

    • Enforce credentials on current process tree at the end

  • Run job manager

    • Fork will be OK by default

    • Batch systems may need primary group explicitly

    • Batch systems will need updated (distributed) UNIX account info

  • Order and function: policy-based

& Enforcement


Job Mngr

Grid Middleware III47

LCMAPS Acquisition and Enforcement

Need two phases

  • Acquisition (while in privileged mode)

    • access to root-only-readable files with, e.g., LDAP passwords

    • access to host certificate/key for remote communications

  • Enforcement

    • Do actual setuid(2) and initgroups(2) calls

    • from that point on, it’s irreversible

    • must be within the running process

Grid Middleware III48

LCMAPS – modules

  • Modules represent atomic functionality

  • VOMSextract VOMS credentials from the proxy (A)

  • PoolAccountsfrom username assign unique uid (A)

  • PoolGroupsfrom (VOMS) groupname assign unique gid (A)

  • LocalAccountfrom username assign local existing unique uid (A)

  • LocalGroupsfrom (VOMS) groupname assign local existing gid (A)

  • VOMS PoolAccountsfrom (VOMS) username assign unique uid (A)

  • AFS/Krb5 get token based on user DN info (A)

  • POSIX processsetuid() and setegid() (E)

  • POSIX LDAP update distributed user database (E)

  • Krb5 run job via k5cert (E)

Grid Middleware III49

LCMAPS – policy evaluation

  • State machine approach (superset of boolean expressions)

  • Policy description file:









path = /opt/edg/lib/lcmaps/modules

localaccount ="lcmaps_localaccount.mod \

-gridmapfile /etc/grid-security/grid-mapfile"

poolaccount = "lcmaps_poolaccount.mod -gridmapfile /etc/grid-security/grid-mapfile"

posix_enf = "lcmaps_posix.mod -maxuid 1 -maxpgid 1 -maxsgid 32"

voms = "lcmaps_voms.mod -vomsdir /etc/grid-security/certificates \

-certdir /etc/grid-security/certificates"


voms -> poolaccount | localaccount

localaccount -> posix_enf

poolaccount -> ldapldap -> posix_enf

Grid Middleware III50

example groups

# groupmapfile

"/VO=atlas/GROUP=/atlas/phys-*/ROLE=production" atlphprd "/VO=atlas/GROUP=/atlas/det-*/ROLE=production" atldtprd "/VO=atlas/GROUP=/atlas/simul-*/ROLE=production" atlsiprd "/VO=atlas/GROUP=/atlas/*" atlgnusr

"/VO=EGEE/GROUP=/EGEE/picard/Role=Manager" iteamsgm

“/VO=Wilma/GROUP=/Wilma/bfys/Role=prod” wilmgr

"/VO=Wilma/GROUP=/Wilma/*" .wilma

VOMS to Unix domain mapping

* Syntax as per VOMS attribute naming in 2.6

  • Groups can be used for setting scheduling priorities, accounting &c.

  • If site supports it, a single uniform pool of UIDs can be used for all GIDs

  • For the “fork” JM, and for sites with a modifiable userdb, the job will collect all supplementary gids, as per the VOMS proxy

Grid Middleware III51

example gridmap

# gridmapfile

"/VO=atlas/GROUP=/atlas/phys-*/ROLE=production" .aphpd "/VO=atlas/GROUP=/atlas/det-*/ROLE=production" .adtpd "/VO=atlas/GROUP=/atlas/simul-*/ROLE=production" .asipd "/VO=atlas/GROUP=/atlas/*" .agnu

"/VO=EGEE/GROUP=/EGEE/picard/Role=Manager" .isgm

“/VO=Wilma/GROUP=/Wilma/bfys/Role=prod” .wgr


VOMS to Unix domain mapping

… or using poolaccounts with a static group association

* Syntax as per VOMS attribute naming in 2.6

  • But you need a sufficiently large pool for each group

  • Only the primary group and its fixed assoc. supplementaries will be set

Grid Middleware III52

LCMAPS – caveats

  • Unix mapping based on VOMS groups, roles, and capabilities

  • Possibly pool groups as well as pool accounts

  • Granularity set by the site administrator (see example following)

  • Primary group set to first VOMS group – accounting

  • More than one VO/group per grid user allowed [but…]

  • Each VOMS unique FQAN listed translates into 1 Unix group id

  • Each user-FQAN combination translates into 1 Unix user id

  • New mechanisms could mitigate issues:

    • groups-on-demand, support granularity at any level

    • Central user directory support (nss_LDAP, pam-ldap)

      Not ready – and priorities have not been assigned to this yet.

Grid Middleware III53

Work Space Service

On the road towards virtualized resources:

Work Space Service

  • Managed accounts

    • enable life cycle management

    • controlled account management (VO can request/release)

    • “special” QoS requests

    • Use to request credentials (groups) with specific prios?

  • future: provision a virtual machine

  • WS-RF style GT4 service

    • uses LCMAPS as a back-end for account leasing

Grid Middleware III54

Workspaces and accounts

  • Unix account is ‘just’ a specific kind of workspace

  • ought to be provides like one

Grid Middleware III55

Work Space Service

Work by Kate Keahey, et al., ANL

  • provision workspaces before the job starts

    • static account mappings: grid-mapfile

    • with poolaccounts (using LCMAPS)

    • provisioning of workspace using VM technology

      • provides abstraction of resources

      • option for a ‘feel at home’ environment for applications

      • if VM technology can deliver enough performance

  • parts of this now part of a GT4 tech preview

Grid Middleware III56

LCMAPS usage with the WSS

Grid Middleware III57





  • A VM can serialize all of its state (including RAM)

    • A VM image is simply a collection of files

      • Disk partitions, RAM, configuration file

    • Such image can be easily moved (migrated) between hypervisors of the same type

    • Such image can also be saved and used for rollbacks






Guest OS


Guest OS


Guest OS


Virtual Machine Monitor (VMM) / Hypervisor


Grid Middleware III58

Types of virtualisation

  • Depending on the layer you virtualize you will end up with a different VM

    • API: language VMs (JVM)

    • ISA: system VMs (VMware)

  • Different types of system virtual machines

    • Full virtualization (VMware)

      • Run multiple unmodified guest OSs

    • Para-virtualization (Xen, UML, Denali)

      • Run multiple guest OSs ported to a special architecture

    • Single OS image (Vserver)

  • What is the cost of using VMs?

    • Paper by Kate Keahey et al. “From Sandbox to Playground: Dynamic Virtual Environments in the Grid”, Grid 2004

from: Kate Keahey’s PPAM 2005 talk

Grid Middleware III59





























SPEC INT2000 (score)

Linux build time (s)

OSDB-OLTP (tup/s)

SPEC WEB99 (score)

Benchmark suite running on Linux (L), Xen (X), VMware Workstation (V), and UML (U)

The Need for Speed

Paper: “Xen and the Art of Virtualization”, SOSP 2003

Grid Middleware III60

What Makes VMs Great

  • Summary of VM properties:

    • Good isolation properties

      • Generally enhanced security, audit forensics

    • Excellent enforcement potential

      • Details depend on implementation

    • Customizable software configuration

      • Library signature, OS, maybe even 64/32-bit architectures

    • Serialization property

      • VM images (include RAM), can be copied

    • The ability to pause and resume computations

      • Allow migration

  • How do we make VMs available over the network and manage them so as to leverage this potential?

    • Challenges: security, enforcement, protocols

from: Kate Keahey’s PPAM 2005 talk

Grid Middleware III61

What are Virtual Workspaces?

  • Virtual Workspaces: environments that can be made available dynamically the Grid

    • well-defined properties in terms of environment definition and resource usage enforcement

  • Examples:

    • A physical cluster booted to a desired configuration (e.g. Cluster on Demand)

    • A Grid3 node dynamically configured using Pacman

    • A cluster partition configured with a hypervisor

    • A VM representing an OSG configuration enforcing memory and CPU usage

  • Workspaces can be implemented using a variety of technologies

    • VMs are the most promising

from: Kate Keahey’s PPAM 2005 talk

Grid Middleware III62

Virtual Workspace

  • Environment Aspect (workspace meta-data)

    • Information/state that outlives its deployment

      • Generic information (name, time to live)

      • Attested software partition information: OS, “OSG configuration”, “application installation”, etc.

      • Services: ssh, GRAM, pre-configured job

  • Resource allocation request (deployment time)

    • Flexibly negotiated within desired constraints

      • See GGF WS-Agreement standard

    • Memory, disk, networking, etc.

      • See GGF JSDL standard

    • On deployment the actual resource allocation information becomes available for inspection

  • Atomic workspaces and virtual clusters

    • Clusters are simply aggregate workspaces

from: Kate Keahey’s PPAM 2005 talk

Define workspace environment

Manage workspace

Negotiate workspace deployment characteristic

Grid Middleware III63

request a workspace

workspace meta-data

negotiate workspace deployment


workspace deployment


Deploying Workspaces in the Grid



(VW Factory)

manage workspace environment




(VW Repository)

workspace metadata



(VW Manager)

terminate workspace deployment

manage activities within the workspace

from: Kate Keahey’s PPAM 2005 talk

Grid Middleware III64

Current Implementation

  • Current prototype using Globus Toolkit 4

    • Leveraging standard Grid Service features

  • Workspace Wizard

    • Returns workspace meta-data

    • Very rudimentary implementation

  • Workspace Service

    • Create: takes workspace meta-data and a deployment descriptor

    • Manage:

      • renegotiate resource allocation

      • Also traditional Grid Service management: TTL, etc.

    • Destroy

      • Different options: pause, shutdown or destroy

  • First tech preview release expected later this month

from: Kate Keahey’s PPAM 2005 talk

Grid Middleware III65

How dynamic is the deployment?

  • Automatic

    • Protocol-based

    • Moving towards better articulation of migration

    • Renegotiation of resource allocation

  • How fast is this deployment?

    • Deployment of workspace for EMBOSS suite:

      • Manual: ~45 minutes

      • Based on pre-configured Vmware VMs: ~6 minutes

      • Based on pre-configured Xen VM: < 1 second

  • How much overhead does workspace deployment add over what we have today?

from: Kate Keahey’s PPAM 2005 talk

Grid Middleware III66

How much deployment overhead are we adding?

  • Using a paused VM allows us to “save” on initiation time

GRAM job execution

GRAM job execution in a paused Xen VM

job execution in a booted Xen VM (pre-configured job)

from: Kate Keahey’s PPAM 2005 talk

Grid Middleware III67

Virtual Grids?

  • In principle, VM technology opens the possibility for virtual grids, built as overlay networks

    • for full virtualisation need a VPN between the VMs as well

  • but policy and deployment issues remain

    • regulatory and system sanity requirements for hosting providers to know who is running where

Grid Middleware III68

Virtual Grid

Virtual Playgrounds


from: Kate Keahey’s PPAM 2005 talk

Access Control to Services

Fine grained control within the integrated framework

Grid Middleware III70

AuthZ in the container

  • authorisation decision taken in the stub (hosted by the container)

  • service provider business logic does not see the authZ

  • today, does not even get the list of attributes back for perusal

  • challenge for services that themselves are concerned with ACLs …

Grid Middleware III71

AuthZ for fine-grained services, pre-WS

From: Ann Chervenak Authorization for Globus Replica Services, EGEE Design Team Meeting, ANL 2005

Grid Middleware III72

Policy Identifiers and Policy Engines

  • Associate entries in the RLS with one or more policy identifiers

    • E.g., policy identifier could represent an ACL

  • When a client attempts to create, update or access an RLS entry, the authorization framework invokes a policy engine

  • Policy engine understands how to enforce the policy associated with each policy ID

  • Assumption is that there will be a relatively small number of unique policies

    • Typically, data organized as datasets or collections, with permissions on all objects the same

From: Ann Chervenak Authorization for Globus Replica Services, EGEE Design Team Meeting, ANL 2005

Grid Middleware III73

AuthZ in a WS world with AuthZ stubs

From: Ann Chervenak Authorization for Globus Replica Services, EGEE Design Team Meeting, ANL 2005

Grid Middleware III74

WS-RF Version

  • The client request (1) is handled at the container level, where a custom authorization callout is performed.

  • The authorization callout passes the entire client request to a custom Policy Decision Point (PDP) (2).

  • Then the PDP queries the LRC (3) to obtain the policy identifiers associated with the request.

  • LRC returns list of unique policy identifiers to the PDP (4).

  • PDP passes the client information, requested operations, policy IDs and objects of the request to policy engine (5).

  • Policy engine queries associated policy database (6) to obtain the policies associated with policy identifiers.

  • The policy engine makes decisions to permit or deny the request and returns these decisions to the PDP (7).

  • The permit/deny decisions are passed to the custom authorization framework (8).

  • For permitted operations, the authorization framework passes the client request to the LRC for execution (9).

From: Ann Chervenak Authorization for Globus Replica Services, EGEE Design Team Meeting, ANL 2005

Network Access

Provisioning connectivity

Grid Middleware III76

Firewalls and NAT

  • Traditional site network protection has been centred around the concept of firewalls

  • some sites also adopt NAT

    • wrongly advertised as being a security solution

    • or because of supposed ‘lack of address space’

    • in fact, it is still used as it is the path of least resistance …

  • firewalls and NAT are the most common obstacles to grid computing

    • many protocols are not firewall friendly (like GridFTP); or

    • require inbound connectivity to the farm (service containers)

Grid Middleware III77

Firewall connectivity ‘white’ solutions

  • explicit application-level solutions

    • outbound connectivity only via external proxy boxes

    • move to transport over port 80 (http) and hope for dumb firewalls that are not packet-inspecting

      Jabber, R-GMA MON boxes, proprietary solutions

  • explicit solutions

    • connectivity provisioning & grid-aware firewalls/routers

    • similar to provisioning network links in a point2point setup like lambda provisioning

      EGEE DCS, GGF Firewall Issues RG work, …

Grid Middleware III78

Firewall avoidance, the ‘black’ methods

  • implicit brokering

    • trap program syscalls and route the traffic at the user level

    • dynamically select the systems that allow incoming traffic

    • or interpose a connection broker

      Condor Generic Connection Broker, Sonny’s work, …

  • tcp splicing

    • with two co-operating applications, transmit TCP packet serials out-of-band, synch them up, and try to fool the firewall

    • may take a long time, but it doesn’t break to the protocol

    • it is a dedicated abuse of the protocol that admins may detect and consider a crack.

      IBIS Java toolkit

Grid Middleware III79

Example: Dynamic Connectivity Service

see DJRA3.2 chapter 6

Next: once you’ve got access …

Compute and brokering services

  • Login