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.
There are minutes attached to this event.
Show them.
