Site access control
1 / 78

Site Access Control - PowerPoint PPT Presentation

  • Uploaded on

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

PowerPoint Slideshow about 'Site Access Control' - wesley

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

Site Access Control

Grid Middleware 3

David Groep, lecture series 2005-2006


Grid Middleware III 2


  • 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

Authorization stakeholders a reminder

Grid Middleware III 3

Authorization Stakeholders, a reminder

Site access control1

Grid Middleware III 4

Site Access Control



user space


Site Proxy


















Transport level security



What problems should we solve

Grid Middleware III 5

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

What to do

Grid Middleware III 6

What To Do?

  • collect policies that need to be enforced

  • collect the information on which to base the decision

  • make the decision

Distinct pieces in the process flow

Grid Middleware III 7

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)

Architecture for local access control

Grid Middleware III 9

Context cache

PEPService ormessageinterceptor






User inblacklist?

RetrieveVO info

Retrievelocal info


Chain 1



Chain 2


= PAP accessible interface

Architecture for Local Access Control

Authorization framework components

Grid Middleware III 10

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

A perfectly integrated model

Grid Middleware III 11

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

Issues with an integrated model

Grid Middleware III 12

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)

Issues with the model 2

Grid Middleware III 13

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

Local policy today mapping credentials

Grid Middleware III 14

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

Implementations today

Grid Middleware III 15

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!

The c world job submission and gridftp

Grid Middleware III 17

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

Job submission components

Grid Middleware III 18

Job submission components

most simple case

  • make access decision

  • figure out a local policy mapping (unix account)

  • log what you did

  • run the job

Job submission classic case

Grid Middleware III 19







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

Policy decision modules

Grid Middleware III 20

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

Pdp configuration

Grid Middleware III 21

PDP configuration

  • A PDP is driven by a policy language

    • typical choice is XACML

Policy languages

Policy languages

Driving the PDP

Policy evaluation a reminder

Grid Middleware III 23

Policy Evaluation (a reminder)

Policy languages1

Grid Middleware III 24

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 

Saml conveying assertions

Grid Middleware III 25

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

Saml assertion types

Grid Middleware III 26

SAML assertion types

  • Authentication Assertion

  • Attribute Assertion

  • Authorisation Decision

All assertions have some common information

Grid Middleware III 27

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

Attribute assertion

Grid Middleware III 28

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”

Saml attribute assertion

Grid Middleware III 29

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>

Authz decision assertion

Grid Middleware III 30

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

Saml authorization decision assertion

Grid Middleware III 31

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>

Xacml access control

Grid Middleware III 32

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

Xacml policy type

Grid Middleware III 33

XACML policy type

Xacml rules

Grid Middleware III 34

XACML rules

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

Xacml request example

Grid Middleware III 35

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,

Xacml policy login from 9 am to 5 pm

Grid Middleware III 36

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







Simpler policy languages

Grid Middleware III 37

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

Gacl example

Grid Middleware III 38

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>

<entry> <voms-cred> <vo>iteam</vo> <group>/iteam</group> </voms-cred> <allow><read/><write/></allow> <deny><list/><admin/></deny></entry></gacl>

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

Credential mapping

Credential mapping

and virtual workspaces

Credential mapping1

Grid Middleware III 40

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 mapfile

Grid Middleware III 41


  • 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 III 42


  • 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

Gridmapdir associations

Grid Middleware III 43

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


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

Lcmaps functionality view

Grid Middleware III 45

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)

Lcmaps control flow

Grid Middleware III 46

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

Lcmaps acquisition and enforcement

Grid Middleware III 47

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

Lcmaps modules

Grid Middleware III 48

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)

Lcmaps policy evaluation

Grid Middleware III 49

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

Voms to unix domain mapping

Grid Middleware III 50

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

Voms to unix domain mapping1

Grid Middleware III 51

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

Lcmaps caveats

Grid Middleware III 52

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.

Work space service

Grid Middleware III 53

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

Workspaces and accounts

Grid Middleware III 54

Workspaces and accounts

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

  • ought to be provides like one

Work space service1

Grid Middleware III 55

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

Lcmaps usage with the wss

Grid Middleware III 56

LCMAPS usage with the WSS


Grid Middleware III 57





  • 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


Types of virtualisation

Grid Middleware III 58

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

The need for speed

Grid Middleware III 59





























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

What makes vms great

Grid Middleware III 60

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

What are virtual workspaces

Grid Middleware III 61

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

Virtual workspace

Grid Middleware III 62

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

Deploying workspaces in the grid

Define workspace environment

Manage workspace

Negotiate workspace deployment characteristic

Grid Middleware III 63

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

Current implementation

Grid Middleware III 64

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

How dynamic is the deployment

Grid Middleware III 65

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

How much deployment overhead are we adding

Grid Middleware III 66

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

Virtual grids

Grid Middleware III 67

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

Virtual playgrounds

Grid Middleware III 68

Virtual Grid

Virtual Playgrounds


from: Kate Keahey’s PPAM 2005 talk

Access control to services

Access Control to Services

Fine grained control within the integrated framework

Authz in the container

Grid Middleware III 70

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 …

Authz for fine grained services pre ws

Grid Middleware III 71

AuthZ for fine-grained services, pre-WS

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

Policy identifiers and policy engines

Grid Middleware III 72

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

Authz in a ws world with authz stubs

Grid Middleware III 73

AuthZ in a WS world with AuthZ stubs

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

Ws rf version

Grid Middleware III 74

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

Network Access

Provisioning connectivity

Firewalls and nat

Grid Middleware III 76

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)

Firewall connectivity white solutions

Grid Middleware III 77

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

Firewall avoidance the black methods

Grid Middleware III 78

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

Example dynamic connectivity service

Grid Middleware III 79

Example: Dynamic Connectivity Service

see DJRA3.2 chapter 6

Next once you ve got access

Next: once you’ve got access …

Compute and brokering services