SSO BasicAA

[Giuliano Taffoni]

Thanks Patrick 
I do not have to add more to your answer, except that we may prepare an errata if we want to specify better 7.2 
Or maybe we can summarise the results of the discussions we had the last year in  a Note with some example, or maybe  suggestions for the developers
if we already identify some  :-)
Regards
G.



> On 2 Apr 2019, at 16:42, Patrick Dowler <pdowler.cadc at gmail.com> wrote:
> 
> 
> 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/