Authentication progress

[Mark Taylor]

Dear GWS,

following the discussions about the way forward for Authentication/SSO
at the virtual interop
(https://wiki.ivoa.net/twiki/bin/view/IVOA/InterOpMay2020GWS#SSO)
and particularly Pat's presentation and strawman proposal:

   https://wiki.ivoa.net/internal/IVOA/InterOpMay2020GWS/auth-reqs-strawman.pdf

I have experimented with some implementation.
I'm also working with a prototype developed by ESDC on one of the
development versions of the Gaia TAP service which provides
challenges looking like this:

   WWW-Authenticate: Basic realm="Authentication needed",
                     ivo://ivoa.net/std/SSO#cookie
                     realm="Authentication needed",
                     accessURL="https://example.com/service/login",
                     userParameter="username", passwordParameter="password",
                     responseCookie="JSESSIONID"

Experiments so far are positive: some details to be ironed out,
but the basic approach seems to work.  I also think it's going to be
much more tractable, from the client side in any case, to do it this
way (respond to RFC7235 WWW-Authenticate challenges) than to go
looking for similar information from securityMethod elements in
capabilities documents.

Some more detailed thoughts below.

Auth-scheme syntax
------------------

   We can't use SSO ivo-ids as the authentication scheme identifiers
   in the WWW-Authenticate header: RFC7235 says that the auth-scheme
   identifier has to be an RFC7230 token, which disallows the "/" and
   ":" characters.  So challenges would have to look like e.g.

       WWW-Authenticate: vo-sso-cookie ...

   instead of

       WWW-Authenticate: ivo://ivoa.net/std/SSO#cookie ...

Creating custom auth schemes
----------------------------

   RFC7235 says:

      5.1.  Authentication Scheme Registry

      The "Hypertext Transfer Protocol (HTTP) Authentication Scheme
      Registry" defines the namespace for the authentication schemes in
      challenges and credentials.  It has been created and is now
      maintained at <http://www.iana.org/assignments/http-authschemes>.

   So there is an IANA registry for these schemes, but I don't think
   there's any problem if we want to dream up our own custom
   authentication schemes for internal VO usage.


Adding custom auth-params to existing authentication schemes
------------------------------------------------------------

   Pat queried whether we are allowed to augment a challenge like (RFC6750)

       WWW-Authenticate: Bearer

   with custom parameters along the lines:

       WWW-Authenticate: Bearer loginurl=https://example.com/login

   RFC7235 section 5.2.1 says:

      Definitions of new schemes ought to define the treatment of
      unknown extension parameters.  In general, a "must-ignore" rule is
      preferable to a "must-understand" rule, because otherwise it will
      be hard to introduce new parameters in the presence of legacy
      recipients.  Furthermore, it's good to describe the policy for
      defining new parameters (such as "update the specification" or
      "use this registry").

   so the legality of this is on a scheme-by-scheme basis.
   For Bearer in particular, RFC 6750 says (section 3):

      All challenges defined by this specification MUST use the auth-scheme
      value "Bearer".  This scheme MUST be followed by one or more
      auth-param values.  The auth-param attributes used or defined by this
      specification are as follows.  Other auth-param attributes MAY be
      used as well.

   So I think we're in the clear for adding custom params to
   Bearer/RFC6750/OAuth2.0.


Providing authentication confirmation to clients
------------------------------------------------

   Pat proposed:

      X-VO-Authenticated: true|false

   so that clients can tell if authentication was successful;
   this is almost a good idea but I'd like to see instead:

      X-VO-Authenticated: <authenticated-user-id>

   which provides more information and can give the user more confidence
   that they've done what they thought they did.


Supporting anonymous and authenticated access on a single endpoint
------------------------------------------------------------------

   Pat suggests that clients can provoke a challenge-bearing 401
   response by supplyingn a dummy Authorization header:

       Authorization: tell-me-how-to-auth

   I think that would work, but I don't think it's necessary.
   RFC 7235 section 4.1 says:

      A server generating a 401 (Unauthorized) response MUST send a
      WWW-Authenticate header field containing at least one challenge.  A
      server MAY generate a WWW-Authenticate header field in other response
      messages to indicate that supplying credentials (or different
      credentials) might affect the response.

   So I think that services which support anonymous-or-authenticated
   accesses could just include the relevant WWW-Authenticate headers
   on all responses (not just 401s).  Vanilla HTTP clients would
   generally ignore these, but SSO-aware clients could look out
   for this behaviour and supply Authenticate headers without ever
   encountering a 401.  Unless I'm missing something.


I have proof-of-concept implementation for cookie-based login
tested against the ESDC service, which I will work to refine.
If CADC or anybody else implements something similar using
other authentication schemes (especially OAuth2.0/Bearer)
then I'll have a go at those.

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/