SSO BasicAA

[Patrick Dowler]

Responses in no particular order:

- in general the language in SSO encourages use of TLS (https) when sending
senistive info but does not ban http

- I am probably to blame for that #BasicAA securityMethod in the first
place (we started using a w3.org URL that ended in #BasicAA way back) and I
think it has to be taken to mean basic and not digest. Do we need a
#Digest? see below

The paragraph at the end of section 3 (before 3.1) says that in general
service endpoints should be using #Oauth, #cookie, #tls-with-certficate
and/or allow anon. Special "login" endpoints where you get such tokens
(oauth and cookie) should be using #tls-with-password,
#tls-with-certifcate, and/or #saml2.0 -- you will note that #BasicAA
doesn't appear anywhere in this recommendation! I think it is for all the
same reasons that TAP-1.1 was hard and we had that meeting in Trieste :-)
It could be because #BasicAA is inherently the opposite of SSO (!single :
you sign in every time) but I think that paragraph is just somewhat more
prescient about the way things would/should go.

So, SSO also seems to leave #BasicAA off to the side as the thing that
doesn't fit the big picture. That probably doesn't help client writers come
up with a strategy but I would say to keep the concepts in that paragraph
in SSO in mind as it captures the way things will work now and in future.


Aside: One thing that is seems missing is an actual spec for
#tls-with-password. When I read section 7 it says the username and password
are passed in the message body but doesn't specify exactly how (2 params? 2
parts with separator? simple doc format?). Now that I read it again, 7.2
really confuses me :-) Anyway, I have some ideas on what to do with this
issue that are related to another email thread on standardising "login" to
an SSO realm.

--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada


On Tue, 2 Apr 2019 at 03:45, Mark Taylor <M.B.Taylor at bristol.ac.uk> wrote:

> Hi GWS.
>
> I'm looking at the SSO 2.0 standard, specifically section 4,
> "HTTP Basic Authentication", and there are some points I would like
> to have clarified.  The text says this:
>
>    "Services using HTTP basic authentication SHALL use the authentication
>     mechanism described in the RFC7235 (Fielding, 2014) that updates
>     RFC2617 (Franks and Hallam-Baker et al., 1999). Interfaces using this
>     mechanism SHALL be registered with the security method
>     ivo://ivoa.net/sso#BasicAA"
>
> But the RFCs referenced here don't really match the text.
>
> RFC 2617 defines approximately three things:
>
>    [A]: challenge/response framework, i.e 401 HTTP response etc (section 1)
>    [B]: Basic authentication scheme (section 2)
>    [C]: Digest authentication scheme (section 3)
>
> RFC 7235 on the other hand really just talks about [A].
> RFC 2617 is obsoleted by more than one document, in particular:
>
>    [A]: discussed in RFC 7235
>    [B]: discussed in RFC 7617
>    [C]: discussed in RFC 7616 (and maybe RFC 7615)
>
> The Commentary section 4.2 in SSO is not particularly clearly worded,
> but from the text:
>
>    "The 'HTTP basic authentication' SHOULD be used with particular
>     attention as sensible information (password) are sent over the
>     wire in base64 encoding"
>
> it seems that it is talking specifically about [B].  At the least
> therefore, I think that SSO section 4 ought to include a reference
> to RFC 7617 instead of, or possibly as well as, RFC 7235.
>
> Even so however, I'm still not certain exactly what is required from
> a service that declares a SecurityMethod ivo://ivoa.net/sso#BasicAA.
> In particular, does it have to use the "Basic" authentication scheme
> ([B]), or is it permitted to use "Digest" ([C]) or other non-standard
> authentication schemes permitted by the HTTP authentication
> framework ([A])?  I'm guessing that [B] is required, but it would
> be nice to have this made explicit in the text.
>
> Thinking further along these lines: if BasicAA does indeed mandate [B],
> maybe we should add another SecurityMethod option for the Digest
> authentication scheme [C].  Although the authors of RFC 7616 are at
> pains to point out that Digest authentication is not a total solution
> to security over HTTP(S), it does provide user/password authentication
> without sending passwords over the wire, so it's a whole lot better
> than Basic, it likely provides security strong enough for the kind
> of thing astronomers (and maybe even data centers) care about, and
> it's probably a lot less effort than something like OAuth.  I'm not
> necessarily advocating this, since another Auth option becomes another
> implementation burden for client authors, but it could be worth
> bearing in mind.
>
> While I'm griping about this section, some clarification about use of TLS
> would be nice too; it currently says "Connection secured with TLS are
> RECOMMENDED prior to exchanging any credentials."  I *think* what it
> means is that if you're using BasicAA it's a good idea to do it over
> HTTPS rather than HTTP, but I'm not certain.
>
> 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20190402/8d24e72f/attachment.html>