Quick review of the state of play

Mark reviewed the ESP-GRID workpackages and where the output is (going to be).

DyVOSE (ESP-GRID) portal: Single IdP (DyVOSE project) Portlets inside it for BLAST/BRIDGES, DyVOSE search/sort and VOTES data federation framework. Shib enabled access to the gridsphere portal

• collections of portlets - get access to different types of functionality depending on attributes from IdP

  • (only need DN from user for BLAST - would have made this more sophisticated if time and app. permitted it) search/sort portlet - roles (see below)

AuthN and AuthZ done at the portal level (the portal is the SP). Portlets also accept SAML Shib attributes but nothing written in there to go and get that extra info from the IdP yet. Portlets are different SPs from the portal itself. Difficult to choose which architecture you should use.

SSO to access the portal. BLAST service AuthZ done on the presentation of the DN.

DyVOSE Search/sort (DyVOSE project) AuthZ done by looking at PermisRole attribute containing "StudentTeam1" and "StudentTeam2" which was presented at the initial login to the portal (along with DN).

VOTES proof of concept VOTES project proto-typing now. Definied 3 roles for the prototype. Clinical databases. Will deliver the roles to the SP via shibboleth. Will deliver something before the end of March. Roles will be collected at log in to the portal.

• Set of databases. When user logs in role determines which DB they can access and whether they see anonymised or non-anon. data. NeSC team now working on an interface that the user can build his/her own queries.

Plan for demonstrators: (see below)

Overview of aims and work still to be done

In write up:

• Computer security = BRIDGES DyVOSE = VOs and collaborative access management VOTES = data security

For BRIDGES, look at Richard's Vienna paper for objectives and what they actually managed. e.g. 1st goal "An effective environment for biomedical bioinformatics..." Richard's text about sharing data issues.

Richard to send through some text for evaluating relevance to the VOTES project.

Services Applications BLAST is an application. If it got wrapped up via WSs, then it may be deemed a (grid) service.

Suggest for "Building on the above, routes for migration and/or integration should be proposed in order to achieve interoperability with regard to access controls between existing PKI-based grids and information environments." that lots of services/apps be developed for the (UK) research community. Real requirements analysis.

Alun: interviews etc. about development process evaluation

Alun to get a short list of questions and to contact some or all of the following.

John Watt - lots of time getting PERMIS to talk to Shibboleth.

Jipu - Portal stuff

Femi - involved in implementation aspects of ESP-GRID project (Shib interacting with Apache, Grid services with globus containers)

Micha Bayer - Grid/BLAST person and portlets, globus (at CCF for the next few days). David Leader's main contact.

Anthony Stell - did most work on setting up security infrastructures (with John). Lots of stuff with PERMIS.

Richard said that they've been working on 'experience reports' (e.g. got students to build policies with PERMIS - gave honest feedback). John could show us the how-to guides and troubleshooting etc. (e.g. error messages).

Demos of shibbed BRIDGES, ?DyVOSE?, ?VOTES? etc.

Done! Saved some screen dumps and information in a doc.

Next steps - reports and planning for deadlines.

Demonstrators

Rich to send URLs and usernames/passwords with different roles. BLAST, DyVOSE (search/sort) and VOTES.

Road map doc headings

Separation of types of users

Average researchers inappropriate heavyweight security.

UK federations

Lightweight exploratory federation for grid work

Scalability testing (of BRIDGES-like Shib enabled interfaces)

Rigorous assessment of MAMS type interface? Body like OMII to stress test and scale applications/services.

Standardisation of attributes wrt grids

And values therein. Licensing (e.g. Matlab). Do we need different attributes (and values) for grid computing?

• e.g. setting up VOs - similar attributes. Is this a different problem from the information environment?

VO demonstrators

And VO adminstrator admins the set of users etc.

Shib core improvements

Basic shib code

• - all of the add-ins PERMIS etc. being pluggable/ready

Backwards compatibility of Shib

• Too much of a moving target now - difficult for roadmap.

PKI core improvements

Secure issuing. Good revocation.

General security (patching, anti-virus etc. etc.)

Should this be tackled at the federation and/or CA level?

• Standards, auditing.

Other

Sharing usernames/passwords

• PKI extra level that is obvious to the user.

On the other hand...

Maybe it's too early to take security this seriously - we haven't got a working grid yet. In another ?2 years? a roadmap may be worthwhile.

Deadlines for reports/text

The three demonstrators

• what was difficult
• what worked with Shib well
• what clashed with AuthZ mechanisms
• set of pointers for how-to's
  • recipes:

    • see http://labserv.nesc.gla.ac.uk/projects/etf/evaluation/index.htm

    Shib installation walk-through:

    • http://labserv.nesc.gla.ac.uk/projects/dyvose/shibbolethSDSShowto.html

And talk about MATU.

Mark to write up the following text on the above (a few lines on each project). Richard to check.

• "We have shown that there are multiple grid services that can be enabled via your institutional SSO."

  • DyVOSE search/sort = initial demonstrator, showing authZ decision based on a string (e.g. "StudentTeam1") Pulled attribute out of LDAP server on log in to the portal. Using local CONDOR pool. BRIDGES/BLAST = Can submit jobs to remote grid machines (CN from Shib to make AuthZ decision). Host certificate for remote machines.

    VOTES = More data-focussed authZ. Same Shib mechanism as DyVOSE. (But AuthZ is far more complex).

Need to conclude that lots more documentation is needed for implementers to make it work (MATU trying to do this).

Any future collaborations?

vos

Getting attributes from 3rd parties

SSO - using 2 IdPs, or 2 federations.

Grid service - no proper discovery of authZ policies.

• Lack of discovering roles between VO entities.

MAMS service provider description file concept. Alternative idea - multiple SOAs.

(Include DyVOSE in Policy Management doc.)