-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggestions for SSO next #18
Comments
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 The actual contents of the 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 |
The 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:
The standard_id describes a form POST the client can make to that access_url and expect to get a 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?The text was updated successfully, but these errors were encountered: