Portal working group meeting ------------------------------------------------------------------------ 02 May 2007 Present: Dave Kelsey, David Groep, Charles Loomis, Cristophe Blanchet (chair), Gidon Moont, Kuba Moscicki, Jens Jensen (mins) Get requirements, review experiences Gidon represents the GridPP portal. Cal suggests need to find someone from pgrade and genius. And gridsphere, pgrade is based on gridsphere. Need a basic list of use cases developed during this workshop. ** Bioinformatics portal (Christophe): anonymous access. 5000 analysis per day (avg). Users use the same credential. Use case: people putting data into SE through portal. Bioinformatics web services: biologist define workflow, using Triana or Taverna - any SOAP client can be used. Workflow should be another use case. Workflow clients are not portals - "thick" clients, need SSL. Possible to get credential out of MyProxy. Anonymous, or asking user for certificate. Requirement is ease of access, not really anonymity? Low assurance visitor account for trying things out. Use case for anonymity (or pseudo) would be hiding who is interested in what. OK if user authenticates to portal and portal is "anonymous". What is the minimal amount of logging required. Cap anonymous use of resources? ** GridPP portal (Gidon): using gridsite (Apache auhtentication module), make a proxy available, java web start starts thingy that can pick up PKCS#12 credential to create proxy on client machine, then gets an attr certificate. Using glite trust manager or myproxy server. Use case: VOMSifying a non-VOMS proxy: first proxy off the cert is used to get attr cert which is then embedded into second proxy generated from the user cert. Can only create a new proxy with the attr cert inside it. VOMS should be updated to assign the attr cert to the proxy, so the proxy's proxy is validated. Gidon built his own VOMS server, the SHEBANGS (Manchester) project also has something. With a few users, quicker sometimes to train them to use a UI. Portals not handling data transfer well - should not go via the portal itself! Interested in SRM-transfer to/from user's machine via HTTP - DPM and dCache support HTTP (or HTTPS, or both). CASTOR doesn't. Use case: portal handles (delegated) credential on behalf of the user. What is best practice for this. Dedicated machine. Not all people who want one will be equally security conscious. Comparable to an RB - any central resource to which people delegate - sees everybody's proxies. GACL (in gridsite) can authenticate on VOMS FQAN. Can also authenticate based on partial DNs, but therein lie dragons (bad ones), avoid. OGSA-AuthN should be looking into delegation. ** Cal made a presentation as a "small site person": need to identify users. A service certificate should reveal who to contact, to be able to see who is doing/is responsible for what. More information in the certificate than the DN. Users OK, but service and host certificates treated inconsistently across CAs. Specific VO role attached to a service? On the ops side, local groups want to run a portal - need recommendations on technology and setting them up, in addition to best practices. How to migrate between them. ** Discussion In STFC (RAL's research council) there is a group chasing the latest portal technology [at the Daresbury laboratory]: stringbeans, uPortal, CHEF, Sakai, ... Portal particularly needs to protect "its name" when many users are using the same portal credential to access resources. Genereate an attr cert for the job with more information, with user and IP address. Can you ask for traceability in general, or do you need a warrant. Country dependent. Need disclaimer on the portal. Can we trust other CAs. Other CAs might issue in somebody's namespace (so need the nasty VOMS solution), also may not be technically compatible. Use cases for this exist. Similar to Shibboleth and other authentication methods. Five levels of authn: 1. anonymous, 2. pseudonymous, 3. id'ed users but not with certs, 4. id'd users with grid creds but doing stuff with separate creds, 5. id'd users with certs which are used to do stuff. The "warm and fuzzy" is even better, with a validated reasonable representation of the person's identity embedded in the DN. Improves traceability. Need mapping to how many capabilities the portal provides to the user. And perhaps limits on resources for the unauthenticated. What is the scope of the group? Need to be pragmatic. Best practice important. How do we provide technical recommendations, do we need to try things out? Collate existing information. ------------------------------------------------------------------------ 03 May 2007 Present: David Groep, Gidon Moont, Christophe Blanchet (ch), David Kelsey, Jens Jensen (mins), Kuba Moscicki Uptake of 1999/93/EC and e-Identification slow, Estonia has got it. Thus started own Grid CA group, with separated authentication from authorisation. Approximately same level of authentication guaranteed by accredited CAs. New challenges with Levels of Assurance (LoA). When host/assurance are ill defined, raise the assurance level: robots ("automated entities") could be a solution. Conversely, for a low assurance level, it may be restricted how much you can do. Do user have to be in a VO, or can the portal itself decide which resources the users have access to. The portal could create its own attr cert. Other use cases for robots include automatic replications, automatically running jobs, monitoring, encrypted mail handling. Three existing cases: users use exisiting high (medium) assurance certificates, or myproxy generated certificates, or only to the portal. Which policies are imposed on users when they use a portal? Users should be tied to the purposes of the VO - how will this be done for portals? Can portals be covered also by the services requirements document coming out of the JSPG, or do we need a new document? Suggest joint meeting with JSPG, when enough progress has been made here. EGEE meeting in Budapest - planning 2nd meeting of this wg in June. Can the portal (or a robot) be a member of the VO rather than the users? Then the portal will have to protect the resources rather than the resources themselves (or rather, in addition to the resources protecting themselves). Middleware needs better protection. Also, VOMS server certificates need to be deployed with the current middleware. Migration for existing portals? Take back to existing portals. What about semi-anonymised services, like pilot jobs. Long term idea is glexec. JSPG is looking at policy for this; this group should look at the "classical" portal stuff.