https://docs.google.com/document/d/12rttHPhNZ2o-kTVHRpnfco535idQoBDCh_pyGu1562I/edit?usp=sharing
(a) This is the right solution and I wish we could make ppl understand that it represents a higher level of security;
- if a person from site A has access to data at site B, but then leaves, site B can only stop access if site A notifies them
"Ahh" says the ITSEC person at site B "but we are protected by whitelisting of IP addresses"
BUT the person from site A moves to site C, which is whitelisted. The person still has access to the system even if their new job doesn’t require it
- I think the difficulty from your dgm is the site has to maintain a list of external email accounts. OK, I know this *should* be trivial, but having gone through changes to organisational email addresses before, there could be some reluctance to support this (and it would mean a change to the process)
- Now thinking with my ITSEC hat on; how do we prevent spoofing of email addresses? I assume this is handled by a reverse lookup to the site
- Finally - what happens if your site is not associated with EDUGAIn or checkin?
'UDA' must be extended to allow not only `X.509` based authentication/authorization but also one based on bearer tokens (OAuth2.0 Access Tokens).
==> This should be possible, but means you cant access ITER data which requires X509
This is why we need changes inside UDA - it must support other means of authentication as well.
by default, any authenticated user is granted very limited access,
==> not sure what you are envisaging here
We can either allow people to access data directly inside CatalogQT or we can do it at experiment side.
If we decide to allow people access sites by giving them access rigths inside CatalogQT, we assume that people start with very limitted power and can get more by requesting particular features - e.g. accessing external sites.
In this case, external sites have to trust us - I am not sure if this is possible.