= 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 Id``P (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 Id``P 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 Id``Ps, 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.)