OGF2225th February 2008

OGF22 Demo Slides

Prof. Richard O. Sinnott Technical Director, National e-Science Centre

University of Glasgow, Scotlandr.sinnott@nesc.gla.ac.uk

OGF2225th February 2008

Shibboleth ScenarioService provider

ShibFrontend

5. Pass authentication info and attributes to authZ function

Grid Portal

6. Make final AuthZ decision

Grid Application

Identity Provider

Home Institution

W.A.Y.F.

Federation

User1. User points browser at Grid

resource/portal

2. Shibboleth redirects

user to W.A.Y.F. service

3.User selects their

home institution

4. Home site authenticates user and

pushes attributes to the service provider

AuthNLDAP

LDAPAuthZ

?

What sites +

attributes to

accept (trust)?

What attributes to send?

Only see/use what

allowed to?

uid

Log-in once and roam

OGF2225th February 2008

Centralised Shibboleth Scenario

Service provider

5. Pass authentication info and attributes to authZ function

Grid Portal

6. Make final AuthZ decision

Grid Application

Identity Provider

Home Institution

W.A.Y.F.

Federation

User1. User points browser at Grid

resource/portal

2. Shibboleth redirects

user to W.A.Y.F. service

3.User selects their

home institution

4. Home site authenticates user and

pushes attributes to the service provider

AuthNLDAP

LDAPAuthZ

VO wide

authZ

OGF2225th February 2008

VOMS

OGF2225th February 2008

VOMS

OGF2225th February 2008

VOTES

Virtual Organisations for Trials and Epidemiological Studies

3 year (£2.8M) MRC funded project started October 2005Plans to develop framework for producing Grid infrastructures to address key components of clinical trial/observational study

Recruitment of potentially eligible participants Data collection during the study Study administration and coordination

– Involves Glasgow, Oxford, Leicester/Nottingham, Manchester, Imperial

» Direct links with UK Biobank, Generation Scotland Scottish Family Health Study

Clinical Virtual Organisation Framework

IMP

CVO-2 (e.g. for

recruitment)

Used to realise

GPs

Lei- Nott GLA

OX

Disease registries

Hospital databases

Transfer Grid

CVO-1 (e.g. for data collection)

Clinical trial data sets

OGF2225th February 2008

VOTES Distributed Data Framework

OGSA-DAIService

GlobusContainer

PortalGrid Server Data Server

DrivingDB

SCI Store 2(SQL Server)

SCI Store 1(SQL Server)

Consent DB(Oracle 10g)

RCB Test Trials DB

(SQL Server)

User Authentication

GlasgowOther

Transfer Grid

Nodes

Remote Trust Policies

Authorisation Access Matrix Security Policies

Access Security Policies

Local Trust

Policies

Local Trust

Policies

Local Trust

Policies

OGSA-DAIService

GlobusContainer

PortalGrid Server Data Server

DrivingDB

SCI Store 2(SQL Server)

SCI Store 1(SQL Server)

Consent DB(Oracle 10g)

RCB Test Trials DB

(SQL Server)

User Authentication

GlasgowOther

Transfer Grid

Nodes

Remote Trust Policies

Authorisation Access Matrix Security Policies

Access Security Policies

Access Security Policies

Local Trust

Policies

Local Trust

Policies

Local Trust

Policies

Service

OGF2225th February 2008

Existing Demonstration(pushing attributes in

SAML)

OGF2225th February 2008

OGF2225th February 2008

OGF2225th February 2008

OGF2225th February 2008

OGF2225th February 2008

OGF2225th February 2008

OGF2225th February 2008

OGF2225th February 2008

VOMS’ing

OGF2225th February 2008

The Scenario

GT4-VOTESVOTESdiabetes

Client

GT4-VOTESVOTESdiabetes

ServicePEP OGSA-DAI

PERMISPDP

Deny/Grant

GSI-based security

DB2

DB1

DB3

VOMS Server

Voms-proxy-init VOMS credentials

VOMS PIP

collectAttribtues VOMS validated attributes

VO=nanoCmos

AuthZ request

(1) A VOTES diabetes service is deployed on a GT4 infrastructure(2) A user runs “voms-proxy-init” to generate a proxy certificate including VOMS credentials (3) and tries to invoke the protected stored procedure(4) The PEP passes the user information (including proxy certificate) to the VOMS PIP(5) VOMS PIP validates the credentials and passes back the VOMS Fully Qualified Attribute Name (FQAN) within the subject attributes. (6) The PEP calls the PERMIS PDP pushing the request information and credentials(7) The PERMIS PDP according to the policy decides if this user with certain attributes is authorized to access the service. (8) If successful the stored procedure is invoked, the federated query run and returned results joined and returned to the end user

OGF2225th February 2008

OGF2225th February 2008

Successful Nurse Interaction

Unuccessful Nurse Interaction

=> java -classpath ./build/stubs/classes/:$CLASSPATH org/globus/clients/DataFederationProxy/SecureGSNurseClient security-configRichard.xml

=>java -classpath ./build/stubs/classes/:$CLASSPATH org/globus/clients/DataFederationProxy/SecureGSDoctorClient security-configRichard.xml

OGF2225th February 2008

OGF2225th February 2008

Successful Nurse Interaction

Successful Doctor Interaction

=> java -classpath ./build/stubs/classes/:$CLASSPATH org/globus/clients/DataFederationProxy/SecureGSNurseClient security-configRichard.xml

=>java -classpath ./build/stubs/classes/:$CLASSPATH org/globus/clients/DataFederationProxy/SecureGSDoctorClient security-configRichard.xml

OGF2225th February 2008

The Scenario with Permis (VPMan)

OMII-nanoCMOSGeronimo client

OMII-nanoCMOSGeronimo ServicePEP GridSAM

PERMISPDP

OMII-PERMIS AuthZ request

Deny/Grant

SGE

NGS/ScotGrid

Condor

VOMS Server

VOMS PIP

collectAttribtues VOMS validated attributes

VO=nanoCmos

GridSAM

GridSAM

MyProxy

WS-security = Message Level Security,

1

2

3

4

5

6Subject PIP

(1) The client attempts to invoke the PERMIS protected Geronimo service. The PEP extracts the users DN and identifies that it needs attributes from a VOMS server(2) The PEP, via a Subject PIP, pulls back the relevant attributes from VOMS server (3)and passes them to the PDP(4) The permis PDP makes the decision (5) and if ok, submit job using via GridSAM to appropriate Grid Resource