OpenID challenge
Mark Taylor
m.b.taylor at bristol.ac.uk
Mon May 9 14:13:31 CEST 2022
Hi Paul.
the suggestions here are not supposed to replace the standard
browser-friendly SSO flows. If you look at e.g. the example from
page 8 of https://wiki.ivoa.net/internal/IVOA/InterOpApr2022GWS/auth.pdf
you can see some non-standard (SSO-defined) challenges
"ivoa_bearer" and "ivoa_x509" alongside the vanilla RFC 6750
challenge "bearer". The ivoa_* ones we are defining here are
just for the benefit of non-browser clients; browsers will ignore
them and use instead the standard "bearer" challenge to do ...
whatever they were going to do anyway, which may include the
complex reCAPTCA/2FA/whatever user interactions that you mention.
Service providers (e.g. ESO?) that are only willing to serve data to
users authenticating via browser-based flows won't use these ivoa_*
schemes at all. Those (e.g. CADC?) who are willing to accept a
username+password acquired by a non-browser client can use these
schemes in order to give clients enough information to supply them.
Mark
On Mon, 9 May 2022, Paul Harrison wrote:
> Hi,
>
> I have not really been following the SSO developments, but I feel that what is being proposed here might not be “standard enough” that browsers would be able to follow the SSO being attempted. The first point is that the responses are outside the WWW-Authenticate header registered schemes https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml - this in itself might not absolutely disqualify the suggested schemes themselves, but I think that the pattern of responses that they imply might be more troublesome. Many of the SSO flows actually begin with a “redirect” to the IdP with the original URL as a “callback” query parameter in the case that authentication is required when the server detects that the required authentication tokens are not present rather than a 401 response. I think that in these scenarios the 401 response is generally restricted to the case where a presented token is invalid in some fashion, and then I think that the protocols
generally expect the browser to try the original target URL without presenting tokens in order to be redirected to the authentication again (though this can get messy). If the “redirect” url is encoded in the 401 WWW-Authenticate header in a non-standard fashion as suggested below, the it seems to me that a standard browser client cannot “understand” it.
>
> The fact that the SSO flows tend to start with a re-direct also has a bearing on another part of the discussion in this thread - the page redirected to can contain a complex UI (including elements that the user can recognise so that they can know that they are entering their credentials into a trusted server) and all sorts of custom logic (reCAPTCHA, 2FA etc) - it would be fruitless for non-browser clients to try to implement support all this as it is so fast changing. I think that it is the main thinking behind browsers being the “trusted” clients in these SSO scenarios. Therefore I think the best strategy for non-browser clients is to just accept that they are going to have to have this browser interaction step in the flow.
>
> Cheers,
> Paul.
>
>
> > On 2022-05 -09, at 11:22, Mark Taylor <m.b.taylor at bristol.ac.uk> wrote:
> >
> > If you agree, I can draft a PR setting this out as an update
> > for the text in the current Section 2.1.
> >
> > On Wed, 4 May 2022, Mark Taylor wrote:
> >
> >> Pat,
> >>
> >> [I'm taking this to the GWS list for transparency, I take it you
> >> don't object, probably I should have done that in the first place]
> >>
> >> If #tls-with-password has to define all those return type options,
> >> then #BasicAA would have to do the same thing too.
> >> Coupling the standard_id with the auth scheme like this mixes up
> >> concerns in a messy way.
> >>
> >> If you want to separate What and How, it would be cleaner to define
> >> schemes:
> >>
> >> "ivoa_bearer" with params standard_id, access_url:
> >> get back a Bearer token in the x-vo-bearer header
> >> (at access_url, presenting user/pass as per standard_id)
> >>
> >> "ivoa_cookie" with params standard_id, access_url:
> >> get back a cookie in the usual way (set-cookie header)
> >> (at access_url, presenting user/pass as per standard_id)
> >>
> >> "ivoa_x509" with params standard_id, access_url:
> >> get back a certificate in PEM format in the body
> >> (at access_url, presenting user/pass as per standard_id)
> >>
> >> and standard_ids:
> >>
> >> ivo://ivoa.net/sso#tls-with-password:
> >> submit username and password as POST params
> >>
> >> ivo://ivoa.net/sso#BasicAA:
> >> submit username and password as per RFC7617
> >>
> >> OpenID defines both how to submit credentials (like standard_id)
> >> and how to receive and use a token for subsequent authenticated usage
> >> (like scheme) so it should have its own scheme:
> >>
> >> "ivoa_openid" with param access_url:
> >> do OIDC interaction in the usual way
> >> (at access_url)
> >>
> >> Do you forsee other challenge types that we will need to define?
> >>
> >> Seen like this, "standard_id" is not a very good name for "how to
> >> supply username and password", something like "login_type" would
> >> be better.
> >>
> >> Mark
> >>
> >>
> >> On Tue, 3 May 2022, Patrick Dowler wrote:
> >>
> >>> I think you are right that the scheme can't really define the return, so
> >>> we'll have to specify that #tls-with-password has these input form params
> >>> and returns tokens like this (x-vo-bearer header), cookies like that
> >>> (set-cookie header), and x509 proxy certs in pem format in the body (body
> >>> because multi-line format).
> >>> If we introduce a new scheme (type of returned credential) we'll have to
> >>> augment what #tls-with-password says.
> >>>
> >>> Then #OpenID also defines input and output (starting with appending the
> >>> well-known path to the access_url and on from there).
> >>>
> >>>
> >>> --
> >>> Patrick Dowler
> >>> Canadian Astronomy Data Centre
> >>> Victoria, BC, Canada
> >>>
> >>>
> >>> On Tue, 3 May 2022 at 09:00, Mark Taylor <m.b.taylor at bristol.ac.uk> wrote:
> >>>
> >>>> Pat (or Brian),
> >>>>
> >>>> I'm talking to Alberto about use of SSO_next at ESO.
> >>>> There are some difficulties, which I'll probably bring to the mailing
> >>>> list before too long, but I have a query to help me understand how
> >>>> usage is currently envisioned.
> >>>>
> >>>> CADC services currently issue a challenge like this:
> >>>>
> >>>> www-authenticate: ivoa_bearer standard_id="ivo://ivoa.net/sso#OpenID",
> >>>> access_url="https://ws-cadc.canfar.net/ac"
> >>>>
> >>>> How do you envisage this being used, and in particular, how is the
> >>>> token returned to the client? My (possibly incorrect) understanding
> >>>> of OpenID Connect is that it requires return of the token as a
> >>>> JSON Web Token.
> >>>>
> >>>> SSO_next says
> >>>>
> >>>> "The #tls-with-password standard defines the input (form params)
> >>>> and the challenge (ivoa_bearer) defines the output."
> >>>>
> >>>> but in the case of OpenID it seems that the standard_id
> >>>> defines both the input and the output, so that the "ivoa_bearer"
> >>>> scheme is not doing any work. Then the scheme and standard_id
> >>>> are not orthogonal, and the existence of such cases is why I was
> >>>> resistant to organising the challenges in this way earlier in
> >>>> the discussion.
> >>>>
> >>>> Have I got it right, or is the OpenID response required to include
> >>>> the x-vo-bearer header as well as the JWT content?
> >>>>
> >>>> Mark
> >>>>
> >>>> --
> >>>> Mark Taylor Astronomical Programmer Physics, Bristol University, UK
> >>>> m.b.taylor at bristol.ac.uk http://www.star.bristol.ac.uk/~mbt/
> >>>>
> >>>
> >>
> >> --
> >> Mark Taylor Astronomical Programmer Physics, Bristol University, UK
> >> m.b.taylor at bristol.ac.uk http://www.star.bristol.ac.uk/~mbt/
> >>
> >
> > --
> > Mark Taylor Astronomical Programmer Physics, Bristol University, UK
> > m.b.taylor at bristol.ac.uk http://www.star.bristol.ac.uk/~mbt/
>
>
--
Mark Taylor Astronomical Programmer Physics, Bristol University, UK
m.b.taylor at bristol.ac.uk http://www.star.bristol.ac.uk/~mbt/
More information about the grid
mailing list