|
Size: 1794
Comment:
|
Size: 2230
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 5: | Line 5: |
| BRIDGES portal: | DyVOSE (ESP-GRID) portal: |
| Line 7: | Line 7: |
| Portlets inside it for BLAST/BRIDGES, DyVOSE search/sort and VOTES data federation framework. | |
| Line 9: | Line 10: |
| (only need DN from user - would have made this more sophisticated if time and app. permitted it) search/sort portlet |
(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) |
| Line 16: | Line 17: |
| DyVOSE | |
| Line 18: | Line 20: |
| VOTES project proto-typing now. Definied 3 roles for the prototype. Clinical databases. Will deliver the roles to the SP via shibboleth. | 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. Plan for demonstrators: (see below) |
| Line 27: | Line 34: |
== Demonstrators == Rich to send URLs and usernames/passwords with different roles. BLAST, DyVOSE (search/sort) and VOTES. |
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.
Plan for demonstrators: (see below)
Overview of aims and work still to be done
Alun: interviews etc. about development process evaluation
Demos of shibbed BRIDGES, ?DyVOSE?, ?VOTES? etc.
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
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.)