We have many use cases which assume that their workload management will be done with DIRAC. There is a catch-all instance at in production at https://dirac.egi.eu and a dev instance at https://dirac5.grid.cyfronet.pl/DIRAC/
There are actually two bits of DIRAC - the front end web interface and the back-end platform that talks to the grid:
- The front end talks OpenID Connect and AuthN/Z’s users who access the web interface
- The back end talks x.509 and AuthN/Z’s users who want to use platform functions - job submission, data catalogue, etc.
Also : the front end talks to the backend!
This is the missing bit - we need a piece of plumbing that gets a x.509 cert to the platform, when the user does things on the frontend. Clearly we want some interaction with the Master Portal here. A feature might be:
Feature: I can submit a job which needs an X.509 certificate, using only federated credentials Any user coming from certain federated identity providers can submit a job with DIRAC Scenario: A user from EGI SSO can submit a job Given a known user authenticates to the DIRAC web interface Then they can see an authenticated view of it When they click on submit job Then a proxy certificate is retrieved by DIRAC from the MasterPortal
A typical flow could be implemented like this:
- User goes to web interface.
- Clicks on “log me in”
- Usual flow through Check In
- User has context in the front-end - service authorises the user based in some group management system.
- User wants to submit a job - clicks on “submit job” – currently, this requires uploading a cert or proxy.
- Frontend contacts Master Portal to request an x.509 proxy cert, sending the claims of the user
- Master Portal sends back a proxy cert to some end point of the frontend (callback url, e.g.)
- Proxy certificate is used to submit the job.
- Job runs.
- User wants to get the status. The proxy cert has now expired. Do 3 again.
Can we get some critique of this?