Open aragilar opened 1 year ago
Hi @aragilar
Personally I think this is a good place for conversations.
Those all seem like good suggestions. A question though: I'm curious as to how brokers (or proxies), such as cilogon, are able to make longer-lived tokens than the OAuth ones obtained from an OIDC flow. Is it that they are managing refresh tokens on behalf of users?
The contents of the token provided to the VO service under the ivoa_token
flow would be unrelated to the contents of any token given by CILogon or similar. The idea would be there's a token issuing service, which has a web UI which acts at the OAuth/OIDC client for CILogon and then is a client itself for some other provider (so you can defer the authentication side to other providers), and gives the user back some string to copy into their client (generated however the service wants, with whatever expiry it wants). This is what rclone (https://rclone.org/) does if you're trying to login to a service on a headless machine, and solves the "but I need a real web browser" part of the flow.
The actual contents of the ivoa_token
shouldn't matter, as allows providers to stick whatever they want in there (https://fly.io/blog/api-tokens-a-tedious-survey/ has list of possible things you could stick in there).
I'd expect services which are happy (or are allowed) to run and manage their own login infrastructure (so as to avoid the need for browsers in the flow) won't need this, and the existing ivoa_
options are fine for them, but for providers where they are deferring this to systems which require browsers, it will be less work for clients and providers if there's an escape hatch which means users only need to login with a browser in one place, and be able to access the data they want on remote systems (e.g. on cloud-provided notebook servers).
The ivoa_token
suggestion is a nice idea, but if I understand it correctly there is a problem.
I think you are suggesting that a data service A advertises the URL of a token-providing service B so that a user can go to B, present their credentials there and get a token to use when talking to A.
The trouble is that an unrelated malicious service C could advertise B as its token-providing service so that users will get tokens there and pass them back to C. C then has possession of tokens that enable it to masquerade as authenticated users when talking to A.
To get round that you would presumably need some kind of scoping rules so that service B restricts the places the tokens it issues can be used. It might be possible to invent such, but it would add complication. Cookies on the other hand do come packaged with such scoping.
I think cookies are definitely preferable where they're an option, but I'm not sure how you'd get the cookies out of a web browser in a form that users could copy to a different client? The workflow of running the authentication in a browser, and then copying a returned credential to a client (which could be on your local machine, but could also be on a headless server) was what I was trying to enable, based on the similar workflow rclone provides. I'll be at ADASS/IVOA next month, it might be easiest if I show how rclone handles authenticating, rather than trying to explain it over text.
Yes, I wasn't saying cookies could do the same job. I think what you're saying would work, it just opens up a major security hole. Anyway yes! let's talk in Tucson.
Cookies can be made accessible easy to use by a client like topcat with something like this:
www-authenticate: ivoa_cookie standard_id="ivo://ivoa.net/sso#tls-with-password",
access_url="https://{server}/cookie-issuer
The standard_id describes a form POST the client can make to that access_url and expect to get a set-cookie
in the response. The cookie would be known to be valid for any calls to {server} or maybe the domain that server is in (I don't recall off hand how one tells if that's know to be OK, but we issue cookies that work for www.domain (UI apps) and ws.domain (services) and browsers are fine with that.
It does mean that you don't get seemless single-sign-on across multiple domains (eg www.cadc... and www.canfar... -- self-inflicted pain there!) but a client could use the same cookie to authenticate to several services in the same domain (eg TAP, DataLink, SODA, storage system at CADC). A client would need to get another one to jump over to VOSpace in the CANFAR domain, but that's not so bad.
Cookies do work well for a client like topcat as Pat describes. However they may not be so suitable for cut'n'paste command-line usage which I suppose is what something like rclone needs, since as well as the cookie (set-cookie header content) itself, the client is supposed to do some other header manipulation associated with (optional) domains, paths and expiry dates - see RFC 2965.
I'm not sure if suggestions/comments should go here, or via the mailing list, so happy to mirror them there if it helps. Anyway, here's some in the context of planning for adding authenticated TAP at Data Central:
I find the SSO next to be much more understandable than the previous version, but I think there's some tightening up that could be done. First, it's somewhat implied that a service can run "standard" (i.e. IETF registered) authentication methods, and that the
ivoa_
based ones should go before those (to ensure correct fallback), but I didn't see that spelled out explicitly. As a follow up, explaining that for methods that do not require redirects (e.g. Basic Auth) can just use the existing standards, and that clients should support those in addition to theivoa_
based ones. Also, being more explicit about where the credentials are encoded in the response (e.g. what if multiple cookies are set?) would I think help.Also, I wonder if it's worth adding a
ivoa_token
method, which provides a URL for users to visit to get the token, and a short user-facing text string telling users what they should do. This would allow for setups where there may be multiple providers involved (e.g. allowing logins via services like https://www.cilogon.org/, which act as a single broker over many universities; or where there's MFA and other security involved), and so rather than require clients to try to handle complex OAuth flows, the tokens are long-lived enough to avoid frustrating users?